-
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.
-
That not going to catch anything.. Test it!!! Do a query with that in the fqdn..
-
-LAN and -DMZ aren't in the command.
-
And again TEST it...
where do you think in that tcpdump the info of the query would be listed? So how could you grep for it.
-
well can you explain that to me?
There they are
07:33:13.204333 IP 192.168.0.141.57062 > 192.168.0.2.53: 57715+ [1au] A? test.null. (38)
07:33:13.241310 IP 192.168.0.141.57062 > 192.168.0.2.53: 57715+ A? test.null. (27)
07:33:54.634610 IP 192.168.0.141.59863 > 4.2.2.2.53: 5400+ [1au] A? test.null. (50)guess I didn't need the -A
This is what I used
"tcpdump -ni em0 udp port 53 |grep .null"
"tcpdump -ni em1 udp port 53 |grep .null" -
Ok so now that you have validate your method can find an example - yeah lets see if you find anything at the time you see the snort log.
When I try that grep doesn't find my test
But without grep I see it
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: tcpdump -ni igb0 udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
06:39:44.111865 IP 192.168.9.100.61488 > 192.168.9.253.53: 11023+ [1au] A? test.domain.null. (57) -
The same thing that the gui says lines up with the logs. But it says it's from the WAN IP. with grep .null on my dmz interface log file in /var/log/snort doesn't seem to have .null in it.
It took a few seconds after I ran the command. Also if you change the snap length it should get to grep quicker.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.