[Dshield] UDP/65535 and Tcpdump Help
jgs316 at gmail.com
Fri Oct 22 18:24:47 GMT 2004
You have helped to answer the question of what, now if we could only
figure out who and why we'd be all set. The other oddity is that
other people seem to be getting them as well. Maybe an attempt to
slow things down, or maybe an exploit that we don't know about yet??
Anyway, thank you for the analysis!
On Fri, 22 Oct 2004 12:26:23 -0400, MH <procana at insight.rr.com> wrote:
> Thanks Justin for sending me your capture files.
> After analyzing the trace files some things jump out
> immediately. They look just like crafted/malformed
> DNS queries.
> Here is a representative payload snipit:
> 11ef 0035 0019 2374 71f7 0100 0001 0000 0000 0000 0000 0200 0100
> The source port is always 0x11ef (4591) and the
> destination port is always 0x0035 (53).
> The length is 0x0019 (25 bytes)
> The checksum and transaction id remain the same
> for each unique source ip address.
> Then 0x0100 would indicate a standard query and
> 0x0001 is one question.
> 0000, 0000, 0000 are answer rr , auth rr and additional rr respectively.
> However, there is no real query that follows and according to
> the fragmentation flags, this is the last "fragment".
> The fact that the fragmentation offset is non-zero is pretty strange.
> I imagine that this would be an attempt to bypass a non-stateful or
> poorly configured screening device.
> I would guess that this would be an attempt to dos a DNS server with the
> malformed query. However, I don't know of a system that would
> process these packets. It seems that most stacks would just
> discard the fragment.
> Other ideas?
> Hope this helps,
> DShield and the Internet Storm Center are sponsored by the SANS Institute.
> To learn more about current SANS training, see http://www.sans.org .
> send all posts to list at lists.dshield.org
> To change your subscription options (or unsubscribe), see: http://www.dshield.org/mailman/listinfo/list
More information about the list