Follow

Snort on CentOS 6 with redBorder Live - Part I

Introduction

Security is a vital element in many environments, regardless of their size.

Snort is a free software project that is a leader in the field and widely used to reinforce network security. It is a NIDPS (Network Intrusion Detection and Prevention System) that is very present in many professional, academic, and laboratory installations.

This guide aims to facilitate the integration of these types of installations in the new redborder Cloud environment: redborder Live.  

This way, the user can easily and effectively configure multiple rule policies, as well as store and analyze the alterts generated by Snort quickly and productively.

Following these simple steps, the system can be registered in Live as if it were a redborder sensor.

Prerequisites

The procedure described here takes as a reference a completely updated installation of a CentOS 6 system.

To begin with the integration, the following requirements must be met:

  • Access to repositories:
    • EPEL
    • redBorder (publicrepo)
    • cert-forensics-tools
  • Have an account and organization created in redborder Live.

To install the repositories, simply execute the following command:

[root@snortstd-centos6 ~]# rpm -ivh \
https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm \
https://forensics.cert.org/cert-forensics-tools-release-el6.rpm \
http://publicrepo.redborder.com/redBorder-release-6-5.noarch.rpm
Retrieving https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm Retrieving https://forensics.cert.org/cert-forensics-tools-release-el6.rpm Retrieving http://publicrepo.redborder.com/redBorder-release-6-5.noarch.rpm Preparing...                ########################################### [100%]   1:redBorder-release      ########################################### [ 33%]   2:cert-forensics-tools-re########################################### [ 67%]   3:epel-release           ########################################### [100%]

Selection and Installation of the Snort Packet

You can skip this chapter if you already have Snort properly installed and running.

The cert-forensics-tools repository contains various versions of Snort compiled for CentOS 6:

[root@snortstd-centos6 ~]# yum search snort --showduplicates
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: mirror.trueinter.net
* epel: epel.check-update.co.uk
* extras: mirror.trueinter.net
* updates: mirror.trueinter.net
============================================================================================================= N/S Matched: snort =============================================================================================================
fwsnort-1.6.4-1.el6.noarch : Translates Snort rules into equivalent iptables rules
1:snort-mysql-2.9.1.1-1.el6.x86_64 : Snort with MySQL support
1:snort-postgresql-2.9.1.1-1.el6.x86_64 : Snort with PostgreSQL support
snort-sample-rules-2.9.8.0-1.el6.noarch : Sample rules for snort
1:snort-unixODBC-2.9.1.1-1.el6.x86_64 : Snort with unixODBC support
1:snort-2.9.8.0-1.el6.x86_64 : An open source Network Intrusion Detection System (NIDS)
1:snort-2.9.8.0-1.el6.x86_64 : An open source Network Intrusion Detection System (NIDS)
1:snort-openappid-2.9.8.0-1.el6.x86_64 : An open source Network Intrusion Detection System (NIDS) with open AppId support

Name and summary matches only, use "search all" for everything.

In this case, snort version 2.9.8.0-1 is going to be selected as the packet to be installed (valid for all versions).

[root@snortstd-centos6 ~]# yum install snort-2.9.8.0-1.el6.x86_64

This guide is focused on performing a basic configuration that allows the Snort service to function, such that it serves as a starting point for a more complex configuration.

The specific Snort configuration to adapt to the inspection needs of your particular environment is outside the scope of this document.

Basic Snort configuration

You can skip this chapter if you already have Snort properly installed and running.

Let's assume the following configuration parameters:

  • Management interface: eth0
  • Inspected interface: eth1
  • Snort operation mode: IDS
  • Snort output format: unified2

Based on these parameters, we are going to slightly modify the default configuration files to make it work. This is far from a properly-secured configuration. The idea is to make it work easily as a proof of concept.

  • Disable the ALERTMODE and BINARY_LOG options in /etc/sysconfig/snort. For example:
  • Set INTERFACE=eth1
# /etc/sysconfig/snort
# $Id: snort.sysconfig,v 1.3 2005/05/05 18:23:45 jhewlett Exp $

# All of these options with the exception of -c, which tells Snort where
# the configuration file is, may be specified in that configuration file as
# well as the command line. Both the command line and config file options
# are listed here for reference.


#### General Configuration

# What interface should snort listen on?  [Pick only 1 of the next 3!]
# This is -i {interface} on the command line
# This is the snort.conf config interface: {interface} directive
INTERFACE=eth1
#
# The following two options are not directly supported on the command line
# or in the conf file and assume the same Snort configuration for all
# instances
#
# To listen on all interfaces use this:
#INTERFACE=ALL
#
# To listen only on given interfaces use this:
#INTERFACE="eth1 eth2 eth3 eth4 eth5"


# Where is Snort's configuration file?
# -c {/path/to/snort.conf}
CONF=/etc/snort/snort.conf

# What user and group should Snort drop to after starting? This user and
# group should have very few privileges.
# -u {user} -g {group}
# config set_uid: user
# config set_gid: group
USER=snort
GROUP=snort

# Should Snort change the order in which the rules are applied to packets.
# Instead of being applied in the standard Alert->Pass->Log order, this will
# apply them in Pass->Alert->Log order.
# -o
# config order: {actions in order}
# e.g. config order: log alert pass activation dynamic suspicious redalert
PASS_FIRST=0


