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

[Jeroen Massar]

On 2013-11-11 19:23, Luther Blissett wrote:
> 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

I was not talking about OS fingerprinting; completely different beast.
While nmap can do that, in this case nmap is just used as an example for
service discovery.

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

As a ICMP Port Unreachable is a standard response, there is nothing the
attacker will learn 'more' from this. It WILL learn when you DROP that
you chose to block that specific port though and thus that there is
likely something you are hiding there.

If the attacker wants to know your OS it will learn that from the
services and packets that you will allow in (and allow answers from).

Though if you are paranoid about your OS then you are doing something
wrong. Best solution: let a friend pentest your host without telling
them what is and what is not there.

(hence why the pentesting industry is a happy and well paid place)

> 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 you have 1 user that is fine, if you have a thousand or several
hundred thousands of users and they start calling you up, you will be
changing that ;)

Please note again that DROP/REJECT choice is a personal one. Each has
advantages and disadvantages.

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

TCP connections do not time out that quickly.

Put a DROP on a port and then try to connect to it using your favorite
browser or telnet client.

A scanner (nmap et all) will not bother waiting around, real clients
will. As such you are hurting real clients, not the scanners; and again
you are just telling the scanner you are hiding something.

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

While *you* will be able to figure it out, the user's perception will be
quite different.

They connect, it times out. As such, "The network is broken". And that
is what they will call you with (and it can indeed be anything).

While if they get 'connection refused', it is a much more clear message.

PS: Try doing a packet sniff on a link with thousands of connections and
where your user cannot tell you what source IP they have; next to the
fact that they might just be using the wrong destination host... ;)

Greets,
 Jeroen