Were are the(se) unknow dns requests coming from?

Last night i was fiddling around with the dns resolver log levels to also set it a short moment on level 5 and i didn’t saw anything that could help to find out what is generating those dns lookup’s. Because it was so much data i switched it back to level 3 and this is a snipped out of that. you can see this casa domain is being looked up on several dns servers.

Maybe setting snort and pfBlocker to the WAN is a overkill not needed because of the pfSense default rule blocking everything but sometimes i have some ports open to the internet for those cases i have them set on both incoming and outgoing interfaces.

This is how my LAN looks like. Local systems can’t just connect to any port with any protocol. If one of my systems would be compromised they can’t phone home on just any port it must be a port on the allowed out alias.

I would probably see it if there would be something out of the ordinary on one of my local systems wanted to connect to something on the outside. I set this also on my WLAN network. IOT network cannot connect to anything on the outside DMZ cannot connect to anything on the outside. Wen i need to update one of the IOT or DMZ systems i set a temp rule to allow a specific ip port prot to the outside just for that moment to update after that i remove the temp rule.

The disabled PASS ALL rule you see is just there to edit if i need a rule fast wen i want to allow something for a short moment.

Good to know! I also have an alias of allowed outbound ports that I use for internet access.

If you can easily replicate this on your virtual test pfSense I would put a firewall rule on the WAN side to block that subnet then start turning off services until you don’t see it anymore. That might help narrow down where it is originating from (snort, pfblocker, or some other package). If the DNS lookup is on a regular interval I would install the cron package and see if anything matches up. Do you have a lot of other packages installed?

To be honest that pfSense VM is last updated on februari 21 2021 i have to upgrade it from pfSense 2.5 to 2.5.2 it is today. I created this VM way in the beginning this cyber.casa stuff started. To upgrade i need to connect my Internet cable to the wan of the VM. To much hassle before i know more about this cyber.casa dns lookups. I am just doing it on the main pfSense box.

I think the dns requests are probably coming from pfblocker. Because we see 1 incoming sync with sequence number 0 blocked by pfblocker. Then 1 second after that we see many outgoing dns requests to a dns server on the network of the “attacker” that are blocked by Snort. Apparently the dns resolver did not cache that ip btw which is weird in itself.

But besides all that I am still going to do what you suggest. I backup my pfSense config and start turning of packages (pfblocker, snort) to see what difference i see. And i put a floating rule on the top blocking this cyber.casa range of course.

The packages i have installed:

That service watchdog package is great! I’m surprised it’s not a default thing just to restart DHCP and DNS if they break.

Have you looked around in the pfBlockerNG logs? I only keep eyeing Snort because I’ve occasionally seen it cause strange issues which then make people switch to Suricata. If it is pfBlockerNG then you can contact BBcan117 per the support section on the general page within pgBlockerNG. He is very receptive.

I look forward to hearing how it goes. Have a great day!

1 Like

Yeah I know I talked to Anthony (BBcan117) in the past about other things. It is a very nice guy.

You’re right about the watchdog service it should be installed by default. Maybe there is a reason it is not i don’t know.

I will let you know how it goes of course :+1:

Great day to you too :wink:

After i created the floating block rule for the 193.163.125.0/24 range and disabled pfBlocker and DNSBL. After a while cyber.casa hit the WAN interface again. This time no list of (blocked) DNS lookups to their DNS server. Before, i disabled pfBlocker, Snort would block outgoing DNS lookups to 193.163.125.254 this time it did not. I didn’t disable Snort so it should have block outgoing dns connections if there would be any.

The incoming TCP:S from 193.163.125.98 is blocked by the default pfSense rule not the floating rule.

Progress! Do you see that IP range or domain in any of your pfBlocker lists? If so which one. I am curious, maybe it is blocking the domain but needs the IP for something else like reputation score.

Yes it is in GeoIP Top Spammers.
afbeelding

The range is also in Snort
ET DROP Dshield Block Listed Source group 1
https://www.dshield.org/block.txt

I don’t see domain cyber.casa or the tld in the list. I think pfblocker is doing (or trying to do) a reverse lookup.

Ah, while a lot of email spam may come from those countries a lot of legitimate traffic happens as well so tread carefully. This still doesn’t answer where the DNS lookup comes from but I think you are close. If you can easily replicated it then this would be a good question for BBcan117.

