[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <410FF552.8020503@mchsi.com>
From: fd at mchsi.com (Mark)
Subject: FW: Question for DNS pros
Frank Knobbe wrote:
> On Tue, 2004-08-03 at 10:21, Paul Schmehl wrote:
>
>>That's interesting. The address being targeted here was *also* a firewall
>>PAT address. I'm starting to wonder if this is some sort of a recon tool
>>to get past firewalls. That would explain why they're using port 53
>>(normally open) and udp (stateless). If they get any kind of response at
>>all, they've identified a live host.
>
>
> I'm not sure it qualifies as a recon as it only hits the firewall
> address, no other address. It seems to know the exact address. It
> appears to be triggered by something that originates from our networks,
> but I wasn't able to capture anything. It may be as old as a bounce
> email a month ago, or access to a web site a month ago. The dump
> supplied was filtered on that one address over most of the night. As you
> can see there are no packets going to that address and provoking this
> traffic as a response. Considering the thing on my end started last
> week, it seems plausible that the trigger occurred around that time, or
> even earlier (as there were one or two probes over a month ago).
>
> Also worth noting is that this is on a single address within the main
> two class C's. This client also has other networks connected to the
> Internet which carry local traffic, and these do not receive these
> probes. The vast majority (of this large shop) goes through the
> redundant class C's. So the trigger appears to be rather rare and not
> wide spread. Also noteworthy is the fact that this client is pretty
> clean when it comes to viruses, so I'm ruling that out as a trigger as
> well. But something had to have happened as it is so targeted....
> hopefully through correlation we can shed some light on this.
>
> Later,
> Frank
>
I'd say I'm pretty much seeing the same thing from the following 14
addresses.
202.103.67.196 - appears in dshield
218.25.41.136 - does not appear in dshield
218.30.23.100 - appears in dshield
218.30.23.161 - does not appear in dshield
218.30.23.162 - appears in dshield
218.75.110.194 - appears in dshield
61.135.158.170 - does not appear in dshield
61.135.158.171 - appears in dshield
61.135.158.28 - appears in dshield
61.135.158.29 - appears in dshield
61.135.158.30 - does not appear in dshield
61.135.158.31 - does not appear in dshield
61.135.158.34 - does not appear in dshield
61.135.158.35 - does not appear in dshield
I was guessing it was targeting suspected DNS servers based on it seeing
queries at some point. The target is the dynamic NAT address of one of
our internal DNS servers, DNS is the only service running on that box
and the only thing that server is allowed to do to the outside world is
DNS queries. Unfortunately I don't think I'm going to be able to tell
exactly what it's trying to do without a Honeypot (Which for several
reasons I cannot set up at this address.)
tethereal -s 1500 -n -n -r DNSTCPSynWpayload.cap | more
0.000000 202.103.67.196 -> XXX.XXX.40.74 ICMP Echo (ping) request
0.772315 202.103.67.196 -> XXX.XXX.40.74 ICMP Echo (ping) request
1.495178 202.103.67.196 -> XXX.XXX.40.74 ICMP Echo (ping) request
3.039469 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
NS<Root>
3.767420 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
NS<Root>
4.592464 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
NS<Root>
6.077981 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
PTR74.40.XXX.XXX.in-addr.arpa
6.774427 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
PTR74.40.XXX.XXX.in-addr.arpa
7.480926 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
PTR74.40.XXX.XXX.in-addr.arpa
9.014256 202.103.67.196.2470 -> XXX.XXX.40.74.53 DNS [Unreassembled
Packet]##### TCP initial SYN
9.766300 202.103.67.196.2496 -> XXX.XXX.40.74.53 DNS [Unreassembled
Packet]##### with a payload
10.508395 202.103.67.196.2535 -> XXX.XXX.40.74.53 DNS [Unreassembled
Packet]##### of NULLs
12.031538 202.103.67.196.53 -> XXX.XXX.40.74.33434 DNS Standard
queryresponse, Format error
12.769536 202.103.67.196.53 -> XXX.XXX.40.74.33434 DNS Standard
queryresponse, Format error
13.541778 202.103.67.196.53 -> XXX.XXX.40.74.33434 DNS Standard
queryresponse, Format error
49.997682 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
NS<Root>
50.730448 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
NS<Root>
51.535798 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
NS<Root>
53.033250 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
PTR74.40.XXX.XXX.in-addr.arpa
53.729775 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
PTR74.40.XXX.XXX.in-addr.arpa
54.525959 202.103.67.196.2566 -> XXX.XXX.40.74.53 DNS Standard query
PTR74.40.XXX.XXX.in-addr.arpa
56.018748 202.103.67.196.53 -> XXX.XXX.40.74.33434 DNS Standard
queryresponse, Format error
56.794312 202.103.67.196.53 -> XXX.XXX.40.74.33434 DNS Standard
queryresponse, Format error
57.586551 202.103.67.196.53 -> XXX.XXX.40.74.33434 DNS Standard
queryresponse, Format error
59.025534 202.103.67.196.1854 -> XXX.XXX.40.74.53 DNS [Unreassembled
Packet]##### TCP initial SYN
59.756505 202.103.67.196.1885 -> XXX.XXX.40.74.53 DNS [Unreassembled
Packet]##### with a payload
60.506336 202.103.67.196.1917 -> XXX.XXX.40.74.53 DNS [Unreassembled
Packet]##### of NULLs
62.028318 202.103.67.196 -> XXX.XXX.40.74 ICMP Echo (ping) request
62.748992 202.103.67.196 -> XXX.XXX.40.74 ICMP Echo (ping) request
63.499533 202.103.67.196 -> XXX.XXX.40.74 ICMP Echo (ping) request
Regards,
Mark
Powered by blists - more mailing lists