Microsoft Updates Not Progressing
-
@stephenw10 I think I may see the issue, I do have the DNS over TLS NAT rule but I guess I need one for each VLAN, its only only setup on the Default Vlan. But maybe the rules themselves need some work also.
-
@stormgate
Why would you want to use DNS over TLS on the pfSense LAN side & VLAN side ?
You will be one of the first to do so among the pfSense user base, over 100 000 (this is very IMHO).
Again : you will have to configure every LAN/VLAN device ! See [https://en.wikipedia.org/wiki/DNS_over_TLS](https://en.wikipedia.org/wiki/DNS_over_TLS.It can be done of course.
I've installed a Windows 10 Pro DNS-over-TLS client just a couple of days ago.If you want to make your traffic invisible, go for the much simpler VPN tunnel.
Or do you really want to MITM with pfSense ? ;)
-
@gertjan Only because I thought DNS over TLS was a better secure setup, but I have no other reason. I would be prefer to set it up so its reliable and works for everything and yet secure. Would you simply recommend setting up DNS (53) with a some rules? This system is going to be thousands of kms away so I have no margin for error, so the most recommended setup is what I will adhere too. Thanks
-
Category based DNS filtering on the firewall can only be done via pfBlocker like that.
You can block DoH using IP lists in pfBlocker. Obviously that's not 100%
Firefox will look for a specific domain locally and not use DoH if it finds it. But users can still force it to use DoH.
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-httpsSteve
-
@stephenw10 @Gertjan So much help you are giving me, ok I have cleaned up my rules and set everything as DNS(53), cleaned it all up. So DNS over TLS is no longer. Firewall was probably so confused with my rules.
-
@stormgate said in Microsoft Updates Not Progressing:
This system is going to be thousands of kms away so I have no margin for error
So DNS over TLS, locally ( not to be mistaken with DNS over TLS, used by unbound when it is in forwarding mode) is out of the question, as every device that connects to your local networks has to be setup correctly.
It can be done, but you need to be there. -
@gertjan Thanks, yeah I have moved everything back to the conventional DNS and now filtering works pretty good, rules look much better now. Still struggling with this Windows Update issue, they eventually download but it can take days and several retries, I'm at a loss where what exactly is causing the issue. This is a complete stand alone simulated network and everything is brand new. Running 2 stacked Aruba 1960's, the uplink to the Pfsense is using a 10GB connection, the stacks connections are fiber, and when I run a speed test over the internet I get the full speeds according to the package so that all seems right. All PC's are affected whether they are plugged in or over their respective SSID. I wish I had tried this prior to installing any packages like pfblockerng or snort but unfortunately I did not. I am not seeing anything like microsoft.update or anything, alot of IP's are being blocked but nothing I have looked into refers to Microsoft in anyway.
-
So it does seem Snort is the culprit, I actually think my one Windows 11 PC didn't have the issue with updates, however after really disabling and leaving for a bit it does appear that Snort is causing this windows update issue. I removed the package and reinstalled, and setup back up. I'll check it when I get home if updates are now ok. It doesn't seem to be throwing up nearly as many alerts.
-
@stormgate said in Microsoft Updates Not Progressing:
I removed the package and reinstalled,
That's a no operation.
@stormgate said in Microsoft Updates Not Progressing:
and setup back up.
That's where things go wrong.
You are using snort : you activated 'rules' or something like that (I never used snort) and one of the rules matches on the Windows Update traffic ....
Snorts logs ? If so, you can find 'what' to modify or what rule ( ? ) to disable and done. -
@stormgate said in Microsoft Updates Not Progressing:
So it does seem Snort is the culprit, I actually think my one Windows 11 PC didn't have the issue with updates, however after really disabling and leaving for a bit it does appear that Snort is causing this windows update issue. I removed the package and reinstalled, and setup back up. I'll check it when I get home if updates are now ok. It doesn't seem to be throwing up nearly as many alerts.
Unless you modify the Snort rules you have selected, you can expect the same issue to keep recurring.
I do not know your skill level with an IDS/IPS, so for the sake of simplicity I am going to assume you are new with such packages.
The admin MUST really understand the various types of rules used in an IDS/IPS and also be fully aware of the potential exposures (security vulnerabilities) present in their protected network(s) in order to properly select the Snort rules to use. This same level of knowledge is also needed to interpret resulting alerts from those selected rules to weed out actual "threats" from "false positives".
In reference to the paragraph above, I have seen many new IDS/IPS users install Snort or Suricata, go through and enable everything (or almost everything) without regard to the actual vulnerabilities in their network. Then they start getting a lot of alerts (blocks), stuff stops working they want to work, and they come here posting for help ...
.So how should you do it? First, choose the rules or rule categories that you enable carefully. Many rules are designed for things you may not even have present on your network. Two prime examples are mail servers and web servers (meaning public-facing servers). Another is a public-facing DNS server. So right away that means you don't need any of the rules enabled associated with those types of exposure. Another example is some categories of rules that are meant to be information only rules. The ET-INFO category is one of these. They will alert on things simply to let the admin know certain traffic is happening. You may be perfectly fine with that traffic, though, and don't want it blocked. For example, there are ET-INFO rules that can detect a DLL or EXE file being transferred. That rule would certainly alert (and block when Legacy Blocking Mode is enabled) with any Windows Update traffic. But you want that traffic to proceed, so why does such a rule even exist? Consider that you are a corporation and have an on-premises WSUS arrangement where you want internal clients to ONLY use WSUS for their updates. In that case, you might want the ET-INFO rules enabled on your WAN to make sure local clients don't go out directly to Microsoft for their updates and grab them instead from your WSUS. But for most home setups, you would not want to even enable the ET-INFO rules category.
Now the most important part!!
Select your rules and then run with them for several days or even weeks with blocking turned off. Regularly visit the ALERTS tab in Snort and investigate every alert you see, because once you turn on blocking mode each of those alerts represent blocked traffic. You want to determine if the alert is a false positive in your environment. If it is, you want to either disable that rule (best option) or suppress that alert (can be done on a per-IP basis if needed) to prevent those alerts and subsequent blocks. After running this way for a while you will have a tuned ruleset for your environment. Only then should you enable blocking.Note once again, this is not meant as a dig against you personally -- I'm just giving some background info and also leaving a message for anyone in the future that stumbles upon this thread when investigating a similar issue.
-
@bmeeks said in Microsoft Updates Not Progressing:
Select your rules and then run with them for several days or even weeks with blocking turned off
.... and password protect this "blocking mode on" button.
Hide the secret password in your post above, and link that post in the GUI.
You'll be saving a lot of time and head scratching to many new snort users.Btw : replace "snort" with "pfblocker" and "IDS/IPS" with "IP/DNSBL" and your post stays 100 % correct
-
Sorry for the delay guys, so yes this is my first experience and setup with Pfsense and its packages. Let me explain, so I have been following a bunch of videos trying to get the best basic setup that meet ours needs and pfblockerng and snort seemed to be 2 very good defences but all aware of the learning curve. So when I initially setup for what ever reason, snort didn't install correctly, it failed. So I was able to reinstall, I didn't want to go to crazy so I simply set it to Connectivity, as it says this is the safest when starting out, I didn't even add any extra categories as I assumed these were automatically chosen. Anyway things seemed to work, I didn't even try windows updates till after I started knocking the other setup tasks I needed to do. I tried turning off snort but it didn't seem to turn off, or rather I was still having windows updates issues. I started reading about a package suricata, so I thought maybe I should uninstall snort and install suricata, after uninstalling I tried my windows updates and they worked as they should. But after some more video watching it seemed snort is such a good package I decided to reinstall. So after installing without any setup I retried windows updates and all good, then followed a video and took my time setting up, I did choose "Security" this time and chose various lists, like malware, worms, bots etc...and then just watched the traffic. The very first traffic it picked was the system calling out to our remote PBX, so I watched how to add that to a whitelist and took care of that, it did add the remote WAN IP to the block list but quickly cleared that, thanks to the discussions here on managing that list. But then it started picking up probes and such, looked more like genuine scans externally and has been them ever since. Oh I should mention this time around I didn't turn on Block Offenders right out of the gate instead watched the alerts, then as it settled down and I understood what now is being alerted on then turned on block offenders and its working much better. Windows updates are fine. So my last step to complete is now our remote phones, I managed to get one working completely but adding the second, they a both registered back to the remote PBX but just get a busy signal so I assume both are competing for port 5060 but the Netgate configuration is very vague so you will probably see a new post on that, lol. I really appreciate everyone's feedback and help and challenging me to explore more of the product, some still confuse me when it comes to NAT and setting those all up so bare with me. I know @Gertjan had mentioned troubleshooting more and it was a bit confusing trying to locate where the updates were blocked, I tried several ways and it seemed microsoft's updates are a bit convoluted, so in one instance I might find "au.microsoft.update" then when you run the IP you get its comes back to StackPath LLC and then some other name when you run thru Virus total so without a definite resolve I didn't want to accidently whitelist something that is actually malicious so that when I decided to just uninstall and maybe try something else.
-
@StormGate:
I strongly recommend that you do not use the "Security" IPS Policy. "Connectivity" is more than adequate in most circumstances. Once you get things tuned and feel you really have a handle on the various traffic types in your network, you could consider moving to "Balanced" for a policy. But I would never go beyond "Balanced" for any business or home network.Snort's network scan preprocessor logic can be touchy and has a bit of a hair-trigger. There are some adjustments to tame it down a little on the PREPROCESSORS tab. You will also find that the HTTP_INSPECT category of rules are really prone to false positives these days due to the weirdness in web traffic associated with serving up ads and fooling ad blockers. I will also note that due to the increasing use of encryption, an IDS/IPS running on the firewall attempting to scan network traffic is becoming more and more useless unless you configure a proxy setup with MITM (man-in-the-middle) so the IDS/IPS can see cleartext traffic. It can't scan encrypted stuff like HTTPS, SSH, TLS, DoT, etc. That means a lot of the available rules are worthless when applied to encrypted traffic.
Legacy Blocking Mode in Snort (and Suricata) is a special kind of beast. It blocks by adding IP addresses to a pre-existing (as in created by pfSense at boot-up) table in the
pffirewall engine. Any IP added to that table is blocked so long as it exists in the table. The table is named snort2c. You can view its contents in two places: (1) the BLOCKS tab in the IDS/IPS application GUI; and (2) under DIAGNOSTICS > TABLES in the pfSense GUI. Once Snort or Suricata places an IP in that table to be blocked, it is done. Stopping Snort or Suricata will not remove the IP from the table. So once the IDS/IPS package blocks an IP, that IP remains blocked until it is removed from that table. Stopping the IDS/IPS package service will not clear the IP. Clearing requires manual action by the admin, or the admin can enable the automatic cron task to remove blocks under the GLOBAL SETTINGS tab. -
@bmeeks Thanks so much, adjusted accordingly. This being my first Pfsense setup I guess I am bit nervous, I'm use to working Sophos XG NG's and Junipers completely different animals and with this system going thousands of miles away just want to make sure I am providing them with a secure device.
