لطفا منتظر باشید ...
Recipe 9.22 Detecting Intrusions with Snort
9.22.1 Problem
You
want to notice if your system is under
attack from the network.
9.22.2 Solution
To run as a network intrusion detection system, with binary logging,
and alerts sent to the system logger:
# snort -c /usr/local/share/rules/snort.conf -b -s
To run Snort in the background, as a daemon:
# snort -D [-u user] [-g group] [-m umask] -c ...
9.22.3 Discussion
Snort is most valuable when run as a full-fledged NIDS:
# snort -c /etc/snort/snort.conf ... SuSE installation
# snort -c /usr/local/share/rules/snort.conf ... Manual installation
The configuration file includes a large number of pattern matching
rules that control logging and alerts.In this mode of operation, packets are recorded (logged) when they
match known signatures indicating a possible
intrusion. Use the -b option for efficient
logging to
binary
libpcap-format files. [Recipe 9.24]
The -N option disables logging if you want
alerts only, but we
don't recommend this: the logs provide valuable
context about the events that triggered the alerts.Alerts can be directed to a wide range of destinations. We recommend
the system logger [Recipe 9.27] because:
- It's efficient.
- It's convenient (and enlightening) to correlate
Snort's messages with those of other daemons, your
firewall, and the kernelthese are all recorded in the system
log. - Tools like
logwatchRecipe 9.36] can scan the log files effectively and provide
notification by email, which works well with high-priority alerts.
Use the -s option to direct alerts to the system
logger. By default, alerts are sent using the
auth facility and info
priority. This can be changed by uncommenting and changing a line in
snort.conf, e.g.:
output alert_syslog: LOG_LOCAL3 LOG_WARNING
|
the -A none option. We don't
recommend this for routine operation, unless you have some other
special mechanism for producing alerts by examining the logs.To run Snort in the background, as a
daemon, use the -D
option. This is the recommended way to launch Snort for continuous,
long-term operation. Also, Snort is best run on a dedicated
monitoring system, ideally sniffing traffic on an unconfigured,
"stealth" interface. [Recipe 9.16]On SuSE systems, you can
enable Snort to start automatically at boot time with the
chkconfig command:
# chkconfig snort on
Edit /var/adm/fillup-templates/sysconfig.snort
to specify the desired snort command-line options.On Red Hat systems, the simplest
way to start Snort at boot time is to add a command to
/etc/rc.d/rc.local. Alternately, you can copy
one of the other scripts in /etc/init.d to
create your own snort script, and then use
chkconfig.Snort must be run as root initially to
set the network interfaces to promiscuous mode for sniffing, but it
can run subsequently as a less privileged userthis is always a
good idea for added security. Use the -u and
-g options to designate this lesser user and group
ID, respectively. The
permissions of the logging
directory need to allow only write access for this user or group. If
you want to allow a set of other authorized users to analyze the
logging data (without root access), add the users to
Snort's group, make the logging directory group
readable, and use -m 007 to set
Snort's umask so that all of the
files created by Snort will be group readable as well. [Recipe 5.10]You can ask Snort to dump statistics to the system
logger (the same report that is produced before Snort exits) by
sending it a SIGUSR1 signal:
# kill -USR1 `pidof snort`
Snort writes its process ID to the file
/var/run/snort_<interface>.pid.
If you are running multiple copies of snort, with
each listening on a separate interface, these files can be handy for
signaling specific invocations, e.g.:
# kill -USR1 `cat /var/run/snort_eth2.pid`
9.22.4 See Also
snort(8). The Snort home page is http://www.snort.org.