#### Logging & Alerting

# NOTE: NO_PACKET_LOG and BINARY_LOG, ALERTMODE, etc. are mutually
# exclusive. Use either NO_PACKET_LOG or any/all of the other logging
# options. But the more logging options use you, the slower Snort will run.


# Where should Snort log?
# -l {/path/to/logdir}
# config logdir: {/path/to/logdir}
LOGDIR=/var/log/snort

# How should Snort alert? Valid alert modes include fast, full, none, and
# unsock.  Fast writes alerts to the default "alert" file in a single-line,
# syslog style alert message.  Full writes the alert to the "alert" file
# with the full decoded header as well as the alert message.  None turns off
# alerting. Unsock is an experimental mode that sends the alert information
# out over a UNIX socket to another process that attaches to that socket.
# -A {alert-mode}
# output alert_{type}: {options}
#ALERTMODE=fast

# Should Snort dump the application layer data when displaying packets in
# verbose or packet logging mode.
# -d
# config dump_payload
DUMP_APP=1

# Should Snort keep binary (AKA pcap, AKA tcpdump) logs also? This is
# recommended as it provides very useful information for investigations.
# -b
# output log_tcpdump: {log name}
#BINARY_LOG=1

# Should Snort turn off packet logging?  The program still generates
# alerts normally.
# -N
# config nolog
NO_PACKET_LOG=0

# Print out the receiving interface name in alerts.
# -I
# config alert_with_interface_name
PRINT_INTERFACE=0

# When dumping the stats, what log file should we look in
SYSLOG=/var/log/messages

# When dumping the stats, how long to wait to make sure that syslog can
# flush data to disk
SECS=5

# To add a BPF filter to the command line uncomment the following variable
# syntax corresponds to tcpdump(8)
#BPF="not host 192.168.1.1"

# To use an external BPF filter file uncomment the following variable
# syntax corresponds to tcpdump(8)
# -F {/path/to/bpf_file}
# config bpf_file: /path/to/bpf_file
#BPFFILE=/etc/snort/bpf_file

  • Configure HOME_NET and EXTERNAL_NET variables in /etc/snort/snort.conf. In order to avoid conflicts with some rules, please, avoid set this variables to "any". If you aren't sure which values use, you can set HOME_NET with private networks (192.168.0.0/16,10.0.0.0/8,172.16.0.0/12) and EXTERNAL_NET with !HOME_NET.
...
###################################################
# Step #1: Set the network variables. For more information, see README.variables
###################################################

# Setup the network addresses you are protecting
ipvar HOME_NET 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12

# Set up the external network addresses. Leave as "any" in most situations
ipvar EXTERNAL_NET !$HOME_NET ...

  • Configure output using unified2 format. Example:
output unified2: filename snort.log, limit 128, mpls_event_types, vlan_event_types
  • Disable all the references to rules archives (include $RULE_PATH/*.rules) except those that point to local.rules (include $RULE_PATH/local.rules) in /etc/snort/snort.conf.
...
###################################################
# Step #7: Customize your rule set
# For more information, see Snort Manual, Writing Snort Rules
#
# NOTE: All categories are enabled in this conf file
###################################################

# site specific rules
include $RULE_PATH/local.rules

#include $RULE_PATH/app-detect.rules
#include $RULE_PATH/attack-responses.rules
#include $RULE_PATH/backdoor.rules
#include $RULE_PATH/bad-traffic.rules
#include $RULE_PATH/blacklist.rules
#include $RULE_PATH/botnet-cnc.rules
...
  • Enable the perfmonitor preprocessor to gather statistics on Snort usage. These values will be sent to redBorder Live were you can view them in an understandable format (watch out for the proposed path).
...
# performance statistics.  For more information, see the Snort Manual,
# Configuring Snort - Preprocessors - Performance Monitor
preprocessor perfmonitor: time 300 file /var/log/snort/snort.stats pktcnt 10000
...
  • Disable the reputation preprocessor that won't be used in this basic configuration in /etc/snort/snort.conf. 
...
# Reputation preprocessor. For more information see README.reputation
#preprocessor reputation: \
#   memcap 500, \
#   priority whitelist, \
#   nested_ip inner, \
#   whitelist $WHITE_LIST_PATH/white_list.rules, \
#   blacklist $BLACK_LIST_PATH/black_list.rules
...

To finish this basic configuration and thus enable the service to run in very basic mode, two more steps are still pending:

1. Create the dynamic rules directory:

[root@snortstd-centos6 ~]# mkdir /usr/local/lib/snort_dynamicrules

2. Create the local.rules archive, initially empty:

[root@snortstd-centos6 ~]# touch /etc/snort/rules/local.rules

Now we should be able to start the basic service: 

[root@snortstd-centos6 ~]# /etc/init.d/snortd start
Starting snort: Spawning daemon child...
My daemon child 31590 lives...
Daemon parent exiting (0)
                                                           [  OK  ]

Click here to go to the installation process of redBorder plugin.

Have more questions? Submit a request

Comments

Powered by Zendesk