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

["David P. Maynard" <dpm () flametree com>]

The "ip verify reverse-path" setting certainly sounds like a good thing, 
but I will admit to not having tested it.  Depending on how Cisco has
implemented it, the setting could eliminate the DOS problem as effectively
as manually configuring access to the NAT pool.  I believe that they even
recommend it in some of the "best practice" documents.

I always prefer explicit filters when configuring routers, so I never use
the IOS equivalent.  It never occurred to me to consider the PIX feature
as an alternative to limiting access to NAT.  The original Release Notes
for the feature (from 4.4(5)) mention that they perform a routing table
lookup to validate every session.  I doubt that is any more intensive than
performing the ACL match though.  (If people are pushing the CPU on a
PIX hard enough that it matters, they probably shouldn't be using that PIX
anyway.)

I would bet that the vast majority of PIX installations could run with
ip verify reverse-path enabled.  The multi-exit network topologies where 
you typically can't use the IOS version of the feature would already 
"break" the stateful inspection tables.  Maybe Cisco should change the PIX
to enable the verify reverse-path feature by default.

"Zeke Gibson [STI]" wrote:
> 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
> > --