Why are processes listening to closed ports on my firewall?

Oh they may be listening, but that doesn’t mean they’re going to hear
anything.

It really just the nature of how a firewall works, so I’ll use this as an
opportunity to try to clarify that just a little.

In an unprotected system, every application that wants to be able to respond
to an incoming message from another computer somewhere out on the internet is
said to be “listening”. It does this by registering itself with the network
component of the operating system, saying in effect, “whenever you receive a
message of this type, give it to me and I’ll deal with it”.

In a very important sense, each process is connected directly to the
internet, listening for messages of the type that it wants to hear about:

Now, what I’ve called a message of “this type” is identified by what’s
called a port number, so processes are “listen” to “ports”. That how each
process is listening to only one type of message and not interfering with the
messages destined for another process. Windows itself might be listening for
file-sharing requests on one port, while an instance of svchost.exe is
listening for incoming remote desktop requests on another port.

Using TCPView, here’s a snapshot of
the processes listening on my machine as I write this:

Among other things you can see that instance of svchost listening to port
3389, which is the incoming port for Remote Desktop requests.

When we add a firewall to the picture, none of that changes:

In a sense, the firewall lives on the “internet side” of the computer’s
network connection. All the processes are unaffected; they don’t know about the
firewall, they just keep doing whatever it is they do. They keep listening.

The firewall simply prevents messages coming in from ever reaching any of
the processes listening for them. The messages are “blocked” at the firewall.
This is how a firewall protects you – it keeps all unexpected messages from
ever reaching the software that might try to act on them. Particularly if
you’re connected directly to the internet you’ll see that there are many such
“unexpected” messages, and a vast majority of them are viruses, malware, and
other hacking attempts. Your firewall stops them cold.

But what if we want to be able to respond to some of those
messages? What if we know that certain messages are okay and that we
actually want to use the functionality those messages represent?

Remote Desktop is a good example. Since even with a firewall in place my
computer is still listening to the remote desktop port (3389), all we need to
do is to configure the firewall to allow that port through. Once configured
everything else might be blocked, but if a message comes in that’s destined for
port 3389 then the firewall can let it through. (Naturally I’ll want to make sure
that remote access is secure in other ways, perhaps by using exceptionally
strong login passwords since it can now reach my machine.)

That’s why you sometimes have to configure your firewall before some
applications will work. The application might be listening, but the firewall
could be preventing it from ever hearing anything.

As a side note, so far we’ve only talked about blocking incoming messages.
Many software firewalls often work both ways: blocking unwanted messages coming
in and also unexpected messages going out. If a program needs to be able to
communicate out to other machines through ports that aren’t already open in the
firewall, you might have to configure it to allow those ports through as
well.

Finally, all this does beg the question: if a firewall is going to prevent
any of the messages of a given type from reaching us then why are we “listening” at
all?

It’s a legitimate question. Sometimes you can in fact turn off or
disable the software that’s listening to a given port because it’ll never be
activated. If I didn’t use Remote Desktop, for example, I’d turn off the
service and it would stop listening on 3389. Not only would that prevent
accidental or malicious connections to that port, it also frees up memory for
other processes to run.

In other cases, things aren’t quite that simple. Quite often the system
“talks to itself”, so to speak, through networking connections that need to
remain open. Other programs simply can’t be told not to listen even
though you might still want them running for other reasons.

In an ideal world we wouldn’t need firewalls. Every machine would listen for
only those things it needs and would do so in a perfect bug-free way. There
also wouldn’t be malware out on the internet trying to propagate and infect
your machine through your network connection. But we don’t live in an ideal
world, and a firewall is a critically important first line of defense.