Up to this point we have our SFR passing the traffic and block only telnet to certain hosts. Now we will go a step forward and play around with the “Intrusion Prevention (IPS)” policy.
Our topology stays the same, but we will change the scenario a bit. On our laptop there is a FTP server installed which holds some important documents. Let’s pretend that this laptop is in fact a server. We will create a rule that will allow FTP access from outside network to this FTP server. Actually, this access is already granted by our current policy, but we don’t want to apply IPS policy to the default action, but rather to a custom rule we are going to make. We now know hot to create a policy rule, and the result of that rule creation should be something like this:
We added rule number two which says: allow all FTP application connections from the outside world to our FTP server and don’t do any further inspection. Let’s try our rule from some PC that sits outside of our protected network:
Here we can see that we first tried a FTP connection from 10.a.b.215 to 10.a.b.1 and hit the “Default Action” (the blue arrow). After we created our “WP FTP IPS ACCESS” rule and tried again, we hit that specific rule (the green arrow). This is the rule we will apply our IPS policy to.
We click “Policies->Intrusion->Intrusion Policy->Create Policy“. We give this policy a name and description, make sure that the “Drop when Inline” is selected and specify what this policy will be based on. We have several choices here and depending on our choice some rules will be enabled while others will be disabled. Some of them will have one action, another will have different action. The names are pretty descriptive. Let’s go with “Balanced Security and Connectivity” and click “Create and Edit Policy“:
Now the whole new world opens in front of us 🙂
We can see that, based upon our previous choice, this policy has 6536 rules, out of which 6428 drops and logs detected intrusion events and 108 rules just logs them. We can see the link “No recommendations have been generated. Click here to set up FireSIGHT recommendations“. We will deal with this later. What this link does is it applies recommendations based on the traffic the SFR has seen so far. When we deploy the SFR, it should monitor the traffic for a while. This way it learns about our network, hosts, operating systems, services and so on. When we decide to apply recommendations, FireSIGHT should not enable IIS signatures, if it detected only Apache web servers. Makes sense?
On the left, we can see the Rules section that we will be exploring in this blog, then again “FireSIGHT Recommendations” and “Policy Layers“. More about these last two in the next blog posts. For now, let’s just click “Commit Changes” and save our policy.
Remember, this policy is not applied to anything yet, so we need to edit our “WP FTP IPS ACCESS” rule:
Now we save our rule and apply security policy. We can see that our rule has IPS policy applied by looking at the color of the shield on the right hand side of the rule. If it’s yellow, then the intrusion prevention policy is applied. Before we test our protection, let me tell you what is our test plan: we will make a FTP connection to our laptop and list the current directory. This should work fine. Then we will try the old CWD ~root attack. In old FTP servers this allowed user to go to the root directory of the server. Now days FTP servers themselves don’t allow this, but this is the rule I like to use when testing IPS systems. So, let’s try this:
We can see that we pulled the attack off! Or should I say the IPS did not prevent it. This is because the signature for this attack is disabled. After all, the servers are no longer vulnerable to this attack. Let’s go back to our IPS policy and click Rules option from the top left. Now Rules sections opens and in the Filter field we type ~root and hit <ENTER>:
We can see the grayed-out-kinda-green arrow. This indicates that the rule is disabled. We select the rule, then the “Rule State” and select “Drop and Generate Events“:
Now we can see that the rule state has changed:
Finally, we need to save our changes. Let’s click “Policy Information” on the top left, and click “Commit Changes“. After the IPS policy changes are saved, we need to re-apply the access control policy. Under “Policies->Access Control” or “Policies->Intrusion->Intrusion Policy” we click the green check mark within the policy that is out of date. The out of date policy is marked with the red colored text “Policy out-of-date on n of m devices“.
Let’s go back to our FTP client and try our attack again:
Now we see completely different result. We can see that the SFR dropped this attack, which we can verify on our defense center.
So, our IPS policy works! Next time we will continue to explore intrusion prevention capabilities of SFR module.
Thanks for reading!