[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IDS: RE: Food for thought...
[ The following text is in the "iso-8859-1" character set. ]
[ Your display is set for the "US-ASCII" character set. ]
[ Some characters may be displayed incorrectly. ]
Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner@uow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo@uow.edu.au
-----------------------------------------------------------------------------
This is exactly the idea presented in:
http://phrack.infonexus.com/search.phtml?view&article=p56-11
Cheers,
Andrew J. Stewart
> -----Original Message-----
> From: Harris, Tim [mailto:tharris@ocair.com]
> Sent: Wednesday, August 02, 2000 10:34 AM
> To: 'ids@uow.edu.au'
> Subject: IDS: Food for thought...
>
>
> Archive: http://msgs.securepoint.com/ids
> FAQ: http://www.ticm.com/kb/faq/idsfaq.html
> IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
> HELP: Having problems... email questions to ids-owner@uow.edu.au
> NOTE: Remove this section from reply msgs otherwise the msg
> will bounce.
> SPAM: DO NOT send unsolicted mail to this list.
> UNSUBSCRIBE: email "unsubscribe ids" to majordomo@uow.edu.au
> --------------------------------------------------------------
> ---------------
> Greetings and felicitations. What do you folks think about...
>
> I use snort as an IDS and I was wondering about how some of
> the shortcomings
> of an IDS might be overcome. I expect that these questions have been
> debated before in various forums but I have not been privy to those
> discussions so here goes...
>
> 1. The fundamental problem with any current IDS is that it relies on
> signature files. It is very simple to modify an attack
> (particularly a
> buffer overflow) to avoid using the known signature thus
> causing the analyst
> to have no data to examine.
>
> 2. An IDS is difficult to tune. You either get many false
> positives and
> can't find the real threat or you never see the actual attack.
>
> 3. Snort creates large quantities of data that need to be
> filtered by the
> analyst.
>
>
> What would happen if we changed the basic philosophy of the
> IDS to be a
> conceptual "deny except as permitted"? Right now it shows me
> the things
> that it knows are bad. What if it sorted a packet (or
> packets) into four
> categories instead of only alert or ignore?
>
> Category 1: Things that are explicitly OK. Pass without notice
> Category 2: Things that are bad but I am safe from. Log without Alert
> Category 3: Things that I am not safe from. Log and Raise Alert
> Category 4: By defualt, everything else is questionable. Log
> in a separate
> location
>
> The obvious problem with this scheme is that category 4 will
> initially be
> huge. But after time, things would be moved into one of the other
> categories by writing or modifying a rule. The thing that
> the analyst needs
> is to be able to focus on the high risk areas (category 4).
> Once a threat
> is identified it can be re-categorized from a level four to a
> 1, 2, or 3.
>
> I know that I'm being a bit muddy in my thinking but let me
> give you an
> example.
>
> Suppose I have a server set up with HTTP and DNS daemons running.
>
> The first level of filtering would be to ignore everything
> that we have
> defined as OK. This might be a list of
> files/directories/addresses/ports/etc that I know are OK.
> All these things
> would pass without mention.
>
> The second level of filtering would be addresses or ports
> that don't exist
> and/or have no listeners. Activity against these would go
> into a historical
> log to be used if more detail is needed. This category might
> also include
> information gathering attempts that are not important such as
> pings and
> traceroutes.
>
> The third level would be positive attacks against existing
> ports/addresses.
> These would go into a separate log of hostile activity.
>
> The fourth level would be everything that is left. That would be the
> separate file that the analyst would use to identify new
> attack modes. The
> analyst would spend the majority of time examining that data. As the
> analyst identifies a new attack or determines that the traffic is
> unimportant/harmless, a rule would be written to place that traffic or
> attack method into one of the other categories.
>
>
> I can see a lot of difficult problems with defining each of
> these areas but
> this would give the analyst data on previously unknown attack
> modes as well
> as the backup data for someone who has been poking for a
> while. There are
> lots of things that happen that are not important unless a real attack
> occurs. An example would be a port scan or a ping. I don't
> care about
> those unless a real attack occurs. Then I need to be able to
> refer back to
> the historical data. This scheme would save the relevant data without
> making me wade through unimportant alerts.
>
> Any thoughts or opinions that you would like to share?
>
|
