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@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@sourcefire.com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Snort-users mailing list
Snort-users@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
