[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] tor-talk Digest, Vol 23, Issue 25
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, <tor-talk-request@xxxxxxxxxxxxxxxxxxxx> wrote:
> Send tor-talk mailing list submissions to
> tor-talk@xxxxxxxxxxxxxxxxxxxx
>
> 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
> tor-talk-request@xxxxxxxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> tor-talk-owner@xxxxxxxxxxxxxxxxxxxx
>
> 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 <esolvepolito@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] about tor entry node
> Message-ID:
> <
> CAEYCsr4xV-ztY1pGoYSUuhXwDVUGJhFyJr2HGDi1zkLY3NEUuQ@xxxxxxxxxxxxxx>
> 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> <bastik.tor@xxxxxxxxxxxxxx>
>
> > 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
> > tor-talk@xxxxxxxxxxxxxxxxxxxx
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 8 Dec 2012 04:32:36 +0000
> From: Julian Yon <julian@xxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> 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>" <bastik.tor@xxxxxxxxxxxxxx> 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) <pgp.2012@xxxxxx>
> -------------- 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 <maimun.rizal@xxxxxxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: [tor-talk] Bandwidth in TOR
> Message-ID: <50C2C56E.8050002@xxxxxxxxx>
> 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>" <bastik.tor@xxxxxxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] about tor entry node
> Message-ID: <50C30946.1060700@xxxxxxxxxxxxxx>
> 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 <moritz@xxxxxxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Bandwidth in TOR
> Message-ID: <50C30AEC.8070903@xxxxxxxxxxxxxx>
> 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>" <bastik.tor@xxxxxxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Bandwidth in TOR
> Message-ID: <50C30FA1.4000600@xxxxxxxxxxxxxx>
> 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 <eugen@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Securing a hidden service
> Message-ID: <20121208101703.GH9750@xxxxxxxxx>
> 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
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
>
> End of tor-talk Digest, Vol 23, Issue 25
> ****************************************
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk