- tor-relays - lists.torproject.org

Re: [tor-relays] tor-relays Digest, Vol 3, Issue 11
by Gijs Peskens 14 Apr '11

14 Apr '11

My ISP also send me a message about abuse (virusses) ,and after I send them a reply that I'm running a tor node and that if they receive further abuse complaints they should just forward them to my mail for me to handle myself I didn't receive any abuse mail again :) I think my ISP is actually running some IDS with sinkholethinghies (I don't know anything about IDS'es yet, will research into it) and I can access a page with info on my IP wich shows some activity: 2011-04-05 21:56:55,85.223.49.156,29272,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,DE,,1,,,Windows,2000 SP2+, XP SP1+ (seldom 98) 2011-04-05 22:26:35,85.223.49.156,45924,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,US,,1,,,Windows,2000 SP4, XP SP1+ 2011-04-04 21:04:06,85.223.49.156,20507,NL,GET /search?q=0 HTTP/1.1,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .N... 2011-04-05 02:29:02,85.223.49.156,20507,NL,GET /?REMOVED HTTP/1.0,sality,KUKU v5.02c =REMOVED,,30184,Windows,2000 SP4, XP SP1+,,80,www.REMOVED.info,,,,REMOVED,8560,... 2011-04-05 22:02:01,85.223.49.156,20507,NL,GET /search?q=0 HTTP/1.1,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .N... 2011-04-06 01:13:53,85.223.49.156,20507,NL,.,downadup,,,21901,,,,80,,,,,REMOVED,US 2011-04-07 20:08:37,85.223.49.156,20507,NL,GET /tatoshko.biz?data=REMOVED== HTTP/1.0,machbot,MachBot,,10988,Windows,2000 SP4, XP SP1+,,80,853c9e57.biz,,,,87.10... 2011-04-11 16:46:41,85.223.49.156,47015,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,US,,1,,,Linux,2.6 (newer, 2) 2011-04-11 15:31:23,85.223.49.156,20507,NL,GET /search?q=15 HTTP/1.0,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727),,45931,Windows,2000 SP... 2011-04-12 04:08:30,85.223.49.156,44022,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,DE,,1,,,Windows,XP/2000 REMOVED= ip adresses (destination), dns names or things that look like http session specific things. I see one port number (destination) somewhat more (all cases of tcp,sinkhole except 1): 8560 might be a virus/trojan/worm specific port ? Might be a good idea to remove this port from your exit if you get a lot of complaints (and it's not used for anything usefull) The idea of setting up a local smtp out server with spam detection and clamav seems like a very good idea, maybe together with some tarpitting (if possible and easy) it would help a lot of users in need of smtp access and deter spammers (as they would spend hours and hours in tarpits at random when using tor) anyone can provide some good advice on how to set it up properly (I'm running FreeBSD)? Would also be _really_ nice to maybe somehow add some header that says it was send using a tor relay with admin details so my ISP (as I would probably need to set it to relay to their smtp) will not start bitching and moaning about that to me, is it possible ? Yes? How ? ;) What are the dangers of running an IDS myself ? Privacy wise I mean, could it be set up so that it knows about bad stuff hapening and in no way log other stuff ? 2011/4/13 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Tor and Viruses (Porcelain Mouse) > 2. Re: Tor and Viruses (grarpamp) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Apr 2011 20:46:21 -0700 (PDT) > From: Porcelain Mouse <porcelain_mouse(a)q.com> > Subject: [tor-relays] Tor and Viruses > To: Tor-Relays <tor-relays(a)lists.torproject.org> > Message-ID: <alpine.LFD.2.02.1104122018100.5770(a)localhost.localdomain> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > Greetings All, > > I've been running an exit for about 5 months, but had to stop due > to virus abuses. In the last two weeks, my ISP has partially blocked my > Internet access twice due to suspected virus infections. I'll spare you > the long story, but I was able to get a copy of their "evidence" and I'm > fairly certain it was connections made through my Tor relay. > > 1) How common is it that Tor is abused by viruses? What is the trend? > 2) Is this just standard virus-kit material, these days? > > I guess I was a little surprised. Obviously, this is a great idea for > hiding the infection site, so I'm sure it's being done. But still, I've > been fighting viruses for quite a while and I don't think I've read a > single virus description that mentioned Tor. I'm sure it's happening, but > I've never heard a single statistic about it, so I thought I would ask. > > Also, this type of abuse is *not* mentioned on the Tor wiki's Abuse FAQ > under "What should I expect if I run an exit relay?" I read that section > carefully and was prepared for most of the things mentioned. Again, I'm > not completely shocked. I'm just saying it didn't seem likely, according > to the FAQ. It would be nice to know how likely is this kind of abuse, > and what is the trend. (And, maybe someone can add the results to the FAQ > when we have an answer.) > > Thanks, > PMouse > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Apr 2011 03:19:27 -0400 > From: grarpamp <grarpamp(a)gmail.com> > Subject: Re: [tor-relays] Tor and Viruses > To: tor-relays(a)lists.torproject.org > Message-ID: <BANLkTikwPS6JDqKMvaxxWhgq2dUoGELKKA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > my ISP has partially blocked my Internet access twice > > due to suspected virus infections. > > Virus is likely not the right word for things. Anyways... > > There's really no reason an operator cannot run something > like bro-ids.org and sink known bad traffic in real time. Yeah, > sure, everyone will bitch at me. But it is operator fiat, and > they're not sinking specific users, so well within common > carrier exceptions on that aspect. No different than operators > who block 'torrent' ports, smtp, etc. > > Speaking of smtp, one could even redirect that into their > system despam/clamav it and send it on its way. Better > than nothing. Especially for the legit senders. > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 3, Issue 11 > ***************************************** >

