From: Javier Fernandez-Sanguino (jfernandez@germinus.com)
Date: Thu Jun 08 2006 - 04:12:26 EDT
James Fryman dijo:
> You could spoof your packets to match the IP's of the internal network,
> but you cannot expect to get them back... the best you could hope for is
> some sort of internal DoS attack, or an exploit with a payload that
> would return to your external address... assuming that the firewall
> allows RFC1918 address inside.
If the firewall allows incoming RFC1918 addressing you could guess that
by sending packets and checking if there are giveways that tell you
(from the outside) that the packet was indeed received in the remote
host (i.e. IPID).
It would work like this:
0.- You test IPID generation for the RealIP of the web server: 'nmap -v
-sT -p 80 RealIP -O'. Let's assume that you get an Incremental IPID
Sequence Generation value
1.- You make a legitimate connection to the RealIP of the web server and
note down the value of the ID field of the IP header for the packets you
receive.
2.- You send a SYN packet with IPsrc=192.168.0.10 IPdst=RealIP of the
webserver, port 80
3.- The firewall checks its rulebase and says 'ok' as it's directed to
port 80
4.- The webserver (at, say, NAT IP 192.168.0.5) receives the SYN packet,
opens up a socked (half-established) and sends the SYN,ACK to
192.168.0.10 (this packet does not leave the firewall, you will not see it)
5.- If there is a 192.168.0.10 system it will send a RST (as it receives
a SYN,ACK for a connection it did not try to establish) if there is no
system there the SYN,ACK packet will go nowhere
6.- You make another legitimate connection to the RealIP and note down
the ID field.
If you time the test properly you could compare the values retrieved 0)
and 5) and see how much has the ID incremented. If it has, then the
system *is* receiving the SYN packet and you can assume that the
rulebase is flawed.
If the rulebase does proper ingress filtering (blocks RF1918 packets)
then steps 3 to 5 will not take place and you will see an increment, but
not as big.
Now, some caveats:
- your ISP (or wherever you do the test from) should *not* have egress
filtering (many ISPs block *outbound* RFC1918 packets)
- if the web server gets a lot of traffic you need to generate many
packets in the step 2 (hping is your friend) so you can properly compare
the IP ID increment, otherwise you might not be sure if the increment is
due to *your* packets or to the average traffic the system is receiving
(that's why it's best to do this test in low traffic hours)
- works only with OS that have "increment" IPID generation, which is not
always true (but it is common)
When testing firewall rule bases I find that it's more efficient
(time-wise) and produces better results to:
a) put a device that generates trafic in one side of the network (the
'Internet') and another that sniffs it in the other side (the DMZ), send
traffic from one side to the other, check what goes through and you can
determine (from a black box perspective) what rulebase does the firewall
have
b) review the rulebase in the firewall itself (accessing the firewall
admin GUI)
c) (Additionally) you can review the OS system to see if there are
half-open connections
Both tests give you a good (and more complete) view of what is the
firewall really permitting through. You can use 'ftester' [1] for a) and
I believe it's use has been discussed in the list many times already [2]
Regards
Javier
[1] http://www.securityfocus.com/tools/3802
http://dev.inversepath.com/trac/ftester
[2] Search Google for:
ftester "pen.test" inurl:archive site:securityfocus.com
------------------------------------------------------------------------------
This List Sponsored by: Cenzic
Concerned about Web Application Security?
Why not go with the #1 solution - Cenzic, the only one to win the Analyst's
Choice Award from eWeek. As attacks through web applications continue to rise,
you need to proactively protect your applications from hackers. Cenzic has the
most comprehensive solutions to meet your application security penetration
testing and vulnerability management needs. You have an option to go with a
managed service (Cenzic ClickToSecure) or an enterprise software
(Cenzic Hailstorm). Download FREE whitepaper on how a managed service can
help you: http://www.cenzic.com/news_events/wpappsec.php
And, now for a limited time we can do a FREE audit for you to confirm your
results from other product. Contact us at request@cenzic.com for details.
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:03 EDT