Jump to content

Experimenting with Windows Firewall to block by default


NoelC

Recommended Posts

It occurred to me in all these discussions about data collection, etc., as an experiment to try to set the Windows firewall to block outbound connections by default.  This is experimentation I've been meaning to do for a very long time, and I'm finally getting around to it.

 

The trick, of course, will be to define enough rules so that the basic things one DOES want to communicate on the net will still work, while (hopefully) disallowing as much snooping as possible.  Yes, it implies an ongoing responsibility to manage the firewall whenever new things are added or needed of the system.

 

I started by disabling all the rules except those labeled as "Core Networking" for All profiles, and Network Discovery and FIle and Printer sharing for the Private profile.

 

Then I added a couple of obvious Allow entries for All profiles, for example to allow iexplore.exe to reach the network.

 

So far it seems effective.

 

  • I can reach my other computers on my LAN via Windows Networking.
     
  • I can browse the web with Internet Explorer.

 

Off the top of my head, the following things still need to be addressed to provide essential network communications, and I'm not yet sure how to accomplish them:

  • In order to continue to be able to get Windows Updates, the Windows Update services/processes, including the wushowhide tool will need to be able to reach the net to check for updates.
     
  • Various other applications and tools that need to be able to reach the network to do things like check for new versions of themselves or activate online.
     
  • Other things as needed.

 

Once the basics are set up, I believe this could potentially be a reasonably manageable approach, and should increase system security overall.

 

-Noel

Link to comment
Share on other sites


As MS can not be trusted anymore I guess same is valid for his firewall, let me suggest you another free alternative PeerBlock http://www.peerblock.com/

 

And having a list of all MS sites you want to block, that should be good enought.

 

Anyway if you want to use Win firewall there is some info and a downloadable Script for it on this page: http://cyber-defense.sans.org/blog/2011/10/25/windows-firewall-script-block-addresses-network-ranges, again you only need a list for all sites you want to block.

 

 

Best Regards

Edited by alacran
Link to comment
Share on other sites

I'm not quite ready to give up on the Windows firewall just yet.

 

I hear you regarding the system itself bypassing the firewall.  However, if they were caught doing that, it could be very bad press for them. 

 

And regarding using an "allow by default, with exceptions" strategy, how can we know all the addresses one would want to block?  We simply can't.  Who knows what's built into the binaries.

 

So for now a "deny by default" strategy seems a reasonable answer.  It's just a matter of discovering the various exceptions.

 

Right now I'm having trouble getting Windows Update to work.  I've added exceptions for the wuauserv service and several other programs (e.g., msdt) and it seems to try just slightly harder, but in fairly short order it just fails with error code 0x80072EFD.  I'm guessing that Microsoft did not update the firewall software to understand the modern Windows Update changes yet.

 

Anyone have any idea what additional services or executables need to be allowed to facilitate Windows Updates?

 

-Noel

Link to comment
Share on other sites

That's awesome, thanks!  I had been considering writing a handler that would watch for such events, since the firewall itself neglects to pop up such messages, and lo and behold someone's already written one.

 

I'm just imagining now, though, that trying to run Windows Update will yield something like the need to enable svchost.exe, which would just be silly.  Let's see if it turns out to be...

 

-Noel

Link to comment
Share on other sites

This is new page with last updates, it is feeware, surce code is available too: http://wfn.codeplex.com/

 

Edit: Site on line again now, but anyway this is another option: https://sekharpadikkal.wordpress.com/2013/04/12/making-windows-firewall-complete-block-outgoing-connections-and-get-notified/   and this is product page: http://www.binisoft.org/wfc.php  but in order to get full features you need to register it making a "donation".

Edited by alacran
Link to comment
Share on other sites

Thanks.

 

I've done some more work on this today... 

 

The Windows Firewall Notifier malfunctions in Win 10 in both its latest release version and its alpha version, failing to put up notifications for every blocked connection (which would be necessary to make this a viable long-term solution).  I'll look into that other one on the binisoft.org site, maybe it's more mature, though I think the real problem is in the way Win 10 has changed the notification interface.

 

Even with the program not giving every blocked connection notification, I WAS able to discern the necessary services and addresses to make Windows Update work.

 

At this point I have a configuration that completes a Windows Update, allows a base set of my applications to access the net as needed, and has a set of addresses that are explicitly denied.  Windows tries to connect to sites all over the world!  I've seen it try to reach Redmond, Kansas City, St. Louis, Boston, and even London.

 

