3

I know how REJECT and DROP chain works. But, as I read here REJECT vs DROP when using iptables, user Dagelf said that the server still replies with TCP SYN/ACK.

Does the scanner knows that a packet is dropped when the firewall is using DROP?

Community
  • 1
machineaddict
  • 159
  • 2
  • 3
  • 12

1 Answers1

5

If you reject the packet, you reply to the incoming SYN with a RST packet, so the scanner knows the port is closed (via reject, or because no service is running on that port).

If you drop the packets, the scanner waits, and after some time (timeout), it assumes the packets have been dropped (although, they may be lost in transit, or the machine on the far end could be down, or anything else could happen, that would trigger a no-reply scenario).

mulaz
  • 10,472
  • 1
  • 30
  • 37
  • Basically, if there is no open port, the scanner would not make a difference between a server that is offline and a server that is using DROP on all ports? – machineaddict Apr 16 '14 at 11:33
  • Exactly (if all ports were "closed" by DROPping the packets). That's why some scanners (eg. nmap), first do a ping test (if not disabled with -P0) – mulaz Apr 16 '14 at 11:34
  • this is inconsistent with http://serverfault.com/a/564774/87556 – andresp Feb 12 '15 at 13:12
  • and this: http://unix.stackexchange.com/a/109462 – andresp Feb 12 '15 at 13:14
  • @andresp it is consistent. – sjas Jul 24 '15 at 09:27
  • @sjas it's not. "Even when the rule says "DROP" the system will still reply to the incoming packet with a TCP SYN/ACK as if it was open." -> ~ "no-reply scenario". The inconsistency is quite clear actually. I'm not saying this is incorrect though. – andresp Jul 24 '15 at 09:43