RealSecure IDS signatures for SNMP vulnerabilitiesFrom: robert_david_graham (firstname.lastname@example.org)
- Previous message: email@example.com: "More MSSP Questions"
- In reply to: Tina Bird: "IDS signatures for PROTOS SNMP tests"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: robert_david_graham <firstname.lastname@example.org> To: "'Tina Bird'" <email@example.com>, firstname.lastname@example.org Date: Fri, 15 Feb 2002 17:33:41 -0800
> From: Tina Bird [mailto:email@example.com]
> According to the ISS Web site, they will be releasing
> signatures that are specific to the PROTOS test suite
The newly released RealSecure XPU contains the following signatures. As
you'll remember in my previous e-mail, the generic BlackICE "SNMP Corrupt"
signature only triggers on some types of SNMP corruption because many
implementations of SNMP accidentally send out corrupt SNMP messages. The new
RealSecure XPU helps resolve this by breaking out each of the different
types of corruption into individual signatures, allowing customers to "tune"
out non-hostile corrupted packets generated by their devices. Remember that
BlackICE and RealSecure both count "signatures" differently than most other
products; we tend to group multiple related "checks" under a single event
type; these new signatures break out each check under a separate "signature"
Some of these will trigger in normal SNMP traffic (e.g. SNMP_Long_String
will likely trigger if somebody is using RMON for packet capture, which may
be legitimate, SNMP_Null_In_String will trigger on implementations that
incorrect NUL-terminate strings). However, if you put this on a DMZ that
doesn't use SNMP, then you'll likely find a "0-day" exploit. Either way, I
would like to see events from customers -- either to write anti-signatures
to suppress known non-hostile traffic as well as signatures to separately
identify popular exploits.
Besides this XPU, ISS RealSecure has non-intrusion signatures that attempt
to "audit" network traffic. A customer might want to apply a policy that
SNMP should not be used (a good policy at this point in time). The following
three RealSecure signatures have existed for some time:
Triggers on any SNMP activity.
Triggers only when somebody is changing/reconfiguring an SNMP agent. Good if
you use SNMP for monitoring, but don't want to use it to configure devices.
You might have a policy against "clear-text" passwords ("community-strings"
are SNMP's equivalent of passwords).
These should not be thought of as "intrusion" signatures; they are disabled
in the default configuration of RealSecure.
This is a *VERY* important issue. Imagine if FTP was assumed to be free of
exploits and somebody dumped a tool on the Internet that demonstrated all
the discovered vulnerabilities all at once. This is what we are seeing here
with SNMP. Forget about IDS for a moment (people aren't quite yet hacking
it) -- instead run and disable SNMP on your devices.