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

On Fri, 25 Feb 2011 18:28:24 -0500 cmeclax-sazri <cmeclax-sazri@ixazon.dynip.com> wrote:
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.
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 * **********************************************************************
participants (1)
-
Scott Bennett