exit node experience: abuse over HTTP, stealrat infection
Dear all, I’ve been running tor non-exit relay freshhumbug at torrelay.nl <http://torrelay.nl/> for about 3 months now. Recently, I tried running it as an exit relay for a week, with following interesting results. Set up: - Ubuntu 14.04 running as VPS with transip.nl <http://transip.nl/>, latest release version of Tor - bandwidth rate set to between 1 MB/s and 2 MB/s - VERY reduced exit policy (listed below) Part 1: Abuse over HTTP. Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings, XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ During the last 30 minutes we recorded 333 attempts like this: XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ==== Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this. Part 2: Stealrat infection. As part of being an exit relay, I set reverse DNS to this-is-a-tor-exit.torrelay.nl <http://this-is-a-tor-exit.torrelay.nl/>, and I displayed the this-is-a-tor-exit-node.html web page on port 80, using the DirPortFrontPage option. A few days after having shut down my exit, I received notification from my provider that they have been told that my IP address was infected with Stealrat. It hosted a Stealrat PHP file, used to send spam. - http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-sites... <http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-sites-conceal-stealrat-botnet-operations/> - http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-... <http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-stealrat.pdf> However, the only thing I do with my VPS is run tor. I don’t run a web site, and don’t have apache or whatever installed. I didn’t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that’s present in the system. Either way, that webserver was hacked through a PHP hack. (Note that I received the Stealrat notification only after stopping my exit node. I’m not sure if the Stealrat hack was still active or not. I couldn’t find relevant PHP files on my system.) Since I didn’t want to spend time or effort (figuring out how to) clean my system, I reinstalled ubuntu & tor (only ~40 min work anyway). Lesson (for me): using the DirPortFrontPage option opens up an unexpected web server vulnerability. Perhaps this information is useful for others. With best regards, Kees Relevant parts of the torrc: ORPort 9001 # port used for relaying traffic DirPort 80 # port used for mirroring directory information - not used, since have accountingmax SocksPort 0 # prevents tor from being used as a client RelayBandwidthRate 1000 KB # limit for the bandwidth we'll use to relay RelayBandwidthBurst 10 MB # maximum rate when relaying bursts of traffic BandwidthRate 1000 KB # same as RelayBandwidthRate BandwidthBurst 10 M # same as RelayBandwidthBurst DirPortFrontPage /home/administrator/.arm/this-is-a-tor-exit.html ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:749 # kerberos ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy reject *:*
On Sun, Oct 19, 2014 at 01:24:31PM +0200, Kees Goossens wrote:
However, the only thing I do with my VPS is run tor. I don???t run a web site, and don???t have apache or whatever installed. I didn???t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that???s present in the system. Either way, that webserver was hacked through a PHP hack.
It is much more likely that this was a false positive. That is, whoever sent you the mail was using a wrong-in-your-case mechanism for detecting whether you're infected with "stealrat". They probably just make a list of all the computers that connect to them and send certain traffic. And if your computer connected to them and sent that traffic, onto their list you go. The Internet is full of people telling other people that they're infected and ought to clean up their computer. Sometimes they're right, sometimes they're wrong. Usually, when it comes to Tor relays they're wrong, because it never occurred to them that you might be proxying the traffic from somebody else. Hope that helps, --Roger
Dear Roger, Thanks for quick reply. This possibility did occur to me. When I asked my VPS provider about getting more information for further diagnosis told me they didn’t have more, but that the party that sent them the notification had been reliable in the past. My provider has been relatively friendly during this process, and I didn’t want to push them further. Overall, let’s just hope that I’ve been an atypical case in getting two complaints in my first week of operating an exit node. Thanks, Kees
On 19 Oct 2014, at 13:31, Roger Dingledine <arma@mit.edu> wrote:
On Sun, Oct 19, 2014 at 01:24:31PM +0200, Kees Goossens wrote:
However, the only thing I do with my VPS is run tor. I don???t run a web site, and don???t have apache or whatever installed. I didn???t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that???s present in the system. Either way, that webserver was hacked through a PHP hack.
It is much more likely that this was a false positive. That is, whoever sent you the mail was using a wrong-in-your-case mechanism for detecting whether you're infected with "stealrat". They probably just make a list of all the computers that connect to them and send certain traffic. And if your computer connected to them and sent that traffic, onto their list you go.
The Internet is full of people telling other people that they're infected and ought to clean up their computer. Sometimes they're right, sometimes they're wrong. Usually, when it comes to Tor relays they're wrong, because it never occurred to them that you might be proxying the traffic from somebody else.
Hope that helps, --Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Kees Goossens schreef op 19/10/14 13:24:
Part 1: Abuse over HTTP.
Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings,
XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ
During the last 30 minutes we recorded 333 attempts like this:
XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ====
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Hi Kees, Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I started sending the same replies but with a note "Please reply if you have read this message." - no replies. Their message mentions a contact address so I started cc'ing that address - still no reply. After replying for two months and never getting any replies, I stopped replying. IANAL but you can probably just ignore those. Abuse reports are very common but there's usually not much you can do other than write a message back explaining why there's not much you can do. Make sure your server provider knows that you run an exit relay! Tom
++ 19/10/14 13:53 +0200 - Tom van der Woerdt:
Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I [...] IANAL but you can probably just ignore those.
I have had exactly the same experience with valuehost.ru. At this moment I'm ignoring any automated notification I receive from them. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely. I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies. Cheers, M.
Manuel Gebauer schreef op 19/10/14 15:29:
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied : ------------------------- Hello, We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for: - TOR exit node operators will cease to think to solve this serious problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious) - TOR exit node uplinks will not notified about malicious activity in their networks Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet. ------------------------- Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ask your upstream to filter their reports if you can, I can testify I have received in excess of 300 complaints from them and ironically, they ignored all of my responses to them for the first 200 or so I responded to. Ultimately (if you'll excuse my language), they are acting like a bunch of tossers and so I am not wasting my time on them when it could be spent productively elsewhere (ie liaising with police and branching out my contacts to talk about Tor). One important thing to remember here is that they only append current Tor IP's to their abuse list. 5 of my exits have recently changed IP address and in the several days following, they are still sending abuse complaints to them when Tor isn't even running. - -T On 24/10/2014 08:16, Tom van der Woerdt wrote:
Manuel Gebauer schreef op 19/10/14 15:29:
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied :
-------------------------
Hello,
We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for:
- TOR exit node operators will cease to think to solve this serious problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious)
- TOR exit node uplinks will not notified about malicious activity in their networks
Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet.
-------------------------
Tom
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSnHiAAoJEE2uQiaesOsLmSIP/1374xBKCng09tWsaLNZ+HH5 Z0fSeBqFTTSTvAXtgrIaefs09mid9AH5iUKbGpfM3NSemRpeXjyt1/QWcYFC5HxI 2uFI1+s/7/DxwSDb5CdRMNscL2JN6VicQgL3Fy/wae1iadMLdCKM9kGw7DqGXyqM 6kMNv76tjgSueX2eBZLKAqw+SfyhCxRb5GHC5fDHKy/esN4yeuTd7ULB2x1Y2YtW yzX5nJ4s7OUJLia3F1YrjYgtNuugZVZu7bO8IFQQHqKOkyNNleYva601yLBNo2UY G5WaY0C8M9S31epsKdQ4UB/M7gJwYRICi+OHA46u0hlm1IMXsUwyXfEUIJSEbE/3 QsahnHEYikpIw39JDGV5jsZTjkMWyXpKqlhXLq2Y/YiUI67aAdndaktyXDyPSvCG YrIVJ1Zrendk9v9LzqZK+uQ1f23Hb38Z4wQOpJFuHSv9AqCaYgq+mqYe+8Lx/Ajn YDQkeM3MQQUwXkP75I1RLt61tsv9wqtu6DaOPzNawfEyLBqO8v3LQBTKy/1H+7Z8 zkuSfSsRrtLTFnBqUWrV96yMrsmRb2V5DKpda7/4Oh4oc+BFSz7w9NlUk/Txsw3M mNzGY+n9X5effGl2JHvhi332BmCKrKdGbaluE73jGuLwBuIW3whZkTFqKUr/mqz/ bboMkO6q8jHDAo3k2Dnv =P6bL -----END PGP SIGNATURE-----
On Freitag, 24. Oktober 2014, 09:16:49 Tom van der Woerdt wrote:
Manuel Gebauer schreef op 19/10/14 15:29:
Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely.
I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies.
Cheers,
M.
So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied :
-------------------------
Hello,
We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for:
- TOR exit node operators will cease to think to solve this serious problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious)
- TOR exit node uplinks will not notified about malicious activity in their networks
Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet.
-------------------------
Tom
Sounds quite "nice" to me :) -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL -----END PGP PUBLIC KEY BLOCK-----
On Sun, Oct 19, 2014 at 01:53:40PM +0200, Tom van der Woerdt wrote:
Kees Goossens schreef op 19/10/14 13:24:
Part 1: Abuse over HTTP.
Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings,
XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ
During the last 30 minutes we recorded 333 attempts like this:
XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ====
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Hi Kees,
Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I started sending the same replies but with a note "Please reply if you have read this message." - no replies. Their message mentions a contact address so I started cc'ing that address - still no reply. After replying for two months and never getting any replies, I stopped replying.
IANAL but you can probably just ignore those.
Abuse reports are very common but there's usually not much you can do other than write a message back explaining why there's not much you can do. Make sure your server provider knows that you run an exit relay!
Tom
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
++ 19/10/14 13:48 +0000 - obx:
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
That is not a sound approach: i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should and ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
Rejo Zenger wrote:
++ 19/10/14 13:48 +0000 - obx:
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
That is not a sound approach: i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should
In torrc? Really? Surely not, given that the policy is published in the exit descriptor. (I can't speak to the legalities of (ii).) ---> Drake Wilson
++ 19/10/14 08:56 -0500 - Drake Wilson:
In torrc? Really? Surely not, given that the policy is published in the exit descriptor. (I can't speak to the legalities of (ii).)
Ah, yes. I was confused with denying access to IP-space using a firewall. That is not published in the exit descriptor. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
That is not a sound approach:
I think it is.
i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should
Not nice, but better then to lose the complete exit node. Big nodes with their own reassigned IP should of course do otherwise and just move the valuehost abuse spam to /dev/null.
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
That is not a sound approach:
I think it is.
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
i remember reading somewhere [1] that if you run a server that carries mail and you don't choose where it goes or who it comes from, the server is protected from some DMCA complaints by the DMCA "safe harbor" terms (us code title 17 Chapter 5 § 512). this might only apply in the US and it may not be entirely correct, but it does lay out that if you censor where the traffic goes to or comes from, you surrender some rights. mikael ball -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJURB3OAAoJELGRAnGuhYf0RlwP/AuZMpcdoe6ZCUciBFjWJzf5 fpny8iB0ttxNGpn2LVwksBS/IjF7iTIkMruvp2MNkwCRvD/OiWXqoFJcy0hSDac2 0B1T5PvseDB9h1NX0FJDENOr+dkByzgrRWdmfgwJt2RIWLvqx/MHuM810a/ppqOm meEPZaMnCC2gD9lcMPTJpKBbsznryZFjqXciQyLDaGJ8/vOMUhipJsJcCcOCV2qe zEX/lmgtNi0oRIvXArTuAMeCx+HICyhg6owpbv2RTGUUby9+ynXiXb5upk0rUiTd /uTKJUhVky0oe8wZO7B9hvySlhYeG1Mu2CWFOY0wIQNiVSklLT/FEWL3Gwzrc8Qs U3TssC2ZQIiGdj/0oyueVJtUpNZgtWEJ2naWU91pgyNkNnmc5q6FY/R9MARBE2Kw 0jZHlm98KADSn3+DOJCk1AnLG15ZnYZAuxqpAPRZH9FzGCzIvXmFVFAbYN55uHBS c9WrrOUQc6VamVpOI9Jp3PV3hApfSF1M1JQSazNhy3kewPo5w+ixl6Vwyb24WnH/ 6JMImlpnqVyR7gDMfJVyVX7FXbPevpNFBcr8tcAuiG802REV4P2hoY9khtqyPg4C qOe9J5ZQhh5joypyaktrkp5MSaB7E33RghSCf8Lz66GqNDAPjgzDuHDgp/IuYCkk wIXk81Gxr6E4ZPWpbkfP =hJrU -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes there are safe harbour provisions. When it comes to civil issues, for example DMCA (Digital Millennium Copyright Act) issues, it is worth considering DMCA title 11 Online Copyright Infringement Liability Limitation Act (OCILLA USA Law) as the spirit of this piece of legislation is reflected in treaties with countries such as the UK and EU too. It refers to a "safe harbor" for online service providers (OSP's) liability provided they meet specific requirements. An exit node operator, assuming UK law was to abide by its treaty obligations would not be liable for holding (or transmitting unknowingly) infringing material but the statue makes clear that it must not be for financial gain. Under EU law (since in this respect US treaty law is overruled by national laws) in order for the copyright holder to successfully prosecute a criminal case or recover damages in a civil case, there must be proof of knowledge of the infringement and that the infringement was intended for commercial gain which is not the case for most exit operators. Although not directly applicable, most EU laws have common traits and developments. UK law itself is surprisingly under developed in the area of computer copyright and the Copyright, Design and Patents Act of 1988 as amended is interesting in its antiquated terminology but the law itself is quite clear on what has to be proved in a prosecution case, so simple threats of action do not mean they have a case you must answer. (some excepts above from a mail I sent ORG earlier this month) - -T On 19/10/2014 21:24, mikael ball wrote:
That is not a sound approach:
I think it is.
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
i remember reading somewhere [1] that if you run a server that carries mail and you don't choose where it goes or who it comes from, the server is protected from some DMCA complaints by the DMCA "safe harbor" terms (us code title 17 Chapter 5 § 512).
this might only apply in the US and it may not be entirely correct, but it does lay out that if you censor where the traffic goes to or comes from, you surrender some rights.
mikael ball
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJURCk1AAoJEE2uQiaesOsLShsQALCDOU4FRUcievWrkxgtq8V+ LLWC+a8bl1BAwtymf6M8vWq5tv0kTm3xWFcjhb3qu/NaZPH/C05xj06omrfvTmaH PiGlVwQFH/j8eBoaIlxaJNgbrPOnRrETxHlCS6NKJ7V5V3IRdG8QNyIPZnnyfoo2 TwmtkhGIaydA37XWLQ4jdGyC6ZPrPj5a6HzRPQj3vOvqeONNXB+b3yoevFGqAsM/ X2RqM2G/gBN9JOujiUVrHtFOmRgjqydKDI21upttg8lYUz7M7IiqwTe6pPPIT9K9 Rujp2GKgtej6eZeBpD/4rW1DwJ9lMUPVFtGE7lPoWDLt8+KQTpM3h0dtB8kb+rVt XLJUqegVSe2I/j+S/qba48bsdmNMzKTic+MJBCbJTjPb5rhprF2zcamIhwuWbb7n DDQv7QzcqMTy7E+OqLrG94sshJjOwnikaHjTBwwrNjbsGikwc162qPL7yVkgy2Bb UeXI1SL1iY744OvksGjqzAjECpDYMBNpxWtusALp2t9KwXsuYpnZYFUK0Ytuyxdq QjCvmZtMmSzxmrQHR5+Nfa5DhTDELqaQ0mYi02VizuskwinkneWgiW1RU5DoSQ3z sMxenBiSm5mG17Xi+JnlOdrmqbJqVs58poDv/+mMlpMaXYmXkCko0cqZxBJpsJlo M2aPDY/a6VbYqX4KZhZ3 =2ZS1 -----END PGP SIGNATURE-----
Thomas, That sounded so reasonable and persuasive that would it be a good idea to have a formal opinion written to give to server companies early on? They might still be looking at the time it takes to deal with notices or police queries but they must accept that the risks of allowing Tor are miniscule. Perhaps the way around the remaining deterrence is a Tor response 'centre' for them to painlessly redirect irritations to. Robert
Yes there are safe harbour provisions.
Already working on it (see https://trac.torproject.org/projects/tor/ticket/13421) Will involve a lot of outreach and will need to consider lots of jurisdictions but it can be done with a few volunteers over the next few weeks I feel. I may also be proposing on trac a @torproject.org email for such things so if ISPs did want to do a little fact checking they can have an easy point of contact and also allows a central place to reach out to the ISPs. I feel a central email for such things would garner more respect than the fracture groups assigned using their own personal emails. -T On 19/10/2014 23:21, I wrote:
Thomas,
That sounded so reasonable and persuasive that would it be a good idea to have a formal opinion written to give to server companies early on?
They might still be looking at the time it takes to deal with notices or police queries but they must accept that the risks of allowing Tor are miniscule. Perhaps the way around the remaining deterrence is a Tor response 'centre' for them to painlessly redirect irritations to.
Robert
Yes there are safe harbour provisions.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thomas, Excellent fellow! I agree that a little more appearance of coherence would do well for us but one great strength of such ideas as Tor is the absence of formal structure and that should be retained. The idea is available to be put into practice by anyone by themselves without permission. I was thinking of a point of contact for help and information only. The qualified statement of Tor operators's legal position should stand on its own. Robert
-----Original Message----- From: thomaswhite@riseup.net Sent: Mon, 20 Oct 2014 00:19:40 +0100 To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
Already working on it (see https://trac.torproject.org/projects/tor/ticket/13421)
Will involve a lot of outreach and will need to consider lots of jurisdictions but it can be done with a few volunteers over the next few weeks I feel. I may also be proposing on trac a @torproject.org email for such things so if ISPs did want to do a little fact checking they can have an easy point of contact and also allows a central place to reach out to the ISPs.
I feel a central email for such things would garner more respect than the fracture groups assigned using their own personal emails.
-T
On 19/10/2014 23:21, I wrote:
Thomas,
That sounded so reasonable and persuasive that would it be a good idea to have a formal opinion written to give to server companies early on?
They might still be looking at the time it takes to deal with notices or police queries but they must accept that the risks of allowing Tor are miniscule. Perhaps the way around the remaining deterrence is a Tor response 'centre' for them to painlessly redirect irritations to.
Robert
Yes there are safe harbour provisions.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
that meant Being part of Tor the ideal is available to anyone just by downloading and running it. Robert (you can't imagine how much I envy Roger Dingledine's clarity of expression)
++ 19/10/14 16:13 +0200 - Manuel Gebauer:
ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node.
Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally.
First: I was discussing a situation where the policy doesn't get published in the descriptor. For example, one is iptables to deny access to some IP-space. This is of course different from configuring this rejection policy in the Tor configuration file. As for the responsinilty: I was referring to the e-Commerce directive in the EU. Article 12 says: "Where an [...] service is provided that consists of the transmission in a communication network of information [...], Member States shall ensure that the service provider is not liable for the information transmitted, on condition that the provider [...] does not select or modify the information contained in the transmission." I would says that if an operator rejects traffic using iptables, he does do selection of information contained in the transmission. Of course, this is different when configuring the rejection in the Tor configuration that gets published. As far as I know, there is no case law, so results may differ. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
Thanks, Rejo (and others) for elucidating the point. I now get your line of thought. I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information. Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility. I'd rather pessimistically guess that most courts would judge tor operators in analogy to people operating private open wireless access points ...
++ 21/10/14 01:58 +0200 - Manuel Gebauer:
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information.
As the e-Commerce directive is a directive (duh!) and not a regulation, this European rules need to be transposed to national laws in each every member state. The Dutch also have their own version.
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but [...]
That's right. Like I said: there is no case law, but it would be a most interesting case. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
Manuel Gebauer <manuel@myops.de> wrote:
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information.
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed. As far as precedence is concerned, I believe that all the Tor-related raids in Germany (that I became aware of) ended with the state attorney closing the investigation (against the Tor operator) after finally realising that the offending traffic came through Tor. Fabian
I learned that the qualification "not select or modify" acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not "chose or modify" the transmitted information. [..] As far as precedence is concerned, I believe that all the Tor-related raids in Germany (that I became aware of) ended with the state attorney closing the investigation (against the Tor operator) after finally realising that the offending traffic came through Tor. [..]
Is the TMG law even used/relevant in Tor cases here in Germany? I don't have quotes or sources but if I remember correctly this specific law was never part of the closure. Renke
Hi Fabian, Quoting Fabian Keil (2014-10-21 12:55:21)
Manuel Gebauer <manuel@myops.de> wrote:
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed.
"Für ein schlecht gesichertes WLAN besteht Störerhaftung." BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link: http://tlmd.in/u/1057 I cant't of course cite missing precedence concerning tor, because it is missing.
As far as precedence is concerned, I believe that all the Tor-related raids in Germany (that I became aware of) ended with the state attorney closing the investigation (against the Tor operator) after finally realising that the offending traffic came through Tor.
Citation needed. :)
On 10/21/2014 10:29 PM, Manuel Gebauer wrote:
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed. "Für ein schlecht gesichertes WLAN besteht Störerhaftung." BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link: http://tlmd.in/u/1057
Don't confuse Internet ACCESS Providers and Internet Service Providers. Legally, they're looked at quite different. And a "wifi with bad security" does not even mean you can't offer a completely open wifi. Any layman with a bit of sense could have known that to argue that the wifi was misconfigured "by mistake" is a bad excuse. To come back to the topic, I believe it is perfectly fine to announce _in advance_ that your relay does not want to see/relay particular traffic. Then, it is not a question of interfering with traffic, since you don't see that kind of traffic at all. It's different if you stop dropping packets on purpose. -- Moritz Bartl https://www.torservers.net/
++ 21/10/14 22:29 +0200 - Manuel Gebauer:
Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility.
Citation needed.
"Für ein schlecht gesichertes WLAN besteht Störerhaftung." BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link:
A "schlecht gesichertes WLAN" is, of course, something else than a deliberately opened router. The intentions of the owner a different, for a starter. Anyway, I am not sure whether this is worth a discussion or debate on this list. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
On 10/19/2014 03:48 PM, obx wrote:
Same here, I've blacklisted their /24 in my torrc. The complaints stopped.
Did the same after I got those complaints. B/c my provider do open for every complaint a ticket I do not have another chance than doing this: reject 217.112.0.0/16:* -- Toralf pgp key: 0076 E94E
On 10/19/2014 01:24 PM, Kees Goossens wrote:
Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this.
Well, no need to give up - I made similar experiences with the reduced exit policy. Even then my provider's inbox was hammered with DMCA mails. But what worked (for me) is a further reduced policy containing ports below 1024 + few above. Said that this works for me till now: # un-comment the next line to disallow exits # #ExitPolicy reject *:* # abuse mails # ExitPolicy reject 217.112.0.0/16:* # AbuseID:11F39E:22 7th October 2014 # allowed exits # ExitPolicy accept *:43 # whois ExitPolicy accept *:53 # dns ExitPolicy accept *:80 # http ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # pop3 ExitPolicy accept *:143 # imap ExitPolicy accept *:194 # irc ExitPolicy accept *:220 # imap3 ExitPolicy accept *:389 # ldap ExitPolicy accept *:443 # http ssl ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:543-544 # kerberos ExitPolicy accept *:531 # irc/aim ExitPolicy accept *:563 # nntp ssl ExitPolicy accept *:636 # ldap ssl ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:993 # imap ssl ExitPolicy accept *:994 # irc ssl ExitPolicy accept *:995 # pop3 ssl ExitPolicy accept *:6660-6669 # irc ExitPolicy accept *:6679 # irc ssl ExitPolicy accept *:6697 # irc ssl ExitPolicy accept *:11371 # OpenPGP hkp # reject everyting else # ExitPolicy reject *:* -- Toralf pgp key: 0076 E94E
participants (15)
-
Drake Wilson -
elrippo -
Fabian Keil -
I -
Kees Goossens -
Manuel Gebauer -
mikael ball -
Moritz Bartl -
obx -
Rejo Zenger -
renke＠mobtm.com -
Roger Dingledine -
Thomas White -
Tom van der Woerdt -
Toralf Förster