full-disclosure - FW: Question for DNS pros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BD26CF349C38501EA50A8A40@utd49554.utdallas.edu>
From: pauls at utdallas.edu (Paul Schmehl)
Subject: FW: Question for DNS pros

--On Tuesday, August 03, 2004 09:48:59 AM -0500 Frank Knobbe 
<frank@...bbe.us> wrote:
>
> I'm seeing the same thing now. It caught my eye because of another
> oddity that occurs from those IP's and I wanted to check with you if you
> see that as well. These addresses (about a dozen IP's from China in my
> case) also send a TCP SYN packet with 24 '0x00' bytes payload to port
> 53. Seq # and Ack # are set, windows size is 2048 (although I haven't
> confirmed that with all past scans).
>
> Below is a tcpdump. See if that looks familiar :)
>
Very familiar.

> So it doesn't appear to be targeted just at UT Dallas. I start to wonder
> if other sites get hit too, but if that flies under the radar.
>
I have no doubt that would be true.  This now appears to be very deliberate 
and well planned.

> Also, there is no name server at that address, never has been. The IP
> being targeted is the global NAT IP of a firewall. All outbound
> connections come from that IP. No other IP (in a two class C range) is
> being hit.
>
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.

> This has started on a regular basis last week and seems steady:

Ours has stopped.
>
> There are about 18 sources involved, but the majority of the packets are
> coming from 218.75.110.194 (601),

Ditto

 61.135.158.28 (589), and 61.135.158.29

I don't have those two in my dumps, but I only identified 8 unique 
addresses before the probes ceased.

> (451), all three from China. All unsolicited incoming packets. Nothing
> is part of any kind of communication (i.e. response to web browsing,
> triggering web bugs, p2p, IM, etc).

Ditto
>
> Paul, were you able to find anything out about this? Do those IP's
> correlate with your captured IP's? Do you see the TCP SYN too?

Unfortunately, I wasn't capturing *all* traffic to that IP, just udp/53, so 
I can't tell you if there was any tcp traffic to it.
>
> 21:16:15.434753 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51621
> NS? . (17) (ttl 44, id 51622, len 45)
> 21:16:16.194129 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51622
> NS? . (17) (ttl 44, id 51623, len 45)
> 21:16:16.932505 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51623
> NS? . (17) (ttl 44, id 51624, len 45)
>
> 21:16:18.431546 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9949
> PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9950, len 73)
> 21:16:19.186279 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9950
> PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9951, len 73)
> 21:16:19.939409 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9951
> PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9952, len 73)
>
Mine are identical to yours.  Same host, same src port, same types of 
packets, same ttl, same len)  Whatever this is is obviously crafted from 
some sort of script.  The only thing I can think of is recon.  If someone 
has any bright ideas, speak up.

14:07:51.507129 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]
23237 NS? . (17) (ttl 48, id 23238, len 45)
14:07:52.256946 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]  23238 
NS? . (17) (ttl 48, id 23239, len 45)
14:07:53.573977 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]  23619 
NS? . (17) (ttl 48, id 23620, len 45)
14:07:53.752289 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]  23703 
PTR? x.x.x.x.in-addr.arpa. (44) (ttl 48, id 23704, len
72)
14:07:54.336206 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]  23620 
NS? . (17) (ttl 48, id 23621, len 45)
14:07:54.516745 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]  23704 
PTR? x.x.x.x.in-addr.arpa. (44) (ttl 48, id 23705, len
72)
14:07:55.087551 218.75.110.194.3847 > x.x.x.x..domain: [udp sum ok]  23621 
NS? . (17) (ttl 48, id 23622, len 45)
14:07:55.275934 218.75.110.194.3847 > x.x.x.x.domain: [udp sum ok]  23705 
PTR? x.x.x.x.in-addr.arpa. (44) (ttl 48, id 23706, len
72)

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/