- tor-relays - lists.torproject.org

Source build, then update it
by Petrusko 13 Jul '16

13 Jul '16

1 0

Exit node situation in Finland
by Nurmi, Juha 12 Jul '16

12 Jul '16

Greetings Tor Relay mailing list, I decided to write little bit about Finnish exit node situation. I am maintaining this exit node campaign in Finland: http://campaigns.ahmia.fi/finnish-tor-campaign/index_en.html In Finland: - Running an exit node is absolutely legal - ISP may cut your connection because it is listed as malware host - The National Cyber Security Center Finland (NCSC-FI) is able to "whitelist" your IP address so the ISP does not get those automated malware detections - Sebastian Mäki got police visit because his exit node - The National Bureau of Investigation is using exonerator.torproject.org so basically they are considering this information before they rush to your home - There has been warming up phase that maybe Finnish libraries start some Tor activity I am doing a lot of local advocacy work here :) Best, Juha

9 14

Re: [tor-relays] interesting tor platform string or tor bug?
by Tim Wilson-Brown - teor 11 Jul '16

11 Jul '16

> On 11 Jul 2016, at 16:27, 김성민 <dallas1004(a)gmail.com> wrote: > > Hi, I'm Ph.D. Student in KAIST, South Korea. > I'm implementing a modified Tor on top of Intel SGX CPU to improve the security issues of Tor as a research. > (Here is a related paper work [1, 2].) > For this, we port the Tor source code on the VS2012 to build an SGX project. > To make Tor running on top of SGX, we modified several lines of code of Tor and I think there is some mistake while printing a platform string. Tor shouldn't produce output like the output we're seeing, unless the platform name retrieved by tor has been localised. (Which seems unlikely, as the platform name is reported correctly some times, and incorrectly other times.) What do you get if you compile a simple program that only contains the function that retrieves the Windows platform name? It looks like you might be corrupting memory or mangling string processing. But it's very hard to help you unless we know what lines of code you changed, and how you changed them. > Currently, We successfully compiled a SGX-Tor binary and we ran it as a Tor relay for testing compatibility with existing Tor network. > We tested a Tor client with our SGX-Tor and it successfully works. > Is there any issues or rules to be considered for testing our SGX-Tor? It should pass all the unit tests run using "make check". It should pass the integration tests run using chutney and "make test-network-all". https://gitweb.torproject.org/chutney.git/ If you do find that it's a programming error in tor, feel free to submit a patch, or a unit test that would catch similar errors in the platform string. https://trac.torproject.org/projects/tor Tim > > Thanks, > Seongmin > > [1] http://ina.kaist.ac.kr/~dongsuh/paper/kim-hotnets2015.pdf > [2] http://ina.kaist.ac.kr/~dongsuh/paper/opensgx.pdf > > 2016-07-08 9:07 GMT+09:00 Tim Wilson-Brown - teor <teor2345(a)gmail.com>: > > > On 8 Jul 2016, at 09:48, Tim Wilson-Brown - teor <teor2345(a)gmail.com> wrote: > > > > > >> On 8 Jul 2016, at 09:41, nusenu <nusenu(a)openmailbox.org> wrote: > >> > >> Hi Seongmin, > >> > >> out of curiosity I was wondering whether your so called tor "platform" > >> string ("??B`?\u0001") or your tor relay [1] was generated by a modified > >> tor installation on Windows 8 or if we are looking at some bug in > >> vanilla tor? > > > > We plan on authorities rejecting descriptors with non-ASCII characters in 0.2.9, if we get it implemented before the code freeze. > > https://trac.torproject.org/projects/tor/ticket/18938 > > Hmm, I can't find an actual descriptor with these characters in it. The latest descriptor I can find for this relay has a normal platform line: > https://collector.torproject.org/recent/relay-descriptors/server-descriptor… > > Could this be a bug in Atlas? > > > > >> > >> thanks! > >> > >> > >> [1] > >> https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC3… > >> > >> descriptor containing that platform string: > >> https://collector.torproject.org/recent/relay-descriptors/server-descriptor… > >> > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > Tim Wilson-Brown (teor) > > > > teor2345 at gmail dot com > > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > > ricochet:ekmygaiu4rzgsk6n > > > > > > > > > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > > > > > Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B OTR 8F39BCAC 9C9DDF9A DF5FAE48 1D7D99D4 3B406880 ricochet:ekmygaiu4rzgsk6n

