pfsense windows defender
-
What is the recommended architecture or pfSense-supported method for this requirement?
Specifically:
Can pfSense dynamically allow Microsoft Defender signature-update traffic without manually maintaining destination FQDN/IP allowlists?
Does pfSense or any officially supported Netgate package provide a Microsoft-maintained dynamic URL/FQDN feed for Defender Antivirus updates?
Can Squid or another supported proxy mechanism identify and allow Microsoft Defender update traffic based on application/service identity rather than destination FQDNs?
Is there a recommended method to synchronize Microsoft-published endpoint lists dynamically into pfSense aliases?
Would the recommended design be to bypass pfSense filtering for Microsoft update traffic and enforce the Microsoft-managed WindowsUpdate/Defender allowances directly on Azure Firewall?
If Defender update traffic must traverse pfSense, what is the recommended approach that avoids broad Internet access and minimizes manual maintenance? -
@abarna said in pfsense windows defender:
Does pfSense or any officially supported Netgate package provide a Microsoft-maintained dynamic URL/FQDN feed for Defender Antivirus updates?
That question needs the answer of another question : Does Microsoft published their IP (or host names) ? The only answer I've found : they have there own entire 'AS' just for them (millions of IPs) and at any time it could be 'any of these IPs'. The reason why they don't publish this info can be recapped in one word : security.
Squid : I presume the update IP uses TLS with and the Microsoft server will impose 'SHTS' so a proxy will be a no-go. After all, if Windows Updates can get proxied this will open the door for huge security issues. Btw : There are, afaik, Windows products that can 'cache' official Microsoft Updates.As always : I hope to be wrong of course ^^
Why do you want to 'filter' this traffic ?
@abarna said in pfsense windows defender:
llow Microsoft Defender update traffic based on application/service identity rather than destination FQDNs
What does Squid see ?
A Ethernet packet = a packet header and the data payload.
The packet header contain info like source destination IP, source destination port, some flags and protocol uses, a time stamp and a packet sequence number. The notion of an 'app' is buried in the data, and the data is TLS (or 'better') encrypted, so Squid can't see/use it
