        ĳ
                                +-+-+-+-+-+-+-+-+
         ۲|O|u|t|b|r|e|a|k|𰰰
                                +-+-+-+-+-+-+-+-+
                            Issue #6 - Page 15 of 16
        ĳ



######################################################################
##   firewall detection, interrogation and penetration. -dropcode   ##
######################################################################

intro.

on  todays  internet  its rare to find a system that isn't behind some
type  of firewall. be it a software based application gateway, a hard-
ware  based  packet filtering or logging gateway, or some type of acd,
firewalls are everywhere.

this  text  will  cover  various techniques to detect firewalls on the
target  network, remotely determine the firewalls rulesets and map out
the internal network through the firewall.

detection.

the  detection  of  a  firewall on a target network is generally quite
simple.  as  the  function  of a firewall is to prohibit certain types
of data from passing beyond itself and into the internal network, they
can  easily  be  discovered  by  monitoring  an orchestrated data flow
between you and a target system.

detection with traceroute.

traceroute  is  a  network  administration  tool  used  to map a route
between you and a destination box. by default it launches a UDP packet
with  a  low  TTL,  or  time  to  live, flag set in the IP header. the
objective  is to force an ICMP TIME_EXCEEDED response for every system
on  the  route.  for instance, we start by sending a UDP packet to our
target  host  with  a  TTL of 1, it will reach the first system on the
route and timeout there. that first system will discard the packet and
send  an  ICMP  TIME_EXCEEDED  packet  back  to  you. you'll then send
another  UDP  packet,  but this time the TTL will be set to 2. it will
terminate  on the second system and we'll recieve a TIME_EXCEEDED from
them.  so  on,  et  cetera,  ad nauseum. thats the general idea, to be
technical  the  standard  with traceroute is to send three probes with
the  same  TTL  before  the incrementation. also, every packet is sent
to  one  port higher then the preceeding packet. so, not only does the
TTL increment, but the port does as well.

now,  that  probably  seemed  like i was getting way off track, but as
you'll soon see its all relevant.

--
 bash-2.05a$ traceroute 0.0.0.8
 traceroute to 0.0.0.8 (0.0.0.8), 64 hops max, 40 byte packets
  1  0.0.0.2 (0.0.0.2)  0.630 ms  0.470 ms  0.413 ms
  2  0.0.0.4 (0.0.0.4)  1.599 ms  1.505 ms  1.809 ms
  3  0.0.0.6 (0.0.0.6)  1.759 ms  1.714 ms  2.847 ms
  4  * * *
--

for  some  reason,  the  machine  on  hop  4 failed to return an ICMP 
TIME_EXCEEDED.  theres  a  good  chance  that  this box is a firewall
filtering  incoming  UDP  (or  outgoing ICMP?). in either case, we've 
probably found a firewall :).

for  windows  users,  the  microsoft  implementation  of  traceroute, 
tracert uses ICMP by default.

of  course, traceroute/tracert isn't the only way to find a firewall. 
there  are many ways, often if an ICMP ECHO_REQUEST (ping) returns no 
ECHO_REPLY  its  because  theres  a  firewall  filtering  icmp (note: 
this  doesn't  apply  to  users  on dalnet *smirk*). there are plenty
more  tools  that  can  be used in firewall detection, but i'll leave 
that to your imagination.

interrogation.

interrogation  is the process of remotely determining the rulebase of 
a firewall systematically.

in  the  previous  section  we  have  already  done  a  bit  of basic 
interrogation.  we  know  that  the  firewall at hop 4 filters either 
incoming  UDP  or  outgoing  ICMP  on  at least the port we connected
to,  which  is  unknown  to us. using traceroutes -p attribute we can
specify  a  port  to start at and determine if any ports allow UDP. a
good place to start looking is DNS (port 53) since some DNS transfers
require  UDP  theres  a good chance it will allow UDP packets through 
this port. 

since  traceroute  increments the destination port for each packet we 
need  to  do  a bit of math. there are three packets for each hop and 
4  hops  till  we reach the firewall. so the port to start at will be 
53 - (4 * 3) - 1 giving us 40.

--
 bash-2.05a$ traceroute -p40 0.0.0.8
 traceroute to 0.0.0.8 (0.0.0.8), 64 hops max, 40 byte packets
  1  0.0.0.2 (0.0.0.2)  0.630 ms  0.470 ms  0.413 ms
  2  0.0.0.4 (0.0.0.4)  1.599 ms  1.505 ms  1.809 ms
  3  0.0.0.6 (0.0.0.6)  1.759 ms  1.714 ms  2.847 ms
  4  0.0.0.8 (0.0.0.8)  1.831 ms  1.918 ms  1.303 ms
--

we  now  know that the firewall allows UDP to pass through port 53 :)

hping  and  firewalk  are  two  of  the  most  important tools needed
for  successful  firewall  interogation.  firewalk  is  a console app 
used  to  check for open ports on a firewall. it sends data to a live
system behind the firewall on various ports to see what is allowed.

hping  is  a tool for pinging remote systems, but it has alot of nice 
attributes  for  playing  with  different  parts  of  the  actual tcp
packets.  sometimes  you can change a few of the features of a packet
and  a  firewall will let it through. hping also gives you the option
of fragmenting packets. this means that the packet will be split into
more  than  one  packet.  most  firewalls  nowadays have handlers for 
fragmentation,  but  you  may  find  one  that  doesn't recognize the 
packets and lets them through.

now nmap. as important as firewalk and hping are, nmap owns them both 
hands  down.  it  is  the single most important tool in your armoury. 
ports   scanned   with  nmap  will  output  filtered  when  there  is 
no  SYN/ACK or RST/ACK recieved from the destination. if nmap outputs
unfiltered  it  means  we recieved an RST/ACK which means our packets
are  passing  through  the firewall but the destination machine isn't 
listening on the destination port.

penetration.

using the methods above, it is possible to map out the network behind
a firewall. similar to ping sweeping, only every packet sent is care-
fully formatted so to not be blocked by the firewall.

--

well  thats about all for this text. if anyone has any questions, try 
me  at  uberego@hotmail.com.  regular  greets  to my bestest phrends:
   kleptic, ramb0x, gr3p, jenny, lexi, oj, smiley, dirv, adeamis.
   and  to  my newest phrends: |arry, turb. and anyone i forgot.
                      
                         sav, i love you. 

ps. maybe  someday  i'll  be  as hardcore as failure. *throws fone at 
    wall* till then, i'll keep practicing.

-dropcode