-
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.
-
I just enabled snort on my LAN interface. If it's sourced from there it should line up in the logs for LAN and WAN.
-
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
I just enabled snort on my LAN interface. If it's sourced from there it should line up in the logs for LAN and WAN.
Are your LAN and DMZ VLANS, if they are and both share the same parent interface you can just run Snort on the parent interface as it puts the interface into promiscuous mode.
-
In my case LAN and DMZ are two physical interfaces. Hopefully by tonight the queries will be sent again. Maybe it's nothing but it doesn't seem normal to me.
Thanks again for everyone's help with this issue. I'll report back if it's finds anything by tonight or tomorrow.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.