1 0

BoingBoing Says Running Exits Is No Trouble re: LEA
by grarpamp 09 Jul '16

09 Jul '16

https://boingboing.net/2016/07/01/researchers-find-over-100-spyi.html "Many people fear that running an exit node will put them in police crosshairs if it gets used in the commission of a crime. For the record, Boing Boing runs a very high-capacity exit node, and though we've received multiple contacts from US law enforcement, we've just explained that this is a Tor node that runs with logging switched off, and thus we have no information that'll be relevant to any investigations, and the officers involved have thanked us and gone away without further trouble." -- BoingBoing

3 4

dns request capitalization, tor and unbound
by ajs124 09 Jul '16

09 Jul '16

Hey, I recently started running my first two exit relays. Since it was mentioned on the mailing list a while back and seem like a reasonable thing to do, I installed and configured unbound. Afterwards, I noticed that most if not all the DNS request are randomly capitalized. Does this impact unbound's caching ability? My cache hit/miss ratio is around 1/5. What is the reason for changing the capitalization? Best regards ajs124

7 6

in/out bandwidths and packet sizes
by Toralf Förster 09 Jul '16

09 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm just curious, why at my exit relay the bandwidth is constantly around 8 MByte/sec in both directions with a 2-3% higher value for the inbound bw whereas the amount of incoming packets is 25% and more higher more than the outgoing packet amount. And as always I do have the question in mind: Would that be helpful for an attacker ? - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAleAvUQACgkQxOrN3gB26U5ReQD+MXWkaph94+xUEw5+6oD63PtL WXMdSqg+vQvFxa68XhQBAIz9ys6ifbEGUXtOCFB4BUjfdPyaa1qvS+WKKZJur/Yx =6JG/ -----END PGP SIGNATURE-----

2 1

interesting tor platform string or tor bug?
by nusenu 08 Jul '16

08 Jul '16

Hi Seongmin, out of curiosity I was wondering whether your so called tor "platform" string ("??B`?\u0001") or your tor relay [1] was generated by a modified tor installation on Windows 8 or if we are looking at some bug in vanilla tor? thanks! [1] https://atlas.torproject.org/#details/21E84B294794821E2898E8ED18402E45E4FC3… descriptor containing that platform string: https://collector.torproject.org/recent/relay-descriptors/server-descriptor…

4 8

AS: "SIGTERM MIKAL VILLA" - Linux (15)
by nusenu 07 Jul '16

07 Jul '16

Dear sigterm support, thanks for adding relays. In case you are aiming for the exit flag, you will have to add port 80 or 443 to your current exit policy (accept *:6660-6667) because 2 out of 3 ports are required to gain the exit flag, see: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2216 Should you ever add relays outside your current /16 netblock, please set the MyFamily setting properly. btw: your piwik installation wants to be taken care of https://sigterm.no/ ornetradar(a)riseup.net wrote: > 2016-07-06 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | CC | ORp | Dirp |Version | ContactInfo | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 0 | 0 |05:19:24| 193.150.121.140 | no | 9001 | 0 |0.2.5.12 | None | sigtermsupportsrv | 1 > 0 | 0 |05:20:17| 193.150.121.139 | no | 9001 | 0 |0.2.5.12 | None | sigtermsupportsrv | 1 > 0 | 0 |05:21:08| 193.150.121.141 | no | 9001 | 0 |0.2.5.12 | None | sigtermsupportsrv | 1 > 0 | 0 |06:04:26| 193.150.121.133 | no | 9001 | 0 |0.2.5.12 | None | sigtermsupportsrv | 1 > 0 | 0 |07:05:22| 193.150.121.131 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 0 | 0 |07:33:52| 193.150.121.130 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |08:14:46| 193.150.121.131 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |08:46:35| 193.150.121.132 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |08:53:18| 193.150.121.133 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |09:12:50| 193.150.121.134 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |09:36:12| 193.150.121.135 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |10:37:52| 193.150.121.136 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |11:03:56| 193.150.121.130 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |11:13:48| 193.150.121.137 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > 1 | 0 |11:44:06| 193.150.121.138 | no | 9001 | 0 |0.2.5.12 | Sigterm AS darknet server | sigtermsupportsrv | 1 > Fingerprints: > 506088E8CC79AB70A58E47D99D048E4560236B0C,0FFBA0D381CA6E8E2CA444C0F4B86C99BC228FAB,176EC54479BE0A2D700621D897B33B4AA000EE2F,C63EF61EF3615B6B14ACD5972C5EA1DA5BC7857D,D4F93347D639D8AF7A2144C94CD2196F107F4893,E6D022954AE4CA368F67633660165DADDA95C62B,9919526DCACE9B1D117978FD698E160457C9DA56,197B3FC47FD5C8F22929C7076FF0E66815DC044A,798DFE9B219E2CE0E737447EAF388320EACCFE8A,E8F1959686700D522B931255288887F7087643BD,038C5BD680C5101AB0E2E43DFD178FD2B3AACF97,46DDFEACB49429EC6664248223FDEED712E71BBB,010D54F9C9047768E7FA8C835EFC01BCF379106D,799B19EF0F409CF237EA53FC636FA5FCBB779912,662142681939C03F3A17A1D8C6BDA8AF362A5E81 >

