RE: criticism of snort in articles that I can not r emember being explained or rebutted on this list. Device Discovery slash manually configuring snort.

["Cloppert, Michael" <Michael.Cloppert () 53 com>]

Jacob et al,
 
You mention reporting in here - for example, alerts triggered on port 80.
This is one of the drawbacks of snort frontends to date if you ask me, as
well: no advanced reporting.  What I've had to do, against my own wishes, is
learn SQL querying.   I have some (most likely messy and non-optimized)
scripts that will do searching for me when I need to.  For example, if I
need to generate a report on a particular IP address that I'm going to be
sending to an ISP to gripe about one of their users, I will run
./generate_report xxx.yyy.zzz.123, which prints a CSV file to stdout that I
can attach to an email for easy importing at their end to the database of
their choice.  The reason I can't simply use ACID is:
1) it's REALLY messy trying to select, copy, & paste alerts the way ACID
displays them, and
2) I don't "alert" on all of my events... there are some things I see
constantly and are usually noise, such as some of the Unicode exploits.
These things I Log, but not alert, so when I run my report, I'm really
re-scanning all of my log files for alerts from the IP address in question,
throwing them into a temporary database, then running SQL queries, then
deleting them from my temporary database.
 
This is messy, I know... but it works, and I'm not sure of a better way to
do this without alerting on EVERYTHING.  It'd be nice to see someone come up
with a tool for advanced reporting of this nature that offers flexibility, I
agree... however one of the nice things about snort is its openness so that
things like my hack-around can be done.
 
Mike

-----Original Message-----
From: Jacob, Raymond A Jr [mailto:raymond.jacob () navy mil]
Sent: Monday, November 25, 2002 8:09 PM
To: snort-users () lists sourceforge net
Subject: [Snort-users] criticism of snort in articles that I can not
remember being explained or rebutted on this list. Device Discovery slash
manually configuring snort.



Firstly, I appologize in advance if this issue has been discussed and I
missed it in 
corespondence or I just need to RTFM. 

I have seen reviews of IDS products with snort and they all mention that
snort 
requires to much manual configuration and tuning. At first, I thought there 
is a reason why you never see "Intrusion Detection for Dummies" in the book
store 
because in order to do network intrusion detection right you need to know
about 
network security so Dummies need not apply. 
I think most of the people on the list know how to read an ip packet and 
acid gives you enough of an idea to know someone is trying to hack into 
your network. 

Then after reading these reviews and all of them saying to me the say thing,
I had to ask 
myself what are these criticisms really saying. What I understand them to
say is 
that snort can not tell me what to worry about in my trusted network and
DMZ. 

    Before one can effectively monitor a network for intrusion, 
one must be able to eliminate false positives from known devices. 
At this time as far as I know this process is done manually. However, there
are tools 
such as cheops or nmap which can determine what hosts are running
webservers, 
or pop mail servers, or ftp servers... in your trusted network or DMZ. 
Information about services running on particular hosts could not only be
used 
to filter events but to raise an alert when the IDS recognizes an attack
signature 
destined for a host with that service running. 
The question is: why can not nmap or cheops be used to automatically
configure 
HTTP_Servers(?) or create rules and alerts in snort for hosts in the DMZ and
Trusted Networks 
with well known services? 

When there is a problem and server or workstation is running netbios, I ping
the ip address and 
use nbtstat to find the name of the computer. If nbtscan could be used to
identify computers 
in order to provide limited windows name resolution to the ACID names table,
furthermore the ACID(MySQL) server 
could run winbind to populate a machine, user, group table in the ACID names
table.One could argue 
that DNS will replace WINS one day. I don't know if that day will come soon.

The questions here are: 
1. If ntbscan does not use a broadcast mechanism and netbios-dgm(135) is
allowed 
to travel within the trusted network, why can't it be create an /etc/hosts
file 
to provide name resolution in snort? 
2. If winbind is run on the ACID(MySQL) server will resolving Windows User
names 
put such a burden on the ACID(MySQL) server that it can not receive
information from 
snort? 


ACID has a great schema however the tool is very limiting and does not
provide information to me 
in a useable format. I must generate a text file and run a perl or sed
script to generate a report 
to get useful information. 
For example, I would like to look at the information 
in three ways: First, I liked to determine the total number of alerts with
dest. port 80 from source network with a class

C network mask. Second I would list by source ip address and network
destination address(i.e. And ip 
address with class mask or just convert to string and replace last octet
with 0.) the number of alerts. 
Third, when the total number of alerts for a particular alert was over 80, I
would try to resolve the ip address 
into a name. ACID does not provide this ability as far as I know. 
The question here is (I will admit that talk is cheap and I don't know the
amount of effort involved) 
that there is a need for a daily, weekly, monthly,..,long term trending IDS
management station for professional network 
security analysts. Will acid evolve into this tool? 
Conversely, at the low end and for wide deployments where there are no
professional network security analysts. 
One needs what I call a trained monkey IDS alert station with christmas 
tree lights. Basically this consists of a table with cells or a tree with
branches 
that turns green, yellow, and red depending on the 
serverity and number of network events. The user clicks on a light, a
description of the event pops up 
with the source address, the port, and destination network. I don't know
what type of ids alert 
tool -i.e. professional or trained monkey- should be included in snort. I
will tell you that  there are many 
organizations that bought earlier versions of ISS and figured it is a GUI so
we don't need a qualified 
person to run it. ISS was basically brain dead back then - i.e. no packet
dumps- so you either went 
brain dead trying to run it or just ignored it. 

Lastly and although this was not mentioned in the reviews, there is a big
push to combine alerts/denials from all network

security devices i.e. routers, firewalls, and IDS's. Meaning that at some
point in time logsnorter may have to 
become part of the basic snort package. 



In conclusion, it is my opinion that commercial customers want no brainer
solutions because either 
they don't have or can not afford professional network security analysts.
This is the customer 
the trade magazine and journals are writing for. This means that I hope
snort becomes 
an network detection system composed of an engine, management console, and
alert station 
to insulate the untrained security analyst while providing the tools that
the 
professional analyst needs to be productive. 
However, until snort becomes a no brainer the reviews will continue to
portray snort as the 
cinderella of IDS's. The problem with bad press is that some managers don't
know enough 
to objectively decide on what solution is best for the organization and
proprietary vendors 
in their sales pitch will say that snort is too difficult to configure and 
our product won an A+ from .... magazine. I appologize for this distracting
email. I just 
get the sense that everyone is so wrapped in the technology that we forget
that everyone 
is not like the users on snort-users. That is why no one asked the question
why snort is 
always reviewed with a negative spin, i.e. Snort it is great, but... 

Respectfully, 
Raymond 
PS: These thoughts are my own definitely not my employers.