The Intrusion Prevention System is only effective if you enable appropriate rules.
The more rules which are activated, the more likely you could find an intruder. However more rules means that you are more likely to see false-positive alerts and the more load put on IPFire. If IPFire is under high load, from processing many complex rules, it may affect the performance of your network.
Choosing rulesets and rules requires you to have a good understanding of your network. It is very helpful, but not required, to be familiar with historic security vulnerabilities (especially those which were given fancy names, like Heartbleed and EternalBlue) and aware of penetration testing tools (like Metasploit).
This is not a simple process and it will take some time to come up with appropriate configuration to suit your needs.
Developing an appropriate Ruleset
Summary
- Understand your network
- Enable an appropriate ruleset category
- Monitor for activated rules (alerts)
- Investigate alerts
- Act on legitimate alerts
- Disable rules which cause false-positive alerts
- Once there are few false-positive alerts enable another ruleset category. Then repeat step 3.
- Once all useful ruleset categories have been enabled choose an enabled category then investigate rules it provides which were disabled by default (ensure you have not disabled them previously). Enable those which sound appropriate for your network. Repeat step 3
- Once you are confident all rules useful have been enabled, check regularly for new rules added in updates. Never stop monitoring! Repeat step 3.
Step 1: Understand your network
In order to select the right rules for your network you need to understand the systems and applications on it.
- Make a list of all Operating Systems on your network, including those of Mobile devices and IoT devices (if applicable)
- Make a list of major applications used on your network, making special note of those which offer services to other systems or out to the internet. For example, web servers, database servers, directory servers and file servers.
- Find out how access to shared services is controlled. Are any services inside your network exposed to the internet or to other networks through IPFire?
- Some examples; A web server which only serves a local network as both the OS firewall and IPFire prevent external access, may not require web server rules to be active. This is because the system is effectively isolated already. If a system has database software but the database is not exposed to the network at all, then there is little reason to enable rules to detect suspicious database connection attempts.
Step 2: Enable an appropriate ruleset category
IPFire has a variety of rulesets to choose from. Some are more optimised protecting towards servers in Data Centres, while others have rules to detect malware on client computers and mobile devices. Selecting a ruleset and rules requires detailed knowledge of the systems and applications used on your network.
| Note! |
|---|
| It may be wise to enable "Monitor traffic only" mode when starting out if you find IPS rules are regularly causing legitimate traffic to be blocked. When time has passed and you have tuned your rules you should select "Enable Intrusion Prevention System" in the UI. |
- If you are starting out and have not yet investigated a professional (paid) ruleset from Talos VRT (Snort) it is generally best to start with a simpler ruleset like that provided by Open Emerging Threats, (called the "EmergingThreats.net Community Rules" in IPFire). Note that EmergingThreats is often referred to by the acronym "ET".
- When starting avoid ruleset categories which just include blocks of IP addresses, like the ET "ciarmy.rules" and "dshield.rules". These are lists of internet systems which have been detected generating malicious traffic. When they are enabled you will frequently see alerts, however they are all likely to be false-positives as these suspicious systems frequently scan the internet for vulnerable services.
- It is also best to initially avoid ruleset categories designed to apply a restrictive corporate policy, like the ET emerging-policy.rules ruleset. These kinds of categories must be tuned or they are likely to block legitimate traffic and cause false-postive alerts. For example, by default the emerging-policy.rules category blocks common Linux package management tools from accessing the internet, preventing legitimate OS updates.
| Note! |
|---|
| Never enable all rules in a category. This will slow down your network and will generate many false-positive alerts. |
- It is usually best to gradually enable one category a day, while regularly the IPS Log Viewer for activated rules.
- When you enable a category in the IPFire UI only some rules are enabled by default. These are the rules the ruleset provider considers most common or most valuable. When starting do not enable more rules than these, but instead consider which of the enabled rules you can disable.
- Use the information you gathered in Step 1 to consider what you need to protect on your network. Rules that can block Ping of death on systems running the BSD operating system should be disabled if you do not have any BSD systems on your network. Similarly if you are not running an open database server in your local network, there is no benefit in enabling rules for malicious MySQL traffic. Finally many rulesets have rules for old security vulnerabilities. If you don't have any old MS Windows systems you could disable rules which only apply to older Windows operating systems.
| Note! |
|---|
| When first enabling a new category of rules carefully read the name of all the rules which are enabled by default and check that they won't prevent legitimate traffic on your network |
Step 3: Monitor for activated rules
Regularly check the IPFire IPS Log Viewer for activated rules and very high CPU usage.
- When you start out you may get many rules activate each day. This could mean you are under a sustained attack, but is usually because you have not yet tuned the rules to avoid false-postive alerts. If you're unsure, ask a security professional.
- Every time a rule is activated take the time to understand what it means. IPFire has a link to the ruleset provider's documentation in the SID field, but this may be very limited or even confusing. Search the internet for words used in the rule name or search for the IP port. You need not understand the syntax of the rule itself.
- If an activated rule sounds like a legitimate security concern, inform the owners of the effected system, or if you are responsible patch or isolate the system from the network (depending on the severity).
- Note: The severity the ruleset provider puts on a particular rule may not correspond to the impact the rule will have in your network.
- If no rules have been activated and you want to ensure the IPS is working, enable an IP blocklist (like the ET dshield.rules) for an hour. Most internet connected systems should see at least one rule activated in that time.
- If CPU usage is very high for a long period of time you should try to identify rules which are less likely to be important on your network and disable those rules. Sustained high CPU usage will impact the performance of IPFire and slow down internet access.
| Note! |
|---|
| If you are not certain what rules to use have a professional consultant advise you on how to best protect your network. |
Step 4: Enable another Ruleset Category
- After some time has passed (a day to a week, depending on the complexity of your network) and there are few false-positive alerts, enable another category.
- Then repeat step 3 (above).
Step 5: Enable disabled rules in existing categories
- After you have found and enabled all categories which appear appropriate for your network and are no longer seeing many rules activated each day, go back through each category and look for additional rules which may be appropriate.
- Then repeat step 3 (above).
- Look for rules which were not enabled by default in the category.
- Be careful not to re-activate rules you've previously investigated and disabled.
- Keep in mind that many rules which are disabled by default are for older exploits and may no longer be very useful.
Step 6: Check for new rules
- New rules are added regularly to categories, which is why they are updated often. Check regularly for new rules added in updates, enable them if they seem appropriate.
- Then repeat step 3 (above).
| Note! |
|---|
| Although an IPS is designed to provide automated protection, it is of limited benefit unless activated rules are investigated! |
Rule Categories
This is a brief list of some categories these rules come in:
Attack Response Rules, Command & Control Rules, Compromised Rules, Exploits
These are designed to catch the results of a successful attack. If a host is already infected, it will stop it from reaching out to their command and control servers and block attacks from known compromised hosts on the Internet.
Current Events
These are rules that block access from and to resources that are currently malicious but won't be for a longer time.
DoS & DROP Rules
These are to mitigate any Denial-of-Service attacks on your network or block whole address ranges that are known to be malicious.
Policy Rules
There is groups of rules that are not necessarily malicious, but might be unsuitable for certain environments. Examples are gaming, P2P and chat protocols, and pornography.
Scan Rules
Made to detect if someone is trying to collect data about your network.
OS, Browser, App & Protocol Rules
These rules scan traffic for exploits for certain operating systems, browser types or other applications. Should be enabled when you have client computers on your network.
The protocol rules work for clients and servers and try to detect if an attack is run by exploiting a vulnerability in a protocol.
Server Rules
These are there to protect your servers. There might be different categories for web, mail and others. You will only need them if you are hosting a server locally.
These rules might only be effective when they have access to the plaintext protocol. That means that HTTPS connections cannot be scanned, but if the TLS termination is happening on the firewall itself, it would have access to the unencrypted HTTP stream.
File Rules
Not necessarily malicious again, but there to detect transferring certain file types which can be blocked.