Re: PIX DOS (config problem) - Similar to NetScreen ScreenOS...

["Zeke Gibson [STI]" <zeke () silastech com>]

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
> --