|
|
|
|
| |
| Users of Cisco Pix Firewalls may discover that their pool of NAT'ed IP addresses is running out, and that a reboot or reload of the firewall clears the problem, this is due to a vulnerability in the Cisco Pix Firewall that allows specially constructed ICMP packets to deplete the pool. |
| |
Credit:
The information has been provided by John Airey
|
| |
Vulnerable Systems:
* Cisco Pix Firewall IOS versions 6.2.2 and 6.3.(3.102)
The problem is caused by the Firewall being swamped by incoming ICMP packets on the global pool IP addresses. If these are not intercepted by a router beforehand, the incoming echo requests (that are emanating from Nachi/Welchia worm infected machines) are preventing the release of the address translation. i.e.: The Cisco Pix Firewall is detecting the blocked traffic as indication that the translation is still in use.
Workaround:
For those who are unable to block incoming ICMP echo requests at their router (for whatever reason), Cisco has released the following details:
1 - use PAT (a global pool with a single entry) this way although the xlate will remain up but all your internal hosts will be multiplexed over this pat address. single pat address can accommodate in theory 65535 connections. However, this might break un-PATable traffic
2 - Use statics for your important servers that need NAT (1 to 1 mapping)
3 - Also instead of rebooting the whole pix you can simply log into it and do "clear xlate" this will clear all translations.
It should be pointed out that "2" is not a solution to this problem. The others are not ideal either.
Vendor Status:
Cisco was notified and bug ID CSCec47609 has been opened to investigate this issue.
Cisco have updated the Security Notice about the "Nachi Worm Mitigation Recommendations" ( http://www.cisco.com/warp/public/707/cisco-sn-20030820-nachi.shtml ) to reflect this information.
|
|
|
|
|
|
|
|
|
|
