[Snort-users] Re: Arachnids IDS Database
vision at ...4...
Thu Sep 28 20:12:32 EDT 2000
On Thu, 28 Sep 2000, Brian Caswell wrote:
> > Anyone know if there's a mirror to the Whitehats IDS Arachnids Database?
> > It's been down for days.
> I would not be suprised if he is ... busy doing other things.
> Many people used his database and references. Arachnids was a
> great help to the security communittee as a whole. If someone did
> have a mirror of the information, I am sure that someone could host it
> until such time that Max was able to do so again.
Thanks everyone for the offers to host the information, but I have this
covered very well with plenty of connectivity with high uptime
(whitehats.com). The problem has been that I have been making huge
updates and changes to the entire database in a development mode and
failed to keep a stable snapshot on the main server. When my development
network dropped off the net last Friday (I've been offline for 6 days -
say thanks to AT&T and their crappy service!) the data was completely
unreachable. Correlation of my connectivity loss with anything else is
Early yesterday morning I used another net connection to upload a static
snapshot of the database and a new vision.conf file.
Here are some brief changes to the database that will be available when
connectivity to the dev database is restored:
o added "HasSignature" so I can add the numerous IDS events that can't
be detected in a single packet by Snort, but can be enumerated and
kept track of on the to-do list. (Example: land attack)
o added "NoSigWhy" to keep track of why certain intrusions do not have
not yet analyzed
need protocol decode/state
signature language insufficient
attack involves multiple packets
attack is covered by a plugin
o added "NoSigBackground" to leave pointers for future signature
development, tips on how to detect the attack, etc.
o added "RPCapplication", "RPCprocedure", and "RPCversion" to allow for
the easier RPC detects - existing rules cover most RPC queries, but
this simpler syntax will remove the need for those bulky content rules.
o added "EasilySpoofed" to help judge the "trust level". This will
always be YES for ICMP, UDP, or TCP where the packet is not a part of a
stream/session. It will always be NO for TCP sessions (the assumption
is that 1> the server has strong sequence number generation, and that
2> snort tracks tcp streams statefully) (note that the second
assumption is false but I will cover that in a paper to be released)
o added "AttackerNeedsResponse" to keep track of motive - the reason for
this is to help judge the "trust level" of the attack. The idea is to
help determine the liklihood that an easily spoofed probe was
authentic - if the attacker needs the response data, such as an rpc
query, it is more likely to be a valid source IP - versus something
like a denial of service attack, where the attacker could care less and
is more likely spoofed.
o added "WhyFalsePos" and "WhyFalseNeg" to better track reasons for
inaccuracy in attack detection.
o added "BlackICE", "XFORCE", "CERT", "RFC", and "MSKB" for greater
database cross-reference capability. (CVE & Bugtraq already present)
o cleaned up "Categories" to a simpler list of attack types.
o I went through each record manually setting new values in most of the
new fields above. :)
The new model I plan to implement is to populate the database with a
"complete" archive of known remote attacks, then as users see alerts for
the signatures, use these packet captures to fill in the packet trace
evidence. This is somewhat backwards from the current method of
researching vulnerabilities in more detail up front, but I think everyone
will benefit from the greater number of signatures that result.
arachNIDS is a free resource with a stable future. I have actually been
spending a huge amount of unpaid research time developing and building the
database, and it has been a very rewarding and exciting project. I hope
that the partial functionality that I have restored will tide people over
until my network outage has been resolved. I have alternate connectivity
at the lab now but it is woefully inadequate. In short, I am doing
everything I can right now and the database will be back in a new and
improved state ASAP.
More information about the Snort-users