On Aug 06, 2006, Pascal Hambourg wrote: > Hello, > > former03 | Baltasar Cevc a écrit : > > > >Just for the record: there is a side effect the dropping behaviour. > >While not exposing whether the port is open or closed, show some > >scanners will conclude that there is a filter. If you want the scanner > >to think the ports are closed, you could issue send back a port > >unreachable packet (-j REJECT --reject-with icmp-port-unreachable) > > This works only against UDP scans or basic TCP scans using the "connect" > method. A more advanced TCP scan will detect a packet filter when > receiving an ICMP port unreachable instead of a TCP RST which is the > normal reply for a closed TCP port. A TCP port is properly firewalled > using "-j REJECT --reject-with tcp-reset". You may not want to generate RST packets at all because a clever attacker can examine the specific manner in which the RST packets were constructed to differentiate the response software. For example, the Netfilter REJECT target always hard-codes the TTL value at 255, sets the TCP Window size to zero, and only sends one RST packet per rule match. In contrast, the Snort flexreponse2 detection plugin examines the TTL value of the matching packet and chooses a near multiple of 64, sets the Window size to the same value in the matching packet, and typically sends a minimum of five RST packets... very different. If you just drop the packet, then the attacker only knows that there is _some_ inline device that is getting in the way. In response to the original poster, if you are interested in detecting and preventing port scans via Netfilter, you might like psad: http://www.cipherdyne.org/psad/ -- Michael Rash http://www.cipherdyne.org/ Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