Once you sort out the initial jumble of what services and addresses to allow the required firewall maintenance activity settles right down and you can just use the system.  I'm starting to think the ongoing maintenance activity needed to support this approach, if supported by a firewall augmentation tool that really pops-up notifications when it should, it's really possible to keep a system on "deny all outbound networking with exceptions".

 

Of course, there's no guarantee Microsoft doesn't circumvent their own firewall under some conditions.  If they were actually caught at doing that, though...  Bad juju.

 

-Noel

Link to comment
Share on other sites

In my opinion, a firewall by default, should allow all the programs I have installed on my computer to communicate to the internet.  It would just be too  much hassle to set this up on my own.  What I think a firewall should do is prevent rogue communications from the outside to get in by default.  I certainly do not wish to be forced to allow programs access that should automatically have access.  This would turn using a computer from a joy to a really huge pain.  Also, I have very rarely changed any firewall settings except to not allow access to a certain program that I am testing that I might have activated surreptitiously. 

Link to comment
Share on other sites

A firewall should do whatever it is you want it to do.  If the defaults suit you, dhjohns, more power to you.  They don't suit me, and now that I've been doing this experimentation I have come to realize how incredibly promiscuous Windows is about sending data out to sites all over the world.  It's another case of "what you don't know could hurt you".

 

The strategy I'd like to develop a configuration for is one that:

  • Denies access by default, unless there is a specific rule allowing a connection.  This will ensure network accesses that have not yet been vetted re disallowed.
      
  • Allows only what's really needed by the various components of the system to do things one wants the system to do (such as Windows Update).  This involves not only identifying the components (e.g., members of the netsvcs svchost), but also addresses and port numbers needed to succeed at the given tasks.
     
  • In my case, I trust all the systems inside my router, so I allow all local LAN segment access.  This facilitates easy Windows Networking between my machines.  I never expect to be able to do Windows Networking with machines outside the LAN.  This may not be ideal for everyone.
     
  • I don't have a Domain so I'm ignoring Domain access and really concentrating on Public internet access.  This may not be ideal for everyone.
     
  • As the system is used in an ongoing fashion, one can note failures and allow connections by applications that are installed by recognizing the application and allowing all access.  Under some conditions - e.g., big, cloud-integrated applications, possibly restrict the access somewhat by using addresses and port numbers.

 

Remaining challenges I have been thinking of:

  • Managing such a system long-term will of course take more effort than a permissive one.  One will have to constantly be aware that network accesses will fail by default, and occasionally manage the exceptions list as needed.  It's still unknown how difficult this will be, though so far it's been pretty trivial to get my stable of applications to work.  Funny how the tables have turned, where we can trust applications more than the system itself.
     
  • Procure or create tools to specifically help manage such a system.  Ideally you'd receive a pop-up message for each new network access failure and be presented with a pertinent list of things to do about it (e.g., some combination of deny/allow the application/service, deny/allow the address, ignore default failures for now/forever, etc.).
     
  • So far I only have IPv4 access to the internet to test with.  IPv6 will have to be taken into account as well.
     
  • Once a working and workable Outbound rule set is developed, reconsider what's going on in the Inbound rule set.  For now most application installers don't set up Outbound rules, but many DO set up Inbound rules.  It may be that tighter management of Inbound rules is needed too. 

 

At this point, armed with an understanding of how the firewall works, I am just in a process of refinement.  I've had to enable all network access for certain services, for example, to get Windows Update to work - and that's just too permissive.  So now it's a matter of disabling them individually, seeing what addresses/ports are required, and enabling just those.

 

Still, already a huge number of network accesses are being blocked, with no apparent downside, other than it maybe taking a few extra seconds to log in.

 

I'll publish the specific information here once I've got things more nailed down.

 

-Noel

Edited by NoelC
Link to comment
Share on other sites

@ NoelC

 

I'm very interested in your findings, thanks to you very much for keeping us informed.  I'm going to be checking this thread every day.

 

I found another free tool to manage Windows Firewall to block everything (incoming and outgoing) and then let you set the exceptions, but no popups when blocking someting, they say it works on Win10: http://tinywall.pados.hu/

 

Best Regards

Link to comment
Share on other sites

I've been working some today to refine this.  I've been able to simplify it quite a bit today. So far I'm seeing a fair bit of traffic blocked with no apparent downside, save for maybe a little longer log-in time.

 

