Hello Can anyone explain that to me ?
I have a clean up rule (no 3) "from any, to any, drop" that allows traffic on the Internet anyway !!!. See the rule and the log below.
Is it me, or this is a very serious issue ?
Hello Can anyone explain that to me ?
I have a clean up rule (no 3) "from any, to any, drop" that allows traffic on the Internet anyway !!!. See the rule and the log below.
Is it me, or this is a very serious issue ?
Big_Buck,
In your first photo where you are creating the firewall rule, look at Action (under Rule Name at the top). The Action is the clean up rule. You must choose to ether Accept all or Drop All or Reject all. This means that anything that is not covered in the Advanced section (lower down) will either be Accepted, Dropped, or Rejected (whichever you chose).
Hello David,
In the case of a "Drop" or "Reject" rules, this "Avanced" section as well as the "Web Malware and Content Scanning" will not shop up. i.e. It shows up only on "Accept" rules. So, how can your statement: "In other words, There are basically two general ways to set up a firewall rule in XG. You can set Action to Drop/Reject all with the Advanced section identifying traffic to Allow." work ?
PJR
Big_Buck said:Hello David,
In the case of a "Drop" or "Reject" rules, this "Avanced" section as well as the "Web Malware and Content Scanning" will not shop up. i.e. It shows up only on "Accept" rules. So, how can your statement: "In other words, There are basically two general ways to set up a firewall rule in XG. You can set Action to Drop/Reject all with the Advanced section identifying traffic to Allow." work ?
PJR
Yes, that is strange.
According to your log (in your photos), Firewall Rule 3 is allowing some traffic. Have you checked Firewall Rule 3 or any other firewalls rules to see if those sections are missing from those rules too? Without those two sections, your firewall will allow all traffic and may not be scanning anything.
Have you tried making a new User/Network Rule? If you have tried making new firewall rules and those sections are still missing, I would contact Sophos Support: https://www.sophos.com/en-us/support.aspx
rfcat_vk said:Hi David,
did you see the detailed response above from deepit?
Ian
Ian, yes I did.
deepit describes a situation where you have two firewall rules with different Identity settings. Rule 1 is based on the default setting of Match known users in the Identity seciton. Rule 2 is not matching known users. Deepit describes the outcome I would expect on that setup.
Based on Big_Buck's photos, there are at least 3 firewall rules on Big_Buck's firewall, but the settings for those are unknown. This means we have no idea if deepit's situation applies.
Hi David,
where I am having trouble with Big_Bucks drop everything rule is it does not hide all those extra bits you are pointing to. I posted my original drop all rule which I have since removed (you can see it in an earlier post in this thread) and it does not have any extra fields as a normal rule does.
I have just created it again and still no extra (advanced ) fields. I changed the rule to accept then updated all the missing fields to drop all and added MASQ and a gateway, then saved the rule. Edited the rule and changed it to drop and all the advanced features were gone again.
Some wild thoughts, if you filled in all those fields before making the rule a drop rule what happens to the values, does the drop rule acttually empty those fields or just mask them? If so what is the likely affect?
Ian
It is VERY logical to me the "Advanced" section disappear on a drop rule. If you drop it, you will not perform any function listed in the "Advanced" section anyway !!! Why would you scan a packet destined to be dropped ? So why show the "Advanced" section then ?
PJR
rfcat_vk said:Hi David,
where I am having trouble with Big_Bucks drop everything rule is it does not hide all those extra bits you are pointing to. I posted my original drop all rule which I have since removed (you can see it in an earlier post in this thread) and it does not have any extra fields as a normal rule does.
I have just created it again and still no extra (advanced ) fields. I changed the rule to accept then updated all the missing fields to drop all and added MASQ and a gateway, then saved the rule. Edited the rule and changed it to drop and all the advanced features were gone again.
Some wild thoughts, if you filled in all those fields before making the rule a drop rule what happens to the values, does the drop rule acttually empty those fields or just mask them? If so what is the likely affect?
Ian
Ian,
I see what you mean. I just tested Drop/Reject on my XG Firewall, and yes, it is doing the same for me too. I don't remember this behavior before. I don't know if this is a design change or an issue.
The problem I am having now is: How can one have a Drop/Reject all rule (without exceptions) after an Accept all rule (with exceptions) on the same interface? That doesn't seem functional nor logical. It seems to me that whichever rule is in higher priority will trump and cancel out the rule of lower priority. It would be easier to create a a single Drop/Reject all rule with policy exceptions for Allow.
If you don't have exceptions for a Drop/Reject all firewall rule, then that interface won't allow any communications at all. You might as well remove that interface or turn it off.
The point to my earlier comments was that an individual "clean up" rule is pointless since a clean up provision is included in each and every "normal' firewall rule. Next Generation Firewalls allow IT managers to create combined policy firewall rules. You can create one firewall rule for each interface that can be as simple or complex in policies as you need it to be. Everything is included in this one rule for the interface, so you can create complex protection yet still be granular in design and troubleshooting. You can create an Allow all rule with exceptions of what you want to Deny, or you can create a Deny all rule with exceptions of what you want to Allow.
"Clean Up rules" are old techniques from when firewalls did not combine policies. You had to create/choose policies and manually order them in priority to create an "if this, then that" sequence to create your "rule". Then, you had to write a "clean up" procedure to protect yourself from anything you could not think of. The "clean up" technique is still used by those few customers who migrated from old firewall setups and don't need to rewrite their firewall rules/policies or don't want to.
Has Sophos gone back to that bygone era in the XG Firewall?
Hi David,
that configuration of the drop rule has been that way for a number of releases, I have two drop bad guy i/c and o/g) rules at the top of my rule list and they have as long as I can remember been like that, doesn't mean they work though, still waiting for that fix.
I had a rule based on some sophos trained wizkids recommendations, but since then Flo has advised there is a default drop any leftover traffic rule (0) and an implicit rule is not required, so I removed mine.
Ian
rfcat_vk said:Hi David,
that configuration of the drop rule has been that way for a number of releases, I have two drop bad guy i/c and o/g) rules at the top of my rule list and they have as long as I can remember been like that, doesn't mean they work though, still waiting for that fix.
I had a rule based on some sophos trained wizkids recommendations, but since then Flo has advised there is a default drop any leftover traffic rule (0) and an implicit rule is not required, so I removed mine.
Ian
Ian,
Yes, exactly. If you don't have any rules in your XG Firewall, nothing flows through it. This is consistent with the basic design and function of a firewall.
So why even have a Drop/Reject all rule with no exceptions sit on top of the default Drop/Reject all design? Why even have a choice of Allow/Deny in the policies? The policies should all be Deny, because apparently, they only go with the Allow rule.
This must be an issue. I don't remember this being this way when I converted from Sophos UTMs to Sophos XG Firewalls several months ago.
rfcat_vk said:Hi David,
that configuration of the drop rule has been that way for a number of releases, I have two drop bad guy i/c and o/g) rules at the top of my rule list and they have as long as I can remember been like that, doesn't mean they work though, still waiting for that fix.
I had a rule based on some sophos trained wizkids recommendations, but since then Flo has advised there is a default drop any leftover traffic rule (0) and an implicit rule is not required, so I removed mine.
Ian
Ian,
Yes, exactly. If you don't have any rules in your XG Firewall, nothing flows through it. This is consistent with the basic design and function of a firewall.
So why even have a Drop/Reject all rule with no exceptions sit on top of the default Drop/Reject all design? Why even have a choice of Allow/Deny in the policies? The policies should all be Deny, because apparently, they only go with the Allow rule.
This must be an issue. I don't remember this being this way when I converted from Sophos UTMs to Sophos XG Firewalls several months ago.
Hi David,
I have been using XG since V15 and UTM since v4.
I have country blocking at the top in XG whereas the UTM country blocking is an integral part of the firewall function. So there is a requirement in XG for allow and drop and reject rules.
Ian
rfcat_vk said:Hi David,
I have been using XG since V15 and UTM since v4.
I have country blocking at the top in XG whereas the UTM country blocking is an integral part of the firewall function. So there is a requirement in XG for allow and drop and reject rules.
Ian
I've been using the XG Firewall since it came out. I tested SG UTM version 1 and deployed my first UTM as version 2 getting ready for release.
Both are very good at what they are designed to do. The XG Firewall is just more advanced on many levels.
Sometime around SG UTM 3/4, Sophos acquired Cyberoam, which was used to integrate SG into XG. Country blocking is an integral part of the XG Firewall too. Like all firewalls, the XG Firewall will Drop/Reject all traffic by default.
In the SG UTM, the default went back and forth between Allow All to Block All from version 1 to version 2. In version 3, Sophos got smart. A default could be chosen among several options at initial deployment, and this could still be changed after deployment.
The beauty of this is being able to set a default of Block All and setting Allow for the specific websites, applications, and services absolutely necessary. Apparently this is not possible in XG right now. The only way to allow traffic through the XG Firewall is to create a firewall rule with Action set to Allow all, and then, re-Deny what is not wanted. This seems counterintuitive.