1 0

suspicious relays
by yandereson＠riseup.net 07 Jul '16

07 Jul '16

Hello, I check torstatus/atlas regularly and this was showing up : https://atlas.torproject.org/#search/Relay127001 i just thought i report it here. good day!

15 21

Re: [tor-relays] VPS for Exits
by tor relay 07 Jul '16

07 Jul '16

> Well, I'm still sticking with CoolHousing/Virtual Server Lite because I hardly ever get abuse > complaints. For ITL, I may leave after my term expires. > But a few other companies I found were: > https://hostmaze.com/ tested it, made really bad experience with them, network performance was almost unusable <10MBit/s lately, they had an outage of 2 days ("because voxility upstream added two new uplinks", than I canceled) > https://blazingfast.io/ made also bad experience with them, like "fatal" said, their network performance isn't the best <20MBit/s (per direction) weekly average If anyone can recommend any other hosters, please come forward.

7 9

Darknet Shenanigans [was: suspicious "Relay127001" relays]
by grarpamp 07 Jul '16

07 Jul '16

On 7/6/16, Roger Dingledine <arma(a)mit.edu> wrote: > In this > case we actually found these relays misbehaving (accessing onion https://boingboing.net/2016/07/01/researchers-find-over-100-spyi.html http://motherboard.vice.com/read/over-100-snooping-tor-nodes-have-been-spyi… https://www.defcon.org/html/defcon-24/dc-24-speakers.html#Noubir https://motherboard.vice.com/read/the-booming-and-opaque-business-of-dark-w… https://motherboard.vice.com/read/dark-web-drug-dealers-are-making-sloppy-m… All quite expected and well known ever since the dawn of overlay networks. Same with the Internet.

4 3

which DirPort should be advertised ?
by Toralf Förster 05 Jul '16

05 Jul '16

3 4

More than one instance with Debian Jessie
by Patrick ZAJDA 04 Jul '16

04 Jul '16

Hi, With Debian Jessie and systemd, we can have multiple instances of Tor. But I cannot find any documentation about how to do that. Can someone tel me where to find some documentation (and not an alternative to have multiple instances). please? Else, can someone explain me how to do that if there is not documentation? Thanks and best regards. -- Patrick ZAJDA

8 30

why are so many OR connections closed with IOERROR ?
by Toralf Förster 02 Jul '16

02 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do run a Tor exit relay under a 64 bit hardened Gentoo as OS and do wonder about a Trac issue reported in [1]. About 2/3 of all closed onion connections returns IOERROR instead of DONE as seen using [2]. That's why I'm asking here if other made a similar experience under a different OS ? [1] https://trac.torproject.org/projects/tor/ticket/13603 [2] https://github.com/toralf/torutils/blob/master/err.py - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAld32PcACgkQxOrN3gB26U4B5AD+KiugVV97Fsxe0OdbcSXSl+SX yvdc8IolpZ8WwvInc/sA/1rKZDJ3X2BUCnANQClAKGb8uTPJ3243cVudACOc79kK =3/d+ -----END PGP SIGNATURE-----

1 0

Thoughts on a meta-package for bridges?
by Nima Fatemi 30 Jun '16

30 Jun '16

Hello relay operators, I just started a thread about the usability of running different bridges on tor-dev@ and would appreciate some feedback from bridge operators. Though for the sake of better communication, I decided to avoid cross posting and only send it to tor-dev@. This is more of a FYI post to let you know this thread exists: https://lists.torproject.org/pipermail/tor-dev/2016-June/011159.html Looking forward to hear your thoughts on tor-dev mailing list. Best, -- Nima 0X58C4B928A3E218F6 | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

1 0

Re: [tor-relays] [tor-talk] Unrecommended old 0.2.4.x and 0.2.5.x versions
by nusenu 30 Jun '16

30 Jun '16

(replying on a (more) public list) Roger Dingledine wrote: > I just removed > "0.2.4.23,0.2.4.24,0.2.4.25,0.2.5.8-rc,0.2.5.9-rc,0.2.5.10" > from the set of Tor versions that moria1 recommends as acceptable. glad to see this move and looking forward to the day where 0.2.4.x relays (currently at 7.8% cw) will no longer be included in consensus and all these short lived "default" windows bots disappear with it http://article.gmane.org/gmane.network.onion-routing.ornetradar/1452 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1449

1 0

Usability Improvements for Atlas (was Re: Globe is now retired)
by Iain R. Learmonth 30 Jun '16

30 Jun '16

Hi All, On 29/06/16 09:56, Karsten Loesing wrote: > tl;dr: Globe is now retired in favor of an improved Atlas. Atlas is improved, but I'd like to improve it further. I've been tackling #6787 looking to improve the homepage and make Atlas easier to use for someone that isn't already a Tor expert. The changes I'm proposing in my fix for #6787 [1] do make some noticeable UI changes and I just want to gather some opinions on whether or not Atlas users feel that this is taking it in the right direction. The "Top 10 Relays" page was added to Atlas in order to make sure that functionality was not lost when shutting down globe. (See #5430 [2]) In my proposed patch, I'm also adding an "Authorities" page and adding text to both of these pages to explain what you're seeing. These are linked from the homepage, and from the top navbar. I'm also moving the introduction and explanation of the Atlas features from the About page to the homepage and introducing a new Help page that explains the details that are found in the relay details pages. You can find a live example of this patch at: https://irl.github.io/atlas/#/ and a full list of changes are detailed in #6787. Please let me know if you can see any reason to not merge this, or if you have any suggestions for small changes before merging. Thanks, Iain. [1]: https://trac.torproject.org/projects/tor/ticket/5430 [2]: https://trac.torproject.org/projects/tor/ticket/6787

5 14

Bridge torrc custom + socks
by Petrusko 29 Jun '16

29 Jun '16

Hey, Starting to set up some Bridges behind some routers, if possible at several locations. Since last time, I've found some useful informations, but I'm not 100% sure if torrc config is ok. So the goal is : - bridge - obsfproxy to help censored people - SOCKS available for LAN computers, to redirect traffic to Tor Here the torrc file I've tuned : ####START#### SocksPort 192.168.1.10:9050 #LAN IP SocksPolicy accept 192.168.1.0/24 #Socks available for LAN computers SocksPolicy accept 127.0.0.1 #Socks available for localhost too SocksPolicy reject * Log notice file /var/log/tor/notices.log ORPort 10000 Address x.x.x.x #WAN IP Nickname Test01 #name of the bridge node ContactInfo me(a)mail.com DirPort 10001 ExitPolicy reject *:* BridgeRelay 1 PublishServerDescriptor bridge AuthoritativeDirectory 1 BridgeAuthoritativeDir 1 ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed ServerTransportListenAddr obfs3 0.0.0.0:10002 ExtORPort auto ####END#### In the router/box, I'll open/forward those 3 TCP ports from the WAN to the LAN server IP : ORPort : 10000 DirPort : 10001 Obfs : 10002 Test with a LAN client Firefox connecting with Socks is ok, IP seen is a Tor exit... Torcheck says the current browser is using Tor. But how to know if censored people can use this bridge ? (I'll test it from an open wifi hotspot in future...) Is this one is available in the list at bridges.torproject.org ? I see some log lines about stats files... where will it possible to check this bridge utilization ? If someone wants to correct this torrc file, please don't hesitate ! Is there something to add, to remove ?! Another eye is always cool to be sure ! Many thx for your lights :) -- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

2 3

If you get weird crashes, that might be why
by pa011 26 Jun '16

26 Jun '16

On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message: [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: OpenSSL 1.0.1t 3 May 2016). Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now? Could anyone please give some help - or is there none? Thanks Paul

4 4

Re: [tor-relays] Tor Weather has been discontinued
by l3thal.injecti0n＠gmail.com 24 Jun '16

24 Jun '16

If tor weather isn't running, and tshirt emails aren't being sent out, is someone doing this manually then? How can I help get the show on the road? Not gonna lie, I was really looking forward to the tshirt email as my relay definitely should have earned one about 2 weeks ago. haha. Actually I just donated $100... maybe now I can get a tshirt? https://atlas.torproject.org/#details/1F45542A24A61BF9408F1C05E0DCE4E29F2CB…

8 15

Multiple fingerprints for same IP:Port combo
by simon 22 Jun '16

22 Jun '16

Hi, Is it possible to have multiple Tor-nodes (with different keypair and fingerprint) at the same IP-Port combination? Or does that not work with the Directory implementation? The idea would be to have nodes under an anycast IP, because the anycast network has a lot of unused capacity. Another possibilty is to replicate the same node and re-use the same keypair in multiple physical locations for the same anycast IP, but I'm not sure this is a good idea. Simon

2 1

Opt-In Trial: Fallback Directory Mirrors
by Nick Mathewson 22 Jun '16

22 Jun '16

TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in! We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities. Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports. For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load. We want relays that expect to be stable for the next 2 years, with: good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity. In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_d… If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.) For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.) all best wishes, & thanks for running Tor!

