| # Intrusion Prevention System |
| # Intrusion Prevention System (IPS) |
| IPFire employs [Suricata](https://www.suricata-ids.org/) as IPS which is secure and fast. It is possible to analyse multiple Gigabit per second on a fast system and search for any malicious traffic. |
| ### How does it work? |
| In IPFire, the IPS supplements the packet filter by not only being able to classify traffic by IP address, protocol and port, but can also look into the packet. By decoding protocols like DNS, HTTP and many more, it can gather additional knowledge about the traffic and identify any unexpected behaviour. |
| Packets are being passed through the IPS before they are being sent to the firewall engine. However, the [](../geoip-block) is working in front of the IPS. If a packet is considered malicious it will be dropped by the IPS. |
| ### Disadvantages of an IDS |
| There are some negative aspects when running an IDS. Most are not critical but some could prevent you from using it on IPFire. |
| - An active IDS requires*a considerable amount* of system resources (CPU load and memory). In general, 2 Gigabytes of RAM and a fast CPU ([few faster cores are better than many slow ones](/hardware/mythbusters/single-core-performance)) should be there if you use an IDS. |
| - An IDS is not a magic bullet. Please use this guide to make your firewall system stronger against attacks: [](/optimization/start/security_hardening) |
| ## Configuration |
| The complete Intrusion Detection System can be managed by using the IPFire web interface. The configuration area is grouped into different sections for configuring the service and it's used ruleset, white-listing hosts and to manage the rules if a ruleset has been downloaded. |
| FIXME Add screenshot of main page |
| The first configuration area is used to managing the intrusion detection system and the monitored network zones. |
| The configuration of the IPS has a couple of different steps. On the main page, the system can be enabled or disable. |
| FIXME - Picture of the top (with configuration options) |
| At least one network zone has to be selected. All traffic coming from, or going to that zone is being passed to the IPS and being filtered. Traffic of deselected zones is passing through the firewall without scanning. |
| ### Activate Intrusion Detection System |
| ### Monitor Only Mode |
| By checking this checkbox, and hitting the save button, the IDS system will be launched, or if it is already running and unchecking the box, it will be stopped. |
| Traffic can also just be analysed, but the IPS will not take any action if a packet is considered dangerous. It will be logged, but will pass into the network. |
| ### Monitor traffic only |
| This is useful for debugging rulesets and when you are not sure if you are not accidentally overblocking. |
| When using this checkbox, network traffic still will be scanned, but **no actions against malicious activities will be performed**. |
| ### Whitelisting Hosts |
| **It is strongly recommended to keep this box unchecked, except you are really know what your are doing!** |
| In case of constant false-positives, hosts can be whitelisted. They will no longer be blocked when they are on this list. |
| ### Monitored interfaces |
| FIXME Screenshot |
| Depending on your local setup, a box for each [network interface](/installation/step5) will be displayed. By checking **at least one**, all network traffic arriving or passing this zone will be scanned by the IDS. |
| As well as hosts, networks (including subnet mask) can be whitelisted, too. |
| ## Ruleset settings |
| ## Rulesets |
| In this configuration area, all required settings for downloading, updating and of course, the used ruleset can be taken. |
| FIXME - Picture of the ruleset section |
| To get a ruleset, choose the desired one from the dropdown box and enter the registration code in the input field, if necessary. After that hit the "Save" button for the changes to take effect. The download the rule database automatically will be started and extracted. This procedure may take a while; the actual speed depends from your internet connection speed and the clock speed of your CPU. |
| ### IDS rules |
| This option allows to select which ruleset should be used. There are currently four sources available: |
| -*Emergingthreats.net Community Rules* -- They are free and community-maintained rules ([further information](http://docs.emergingthreats.net/)) and cover scanning activities, attack patterns agains various protocols, blacklists and more. No registration is required to use those rules. |
| -*Snort/VRT GPLv2 Community Rules* -- These are free and GPL licenced snort rules. Usually, the quality is good. Accoding to the [Snort blog](https://blog.snort.org/2013/03/the-sourcefire-vrt-community-ruleset-is.html), no registration is required. |
| -*Sourcefire VRT rules for registered users* -- These rules are usually more than 30 days old and can be used for free. Registration is required. Usually, the quality of these rules is a bit better than these of the*Emergingthreats.net Community Rules*. |
| -*Sourcefire VRT rules with subscription* -- Same as above, but they are chargeable and more current. These might be useful in productive environment, where you need reliable and up-to-date IDS rules. |
| ### Automatic rules update |
| FIXME |
| ### Oinkcode |
| This text field dynamically will be displayed when a ruleset is selected, which requires an oinkcode or any other kind of registration code. |
| ## Ignored Hosts |
| FXIME - Description - ignored means traffic of the host will not be scanned by the IDS |
| FIXME - Picture of the Ignored Hosts section |
| The ignore list easily can be manipulated by using the web interface. Existing elements from the list can be dropped by clicking the trash icon next to each. |
| A new entry can be added by using the input field and using the*Add* button. |
| Valid inputs are all kind of single IPv4 addresses or networks. Guardian accepts networks with an appended prefix (192.168.0.0/24) or netmask in dot-decimal notation (192.168.0.0/255.255.255.0). |
| FIXME OLD STUFF |
| #### Choose rules |
| This part is the most difficult: You need to choose which rules should be active. |
|  |
| This decision depends on the needs of your network (like operating systems in use, active services, protocols in use). Please refer to the homepage of your rule source to get further information about the purpose of some rule categories; |
| * [Snort](https://www.snort.org/rules_explanation) |
| * [Emerging Threats](http://doc.emergingthreats.net/bin/view/Main/EmergingFAQ#What_is_the_general_intent_of_ea) |
| Some rules are based on blacklists (such as the Emerging Threats CIArmy list) and indicate that a certain IP has a bad reputation for some reason. This does not necessarily mean that it attacked your firewall, in case it appears in the log files, unless it triggered some other rules. Nevertheless, it is usually safe to use IDS rules based on blocklists since they are very conservative most of the time, making blocking a legitimate IP address very unlikely. |
| We cannot give you any advice here. |
| Select the rules you want to be active by clicking at the checkbox. After that, hit the "update" button at the end of the web page. The IDS will restart now to apply the changes. |
| FIXME - Move the next stuff to an own wiki page |
| ## What rule provider is best and what rules are best? |
| An excellent [answer](https://forum.ipfire.org/viewtopic.php?f=27&t=21521#p119051) from **TimF** |
| First some definitions for the sake of discussion: |
| * **Ruleset** - a complete set of rules coming in a single download. Contains a number of rulefiles. These are what you select in the pull-down on the WUI. |
| * **Rulefile** - a set of rules that address a similar problem area. Contains a number of rules. These are what you select with the check-boxes in the WUI when the page comes up initially. |
| * **Rule** - a set of instructions for detecting a condition. |
| Note that rules are not necessarily independent - for example, a rule to detect malware in a PDF file will rely on another rule that detects that the traffic is actually a PDF file - if the latter rule isn't enabled, the former rule won't work. The basic detection rules are generally in*emerging-policy*,*emerging-info*, and*file-identify* (I think) - but there are other dependencies. |
| The rulesets are: |
| * **Talos VRT Subscription.** This is probably the best ruleset - apparently, they expend quite a bit of effort in order to ensure that the ruleset is of high quality. Downsides - it's generally only updated twice a week and you have to pay for it.*Note Talos VRT was formerly known as Sourcefire*. |
| * **Talos VRT Registered.** This a one month old version of the subscription ruleset. The quality is the same, you don't have to pay, but it is a month old. |
| * **Emerging threats open.** This is a free ruleset. It's smaller than the Talos VRT ruleset, and is therefore less comprehensive. It's updated every weekday. These rules are in rulefiles starting with *emerging-*' on the WUI. |
| * **Community rules.** While this is available separately, it's also included in all the other rulesets, although it's a month out of date in the Talos VRT Registered ruleset and of uncertain age in the Emerging Threats ruleset. Note that this ruleset is curated by Talos VRT. If you download this separately, these rules are in the rulefile *community.rules*' on the WUI. |
| Note that you can have multiple rulesets installed, which is why the available rulefiles doesn't seem to change when you download a new set. This isn't a problem, but if you really want to get rid of an old ruleset do the following: |
| `- Log on to the system via ssh.` |
| `- Delete the appropriate rule files from /etc/snort/rules:` |
| - Community rules -*community.rules* |
| - Emerging threats - rulefiles starting with*emerging-* |
| ` - Talos VRT - any other rulefile.` |
| - Edit* /etc/snort/snort.conf* and delete the include lines at the end of the file corresponding to the rule files you've deleted - **don't just comment the lines out.** |
| So, what ruleset should you use? For the sake of completeness (since other people might view this post later), I'll cover more scenarios than just yours. Note that you may well be constrained by how fast your IPFire computer is and how much memory it's got. |
| * **Large business/organisation.** You should either have your own cyber security team or a contract with a specialist company. Ask their advice - if they can't give it or can't explain it fire them and get someone better. The answer won't be 'load this ruleset on a computer running IPFire' (or if it is, fire them) - it'll be more complicated and, of course, more expensive. This is also the advice for any organisation where the consequences of compromise are serious (for example, hospitals, utilities etc), no matter what size. |
| * **Medium sized business/organisation.** Consider if you need a cyber security team, but the minimum would be the Talos VRT Subscription with a large number of rules enabled. If you're using my automatic update script you would be aiming to use the Security-over-Connectivity policy. |
| * **Small business/organisation.** Consider the consequences of a compromise. If they're serious, either to you or to someone else (don't forget your responsibilities under the GDPR), you should be using the Talos VRT Subscription, otherwise you may get by with either Talos VRT Registered or Emerging Threats. |
| * **Home use.** The Emerging Threats ruleset is probably sufficient, but you could use the Talos VRT Registered set. A Policy of Balanced-between-Security-and-Connectivity is probably sufficient. If you volunteer for a charity or similar and as a consequence keep either personal or financial information on your home network, you should consider the Talos VRT Subscription, but you should be eligible for the personal use license, which is much cheaper. |
| As well as this, if your computer has limited processing power or memory, it may tip the balance towards the Emerging Threats ruleset. |
| This is all in my opinion, and I am not a cyber security professional. |
| So what rules do I use? None of the above scenarios. Note that (probably due to security briefings long ago) I tend to be careful a little more careful than many people on these matters. |
| I run two IPFire systems: one at home, and one for a small charity. In both cases, I use the Talos VRT Registered, Emerging Threats open and community rules. I primarily use the Talos VRT set, with the community ruleset to bring the community rules up to date and then I add the emerging-current-events full file to address newer threats than the month old Talos VRT registered rules. In consequence, I have about 10000 rules enabled. I also run an IP blocklist (more on that later). |
| I have no problems with the Talos VRT ruleset. I think that the reason for the reports of problems is that the Emerging Threats rulesets, by default, has IP blocklist rules enabled. These generate an alert when a packet is received from one of the IP Addresses; you can get from several hundred to several thousand of these per day, however this is misleading because these packets would be blocked by the firewall anyway. If you disable these rulefiles you'll get very few rules alerting - most days I don't get any. This is a good thing - if you're getting several hundred alerts dues to IP addressing being blocked, it's unlikely you'll spot the small number of messages that tell you you've actually been compromised. The Talos VRT rulesets don't have equivalent rules enabled and so you don't get the large number of spurious messages. |
| Do you need IP Blocklists? If you're not exposing any services to the internet then probably not. The firewall's default rules will block any unsolicited traffic unless it happens to hit a port that's open due to an outgoing connecting, and in that case the application using the port will almost certainly reject the traffic. |
| If you're providing a service visible from the internet then a blocklist is probably a good idea. In this case rather than using the IDS rules I would use one of the scripts that are intended to install a blocklist in the firewall - this solves the problem of not being able to see important IDS alerts. There's at least three scripts about, but I can only find two at the moment: |
| *[forum.ipfire.org/viewtopic.php?f=50&t=15124](https://forum.ipfire.org/viewtopic.php?f=50&t=15124) |
| *[github.com/timfprogs/ipfblocklist](https://github.com/timfprogs/ipfblocklist) |
| The reason for not using the Emerging Threats rulefiles for doing this blocking is twofold: Firstly, it's inefficient - blocking using the firewall uses less memory and less processor power, and secondly, as mentioned above, you tend to get so many alerts triggered by these rules that you can't see the alerts you actually need to worry about. |
| What rulefiles should you enable? That's going to depend on the use you make of the system, the amount of memory you've got and the speed of your computer in reference to the speed of the internet connection. |
| In general, the Emerging Threats rulefile for a threat are will have fewer rules than the equivalent Talos VRT rulefile, so if you're short of memory or processing power go for the Emerging Threats version. I also don't see any point in including both the Talos VRT and Emerging Threats rules for the same topic. |
| So, go through the list of rulefiles and decide which ones are relevant to your situation. Bear in mind that you may have to include some rulefiles you don't expect, like the emerging-policy, emerging-info, and file-identify ones that are relied on by rules in other rulefiles. Also, I remember reading an article an number of years ago that WINE had advanced to the point where it was capable of running some Windows malware, so even if your computers are all Linux, it may be appropriate to enable some Windows rules. The same applies to Open/Libre Office and Microsoft Office - each can open the other's files. |
| In [this case](https://forum.ipfire.org/viewtopic.php?f=27&t=21521#p119029), the list of rulefiles looks reasonable, but you need to enable emerging-policy and emerging-info, and double check that you're not using both the Emerging Threats and Talos VRT versions of a rule. |
| Once you've set up some rules, let them run for a while and then check memory usage (Status -> Memory from the WUI). If it looks like you're running short of memory you'll have to use fewer rules. Also check the processor usage (Status -> System). Again, if you're running short of processor power you need to use fewer rules. |
| You also need to check for IDS alerts (Logs -> IDS Logs), preferably daily. You may well get the occasional report of malware from someone on the internet probing your system, but if you get lots of reports of malware then you'll have to track down the device that's responsible and clean it (which is another topic). |
| Finally, you need to keep your rules up to date. There are new threats appearing everyday, so this is vital. You can do this from the WUI by selecting the ruleset and then downloading it, or you can use one of the scripts: |
| *[viewtopic.php?f=27&t=8323](https://forum.ipfire.org/viewtopic.php?f=27&t=8323) |
| *[viewtopic.php?f=27&t=20965](https://forum.ipfire.org/viewtopic.php?f=27&t=20965) |
| If you use the last script it will remember the enable/disable state of individual rules and you can also select a policy which determines whether new or changed rules are enabled or disabled.. The drawback is that this script uses a lot of memory when it runs. Using the other script or a manual update will reset the enable/disable state of individual rules to a default (which corresponds to the policy balanced-between security-and-connectivity. This may or may not be a problem. If you find that something you are doing on your network triggers rules and that leads to guardian blocking the device, you then either have to use the second script or alternatively do manual updates and resign yourself to having to change the rule state each time. |
| I hope this helps answer your questions. Unfortunately, there's no simple answer, and you may well have to make adjustments to get everything working correctly. I had to do quite a bit of work initially, but now my systems are in a state where I just need to check the logs regularly, otherwise they run quite happily without my intervention. |
| ## FAQ |
| ### What is an Intrusion Prevention System? |
| An [](wp>Intrusion Detection System) (IDS) is a program or a framework supposed to analyze network traffic and to detect a certain attacks. It does not replace a packet filter (which is enabled in IPFire by default, see [](/configuration/firewall)) but can eliminate some limitations of it. |
| There are basically two types of IDSs: Host-based Intrusion Detection Systems (HIDS), which are running on a single computer, and Network-based Intrusion Detection Systems (NIDS). A NIDS is able to protect a complete network and traditionally is running on a firewall, gateway or dedicated server. |
| An second classification can be done by the taken action, if any intrusion has been detected. A typical IDS or NIDS reports and logs malicious activity but does not perform any kind of action against it. An [](wp>Intrusion Prevention System) (IPS), also known as Intrusion Detection and Prevention System (IDPS), is a program or security appliance that monitors network or system activities for malicious activity and log information about this activity, report it and attempt to block or stop it. |
| IPFire features a Network-based Intrusion Detection System with Intrusion Prevention System capabilities. |
| ## Further Reading |
| * [The Snort Cookbook](https://ssearch.oreilly.com/?q=Snort+Cookbook) |
| * [Overview of the Emergingthreats.net Community Rules](http://docs.emergingthreats.net/bin/view/Main/AllRulesets) |
| * [FAQ to the Emergingthreats.net Community Rules](http://docs.emergingthreats.net/bin/view/Main/EmergingFAQ) |
| * [The CIArmy list (blacklist)](http://cinsscore.com/#list) |
| * [Open Threat Intelligence](https://cymon.io/) |
| * [Mailing list for updates to the Emerging Threats IDS rules](https://lists.emergingthreats.net/mailman/listinfo/emerging-updates) |
| * [SpamHaus DROP list](https://www.spamhaus.org/drop/) |