I'm not ready to publish a full Windows Firewall Policy yet, but if you'd like to have a look at what I've got so far, perhaps to experiment for yourself, here's what it looks like:

 

FirewallScreenshot08172015.png

 

I've decided to try to manage Windows Updates as just a series of addresses that must be allowed to be contacted via TCP on ports 443 (https) and 80 (http).  Mostly those in the 443 list are required to determine if updates are needed, and those in the 80 list are required to actually download them.  It's a surprisingly complex process involving servers all over the place.

 

Note that in other places in the world the addresses may well be different.  These are the ones that are working for me.

 

Notably when something's blocked by default, what's logged in the Security log are not just the single failures, but rather I see the system hunting around for a working address.  It's clear that not all the possible addresses are listed in any one attempt, but it does make it easier to develop lists.

 

You can get the actual address lists I've derived (IPv4 only) from this:

 

Name Group Profile Enabled Action Override Program Local Address Remote Address Protocol Local Port Remote Port Authorized Computers Authorized Local Principals Local User Owner Application Package
- Block - Known Google Data Collection Addresses All Yes Block No Any Any 216.58.219.110, 216.58.219.161 Any Any Any Any Any Any Any
- Block - Known Microsoft Data Collection Addresses All Yes Block No Any Any 157.56.106.184-157.56.106.185, 94.245.121.253, 94.245.121.251, 204.79.197.200, 23.218.212.69, 65.55.108.23, 65.39.117.230, 134.170.30.202, 137.116.81.24, 65.52.108.116, 131.253.61.66, 64.4.54.18, 64.4.54.99 Any Any Any Any Any Any Any
- Block - Miscellaneous Addresses Seen Contacted by System All Yes Block No Any Any 192.0.77.2, 215.58.192.100, 192.229.163.16, 72.21.91.121, 199.27.76.193, 190.93.243.61, 108.162.232.198, 72.21.91.29, 199.96.57.6, 192.229.163.25, 104.244.43.39, 199.16.156.21, 72.52.129.170, 108.161.187.102, 93.184.216.180, 66.211.181.192, 66.135.211.36, 173.0.82.206, 173.0.72.211, 192.225.158.136, 192.225.158.3, 66.135.211.19, 66.211.178.172, 66.211.181.172, 66.135.216.134, 205.251.242.54, 204.160.119.126, 54.239.22.240, 54.239.18.134, 176.32.103.205, 174.35.36.71, 93.184.215.200 Any Any Any Any Any Any Any
Application - Beyond Compare [Allow All Communications] All Yes Allow No %ProgramFiles% (x86)\Beyond Compare 3\BCompare.exe Any Any Any Any Any Any Any Any Any
Application - BowPad [Allow Update Check] All Yes Allow No %ProgramFiles%\BowPad\BowPad.exe Any Any Any Any Any Any Any Any Any
Application - Chrome Browser [Allow Web Browsing] All Yes Allow No %ProgramFiles% (x86)\Google\Chrome\Application\chrome.exe Any Any Any Any Any Any Any Any Any
Application - Internet Explorer x32 [Allow Web Browsing] All Yes Allow No %ProgramFiles% (x86)\Internet Explorer\iexplore.exe Any Any Any Any Any Any Any Any Any
Application - Internet Explorer x64 [Allow Web Browsing] All Yes Allow No %ProgramFiles%\Internet Explorer\iexplore.exe Any Any Any Any Any Any Any Any Any
Application - Photoshop CC 2015 x32 and its Plug-ins [Allow Online Activation] All Yes Allow No %ProgramFiles% (x86)\Adobe\Adobe Photoshop CC 2015 (32 Bit)\Photoshop.exe Any Any Any Any Any Any Any Any Any
Application - Photoshop CC 2015 x64 and its Plug-ins [Allow Online Activation] All Yes Allow No %ProgramFiles%\Adobe\Adobe Photoshop CC 2015\Photoshop.exe Any Any Any Any Any Any Any Any Any
Application - Safari Browser [Allow Web Browsing] All Yes Allow No %ProgramFiles% (x86)\Safari\Apple Application Support\WebKit2WebProcess.exe Any Any Any Any Any Any Any Any Any
Application - SignTool [Allow Code Signing Of Products] All Yes Allow No %ProgramFiles% (x86)\Windows Kits\8.1\bin\x86\signtool.exe Any Any Any Any Any Any Any Any Any
Application - Skype [Allow Communications] All Yes Allow No Any Any 104.40.75.8, 23.96.32.46, 23.101.115.193 UDP 137 Any Any Any Any Any
Application - Skype [Allow Communications] All Yes Allow No %ProgramFiles% (x86)\Skype\Phone\Skype.exe Any Any Any Any Any Any Any Any Any
Application - Visual Studio 2015 [Allow DevEnv to Access Online Resources] All Yes Allow No %ProgramFiles% (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe Any Any Any Any Any Any Any Any Any
Application - Visual Studio 2015 [Allow VShub to Access Online Resources] All Yes Allow No %ProgramFiles% (x86)\Common Files\Microsoft Shared\VsHub\1.0.0.0\VsHub.exe Any Any Any Any Any Any Any Any Any
Normal System Activities - Allow Any Access on the LAN All Yes Allow No Any Any Local subnet, Intranet Any Any Any Any Any Any Any
Normal System Activities - ICMPv4 [Allow PING] All Yes Allow No Any Any Any ICMPv4 Any Any Any Any Any Any
Normal System Activities - ICMPv6 [Allow PING] All Yes Allow No Any Any Any ICMPv6 Any Any Any Any Any Any
Normal System Activities - svchost LocalService [W32Time] [Allow Online Time Update] All Yes Allow No %SystemRoot%\System32\svchost.exe Any Any UDP Any 123 Any Any Any Any
Windows Update - svchost [Port 443] [Allow Check for Updates] All Yes Allow No C:\windows\system32\svchost.exe Any 66.119.144.157-66.119.144.158, 65.55.163.221-65.55.163.222, 191.234.72.180-191.234.72.190, 157.56.96.123, 157.55.133.204, 134.170.58.190, 134.170.115.62, 23.103.189.125 TCP Any 443 Any Any Any Any
Windows Update - svchost [Port 80] [Allow Download of Updates] All Yes Allow No C:\windows\system32\svchost.exe Any 23.14.84.0-23.14.84.255, 23.15.5.0-23.15.5.255, 8.253.0.30, 8.253.0.46 TCP Any 80 Any Any Any Any
Windows Update - System [Allow Check for Updates] All Yes Allow No System Any 131.253.61.0-131.253.61.255 TCP Any 443 Any Any Any Any

 

I don't imply that any of these lists are complete, but at least the system hangs together okay.  The blocking rules are there in case the overall policy gets changed, or that some other rule allows blanket access.

 

At some point I think I'm going to adopt this strategy on my Win 8.1 host workstation as well.  It's scary to see how much data is normally being sent out.  :crazy:

 

-Noel

Link to comment
Share on other sites

In my opinion, a firewall by default, should allow all the programs I have installed on my computer to communicate to the internet.

That is typically how the Windows firewall works already. The problem with that approach is... how does the firewall know that the program was actually installed by you and not a malware?

Link to comment
Share on other sites

In a proper world the application would ask you if you'd prefer to add a firewall entry (for both incoming and outgoing connections) and tell you exactly why it wants to do so, giving you the user the option to opt out of Internet communications.

 

Of course, none do that.  Many go ahead and add their own firewall entries for incoming data, and sometimes for outgoing as well, even though Windows' default policy is to allow outgoing connections unless blocked by an exception.

 

My recent development of "deny Outgoing connections by default" firewall configurations for both my Win 8.1 and 10 systems has been a real eye-opener.  There's 1000% more attempted network activity in Win 10, but unsolicited attempts to send out data are non-zero even in Win 8.1.  This is a bit alarming, since it's a system that's been carefully kept clean and already has a fair number of other measures in place.

 

My advice:  Be afraid, be very afraid of your system telling the world all about you.

 

-Noel

Link to comment
Share on other sites

If it's at all interesting, here's my list of notes based on observation of what Win 10 does.  The sections pretty much match my current "Oh hell no", "let the system block by default and wait and see if anything bad happens", and "allow" exception lists.

 

Please be careful if you act on this information.  It's entirely new, experimental, and potentially flat wrong.  Plus it's oriented toward running only desktop operations - NO Modern Apps, which is what I do.  It may not suit you if your goals are different.

 

I certainly haven't done everything with Windows I could possibly do after setting up the firewall per these notes.  In other words, use at your own risk.  I would, however, like to hear your thoughts on specific entries.  I certainly don't know everything Windows does with networking.

 

Windows 10 firewall configuration development notes as of August 18, 2015 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------#  The System (not the browser) has been seen communicating with these addresses on various occasions, often at some time after#  having visited various web sites.  They don't appear necessary for the sites to work, and since the conditions under which#  the system tries to contact them are suspicious, they are aggressively blocked.192.0.77.2          # Automattic, San Francisco215.58.192.100      # DoD Network Information Center192.229.163.16      # Edgecast Networks72.21.91.121        # EZE Castle Integration199.27.76.193       # Fastly, San Francisco190.93.243.61       # CloudFlare, San Jose108.162.232.198     # CloudFlare, San Francisco72.21.91.29         # Edgecast Networks, Santa Monica199.96.57.6         # Twitter, San Francisco192.229.163.25      # Edgecast Networks, Santa Monica104.244.43.39       # Twitter, San Francisco199.16.156.21       # Twitter, San Francisco72.52.129.170       # SourceDNS, Lansing Michigan108.161.187.102     # Tinet SpA, Studio City California93.184.216.180      # Edgecast Networks, Wichita Kansas66.211.181.192      # eBay, Campbell California66.211.178.172      # eBay, Campbell California66.135.211.36       # eBay, Campbell California173.0.82.206        # PayPal, San Jose173.0.82.211        # PayPal, San Jose192.225.158.136     # ThreatMetrix, San Jose California192.225.158.3       # ThreatMetrix, San Jose California66.135.211.19       # eBay, Campbell California66.211.181.172      # eBay, Campbell California66.135.216.134      # eBay, Campbell California205.251.242.54      # Amazon Technologies, Ashburn Virginia204.160.119.126     # Level 3 Communications, Wichita Kansas54.239.22.240       # Amazon Technologies, Ashburn Virginia54.239.18.134       # Amazon Technologies, Ashburn Virginia176.32.103.205      # Amazon Data Services Ireland Ltd, Ashburn Virginia174.35.36.71        # CDNetworks, Dallas, TX93.184.215.200      # Edgecast Networks, Wichita Kansas94.245.121.251      # Microsoft Limited, London England; UDP 354494.245.121.253      # Microsoft Limited, London England; UDP 354464.4.54.99          # Microsoft bingbot, Redmond Washington#  Communications attempted right after bootup#  Aggressively blocking the whole range 65.52.108.0 - 65.52.108.25565.52.108.90        # Microsoft bingbot, Redmond Washington (msnbot-65-52-108-90.search.msn.com)65.52.108.92        # Microsoft bingbot, Redmond Washington65.52.108.116       # Microsoft bingbot, Redmond Washington65.52.108.135       # Microsoft bingbot, Redmond Washington#  A Windows Update that actually downloads updates makes a lot of attempts to#  connect UDP to ports 547 and 3544.  However, the update completes without these#  operations being allowed to continue, so these addresses are blocked.157.56.144.215      # Microsoft Corporation, Redmond Washington157.56.106.184      # Microsoft Corporation, Redmond Washington#  Explorer.exe attempts to connect TCP port 443 to these just after bootup or during an update check.  No failures seen,#  though I wonder if they may have to do with logging in with a Microsoft account.  I use a local account, so they're#  blocked.157.56.106.184      # Microsoft Corporation, Redmond Washington157.56.106.185      # Microsoft Corporation, Redmond Washington157.56.106.189      # Microsoft Corporation, Redmond Washington157.56.106.208      # Microsoft Corporation, Redmond Washington157.56.96.80        # Microsoft Corporation, Redmond Washington157.56.96.83        # Microsoft Corporation, Redmond Washington157.56.96.123       # Microsoft Corporation, Redmond Washington157.56.96.207       # Microsoft Corporation, Redmond Washington (bn1-2cd.wns.windows.com)157.56.96.208       # Microsoft Corporation, Redmond Washington (bn1-2cd.wns.windows.com)#  Cortana, which is disabled in every way I know how, still tries to contact this address via#  TCP port 443 right after bootup.  I don't ever intend to use Cortana, so this is blocked.204.79.197.200      # Microsoft Corporation, Redmond Washington (a-0001.a-msedge.net)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------#  The following have been seen to be passively blocked.  Don't know yet whether to block these aggressively...224.0.0.252         # ??? No idea157.56.75.164       # Microsoft Corporation, Redmond#  svchost.exe attempts to connect TCP port 80 to this a minute or so after bootup / first logon.  No failures seen.192.116.242.20      # 012 Smile Communications, Gaza City Israel#  svchost.exe attempts to connect TCP port 443 to these just after bootup.  No failures seen.157.56.96.58        # Microsoft Corporation, Redmond Washington157.56.96.123       # Microsoft Corporation, Redmond Washington#  System attempts UDP port 137 communication with the following during a Windows Update check and download. #  No failures are seen due to their being blocked.23.103.189.125      # Microsoft Corporation, Redmond Washington66.119.144.157      # Microsoft Corporation, Redmond Washington#  System131.253.61.66       # Microsoft Azure, Wichita Kansas131.253.61.68       # Microsoft Azure, Wichita Kansas131.253.61.80       # Microsoft Azure, Wichita Kansas131.253.61.82       # Microsoft Azure, Wichita Kansas131.253.61.98       # Microsoft Azure, Wichita Kansas131.253.61.100      # Microsoft Azure, Wichita Kansas--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------#  The addresses that follow are required to do a manually initiated check for updates via the hide update tool and#  an actual manually initiated Windows Update, so they are allowed#  svchost Port 44366.119.144.157      # Microsoft Corporation, Redmond Washington66.119.144.158      # Microsoft Corporation, Redmond Washington65.55.163.221       # Microsoft Hosting, Redmond Washington65.55.163.222       # Microsoft Hosting, Redmond Washington157.55.133.204      # Microsoft Azure, Redmond Washington134.170.58.190      # Microsoft Corp, Wichita Kansas134.170.115.62      # Microsoft Corp, Wichita Kansas191.234.72.183      # Microsoft Azure, Wichita Kansas191.234.72.186      # Microsoft Azure, Wichita Kansas191.234.72.188      # Microsoft Azure, Wichita Kansas191.234.72.190      # Microsoft Azure, Wichita Kansas23.14.84.152        # Akamai Technologies, Cambridge Massachusetts23.15.5.207         # Akamai Technologies, Cambridge Massachusetts23.15.5.214         # Akamai Technologies, Cambridge Massachusetts23.14.181.100       # Akamai Technologies, Cambridge Massachusetts (a23-14-181-100.deploy.static.akamaitechnologies.com TCP port 80)191.234.4.50        # Microsoft Azure, Wichita Kansas (TCP Port 80)#  explorer.exe attempts to connect TCP port 80 to these just after bootup.  No failures seen when they were blocked.#  However, the domain and the persistence of the attempts at connection imply they may be needed for updates.96.16.98.27         # Akamai Technologies, Cambridge Massachusetts (a96-16-98-27.deploy.akamaitechnologies.com)23.15.5.130         # Akamai Technologies, Cambridge Massachusetts (a23-15-5-130.deploy.static.akamaitechnologies.com)23.0.91.156         # Akamai Technologies, Cambridge Massachusetts (a23-0-91-156.deploy.static.akamaitechnologies.com)23.78.145.102       # Akamai Technologies, Cambridge Massachusetts (a23-78-145-102.deploy.static.akamaitechnologies.com)23.210.124.46       # nLayer Communications,  Cambridge Massachusetts (a23-210-124-46.deploy.static.akamaitechnologies.com)#  svchost.exe (fairly diligently) attempts to connect TCP port 80 to these just after bootup.  No failures seen when they#  were blocked.  However, the domain and the persistence of the attempts at connection imply they're necessary for updates.104.73.28.226       # Akamai Technologies, Cambridge Massachusetts (a104-73-28-226.deploy.static.akamaitechnologies.com)23.34.81.224        # Akamai Technologies, Cambridge Massachusetts (a23-34-81-224.deploy.static.akamaitechnologies.com)131.253.61.66       # Microsoft Corp, Wichita Kansas131.253.61.84       # Microsoft Corp, Wichita Kansas131.253.61.96       # Microsoft Corp, Wichita Kansas131.253.61.98       # Microsoft Corp, Wichita Kansas65.55.113.11        # Microsoft Hosting, Redmond Washington65.55.113.12        # Microsoft Hosting, Redmond Washington65.55.113.13        # Microsoft Hosting, Redmond Washington#  svchost.exe attempts to connect TCP port 443 to these just after bootup.  No failures seen when they were blocked.#  However, the domain and the persistence of the attempts at connection imply they're necessary for updates.131.253.61.66       # Microsoft Corp, Wichita Kansas131.253.61.84       # Microsoft Corp, Wichita Kansas131.253.61.96       # Microsoft Corp, Wichita Kansas131.253.61.98       # Microsoft Corp, Wichita Kansas--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Now that the above is in place, longer-term refinement of the firewall settings needs to happen, to make sure everything works.

 

 

-Noel

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...