2 1

Re: [tor-relays] tor-relays Digest, Vol 3, Issue 9
by Ray Waren 12 Apr '11

12 Apr '11

I have problems connecting to the tor network always stuck at "Authenticating to Tor". I ask for assistance in what I should try to get in touch with tor again. Thank you. 2011/4/11 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: two relays serving same hidden service (prafull moulekhi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Apr 2011 23:59:08 +0530 > From: prafull moulekhi <prafullmoulekhi90(a)gmail.com> > Subject: Re: [tor-relays] two relays serving same hidden service > To: tor-relays(a)lists.torproject.org > Message-ID: <BANLkTi=G8-OyQsz0rr38=PJWHNb7bgwCOA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hi > my tor is not working.It's logs show "No certificate available" > > please help > > Prafull >

2 1

two relays serving same hidden service
by cmeclax-sazri 10 Apr '11

10 Apr '11

Suppose I have this setup: Dhole, Dingo, and Fennec are three computers on a LAN. Dhole and Dingo both have external IP addresses and both run Tor relays. Fennec runs a hidden service. Both Dhole and Dingo have the same hidden service address, paxamifrabolerfu.onion, pointing to Fennec's LAN address. Alice tries to connect to paxamifrabolerfu.onion. What happens? cmeclax

3 2

avoiding frequent MyFamily syncing on a dynamic Tor instance group
by tagnaq 07 Apr '11

07 Apr '11

Hi, I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes: To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones. >From a security point of view this is probably quite a bad thing, but does someone already do that?

4 4

Re: [tor-relays] Request for help - Tor legal FAQ
by Marcia Hofmann 07 Apr '11

07 Apr '11

>> To make the FAQ as current and useful as possible, we want to make >> sure that we know about any legal issues that relay operators in the >> United States may have experienced over the past few years. > I understand the focus on USA, but wouldn't this be a good opportunity > to add legal information about other countries as well? It's fantastic idea, and we'd love to be able to do it. Unfortunately, all of our practicing lawyers are licensed in the United States, and we don't have the legal expertise to provide an FAQ like this on a country-by-country basis. :(

3 3

high cpu usage, normal ?
by Gijs Peskens 05 Apr '11

05 Apr '11

I'm running an exit relay configured to give up to 6,4MB/s on an Athlon64 3000+ Freebsd box, and I'm seeing cpu usage between 30-60% is this considered normal ? Any means of getting it down? (except getting a faster cpu or hardware crypto)

3 2

help w/ Debian: Error binding network socket: Address already in use
by Olaf Selke 04 Apr '11

04 Apr '11

Kernel 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux Tor v0.2.2.23-alpha (git-b85eb949b528f4d7) Hi folks, on blutmagie exit Tor frequently logs Apr 04 15:27:48.706 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.765 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.775 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.785 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.864 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.900 [warn] Error binding network socket: Address already in use I'm a little bit clueless what's wrong here. I've read http://hea-www.harvard.edu/~fine/Tech/addrinuse.html and found SO_REUSEADDR being used in connection.c. Tor opens about 1k new tcp connections/s and the average number of open tcp sessions is about 70k. anonymizer2:/tmp# netstat -tn | wc -l 70597 Any ideas why Tor can't bind to sockets? regards Olaf

2 2

Request for help - Tor legal FAQ
by Marcia Hofmann 04 Apr '11

04 Apr '11

Hi there, EFF is updating the Legal FAQ for Tor Relay Operators, which we first wrote about six years ago. https://www.torproject.org/eff/tor-legal-faq.html.en To make the FAQ as current and useful as possible, we want to make sure that we know about any legal issues that relay operators in the United States may have experienced over the past few years. To that end, does anyone on this list know about situations where... ...a relay operator has been sued or prosecuted for anything Tor-related? ...the police have seized servers that are running relays? ...someone has tried to use a legal demand (like a subpoena) to figure out who operates a relay? Please email me off-list if you know about an incident like this or anything else you think I should be aware of. Many thanks for your help! -- Marcia Hofmann, Senior Staff Attorney Electronic Frontier Foundation 454 Shotwell Street San Francisco, CA 94110 tel: (415) 436-9333 x. 116 | fax: (415) 436-9993 marcia(a)eff.org | http://www.eff.org

3 2

circuits that fail the exit policy repeatedly
by Scott Bennett 03 Apr '11

03 Apr '11

Upon occasion, I see very long sequences of info-level log messages to the effect that an exit stream has failed the exit policy. Is there any good reason why a relay should not return a DESTROY cell on a circuit whose exit connection attempts have failed the exit policy some threshhold number of times? After all, the exit policy is published information. Anyone making repeated attempts to violate it is either doing so in ignorance of a recent change to the exit policy, perhaps not yet propagated to the client causing the problem, or is doing so as some sort of cracking attempt. It seems to me that killing a circuit in this situation is appropriate to minimize waste of tor network resources. Any thoughts on this? 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 * **********************************************************************

1 0

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 03 Apr '11

03 Apr '11

On Thu, 10 Mar 2011 10:27:50 -0800 Chris Palmer <chris(a)eff.org> wrote: >On 03/10/2011 09:10 AM, mick wrote: > >> Using Tor to scan the internet is a good way to see how the internet >> looks from different perspectives at once, which can be quite valuable." >> >> Which says to me that you are using Tor to do this research. > >No, it says to you that using Tor to scan the internet is a good way to >see how the internet looks from different perspectives at once, which >can be quite valuable. > >> So which is it? > >The Observatory work was not done through Tor. Good. > >However, using Tor to scan the internet is a good way to see how the >internet looks from different perspectives at once, which can be quite >valuable, so I vociferously defend the idea of doing so. > Ah. "The ends justify the means." How enlightened. :-( 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 * **********************************************************************

2 1

Tor not releasing port on shutdown?
by Geoff Down 02 Apr '11

02 Apr '11

Hi, the most recent times I have tried to restart Tor after a 'killall -INT' I have been presented with the following error: "[warn] Could not bind to 0.0.0.0:9001: Address already in use. Is Tor already running?" I'm not sure if this has started since I changed version, I'm on Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) OSX 10.3.9 . Anyone else see this? How do I release that port? Command 'lsof -i' returns no results, so I don't see Tor is really using it still - no sign of Tor in command 'ps -aux' output. Update: after running those commands, Tor was able to start. Why the delay? Is this normal? TIA GD -- http://www.fastmail.fm - The professional email service

5 5

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 30 Mar '11

30 Mar '11

On Wed, 9 Mar 2011 19:18:34 -0500 cmeclax-sazri <cmeclax-sazri(a)ixazon.dynip.com> wrote: >On Wednesday 09 March 2011 17:20:17 Chris Palmer wrote: >> On 03/09/2011 01:48 PM, Arjan wrote: >> >> We are saying hello on port 443, and then saying goodbye. Once. Using >> >> normal TCP and TLS handshaking, no tricks. For the good of the internet. >> > >> > That would be enough to get me in trouble with my ISP for performing >> > portscans (if I were running an exit node). >> >> And how would you, or anyone else, differentiate that from normal web >> browsing? > >If a lot of those connection attempts are going to IP addresses with no host >present, or hosts not running a webserver, it looks like portscanning. If >almost all of the connection attempts are to webservers that have port 443 >open, it looks like normal https web browsing. Are you kidding? Closing a connection upon receipt of the ACK response to the SYN you sent looks like normal HTTPS web browsing? On what planet? Normal web browsing, whether HTTP or HTTPS, involves data transmission occurring in both directions between receipt of that ACK and the closing of the connection by the web browser. Closing the connection upon receipt of the ACK response to the SYN without any intervening data transmission is, OTOH, a characteristic behavior of port scanners. So you had it backwards. Here's a tidbit for you to consider. pf offers an option on filtering rules for inbound SSL connections called "synproxy", which relieves server software of the effort of dealing with bogus connection attempts by handling the SSL exchanges itself before passing the connection on to the server. It also means that a connection from something that doesn't know how to perform the SSL handshaking will sit until the timeout occurs, so the attacker is stuck with an outstanding connection tying up resources until that happens. That delay of a couple of minutes can be a long and wasteful nuisance to an attacker. OTOH, a legitimate application, e.g., a tor client or relay trying to connect to the ORPort of another relay, completes the handshake and begins communicating with its peer with no delay, and the software accepting the connection only deals with the legitimate connections. It works just great! :-) I highly recommend it to anyone running a tor relay on a system that supports pf. > >I have only one external address and only a few ports forwarded, so I can't >detect portscans. I have noticed that an attempt to guess passwords on SSH is >often, but not always, preceded by a connect and disconnect from the same IP >address, which is probably part of a portscan. I don't block addresses that >scan ports, but I do block addresses that try to guess passwords (not on the >Tor box, just on the other one). The block expires in a day. > To each his/her own. Legitimate port scanning operations are typically run by system/network administrators against the machines on their *own networks*. I treat any others as attackers or at least attacker-wannabes, and I keep track of such miscreants indefinitely against the possibility that I might someday provide services other than tor relaying. The miscreants will have no access to such services on general principles and will only have access to the tor node if and when they are currently running a public (i.e., not a bridge) tor node on the system with the IP address from which their tor attempts to connect to mine. 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 * **********************************************************************

