Re: another unusual connection
On Sun, 10 Feb 2008 07:54:06 GMT Paul Ferguson [EMAIL PROTECTED] wrote: - -- Scott Bennett [EMAIL PROTECTED] wrote: Huh. Nice of you to delete the attribution to Roger Dingledine. = $ telnet 212.112.242.159 80 Trying 212.112.242.159... Connected to 212.112.242.159. Escape character is '^]'. GET /tor/ HTTP/1.0 For what it's worth, we (Trend Micro) have identified several Tor Is there some reason we should believe that you represent Trend Micro? However, given the obviously false information being provided by anon-tor-proxy.maximator.org (212.112.242.159), could it please be flagged as Invalid and Bad Exit by the directory authorities? nodes which have malicious intent -- this one among them. Be very careful. Tor is being actively exploited. We know that. 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 * **
Re: another unusual connection
Paul Ferguson schrieb: For what it's worth, we (Trend Micro) have identified several Tor nodes which have malicious intent -- this one among them. Be very careful. Tor is being actively exploited. - ferg Thanks for the heads up. While the tor community does know, that malicious exit nodes exist, to my knowledge there is nothing we could do about it except manually flag each one in the directory. I suppose you are not at liberty to share that list of bad exits; however, any clues as to how one could effectively identify them would be very appreciated. Andrew
Re: iptables and tor
On Sat, Feb 09, 2008 at 07:07:26PM -0500, [EMAIL PROTECTED] wrote 0.8K bytes in 21 lines about: : Has anyone given any thought as to what firewall rules to use on a linux : system running a tor server? Besides the usual attacks against the In general, how would you protect a server with a public IP without tor? -- Andrew
Re: another unusual connection
On Sun, Feb 10, 2008 at 07:54:06AM +, [EMAIL PROTECTED] wrote 0.8K bytes in 37 lines about: : For what it's worth, we (Trend Micro) have identified several Tor : nodes which have malicious intent -- this one among them. I hear the sky is falling and my milk is going sour because of neutrinos, too. Full disclosure would be better than fearmongering. -- Andrew
Re: another unusual connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Scott Bennett [EMAIL PROTECTED] wrote: Is there some reason we should believe that you represent Trend Micro? Believe what you like. Just trying to be helpful. Cheers, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHr0jzq1pz9mNUZTMRAiqcAKDmRMa3TNLjx04cuni0dKIgVqJHIgCfVEbZ gOzf1jOqhYhzaYBlHaF8FmQ= =QvDD -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: another unusual connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Dominik Schaefer [EMAIL PROTECTED] wrote: For what it's worth, we (Trend Micro) have identified several Tor nodes which have malicious intent -- this one among them. Could you give us some more information about this? ;-) I would assume, the reported behaviour could be very well caused by some unusually configured or misconfigured node and not malicious intent itself. Actually, it appears that the hosts that are triggering alarms for us have already been identified previously as hosting malicious content -- not flagged explicitly for being a Tor node. For example, a host that may have been previously identified as hosting an MPack exploit engine may also now be used as a Tor node. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHr0o3q1pz9mNUZTMRAlmAAJ9kIG1X7UYBw0wJHXrmGmN52bL+EwCdGGv0 pOfGiCAuQW9StPguQD1JBoI= =Asxa -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: iptables and tor
The packets coming in on Tor TLS tunnels are destined for your node. They go up the stack through TCP and TLS to the Tor application itself. Tor does its AES CTR encryption on the cells coming out of these streams, and puts them in other streams based on the circuit labels. Here they get TLS'd, packed into TCP segments and go out. This means that packets going out after relaying have nothing to do with packets coming in, so I don't think marking makes any difference. This is clearly a positive point of Tor. Thanks Csaba, that's exactly what I was worried about and your information is reassuring. The usual allow/deny rules should be good enough. --- Anthony G. Basile, Ph.D. Director of Information Technology, D'Youville College, 320 Porter Ave. Buffalo NY, 14201
Re: iptables and tor
dante schrieb: Hi everyone, Has anyone given any thought as to what firewall rules to use on a linux system running a tor server? If you operate a tor node within your private network und your network offers services which are not public or should not be public, then you should remember that you create a tunnel in your local network by running tor. In this case you have to ensure that the exit policies of the tor node are set in a way that nobody can exit from your tor node into you local net. Additionally you can filter the relevant traffic originating from your tor node. Dominik
Re: iptables and tor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 By default are all the private ranges already blocked in the exitpolicy. Dominik Schaefer wrote: dante schrieb: Hi everyone, Has anyone given any thought as to what firewall rules to use on a linux system running a tor server? If you operate a tor node within your private network und your network offers services which are not public or should not be public, then you should remember that you create a tunnel in your local network by running tor. In this case you have to ensure that the exit policies of the tor node are set in a way that nobody can exit from your tor node into you local net. Additionally you can filter the relevant traffic originating from your tor node. Dominik Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkevdlUACgkQStmJ9+mkUHNdxwCeOjcYGMgP8vrmaKGTZIRx/7nh EqQAn1pfvH7X8+1f1QhcOPE0CfGKCKAG =7f0e -END PGP SIGNATURE-
Re: another unusual connection
On Sun, 10 Feb 2008 01:47:01 -0600, Scott Bennett wrote: But, Roger, will the 0.2.0.19-alpha release at least confirm during the reachability tests that it is talking to itself and not to some other server? I am not sure that is what is happening. For example, it may be that the reachability checks are being performed on the current (and correct) IP before the update to the suggested new IP is put into effect. Anyway, I suggested making an explicit verification of the reachability of the current IP before updating to a suggest new IP as a means to help counter incorrectly suggested new IPs. E.g., if the old IP still works, ignore the suggested new IP; if the old IP does not work, update to the suggested IP. (This sort of thing doesn't solve the root issue of how best to establish trust in the IP address observations of directory servers, but maybe it helps a bit. Once you get an accurate IP suggestion, you are protected against incorrect suggestions until such time as you become unreachable again, when the game starts all over and you were back down anyway.) There are probably many ways to perform that check - one way I threw out there was to explicitly call the check reachability routines before updating; another (and perhaps better) way might be to only process suggested new IPs when Tor notices that it is no longer reachable. Unfortunately, neither did I supply a working patch to implement explicit verification of the old IP as an additional workaround for the root issue nor did I even confirm the cause of the successful reachability tests. Scott, you have been quite vocal in this area, so perhaps you might want to put in some legwork here. I am sure the Tor team (and the rest of us) would appreciate such efforts. -Andrew
Re: another unusual connection
john smith wrote: Yet another reoccurrence, yesterday, of the same sequence of events once again with the same IP address. My server had been running for just under five days since the last time this happened. Feb 07 10:56:59.108 [Notice] Our IP Address has changed from 87.194.38.72 to 212.112.242.159; rebuilding descriptor. Feb 07 10:57:11.780 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Feb 07 11:09:51.530 [Notice] Our IP Address has changed from 212.112.242.159 to 87.194.38.72; rebuilding descriptor. Feb 07 11:09:55.905 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Feb 07 11:10:03.139 [Notice] Performing bandwidth self-test...done. I do have a question for John Smith; are you using a VPN from your home to your server or from your server to somewhere else? In the past I've seen this happen with my exit node when I would VPN into my server or a clients server. The VPN connection would set the default gateway and all my traffic would exit the other end of the VPN. So when Tor would do it's IP check and reachability test, it went bad. Also, it wasn't obvious right away when this would happen. Sometimes it would take up to an hour after I had connected the VPN before Tor would freak out. Since I've seen error messages like yours when I had that problem, I thought I might offer a couple of pointers. You may want to use the following two options in your torrc config. Address - This should be the IP of your server which is reachable from the internet. OutboundBindAddress - If your Tor server is behind a NATd router, then set this to the internal (192.168.x.x or whatever) address of your machine. This should prevent traffic from leaving a 10.x.x.x address if your real internal address is a 192.168.x.x. [OPTIONAL THIRD OPTION] AssumeReachable 1 - Prevents your server from doing reachability test. It will just upload your descriptor to the DAs. By using the OutboundBindAddress, I was able to have my Tor server listen on my regular local address (192.168.X.X) and not think it was on a the VPN local address (10.x.x.x). Also, double check to make sure your VPN connection is *not* setting itself as the default gateway (Windows) or pushing the default route (Linux). (It should be obvious, but just in case it's not, the 192.168.x.x and 10.x.x.x addresses are just examples. Your setting may be different so adjust your settings accordingly).
Re: iptables and tor
Tom Hek schrieb: By default are all the private ranges already blocked in the exitpolicy. Yes, the private or non-routable nets. I should have been more precise what I meant. ;-) (or should have avoided the term private) Suppose you have 87.78.1.170 as exit node and its subnet is 87.78.1.128/26. Suppose your organization has the net 87.78.1.1/24 and you have some services for internal use running on various hosts in that Class-C net. Then AFAIK you have to take care yourself of the appropriate exit policies, because tor can't possibly know this, e.g. explicitly disallow 87.78.1.1/24. Dominik
Re: tor and google-error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 like others have said, scroogle ssl is probably the way to go. however, it doesn't seem to handle special google queries yet (like define:foo or convert 1 gram to lbs, etc.). so, if you must use google (see below) Roger Dingledine @ 2008/02/08 21:00: https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#GoogleSpyware [...] if you find a useful workaround and write up a description of it, please let us know. tell vidalia 'new identity', then open 'network map' and close the connection to google, if still open. re-search on google and it will use a new circuit with hopefully a new exit node. repeat until google complies. note: don't just hit 'reload' in your browser as that will reload the google 403 error! ;) -BEGIN PGP SIGNATURE- iD8DBQFHr4pAXhfCJNu98qARCB25AJ9qt3rFKeIwrktKLNe19oDCMvbx2ACgxTHv YgMysl6c5XUmHAf19+GKO3E= =xWsG -END PGP SIGNATURE-
Re: another unusual connection
On Fri, Feb 08, 2008 at 02:45:04AM -0600, Scott Bennett wrote: I've been reading these reports on this list carefully and with growing alarm. How is it that the reachability testing routine(s) fail to discover that, upon connecting to the supposed new IP address on whichever TCP port the tor server is using, it is *not connected to itself*? I had been assuming all along that the reachability testing would check for something so obviously important. Does DirPort reachability testing also fail to check the identity of the server that answers its connection attempt? I think you're confusing the IP address guessing with the reachability detection. The IP address guessing is known to be not perfect. I mean, heck, it's based on plaintext unauthenticated claims from some dude running a Tor relay somewhere in the world. But in general it's quite a bit better than nothing, which was the previous option. (Once we have our netinfo cells up and running, we may be able to make it encrypted and authenticated. Which will help a little bit.) The reachability detection is also known to not be perfect. It just has to weed out most of the problems and the directory authorities can then test the rest. It makes me wonder what other glaring holes may exist in tor's various checking/testing routines. Submit a patch. --Roger
Re: another unusual connection
On Sun, Feb 10, 2008 at 02:10:55AM -0600, Scott Bennett wrote: However, given the obviously false information being provided by anon-tor-proxy.maximator.org (212.112.242.159), could it please be flagged as Invalid and Bad Exit by the directory authorities? Is it actually being a bad exit with respect to any content? My guess is that it's doing a proxypass from its apache on port 80 to whatever port Tor is running on locally, and Tor is getting confused about what IP address to report, because all the addresses *it* sees are coming from the apache server. I just checked in another patch that will reduce instances of this in the future, even for relays that haven't upgraded yet: http://archives.seul.org/or/cvs/Feb-2008/msg00117.html (There probably *are* a few malicious Tor operators out there somewhere, but in general many of the issues people tend to raise on this list can be more easily explained by bugs, misconfigurations, or other confusion. I've met the fellow who runs maximator, and he's been running Tor servers since 2005. He seems like a nice enough guy.) --Roger
