[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Kyle Maxwe ll (Detect 1)

[Adams, Samuel (contractor)]

Some questions below...

-----Original Message-----
From: intrusions-bounces at lists.sans.org
[mailto:intrusions-bounces at lists.sans.org]On Behalf Of Kyle Maxwell
Sent: Sunday, July 25, 2004 8:49 PM
To: intrusions at incidents.org
Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Kyle Maxwell
(Detect 1)

Based on other alerts seen in analyzing the original log file (e.g.
inbound connections to TCP ports 515 and 6346), it is conjectured that
there is no firewall in place protecting the 46.5.0.0/16 network, or
at least such a firewall has an extremely permissive rule set.
Further, all packets in the file the same MAC addresses 0:0:c:4:b2:33
and 0:3:e3:d9:26:c0 (no results were returned from "/usr/sbin/tcpdump
-ner 2002.6.16 |awk '{print $2"\n"$3}'|grep -v "0:0:c:4:b2:33" | grep
-v 0:3:e3:d9:26:c0"). Both MAC addresses belong to Cisco Systems,
Inc., suggesting that the IDS sensor was monitoring a link between two
Cisco routers, though one or both may also have been a PIX firewall or
similar.

What makes you think that one of these systems isn't providing firewall
protection? Did you see responses to these inbound connections on ports 515
and 6346?

(2) Detect was generated by:
Snort 2.1.3 (build from dag repository) running on Fedora Core 2. The
rule that triggered this alert was:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS named version
attempt"; content:"|07|version"; offset:12; nocase;
content:"|04|bind"; offset:12; nocase; reference:arachnids,278;
reference:nessus,10028; classtype:attempted-recon; sid:1616; rev:6;)

In particular, the rule triggers based on the presence of <07>
followed by "version" beginning at the 13th byte in the packet.
Do you know why the |07| was incorporated into the signature? Is that always
part of a DNS packet or does it mean something else? 

(3) Probability the source was spoofed:
It is unlikely (though possible) that the source was spoofed; although
the packet was a UDP datagram (thus making it a connectionless
attempt), the activity is apparently a reconaissance attempt (see part
4 of this detect analysis below) and thus the attacker would need to
see the result for the activity to be of any use to him. It's
possible, however, that this is not the actual address of the source;
the true source could potentially be anywhere along the route to
203.107.136.44 or on the same subnet, in which case the attacker could
generate a packet with the spoofed address and observe the reply in
transit.

Were there other version queries from different sources? Sometimes an
attacker will disguise his origin by burying it in a blizzard of similar
spoofed reconnaissance. Any evidence of that here? 
Cheers,
Sam