4 4

Bridges on OpenWrt
by Mitar 29 Mar '11

29 Mar '11

Hi! Is there some package for running Tor bridges on OpenWrt supported devices? But as I understand Tor bridges consumes same amount of CPU power and RAM as Tor itself so they are not really possible for low power devices as WiFi routers where OpenWrt normally runes (with typically around 16 MB RAM and 200 MHz CPU power). But on the other hand, as we have in operation a lot of WiFi routers around the country, many of them having their own public IP from very diverse IP ranges, this would be quite useful for bridges. So my question is if somebody has tried to do something like that? Have some experience with it? And also if maybe bridges support would be possible to extend so that we could make (low overhead) tunnels from this WiFi routers to the central server where there would be running a Tor node connected to the Tor network, having enough CPU power and RAM to run everything. So it would be great if the Tor clients would be able to connect to those VPNed end points, but encryption itself would be done on the server. Mitar

3 5

multiple tor nodes on one router? was first using bridge then become bridge
by Lorenz Kirchner 27 Mar '11

27 Mar '11

Hi everyone, so I received no hint as to how or whether to pursue this thought... i shall find other sources of information I just started reading the manual, would you believe it.. I have a new question now, I currently have set up number of tor relays on my router which are loadbalanced using squid... in the hope to increase throughput and perhaps achieve increased anonymity by sending requests for one site through different tor routes... Is that advisable or even effective? My feeling is that the connection is somewhat more reliable than with just one tor relay.. and following on with this could one of these relays be set up to connect to tor via a bridge and then pass directory info on to the other relays running on the same machine? Kind regards, Loz On Thu, Mar 10, 2011 at 11:16 PM, Lorenz Kirchner <znerol2(a)gmail.com> wrote: > On 3/9/11 11:29 PM, mick wrote: > >> >> This this: >>> https://sites.google.com/a/infosecurity.ch/testst/ >>> >>> It's the google spreadsheet that load the bridge information embedded >>> into a google site. >>> >> I need a google account for that. What if I don't want one? >> >> So, any new ideas anybody? I still feel it would be best if 1. there was > a special function within tor to change from using a bridge to becoming a > bridge whithin the censored network, and 2. spreading this bridge-status > info locally... perhaps like dht in torrent.. only revealing a small > selection of available bridges nearby.. i obviously only have a very dim > idea of what i'm talking about.. sorry about that > > anyways, if these two problems could be addressed tor could be a biggie > with a lot of people here.. ;) -- think: cheap openwrt low maintenance > appliance.. > > Loz >

