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

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.

2018 soon and still stuck using CLI ... 

Would you happen to have a list of those commands ?

Thanks

Hundreds of "allowed" traffic on the clean up rule today.

To update the thread in regards to the allowed traffic that Big_Buck was experiencing, we were able to perform a remote session together to further investigate.

The traffic that was being passed was his local Sophos Access Points communicating with the internal Sophos XG interface to establish a tunnel. The XG will listen for this local access point traffic regardless of what firewall rules are in place. With the clean up rule disabled, the access point traffic was still being allowed and received by the XG by the default rule 0. It was just interesting that the traffic was matching to this cleanup rule when viewed in the log viewer. Perhaps because the rule is encompassing "any>any". I have noted this and will followup to attempt to replicate with our internal team to report.

The other traffic that was being allowed was ICMP pings, however this may have been caused due to Pings being allowed on the WAN zone via the local service ACL.
We also disabled this during our troubleshooting call which I hope will resolve this.

Regards,

FloSupport | Community Support Engineer

The official CLI documentation is here:

Sophos Firewall Command Line Reference Guide v16.5

Also there's a bunch of logfiles in /var/tslog. awarrensmtp.log and awarrenmta.log in particular are useful for Legacy Mode and MTA Mode troubleshooting respectively.

tl;dr

Log Viewer misrepresents what's actually happening.

Use other tools (e.g. Console, Advanced Shell) to see what's really happening.

FloSupport said:

To update the thread in regards to the allowed traffic that  was experiencing, we were able to perform a remote session together to further investigate.

The traffic that was being passed was his local Sophos Access Points communicating with the internal Sophos XG interface to establish a tunnel. The XG will listen for this local access point traffic regardless of what firewall rules are in place. With the clean up rule disabled, the access point traffic was still being allowed and received by the XG by the default rule 0. It was just interesting that the traffic was matching to this cleanup rule when viewed in the log viewer. Perhaps because the rule is encompassing "any>any". I have noted this and will followup to attempt to replicate with our internal team to report.

The other traffic that was being allowed was ICMP pings, however this may have been caused due to Pings being allowed on the WAN zone via the local service ACL.

We also disabled this during our troubleshooting call which I hope will resolve this.

Regards,

FloSupport | Community Support Engineer

This is one thing I really think Sophos XG needs - the ability to see ALL firewall rules on the firewall page, not just user created. I created an entry on the Sophos Ideas page a few days ago if anyone else thinks this would be useful:

Would you please help.

I need to hear about how you do it.

Thanks.

PJR

I have re-opened the case today.

To clarify, here's a resumé of the clean up rule logs. As of 7th December.

1. With v17 MR1, I had various traffic allowed via CleanUp / DropAll rule up until the 27th November.
2. I upgraded from v17 MR1 to v17 MR2 on the 6th December.  But I reverted back to v17 MR1.
3. I noticed then traffic was allowed via CleanUp / DropAll rule up.  Far more than what I saw up until 27th November.
4. Sophos support looked at it, and we brought back both main firewalls to v17 MR2.
5. We disabled existing VPN IKEv2.  Created a new one with much the same parameters except for Gateway Settings' "Local Id" and "Remote Id" left untouched to default value. (i.e. blank)
6. Main VPN worked under v17 MR2.

Then we looked at what was happening with logs related to the CleanUp / DropAll rule

1. Most allowed traffic generated in CleanUp / DropAll rule originate from three AP55c antennas from LAN Network to LAN address of the firewall on port 8474.
2. Some WAN ICMP traffic is allowed to a WAN address behind which one of our network is NATed.  Not the same WAN address as our firewall.
3. Some WAN traffic on port 6666 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
4. Some WAN traffic on ports 54680 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
5. Some WAN traffic on ports 10978 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
6. Some WAN traffic on ports 49977 is allowed to the WAN address of the firewall on port 8443.
7. Some WAN traffic on ports 53798 is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
8. Some WAN traffic on ports 10978 is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall
9. Some WIFI traffic on ports 43265 is allowed to  WAN on port 443.
10. Some WAN ICMP traffic is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall
11. et.c. et.c. et.c.  Many more.  There's traffic generated on most of our WAN ip addresses in fact.

For all of the above:

1. Ping is not allowed via ACL.
2. Sometime the destination port is blank, sometime it is port 2 (WAN)
3. Sometime the originating port is port 1, sometime it is port 2.

 The problem is worsening.

I have re-opened the case today.

To clarify, here's a resumé of the clean up rule logs. As of 7th December.

1. With v17 MR1, I had various traffic allowed via CleanUp / DropAll rule up until the 27th November.
2. I upgraded from v17 MR1 to v17 MR2 on the 6th December.  But I reverted back to v17 MR1.
3. I noticed then traffic was allowed via CleanUp / DropAll rule up.  Far more than what I saw up until 27th November.
4. Sophos support looked at it, and we brought back both main firewalls to v17 MR2.
5. We disabled existing VPN IKEv2.  Created a new one with much the same parameters except for Gateway Settings' "Local Id" and "Remote Id" left untouched to default value. (i.e. blank)
6. Main VPN worked under v17 MR2.

Then we looked at what was happening with logs related to the CleanUp / DropAll rule

1. Most allowed traffic generated in CleanUp / DropAll rule originate from three AP55c antennas from LAN Network to LAN address of the firewall on port 8474.
2. Some WAN ICMP traffic is allowed to a WAN address behind which one of our network is NATed.  Not the same WAN address as our firewall.
3. Some WAN traffic on port 6666 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
4. Some WAN traffic on ports 54680 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
5. Some WAN traffic on ports 10978 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
6. Some WAN traffic on ports 49977 is allowed to the WAN address of the firewall on port 8443.
7. Some WAN traffic on ports 53798 is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
8. Some WAN traffic on ports 10978 is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall
9. Some WIFI traffic on ports 43265 is allowed to  WAN on port 443.
10. Some WAN ICMP traffic is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall
11. et.c. et.c. et.c.  Many more.  There's traffic generated on most of our WAN ip addresses in fact.

For all of the above:

1. Ping is not allowed via ACL.
2. Sometime the destination port is blank, sometime it is port 2 (WAN)
3. Sometime the originating port is port 1, sometime it is port 2.

 The problem is worsening.

I'm back to MR1.

v17 MR2 have killed our access to Exchange OWA.

Too many problems with MR2.

This is nausea.

Hey Big_Buck

-Edited to correct my mistake-

Could you please also verify using the Packet Capture utility available in the diagnostic tools regarding this traffic?
Please also note the TCPdump tool available within the CLI. 

Thanks,

FloSupport | Community Support Engineer

/var/log does not respond.  Seems to not exist.

/var do exist and respond.

Hey Big_Buck 

Edit: My mistake and apologies, my mind was on another case/issue while I was responding. I mistakenly referenced the incorrect KB article and product.

Sent you a PM regarding this.

Hi flo,

not wanting to sound picky, but that looks and sounds like UTM not XG. No loginuser on XG.

Ian

I use putty 0.70 in SSH

There's no alternative but to log as "admin" (literally)  then punch the corresponding administrative password.  Unless I miss something.

 5850.untitled.txt 

Since nothing seems standard here, please reply and posts commands i could cut and paste on the telnet session.

PJR

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