-
Hi.
I found about 4 of these entries in the snort alerts, and they are sourced from the WAN IP.
"INDICATOR-COMPROMISE suspicious .null dns query"
I have snort's IPS policy set to security without blocking offenders, running on the WAN and DMZ interfaces. My pfsense version is 2.4.4-RELEASE-p2 (amd64)
The server in the DMZ is accessible from the Internet.
-
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
INDICATOR-COMPROMISE suspicious .null dns query
And what was the specific query for? .null is a valid OpenNIC tld - just because snort flags/blocks it doesn't mean its actually bad.. Something asks pfsense for host.domain.tld, then yeah its going to try and resolve or forward that query (based on your settings in pfsense) out its wan IP.
btw - moved your thread to IDS/IPS section.
-
I don't know the contents of the query, but all of the queries are not going to dns servers on have set on the computers or pfsense. I looked some of them up and some go to japan others to the netherlands.
-
And what are some of these IPs... Resolving which is pfsense default setting, then yeah the queries would go all over the globe as it "resolves" and actually talks to the authoritative NS for domain its resolving.
OpenNIC is not normal public domains from ICANN, etc. pfsense would not be able to actually resolve those, unless setup for OpenNIC.
-
202.12.27.33
193.0.14.129
198.41.0.4
199.9.14.201
192.36.148.17also I didn't setup anything with opennic. I wasn't even aware of that.
-
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
202.12.27.33
Those are all roots..
;; QUESTION SECTION:
;33.27.12.202.in-addr.arpa. IN PTR;; ANSWER SECTION:
33.27.12.202.in-addr.arpa. 86400 IN PTR M.ROOT-SERVERS.NET.;; ANSWER SECTION:
17.148.36.192.in-addr.arpa. 86400 IN PTR i.root-servers.net.;; ANSWER SECTION:
129.14.0.193.in-addr.arpa. 21599 IN PTR k.root-servers.net.So yeah - when unbound on pfsense is asked for host.something.NULL as the tld, it would ask roots - hey roots who is the NS for this tld .null...
You need to track down on your lan side network what is asking for whatever.NULL to see if legit or not... Could be billy bob user trying to access some p0rn site ;)
-
ok I'll start looking.
-
but those are never going to resolve unless you setup your DNS to understand how to talk to OpenNIC
You can turn on full query logging in unbound, but has to be done in the custom options box
server:
log-queries: yesedit, example I just did a query for
Apr 21 05:36:10 unbound 65356:0 info: 192.168.9.100 test.domain.null. A IN NXDOMAIN 0.013277 0 120
So you can see that my pc at 192.168.9.100 asked for that .null domain. If you turn on full query logging, you should be able to figure out who is asking for it, and exactly what real quick.
-
quick tcpdump for udp port 53 shows odd things. The server is resolving stackoverflow.com and some yandex stuff zen.spamhaus.org
-
Those don't seem too odd to me... Those are very legit domains.
See my edit above - you prob have easier time just turning on logging in unbound and then looking through the log for .null
-
I turned that on, but it isn't sending queries at the moment. I'll let it settle for a while and let you know. Thank you for the help btw.
-
Do you run pfBlocker?
It could be some dubious hosts hitting your WAN interface and pfBlocker doing a lookup for the host.
Is the alert just in the WAN interface or on the WAN and DMZ.
Also have a poke about in the /var/log/snort directory, there may be a file that you can do a u2spew or u2boat command.
-
And how would pfblocker know to look for something.null? It could maybe do a PTR for an IP..
Oh you mean in one of its block lists? Having a null tld in a block list could be very problematic, since there is no way to resolve those without setting up use of OpenNIC
-
@tman904 As @bmeeks has recommended several times in this forum, you should turn off monitoring WAN in Snort and instead run it on the internal interfaces such as LAN and in this case DMZ. This will make it easy to see which device on your network is causing these alerts by looking at your internal IP addresses. Since everything is blocked by default on pFsense, running Snort on the WAN just duplicates what pFsense already does.
-
NogBadTheBad
The alert is only on my WAN but sourced from the WAN's IP.Johnpoz I turned log level up to 5 on the dns resolver, but I still havn't found anything.
-
@jdeloach said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
@tman904 As @bmeeks has recommended several times in this forum, you should turn off monitoring WAN in Snort and instead run it on the internal interfaces such as LAN and in this case DMZ. This will make it easy to see which device on your network is causing these alerts by looking at your internal IP addresses. Since everything is blocked by default on pFsense, running Snort on the WAN just duplicates what pFsense already does.
@bmeeks also states that if you have open ports on the WAN interface to enable Snort on the WAN interface.
-
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
NogBadTheBad
The alert is only on my WAN but sourced from the WAN's IP.Johnpoz I turned log level up to 5 on the dns resolver, but I still havn't found anything.
Is there anything in the Snort log directory?
-
I thought you want to run snort on WAN if you have open ports which I do.
Yes there is a directory for each interface. As well as an update log file. The gui did state the most recent update was successful.
-
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
Johnpoz I turned log level up to 5 on the dns resolver, but I still havn't found anything.
Doesn't actually log queries... You have to set the query as stated in the option box..
-
at the moment I have two ssh connections to the pfsense and I'm running.
tcpdump -ni em0 udp port 53 |grep .null -LAN
tcpdump -ni em1 udp port 53 |grep .null -DMZHopefully that will grab it at some point.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.