On Wed, 2013-11-06 at 14:00 +0100, Jeroen Massar wrote:
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén lars.nooden@gmail.com allegedly wrote:
On 11/06/2013 01:26 PM, mick wrote:
I disagree. Dropping all traffic other than that which is explicitly required is IMHO a better practice. (And how do you know in advance which ports get attacked?)
Using reject instead of drop simplifies troubleshooting.
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
Drop tends to get in the way.
Again, I disagree. But I recognise that this can be a religious decision. My default policy is to drop rather than reject. I know that strict adherence to standards implies we should “REJECT” with a helpful ICMP error message.
Configure your host with DROP, do an nmap, then configure it with REJECT thus for Linux:
IPv4: -j REJECT --reject-with icmp-port-unreachable" IPv6: -j REJECT --reject-with icmp6-port-unreachable"
Now repeat that nmap; indeed, for the DROP it is shown that these ports are filtered, for REJECT the ports are just 'closed'.
Hence, the adversary did not learn anything in the REJECT case (services apparently are not there), but in the DROP case they learned that you have a firewall configured and that those services are likely there...
Hence, not only is reject good for the user (as they do not time out connecting to the port), but it is also good against adversaries as they do not learn anything.
I'd agree with the above logic if weren't 4 the f4c1 that OS fingerprinting is done though the analysis of the packets your system sends in replying to scans - the way the kernel generates packet headers tells info on your system. So besides what others have said, I would also add that there is indeed a great difference of info your intruder can get from your system when it generates some kind of answer to random unpredictable requests when compared to no answer at all.
So I rather open only those ports to which I gave some love to and am willing to share, than just let my beloved machines to their own fate just to not let the =user= waiting for some seconds. I think the user can wait or close connection if impatient. If his interest on my machine was for just nano secs, I guess we can sidestep this whole gentleman's reply to a connection attempt.
Also, I do not get this troubleshooting hassle. If you r the sysadmin u can write in time iptables rules, port scan, packet sniff and single out easily when it is network related or server software related.