2008/4/6 Kyle Liddell <[EMAIL PROTECTED]>:
> Have you tried passing the -p option to netstat?  That should show you what 
> program/pid opened each port.
>
>
>  On Sun, Apr 06, 2008 at 10:51:47PM +0200, Julien Cassette wrote:
>  > Hi,
>  > I see many lines similar to these ones in my netstat:
>  >
>  > tcp        0      0 localhost:9050          localhost:48065
>  > TIME_WAIT   -
>  >
>
> > Is it a security issue?
>  >
>  > Regards.
>  --
>  [email protected] mailing list
>
>

Yes, I tried but obviously these sockets aren't owned by a particular program.
See http://rafb.net/p/l7Ykp653.html


2008/4/7 Duncan <[EMAIL PROTECTED]>:
> "Julien Cassette" <[EMAIL PROTECTED]> posted
>  [EMAIL PROTECTED], excerpted
>  below, on  Sun, 06 Apr 2008 22:51:47 +0200:
>
>  Please kill the crap HTML.  /That/ is a security issue, and folks aware
>  of it won't be using a (local at least) client that parses it let alone
>  spits it out, for that reason.  The raw HTML then looks like crap, as the
>  above should demonstrate.

I didn't know about this issue.
And since GMail doesn't specify that I'm writing in HTML or text only,
I just disabled advanced formatting but I'm not sure if it disables
HTML.


>  Normally you'd not have so many localhost entries, but when you run a
>  local proxy (FWIW, I run privoxy here, but not tor, so am used to seeing
>  them from that), you do tend to get more as other things run thru it.  If
>  you run a privoxy/tor chain, you'll have even more as you'll have both the
>  app/privoxy and the privoxy/tor connections, all on localhost (with the
>  tor/world connections as well, but those aren't localhost and would be
>  the same as direct app/world connections where no local proxy is used).
>
>  Then there's the connection status.  TIME_WAIT indicates a connection
>  that has been completed and mostly torn down, except the system has a
>  timeout on the final piece of the tear-down to keep anything else from
>  trying to use the same socket during the period packets may still be in
>  transit, thus keeping any potential new connection from getting mixed up
>  by packets arriving for the old one.  That's why the sent/received count
>  is zero -- the connection is already torn down and the sent/received
>  information lost -- it's just waiting for the timeout.  (This paragraph
>  may not be absolutely correct and definitely lacks detail, but it should
>  be sufficient from a security aware sysadmin's point of view, the way I
>  and presumably you approach it.  If you want technically correct, the
>  RFCs are freely available. =8^)
>

OK, thanks =)
-- 
[email protected] mailing list

Reply via email to