Windows 7 Firewall

[Fidelia Boldul]

When Windows XP was originally shipped in October 2001, it included a limited firewall called "Internet Connection Firewall". It was disabled by default due to concerns with backward compatibility, and the configuration screens were buried away in network configuration screens that many users never looked at. As a result, it was rarely used. In mid-2003, the Blaster worm attacked a large number of Windows machines, taking advantage of flaws in the RPC Windows service.[1] Several months later, the Sasser worm did something similar. The ongoing prevalence of these worms through 2004 resulted in unpatched machines being infected within a matter of minutes.[1] Because of these incidents, as well as other criticisms that Microsoft was not being active in protecting customers from threats, Microsoft decided to significantly improve both the functionality and the interface of Windows XP's built-in firewall, rebrand it as Windows Firewall,[2] and switched it on by default since Windows XP SP2.

Security log capabilities are included, which can record IP addresses and other data relating to connections originating from the home or office network or the Internet. It can record both dropped packets and successful connections. This can be used, for instance, to track every time a computer on the network connects to a website. This security log is not enabled by default; the administrator must enable it.[4]

Windows Firewall can be controlled/configured through a COM object-oriented API, scriptable through the netsh command,[5] through the GUI administration tool[6] or centrally through group policies.[7] All features are available regardless of how it is configured.

Windows Firewall was first introduced as part of Windows XP Service Pack 2. Every type of network connection, whether it is wired, wireless, VPN, or even FireWire, has the firewall enabled by default, with some built-in exceptions to allow connections from machines on the local network. It also fixed a problem whereby the firewall policies would not be enabled on a network connection until several seconds after the connection itself was created, thereby creating a window of vulnerability.[9] A number of additions were made to Group Policy, so that Windows system administrators could configure the Windows Firewall product on a company-wide level. XP's Windows Firewall cannot block outbound connections; it is only capable of blocking inbound ones.

Windows Firewall turned out to be one of the two most significant reasons (the other being DCOM activation security)[10] that many corporations did not upgrade to Service Pack 2 in a timely fashion. Around the time of SP2's release, a number of Internet sites were reporting significant application compatibility issues, though the majority of those ended up being nothing more than ports that needed to be opened on the firewall so that components of distributed systems (typically backup and antivirus solutions) could communicate.

I have a new ArcServer 10.3.1 installation on a Windows 2012R2 server. I went through installing a new site and added user and admin ArcGIS server connections in ArcCatalog 10.3.1 on the server itself, and was able to preview the sample map service, SampleWorldCities. I thought I was on my way, but when I tried Add ArcGIS Server on a client Windows 10 PC with Desktop 10.3.1 ArcCatalog on a network without a domain to add a user connection, I couldn't seem to guess at the connection url. Tried :6080/arcgis/services, :6080/arcgis/services, :6080/arcgis/services and a few others, like putting /rest on the end, but they all failed. But in the first two forms, they took longer to fail, and got a message "We were unable to connect to:..... Error:Proxy server got bad address from remote server (verify the server is running).

But then I had an idea, Crap! Is this another Windows Firewall problem on the server? I turned off the server's firewall private and public profile temporarily, and the client PC hooked up right away with :6080/arcgis/services.

I don't know why the first two in your link should work. I'm not sure why you would think it is not a firewall issue. I'm talking about the SampleWorldCities map service that appears by default after installing Server. The service seems to be using the defaults. There are no authentications set on the service, https/ssi are not involved. Simply adding the service in ArcCatalog as user or administrator with :6080/arcgis works fine when I remote desktop to the server. On a client machine, Add ArcGIS Server doesn't work for any of the urls I tried, but it connects easily if I turn off Windows Firewall on the server temporarily. Shouldn't I concentrate on making a firewall exception for port 6080?Already this week I had to work on the firewall to get license service through the firewall.

