[Snort-users] Centralized DB Server??

Marc Thompson Marc.Thompson at ...2101...
Tue Jun 12 21:07:07 EDT 2001


Paul,

>Just jumping in here but I saw a recommendation somewhere to use something
>like swan between distributed sensors and the centralized console.
>Anybody actually accomplished this?

My information is all second-hand, but from a source that I trust.
Apparently,
FreeS/wan is easy to configure on Linux and trustworthy.  The person I asked
has actually set it up.  It apparently provides IPsec (56bit?) encryption
to create a VPN between Linux hosts across the Internet.  I've even heard
rumors
that it can connect to Cisco IOS systems running IPsec (very cool if true).

Wish I had more to add, but it seems like a worthwhile thing to at least
checkout.

Here's a good overview from RedHat's site:

	
http://www.europe.redhat.com/documentation/HOWTO/VPN-Masquerade-HOWTO-1.php3

Quote directly from the above page:
	"The home page for Linux FreeS/WAN (IPsec for Linux) 
	is http://www.xs4all.nl/~freeswan/ - this is the 
	preferred Linux VPN solution"

I'd be interested to hear if you get this working.

-Marc Thompson

*******************************************
Marc Thompson
IT Site Manager
BOPS, Inc.
7800 Shoal Creek Blvd. Suite 200N
Austin, TX 78757

-----Original Message-----
From: Paulie [mailto:paulie at ...2160...]
Sent: Tuesday, June 12, 2001 5:02 PM
To: patrick.n.fitzgerald.1
Cc: Marc Thompson; snort-users at lists.sourceforge.net
Subject: RE: [Snort-users] Centralized DB Server??



Just jumping in here but I saw a recomendation somewhere to use something
like swan between distributed sensors and the centralized console.
Anybody actually accomplished this?

This would get problematic if you were attempting to force the IPSEC
tunnels through a NAT-ing box i suppose.


Paul

On Tue, 12 Jun 2001, patrick.n.fitzgerald.1 wrote:

>
> I would have to say, No, that's not a good idea. Keep in mind that while
> the MySQL development team keeps security in mind, the MySQL server is not
> designed to be outside the firewall. I would strongly suggest that you
> rig up some firewall rules to block all traffic from any other host to the
> MySQL port. Even that is dangerous given the prevalence of spoofing, but
> it's better than nothing. In that case, you would want Snort to ignore
> traffic to the MySQL port only from the remote sensor.
>
> I would also strongly recommend using stunnel or a VLAN or something
> similar, as MySQL queries are (mostly) plaintext.
>
> Something that my project is currently working on to circumvent this
> problem is a PHP script which catches XML formatted alerts and puts them
> into the MySQL DB. The XML module can use https, so we just let Apache
> handle the transport layer instead of MySQL.  Unfortunately, because of
> differences between the two data models this is proving somewhat
> difficult. But, we do feel pretty strongly against leaving MySQL open.
>
> Patrick F.
> CERIAS IRDB project
>
> On Tue, 12 Jun 2001, Marc Thompson wrote:
>
> > Kris,
> >
> > >Are your sensors in different geographic locations?
> >
> > Thank you for responding.  My sensors will be in several different
> > geographical locations.  I've been brainstorming this a bit, and it
seems
> > that I should be able to easily ignore alerts that are being generated
by
> > traffic to the MySQL TCP port.  Does this sound like the answer?
> >
> > Thank you for your response,
> > Marc Thompson
> >
> >
> > -----Original Message-----
> > From: Kris Quinby [mailto:kquinby at ...2243...]
> > Sent: Tuesday, June 12, 2001 2:29 PM
> > To: Marc Thompson; snort-users at lists.sourceforge.net
> > Subject: RE: [Snort-users] Centralized DB Server??
> >
> >
> > Are your sensors in different geographic locations?  If not you could
have
> > two network interfaces in each NIDS, one with no IP on the network you
are
> > watching, and one on a "management" network.  Then you could have your
MySQL
> > data base on the management network collecting from all your sensors.
> >
> > Kris
> >
> > -----Original Message-----
> > From: Marc Thompson [mailto:Marc.Thompson at ...2101...]
> > Sent: Monday, June 11, 2001 7:21 AM
> > To: snort-users at lists.sourceforge.net
> > Subject: [Snort-users] Centralized DB Server??
> >
> >
> > I would like to use a IDS architecture using Snort and MySQL
> > that utilizes multiple NIDS across many routers and sites, but
> > only one database to collect alerts.
> >
> > My question is, wouldn't the action of sending an alert to a
> > centralized database set off the same rule on a NIDS box sitting
> > between the alert source and the remote database?
> >
> > Is the only way to prevent this double-logging of alerts to specify
> > that the 'in-between' NIDS should ignore traffic from the remote NIDS
> > to the central database server?  If so, is there a standard way of
> > specifying this in the Snort configuration file? (ignore traffic
> > globally to the MySQL TCP port?)
> >
> > Thank you in advance,
> > Marc Thompson
> >
> >
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users at lists.sourceforge.net
> > Go to this URL to change user options or unsubscribe:
> > http://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users
> >
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users at lists.sourceforge.net
> > Go to this URL to change user options or unsubscribe:
> > http://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users
> >
>
> --
> "BUGS
>      Flood pinging the broadcast address is not recommended." -- ping(1)
>
>
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>




More information about the Snort-users mailing list