-
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.
-
I would be curious as well to what they are looking up.. but domain.null could be almost anything..
Allowing for unbound to resolve opennic tlds is a simple as adding a few stub zones pointing to the opennic NSs..
Here I added stub zones for geek and null so could get to search engine and fine a null site, etc..
That snort marks them as suspicious could be seen a few different ways... For starters anyone trying to do something bad, writing code so it could resolve opennic tlds would be "extra" work ;)
But maybe its someone trying to circumvent something??
It could be just honest sort of mistake where a search suffix is adding .null to something and causing the query to roots for whatever.com.null for example..
You have my curiosity cat meowing ;) So please report back what you find...
-
Under /var/log/snort/snort_interfaceRANDOMNUMBER there should be a file with u2 in the file name, do a u2spewfoo FILENAME or a u2uboat FILENAME > output.pcap.
The first command will dump the output to screen the second will create a file that can be read by Wireshark.
Also I'd be tempted to use Balanced rather than Security.
-
I'll run those commands and see if I spot anything in wireshark.
As of today/tonight I haven't seen incidents on DMZ or LAN that line up with the WAN incidents. I wonder if it's simply because it hasn't happened again since I starting logging on LAN? That would make since since I was only logging on WAN and DMZ when it happened yesterday.
What do you guys think? Could it have came from pfsense directly or is it more likely something on the LAN caused it when I wasn't logging there?
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.