tor-relays February 2011

tor-relays@lists.torproject.org

17 participants
7 discussions

Network Scan through Tor Exit Node (Port 80)
by Bianco Veigel 09 Mar '11

09 Mar '11

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? Thanks in advance, Bianco Veigel ----- attachment ----- ########################################################################## # Netscan detected from host 188.40.98.54 # ########################################################################## time protocol src_ip src_port dest_ip dest_port --------------------------------------------------------------------------- Fri Feb 25 06:53:15 2011 TCP 188.40.98.54 45237 => 138.160.29.194 20019 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 27681 => 94.207.140.89 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 6869 => 94.207.140.93 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 33258 => 94.207.140.94 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 53464 => 94.207.140.95 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 31041 => 94.207.140.96 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 6299 => 94.207.140.97 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 40964 => 94.207.140.98 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 8703 => 94.207.140.99 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 56759 => 94.207.140.187 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 26247 => 94.207.140.227 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 26247 => 94.207.140.227 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 27847 => 94.207.140.228 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 27847 => 94.207.140.228 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 1219 => 94.207.140.229 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 1219 => 94.207.140.229 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 38929 => 94.207.140.230 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 38929 => 94.207.140.230 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 62958 => 94.207.140.235 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 46469 => 94.207.140.236 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 2704 => 94.207.140.237 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 17272 => 94.207.141.12 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 17272 => 94.207.141.12 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 32482 => 94.207.141.13 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 32482 => 94.207.141.13 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 55860 => 94.207.141.14 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 55860 => 94.207.141.14 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 43390 => 94.207.141.15 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 43390 => 94.207.141.15 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 31712 => 94.207.141.16 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 31712 => 94.207.141.16 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 29316 => 94.207.141.17 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 29316 => 94.207.141.17 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 5286 => 94.207.141.18 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 5286 => 94.207.141.18 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 45139 => 94.207.141.19 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 45139 => 94.207.141.19 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 25311 => 94.207.141.20 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 25311 => 94.207.141.20 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 3675 => 94.207.141.21 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 3675 => 94.207.141.21 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 51753 => 94.207.141.22 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 51753 => 94.207.141.22 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 8993 => 94.207.141.23 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 8993 => 94.207.141.23 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 48305 => 94.207.141.24 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 25717 => 94.207.141.25 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 15142 => 94.207.141.26 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 24618 => 94.207.141.27 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 43060 => 94.207.141.28 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 45003 => 94.207.141.45 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 18691 => 94.207.141.48 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 48452 => 94.207.141.60 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 48452 => 94.207.141.60 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 37237 => 94.207.141.61 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 37237 => 94.207.141.61 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 39153 => 94.207.141.62 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 10678 => 94.207.141.63 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 23127 => 94.207.141.64 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 10755 => 94.207.141.65 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 13206 => 94.207.141.66 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 32657 => 94.207.141.67 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 1909 => 94.207.141.68 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 3475 => 94.207.141.69 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 3475 => 94.207.141.69 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 1810 => 94.207.141.70 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 1810 => 94.207.141.70 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 52358 => 94.207.141.71 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 3828 => 94.207.141.72 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 46151 => 94.207.141.73 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 17930 => 94.207.141.74 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 4025 => 94.207.141.103 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 4025 => 94.207.141.103 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 48216 => 94.207.141.104 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 48216 => 94.207.141.104 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 61033 => 94.207.141.105 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 61033 => 94.207.141.105 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 35460 => 94.207.141.106 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 35460 => 94.207.141.106 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 34686 => 94.207.141.107 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 34686 => 94.207.141.107 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 8517 => 94.207.141.108 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 8517 => 94.207.141.108 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 34989 => 94.207.141.109 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 16795 => 94.207.141.110 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 54679 => 94.207.141.111 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 36103 => 94.207.141.112 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 59119 => 94.207.141.113 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 29831 => 94.207.141.114 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 24490 => 94.207.141.115 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 8880 => 94.207.141.116 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 43624 => 94.207.141.117 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 31266 => 94.207.141.118 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 33438 => 94.207.141.119 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 43359 => 94.207.141.120 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 8168 => 94.207.141.121 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 36716 => 94.207.141.122 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 5648 => 94.207.141.123 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 57277 => 94.207.141.124 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 20586 => 94.207.141.134 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 20586 => 94.207.141.134 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 29953 => 94.207.141.135 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 29953 => 94.207.141.135 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 10770 => 94.207.141.136 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 10770 => 94.207.141.136 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 4466 => 94.207.141.137 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 4466 => 94.207.141.137 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 27801 => 94.207.141.138 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 27801 => 94.207.141.138 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 14288 => 94.207.141.139 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 14288 => 94.207.141.139 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 11846 => 94.207.141.140 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 11846 => 94.207.141.140 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 42636 => 94.207.141.141 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 42636 => 94.207.141.141 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 7837 => 94.207.141.142 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 7837 => 94.207.141.142 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 62271 => 94.207.141.143 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 62271 => 94.207.141.143 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 6908 => 94.207.141.144 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 6908 => 94.207.141.144 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 29951 => 94.207.141.145 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 29951 => 94.207.141.145 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 10582 => 94.207.141.146 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 10582 => 94.207.141.146 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 61463 => 94.207.141.147 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 61463 => 94.207.141.147 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 32072 => 94.207.141.148 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 32072 => 94.207.141.148 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 31807 => 94.207.141.149 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 41404 => 94.207.141.152 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 6669 => 94.207.141.153 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 24449 => 94.207.141.172 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 24449 => 94.207.141.172 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 19439 => 94.207.141.173 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 19439 => 94.207.141.173 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 55637 => 94.207.141.174 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 55637 => 94.207.141.174 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 22382 => 94.207.141.175 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 25961 => 94.207.141.176 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 49493 => 94.207.141.177 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 10996 => 94.207.141.178 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 52247 => 94.207.141.179 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 26122 => 94.207.141.180 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 44654 => 94.207.141.181 80