I used to try and “default deny” via GeoIP and it was a huge pain (block everything but these regions). So many companies are trying to be globally distributed now, and if an Amazon datacenter in the USA connects to Brazil and you block Brazil (because it’s a top spammer after all) you would be surprised the things that stop working. At some point I just decided that it would be easier to block a handful of really bad places and the firewall resources worked out about the same but everything just works now and I dont have to mess with it. A router is supposed to route traffic, a firewall is supposed to segment a network, and if you want IDS/IPS things may get wild. Sometimes the difference between IDS/IPS and a firewall get blurred and we have to revisit what we are trying to achieve. Just speaking generally. Now I’m going to be playing with suricata in my lab again thanks to you, haha.

I agree but have not been able to replicate it yet in my lab.

I missed this post from you geez how could i missed this. Of course I am interested in the blocklists you use. Understandable you have low tolerance for false positives. I have more a problem with maintenance of things. Low maintenance blocklists set and forget is more my thing :wink:

I don’t use any of the Geoip list besides the TopSpammers list. Maybe i confused you with the GeoIP Apache module i use for the Apache vhosts. In there i allow only visitors coming in from The Netherlands, my home country, on the websites i run on my local Apache server. I know those country lists are not 100% up to date and besides of that it eats a lot of system resources to block half of the world IP’s so i don’t use those.

I have PRI1 and TopSpammers list in pfblocker nothing else. Years back I used a lot more blocklists but now only those 2. Before with lots of blocklists my pfSense box got slower and slower over time. So i cleaned up after i saw Tom’s video and thought at that time: well this is good enough :wink:

I am going to look closer what you have and test it. You know a lot of this stuff so can’t hurt to check that out for sure.

Thank you for this!

P.S.

Did you see on Spamhaus statistics
.casa tld at nummer 7 of most abused TLD’s

afbeelding

afbeelding

yeah i have to change these pfblocker blocklists. I am going to look at what you have soon and copy that.
I think wen i would remove that Top Spammers list deny inbound from pfblocker these cyber.casa syn scans will be blocked by the pfSense default rule and pfblocker would not doing those reverse dns lookups. Problem solved.

Then again why is this only happening with these cyber.casa syn connections i am sure many other syn scans hit my wan every minute none of them trigger pfblocker to do a reverse lookup

I know company’s use CDN’s around the world they always have a way to connect to you if they want to. I don’t block countries don’t use any geoip country lists just this top spammers list i don’t think its only spammers on that list anymore. This list blocks a lot of incoming connections and several people advised to use it so i did.

I did know that .casa was pretty high up on the list (I was saving that for later, haha). Also, I should mention that I use most of my lists on the LAN side (and other internal networks) watching outbound traffic. Everything incoming is blocked except for a DMZ server where nothing is blocked by the network and I manage everything to protect that server on that server.

GeoIP lists block a lot. To avoid a management nightmare I find it best to find just enough firewall rules (I do push this sometimes though) then also apply security policies to endpoints and use multi-factor authentication and do your security patches. Things like fail2ban and your apache module are nice tools. If someone has money they can buy a nice IDS/IPS but I feel like there should be a reason for that to be in place. If you keep the barn door shut the horse wont wander out. If the horse is trying to escape determine how big of a fence you need or if that is even the right approach. You know?

About my DMZ i know i should do it the way you described. It should not be a vlan and pfSense firewall should not be in front of it. I should enable all the servers local firewalls. I am lazy :wink: I figured i only have one (dynamic) public ip i can’t use a block of static public ip addresses so i thought lets call this vlan for my servers DMZ with pfSense firewall in front of it. This way servers are on their own network not in the LAN. But it is not a proper DMZ as it should be.

I am going to change pfBlocker, Snort and the blocklists in the near future based on what you wrote and showed in this thread. I need a bit of time to look closer to what you use and what i need and make a little plan that fits my network. Not sure yet how exactly i am going to configure things.

You are going to look into Suricata again because of what happened with my cyber.casa adventure? Funny and i think a good thing. Maybe after a while you come back to this thread and let us know what you changed. If Suricata is a better choice then Snort i probably going to test that too. I never heard of Suricata before I Started using pfSense Snort was a more familiar name as a IPS/IDS.

You probably noticed Snort blocked those outgoing DNS (reverse) lookups connecting to the attacker (authoritative) DNS server. So i figure that was a good thing to set Snort on both inbound and outbound WAN port.

