Transcript
Page 1: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Extending pfSense with SNORT for Intrusion detection & prevention.

The SNORT package, available in pfSense, provides a much needed Intrusion detection and/or

prevention system alongside the existing PF stateful firewall within pfsense.

These directions show how to get SNORT running with pfSense and some of the common problems

which may be encountered.

Contents Extending pfSense with SNORT for Intrusion detection & prevention. .................................................. 1

Quick overview of SNORT on pfSense. .................................................................................................. 2

Introduction ........................................................................................................................................ 2

Rules & subscriptions .......................................................................................................................... 2

Rulesets and detection ....................................................................................................................... 2

White lists & suppression rules. .......................................................................................................... 3

White lists ....................................................................................................................................... 3

Suppression rules. ........................................................................................................................... 3

Installing SNORT ..................................................................................................................................... 4

Initial Configuration of SNORT ............................................................................................................... 5

General configuration ........................................................................................................................ 5

Assigning an interfaces to SNORT instances ..................................................................................... 6

Selecting the SNORT rules you need and testing them. ....................................................................... 9

Common Rulesets ......................................................................................................................... 10

Whitelist definition .............................................................................................................................. 11

Alerts, suppression rules & lists ........................................................................................................... 12

Alert alert alert! ................................................................................................................................ 12

Unblocking a host ............................................................................................................................. 13

Preventing it happening again (suppression or disabling a rule) ...................................................... 14

Disabling rules ............................................................................................................................... 14

Suppressing rules .......................................................................................................................... 16

Page 2: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Quick overview of SNORT on pfSense.

Introduction SNORT is installed as a pfSense package.

Once installed you can configure one of more instances of SNORT to run within pfSense.

Each SNORT instance runs with individual settings and against a particular virtual interface.

Rules & subscriptions SNORT has its own syntax to write rules to inspect network traffic, to detect undesirable stuff.

Fortunately you can subscribe to SNORT rule sources – so you don’t need to write your own.

Within pfSense there are several sources of rules you can subscribe to within the SNORT global

settings:

Source name Free/commercial Notes

Snort VRT Free account (requires sign up for code), with commercial version available.

Commercial version provides more up to date rulesets.

Snort Community Free

Emerging Threats ET Open

Free Now included in ‘SNORT community rules’

Emerging Threats ET Pro

Commercial only. Provides best coverage and daily updates.

OpenAppID Free For application identification only, not threat detection. Support for Open App ID is not complete in pfSense/SNORT.

Once SNORT rule sources have been subscribed to, you are given the option to select ‘rulesets’

(groups of rules according to a category) for your instance of SNORT.

Rulesets and detection Rulesets will determine the type of traffic SNORT looks for (or doesn’t).

There are several different types of traffic SNORT will look for:

Exploits for specific services (HTTP (Apache/IIS/etc), FTP, IMAP, SNMP, etc)

User traffic – Web browsers (Chrome, Firefox)

Malware – Viruses, worms, PUAs.

Attacks – DDOS, exploit-kits, bad traffic

Block lists – known compromised hosts & black listed IPs.

Page 3: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

White lists & suppression rules.

It’s important to setup white lists and rule suppression lists to avoid generating unnecessary false

positives.

White lists

Simply a list of hosts SNORT will completely ignore.

Very useful for Oracle or HFS traffic, which often triggers SNORT and is fairly critical and fairly

trustworthy (being internal to the university).

Suppression rules.

More flexible than a white list, these can be used to get SNORT not to block certain traffic.

The rules are written to a suppression list, which you can edit and put comments in – although the

pfSense interface will do this for you.

SNORT will still show alerts, but not block the traffic when it matches a suppression rule.

Can be handy for certain hosts or instances where we don’t want to ignore all traffic, eg a

webserver, which needs access from a particular port for a certain IP, which SNORT deems bad.

Page 4: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Installing SNORT

Snort is easy to install.

Click on the packages tab under system … system packages.

The package management system takes care of the dependencies and soon you will see an

‘installation done’ message.

Page 5: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Initial Configuration of SNORT Once you have done the easy bit of installing SNORT, you’ll need to configure it before it will do

anything at all.

General configuration You’ll find SNORT configuration and management under the Services menu.

From here you’ll see the SNORT configuration dashboard, with any interfaces configured with an

instance of SNORT:

(In the above example we have only our WAN interface configured).