14 27

Re: [tor-relays] Advice for high throughput Tor node
by Mike Perry 02 Mar '11

02 Mar '11

This discussion is better suited for tor-relays(a)torproject.org. Also, for reference, here is the previous tor-relays thread on the technical aspects of this topic: http://archives.seul.org/or/relays/Aug-2010/msg00034.html And also the social side: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment We really need to work on condensing that tor-relays thread into a single document like the blog post. We've still got a lot of mystery and voodoo to unravel in terms of utilizing all spare Tor capcity, though. Thus spake Mitar (mmitar(a)gmail.com): > Hi! > > We are planning a high throughput Tor node, we are hoping for 1 Gbit/s > node. But as I read there are some issues attaining that. So I would > like some suggestions what should we use for hardware and > configuration to attain it. So CPU, ethernet card, etc. As I > understood it is necessary to run multiple Tor instances, but that > then ethernet card's IRQ affinity is still problematic? Would it be > better to have multiple ethernet cards? How much CPU is needed for 1 > Gbit/s throughput? RAM? > > And it is probably also necessary to have multiple IPs to be able to > have more than 65k connections? > > The problem is that we will probably not be able to experiment much, > what we will buy we will have. So I am hoping to get it right. > > We are targeting a fully open exit node policy so some advice on how > to arrange things with ISP would also be good. We have good experience > with one local ISP, but not on this scale. So probably it would be > good to request a SWIP and abuse handle to our e-mail? Anything else? > Is there any software developed which would handle automatic abuse > e-mails with automatic replies? > > I am sorry if all this is already somewhere written. ;-) > > (And all this is still just in a planning stage, we will have to see > if the budget will support it.) > > > Mitar > _______________________________________________ > tor-talk mailing list > tor-talk(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Mike Perry Mad Computer Scientist fscked.org evil labs

3 6

Blocked SYN floods?
by Michael Millspaugh 26 Feb '11

26 Feb '11

