-- [ Host Detection ] --

	Generating arbitrary responses to identify inter-networked nodes.

 			  [ dethy@synnergy.net ]

 Authors Note: This article was published for TISC "Insight" Newsletter,
 	       (The Internet Security Conference: http://tisc.corecom.com).


-- [ What is host detection? ] --


Host detection is  a method of  actively testing nodes  of a network   and
effectively   identifying  those   hosts  that   have  an  inter-networked
connection.  Circumventing firewall  rule-sets and  access control   lists
(ACL's) applied  at the  router  or  firewall level  allow some  arbitrary
client to  map and  interrogate  nodes  after the  initial host  detection
discovery has taken place.

Well-experienced   network  administrators   implement  ingress  filtering
rule-sets  to   block  many  forms  of   host  detection.  However,  these
applied filtering  rules  only  block the   most simplistic  form  of host
detection methods. These common discovery techniques involve:

 * TCP  three-way  handshake  sequence 
 *   Setting TCP  flags  in packets 
 * Sending NULL packets 
 * ICMP echo requests (PING)

Other  forms  of  traffic  are  essentially  categorised  into  the  above
three major protocol oriented requests.

Advanced methods  of host  detection will  ultimately enable  a client  to
completely map  an  entire  network whilst   going unnoticed  and  passing
through   many   firewall  implementations.   These   elusive   techniques
include:

 * Missing  packet  fragments  
 * Invalid   IP header  lengths  
 * Invalid IP field values

The underlying  condition  that  separates the   basic and  advanced  host
detection  methods   is  that  advanced  methods   generate  an  arbitrary
response  from  an  arbitrary  node,  usually  in  the  form  of  Internet
Control   Message  Protocol   (ICMP)  traffic.   Arbitrary  responses  are
created by   encapsulating malformed   data within   the packet,   itself.
Basic forms  of detection  are RFC-compliant,  involving transmission   of
valid packets across the network.


-- [ Generating protocol responses ] --


Creating   anomalistic  IP   headers  in   transmission  will  effectively
increase the  chances  of  detecting a   filtered host,  as  it forces the
node to  generate a  protocol error  message in  response to the malformed
packet.

Imagine a   client spawning   a payload   of intrusive   packets across an
entire network   - for   each packet   sent an   Internet Control  Message
Protocol response  would be   generated and  returned to   the instigating
client. The   client then   deviously could   create a   database of hosts
mapped on   that network,   even though   other such   basic forms of host
detection methods would have failed due to packet filtering.

Many forms   of intrusion   detection systems   and routers   do not  drop
packets   that contain   malformed header   information such   as invalid
protocol  field   values.  This   allows  the   packet  to   pass  through
undetected   and more   importantly, unblocked.   In an   IP masquerading
network, where a firewall's external address is the only node  exposed  to
the     Internet,   host-detection     techniques   immediately     become
restricted. Since the  true mask of  the target host  is cloaked with  the
firewall's public  Internet address,  mapping the  internal network  would
only reveal  the firewall's   presence and  not the   Intranet's. However,
examining  the   network and   the  hosts  within  is   not impossible.  A
technique known as 'passive host fingerprinting' could be carried  out  to
compare and contrast the IP response elicited from the target host.

Take our   previous scenario   for example.   A client   sends a malformed
packet to  a  network-connected  host, where   the firewall  forwards  the
packet to the  target. Now if  the target host  has no filtering  measures
implemented, the  packet is  sent back  by the  firewall complete with the
ICMP error  response message.  Since the  returned packet  is encapsulated
within IP, a  closer analysis of  this layer could  be used to   determine
whether it was   in fact, the   firewall that returned   the packet or   a
host within  the network.  The IP  criteria for  this host  identification
method includes:


 * TTL	- 	time to live value  
 * TOS  - 	type of service  value  
 * DF   - 	don't fragment bit (TCP detection methods)


The foundation  for this  technique relies  on knowing  a host's Operating
System and the  default IP values   it uses. If  the firewall is   a Linux
host, but the  IP values of  the ICMP packet  are indicative of  a Solaris
host, then we   can assume that   there is at   least one other   internal
host behind the firewall. 

Example  Operating   System  default  IP  values   in  the  returned  ICMP
packet:

  __________________________________________________________
 |   OS			Kernel		Arch	TTL	DF  |                                                                    |
 |__________________________________________________________|
 | Linux		2.2.x		I386	64	Yes |
 | OpenBSD		2.x		I386 	225	No  |
 | Solaris		2.x		SPARC	255	Yes |
 | Cisco Catalyst	5505,OSS 4.5	-	 60	-   |  
 | Windows		95  		I386	 32	Yes |
 | Windows		98/2k/NT/ME	I386	128	Yes |
 |__________________________________________________________|


Further information involving  passive fingerprinting can  be obtained  at
http://www.enteract.com/~lspitz.


With  this   relevant fact   in  mind,  effective  rule-sets   need to  be
applied and  implemented that  block  not  only misguided  traffic at  the
network-perimeter   (eg,   packet-filtering  router   or   firewall)   but
anomalistic packets that could otherwise allow unnecessary information  to
be  leaked out   unknowingly. Yes,  it is   time to  review your   packet
filtering methods   for the   21st century   - times   are changing, as is
technology, are  your policies  and firewall  configuration keeping   pace
with the increased sophistication of attacks?


-- [ Analysis of invalid packets ] --


Understanding the  packets elicited  in advanced  host detection  plays  a
vital role   in actively   identifying techniques   used in   the wild  to
discover and compromise unaware networks.

The aforementioned  malformed  IP  packet values   that force  a  response
from a  node on  networks have  the potential  to bypass heavily  filtered
hosts. Perhaps   your firewall   blocks bread   and butter   ICMP Type  8 
- Echo   requests but   does it   explicitly filter   the invalid  packets
detailed below?


-- [ Missing packet fragments ] --


The packet   containing a   fragmented offset   within their   IP field is
initially sent  to query  a  remote  host. Instead  of assembling  another
fragmented datagram to complete the packet block, the client will  let the
initial  fragmented datagram  timeout, leaving  the server waiting for the
next expected packet in  the sequence. The effect  of this is an  elicited
ICMP  Type 11  Code 1  - Time  Exceeded Fragment  Reassembly, generated by
the server transmitted back to the client.


-- [ Invalid IP header lengths ] --


Specifying an invalid header length within an IP header will result in the
remote  host  generating  an   ICMP Type  12  -  Parameter   Problem error
message.  The  code  type  within  this  ICMP  datagram  may  be equal  to
either of the following:

 * 0 - Pointer indicates the error 
 * 2 - Bad Length 

A code value  equal to 0   will return the  exact byte, which   caused the
error   encapsulated within   the pointer   field. Alternatively   a code
equal to   2 signifies   the entire   packet contains   errors. In  either
case, the host  on the receiving   end of this  packet solicits the   ICMP
Type 12 Code  (0 | 2)  in return to  tell the sender  that the packet  has
been  discarded     or dropped.     Once  again    this  allows     for an
effective host    detection   method    to  be    used   in    identifying
some  previously  unknown host.  This technique  is similarly  related  to
creating invalid packet  checksums, which in  effect produce the same ICMP
error message.  Statistically, much of the time, however, checksum  errors
are more easily detected and dropped  on the remote host than other  forms
of advanced host detection.


-- [ Invalid IP field values ] --


On a more general note, specifying invalid values within any fields of the
IP header will elicit ICMP  error response messages from the  target host.
Such a case  is with  the  IP 'protocol' field,  which has  a  total of  8
bits   in  length   and  hence   has  a   possible  total   of  256  (2^8)
combinations. The   trick involved   in this   instance is   by electing a
protocol value   that is   not indicative   of a   legal protocol value on
that host. A  client is able  to determine if  a host does  not support  a
protocol,  as   the  server   will  generate   an  ICMP   Type  3  Code 3 
- Destination  Unreachable Protocol   Unreachable. If  a response   is not
sent  back,   the  client   assumes  that   this  protocol   specified  is
supported  on   that  host,   and  the   protocol  value   would  then  be
incremented to   re-query that   host for   its network   presence in hope
that the protocol is not supported.

The aim in   this situation is   not to brute   force a complete   list of
protocol   values, which   may be   increasingly noticeable   in firewall
logs, but rather  locate a protocol  that is unsupported  on a host  in  a
minimum number of attempts.

As we can  see, these packets   can and will  provide information to   any
client on the Internet unless proper rule-sets are established.


-- [ Blocking malformed ingress traffic ] --


As is   always the   case, "Prevention   is better   than cure". Initially
blocking  incoming   traffic  that   acts  to   engage  in   malicious  or
unnecessary behaviour  should be   explicitly caught  and dropped   by the
router or some ACL before it reaches its target host.

Isolating and  filtering  packets  described above   is one  step  forward
into securing  any inter-network  connected node.  Below are  a few rules,
which should  be applied  to  firewalls  and routers  to put  an immediate
halt to advanced host detection techniques.


 * drop  anomalistic traffic on TCP/IP/ICMP/UDP levels 
 * block egress ICMP Parameter Problem error messages 
 * block egress ICMP Protocol Unreachable error messages 
 * block egress ICMP Fragment Reassembly Time Exceeded error messages   
 * filter ICMP request traffic from external address, unless explicitly - 
   defined for some host  
 * active network monitoring


On  a   side note,   one  of  the  better   open-source network  intrusion
detection systems   is a   project known   as SNORT.   Not only  does this
program detect  traffic  but  it performs   a real-time  analysis,  whilst
having a plethora of various alert capabilities. This Swiss army knife for
the network can be found on www.snort.org.

Opposing   this  is   the  ever-debatable   technique  'security   through
obscurity'    approach.   Instead   of   filtering    the  above    packet
transactions, why   not return   a positive   response to   any and  every
malformed packet block that is sent?

The repercussions   would enable   the network   to disguise   itself as a
much  larger  topology  if  it  were  to  send  any  response back  whilst
masking each  hosts true  identity. The  router or  firewall is capable of
handling  such  a  scenario  and  in  effect  one  stand-alone  host on  a
network  could  return  a  successful  response  to  an  entire  block  of
addresses therefore  obscuring the  actual results  of host detection. The
attacker  would be  left  with useless  misinformation  about the  network
topology and  thus the host  mapping process would  be utterly  pointless,
whilst maintaining the integrity of the local network.


-- [ Comments ] --

Advanced host detection techniques exist  and will be on the  increase  in
the near future. Protecting against unwanted and malformed  traffic at its
earliest stages will  stop inbound host detection requests  and ultimately
protect  your  network for  the  future.  Is your  network prepared?



Article: dethy@synnergy.net (c) 2001 Synnergy Networks [ www.synnergy.net ]