PLEASE READ Advisory: Kernel memory issue affecting multiple OS (aka F**CKWIT, KAISER, KPTI, Meltdown & Spectre) for the latest updates.
We'd love to hear about it! Click here to go to the product suggestion community
I see these 10 IPS Policies available with very minimal description for what they do, what situation they apply to, and their relative “strengths”. I assume strict is stronger than general.
1. DMZ TO LAN
2. DMZ TO WAN
3. LAN TO DMZ
4. LAN TO WAN
5. WAN TO DMZ
6. WAN TO LAN
8. lantowan strict policy
9. lantowan general policy
Are the Policies directionally dependent , meaning LAN to WAN differs from WAN to LAN? How? I have seen other posts saying the source and destination Zones do not matter as the reverse traffic is also checked according to the policy. Is this true, which would imply LAN to WAN and WAN to LAN are identical?
Do I need two firewall rules one applying WAN TO LAN and the other LAN TO WAN?
What is the difference between lantowan general policy and LAN to WAN?
What is the security level of generalpolicy relative to the others?
The Wizard created a default firewall rule using generalpolicy. Does that mean it is “good enough” for general use?
I have one web server in LAN exposed by a DNAT rule and chose to apply WAN TO LAN in that rule; however, I don’t know if that is the best choice. Is it actually doing anything with generalpolicy in the preceeding firewall rule?
I have seen several posts saying descriptions of these policies would be forthcoming, but I can’t find such a thing. I hope someone can and will do it in response.
Ok, I'll take a stab at this.
First off, let's look at the first six default IPS policies. If you open them, you will see that each policy contains filtered groups of policy rules based upon criteria which apply to the role of the policy. For example, the LAN TO WAN IPS policy contains groups of rules which would apply to clients on a LAN, whereas the WAN TO LAN IPS policy contains groups of rules which apply to servers on the LAN. Same for each of the others. Basically, pick the default IPS rule which best applies to the type of firewall rule you are using.
As far as the custom rules are concerned, it is my belief that they are all exactly the same. I deleted all of them for the sake of neatness. The only reason to create a custom IPS policy is to select a sub-set of IPS policy rules you may want to apply to a specific firewall rule. Most installations won't require this level of customization.
Older post but I will chime in. XG documentation leaves a lot of things half explained but it is really not that difficult. All the uppercase rules are templates with predefined rules already built in and you cannot edit them. Lower case rules let you fine tune the rules and there are a few general purpose policies already provided for most users that want to edit them.
In addition to what @steve foote already explained, I will try to answer in order of your questions above.
A snort (IPS) rule is written for external or internal interface most of the time so some policies are direction dependent. Zones have nothing to do with IPS as policies are applied on the interface hardware. So in general, LAN to WAN traffic rules include rules that affect your clients software in an effort to police what your client is communicating with the internet. A virus trying to send packets out to the internet would be blocked by a LAN to WAN policy for example.
WAN to LAN is used for servers mostly. This means that if you are running a web server or a mail server, you want to enable WAN to LAN rule on your business firewall rules. If you don't have a server in your LAN than it doesn't make much sense to scan for traffic for IIS since the firewall will block any unwanted traffic to port 80 anyway.
You do not need two IPS rules one for LAN to WAN and another for WAN to LAN. Most people will only need LAN to WAN rules period. Only people that need WAN to LAN are the ones that are running servers and have business rules opening incoming ports.
Lan to wan general policy is editable policy designed by sophos that monitors/blocks critical flaws in windows and linux browser/ftp/dns/Reconnaissance and malware communications. LAN to WAN is a template that you can use to create your own rules and modify them or use the template as it exists in a firewall rule. The template includes all the lan to wan general policy rules and also includes lower priority alerts and alerts for industrial control /ERP systems etc that you generally don't need in most environments.
General policy is good enough for general use. However I create my own policies most of the time since I don't have any linux boxes for web surfing so doesn't make sense to scan that traffic.
General policy will not protect your web server. You will need to use either WAN to LAN rule or create your own that scans the type of server you are running. For example you don't need to scan IIS traffic if you are running apache.
In reply to Billybob:
Any idea why the number of signatures in an IPS policy seems to have no affect on the performance of Snort/Sophos? Coming from any other firewall that uses Snort or Suricata, having more signatures reduces throughput which makes sense given the IPS is having to scan packets against more signatures in its rule set. I did a speed test using the pre-defined “lantowan_general” rule which has over 7,000+ signatures compared to a custom rule with only ~1,500 signatures and there is no difference in performance.
In reply to shred:
I agree with your observations. Even in SG, you have to carefully choose the IPS signatures so that you don't effect the throughput. Even with suricata, althouh it scales better than snort in my experience, you can still overload the firewall with too many signatures. Although suricata seems to handle them much better than snort does for some reason in the limited experience I have with suricata.
As far as the throughput bottle neck when using IPS, although XG is using snort, they are doing some thing in addition to regular firewalls including SG series. First, they use fast packet optimization https://news.sophos.com/en-us/2015/12/10/sophos-xg-firewall-innovations-fastpath-packet-optimization/ but I don't think that bypasses IPS scanning, only av scanning but I am not sure. Also, although a single stream speed test may indicate slower speeds with XG with IPS enabled, multiple instances of snort running on multiple cores does allow greater throughput with multiple streams.
Also keep in mind that even with minimal signatures, snort is still used for application classification instead of iptables layer7 classification which is used in SG. You can turn it off via console
set ips enable_appsignatures off
and test the throughput. Although doing this will disable your application classification rules, but if you disable IPS for better throughput, it maybe worth testing. You can also set multiple instances of snort if you have a powerful enough processor and enough ram to run multiple instances of snort
set ips ips-instance add
Other than that, only sophos can explain the nuances, but their documentation is severely lacking.
EDIT: XG does support autocomplete with tab and ? for help so you can write set ips <TAB> to get more commands and <?> will give you more help on the topic
Thanks for the reply - great info. With IPS turned off (set to “None” in the applicable firewall rule), I’m able to achieve maximum throughput of my internet connection which is 900 Mbps down. With IPS turned on (set to any policy), the throughput drops to 300 Mbps regardless if the IPS Policy has ~1,500 signatures or 7,000+. It just seems odd the speed stays the same with significantly less signatures.
This is all obviously on a single connection. Sophos XG by default created a snort instance for each CPU core. I’m not too concerned since I haven’t found a need for greater than 300 Mbps+ on a single connection (yet), but it’s just more for my understanding. Every other firewall I’ve used with Snort or Suricata behaves as expected in terms of more signatures = less throughput which logically makes sense as the firewall/CPU has to compare packets against more signatures.