This documentation is now absolute since the IDS has been replaced with our new IPS.
An Intrusion Detection System (IDS) is a program or a framework supposed to detect, analyse and block network attacks. It does not replace a packet filter (which is enabled in IPFire by default, see Firewall Documentation) 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 is normally running on a firewall, gateway or dedicated server. IPFire features a NIDS.
A packet filter can be compared to a doorman: It has only limited information about a network packet, such as; source, destination and type. However, an Intrusion Detection System is more like a security guard, who is able to inspect the visitor for arms or spy tools. Further, the security guard has access to lists of wanted and other documents.
So an IDS is able to detect harmful network packets because of their content, because the source address appears in a blacklist or because the network traffic looks like a known attack. A packet filter (normally) is unable to operate at this level. Again, IDS and packet filter cannot replace each other, they are both important to provide a good level of network security.
The IDS used by IPFire is called Snort. Snort uses rules, which are combined in rule databases and can be downloaded from certain web sites. These rules contain patterns or blacklisted IPs.
There are four rule sources available:
There are some negative aspects when running an IDS. Most are not critical but some could prevent you from setting up the IDS on IPFire.
First, open the WebUI and go to “Services|Intrusion Detection”; the page is not a very big deal at this moment since the IDS is not running.
Second, choose the network interfaces you want the IDS to be active on. Usually, you might at least enable it for the RED interface since it should protect you against attacks from the internet. But also internal networks, such as GREEN and BLUE, can be monitored.
The more networks you check, the more system resources will be later needed for the IDS. Further, the rules you will activate in the next step will affect all activated networks.
Hit “Save” after you made your choice.
Choose the rule database you want to use from the dropdown box and enter the registration code in the input field, if necessary. Again, hit “save” for the changes to take effect.
Then, download the rule database by clicking at “download new ruleset”. This procedure may take a while; the actual speed depends from your internet connection speed and the clock speed of your CPU.
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;
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.
It is highly recommended that you also install and activate the Guardian Add-On.
An excellent answer from TimF
First some definitions for the sake of discussion:
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:
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:
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.
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:
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, 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:
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.