Extending 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

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 Snort Community Emerging Threats ET Open Emerging Threats ET Pro Free account (requires sign up for code), with commercial version available. Free Free Commercial only. Commercial version provides more up to date rulesets. Now included in SNORT community rules 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: WAN SNORT instance in IPS mode for blocking bad traffic/hosts. Bridge SNORT instance in IDS mode for testing rulesets. LAN 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:

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) emergingattack_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. emerging-worm.rules To try and stop worms spreading. snort_botnet-cnc.rules N/A Defunct snort_ddos.rules N/A Defunct Very useful is you are firewalling webservers. General anti-virus.

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 suppress gen id 141 sig id 1 track by dst ip xxx.xxx.xxx.xxx Note As it says this is the start of a supress statement for SNORT This is the GID for the rule This is the SID for the rule Asks SNORT to match the destination address 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 SSH 1 (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.