[tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[Luther Blissett]

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 at 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.