What i was thinking about is: On pfSense NICs only rules for inbound traffic can be set. But as you can see above in my pictures those outbound reverse dns lookups going out of the WAN come from inside dns forwarder going out the WAN and are blocked by Snort. So at least Snort can block outbound traffic on the WAN interface. Wen that happens there is a little arrow shown on the (WAN) interface. You see that in the images i posted earlier. That is remarkable, i think. We can not set rules for outgoing traffic in the interfaces only for inbound. But outbound from inside of pfSense itself you can or at least Snort can.

You can do this in the floating rules. But I think it’s considered a better practice to block traffic at the first chance given and use this scenario (traffic coming into the WAN from the LAN for example) for special situations.

Suricata vs snort is a long running debate. I feel they are very similar. Maybe the development speed is better with one or the other at a given point in time and Suricata is multi threaded but Snort has some different rules. Then there is Zeek too. I wont put any of these things on my main pfSense box, or my clients for that matter, because for me it’s just supposed to route and segment the network traffic in a fast and efficient manner. My lab is a different story however and I do see the value of doing a little monitoring. If I were going to someday add this to my main box or to a client I would likely use a separate box. It’s a fine line between how many firewall rules to put in place (not to mention how much you trust the list sources) and when the firewall is the wrong tool for the job.

I have a DShield Honeypot in my DMZ. Because it’s designed to be attacked the DMZ network has it’s own interface, subnet, and VLAN, and no access except to allow all traffic from the internet to hit it (IP, public DNS servers, etc are manually configured on the box). Ports are changed. Fail2ban is in place. Unattended-upgrades is installed. IPtables keeps everything locked down so the internet cant hit any “real” ports. Unnecessary services are disabled. Unneeded packages removed. It’s a neat project, and I use their blocklist so it makes me feel like I am contributing.

A separate IPS/IDS system would probably be best but oh boy i already have to many computers and boxes that eat away power 24/7. I checked out Zeek a while ago but my attention span is to short or the learning curve to steep. In youtube videos it looked simple to use but not for me.

Sweet this DShield honeypot you setup. That would be really interesting. Do you have a separate public ip for your DMZ?

You are a professional who needs to know all these things i am a hobbyist / home user with broad interests. A separate box for IDS/IPS would probably be best but to much for me. My wife is going to kill me wen i have another box that runs 24/7 and eat away power day and night :wink:

Maybe a more powerfull pfSense system is on my wish list. With more NICs so i could make a LAG to my switch trunk. That would beef up my network a lot i think. Specially for traffic between the vlans. And more resources for packages like Snort / Suricata.

Netgate TNSR, a dedicated IPS/IDS etc is more for professional use with a budget for those things.
I don’t think TNSR is free like pfSense else i would like to check that out for sure.

Nonetheless very interesting information and ideas :+1:

Oke, good to know, thank you!

It was surprised Snort blocks outbound traffic on the WAN probably coming from the inside, the reverse DNS lookups triggered by pgBlocker.

PfSense does hide this pretty well and I imagine that Snort likely wants to see what made it through the firewall.

The honeypot is at my home which is a pretty standard residential connection with a dynamic IP. I created this locked down network segment then forwarded all of the necessary ports to the honeypot. Setting up the honeypot is pretty easy, they have good documentation and it’s mostly automated if you have a spare raspberry pi. I think the 3b+ model I am using consumes 5W of power under load and less while idle. Thus I have no problem running a few of them for various projects, haha. :grin:

I personally have some important rules when it comes to tech toys at my home that keep everyone happy. No fans and the internet has to keep working pretty much covers it (or, put another way, if I spent money on it then it better be worth it). It’s served me pretty well. If it’s loud or breaks stuff then it’s got to go. I do a lot of work in virtual machines on my laptop and if I really “need” a server then I will spin something up in the cloud. But this is my house and should not be confused with a datacenter.

Netgate TNSR is not free and not for home use, but the picture was nice (they do have a home lab extended evaluation version but make no mistake, this is Wall Street level stuff). If you are concerned about DOS attacks that architecture should work better than having everything on one box, but as you said there is a learning curve and you need another box. Probably pretty huge overkill depending on what your server is hosting.

I’ve often wondered what people do at home that needs link aggregation or 10 Gbps connections. Get familiar with your stats before you invest (pfSense > status > monitoring, Unifi > statistics, switch stats) and be mindful of your endpoint capabilities.