Re: [tor-talk] SIGAINT email service targeted by 70 bad exit nodes
I think we are being targeted by some agency here. That's a lot of exit nodes. See above question about number of relays vs capacity of the relays -- it would be great to learn more information before jumping to conclusions. Some very dedicated jerk can probably spin up VPSes at a bunch of places, at least for a while. Hi Roger, the diversity here is interesting. My hunch is that we are looking at 38 popped boxes (IPs are according to Philipps tarball, of course most of the IPs were running 2 relays as is economical for attacks): 104.207.150.52 domain name pointer 104.207.150.52.vultr.com. 104.238.132.150 domain name pointer 104.238.132.150.vultr.com. 104.238.133.3 domain name pointer 104.238.133.3.vultr.com. 104.238.136.249 domain name pointer 104.238.136.249.vultr.com. 104.238.138.19 Host 19.138.238.104.in-addr.arpa. not found: 3(NXDOMAIN) 104.238.161.45 domain name pointer 104.238.161.45.vultr.com. 104.238.180.244 domain name pointer 104.238.180.244.vultr.com. 107.191.46.79 domain name pointer 107.191.46.79.vultr.com. 108.61.177.165 domain name pointer 108.61.177.165.vultr.com. 108.61.188.90 domain name pointer 108.61.188.90.vultr.com. 108.61.198.179 domain name pointer 108.61.198.179.vultr.com. 108.61.199.44 domain name pointer 108.61.199.44.vultr.com. 176.31.208.207 Host 207.208.31.176.in-addr.arpa. not found: 3(NXDOMAIN) 179.43.152.240 domain name pointer smtp11.sicurezza.kz. 179.43.152.247 domain name pointer hosted-ny.securefastserver.com. 185.12.46.132 domain name pointer peraz.co.nz. 185.65.201.196 domain name pointer 196.cloudlix.com. 185.77.129.133 domain name pointer hosted-by.securefastserver.com. 185.77.129.145 domain name pointer hosted-by.securefastserver.com. 185.77.129.222 domain name pointer hosted-by.securefastserver.com. 185.77.129.241 domain name pointer hosted-by.securefastserver.com. 185.92.222.53 Host 53.222.92.185.in-addr.arpa. not found: 3(NXDOMAIN) 185.92.222.57 Host 57.222.92.185.in-addr.arpa. not found: 3(NXDOMAIN) 217.172.190.19 domain name pointer atlantic691.dedicatedpanel.com. 45.63.124.58Host 58.124.63.45.in-addr.arpa. not found: 3(NXDOMAIN) 5.39.26.209 Host 209.26.39.5.in-addr.arpa. not found: 3(NXDOMAIN) 5.39.26.210 Host 210.26.39.5.in-addr.arpa. not found: 3(NXDOMAIN) 5.39.26.211 Host 211.26.39.5.in-addr.arpa. not found: 3(NXDOMAIN) 85.204.74.104 domain name pointer hosted-by.securefastserver.com. 85.204.74.120 domain name pointer hosted-by.securefastserver.com. 85.204.74.156 domain name pointer hosted-by.securefastserver.com. 85.204.74.189 domain name pointer hosted-by.securefastserver.com. 87.117.255.174 domain name pointer hosted-by.securefastserver.com. 87.117.255.187 domain name pointer hosted-by.securefastserver.com. 87.117.255.188 domain name pointer hosted-by.securefastserver.com. 87.117.255.194 domain name pointer hosted-by.securefastserver.com. 89.248.164.62 domain name pointer indohosting.info. 94.242.254.81 domain name pointer ip-static-94-242-254-81.server.lu. with least 9 hosters involved (culled from the as_name field in the descriptors); Choopa, LLC Ecatel Network Iomart OVH SAS PlusServer AG Private Layer INC QHOSTER LTD. UAB DUOMENU CENTRAS root SA The question to me is: Do they all have something in common? What was the vector of compromise? Curiously enough, they all run Debian stable (according to the SSH version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2” *ALL* of them spit out on port 22 — no exception!). Cheers, Ralf -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TOR bundle on hostile platforms: why?
On Aug 7, 2013, at 9:06 PM, Ivan Zaigralin wrote: Using Tor protects you against a common form of Internet surveillance known as traffic analysis. It doesn't, since Microsoft can survey all outgoing and incoming traffic in plain text. Tor also makes it possible for users to hide their locations while offering various kinds of services, such as web publishing or an instant messaging server. On the contrary, Microsoft has the capability to survey all Windows-powered TOR nodes and make a complete table of who is hosting what. As Tor's usability increases, it will attract more users, which will increase the possible sources and destinations of each communication, thus increasing security for everyone. Each Windows host added to the network is a TOR node which is directly under control of Microsoft. Thus adding more Windows hosts decreases the security for everyone. Hi Ivan, may I ask what you base these claims on exactly? The capability of Microsoft to perform auto-updates or is there anything else? If we're talking about auto updates, you have the same problem with essentially every Linux distro that you don't audit and compile yourself. If not, I'd love to hear what angle you're going for here. Cheers, Ralf p.s.: I'm a reverse-engineer. the argument you get binaries, not source code doesn't convince me. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Onion Sites Won't Load
On Jun 7, 2013, at 8:23 AM, Mysterious Flyer wrote: Why oh why can I not access any of the onion sites listed on the hidden wiki? They all time out. Did I do something to make the Onion Master mad? Does everyone else have the same problem? I have a typical 64-bit computer running Windows 7. Laptop-type model. Is there a trick to it? Yes, I have the Tor browser bundle. Have you made sure that your system time is properly synchronized? Cheers, Ralf ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Webserver on 127.0.0.1 only?
On 5/9/12 2:52 PM, Jerzy Łogiewa wrote: when building webserver I want only 127.0.0.1 able to connect - not the internet and not 192.168.x.x even! this is for hidden service _ONLY_ and no one even on local network should be able to probe for it. i know how to setup hidden service basically. how can i do this above with apache or lighttpd? if i want the same for ssh how can I do it using system? restrict all connections to 127.0.0.1 - and no tails please! :-D Hi Jerzy, try Listen 127.0.0.1:80 in your Apache configuration, server.bind = 127.0.0.1 in your lighttpd config and ListenAddress 127.0.0.1 in your sshd config. This makes the daemons only bind to the loopback interface. After a server restart, check with netstat that you really are not listening on any external interface: netstat -na | grep '^tcp.*LISTEN' Cheers, Ralf ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] An external application is needed...
On Mar 10, 2012, at 9:49 AM, bao song wrote: I don't think Word or Adobe Reader automatically connect external links without warning the user, but I could be wrong. Think of Word and PDF documents as potential connect-back shells; then you may understand the warnings better. -RPW ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Hidden service security w. Apache/Win32
On Feb 20, 2012, at 8:57 PM, Ondrej Mikle wrote: On 02/20/2012 05:06 PM, Ralf-Philipp Weinmann wrote: On 2012-02-19 19:58 CET, Ondrej Mikle wrote: Addendum for truly uberparanoid installation: [various best practices] With the uberparanoid installation, the greatest risk is a return-to-libc-style attack on Tor where attacker instructs Tor to make circuit to a node controlled by attacker, thus revealing IP. So this is the part where you should realize how futile all of that pain of setting up policies is… I disagree. Even without RBAC, grsecurity makes ROP-style attacks damn hard. n.b.: I wasn't commenting on the memory corruption mitigations offered by grsec, those are damn fine. Rather, what I was commenting on was the fact that RBAC is mostly worthless for the threat you are trying to address (disclosing the IP address server running the hidden service) unless you've really screwed up somewhere else. Many tricks I've seen in defeating ASLR and other anti-ROP mitigations required some side-channel knowledge. Which is where the policy can do good job at stopping the attacker to gain such side-channel information. Yes, you'll need to bake yourself an info leak to deal with grsec. Since with gentoo you compile everything with your own settings of compiler/linker and whatnot, that alone makes it hard for attacker to search for gadgets (pieces of code that can be used for ROP). I'm familiar with the technique, and agree that custom compiler/linker settings on the box you're attacking can be a PITA to deal with. Depending on the skills of the adversary, they might buy you a couple of months. Is the additional RBAC policy worth it? Depends on your threat model. I've had a server running with grsecurity RBAC enabled for experimentation several years ago. The policies took a few days to write, but that's far from unfeasible. RBAC, SELinux and App Armor (yes, I've added more clunky ways to band-aid buggy code to prevent it from spilling the lifeblood of your box) are useful for some things. I just really doubt they will buy you additional protection in the threat model we're talking about. Cheers, -RPW ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
