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

From: Zeke Gibson [STI] (
Date: 02/06/02

From: "Zeke Gibson [STI]" <>
To: "David P. Maynard" <>
Date: Tue, 5 Feb 2002 17:20:55 -0800


I found your notes very interesting, and I too must agree that Cisco's
configuration example is less-than ideal. What about the ip verify
reverse-path command?
First introduced in PIX OS 4.4, notes at:

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

Thanks in advance,

Zeke Gibson, Sr. Systems Engineer
Silas Technologies Inc.
Cisco Premier / Aironet Specialized

----- Original Message -----
From: "David P. Maynard" <>
To: <>
Sent: Saturday, February 02, 2002 4:34 PM
Subject: Re: PIX DOS (config problem) - Similar to NetScreen ScreenOS...

> 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
> The "1" is the global NAT pool identifier and the "" 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 and, then use:
> nat (inside) 1 0 0
> nat (inside) 1 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
>, Inc. -- Managed IT Operations Solutions [TM]
> EMail:, Tel: +1 512 977 8918, Fax: +1 512 977 0986
> --