Managing Security with Snort & IDS Tools
by Kerry J. Cox, Christopher Gerg

The unconfirmed error reports are from readers.  They have not yet been 
approved or disproved by the author or editor and represent solely the
opinion of the reader.

Here's a key to the markup:
        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification

This page was updated September 29, 2004.


UNCONFIRMED  errors and comments from readers: 


{11}  4rd paragraph;
To end a conversation it can be done with a three-step process but
normally one half of the connection is closed by a two-step process:

FIN ACK ->
        <- ACK

Then the connection his half closed but one side is still allowed
to send data. To finish a session a second two-step process is
necessary:

       <- FIN ACK
ACK    ->

This results in a four-step process. Of course one side is allowed
to answer on a FIN ACK with a FIN ACK which will reduce it to a
three-step process.

But if one speaks about security, snort and IDS tools it should be
mentioned the right way.


{15}  Figure 2-3;
The lable "IP diagram length" is wrong. It should be something like
"total length of IP packet" or maybe "IP datagram length"


{22}  last line;
The correct snaplen for ethernet is 1514 bytes, 14 bytes are the leading
ethernet header. If the author says that "I have been burned by not capturing enough
of the packet to capture what I'm looking for." then
he should also use tcpdump -s 1514 to catch all of an ethernet packet


{24}  principal mistake regarding the whole chapter;
There is one good reason not to use Ethereal to sniff: The power of the
ethereal decoder opens a wide range of possible epxloits of ethereal due
to misbuild packets. So it is wise to sniff the traffic with tcpdump and
write it to a file. This file can be analyzed by ethereal without root
privileges. A book with focus on security should at least mention this.


{35}  2nd paragraph;
-A alert mode
... Rather than specifying the alert mode within a configuration file, you can
include it here on command line

It is important to note that if you are using -A option then all output
options of the configuration file are ignored!


[90]  4th paragraph;
telnet_decode
... It does not generate alerts and has no options.

This is wrong, you can use the "portlist" option to set a list of ports wich should be analyzed by this processor.

The default is not Telnet and FTP but the ports 21, 23, 25 and 119 or FTP, Telnet, SMTP, NNTP


{98}  10th paragraph;
encoding: ... ascii is recommended.

That is an ugly suggestion since the ascii format replaces all binary
data by a dot '.', so you may loose valuable contents. There are a lot
of higher level protocols out there where the binary data could be useful.


{98}  1st paragraph;
"Note that log includes alert information and teh alert-generating packet
information"

This is not correct, there are some preprocessor which only use the alert and not the
log facility.



{129}  2nd paragraph;
priority: <priority integer>
"The classification.config file assigns a priority of High, Medium, Low, and None"

This is not correct, as mentioned in the first line the priority is an integer. The default priorities 
are in the range form 1 to 3. A priority of 3 is low whereas 1 is high. This should be mentioned since
this order was changed in the last time.

Further: You can choose your own priority and additionally you can choose your own order, e.g. you are allowed 
to interpet 1 as a low priority whereas 15 may be high.


{151}  2nd paragraph;
The "normal" order is to check first for alerts and use then the pass
option. This is not useful so therefore here should be a hint that the
"-o" option is neccessary so that pass rules will work.