NIDS detection feasible? (Re: remote intrusion detection)

[mixter () NEWYORKOFFICE COM (Mixter)]

I've recently written some proposals as well, for detecting
stealthed, encrypted, tunneled, etc. traffic used by DDOS programs in
general... they're not complete NIDS rules, just suggestions for
establishing them... however, the real problem is that the people
lacking so much security that their hosts are compromised and
used in DDOS attacks are often not aware enough to actually use
NIDS or similar software.... here is the section about it:

IV.
How can DDOS traffic be detected by Network Intrusion Detection (NIDS)?

The mistake everyone has been making is to search for default strings of
special DDOS tools, for default values, ports, passwords, etc.
To establish Network Intrusion Detection capability in order to spot these
tools, that operate via connectionless raw packets, people will have to start
looking for general signs of DDOS traffic, signs that are obvious and
traffic that is extensively anomalous and suspicious.
There are two kinds of DDOS-generated traffic, control traffic (between DDOS
client and servers) and flood traffic (between DDOS servers and DDOS victim).
Credits to rain forest puppy, Dave Dittrich, and Axent Security Team
for providing some initial hints I needed to write this up.

Anomaly 0: This is not real "DDOS" traffic, but it can be a viable method
of determining the origin of DDOS attacks. As observed by RFP, an attacker
will have to resolve his victim's hostname before a DDOS attack. BIND name
servers are capable of recording these requests. You can either send them
a WINCH signal with 'kill', or you can specify query logging in the BIND
configuration. A single PTR type query before an attack indicates the request
was made from the attackers host, a great load of PTR type query for a
DDOS victim before an attack indicates that the flood servers have been
fed a host name and each server was resolving the hostname for itself.

Anomaly 1: Amount of bandwidth exceeds a maximum threshold that is
expected normal traffic for a site could cause. Alternatively, the
threshold can be measures in the amount of different source addresses
in the traffic. These are clear signs of flood traffic and ACL rules can be
implemented on the backbone routers that detect these signs and filter traffic.

Anomaly 2: Oversized ICMP and UDP packets. Stateful UDP sessions are
normally using small UDP packets, having a payload of not more than 10
bytes. Normal ICMP messages don't exceed 64 to 128 bytes. Packets that
are reasonably bigger are suspicious of containing control traffic, mostly
the encrypted target(s) and other options for the DDOS server. Once
(non-decoy) control traffic is spotted, one of the DDOS servers' location
is revealed, as the destination IP address is not spoofed in control traffic.

Anomaly 3: TCP packets (and UDP packets) that are not part of a connection.
The stealthiest DDOS tools use random protocols, including connection-oriented
protocols, to send data over non-connection-oriented channels. Using stateful
firewalls or link-state routing can discover these packets. Additionally,
packets that indicate connection requests with destination ports above 1024,
with which no known service is registered and running, are highly suspicious.

Anomaly 4: Packet payload contains ONLY alphanumeric character (e.g. no
spaces, punctuation, control characters). This can be a sign that the packet
payload is BASE64-encoded, and therefore contains only base64 characters.
TFN2K is sending such packets in its control traffic. A TFN2K (and TFN2K
derivatives) specific pattern is a string of repeating A's (AAAA...) in
the payload, since the buffer size is padded by the encryption routine. If
the BASE64 encoding is not used, and the payload contains binary encrypted
traffic, the A's will be trailing binary \0's.

Anomaly 5: Packet payload contains ONLY binary, high-bit characters. While
this can be a binary file transfer (traffic transmitted over ports 20, 21,
80, etc. must be excluded if this rule is applied), especially if contained
in packets that are not part of valid stateful traffic, it is suspicious
of being non-base64 encoded, but encrypted control traffic that is being
transmitted in the packet payload.

On Thu, 10 Feb 2000, David Brumley wrote:

> Hi,
> I've been working a while on a remote intrusion detection tool (rid).
> It's basically ngrep paired w/ the ability to form custom packets.  The
> idea is that you can easily configure it to search out for common hacks,
> such as a root shell on port 1524 (though TCP hasn't been implemented
> yet), stacheldraht/tfn/trinoo daemons,etc.
>
> I've released it earlier than I originally planned due to the recent DDOS
> attacks.  It's new home will be
> http://www.theorygroup.com/Public/DDOS/
>
> The site itself is still under development, but the tool is available.
> It's released opensource to anyone and everyone w/ the exception of those
> using it for illegal purposes, or for scanning others net's without
> authorization.  Though I myself cannot do anything about people using it
> when they are not suppose to, maybe it will add one more month to the
> jail sentence for whomever is responsible for yahoo, ebay, etc.
>
> FYI,
> to detect stacheldraht v4 just add the following lines to config.txt
> begin stach4
>   send icmp type=0 id=6268 data=""
>   recv icmp type=0 id=669 data="sicken" nmatch=2
> end stach4
>
> Any contributions to the source/development (since it's really rough right
> now) are greatly appreciated!
>
> Cheers,
> david
>
> --
> #+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
> David Brumley - Stanford Computer Security - dbrumley () Stanford EDU
> Phone: +1-650-723-2445    WWW: http://www.stanford.edu/~dbrumley
> Fax:   +1-650-725-9121    PGP: finger dbrumley-pgp () sunset Stanford EDU
> #+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
> c:\winnt> secure_nt.exe
>   Securing NT.  Insert Linux boot disk to continue......
>           "I have opinions, my employer does not."