Re: snort hosted on server vs. a tap on network

["Roy S. Rapoport" <snort-users () ols inorganic org>]

On Thu, Jun 05, 2003 at 04:32:10PM -0700, Tom Fulton wrote:
> All the network diagrams I see with Snort on it shows snort on computers
> separate from the web servers, file servers, etc.
>
> Why is this?  Are there any negatives to running snort on my servers?

This is not a "why should you do it this way?" response, but rather "why
would I want to do it this way?" response.  In other words, I have no
idea what the universally correct answer to this is.

For me, however, I prefer to -- as much as possible and reasonable -- 
segragate different functions into their own servers.  For one thing, it
means managing those systems in a large enterprise becomes more granular
(webadmins may get root on web servers, but they don't need root on
database servers, and nobody needs root on the main admin servers other
than the superadmins); 

It means you can build physical systems to maintain loads that are more
specific to the function of the system (we found that web servers didn't
need particularly fast disk I/O subsystems but -- and wait, I know you
may find this surprising -- fileservers did);

It means that, in some cases, you get a better ability to debug
inter-application connectivity, since you can snoop it when it's between
servers more easily than when it's on the same server;

It means that you can give only as much access to each system as is
absolutely necessary.  For example, if you've got the standard 
web server->app server->db server tier system, you don't need to open up
port 80 on the app server from the outside just because the web server
needs it (you could also run whatever it is you want to run on the app
server on a different port, but it's sometimes easier not to).

Specifically in the case of Snort, you're either going to run Snort in
promiscuous mode or not; if you're running it on every single server
you've got, then you (obviously -- unless I'm missing something) don't
want it running in promisc mode, since every attack (assuming you've
somehow gotten around the switching issue) is going to generate an alert
from every single one of your boxes.  If you're *not* running in promisc
mode, and aren't seeing all the traffic, you may miss some attacks
(especially ones such as portscans that cleverly spread around the
portscanning across the network to avoid this sort of detection).

Further in the specific case of Snort, it means your Snort system can be
significantly harder to crack because you can have an unconfigured
interface on it that is snooping the traffic that can't even be
reachable from the network.  In other words -- forgive the ASCII
graphics:

---Outside network ------
    |  
  firewall 1
    |
---DMZ ----------
 |     |1     |
WWW   Snort   firewall 2
       |2     |
---Internal network -------

In this diagram, the WWW server is connected only to the DMZ network and
is reachable from the outside.  Snort system has two interfaces;
interface 1 is connected to the DMZ but does not have an IP address;
interface 2 is on the internal network and is the interface by which we
communicate with the Snort system.  

I have to admit to generally getting hives whenever I see a design that
short-circuits a firewall, but there are some advantages to this system.

-roy


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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