[tor-relays] Network Scan through Tor Exit Node (Port 80)

[Scott Bennett]

     On Fri, 25 Feb 2011 18:28:24 -0500 cmeclax-sazri
<cmeclax-sazri at ixazon.dynip.com> wrote:
>On Friday 25 February 2011 11:45:04 Bianco Veigel wrote:
>> Today I got the second abuse mail within two weeks from my hosting
>> provider. They forced me to take down the exit node, otherwise they will
>> shutdown my server.
>>
>> How could I detect such a scan and take counter measures to prevent a
>> network scan through tor? I've thougt about Snort, but I've never used
>> it before. The exit node is running in a Xen-vm, behind a pfSense firewall.
>>
>> I've attached the report from the abuse mail. Does anyone have an idea,
>> what steps should/could be taken?
>
>It may be possible to detect a scan by looking for RST packets coming back 
>from computers that have the port closed. I saw something about that on 
>snort.org, I wouldn't trust Snort to do the right thing in the case of 
>someone portscanning through Tor. I suggest closing the circuit, and only Tor 

     Not only that, but some systems offer the option of not returning the
RST packets.  For example, on my system (FreeBSD 7.4-STABLE), I have a line
in /etc/sysctl.conf,

net.inet.tcp.blackhole=2

which takes effect during system startup.  Its effect is to cause the kernel
to discard and otherwise ignore ALL inbound TCP packets for closed TCP ports.
Because the scanner receives no RST, it will likely be delayed until the
timeout occurs for the expected ACK/RST that will never arrive.
     I also have two applicable rules for my packet filter (pf):

block drop in log on bge0 proto tcp from any to bge0 flags S/S
block drop in log on bge0 proto udp from any to bge0

where bge0 is my Internet-facing network interface.  The former drops without
returning an RST any SYN that arrives for a closed TCP port.  This happens
*before* the SYN can encounter the kernel blackhole code, so that I can have
a log entry for the attempt.  The latter does the same for any unexpected
inbound UDP packets.  (pf keeps the equivalent of state information for UDP,
too, so that UDP responses to requests from my system (e.g., DNS queries) are
recognized and allowed in without being subjected to the rule shown above.)
     I add the addresses logged by the rules above to my file of blocked
addresses and address ranges.  At present, the only open TCP ports I have are
my relay's ORPort and DirPort, so having one's IP address in my "blocked" file
can only cause grief to people attempting to connect to/probe my node directly
from their tor clients.  However, in the event that I might ever offer other
services of any kind, all of those creeps will be denied access to those
services as well.  (N.B. that I have other pf rules that allow IP addresses of
relays in the latest cached-consensus file on my node to connect to both of
tor's ports.  The cached-consensus file is converted every thirty minutes to
a "pass" file for just those ports, so no tor user whose client happens to
choose a route through a relay in my "block" file will be stopped from
building and using a circuit through both the offending node and my node.)
My "block" file is currently 10,177 lines long, each line bearing one IP
address or address/mask range.

>knows what the circuit is, so if an exit node notices several connection 
>attempts in a row on the same circuit fail, it could close the circuit 
>because it looks like a portscan.
>
     However, by that time, the target may also have noticed the same series
of attempts and will eventually complain to the OP's ISP. :-(  Many of the
scanning attempts I've seen in my log have involved just a single try on each
of a handful of ports.  Sometimes they repeat the sequence a few minutes later,
a trick that would likely evade the tactic you propose.
     BTW, something I've noticed moderately frequently in recent weeks is the
arrival of unsolicited UDP packets for the UDP port number that matches my
(TCP) ORPort number.  This usually involves only a single UDP packet so
addressed from any given source address.  This has me rather mystified
regarding what it might be intended to accomplish.  If anyone has an idea
what it might be about, please let me know.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************