I believe I have observed a set of circumstances whereby the normal reporting/logging activity of the UTM perpetually elicits traffic from a remote host that generates Firewall violations. This appears to stem from a third-party DNS misconfiguration and from the UTMs ability to bypass its own filtering rules.
The situation appears to be produced by the following set of circumstances:
Country Blocking is enabled for Country X.
Server Y is delegated authority for a domain.
Server Y is delegated authority for the Reverse DNS Lookup zone for Server Y's IP address/subnet.
Server Y is in Country X.
Server Y is not running a DNS service or is refusing to respond to queries.
What appears to happen is that through web browsing or otherwise, traffic destined (i.e. a DNS request) for Server Y is generated. This traffic is blocked due to Country Blocking and is logged as a Firewall violation. Every 15 minutes /usr/local/bin/gen_inline_reporting_data.plx is run by cron. As part of this a reverse DNS lookup is performed for each IP address that generated a Firewall violation, either as a source or destination. As Server Y is listed against a Firewall violation, a reverse DNS lookup is initiated for its IP address. The UTM appears to generate DNS requests in turn, firstly to its local DNS cache, then to each of its configured forwarders and finally if a response hasn't been received, directly to the IP address of Server Y. Server Y fails to respond to the requests, and returns an ICMP Type 3 Code 3 (Port unreachable error). The UTM blocks this ICMP message from Server Y due to Country Blocking, generating a Firewall violation that will perpetuate this same cycle the next time the cron job runs.
There appears to be two issues here. The first is the DNS misconfiguration by the third-party, as this is outside of our control it needs to be accepted and handled correctly.
The second and more relevant issue is that under some circumstances the UTM apparently does not abide by the Country Blocking rules it applies to traffic from other hosts, otherwise the DNS request destined directly to Server Y wouldn't have been transmitted and wouldn't have elicited the ICMP T3C3.
Attempting to ping Server Y returns an error (Country Blocking appears to take effect):
utm:/root # ping AAA.BBB.CCC.YYY
PING AAA.BBB.CCC.YYY (AAA.BBB.CCC.YYY) 56(84) bytes of data.
From 192.168.1.ZZZ icmp_seq=1 Destination Port Unreachable
From 192.168.1.ZZZ icmp_seq=1 Destination Port Unreachable
From 192.168.1.ZZZ icmp_seq=1 Destination Port Unreachable
From 192.168.1.ZZZ icmp_seq=1 Destination Port Unreachable
...
^CFrom 192.168.1.ZZZ icmp_seq=1 Destination Port Unreachable
--- AAA.BBB.CCC.YYY ping statistics ---
0 packets transmitted, 0 received, +29015 errors
However attempting to nslookup Server Y appears to bypass Country Blocking and elicits 3 x ICMP T3C3, presumably the request is attempted 3 times before giving up:
utm:/root # nslookup AAA.BBB.CCC.YYY
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find YYY.CCC.BBB.AAA.in-addr.arpa: SERVFAIL
This leads me to believe there is an issue with the way Country Blocking is applied by the UTM.
This issue initially led us to suspect malware on several of the servers protected by the UTM, given that the Firewall violations were occurring on a roughly 15 minute cycle 24/7. The number of violations was amplified in our configuration due to the UTM using internal DNS servers as forwarders which resulted in multiple blocked DNS requests from the internal servers. The logging on the UTM isn't sufficient enough to diagnose where the DNS requests originated from, or to extract the content of the ICMP message. This meant we firstly had to enable debug logging on the internal DNS servers (which produced some unmanageably large debug logs - possibly we could have been smarter in the debugging we enabled). Once we had the UTM as a possible source, we had to resort to capturing traffic live on the UTM (which put it under a fair amount of strain and used a fair amount of disk space). This confirmed it was the UTM generating the requests, and then looking through the System Messages log showed the cron job coinciding almost exactly with the Firewall violations. I presume that this all started due to a user browsing the web and viewing a page that referenced a resource on a domain controlled by Server Y, and then once this was in the Firewall violations log the UTM perpetuated the cycle.
Does anyone know of a way to clear the Firewall violations list to prevent this IP address being looked up by the UTM each time the cron job runs? Ideally I would like to just remove the offending IP address. Alternatively is there a way to disable the UTM from attempting to resolve IP addresses to host names?
TIA
This thread was automatically locked due to age.
