console-mki

Firestorm NIDS是一个性能非常高的网络入侵检测系统 (NIDS)。目前

========================================================================
Firestorm Analyst Console MkI                            Thu Dec 26 2002
Copyright (c) 2002 Gianni Tedesco. Verbatim copying of this document is
permitted in any medium provided this copyright notice is preserved.
========================================================================

Introduction
------------
This is a plan for an experimental analyst console for the firestorm
network IDS. There will be at least two re-writes after this one. The
plan is to start simple and re-factor the design over time to work
around observed problems and correct any fundamental design flaws.

Problem Specification
---------------------
The console should be a GNOME2 application. Configuration information
will be stored in GConf and program data in a hidden directory in the
users home directory. The software must be fast and reliable even on
commodity PC hardware (such as 300MHz Pentium-II with 128MB of main
memory and IDE harddisks).

The following specific problems must be solved:
 0x1. Pull data from sensors via network.
 0x2. Persistent event database.
 0x3. Display summary of each event.
 0x4. Able to filter events.
 0x5. Save selected events out to a file.

0x1. Pull data from sensors via network
---------------------------------------
 o Needs to be secure (encrypted and authenticated).
 o Sensor does not need to archive data.
 o Sensor does not need to support more than one user.

0x2. Persistent event database
------------------------------
 o Event database must be persistent between program invocations.
 o Must be free from arbitrary limits on data size since database can be
   expected to grow quite large.
 o Filters must perform well no matter how large the database grows.

0x3. Display summary of each event
----------------------------------
 o Timestamp (32bit integer)
 o Priority (32bit integer)
 o Source & Destination IP addresses (32bit integer)
 o Alert information (sid - 32bit integer, sid->name would be good too)
 o Only needs to support normal packet based alerts

0x4. Able to filter events
--------------------------
 o Filter on all displayed fields.
 o Support range filtering where applicable.
 o Support negation where applicable.

0x5. Save selected events out to a file
---------------------------------------
 o Save to elog format only.
 o elogs can be converted using firecat.

Implementation
--------------
Stormwall listens on a TCP port and secures incoming connections with
TLS. It checks the certificate of incoming connections against one
stored on disk. If it matches it waits for requests, otherwise it drops
the connection. On a download request it streams each elog file and
waits for an acknowlegment. When an acknowlegement is recieved the file
is deleted. This prevents data loss, but data can be duplicated.

The main database is a big elog file. Indexes are created on searchable
fields. Each index is a seperate file and either a hash or btree db
depending on whether ranges are required or not. Each index matches the
key to a list of offsets within the elog.

To update the elog file we simply:
 1. Append the data to the end of the main database.
 2. Acknowlege the new data.
 3. Re-create the indexes and replace them atomically

We always check indexes before beginning to make sure the index mtimes
are later than the elog mtime and we re-create any that are older.

Problems
--------
 o Databases can only grow to 2GB.
 o Database updates will become very slow.
 o Data can be duplicated if crashes or network outages occur.
 o Only one console is possible per sensor.
 o No way to tell which sensor alerts came from.
 o Only supports ELOG_ALERT events.