Upload
dotruc
View
303
Download
4
Embed Size (px)
Citation preview
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
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.
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.
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.
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).
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
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.
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.
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).
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
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.
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.
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.
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:
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’.
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:
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
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
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.
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:
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.