cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
457
Views
4
Helpful
3
Replies

guidelines on securing pix

rpalacio
Level 1
Level 1

Hi,

Anyone could provide me a link on guidelines or best practices on securing the secure pix?

Thanks alot.

3 Replies 3

nkhawaja
Cisco Employee
Cisco Employee

Hi,

Not sure if any such document exists. Basically Cisco firewall default configuration is based on best practices. You just to start configuring the firewall for your network . No need to worry about securing it in particular.

just a thought

thanks

Nadeem

tbissett
Level 1
Level 1

I generally like the PIX firewall and I'm not trying to start a flame war or anything. However I do respectfully disagree that the default config as Cisco recommends is based on best practices. Here are things my issues with it:

1) Implicit "allow all" policy on inside interface - This allows your hosts to participate in DoS attacks on any service and any port.

Recommendation: Use an access-list on the inside interface to restrict traffic to only specific protocols/ports. This applies the security best-practice "deny all unless specifically allowed" policy.

2) ICMP allowed to all interfaces - Enough said. The firewall should silently drop ICMP requests per best practices.

Recommendation: Apply command icmp deny any any [interface] to at least the outside interface. If you have path MTU rediscovery issues, you may need to alter this slightly.

3) On the NAT command, Cisco docs frequently use "NAT (inside) 1 0.0.0.0 0.0.0.0" as an example. Similar to #1 above, using this command allows all traffic to be NATed from the inside. While this sounds harmless, think IP spoof. If a spoofed packet were to go outbound on port 80, even an outbound access-list won't stop it. And since the NAT allows any inside IP out, the NAT won't stop it either.

Recommendation: When programming your NAT statements, use specific networks/subnet masks.

4) Don't use telnet to administer the device. Use at least SSH (currently V1. Hopefully, Cisco will someday change it to V2) or the GUI via HTTPS.

5) At the very least, set up the local user database to identify specific administrators. If you have a lot fo firewalls, look into RADIUS or TACACS+. A single generic username and password (PIX default) is not security best practice.

6) Get ready for this one: Here's a big gotcha that I see all the time in PIX configs. This problem usually occurs when you have hosts in the DMZ that are allowed to go anywhere, AND you have statics defined from the inside of your network to the DMZ. Let me see if I can show an example here:

In the DMZ:

Mail relay at 192.168.1.1 - Talks to Internet and an internal mail server at 10.1.1.1

DNS server at 192.168.1.2 - Only talks to Internet

Most admins set up the rules as follows:

access-list dmz permit tcp host 192.168.1.1 any eq smtp

access-list dmz permit udp host 192.168.1.2 any eq domain

static (inside,dmz) 192.168.1.3 10.1.1.1

The problem with the above rules is that not only is the mail relay allowed to talk to the inside server via smtp, but so is the DNS server. The DNS was not intended.

Even worse, many admins don't use an access-list in the DMZ (again, going back to the default allow all policy for Internet access as in #1). At that point, ALL your hosts in the DMZ can talk on any port to the servers defined via static commands to the inside. Not good.

To fix, the access-list, you ant to permit only SMTP from the DMZ to that one inside host, then deny all other traffic to the inside host should look like this:

access-list dmz permit tcp host 192.168.1.1 any eq smtp

access-list dmz deny ip any host 192.168.1.3

access-list dmz permit udp host 192.168.1.2 any eq domain

So, now your DMZ mail relay can talk to anything on the Internet and the one host on the inside via SMTP. The next rule denies all else to the inside host. Finally, the third rule allows the DNS server to go anywhere on the Internet. Since access-lists match from the top down, the DNS server will not be allowed to talk to the inside host.

Hope all this helps :-)

Thanks a lot. Youve just done a very good explanation. I appreciate your help a lot.

Some additional issues like the static and nat command options of max connections and embryonic connections are just few of my concerns. Theres nothing i could find as to how to gauge this figure. So Iam just leaving it as default 0 0 which i know is not secure coz it accepts infinite embryonic connections.

Review Cisco Networking for a $25 gift card