###################################################################### ## 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 two 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