Page 6: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Assigning an interfaces to SNORT instances

You’ll want to choose which interfaces you want to assign for traffic analysis by SNORT (aka setup a

SNORT instance for that interface).

Note each instance of SNORT takes RAM and CPU. As you add more rules to an instance of SNORT, it

will add an extra load on RAM and CPU.

Each interface will (and should) be setup differently – this is important, as LAN and WAN traffic will

require different types of analysis and thus different configurations in SNORT.

You will almost certainly want to ‘test’ SNORT rulsets before using them to block traffic.

Here is an example of how you could setup SNORT instances on a simple bridging firewall:

NB. In some configurations the LAN interface might also merit SNORT analysis, such as guest WiFi,

public access networks, to check machines aren’t passing out bad traffic.

IPS = Intrusion prevention system. In this case where our SNORT system is configured to block ‘bad’

traffic.

IDS = Intrusion detection system. Only detects ‘bad’ traffic and doesn’t block anything.

Click on the ‘+’ symbol to add an interface mapping to SNORT:

Here we are adding/editing the WAN interface:

WAN

• SNORT instance in IPS mode for blocking bad traffic/hosts.

Bridge

• SNORT instance in IDS mode for testing rulesets.

LAN

Page 7: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Running through the options on the ‘<interface name> Settings’ tab:

General section

Enable – Exactly that, to enable or disable this configuration of SNORT on this interface.

Interface – The network interface SNORT will listen and optional act on.

Description – A friendly name that you can use for the interface, i.e. to determine it from another.

Page 8: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Alerts

Send Alerts to System Logs – alerts (such as network intrusion attempts, SNORT service restarts) will

be sent to the syslog service. These will be prefaced with ‘snort’. You may want to enable this for an

IPS (blocking) instance of SNORT to track IPs blocked (But disable this for IDS instances of SNORT to

save masses of alerts in your syslogs).

System Log Facility – Change the syslog ‘type’ SNORT messages are logged as in syslog.

System Log Priority – Just that, all SNORT logs will be at this syslog priority.

Block offenders – Changes SNORT from an IDS (intrusion detection system) to an IPS (intrusion

prevention system).