I've noticed that pretty regularly my firewall is blocking what it's calling SYN-FLOODS, 50 at a time, originating from my tor relay: 02-26-2011 09:09:41 Daemon.Debug ROUTER kernel: [2011 Feb 26 09:09:33] FVS338 SYN-FLOOD IN=LAN OUT=WAN SRC=192.168.1.5(FALCON) DST=85.78.242.156(unresolved) PROTO=TCP SPT=63848 DPT=23 02-26-2011 09:09:41 Daemon.Debug ROUTER kernel: [2011 Feb 26 09:09:33] FVS338 SYN-FLOOD IN=LAN OUT=WAN SRC=192.168.1.5(FALCON) DST=31.92.154.101(unresolved) PROTO=TCP SPT=63820 DPT=443 02-26-2011 09:09:41 Daemon.Debug ROUTER kernel: [2011 Feb 26 09:09:33] FVS338 SYN-FLOOD IN=LAN OUT=WAN SRC=192.168.1.5(FALCON) DST=188.88.159.200(unresolved) PROTO=TCP SPT=63839 DPT=5060 Most of them are on port 23 or 443, some are on 5060 and the rest are on random ports. I have read that port 23 is for MIRC, and that "syn-floods" are part of the way it operates - could that be causing these errors? Is it removing some functionality of mirc that is important to it's operation? I'd feel better knowing my firewall is stopping these syn-floods before my ISP can see them, and knowing that the relay is still working optimally. -Mike -- TERMS OF USE. By reading this e-mail, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, terms-of-use, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

1 0

Network Scan through Tor Exit Node (Port 80)
by Bianco Veigel 25 Feb '11

25 Feb '11

3 2

Lawsuit threat over (unlikely?) SYN flood
by Formless Networking 25 Feb '11

25 Feb '11

Just as a heads up, I got a curt, vague lawsuit threat the other day out of the blue. The guy claimed my node IP took down his (unmentioned) e-commerce sites for some unspecified period of time through a SYN flood. The sites that I could find associated with his email address appeared still up and functional. Since SYN floods can be spoofed, and since Tor nodes don't really have the resource amplification that typically makes them effective, I'm assuming it's probably just someone who forgot to take their meds for a while and/or who is just making things up to try to chill our tor node off line. Just in case, here is what I sent in response. If anyone else hears from this guy, feel free to copy and paste. ---------------------------- It seems very unlikely that what you pasted here is due to our Tor router (unless it has been compromised?). Our node is not capable of transmitting SYN packets on behalf of users fast enough to actually do damage. It is rather expensive for a tor client to generate this type of traffic, and a couple forms of protection mechanisms are built in to the tor router flow control that slow this down. We would be very surprised if this attack actually came through our node, and actually brought down any of your services. Unlike more direct attacks on your server at the application layer, SYN floods are possible to spoof. This packet could actually be coming from anywhere... However, in either case, this attack should be simple to block. You can prevent the entire Tor network (not just our router) from sending you traffic by using this exported IP list to generate firewall rules to drop SYN packets: https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.2.3.4&port=80 If this is in fact a SYN flood attack, they may just switch spoofed source IPs on you, though, so an IP block is probably not what you want. There are plenty of documents online that describe server parameters to help reduce the impact of this attack on your services, depending on your server OS. We recommend looking into them to better protect yourself and your customers. Thanks

3 2

setting up a bridge - troubleshooting
by Kathryn Cramer 22 Feb '11

22 Feb '11

I am trying to set up a Bridge on a Mac running OSX 10.5.8 and using a Trendnet Wireless Broadband router. UPnP is enabled. Clicking Test on the Vidalia Settings menu yields the message "Failed to add a port mapping." There is a menu on the router software entitled Gaming which is the only place I can find that allows setting of ports. I tried using that to configure the port forwarding needed by the router, but that didn't work. (It looks like this: http://screenshots.portforward.com/TRENDnet/TEW-631BRP/Gaming.htm ) It is described by the manufacturer as follows: "This option is used to open multiple ports or a range of ports in your router and redirect data through those ports to a single PC on your network. This feature allows you to enter ports in various formats including, Port Ranges (100-150), Individual Ports (80, 68, 888), or Mixed (1020-5000, 689)." Ideas?

4 5

New relay - hibernation issue?
by Bill 17 Feb '11

17 Feb '11

I've had a new non-exit relay ("Tor4Democracy") running for about six days, and today based on my daily usage limits: AccountingMax 880803840 AccountingStart day 21:00 it went into hibernation. I'm not sure if this is proper behaviour, but it didn't seem publish a descriptor during hibernation. When it woke up, it reset uptime = 0 and started publishing again. I've scoured the FAQs but haven't had any luck. Following the relay security suggestions, I haven't been logging. Before I start logging to see if it repeats, is there something I'm missing / misconfiguring? Thanks in advance, Bill

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays February 2011