I was thinking that since "I" didn't have to do or request anything special from our network folks....but maybe they already had that open. The 6080 and the 6443 worked fine after finishing my install.

One last thing to verify is that your ArcCatalog is at the same version or higher than your AGS. After that, I'll bow out of this conversation since I don't have control over the network and port side of things in our agency anymore (did many years ago).

I just used Action>New Rule>Port>Specified local ports>6080>Allow the Connection>Applied to all in Windows Firewall with Advanced Security on the server machine, and the Add ArcGIS Server works for a client machine. Both are running 10.3.1. Is that too much permission?

Thank you for reaching out to the live community. I understand you would like to run Windows defender firewall along side Cortex XDR firewall, however, to avoid performance issues, Palo Alto Networks recommends that you disable or remove Windows Defender from endpoints and where the Cortex XDR agent is installed. There are also other potential performance issues with having both XDR and Defender running together on an endpoint as there will be conflicts. Thank you.

I usually leave it on, making sure to leave the Remote Desktop and Remote Administration exceptions turned on. And, of course, anything else I need to (usually the remote administration is good enough for SpiceWorks, I think).

On the network here we dont use windows firewall, neither do we use any other 3rd party firewalls. This is reasonably ok within this network, but for a laptop working remotely (over untrusted wifi / lan) this poses a significant threat.

To summarise, I here run a domain without a desktop firewall - knowing the networks team has secured the internet feed (we also use a proxy that does virus and exploit scanning) so take the risk of an internal exploit happening on an unpatched / pc without virus scan (not easy as AD automatically installs virus scan)

This goes back to the principal of layered security. If you only use a corporate firewall you are protecting the perimeter of your network but not the nodes on the inside. As Martin said, if someone breaches your firewall you have no protection.

If you are not going to use the Windows Firewall or another personal firewall on each node I would recommend segregating trusted and untrusted computers on your network with a DMZ. Corporate systems with managed AV, regular security patches, etc. would be trusted. If a visitor brings in a system or an employee brings in a home system and you do not have verification that it is updated, running the latest definitions of an AV and clean keep it on the untrusted segment.

In the environment I am currently in, a corporate firewall is protecting the network from external threats. Internally central AV and spyware scans run on a regular basis. Any external machines need to go through IT for testing before being permitted on the LAN. As Justin says, there are risks going this route, but they are managed risks. Monitoring systems are also in place to hopefully detect anything unusual, like an out-break, at which point you can take action.

My simple answer is - I would never, ever consider the possibility of not having both. They do different things and are both absolutely the minimum of security that you should ever consider on a networked device. And as the Windows firewall is free there is no excuse for not protecting your machines with it.

The issue has probably been since resolved, but I do not see the need to waste system resources on a software firewall when the network perimeter is already behind both a static and also an active firewall.

As far as asking what traffic is on your network, do you know the answer? Here is a sample of the alerts I get. They are actually very much more detailed, but that also makes that content classified for obvious reasons. Also I bet you did not know Spiceworks 4.0 does a traceroute to the spiceworks IP every 10 minutes.

It really comes down to what your comparison is. If you are comparing the Windows Firewall to no firewall it is better, if you are comparing it to other third party personal firewalls, it is inadequate.

I refuse to trust M$ for any network security beyond authentication to internal resources. They have already proven countless times to be incompetent and I will never use any M$ firewall or antivirus solution on my network.

However, when I try to mount the folder I get a failed connection. I am positive this is the "Private networks" Windows firewall blocking it. If I disable the private network Windows firewall, I am able to mount the folder without any issues through the VPN (keeping the public network firewall enabled). However, as soon as I enable the private network firewall again, the mount fails. Note that I am able to Remote Desktop to the machine (172.16.0.20) without an issue.

I realize this is almost three years late, but I just spent today fighting with the same problem. I did get it working, so I figured I'd share. Note that I'm using a Windows 7 PC as the file server; other versions might need slightly different configuration.

c80f0f1006