Kill states – For blocked IPs any existing states in the firewall will be blocked (usually a good idea to

turn on for an IPS instance (see above).

Which IP to Block – (src/dst/both) Leaving this set to ‘both’ is fine (see whitelisting later on…)

Performance settings

Search method – This determines how well SNORT will perform on your hardware (mainly how

memory efficient it will be. The default selection is usually fine in small networks.

Split ANY-ANY – Performance trade-off for low memory servers.

Search Optimize – self-explanatory.

Stream inserts.

Checksum Check Disable – Performance improvement.

Whitelists and inspection lists

The lists below are all defined within the ‘IP’ lists tab:

Home net – Your local subnet(s)

External Net – The outside world, leave as default…

Pass list – I’ve used my own subnets here, as there are some services in I don’t want to block. There

are some that are easily misidentified by SNORT as a threat.

Alert Suppression and Filtering – A list of SNORT rules (usually used to get SNORT to skip particular

activities on certain hosts).

Advanced configuration pass-through – Not tried this.

Page 9: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Selecting the SNORT rules you need and testing them. SNORT only detects ‘bad’ traffic by the rules/rulesets you give it.

You can select sets of rules (ruleset) for each instance of SNORT.

In the example below we’re selecting a few rulesets for our WAN interface instance of SNORT:

It’s worth leaving ‘resolve flowbits’ checked – this will enable ‘flowbit’ rules to be automatically

enabled/disabled according to the rules you select/de-select.

You can either:

Use an IPS policy (and add any ETPro rulesets individually) for a general ‘low/medium/high’

approach…

Or

Add rulesets individually.

The second option, allow for full ‘tuning’ of the firewall with rulesets you’ll need. The first option

may lead to missed traffic or too many false positives (being a very generic set of rules).

Page 10: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Snort rule select boils down to:

1. Essential rules (Known bad hosts, worms, etc…)

2. Specific rules for your servers/services (These tend to be service specific, eg: FTP, IMAP).

3. Bad services – Some rules are designed to block services, rather than exploits and misuse of

the services themselves (example is the ruleset emerging-p2p.rules).

4. Old and test ruleset – leave these off (an example is snort_ddos.rules) as they may block too

much traffic, being out dated or used for testing/development.

Please note: Having a subscription to commercial SNORT or ETPro will give you better rulesets to

choose from. (Better, because they will be updated more often).

Gotcha alert: If you change your rule subscriptions, your ruleset selections will disappear, as the old

rulesets are removed and replaced with new ones.

Some of the SNORT rules are explained here: https://www.snort.org/rules_explanation

Common Rulesets

Here is a list of some of the rulesets seen in pfSense, with essential rulesets highlighted in red,

specific in orange, bad services in blue and old in grey. Unknown rules are not highlighted.

Ruleset name Use Notes

Snort GPLv2 Community Rules (VRT certified)

emerging-attack_response.rules

emerging-botcc.rules

emerging-compromised.rules Blocking traffic from known compromised hosts

All hosts on this rules blocklist are known to be bad.

emerging-dshield.rules Blocking traffic from bad IPs All hosts on this rules blocklist are known to be bad.

emerging-exploit.rules Blocking various exploits Eg buffer overflows, SQL injections etc..

emerging-malware.rules Blocking malware Known malware traffic/installers.

emerging-trojan.rules Blocking Trojan traffic Attempting to blocking Trojan traffic, drive by downloads etc..

emerging-web_server.rules Foiling attacks on your web servers – or information gathering attempts.

Very useful is you are firewalling webservers.

emerging-worm.rules To try and stop worms spreading.

General anti-virus.

snort_botnet-cnc.rules N/A Defunct

snort_ddos.rules N/A Defunct

Page 11: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Whitelist definition

The whitelists are defined in the ‘pass lists’ tab of SNORT interface within pfSense:

There are three different whitelists:

Home net – This is our local LAN, pop your own subnet in here. SNORT won’t analyse

anything from here.

External Net – The internet, leave this one alone. You don’t want this to be a Not really a

pass list.

Pass List – Other networks you trust, but not on you LAN. Eg. other sites or branches.

Once you’ve defined a pass list item in the ‘pass lists’ tab, you can use it for a SNORT instance.

Page 12: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Alerts, suppression rules & lists

Alert alert alert! Once you have a SNORT instance running with rulesets selected, you soon start to get alerts, as

SNORT identifies bad traffic.

You’ll see this in the ‘Alerts’ tab (and within syslog, if you have it enabled) for a SNORT instance.

Note: the Alerts are filtered by SNORT instance (as highlighted above).

There is also the ‘Blocked’ tab which simply shows you any IPs that SNORT is blocking:

NB. The alert description will correlate with an alert in the alerts tab.

Page 13: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Hosts are only blocked by SNORT for a duration as defined in global settings tab:

We’re a bit draconian with 1 day.

Unblocking a host

It’s easy to unblock a host within the ‘blocked’ tab, but I wouldn’t recommend this:

SNORT will simply block the host again if the host sends/receives the same type of traffic.

Better to identify the problem and either disable the rule (if the traffic isn’t a problem at all for your

network) or make an exception by creating a suppression rule.

Page 14: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Preventing it happening again (suppression or disabling a rule)

Disabling rules Each SNORT ruleset has many rules, which you can manually disable for each instance.

Note this will stop a SNORT instance detecting this traffic for all hosts it scans – be sure this is what

you want!

When you get an alert, you will be able to track down the rule via its Class, SID and description:

Note: If you use the ‘red X’ in the alerts tab, this will remove the rule – which may be a problem if

you later wish to re-instate it.

For the above rule, we can locate it within the correct instance (in this case WAN), then the rules

tab:

Then change the category to match the start of the rule description:

Page 15: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

A quick search should then show you a rule matching the SID shown in the alert:

Note the ‘SID’ in the alerts tab is actually the GID and SID,

So in our example, the alert SID is: 1:2402000, which corresponds to GID = 1 and SID = 2400200.

The GID doesn’t always correspond to a ruleset category, so you’ll need to use the description to

help narrow things down.

Once you’ve found the rule you can disable (not remove) the rule using the red X on the left:

Note how disabled rules are greyed out with a yellow ‘X’. If you disable a rule, you can confirm this

be returning to the alerts tab:

Note how the SID now shows a yellow X, to show it’s been user disabled (rather than disabled by the

ruleset provider level, which would be a pale red ‘X’).

If you made a mistake, you can re-enable it here on the alerts tab, by clicking the yellow ‘X’.

Page 16: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Suppressing rules

Disabling a rule is easy, but not can be risky if the rule is useful for blocking bad traffic.

Sometime you want a single host (or subnet) to be allowed to pass traffic, which is where

suppression is handy.

A suppression rule will allow SNORT to continue using the rule and show alerts, but it won’t block

traffic which matches your suppression rule.

To create a suppression rule, find an alert with traffic you want to supress, eg:

You now have three ‘ ’ buttons to create suppression rules, in the following columns:

Source – will create a rule, to supress traffic from this source for this rule.

Destination – will create a rule, to supress traffic to this destination for this rule.

SID - will create a rule, to supress all traffic for this rule.

The last rule seems a bit pointless, you might want to disable the rule instead. Although you will still

get alerts from SNORT, which may be useful.

As an example, we’ll create a suppression rule for the destination:

Page 17: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

If we look in the suppression tab:

Then edit the list, we will see our new rule at the bottom:

Note how the rule description is entered as a comment.

You can amend this list as you wish, entering comments with a ‘#’ to help you refer back.

The SNORT instance will need reloading if you amend the suppression list (as with most SNORT

config changes) before the change will take effect.

You should check your SNORT logs, in case you made a syntax error, is SNORT has problems starting.

The rule can be easily broken down and changed here:

suppress gen_id 141, sig_id 1, track by_dst, ip xxx.xxx.xxx.xxx

Page 18: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

The suppression rule is just a SNORT command:

Rule breakdown Note

suppress As it says this is the start of a supress statement for SNORT

gen id 141 This is the GID for the rule

sig id 1 This is the SID for the rule

track by dst Asks SNORT to match the destination address

ip xxx.xxx.xxx.xxx Asks SNORT to match an IP for the destination above (actual IP replaced by x’s).

Example 1: By removing the end of the rule( , track by_dst, ip xxx.xxx.xxx.xxx ) you’ll then change

the suppression rule to not matching destination IP and thus it will supress the rule for all traffic:

suppress gen_id 141, sig_id 1

Example 2: You can match more IPs by adding extra IPs (space separated) or whole subnets:

suppress gen_id 141, sig_id 1, track by_dst, ip xxx.xxx.xxx.xxx yyy.yyy.yyy.0/23 zzz.zzz.zzz.zzz

Example 3: You can change the rule to match by source instead:

suppress gen_id 141, sig_id 1, track by_src, ip xxx.xxx.xxx.xxx

Page 19: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Is it bad traffic or not?

Determining what is bad traffic is tricky.

I usually try:

If it’s block with the “Dshield Block” or “ET COMPROMISED” list it’s almost certainly bad.

Thease are IP black lists.

Can you resolve the IP address to a DNS name, if not it’s probably not good.

Does the rule mention ‘possible’ or ‘unknown traffic’ – this maybe harmless if the case.

Try and track the IP, to identify is possible the user – this may help identify the traffic.

The rule description goes a long way here – google it to find more info.

Some rule sets have comments for rules as well (not many!).

Put the IP into a reputation search (there are many online and some show registered

address block owner and geo-location).

Is it from china…? Some locations are more fishy.

Page 20: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

Keeping an eye on your servers resources (swap swap swap)

The more you load onto SNORT the more likely you are to eat RAM and CPU cycle.

If your firewall slows down, you’re likely running into SWAP – bad news!

You can easily see SWAP usage on the dashboard:

Each time SNORT reloads (usually due to config changes or scheduled rule updates) there is a chance

the old instances of SNORT did not stop running before the new ones started.

Check Diagnostics then system activity tab to see how many SNORT instances you have running:

Page 21: Extending pfSense with SNORT for Intrusion detection ...users.ox.ac.uk/...pfSense-with-SNORT-for-Intrusion-detection.pdfExtending pfSense with SNORT for Intrusion detection & prevention

If you have too many, either reboot or use a terminal to kill all instances of SNORT.

If you want to Kill snort (least disruptive), you can log on via SSH1 (if SSH is enabled) and use the

following command:

pkill -9 snort

Then you can start you’re SNORT instances up at the SNORT interfaces screen by clicking on the red

‘X’ icons – which should turn to green chevrons ( ).

1 Enable via System interface, then Advanced, scroll down to secure shell and tick enable. You’ll need an allow rule in firewall rules for your LAN as well.


Recommended