Chapter 10. Summary of the tools and a final survey

The picture shows how all these tools work together. snort watches the Ethernet wire for suspicious traffic and reports alerts to sockserv which forwards them to servsock. This program writes the alerts together with the payload in a database.

The program fpg can be used to generate traffic on the ethernet which should raise alerts within snort. These alerts are written to the unix domain socket /tmp/snort where sockserv reads them.

One thread of sockserv reads in these alerts whereas the second thread sends the alerts via TCP (port 1234) to the central sever. All alerts are buffered to account for bottlenecks in the chain.

On the central sever the master process of servsock waits for new incoming connections from remote sensors. If a new conncetion is established a process is forked off to handle this commmunication.

One thread is of this process receives the alerts and stores them in a memory buffer. The second thread takes these alerts out of the buffer and stores them via an unix domain socket in the database. On alerts with a high priority the details and ID of this event are written to the unix domain socket /tmp/alert.

The program alert reads this alert informations and collects them. On a periodically basis or if a given number of alerts is reached this information is send via email to a list of recipients.

If there are too many buffered alerts within servsock a drop functionality is activated. If the HighWater mark is reached then as many alerts are written and dropped as many to /tmp/drop until the LowWater mark is reached.

The program drop reads these alerts and collect them. It works like alert but does not store the database ID since these alerts are not part and will not be part of the database. If the sending of mail fails for several times these alerts are written to stdout or syslog so no alerts should be lost. This behaviour is different to alert which would simply delete these alerts [2].