19 29

Relay Fingerprint Changed After Updates
by Brian Kroll 21 Jun '16

21 Jun '16

Hi All, I had a weird event happen where the fingerprint of my relay changed after updates to the OS. The host is running Debian 8.3 and the Tor version was at 0.2.7.6 at the time of update. Apt was used to update packages and the following packages were installed/upgraded. libapt-inst1.5:amd64 (1.0.9.8.3) libssl1.0.0:amd64 (1.0.1t-1+deb8u2) libidn11:amd64 (1.29-1+deb8u1) libtasn1-6:amd64 (4.2-3+deb8u2) libxml2:amd64 (2.9.1+dfsg1-5+deb8u2) libcairo2:amd64 (1.14.0-2.1+deb8u1) libexpat1:amd64 (2.1.0-6+deb8u3) libglib2.0-0:amd64 (2.42.1-1+b1) libgdk-pixbuf2.0-common (2.31.1-2+deb8u5) libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u5) libgtk2.0-common (2.24.25-3+deb8u1) libgtk2.0-0:amd64 (2.24.25-3+deb8u1) libgtk2.0-bin (2.24.25-3+deb8u1) libnettle4:amd64 (2.7.1-5+deb8u1) libhogweed2:amd64 (2.7.1-5+deb8u1) libksba8:amd64 (1.3.2-1+deb8u1) apt-utils (1.0.9.8.3) libxapian22 (1.2.19-1+deb8u1) locales (2.19-18+deb8u4) openssh-client (1:6.7p1-5+deb8u2) openssh-sftp-server (1:6.7p1-5+deb8u2) openssh-server (1:6.7p1-5+deb8u2) openssl (1.0.1t-1+deb8u2) After the updates completed I checked on the status of the relay and noticed that it was not running and started the Tor process again. After starting the process the fingerprint changed. My relay BrownLine was 9504CB22EEB25D344DE63CB7A6F2C46F895C3686 and now after updates is 9C8A123081EFBE022EF795630F447839DDFDDDEC. I have looked through Tor logs and can find nothing of value but heartbeat notices. I have also reviewed system logs and can find nothing out of the ordinary. Any thoughts on this? Any help would be appreciated. I will also open a bug report if needed. Thanks! //Brian

2 1

Handling abuse - like to get your help please
by pa011 21 Jun '16

21 Jun '16

As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it? Thanks, Regards and a nice weekend. we have detected abuse from the IP address xxx.xxx.xxx,xxx, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was automatically generated. Note: Local timezone is +0200 (CEST) /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:50 +0200] "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:51 +0200] "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:52 +0200] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 290 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"

13 18

[warn] eventdns: All nameservers have failed
by pa011 20 Jun '16

20 Jun '16

Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour. The /etc/resolv.conf contains # Generated by SolusVM nameserver 8.8.8.8 nameserver 8.8.4.4 Is it really best to set only one DNS like specified here https://trac.torproject.org/projects/tor/ticket/11600 ? Or are there better working solutions?

4 3