OK - here are some test results. I apologize in advance for the length of the message, I'm enclosing TCPDUMP results below.
I first tried nmap -vO -p 22 |grep IPID directed against BOTH the internal and external PIX interface (from each side) and received: IPID Sequence Generation: Incremental on both. I then tried nmap -vO -p 22 |grep IPID directed from the outside of the firewall directed against an internal LINUX host and received: IPID Sequence Generation: All zeros I tried the previous test again using port 80 and 443 (22, 80 and 443 are all permitted through the firewall from my test machine on the outside of the firewall) directed against the same internal LINUX host and still received: IPID Sequence Generation: All zeros Then I tried nmap -vO -p 80 |grep IPID from the outside of the firewall directed against an internal WINDOWS Server and received: IPID Sequence Generation: Incremental I tried it again against another WINDOWS Server substituting port 389 (LDAP as the other server wasn't a web server) and also received the Incremental result. Very strange! So - It appears that the PIX is not randomizing IP IDs and I'm not sure what to make of the Linux results since when I Nessus scan it with either itself or another Linux Nessus system (from the outside or inside of the PIX firewall) I get the same Nessus warning that the remote system does not randomize TCP results. Well, now that I think about it - they are not random, they are all zeros! Anyone have any idea why? What do you think? Time to call Cisco? Here are the TCPDUMP results - note I've trimmed out unnecessary stuff and am only enclosing return traffic since the PIX is supposed so randomize the ID's of returning traffic (which the Nessus specifically tests for): 1st test - Internal NMAP\TCPDUMP System to Internal PIX Interface: PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.38994:(ttl255,id37964,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.39001:(ttl255,id37965,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.39002:(ttl255,id37966,le n60) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.39003:(ttl255,id37967,le n44) PIX_FIREWALL_INSIDE_INT.43504>NMAP&TCPDUMP_SYSTEM.39005:(ttl255,id37968, len60) PIX_FIREWALL_INSIDE_INT.43504>NMAP&TCPDUMP_SYSTEM.39006:(ttl255,id37969, len60) PIX_FIREWALL_INSIDE_INT.43504>NMAP&TCPDUMP_SYSTEM.39007:(ttl255,id37970, len60) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.38995:(ttl255,id37971,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.38996:(ttl255,id37972,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.38997:(ttl255,id37973,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.38998:(ttl255,id37974,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.38999:(ttl255,id37976,le n44) PIX_FIREWALL_INSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.39000:(ttl255,id37977,le n44) 2nd test - External NMAP\TCPDUMP System to External PIX Interface: PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49966:(ttl255,id32750,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49973:(ttl255,id32751,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49975:(ttl255,id32752,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49967:(ttl255,id32753,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49968:(ttl255,id32754,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49969:(ttl255,id32755,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49970:(ttl255,id32756,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49971:(ttl255,id32757,l en44) PIX_FIREWALL_OUTSIDE_INT.ssh>NMAP&TCPDUMP_SYSTEM.49972:(ttl255,id32758,l en44) 3rd test - External NMAP\TCPDUMP System to Internal Linux System - SSH (HTTP and HTTPs returned the same results - all ID 0): LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.32770>NMAP&TCPDUMP_SYSTEM.ssh:(ttl64,id 17649,le LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.32774>NMAP&TCPDUMP_SYSTEM.ssh:(ttl64,id 36004,le LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.32774>NMAP&TCPDUMP_SYSTEM.ssh:(ttl64,id 36005,le LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.32774>NMAP&TCPDUMP_SYSTEM.ssh:(ttl64,id 36006,le LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.32774>NMAP&TCPDUMP_SYSTEM.ssh:(ttl64,id 36007,le LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40120:(ttl64,id 0,len44) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40127:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.32970>NMAP&TCPDUMP_SYSTEM.40137:(ttl64, id0,len4 LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40121:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40122:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40123:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40124:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40125:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40126:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40127:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.35105>NMAP&TCPDUMP_SYSTEM.40131:(ttl64, id0,len4 LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40121:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40122:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40123:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40124:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40125:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40126:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40127:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.31098>NMAP&TCPDUMP_SYSTEM.40131:(ttl64, id0,len4 LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40121:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40122:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40123:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40124:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40125:(ttl64,id 0,len60) LINUX_SYSTEM_ON_OTHER_SIDE_OF_FW.ssh>NMAP&TCPDUMP_SYSTEM.40126:(ttl64,id 0,len60) 4th test - External NMAP\TCPDUMP System to Internal Windows Server (note - this test was to an IIS Server. The other test to port 389 on another server returned the same results - non-random ID's.): 192.168.90.12.http>lnxsvr5.officenet.local.62092:(ttl128,id13172,len44) 192.168.90.12.http>lnxsvr5.officenet.local.62099:(ttl128,id13173,len60) 192.168.90.12.44254>lnxsvr5.officenet.local.62103:(ttl128,id13174,len40) 192.168.90.12>lnxsvr5.officenet.local:icmp:192.168.90.12 udp port 44254 unreachable(ttl128,id13175,len56) 192.168.90.12.http>lnxsvr5.officenet.local.62093:(ttl128,id13246,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62094:(ttl128,id13249,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62095:(ttl128,id13250,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62096:(ttl128,id13251,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62097:(ttl128,id13252,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62098:(ttl128,id13254,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62099:(ttl128,id13262,len60) 192.168.90.12.36073>lnxsvr5.officenet.local.62103:(ttl128,id13263,len40) 192.168.90.12>lnxsvr5.officenet.local: UDP port 36073 unreachable(ttl128,id13264,len56) 192.168.90.12.http>lnxsvr5.officenet.local.62093:(ttl128,id13379,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62094:(ttl128,id13403,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62095:(ttl128,id13405,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62096:(ttl128,id13406,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62097:(ttl128,id13407,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62098:(ttl128,id13408,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62099:(ttl128,id13421,len60) 192.168.90.12.38498>lnxsvr5.officenet.local.62103(ttl128,id13423,len40) 192.168.90.12>lnxsvr5.officenet.local:icmp: udp port 38498 unreachable(ttl128,id13424,len56) 192.168.90.12.http>lnxsvr5.officenet.local.62093:(ttl128,id13432,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62094:(ttl128,id13433,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62095:(ttl128,id13434,len60) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13437,len48) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13438,len40) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13439,len142) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13440,len180) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13441,len186) 192.168.90.12.http>lnxsvr5.officenet.local.62096:(ttl128,id13442,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62097:(ttl128,id13443,len60) 192.168.90.12.http>lnxsvr5.officenet.local.62098:(ttl128,id13444,len60) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13445,len40) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13446,len40) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13447,len40) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13448,len40) 192.168.90.12.1903>lnxsvr5.officenet.local.10000:(ttl128,id13449,len40) --------------------------------------------- Mark F. Ewert, Principal Systems Architect Integrated Healthcare Information Services www.ihcis.com -----Original Message----- From: Paul Johnston [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 4:52 AM To: David Gibson Cc: Mark Ewert; Michael Scheidell; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Nessus & Cisco PIX non-random IP IDs Hi, Some ways I've found to investigate this: nmap -vO -p <one open port> target | grep IPID This reports "IPID Sequence Generation" which seems more reliable than the Nessus plugin. If you use tcpdump -v, the ipid is included in the output. If the ipid really is non random, you can prove this by attempting an nmap idle scan. This lets you scan a remote box, using the box with predictible ipid as a decoy - the scan will appear to come from that IP address. This problem is common in the wild. All versions of windows up to latest XP (2003 not tested) have predictible ipid, although firewalls limit the idle scan potential in practice. Paul David Gibson wrote: >Do you have any sense as to whether or not this is a false positive? I >haven't gone through the packets to see if there's a discernible pattern >to the IP ID's... > >David > > -- Paul Johnston Internet Security Specialist Westpoint Limited Albion Wharf, 19 Albion Street, Manchester, M1 5LN England Tel: +44 (0)161 237 1028 Fax: +44 (0)161 237 1031 email: [EMAIL PROTECTED] web: www.westpoint.ltd.uk --------------------------------------------------------------------------- This e-mail and the information transmitted within it is intended only for the recipient(s) to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back to notify the sender and delete the message and its contents from any computers and network systems involved in its receipt. Thank you.
