Re: Dropping syn+fin replies, but not really?

Hi Eirik,

Perform the nmap scan and look at the tcpdump output to see how your
firewall and/or server react.

nmap command:
nmap -PN -sT --scanflags SYNFIN -p<port>
where <port> was either 80 (open) or 8585 (closed).

tcpdump command on firewall (which NATs to internal IPs):
tcpdump -i <interface> -p -vvv host and \(port 80 or port 8585\)
where <interface> was the publicly facing interface on the firewall.

Results for port 80:
IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP (6), length: 64) > S, cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2747936488 0>
IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP (6), length: 60) > S, cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 2946365534 2747936488>

Results for port 8585:
IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP (6), length: 64) > S, cksum 0xf765 (correct), 1324215952:1324215952(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0>
IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP (6), length: 40) > R, cksum 0x52ef (correct), 0:0(0) ack 1324215953 win 0

I can't tell what's going on here, except I wouldn't have expected a reply at all to the second one at least, and maybe not even the first. However, I don't have enough experience to tell if nmap is doing the "right thing" here at all.

First of all, this is not a scan with both the SYN and FIN flags set. This can be seen from the tcpdump output only showing the 'S' flag. You're using -sT, which makes nmap use connect(), and thus the regular SYN, SYN/ACK, ACK 3-way-handshake. For a SYN/FIN scan, you'll need root access. I tested this locally without supplying further TCP scan options to nmap. Could you retest and make sure you see 'SF' as flags in tcpdump?

Secondly, it would be useful if you'd explain the following: is your firewall NATting port 8585 also, or is traffic sent to that port handled by the TCP/IP stack of the firewall itself? Furthermore, it appears the firewall is not actually filtering traffic to port 8585..

The strictest firewall configuration would be to have everything filtered except the ports you actually use. Those ports are either NATted to the back-end system or handled by the firewall itself (in case you want that functionality). From a security perspective, simply dropping incoming traffic is better than sending back RST's. In pf this is the default.


freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: keeping ports open
    ... If a port is open, it means that 1) a software or service is running on your ... and 2) you're not using a firewall or your firewall isn't ... Use firewall software and hardware and antivirus software that is ... Follow the instructions for hardening Windows and IIS at ...
  • Re: How to Maintain an IIS Server?
    ... > server running on a Windows 2000 server. ... before a firewall and antivirus have been installed]. ... open ports; however, this will not identify which program is using the port. ...
  • Re: CEICW fails at firewall config
    ... ISA Server prevents connection to a remote desktop when you connect through ... Remote Web Workplace on a Windows Small Business Server 2003-based computer ... Acceleration Server as a firewall. ... connection uses TCP port 4125. ...
  • Re: How to Maintain an IIS Server?
    ... >> server running on a Windows 2000 server. ... > before a firewall and antivirus have been installed]. ... > program or executable using that port. ...
  • Re: Is secedit.exe left by a hacker?
    ... > tested on port 445. ... > I have a Linksys router that I use as a firewall to my ... Secedit.exe is the name of a legitimate Windows file, ... investigate the files on your computer - antivirus with the latest updates ...