-
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?
-
pfsense would not have been trying to to some domain.null it only checks for updates, the rss feed if you have that setup and package updates. all would be pfsense/netgate domains.
Did you install any unofficial packages? Here is the thing trying to access any of the opennic tlds from some application would just be stupid - UNLESS!!! the documentation of said software gave you info on how to make sure you can resolve opennic tlds.. Its a pretty small use base in the big picture to be honest.. Other than say the browser addon users..
Guess the software could be hard coded to query an opennic NS... But you stated the queries were to root servers looking for whatever.null - which would never work.. Your just going to get back NX from roots for any of the opennic tlds
-
Here is the course of action I took, note this is after I enabled snort on the LAN interface.
Here's my thought process step by step. Hopefully it's understandable and will help someone in the future facing something similar.
##########################################################################################################
cause found LAN snort compromise report in snort alerts - coming from 192.168.0.132 on the LAN interfacefirst course of action was to look at status->arp table - didn't yeld anything so client hasn't sent in roughly five minutes or so
second course of action was to look at status->dhcp leases - didn't have an active lease but found the IP in the expired leases
third course of action was to set the mac address from that lease for 192.168.0.132 to a static dhcp mapping to IP 192.168.0.250
fourth course of action was to create a rule under firewall->rules->LAN that passes any traffic sourced from 192.168.0.250. I also added a pass rule for 192.168.0.132 just in case the host doesn't request a lease for some reason. Finally I added a description saying this is the compromised host, and set all packets matching the rules to be logged for either of those two hosts. The reason I'm passing the traffic is to see a working example of what they are doing.
note - 192.168.0.250 finally sent packets see below.
LAN tcp 192.168.0.250:53028 -> 209.85.200.189:443 ESTABLISHED:ESTABLISHED 101 / 146 15 KiB / 25 KiB
WAN tcp X.X.X.X:XXXX (192.168.0.250:53028) -> 209.85.200.189:443 ESTABLISHED:ESTABLISHED 101 / 146 15 KiB / 25 KiB
##########################################################################################################To be honest I'm still not sure exactly what's going on yet. I think that it's just an https connection, when I do a whois on the destination IP it returns google.
Anyway for now that is how the situation stands.
-
Yeah that is google, and where is doing dns queries for opennic?
-
Well I definitely found the culprit. Yesterday a snort alert showed up from the existing server for .win. I'm 99.9% sure it originated from the server and somehow got to the other segment. In any case I need to rebuild the server. Hopefully I can get by with some hot standby/swap kind of thing. Can't have much downtime. Wish me luck I'll need it lol.
Thanks for everyone's help I really appreciate it.
-
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
I'm 99.9% sure it originated from the server and somehow got to the other segment. In any case I need to rebuild the server.
What?
So you have a packet capture of this query? "somehow" is a not good RCA for what is happening in your network.. Your saying its now doing queries for something.win, that is not a opennic tld? That is a valid normal new tld that you can register anywhere..
Blocking queries to domains because you don't like the tld and its not .com or .org is sure fire way to break the internet for your users..
Maybe its some legit software installed on the server checking to see if there update available.. And that company just happen to use .win for their tld because its cheap and hip ;)
-
I don't plan on blocking them. I found them in the snort alerts again, just .win this time. After this cropped up I discovered the Web mail panel for the server was exposed to the internet. Unfortunately it runs a product that also has a management ui for the mail server part on 443 also exposed. I blocked that port along with the Web mail. smtp/Imap is ok atm.
I dug deeper and the server hasn't been patched for a few years. In the servers admin logs, it shows the firewalls lan ip successfully logged in at a time and date I didn't login. Thats when i got the permission to build a new firewall with pfsense. Also when we started using snort. This is why I think it's hacked. It was installed before I came on board. So I don't know the history, and almost no documentation of anything.
Tldr version
These dns queries, along with the web mail and admin panel facing the Internet. make me think the server may have been compromised. -
@tman904 said in Snort detecting INDICATOR-COMPROMISE suspicious .null dns query on my WAN:
These dns queries,
What was the query for? Can you not get this info from snort? just saying something.win is not very useful logging.. I can see the alert could be called that, but there should be a log of the actual query done.
-
Is there a way to filter under status dns resolver? Also if the dns request wasn't answered will it not show up in the log?
-
You can tell your resolver to log the queries, but shouldn't snort be saving the packets? And you can view them?
We already went over all of this..
-
if you do what i said ages ago you’ll be able to see what is being looked up with a u2spwefoo.
You could be looking at the logs for ages, DNS is very chatty.
-
I just enabled barnyard2, once I get results I'll run that command. Problem is if it doesn't happen again while running barnyard2. How I'm I suppose to see it? The last time the query for .win happened was April 30th.
-
The mail server was checking domains against spam blacklists. I've confirmed this by matching up timestamps on the server and pfsense.
-
So you were getting mail that said it came from .win and .null domains?
-
The mail server sends DNS queries since it checks the domain name against spam blacklists and If it's on one of the blacklists it rejects the email. Meaning It was the content of the DNS queries that triggered snort, to top it off I put snort on the highest security mode, That combined to create what I thought was a compromised server.
This also explains why I got alerts on the LAN side as those email clients do the same type of checking.
-
Dialing Snort up to the "Security" policy is pretty stringent and just asking for false positives. "Connectivity" is fine the majority of the time, especially for admins new to managing an IPS. "Balanced" is the best policy overall once you get your feet wet with IPS management experience. For the vast majority of business networks, the "Balanced" IPS policy offers plenty of security without running the admin crazy checking out false positive all day long.
-
Thank you for the advice @bmeeks. I'll keep that in mind.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.