[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: netstat reporting destinion IP address



On Sunday 25 November 2007 02:23:18 anonym wrote:
> On 25/11/07 02:54, Gregory Maxwell wrote:
> > On 11/24/07, anonym <anonym@xxxxxxxxxxx> wrote:
>
> >> Even though we still get as much anonymity as Tor offers and netstat is
> >> wrong in some way I really do not want this to happen. Incognito uses
> >> TorK as a control GUI to Tor, and since its "Non-Tor traffic log" uses
> >> netstat and thus will log these erroneous connections, users might freak
> >> out and think that Incognito is unsafe. In fact, that was what happened
> >> to me. Can this be fixed?
> >
> > Yes. Don't do that.
> >
> > it would be better if you were running something that sniffed the
> > network and showed the user all outbound packets that were not TOR.

Absolutely.The use of netstat for the gui (at the moment)  is intended to 
alert the user to chronic non-anonmous traffic and is flagged in the gui 
as 'Not 100% reliable'. The use-case is: OK I'm visiting this site 
anonymously but is it generating stateful traffic I'm not necessarily 
expecting? 

That log window has been there since the year dot and can definitely be 
improved on. The simplest approach I can think of is a setuid libpcap-based 
program to replace the use of netstat. The word 'setuid' rings alarm-bells 
though and I would certainly welcome advice on how much harm such a thing 
could cause. (Installing an rc.d launched daemon is very hard to do in a 
(linux)  platform agnostic way, so if someone is suggesting such an approach 
I would appreciated input on how to implement it properly).

Would libpcap capture stateless/connectionless traffic though?

>
> That would be better but my concern is mainly with TorK, and it uses
> netstat for its logs. I don't expect the average Incognito user to
> monitor netstat, but they might very well find some misleading
> information in Tork's logs (as they are very easily accessible through a
> nice GUI and all). Well, I guess this is an issue with TorK. Hopefully
> Robert Hogan (TorK's maintainer) will read this, although my problem
> might be a bit too specific to justify a fix which I guess would turn
> out much more complex than the current solution with netstat.
>

The 'real' solution is definitely still to be found. The information from 
netstat  is misleading because it is using the /proc filesystem to gather 
that's, and that's at least one level up from the packet-munging taking place 
in netfilter (according to my simplistic understanding). It will always be 
misleading. Maybe even the info from libpcap would be misleading. Could you 
try out pktstat (which I learned of on #tor and uses libpcap) and see if the 
correct info gets reported?

Another candidate is ip_conntrack, but again a root-owned daemon would be 
required. Anyone with wisdom to spare on this listening?

> > Just looking at netstat may well miss short-lived (and especially
> > connectionless) packets which are probably much more of a significant
> > real threat to the user.

Agreed. TorK tries to guard against these for the non-incognito user  by 
providing two 'fail safe' options (DNS Failsafe, and 'System Failsafe') which 
route DNS and sensitive, ecnrypted traffic respectively through Tor. The 
traffic that's routed is configurable for both options.

>
> If I'm not mistaking, Tor circuits are long-lived enough to show up (?).

The connection to the Tor server at the start of the circuit shows up there 
alright, and yes they are long-lived enough generally.

> Or are you suggesting that Tor initiates other connections as some sort
> of intermediate step (I'm certainly no expert on the inner workings of
> Tor)? Perhaps I wansn't clear enough, but the only Internet traffic that
> is allowed is made through Tor. Any way, I don't know exactly how TorK
> uses netstat to generate its log (I guess it uses --continuous which
> updates every second), but the entries in the log stay even though the
> connection has been disconnected (and netstat stops showing them).

Yes, it's intended as a record of your session, but is not retained between 
sessions and can be cleared at any time.

>
> Connectionless packets is not a problem as only TCP is allowed to leave
> the computer since UDP etc., as you pointed out, might be a real threat.


Attachment: signature.asc
Description: This is a digitally signed message part.