Clean Up rule "from any, to any, drop" that's allowed on the Internet anyway !!! WTF ?

ChrisKnight said:

Yeah, this would be a serious issue if the Log Viewer was truly reflecting what's happening.

Unfortunately the Log Viewer is mostly broken and doesn't report correctly on what the device is doing.

If you want to really know what's happening access the XG Firewall via SSH and use the command line tools.

The GUI is useful for creating objects, rules, interface status and the occasional report. Serious log analysis using the GUI will just leave you frustrated, confused, no hair and an endless stream of swearing.

Hi Chris,

I'm really glad you posted this because I've had dozens of issues based on strange GUI log entries that I have placed into 1 of 2 large buckets: (1) Major defect; or (2) The device is lying to me...based on your post, seems like #2 is the winner.

Would you also say syslog reporting is erroneous as well? 

Also, and you may not know but would you say the UTM suffers the same lack of reliable logging?  Is this just that Sophos isn't making the best stuff?  Or is maybe the XG just still too green?

I really want to like the Sophos gear but boy if they aren't making it difficult...

here the command for TCPDUMP

tcpdump -i Portxx -w file.pcap -s0 -b

or just

tcpdump -w file.pcap -s0 -b

the file will be at /tmp because when you login to sophos and pick 5 and 3 will goes to /tmp folder. or just do

pwd

remember, at my /tmp partition, there only 5 Gig, so remove the PCAP file after you have tcpdump pcap file

the logs are at /log just do ls -la at root folder or

ls -la /

to move the pcap from XG just do

scp file.pcap root@xxx.xxx.xxx.xxx:/tmp

or using sftp whenever you like application and do analyze that pcap file from another machine

hope can help.

thank you

Thanks for this info.

Logs that indicates « drop traffic is allowed  anyway » happen mostly in « batch » with time in-between from minutes to hours.  Log file will eventually become gigantic.

Is it possible to dump logs on a USB key instead ? I could format a 64 gig USB key and plug into the appliance in seconds.

Windows SCP cannot connect to the XG210.  Connection is dropped.  Putty SSH putty works.  But not Putty sftp.  I have properly set things up in the XG210's administrative menu (ssh, https, et.c. are enabled.) 

PJR

Now I am getting ATP alarms !!!

Besides, allowed stuff can now be counted - excluding what is coming from our own network - at several hundreds.

​UTQ is also on alert mode.

"drop-all rule" has transported 13 meg of stuff today.  All desktops shutdown.

Really need to fix this log issue URGENTLY.

This situation is absolute non-sens.

​

you can not get the file from XG with traditional file transfer, try installing, winscp or filezilla server at the windows machine and turn off the windows firewall and transfer/send the file from XG to Windows, not from windows to XG.

yes ucan mount the USB for logging. just write the dump to usb that already mounted before with the command

tcpdump -w /mnt/file.pcap -s0 -b

My understanding by looking at the various scripts and binaries installed in SFOS is that pretty much everything is thrown into a Postgres database and all the reporting is done out of this.

Hence the Log Viewer is broken due to some god-awful SQL queries.

I haven't looked at the syslog stuff. If syslog is also chucked into the Postgres database then it also could be screwed over by poorly written SQL queries. If you want to make sure, shell into the box and filter /var/tslog/syslog.log.

The underlying Open Source components are all pretty robust. It's just unfortunate that it's either missing bits (like comprehensive IPv6 support and a solid, well tested MTA) or has some poorly written substitutes (hello warrenmta). We can all see how good the custom bits that sit over the top of it all go. You only have to read all these threads on the forums...

I don't know about the UTM unfortunately.

Ditto on your last sentence.

Hey All,

To hopefully give some more clarity regarding this "clean-up" rule behavior, I discussed this situation with a few senior engineers.

During my investigation with Big_Buck we noticed that the traffic entries shown as allowed on the log viewer by his any>any>drop cleanup-rule was traffic that should have been matched to the implicit any>any default rule 0.

The traffic included internal Sophos AP traffic communicating with the internal interface to establish a tunnel, external User Portal, and SSL VPN traffic that was allowed via local service ACLs. This traffic was accepted as the local service ACLs take precedence over the firewall rules. Normally this traffic is shown in the log viewer as being matched to the catch-all default rule 0. However, with the clean-up rule enabled, traffic is being shown as matching this explicit any>any rule and being allowed, thus causing the confusion.

As advised, this clean-up rule is unnecessary as any traffic not matching to a configured firewall rule is denied by the implicit default rule 0. If you would still like to create such a static explicit rule, it would be better to configure separate specific zone rules instead (LAN>WAN>Drop, WAN>LAN>Drop, DMZ>LAN>Drop). This would avoid the possible rule conflict and confusion being caused.

Regards,

FloSupport | Community Support Engineer

Hi FloSupport,

Did you raise an internal bug?

Because if we can only see the firewall rules we create and not the implicit hidden rules that are there, then the Log Viewer needs to consistently report ONLY against the rules we create.

If the confusion is being created because the Log Viewer is correctly reporting the policy behaviour of the visible AND hidden rules, then we need to be able to see ALL the rules so our world view of the rules and their precedence align with what Log Viewer is telling us.

I can't trust Log Viewer when analysis of underlying log files and command line output tells me something different (e.g. Log Viewer tells me an e-mail is sent correctly, while awarrenmta.log has logged delivery failure and remote mail server logs agree with what's in awarrenmta.log).

We thank you for looking at this, but what are we supposed to think here ? It's hard to rely and have confidence in a product that decides what's good for the user or not.

Again, if we compare with Checkpoint, they have many implicit rules, and we clearly see them in the rule set.  We can also manage them by activating it or not, and by defining if they are last, before last, first, et.c.  And it has been like this for three decades.  It is not like fresh news let's say ...

Sophos engineer is asking us to navigate blind.  We have no clue what's in the "0" rule, or where it is in the priority list.  Or how many of these "0" rules there are.  All logs related in the ACL seems to be dumped in the same can as the clean-up task's logs.  And all of this in a much broken fashion.  That is not desirable. clean, or in par with the industry's best practices.

Is this gonna be fixed ? 

Hey Big_Buck and ChrisKnight 

I will notify the appropriate team in regards to this issue. However, please visit this feature-request submitted by shred to our Sophos Ideas page and upvote it for more visibility in the meantime.

Regards,

FloSupport | Community Support Engineer