If pfBlocker is doing DNS lookups then why only for this cyber.casa range and not with other ip adresses?
Ah! I am using pfBlocker a little differently than you. I created alias lists and manually added them to firewall rules so I could control the exact order.
In your virtual test pfSense can you start turning things off one at a time (snort, then pfblocker) to try and find the source? Dont forget to have a manual rule in place to keep blocking that IP range.
I really donāt think that something from the WAN is triggering this. It looks much more like a standard query for a resource at cyber.casa. Let me explain. I am guessing that with a full packet capture you would see a query to the casa TLD for cyber and on down looking for a server at cyber.casa which is blocked. In your screenshots your internal IP with a random port going to 193.163.125.254 port 53 looks just like a standard query. In your Wireshark screenshot way back at the beginning of this thread I believe there is some data missing. There are a couple of TCP SYN packets and DNS standard queries. Wireshark by default defines the DNS protocol (edit > preferences > protocols) as TCP port 53, 5353, and UPD port 53. So, if those DNS packets are TCP there should be a SYN, ACK packet after the SYN and an ACK packet after the SYN, ACK creating the three-way handshake. It could have switched to UDP but I would expect to see some sort of response telling it to do so, or it could be a totally different conversation (you will have to look at the packet ID numbers). Sometimes the UPD packets arenāt big enough so it tries to use TCP. This used to be mostly for zone transfers but these days with DNSSEC you never know.
If this is all old news to you then I dont mean anything by it. I just have limited details to look at and dont know you, haha. Doesnt your firewall drop all incoming packets by default? With that in mind then what is allowed through? You see what I am saying? If the packet is dropped it cant trigger anything. I hope this helps.
I swear Iāve seen a checkbox somewhere to resolve IPs in logs but I dont see it now. Itās generally a bad practice and like you mention we would see a lot of other lookups.
Yes exactly that is what is in my head too, where did I see this checkbox? I searched in the config.xml file even if i could find something relating to this, but nothing.
I am going to look more into your suggestions and ideas about Wireshark and going to look at the WAN Interface over again and try to follow what you suggested. You clearly know more about TCP / IP then me. I like to learn so this is nice opportunity to learn and at the same time try to figure this out.
I come back to you about your suggestions about Wireshark how and what to look for.
The way I setup pfBlocker is taken from a video of Tom. I think is was this one:
I you might have some ideas of how and what to filter in Wireshark and are willing to give me some hints of filter syntax that would help maybe. because i filter on network cidr i filter on in coming outgoing i filter on packets with casa in de info.
What i see in wireshark is the same i see in the pfsense log. 1 incoming tcp sync 193.163.125.* connection and then few dns packets.
So, top spammers, PRI1, and custom. Is that all of the PRI1 lists? A couple of those have notes about high false positive rates. You may want to be a little more selective.
In regard to Wireshark itās best to capture everything then filter on what you want to see. I love Wireshark.
Good luck!
Also, on your virtual test pfSense you could turn up the DNS resolver logging. It goes by pretty fast so I find it mostly useless unless you dump it all to a syslog server, but if there is nothing behind pfSense then maybe it will work.
Hmm oke I have to look into that PRI1 someday to then.
In the custom list a have few annoying hosting providers
I have the inocming ports 80 and 443 whitelisted with few friends on that list.
Sometimes i remove that whitelist if i want someone to connect my apache server and in htaccess i have blocked ll countries except The Netherland were i live.
But then some connections from dutch hosting providers and / or vpn providers start hitting my web ports so for those moments i have this custom blocklist to block leaseweb and few others. And also this custom list was from before i used the whitelist for allowed incoming ipās
I have wireshark running right this moment on the WAN nothing filtered on tcpdump so i see everything in wireshark and i use ctrl-f to look for the word casa.
I am waiting for cyber.casa to shoot again on my wan 
I turned up dns resolver log level to 3 Query level information.
It sounds like you are on the right path! I look forward to hearing how it goes.
If you are interested, for my blocklists I use a handful of low false positive lists which carriers should implement but probably donāt. I have a very low tolerance for false positives. I have also done extensive work with GeoIP lists and find they are not as accurate as one might think. It sounds great to block everywhere except where you need to go but it comes with a huge management overhead by way of updating an allowlist when things break. Think about how distributed todays networks are and where the datacenters are. If there is an incident and they want to reroute you to a different datacenter something will break for sure. Even so I regularly see googleusercontent blocked because it wants to hit datacenters in India. So today I am currently blocking some regions and TLDs based on Spamhaus statistics which I manually update monthly and pretty much never have any āissuesā but certainly see some interesting stuff such as when a medical device wants to update firmware from a server in China and other similar things. Also, the guest VLAN is the default on my network. Access to nothing but the internet. I have other VLANs but they are used only as needed. Some networks have camera systems or IoT devices that need to talk to each other for example. I try and avoid VoIP if I can because working in break/fix if that makes it to me itās surly a train wreck. 
I often edit for clarity right after posting
Oh, and the reason I dont use snort or suricata is because everything is encrypted these days so it wouldnt be able to see much. If I hosted something unencrypted then I would certainly put that in front of it, but I dont. Along those lines I am really interested in Sentinel IPS which applies statistics to the conversations to look for things out of the ordinary among other things. But someone needs to pay for that.
You probably know a lot more about these things then i do. For me Snort is a name i know for a long time. I donāt have the time and probably not enough knowledge to judge any of these IPS / IDS systems. I figured many, more knowledgeable, people use it so lets use it too. I see a lot of blocking going on the inbound and outbound networks by Snort. If it doesnāt break anything or make anything unreachable then blocking anything canāt hurt. Maybe this is a very simply way of thinking but there is just so much time in a day and i like networking and computers but i also like other stuff too. So it is always balancing my time between a lot of things.
Maybe you could make some tutorial for people in general with better ways to secure their pfSense networks. Tom did a good job with his video of 2020 but maybe things can be done better and maybe you could explain a better way and help a lot of people to have better secured networks.
Btw i stopped Wireshark scanning WAN i saw again few DNS and TCP packets and i saw a rootserver lookup for the casa tld but nothing else. Just few tcp packets but mostly dns packets related to casa.
So something on the inside must trigger this then. I am now monitoring my private wlan were my wife is doing stuff online with here tablet and smartphone playing games watching videoās etc could be there is something coming from her devices.
Keep in mind that snort is processing incoming things before the firewall if you have it on the WAN side. See: Snort and pfsense firewall - order of processing? | Netgate Forum
Iāve spent my whole life in tech, sort of like a corporate and now freelance version of Tom. But unlike Tom I do not care for social media or producing videos. Writing is fun but itās difficult to get the traction where people will read it and the internet is a very toxic place. Not to mention that every network is a little different so itās hard to make a recommendation that will cover what everyone is up to. Good idea though. Probably why I am here I guess, just trying to help a few people. But then my wife asks why I am doing this if Iām not getting paid so I have to limit my time, which is not going well today.
In my images above you see a incoming tcp:s connection that seems to belong to a outgoing connection but since pfSense has a statefull firewall why is this incoming tcp:s blocked by pfblocker top spammers list? Somehow this incoming tcp:s connection want to mimic reaction on some outgoing connection and even be able to trigger many dns lookups.
Those outgoing dns lookups are being blocked on the way out not on the way in. Since i have snort also looking at internal network interfaces it sees these outgoing dns lookups
Tonight i again looked at all the interfaces of pfsense with wireshark even the localhost. I canāt figure out what is causing this weird behavior. I am absolutely sure it is my shortcoming of knowledge. I canāt let this go haha from all the traffic my pfsense box crosses this is the only one that creates this weird behavior and i donāt like that it is able to trigger action on the inside namely the unbound dns lookups going out.
This evening i looked at every pfsense interface only on the wan i see few tcp connections and a lot of dns packets. My head hurts from thinking about what am i missing.
I understand you donāt like social media neither do I. But i am happy people like Tom is producing his videoās that helped me and many others bit i also like to read tutorials about stuff i am interested in. You could run a website / blog or something like that. You could direct people to your pages if some subjects comes up of people have some problems you have wrote about.
But not everybody likes to do such things. You seem to me to be very knowledgeable so you could share that and who knows make a buck even while doing that.
I am thankful for your help and thinking along with me about this nasty cyber.casa thing though! 
Close! I thought about this and I am going to go out on a limb and speculate that it may be a SYN scan. This cyber.casa company scans the web looking for things and because the firewall blocks the scan there will be no response (vs reject which would send a response that the port is closed). You can see that the sequence number is 0 so itās the first packet of the conversation, as a SYN packet should be, but there is nothing before it to suggest there was something reaching out to that subnet asking for a connection. This makes sense if they were doing a scan, you caught them, then for some reason maybe snort or something is trying to get more information on who that was. Like I said, going on on a limb. Also, those ports are unassigned so they must be looking for something very specific if this is true. Has snort ever caught anything that the firewall missed? Just curious, as you know I donāt use it but I like to hear what others are up to.
I love watching Tomās videos (although some of them are quite long)! I think it would be really hard to just talk at a camera, but open a beer with a friend that has a technical topic and I could say a lot, haha. Glad he found a way to make money at it! You know what they say, do something you love and you will never work a day in your life.
1 Like
Just to clarify a couple of thingsā¦ Wireshark likes to display a ārelativeā sequence number to make it more readable so 0 might not necessarily be the first packet, but generally speaking with a SYN packet it will be. Also, the pfSense firewall blocks by default even though it isnāt visible as a rule, which is confusing because some services such as DHCP stick rules in which you cant see.
1 Like
Yeahhh! This is fantastic learning material. This must be it, a syn scan. I knew it i am not crazy hahaha
I know it is still speculation but something inside my brain wants to start a party and dance around the table 
It is 3:35 AM here in Europe i am going to sleep now i will come back to this tomorrow because i donāt know exactly what you are asking. How do i know Snort has ever caught anything that the firewall missed? 
In other words those tons of dns look ups gave away the syn scan?
Thank you! Very helpful new information to learn more about interpret what i see in Wireshark. And more or less confirms what we were thinking or well you thought. For me it was more a feeling then thinking 
That is a good question! I view this thing we are looking at now, a scanner, as just noise because it would never make it past the firewall and distracts you from the important stuff (although I would like to figure out where the DNS lookups are coming from because I might learn something). I guess if you ever caught something outbound that was an āindicator of compromiseā that would be it. Or if the firewall was supposed to be blocking something and wasnāt and Snort caught it.
I bet if you took your virtual test pfSense and setup syslog to send logs to a syslog server then cranked the DNS logging all the way up to the max you might be able to find the process that is making the queries. Itās a lot of logs though so I wouldnt do it on the main box. Nevermind, I just tried to run tail -F /var/log/resolver.log | grep test.com with the DNS Resolver logging all the way up to a 5 and it gave me lots of good stuff but I do not see the process. If you can narrow it down to a specific package (snort or pfblocker) maybe you can get in touch with the devs.