26

Chapter 2     Installing Snort and Getting Started

the host name. You have to build database logging capability into Snort at the compile

time, which will be described later in this chapter. Configuring Snort to use the database

is discussed in Chapter 4, 5 and 6.

2.1.5

Multiple Snort Sensors with Centralized Database

In a corporate environment, you probably have multiple locations where you

would like to install Snort sensors. Managing all of these sensors and analyzing all data

collected by these sensors separately is a very difficult job. There are multiple ways to

setup and install Snort in the enterprise as a distributed IDS.

One method is shown in Figure 1 3 in Chapter 1 where multiple sensors connect

to the same centralized database. All data generated by these sensors is stored in the

database. You run a web server like Apache (http://www.apache.org). A user then uses a

web browser to view this data and analyze it.

However there are some practical problems with this setup. 

  All of the sensors must have access to the database at the time you start Snort.

If Snort is not able to connect to the database at the start time, it dies.

  The database must be available all of the time to all sensors. If any of the

network links are down, data is lost.

  You have to open up additional ports for database logging in firewalls if a

firewall lies between the database server and any of the sensors. Sometime this

is not feasible or against security policy.

You can come up with some alternate mechanisms where Snort sensors do not

have a direct connection to the database server. The sensors may be configured to log to

local files. These files can then be uploaded to a centralized server on a periodic basis

using utilities like SCP. The SCP utility is a secure file transfer program that uses

Secure Shell (SSH) protocol. Firewall administrators usually allow SSH port (port 22)

to pass through. You can run certain utilities like Snort itself,

1

 Barnyard or some other

tool to extract data from these log files and put it into the database server. You can use

the usual web interface to view this data later on. The only problem with this approach

is that the data in the database is not strictly  real time . There is a certain delay which

depends upon frequency of uploading data using SCP to the centralized database server.

This arrangement is shown in Figure 2 1.

Note that this centralized server must be running SSH server so that SCP utility is

able to upload files to this server.

1.

 Snort can be run to get information from its own log files using a command line parameter.