Exit relay operators: a call for packets on port 8118
I am an exit relay operator in Honolulu that has posted to this list before, on the same subject. I am hoping that some other exit relay operators can sniff for packets to destination port 8118 (usually used for Privoxy) to confirm that they are seeing the same thing I am on all exit relays that I have set up in the last half year. Depending on your network configuration, you might have to instead record firewall logs for that port. Don’t worry, unless you have your Privoxy service open to the world, you won’t be intercepting or eavesdropping on any legitimate traffic. You should just be seeing SYN packets from a few hundred-strong net of Windows servers now hosted at Gorilla Servers, Ubiquity/Nobistech, and Limestone Networks, with a handful at Psychz. I am calling this malicious (?) net of Windows servers Rotpoi$on. I have more details in the most recent blog post at https://b.kentbackman.com Thanks for your help. - Kent
On 13-07-21 08:40 PM, rotpoison throngnet wrote:
I am an exit relay operator in Honolulu that has posted to this list before, on the same subject. I am hoping that some other exit relay operators can sniff for packets to destination port 8118 (usually used for Privoxy) to confirm that they are seeing the same thing I am on all exit relays that I have set up in the last half year. Depending on your network configuration, you might have to instead record firewall logs for that port. Don’t worry, unless you have your Privoxy service open to the world, you won’t be intercepting or eavesdropping on any legitimate traffic. You should just be seeing SYN packets from a few hundred-strong net of Windows servers now hosted at Gorilla Servers, Ubiquity/Nobistech, and Limestone Networks, with a handful at Psychz. I am calling this malicious (?) net of Windows servers Rotpoi$on.
I have more details in the most recent blog post at https://b.kentbackman.com
I am not running an exit at present, but i am curious. Shouldnt a SYN flood attack be handled automatically by the ISP? I don't think we can do anything on the node itself.
Hi Kent, I am getting 125 packets per second sustained incoming on port 8118 like you on my exit node. I noticed this last year but forgot about it because it was such low bandwidth. I count 2582 unique IPs in 20 minutes. I think you've found something significant. The obvious question is why since sending data in the clear is pretty worthless and it's going to come out of a tor exit node just like if they were using tor. I'm a security researcher and would be happy to help you learn more about these silly systems. You've already done most of the basic research though: who, what, and where. When I open port 8118 with netcat a few times I get this: GET http://ad.yieldmanager.com/st?ad_type=iframe&ad_size=300x250§ion=4211101&pub_url=${PUB_URL} HTTP/1.0 Accept: */* Referer: http://www.lotsoffree.com/index.php?option=com_content&view=article&id=84:fr... Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Host: ad.yieldmanager.com Connection: Keep-Alive GET http://ib.adnxs.com/ttj?id=1284883 HTTP/1.0 Accept: */* Referer: http://www.psxobs.com/privacy-policy Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Host: ib.adnxs.com Connection: Keep-Alive That looks like clickfraud to me. Perhaps someone wrote a quick script that downloads the list of tor exit nodes and sends clickfraud requests to 8118 and was too lazy to add tor. That would mean that the sites in the referrer are the attackers and the url on the first line is the ad service which is being defrauded. Of course there is the possibility of a joe job occuring, but we know that at least some of them are the bad actors. Whois on both referrers returns China. I'm surprised that the script doesn't remove servers from the list that have the port closed. It's a very inefficient script. Regards, Javantea -----Original Message----- Subject: [tor-relays] Exit relay operators: a call for packets on port 8118 From: rotpoison throngnet <rotpoison@gmail.com> To: tor-relays@lists.torproject.org Date: Sun, 21 Jul 2013 14:40:26 -1000 I am an exit relay operator in Honolulu that has posted to this list before, on the same subject. I am hoping that some other exit relay operators can sniff for packets to destination port 8118 (usually used for Privoxy) to confirm that they are seeing the same thing I am on all exit relays that I have set up in the last half year. Depending on your network configuration, you might have to instead record firewall logs for that port. Don’t worry, unless you have your Privoxy service open to the world, you won’t be intercepting or eavesdropping on any legitimate traffic. You should just be seeing SYN packets from a few hundred-strong net of Windows servers now hosted at Gorilla Servers, Ubiquity/Nobistech, and Limestone Networks, with a handful at Psychz. I am calling this malicious (?) net of Windows servers Rotpoi$on. I have more details in the most recent blog post at https://b.kentbackman.com Thanks for your help. - Kent _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
The CMU Tor exit is seeing about 66 packets/second worth of this (10000 packets, 1151 unique IPs in 149.5 seconds). I don't have time to dig any deeper right now, but on the theory that it's a botnet doing click fraud, I'll pass this along to our cybercrime people. zw
On Mon, 22 Jul 2013, Zack Weinberg wrote:
The CMU Tor exit is seeing about 66 packets/second worth of this (10000 packets, 1151 unique IPs in 149.5 seconds). I don't have time to dig any deeper right now, but on the theory that it's a botnet doing click fraud, I'll pass this along to our cybercrime people.
If this clickfraud bot consumes a thread per connection, it may be possible to overwhelm its available resources by taking as long as possible to answer its requests, known as a tarpit or teergrube. The kernel-based tarpit I wrote years ago (ipt_TARPIT) would only hold these for a few minutes, so I experimented with getting NginX to reply as slowly as possible using its rate-limiting, and was able to capture and hold open 105,000 connections to port 8118 from 1500 different IPs. However, NginX has a lower bound of one byte per second out of the box, which with TCP packet overhead consumed more bandwidth than I was willing to offer. I then wrote a simple Go-based HTTP tarpit, which seems to also be effective at capturing a bunch of connections; I'm back up to to 22,000 and very slowly rising. If anyone else feels like playing with this, feel free to grab http://www.die.net/tools/http-tarpit/http-tarpit.go and install a Go compiler from http://golang.org/doc/install. Build with "go build http-tarpit.go" and then run "./http-tarpit" as a non-root user. Be careful if you are tight on RAM; it seems to eat a few hundred megs per 10,000 concurrent connections. I haven't tried to optimize this at all. -- Aaron
On Sun, 21 Jul 2013, rotpoison throngnet wrote:
I am hoping that some other exit relay operators can sniff for packets to destination port 8118
I set up a copy of nginx returning 404s on that port. After a few thousand requests, here are the hostnames it is trying to hit: 4655 ib.adnxs.com 2193 ad.globe7.com 1705 ads.creafi-online-media.com 1149 ad.tagjunction.com 767 ad.yieldmanager.com 259 an.z5x.net 184 ad.z5x.net 123 ad.xertive.com 115 ib.reachjunction.com 80 tags1.z5x.net 72 ad.bharatstudent.com 71 ad.reduxmedia.com 23 ad.smxchange.com 18 opt.cdxndirectopt.com 10 www.xtendadvert.com It might be worth digging up the security contact for at least the top few of those and give them a heads up. And the /24s that have sent at least 100 requests (of 811 unique IPs from 122 /24s): 1182 23.19.54.0/24 878 173.234.116.0/24 645 208.115.124.0/24 639 173.208.16.0/24 585 23.19.130.0/24 398 64.120.5.0/24 397 64.31.43.0/24 389 64.31.38.0/24 376 64.31.63.0/24 369 173.234.41.0/24 362 108.62.236.0/24 351 23.19.107.0/24 328 173.234.33.0/24 319 64.31.39.0/24 291 108.62.192.0/24 280 108.62.5.0/24 272 173.208.83.0/24 262 208.115.245.0/24 238 69.162.66.0/24 237 70.32.43.0/24 229 216.245.219.0/24 223 64.31.52.0/24 191 64.120.77.0/24 184 173.234.42.0/24 180 64.120.60.0/24 172 63.143.53.0/24 172 23.19.76.0/24 172 23.19.35.0/24 172 173.234.188.0/24 163 173.208.85.0/24 159 208.115.200.0/24 150 173.234.224.0/24 149 173.234.247.0/24 147 64.120.58.0/24 143 74.63.232.0/24 143 74.63.192.0/24 137 108.171.248.0/24 132 64.31.62.0/24 120 108.62.40.0/24 116 64.31.48.0/24 114 173.234.153.0/24 113 74.63.255.0/24 113 108.177.183.0/24 112 69.162.75.0/24 108 208.115.246.0/24 103 74.63.199.0/24 100 63.143.59.0/24 These are very unlikely to have been spoofed, as they were from completed TCP connections. -- Aaron
participants (5)
-
Aaron Hopkins -
Javantea -
krishna e bera -
rotpoison throngnet -
Zack Weinberg