1 Sep 2007 05:01
bizarre connection list to tor's DirPort
Scott Bennett <bennett <at> cs.niu.edu>
2007-09-01 03:01:21 GMT
2007-09-01 03:01:21 GMT
Using netstat or lsof, there are sometimes over 50 ESTABLISHED connections
to my tor server's DirPort from a single IP source address, which resolves to
ignfwdnoi-nat.asia.csc.com
Each such connection is usually displayed by netstat to have at least 32500
bytes in the send queue.
I've checked the current cached-routers and cached-routers.new files and
have found no sign of either ignfwdnoi-nat.asia.csc.com or its IP address
(20.139.66.64) in either file, so it doesn't appear to be a valid exit server,
from which directory fetch requests might be appearing.
Does anyone have an idea what might be going on? I.e., is it something
legitimate? Or should I treat it as an attack of some sort and respond by
blocking packets from that system at my router?
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Not only that, but he posted it
twice, once as plain, ASCII text (correct) and once as HTML (inappropriate
for a mailing list). Nevertheless, I do appreciate the quick response.
On Fri, 31 Aug 2007 21:24:43 -0700 "Kyle Williams"
<kyle.kwilliams <at> gmail.com> wrote:
>sounds strange
Yes, indeed.
>
>If it was my connection, I would fire up a network sniffer and see what's in
>those requests.
My guess is that they would appear to be perfectly normal requests for
directory updates/downloads coming in and the appropriate directory information
in response going out. The individual connections appeared to be fairly
ephemeral. My thoughts ran along the lines of a DoS attack by attempting to
tie up server bandwidth by downloading lots of the same information repeatedly.
If so, then the attempt never came close to the bandwidth capacity, but it used
enough of it to attract my attention.
>If it continues and you don't feel comfortable with it, filter out that IP
>on your firewall.
A few minutes after I posted the query, I decided to block all packets
from that address, at least until I got some other opinions from this list.
>
>If you do see something unusual in those request, could you be so kind to
>post a dump file (pcap format) of the traffic (filtered by that IP of
>course) so the rest of us can take a look? :)
>
Unfortunately, I can't. Around 1 a.m. CDT, my ISP apparently swapped out
their backup server for their main PPPoE (CHAP?) server, which had been damaged
in the recent floods. When they did that, they broke all existing TCP
connections, and I had to restart my local DSL modem/router, which resulted in
a different IP address being assigned. Sigh. TBC Net isn't very good about
continuity of IP address assignment, as compared to, say, Comcast, which does
occasionally assign different addresses. They both do it after outages like
this situation, but TBC is apt to do it with any new link up session. So I
changed the address in torrc to the new one and SIGHUPped the server, but it
will likely be 12 - 24 hours before the new address gets around widely. The
offending site likely doesn't have it yet, and I'm thinking I should leave the
filter rule in place on the router for tonight, so I don't have to stay up all
night to watch for a recurrence.
>
>
>On 8/31/07, Scott Bennett <bennett <at> cs.niu.edu> wrote:
>>
>> Using netstat or lsof, there are sometimes over 50 ESTABLISHED
>> connections
>> to my tor server's DirPort from a single IP source address, which resolves
>> to
>>
>> ignfwdnoi-nat.asia.csc.com
>>
>> Each such connection is usually displayed by netstat to have at least
>> 32500
>> bytes in the send queue.
>> I've checked the current cached-routers and cached-routers.new files
>> and
>> have found no sign of either ignfwdnoi-nat.asia.csc.com or its IP address
>> (20.139.66.64) in either file, so it doesn't appear to be a valid exit
>> server,
>> from which directory fetch requests might be appearing.
>> Does anyone have an idea what might be going on? I.e., is it
>> something
>> legitimate? Or should I treat it as an attack of some sort and respond by
>> blocking packets from that system at my router?
>>
>>
>> Scott Bennett, Comm. ASMELG, CFIAG
[duplicate .signature and much HTML crap deleted --SB]
>
Thanks for the reply, Kyle. Tomorrow I may remove the filter rule to
see what happens. If the problem recurs, I can try tcpdump on that port to
see what's going on, but it's probably all according to the accepted directory
service protocol.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
RSS Feed