Home page logo

bugtraq logo Bugtraq mailing list archives

Re: PIX DOS (config problem) - Similar to NetScreen ScreenOS...
From: "Zeke Gibson [STI]" <zeke () silastech com>
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" <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
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

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

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.


 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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]