Recently (2-3 days) I've noticed regular periodic spikes of Up2Date traffic. Checking the flow monitor, I see a 5-6MB/s spike tagged Sophos UTM Upd2Date every 25 seconds. The total (in Top Clients by Application) was 142GB just yesterday.
There's nothing unusual in the Up2Date log. Checks every 15 minutes with the occasional new pattern successfully installed. Nothing in the IPS log either except regular DNS Amplification Attacks every few minutes, but those have been happening for months.
I can't really see any way to debug this from within the firewall. Do I have to put a monitor on the outside interface and run a packet capture?
Thanks as always for suggestions,
I have found this community-entry:
Please take a look at this KB article.Email Catchrate issue on UTM 9.706 (sophos.com)The issue seems to be limited…
I found this, it may help: https://community.sophos.com/utm-firewall/f/hardware-installation-up2date-licensing/29103/up2date-generates-a-lot-of-traffic
UTM - 9.711 | Intel Xeon 4-core v3 1225 3.20Ghz 16GB Memory | 500GB SATA HDD | GB Ethernet x5
Thanks for the quick reply. I actually had seen that, but there's nothing there that twigs an Aha! moment.
Except that it makes me recall -- I've been using UTM since the V7 days -- where one could manually set the Up2Date URLs, but I can't seem to find that page anymore. Is it gone?
There's nothing in the GUI that you can do with that, but you might be able to do that via SSH. I don't know the procedure for it if it does exist. You can also go do download.astaro.com and grab the latest Up2Date files from there.
I’ve checked the source and it’s two different Akamai servers. Unfortunately that could be any number of things.
What happens if you set both the Firmware and Pattern download intervals to "Manual"?
Cheers - Bob
I have done so and that has fixed the issue! I had set both intervals to 1hr yesterday to see what changed, but hadn't thought to try manual. Will play around with permutations and report back.
Separately but conceivably related, I've also noticed the new spam filter SASI is frequently maxing out the CPU usage (using top in the shell). We're running on very old spare server boxes that could do with upgrading.
Okay, so it's the pattern updates that are causing this: with the firmware updates at 15 minutes and the patterns at manual, all is well.
Not sure what this could be, there's nothing at all between the UTM and the FTTN modem; and it's been happy that way for nearly a decade. Rebooting the UTM doesn't change anything. The unit should be upgraded / reinstalled anyway, so maybe I'll do that next weekend and see if the issue persists.
Very clearly controllable directly with the Automatic Pattern Update setting. Here's what happens with a reboot and turning pattern updates on after about three minutes, then off again two minutes later.
I've discovered that manual pattern updates aren't working. Pressing the manual update button says the update has been initiated, but the pattern remains 201081 even while the latest update ticks up by the hour (it's now at 201088).
I installed TLS Certificate in the SMTP proxy around the time this broke -- could that have broken the Up2Date authentication chain? How can I see more detail about the Up2Date failures? There's nothing in the logs but regular (non-)activity.
2021:06:21-12:31:08 forester audld: no HA system or cluster node
2021:06:21-12:31:11 forester audld: patch up2date possible
2021:06:21-12:31:11 forester audld: Starting Secured Up2Date Package Downloader
2021:06:21-12:31:12 forester audld: Secured Up2date Authentication
2021:06:21-12:31:13 forester audld: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful"
2021:06:21-12:36:04 forester audld: no HA system or cluster node
2021:06:21-12:36:11 forester audld: patch up2date possible
2021:06:21-12:36:11 forester audld: Starting Secured Up2Date Package Downloader
2021:06:21-12:36:14 forester audld: Secured Up2date Authentication
2021:06:21-12:36:14 forester audld: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful"
2021:06:21-12:41:06 forester audld: no HA system or cluster node
2021:06:21-12:41:11 forester audld: patch up2date possible
2021:06:21-12:41:11 forester audld: Starting Secured Up2Date Package Downloader
2021:06:21-12:41:13 forester audld: Secured Up2date Authentication
2021:06:21-12:41:14 forester audld: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful"
2021:06:21-12:51:02 forester audld: no HA system or cluster node
2021:06:21-12:51:07 forester audld: patch up2date possible
2021:06:21-12:51:08 forester audld: Starting Secured Up2Date Package Downloader
2021:06:21-12:51:10 forester audld: Secured Up2date Authentication
2021:06:21-12:51:10 forester audld: id="3701" severity="info" sys="system" sub="up2date" name="Authentication successful"
If I set the TLS cert in the SMTP proxy back to the WebAdmin cert, manual updates work again. Could the Up2Date servers be being given the SMTP proxy cert?
But it still doesn't resolve the broken Automatic Pattern Updates.
What happens if you follow Sophos UTM: Resolve WebAdmin CA cert not trusted by Chrome - does that give you the security you want in SMTP with the WebAdmin cert?
You may have the latest Pattern your system needs. What do you see with the following command?
grep 'action="download"' /var/log/up2date.log|more
The cert issue is a red herring, or at least not straightforward. Manual updates now work correctly regardless of which cert is selected for SMTP TLS. Perhaps this is due to a reboot last night. The big traffic spikes still occur whenever the pattern update is set to automatic.
In the meantime, I have no problem keeping the patterns up to date using manual updating -- it's just laborious, as they seem to come out with new ones every hour or so.