David, I found your notes very interesting, and I too must agree that Cisco's published configuration example is less-than ideal. What about the ip verify reverse-path command? First introduced in PIX OS 4.4, notes at: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v44/relnotes/p ixrn445.htm#xtocid2419610 I agree that simply configuring the NAT statement to allow any inside host to establish an outbound connection and occupy an xlate slot is sloppy, and I recommend that explicit network identifiers always be used when associating a NAT identifier to a global pool. I was just curious as to your thoughts about reverse-path? Thanks in advance, ******************************************** Zeke Gibson, Sr. Systems Engineer Cisco CCNP/CCDP, MCSE, CCEA Silas Technologies Inc. Cisco Premier / Aironet Specialized www.silastech.com ******************************************** ----- Original Message ----- From: "David P. Maynard" <dpm@flametree.com> To: <bugtraq@securityfocus.com> Sent: Saturday, February 02, 2002 4:34 PM Subject: Re: PIX DOS (config problem) - Similar to NetScreen ScreenOS... > > clathem@skyhawke.com said: > > Problem: NetScreen ScreenOS 2.6.1 subject to Trust Interface DoS > > Attack > >... > > Exploit: Someone within the trusted side of the network can attempt a > > portscan on an external IP address. When the scan runs it appears to > > consume all of the available sessions. This, in turn, causes a DoS > > to the entire trusted interface. > > For what it's worth, the instructions that Cisco publishes on how to > configure the PIX firewall will make many users subject to a similar DOS > attack. > > Cisco's published examples (at least the ones I have seen) on how to > configure NAT for the PIX all show the following command: > > nat (inside) 1 0.0.0.0 0.0.0.0 0 0 > > The "1" is the global NAT pool identifier and the "0.0.0.0 0.0.0.0" is the > address and netmask of addresses that are allowed to use the pool. In > other words, any source IP on the inside interface is allowed to use > global NAT pool 1. > > Given this configuration and a limited NAT pool, any machine on the inside > network can create a DOS situation by launching a large number of outbound > connections using random source IPs. Each random source IP will occupy > one slot on the NAT table until they are all exhausted. Adding an > "overload" or "PAT" address will mitigate the situation, but still isn't a > "fix." > > A much better configuration is to restrict access to the NAT pool to valid > source IPs on your local network. For example, if your inside network > uses 192.168.0.0/24 and 192.168.5.0/24, then use: > > nat (inside) 1 192.168.0.0 255.255.255.0 0 0 > nat (inside) 1 192.168.5.0 255.255.255.0 0 0 > > With all of the publicity over the past few years about proper egress > filtering at border routers, you would think that more people would catch > this problem. Unfortunately, I can safely say that I have never seen a > PIX configured by anyone else that restricted NAT access to valid source > IPs. Some of these boxes had been configured by end-users who were just > reading the docs and wouldn't know any better. Unfortunately, a fair > number of them had been configured by high-dollar network consultants (who > apparently didn't know any better either). > > It is possible that PIX OS has a recent feature that can mitigate the > impact of this problem, but I have seen it take down entire sites back > when smurf attacks first came around. In any event, it is always a good > idea to validate the source IPs leaving your network. > > -dpm > > > -- > David P. Maynard, CTO > OutServ.net, Inc. -- Managed IT Operations Solutions [TM] > EMail: dmaynard@outserv.net, Tel: +1 512 977 8918, Fax: +1 512 977 0986 > -- > >