2 2

what updates do I need to install?
by Kathryn Cramer 25 Mar '11

25 Mar '11

I gather from Jacob's Twitter feed that I should download and install the new Tor Browser Bundle because of security updates. Will this affect the relay I am running? Do I also need to update Vidalia? Kathryn

2 1

IRQ affinity
by Mitar 24 Mar '11

24 Mar '11

Hi! I do not know if you have solved this but reading here: http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-li… It is written that: "So if on your system CPU0 handles all interrupts by default, this probably means that APIC configured ambiguously." So maybe it is nothing wrong with e1000e drivers/cards but with APIC configuration? Mitar

1 1

frequency of checking an IP change
by tagnaq 23 Mar '11

23 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm wondering how often Tor tries to detect an IP change of itself and if a relay operator can modify that frequency? Observing the detection point in time and the actual IP change I guess it takes several minutes: - From the logfile: 00:33:30 Tor: Our IP Address has changed from ... to ... The new IP address was actually assigned several minutes before: 00:27:53 (check occurs every 10seconds) It would be valueable to modify the frequency because the relay in question gets a new IP address every few hours (<10h). Looking at the man page I couldn't find anything regarding that frequency. kind regards, tagnaq -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk2J3ZIACgkQyM26BSNOM7b4NwD/QmH0RWDsp0muCy0PFtkE0Gw4 TDNZx4eDYcOLKfvRX5UA/1PdG8w7DYtfvktWGkzBj82d6/gFo68oVJ+QAM8yqvWU =wnE6 -----END PGP SIGNATURE-----

