Nmap Announce mailing list archives

RE: nmap stealth FIN scan not detected by FW-1 V4.0?


From: BIDOU Renaud <Renaud_BIDOU () arca-network com>
Date: Thu, 27 May 1999 17:49:45 +0200


I performed the following tests on a FW1 4.0 SP2 over NT4 SP4 :

1) -sF scan through an accept security policy

* Results = OK
* Log = OK

2) -sF scan against a drop security policy

* Results = False (all open)
* Log = OK

3) -sF scan against a drop security policy

* Results = False x False (all open)
* Log = No

Here are my 2 cents :

Test 2 is OK as a "drop" action means no packet is returned to the
scanning host. Such a behavior is the condition of determining wether
the port is open or not.
Then NMap sees all scanned ports as opened

Test 3 shows it looks like a misbehavior from FireWall-1 as a "reject"
action should mean a RST packet is sent to the scanning host, meaning
the port is closed.
The fact that all ports are seen as opened means the "RST" packet is not
sent by FireWall-1.

IMHO it looks like if the packet is not very well handled by FireWall-1.
May be the 0 TCP window size...
Remember fragmented UDP packets DOS attacks : blocked but not logged

Renaud BIDOU

-------------------------------------------------------------------

platform:
FireWall-1 V4.0 Build 4037 VPN+DES, Solaris 2.6
nmap V2.12, Linux kernel 2.0.34


Today I did some nmap Stealth FIN scans (nmap -sF) against FireWall-1 
V4.0 protected systems. The FIN scan uses a bare surprise FIN packet 
as the probe.
foo@bar:/tmp > nmap -sF -P0 -p1-100 193.189.XXX.YYY

I was not able to get any logging from the firewall software
when sending these probes to protected systems. Neither directly 
with 'fw log' nor in the exported logfile generated with 'fw
logexport' I found any clue.
The FIN packets are handled by the FW software correctly according the
rule set, so the systems behind the firewall should be secure.
Nevertheless, an intruder could scan protected networks without the
risk to become detected.

What went wrong? Am I missing something or does FW-1 V4.0 really not
log surprise FIN packets?
I would rather prefer the idea that I'm wrong ;-)

Olaf
-- 
Olaf Selke, olaf.selke () mediaways net, voice +49 5241 80-7069


Current thread: