TUCoPS :: Unix :: General :: krnl15~1.txt

COMMAND
 kernel
SYSTEMS AFFECTED
 Sun, HpUX 11.00
PROBLEM
 Ofir Arkin and Alfredo Andr駸 Omella found following. It appears
 that only some of the operating systems would answer an ICMP
 Address Mask Request. Those operating systems include: ULTRIX
 OpenVMS, Windows 95/98/98 SE/ME, NT below SP 4, and SUN Solaris
 machines. How can we distinguish between those who answer the
 request?
 This is a regular Address Mask Request sent by SING
 http://sourceforge.net/projects/sing
 written by Alfredo Andr駸 Omella, to a SUN Solaris 2.7 machine:
 [root@aik icmp]# ./sing -mask IP_Address
 SINGing to IP_Address (IP_Address): 12 data bytes
 12 bytes from IP_Address: icmp_seq=0 ttl=236 mask=255.255.255.0
 12 bytes from IP_Address: icmp_seq=1 ttl=236 mask=255.255.255.0
 12 bytes from IP_Address: icmp_seq=2 ttl=236 mask=255.255.255.0
 12 bytes from IP_Address: icmp_seq=3 ttl=236 mask=255.255.255.0
 12 bytes from IP_Address: icmp_seq=4 ttl=236 mask=255.255.255.0
 --- IP_Address sing statistics ---
 5 packets transmitted, 5 packets received, 0% packet loss
 All operating systems that would answer with ICMP Address Mask
 Reply would reply with the Address Mask of the network they reside
 on. What would happen if we would introduce a little twist? Lets
 say we would send those queries fragmented?
 In the next example, we have sent ICMP Address Mask Request to the
 same SUN Solaris 2.7 box, this time fragmented to pieces of 8
 bytes of IP data. As we can see the answer we got was unusual
 (the -c 2 option used with SING enables it to send two ICMP
 Address Mask request datagrams only):
 [root@aik icmp]# ./sing -mask -c 2 -F 8 IP_Address
 SINGing to IP_Address (IP_Address): 12 data bytes
 12 bytes from IP_Address: icmp_seq=0 ttl=241 mask=0.0.0.0
 12 bytes from IP_Address: icmp_seq=1 ttl=241 mask=0.0.0.0
 --- IP_Address sing statistics ---
 2 packets transmitted, 2 packets received, 0% packet loss
 [root@aik icmp]#
 The tcpdump trace:
 20:02:48.441174 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
 icmp: address mask request (frag 13170:8@0+)
 4500 001c 3372 2000 ff01 50ab 8b5c d015
 xxxx xxxx 1100 aee3 401c 0000
 20:02:48.442858 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
 (frag 13170:4@8)
 4500 0018 3372 0001 ff01 70ae 8b5c d015
 xxxx xxxx 0000 0000
 20:02:49.111427 ppp0 < Host_Address > slip139-92-208-21.tel.il.prserv.net:
 icmp: address mask is 0x00000000 (DF)
 4500 0020 3618 4000 f101 3c01 xxxx xxxx
 8b5c d015 1200 ade3 401c 0000 0000 0000
 20:02:49.441492 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
 icmp: address mask request (frag 13170:8@0+)
 4500 001c 3372 2000 ff01 50ab 8b5c d015
 xxxx xxxx 1100 ade3 401c 0100
 20:02:49.442951 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address:
 (frag 13170:4@8)
 4500 0018 3372 0001 ff01 70ae 8b5c d015
 xxxx xxxx 0000 0000
 20:02:50.011433 ppp0 < Host_Address > slip139-92-208-21.tel.il.prserv.net:
 icmp: address mask is 0x00000000 (DF)
 4500 0020 3619 4000 f101 3c00 xxxx xxxx
 8b5c d015 1200 ace3 401c 0100 0000 0000
 The same SUN Solaris box now replies with a 0.0.0.0 as the Address
 Mask for the Network it resides on. What would happen with the
 other operating systems? They all would respond with the
 same/real Address Mask Reply.
 Here we got a distinction between SUN Solaris machines and the
 other operating systems that would answer those queries. When
 this has been tested with this method authors encountered some
 problems replicating the results with different ISPs. As it seems
 from analyzing the information they got, certain ISPs would block
 fragmented ICMP datagrams. This behavior would not enable this
 method to succeed.
 Operating Systems tested:
 LINUX Kernel 2.4t2; LINUX Kernel 2.2.14; FreeBSD 4.0, 3.4;
 OpenBSD 2.7 & 2.6; Solaris 2.5.1, 2.6, 2.7 & 2.8; HP-UX 10.20;
 AIX 4.1; ULTRIX; Microsoft Windows 95 / 98 / 98SE / ME / NT 4
 SP3, SP4, SP6a WRST & SERVER / 2000 Professional & Server.
 According to Peter J. Holzer, HP-UX 11.00 has same behaviour.
 Amusing, but not as strange as it seems because both share their
 TCP/IP STREAMS lineage with the same third party crowd (Mentat).
SOLUTION
 Block fragmented ICMP datagrams. One reason why good solaris
 admins do things like:
 ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
 ndd -set /dev/ip ip_respond_to_echo_broadcast 0
 ndd -set /dev/ip ip_respond_to_timestamp 0
 ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
 ndd -set /dev/ip ip_forward_directed_broadcasts 0