1 0

abuse reports from shadowserver.org
by Alexander Bernauer 21 Mar '11

21 Mar '11

Hi everybody, my ISP keeps on receiving abuse reports from shadowserver.org. They claim that an IRC bot operates from the IP that belongs to my tor exit. The strange thing is that my exit policy only allows web and mail ports. Furthermore, the IPs of the shadowserver honeypots have a ptr entry for *.sinkhole.shadowserver.org. So, I could block their servers either by means of the exit policy or with iptables. Which one would you prefer? I additionally wanted to ask here if there is any experience with shadowserver in this regard? Explaining the issue to my ISP failed. They keep on getting nervous. Talking to shadowserver also failed, because subscription to their public mailing list is moderated and my direct mails have been ignored for several months now. Any advice? regards Alex

6 6

weighting algorithm
by Olaf Selke 16 Mar '11

16 Mar '11

Hi, between Saturday evening and Tuesday afternoon (UTC+1) my relay's bandwidth dropped to about 2/3 of its normal value. Did some changes in directory's weighting algorithm occur during this time period? regards Olaf

5 6

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 10 Mar '11

10 Mar '11

On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris(a)eff.org> wrote: >On Feb 26, 2011, at 9:53 AM, mick wrote: > >> No reputable security researcher would a) scan a network without that >> network owner's explicit permission, nor b) use tor for that scan. > >Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet. Well, as I've just finished describing in another topic here, I treat scanning of my system as attempted security breaches. Such scans will not elicit any apparent response from my system, except that the scanner's IP address will shortly be added to my "block" file, which will deny all future access to my tor node's ORPort and DirPort. > >Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable. > I disagree and, as noted above, treat that as a cracking attempt. tor nodes that you abuse in such fashion will continue to function by the means described below, provided they are listed in the current consensus document. My current procedures are described in the next two paragraphs. However, your implication quoted above that EFF has/does/will abuse tor exits in this manner suggests I may have to modify my treatment of tor exits from which your scans emerge, given the increased likelihood that the offenses did not originate from the exit node's system and that the exit node was instead a victim as well. Nevertheless, your scans will not get responses from my system, except for connection attempts to the ORPort or the DirPort. First, I have set the sysctl variable called net.inet.tcp.blackhole to 2, which causes the kernel to drop all incoming packets addressed to closed ports. The IP addresses of tor nodes, including exit nodes, listed in the cached-consensus file on my system are placed into a "pass" file every 30 minutes, which temporarily exempts them from being checked against the "block" file. It is temporary in that the exemption lasts for 30 minutes only, although it will be exempted for another 30 minutes whenever the address exists in the cached-consensus file at the time the "pass" file is rebuilt. Anyone who may be concerned that their IP address or address range might be listed in my "block" file is welcome to write to me to inquire about it. If it is, then I will offer to remove the block on an indefinitely probationary basis. However, if I encounter the same IP address in my pf log again, then I will block the address permanently. Frankly, I think it's appalling that a previous sponsor organization for the tor project should turn on the tor network in the fashion you've confessed here that it has. I'm tempted to dig out all of the EFF IP address ranges and block them permanently, just as a matter of principle, although it would obviously have little real effect upon your organization. No wonder so many of us have run afoul of our ISPs when trying to run exit nodes when even EFF is trying to spoil the tor network for us. Who needs enemies with "friends" like EFF? 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 * **********************************************************************

