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.noo...@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. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
