Am I the only one plagued by this. 500 alerts in a couple of hours over a 10 year old vulnerability.
rule now set to drop and notify off. It is not one awsdns server. It looks to be all of them.
Details about the intrusion alert:Message........: PROTOCOL-DNS Microsoft Threat Management Gateway heap buffer overflow attemptDetails........: https://www.snort.org/search?query=57878Time...........: 2021-07-17 11:47:19Packet dropped.: noPriority.......: highClassification.: Attempted User Privilege GainIP protocol....: 17 (UDP)Source IP address: 184.108.40.206 (ns-220.awsdns-27.com)
As a mod, I see the IP from which you posted. It appears that there's a bad pattern in the update servers used by Nederland, UK and Deutschland. Hopefully, one of you already has opened a case with Sophos Support.
Cheers - Bob
thanks for your feedback, yes im sure that it is a false-positive.
I take it back - see my response to Robert. I think this is just an issue that occurs occasionally when requesting name resolution from remote name servers. No bad patterns at all.
At least here it happens much more than occasionally: I see approx. 40-60 IPS warnings per day, referring to this rule ID, caused by only 2 workstations. You are right: not all DNS queries/replies trigger the IPS event, but most of them.
As far as I can see from Google, "limando.de" and "rpe.dymatrix.cloud" do not sound dangerous. Therefor I guess these are false alarms. Or do I have any chance to check whether these alarms are indeed seriously?
Given these alarms are false alarms, I consider this to be a bug within UTM firmware or patterns. And this should be solved, because we can not check all these alarms manually. The alarm notifications do not even provide the host name that has been queried, therefor we have to check DNS server logs or whatever to find out whether new alarms are for the already known "false hosts" or for new hosts which might indeed be worth checking. Or we ignore all these IPS alarms or we disable this rule, but both does not really make sense.
The rule isn't triggered by the relative danger of an FQDN, just by the volume of packets received by the UTM from the remote name server.
I'm fairly certain that the rule is correct and that the problem is somewhere in the Internet between your UTM and the DNS server. You can disable this rule on the 'Advanced' tab of 'Intrusion Prevention' or make an Exception for traffic from the name server(s) causing the drop.
When capturing the DNS packets with tcpdump and taking a look into them with wireshark,wireshark is not complaining about them. However I don't whether would ever complain about the packet volume. The volume of these replies looks good, not bigger than other replies where UTM does not complain.
The issue arises for multiple provider DNS servers (different providers), but not for all queries for given DNS record.
Since the snort rule refers to "Microsoft Threat Management Gateway heap buffer overflow attempt" and we don't use Microsoft Threat Management Gateway, I will disable the rule.