12 27

first using bridge then become bridge
by Lorenz Kirchner 10 Mar '11

10 Mar '11

Hi everybody, i'm in china and when i start tor nodes (on a linux server) i often have to first start up the node using bridges, after i ran tor for a while i can restart the node as a bridge-no-exit-relay-entry-node, or whatever, and it will (through its cached data, I guess) be able to connect to the tor network.. and, importantly, help other nodes to connect to the tor network. It would be great if the node's mode could automatically change, when I start the tor node it will try to be a bridge relay according to my torrc, if it can not establish a connection it will first use a bridge and when it has enough data (non blocked entry nodes) will return to becoming a relay. Does this make sense? btw i think bridges.torproject.org is blocked in china (perhaps not surprisingly). And also, on linux servers, couldn't the tor node get the bridges via email by itself, that would be fantastic! each tor node could have its own gmail account, but i guess it would probably somehow be a problem for anonymity..? take care :)

4 11

tor not working
by prafull moulekhi 09 Mar '11

09 Mar '11

hi I m having problem in running tor since last 1 week. I am getting the following log. Mar 08 14:17:17.950 [Notice] Initialized libevent version 1.4.14-stable using method win32. Good. Mar 08 14:17:17.950 [Notice] Opening Socks listener on 127.0.0.1:9050 Mar 08 14:17:17.950 [Notice] Opening Control listener on 127.0.0.1:9051 Mar 08 14:17:17.950 [Notice] Parsing GEOIP file. Mar 08 14:17:22.831 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority urras; launching request.

1 0

about the balls of steel level of relay nodes
by Nicolas Bock 09 Mar '11

09 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, I was running a tor exit node until I came across this article: http://calumog.wordpress.com/2009/03/18/why-you-need-balls-of-steel-to-oper… While I don't live in the UK, I live in the US, I believe that the situation here has eroded to a point where running an exit node requires the mentioned balls of steel, which I admittedly don't have. Since I do want to support the tor project, I am wondering to what extend running a relay node is putting myself and my family at risk of legal prosecution. My understanding is that my host would simply generated encrypted traffic that is not objectionable to the ISP (because they can't look into it) unless the use of tor itself is outlawed. Is that correct? Thanks, nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk11L2cACgkQf15tZKyRylKQKQCgxlmqlOQPy2tUiZW8VsqaiQKv 930AnRW/+5SpltOWtGQr6hwWgJc4RpzG =MoZM -----END PGP SIGNATURE-----

4 3

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 09 Mar '11

09 Mar '11

On Tue, 08 Mar 2011 14:25:16 -0800 Chris Palmer <chris(a)eff.org> wrote: >On 03/08/2011 02:04 AM, Scott Bennett wrote: > >> Frankly, I think it's appalling that a previous sponsor organization for >> the tor project should turn on the tor network in the fashion you've confessed >> here that it has. I'm tempted to dig out all of the EFF IP address ranges >> and block them permanently, just as a matter of principle, although it would >> obviously have little real effect upon your organization. No wonder so many >> of us have run afoul of our ISPs when trying to run exit nodes when even EFF >> is trying to spoil the tor network for us. Who needs enemies with "friends" >> like EFF? > >Do you understand the research we are doing? Do you know technically >what we have done, and what we hope to do, and what the impact has been >and will be? > >If you don't know yet, please check out our page: > >https://www.eff.org/observatory All right, I've looked. I knew someone was doing that sort of thing, but I didn't remember that EFF was involved. It looks interesting and valuable, but quite irrelevant to the point I made. Nothing on that page justifies subjecting tor exit node operators to the abuse and hassle of being shut down by their ISPs because EFF is so crass as to run port scans through the tor network. Nothing on that page justifies damaging the tor network by reducing the exit node pool by getting exit nodes shut down, which also reduces the total number of relays, often for entry and middle usage, too. > >If you have seen and understood that, please explain what about it you >find so objectionable. Note also that the Tor Project is using our Done. See above. >database to improve Tor itself, too. Fine. I don't see that EFF's port scans have to be done through the tor network. > >We are working to make the internet safer for everyone. > Well, sometimes, at least. I'll never forget how John Barlow sold us out during the time of William the Prevaricator, though. 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 * **********************************************************************

1 0

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