Thank you for your help. Is there some way for me to prevent nginx or thw "www-data" user from sending out any data except through 127.0.0.1:9050 (or whichever port it is that I have to use)? An iptables rule?
On 8 December 2012 10:17, <[email protected]> wrote: > Send tor-talk mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-talk digest..." > > > Today's Topics: > > 1. Re: about tor entry node (esolve esolve) > 2. Re: about tor entry node (Julian Yon) > 3. Bandwidth in TOR (Maimun Rizal) > 4. Re: about tor entry node (Sebastian G. <bastik.tor>) > 5. Re: Bandwidth in TOR (Moritz Bartl) > 6. Re: Bandwidth in TOR (Sebastian G. <bastik.tor>) > 7. Re: Securing a hidden service (Eugen Leitl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 8 Dec 2012 01:23:53 +0100 > From: esolve esolve <[email protected]> > To: [email protected] > Subject: Re: [tor-talk] about tor entry node > Message-ID: > < > caeycsr4xv-zty1pgoysuuhxwdvugjhfyjr2hgdi1zkly3ne...@mail.gmail.com> > Content-Type: text/plain; charset=GB2312 > > what I meant is: > > Let me say that an attacker controls some nodes. At a certain time, one of > the controlled nodes is used as entry node by a tor client, if the > attacker doesn't know that the node is used as entry node, then the > attacker can't identify the client. Even if it examines the IP addresses of > the lists of relays, the suspicious IP may belong to a client or a bridge. > > so why tor designer let the attacker know when a controlled node is used as > entry node? > > > > 2012/12/7 Sebastian G. <bastik.tor> <[email protected]> > > > esolve esolve: > > >>> besides, why do Tor designers want to let the entry node know that it > > is > > >> an > > >>> entry node? > > >> > > >> Generally: > > >> Entry nodes get the Guard flag so clients know among which nodes they > > >> can pick as their entry points. (Currently three entry guards, that > > >> might change in the future) > > >> > > > --------------------------------------------------------------------- > > > you meant each client can only have 3 entry guard candidates? > > > > A tor client picks three entry guards from the list of relays which got > > the guard flag. The client sets an expiry time from 30-60 days; after > > which it picks again. (It may do that earlier if Guards go down) > > > > > how many entry guards are there in the whole tor network and how are > they > > > allocated? > > Around 900 entry guards out of 3000 relays. > > > > See this graph: > > > > > https://metrics.torproject.org/network.html?graph=relayflags&start=2012-09-08&end=2012-12-07&flag=Running&flag=Guard&granularity=day#relayflags > > > > > can entry guards be used as normal relay nodes? > > > > Yes entry guards can be at any position in a circuit (if it also got the > > exit flag). (Middle relays are just relays without guard and exit flags) > > > > >> > > >> On each case: > > >> The Tor network is public (beside the bridges) so you know every node > > >> and therefor their IP addresses. Every IP that connects to you, which > is > > >> not in the list of IP addresses you know, has to be either a client > or a > > >> bridge. > > >> > > > -------------------------------------------- > > > actually there are many good conference papers presume that the > attacker > > > takes control of an entry node and exit node, then blabla..... > > > > > > so maybe their assumptions are just wrong at the beginning!? > > > > > > > As much as I hope that they would be wrong... they are not. At least not > > to my understanding. If someone, that might be the relay operator that > > controls both entry and exit of a given circuit, or an adversary that > > can look at the traffic of them, can see both ends he can correlate the > > traffic. Based on timing information and traffic volume, for example. > > > > Low latency networks such as Tor suffer from traffic correlation, which > > has not been defeated yet. As far as I know this would be very hard to > > accomplish, if at all.. (I'm not experienced enough with this topic.) > > > > Entry Guards are one attempt to minimize the risk of being exposed to > > traffic correlation. If the client picks three guards that are honest > > (good guards), an attacker won't be able to correlate traffic, while it > > would be more likely to pick a bad entry point if entry guards wouldn't > > have been invented/introduced. (While there still is the case that a > > client can pick bad guards) > > > > To avoid building circuits over nodes that are controlled by the same > > operator, operators can set a "Family" for their nodes, so the Tor > > client would not pick them for the same circuit (also everything in the > > same /16 IP block). Obviously the relay operators have to be honest as > > this is an optional torrc setting and if your are a bad guy I guess you > > wouldn't set it. (The other way around is not true; if it is not set > > although it would be correct doesn't mean the relay operator is a bad > guy) > > _______________________________________________ > > tor-talk mailing list > > [email protected] > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > > > ------------------------------ > > Message: 2 > Date: Sat, 8 Dec 2012 04:32:36 +0000 > From: Julian Yon <[email protected]> > To: [email protected] > Subject: Re: [tor-talk] about tor entry node > Message-ID: <20121208043236.6b7f57c1@numenor> > Content-Type: text/plain; charset="us-ascii" > > On Fri, 07 Dec 2012 23:23:17 +0100 > "Sebastian G. <bastik.tor>" <[email protected]> wrote: > > > Low latency networks such as Tor suffer from traffic correlation, > > which has not been defeated yet. As far as I know this would be very > > hard to accomplish, if at all.. (I'm not experienced enough with this > > topic.) > > There is a relatively simple strategy for mitigating correlation > attacks: decoy traffic. The problem is, the lower the latency, the more > decoy traffic you need to effectively cover the trail. And to avoid the > decoys being readily identified, a proportion of them must propagate > through the network by at least two hops. This is plausible for high > latency networks such as remailers but completely impractical for Tor, > unless available bandwidth ever significantly exceeds demand. > > > Julian > > -- > 3072D/F3A66B3A Julian Yon (2012 General Use) <[email protected]> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 230 bytes > Desc: not available > URL: < > http://lists.torproject.org/pipermail/tor-talk/attachments/20121208/b0f9abc3/attachment-0001.pgp > > > > ------------------------------ > > Message: 3 > Date: Sat, 08 Dec 2012 05:43:26 +0100 > From: Maimun Rizal <[email protected]> > To: [email protected] > Subject: [tor-talk] Bandwidth in TOR > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi All, > I confused about bandwidth in TOR, there are Bandwidth Max, Burst, and > Observed. > Where I can get information about them? > When will we use three of them? > > Thank > Regards, > MR > > > ------------------------------ > > Message: 4 > Date: Sat, 08 Dec 2012 10:32:54 +0100 > From: "Sebastian G. <bastik.tor>" <[email protected]> > To: [email protected] > Subject: Re: [tor-talk] about tor entry node > Message-ID: <[email protected]> > Content-Type: text/plain; charset=GB2312 > > esolve esolve: > > what I meant is: > > > > Let me say that an attacker controls some nodes. At a certain time, one > of > > the controlled nodes is used as entry node by a tor client, if the > > attacker doesn't know that the node is used as entry node, then the > > attacker can't identify the client. Even if it examines the IP addresses > of > > the lists of relays, the suspicious IP may belong to a client or a > bridge. > > I might be misinterpreting what you say. > > I don't know what a client does, that a relay does not do, because I > don't know the protocol well enough. (How does a relay extend the circuit?) > > For example clients and bridges can be told apart, because sometimes > bridges do things different than clients. (This is going to be resolved > where ever possible). > > > so why tor designer let the attacker know when a controlled node is used > as > > entry node? > > > > You probably have to wait for an answer... > > > > ------------------------------ > > Message: 5 > Date: Sat, 08 Dec 2012 10:39:56 +0100 > From: Moritz Bartl <[email protected]> > To: [email protected] > Subject: Re: [tor-talk] Bandwidth in TOR > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On 08.12.2012 05:43, Maimun Rizal wrote: > > Hi All, > > I confused about bandwidth in TOR, there are Bandwidth Max, Burst, and > > Observed. > > Where I can get information about them? > > When will we use three of them? > > Maximum bandwidth is the average bandwidth limit for both incoming and > outgoing traffic of a relay. "Burst" should be set to near the line > limit (and to more than "max"), specifying a maximum for short-term > bandwidth spikes if necessary/useful to the relay. > > >From the directory spec (third hit when you search for "tor bandwidth > max observed burst": > > > "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL > > Estimated bandwidth for this router, in bytes per second. The > "average" bandwidth is the volume per second that the OR is willing to > sustain over long periods; the "burst" bandwidth is the volume that > the OR is willing to sustain in very short intervals. The "observed" > value is an estimate of the capacity this relay can handle. The > relay remembers the max bandwidth sustained output over any ten > second period in the past day, and another sustained input. The > "observed" value is the lesser of these two numbers. > -- > Moritz Bartl > https://www.torservers.net/ > > > ------------------------------ > > Message: 6 > Date: Sat, 08 Dec 2012 11:00:01 +0100 > From: "Sebastian G. <bastik.tor>" <[email protected]> > To: [email protected] > Subject: Re: [tor-talk] Bandwidth in TOR > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Maimun Rizal: > > Hi All, > > I confused about bandwidth in TOR, there are Bandwidth Max, Burst, and > > Observed. > > Where I can get information about them? > > When will we use three of them? > > > > Thank > > Regards, > > MR > > A quote form the manual[1]: > > "BandwidthRate N bytes|KB|MB|GB > > A token bucket limits the average incoming bandwidth usage on this node > to the specified number of bytes per second, and the average outgoing > bandwidth usage to that same value. If you want to run a relay in the > public network, this needs to be at the very least 30 KB (that is, 30720 > bytes). (Default: 5 MB)" > > "BandwidthBurst N bytes|KB|MB|GB > > Limit the maximum token bucket size (also known as the burst) to the > given number of bytes in each direction. (Default: 10 MB)" > > "MaxAdvertisedBandwidth N bytes|KB|MB|GB > > If set, we will not advertise more than this amount of bandwidth for our > BandwidthRate. Server operators who want to reduce the number of clients > who ask to build circuits through them (since this is proportional to > advertised bandwidth rate) can thus reduce the CPU demands on their > server without impacting network performance." > > Relays observe peak bandwidth and store it in their state file. > > A relay can advertise bandwidth it doesn't even have, therefor some > authorities measure the bandwidth of relays (bandwidth scanner) > > I hope I could help you. > > For further questions or more detailed insight about this topic, you'll > most likely have to wait for other replies, since I'm unable to help you > out, most likely. > > [1] https://www.torproject.org/docs/tor-manual.html.en > > Regards, > Sebastian (bastik_tor) > > > ------------------------------ > > Message: 7 > Date: Sat, 8 Dec 2012 11:17:03 +0100 > From: Eugen Leitl <[email protected]> > To: [email protected] > Subject: Re: [tor-talk] Securing a hidden service > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Fri, Dec 07, 2012 at 09:50:32PM +0000, Aaron Brouard wrote: > > I'm trying to make my hidden service more secure. It runs on a server > > running Ubuntu 12.04.1 LTS server version. I have set up full disk > > If you can't place the service on physically distinct machines, > private (RFC1918) address space with ACL lockdown in the switches > (or at least, dedicated VLANs) you can at least compartmentalize > the application into virtual server guests (heavyweight via KVM > or lightweight via LHC https://help.ubuntu.com/community/LXC or Linux > VServer) > and firewall it on the host. > > > encryption and a basic firewall but I want to do more. If an attacker > > managed to compromise nginx or apache (whichever I decide to use), is > there > > a way I can prevent the web server from sending any data outside of the > Tor > > network? An apparmor profile or something? > > > ------------------------------ > > _______________________________________________ > tor-talk mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > End of tor-talk Digest, Vol 23, Issue 25 > **************************************** > _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
