[Snort-users] Multiple instances of Snort

Martin Roesch roesch at ...1935...
Wed Sep 29 08:00:01 EDT 2004


How about just writing rules that capture the user logins/logouts so 
you can associate a user with an IP and just analyze their events on a 
per IP basis.  It doesn't sound like you need per-user policy 
enforcement, you just want to be able to figure out who the user is on 
a particular IP address.  If this is the case, just log it into your 
event analysis system and if you hit a critical event you just need to 
query for the last login event for that IP addr to figure out who the 
user is.

Forking an instance of Snort for each user seems like overkill to me...

Just my $.02.

      -Marty

On Sep 24, 2004, at 4:44 PM, Rich Adamson wrote:

>>>> In short, here's what I'd like to do:
>>>>
>>>> I am a security technician for a college, and the college runs a 
>>>> public
>>>> cyber cafe. We also offer wireless access. One of the problems is 
>>>> that
>>>> there is little auditing in place for the wireless users. I'd like 
>>>> to
>>>> setup IAS (I have to use Windows, otherwise I'd use 
>>>> freeradius.org), but
>>>> there is no "nice" frontend for IAS. I'm thinking I could use MySQL 
>>>> and
>>>> PHP and exec() IAS's command line options since IAS does not yet 
>>>> have
>>>> scripting support. Here's where Snort would come in. Snort would 
>>>> log the
>>>> packets coming to and from a user, and if something fires a filter 
>>>> in
>>>> Snort, it would alert the cyber cafe monitor, and based on the
>>>> severity/number of alerts for the user, the cyber cafe monitor could
>>>> kill the session for the user. So, I'd like to fork Snort for each 
>>>> user.
>>>> I don't expect more than say 5 wireless users at a time, but of 
>>>> course
>>>> the more that I can get the application and Snort to scale, the 
>>>> better.
>>>> My question is how well would Snort handle in such an environment 
>>>> with
>>>> regards to resources, or is something like this even possible 
>>>> currently?
>>>>
>>>>
>>>
>>> There are lots of very different ways to handle wireless stuff, and 
>>> snort
>>> can do a piece of that. Not sure I understand why you want multiple
>>> instances of snort running, but I have several Win32 machines running
>>> with multiple snort "services", each monitoring via a different nic
>>> card. Works rather well, however I'd have to guess it wouldn't handle
>>> high volume traffic all that well. Never tested, so not 100% 
>>> positive.
>>>
>>> Another approach is to use static IP's on each wireless unit, and if
>>> someone tries to access via dhcp, hand them an IP and default gateway
>>> that leads to a honeypot with alerting capability. Mapping mac 
>>> addresses
>>> to IP's also has some value as well.
>>>
>>>
>>>
>>>
>> Thanks for the reply. The reason I want multiple instances of Snort 
>> (and
>> maybe I'm overthinking this, I don't know) is so that I can have the
>> alert packets logged to mysql and/or the filesystem for that user.
>> Here's (hopefully) a better explanation.
>>
>> 1. A user registers for the first time and they are given their 
>> username
>> and password that lasts for say 3 hours. Or, they have already
>> registered, and they are given their username and password that lasts 
>> x
>> hours.
>> 2. Once they sign in, I would fork Snort for that user's session. 
>> Snort
>> would just be running in NIDS mode. Then I have a ruleset that detects
>> an attempt to  say have a Bitorrent server running off of the user's
>> laptop. An alert would fire, and the lab monitor would see it, and 
>> based
>> on our policy, wait to see if anything more happens or immediately 
>> kill
>> the session for that user. We can later go back and run a report and
>> tell those higher-up that this person was doing x at y time.
>> 3. However, during that time, another user signs in and is given their
>> temporary username and password.
>> 4. Another Snort process is started, and is monitoring only them.
>> However, if we only had a single Snort process, and though Snort does
>> log for the various IP addresses, we would have a more difficult time
>> tracking down which IP address belongs to which user. Unfortunately
>> static IP addresses are not an option.
>>
>> That's my reasoning behind the forking anyway.
>
> Think that might be a little overkill. If I were one of you users
> and decided to run VoIP across your network, how would you know I'm
> doing that (assuming you didn't want me to do that)?
>
> Might be chasing your tail trying to control the users.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
>
-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Discover.  Determine.  Defend.
roesch at ...1935... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org





More information about the Snort-users mailing list