Read this as a study guide instead
Filtering rules, default-deny, ingress versus egress.
These commands only read information — they change nothing. Run the block for your OS, then use the table to read your own numbers against the ideas above.
Get-NetTCPConnection -State ListenWhat you should see Get-NetTCPConnection -State Listen lists every listening TCP endpoint with its LocalAddress, LocalPort, and OwningProcess. A LocalAddress of 0.0.0.0 or :: accepts connections on any interface; 127.0.0.1 or ::1 listens only to the local machine.
Note Run this in Windows PowerShell, not inside WSL: inside WSL you get the Linux network stack and ss applies instead.
netstat -an -p tcpWhat you should see netstat -an -p tcp lists TCP sockets by numeric local and foreign address with their connection state; the rows whose state is LISTEN are the services accepting new connections. A local address ending in a port on 127.0.0.1 is local-only, while one on * accepts connections on any interface.
Note This lists TCP only; add a separate -p udp run to see UDP listeners, which have no LISTEN state of their own.
ss -tulnWhat you should see ss -tuln prints one row per listening socket: the protocol (tcp or udp), the Local Address:Port it is bound to, and the state (LISTEN for TCP). An address of 0.0.0.0 or [::] means the service accepts connections on every interface; 127.0.0.1 or [::1] means it listens only to the local machine.
Note As invoked, ss -tuln only selects and displays sockets, so it changes nothing on the machine; -t is TCP, -u is UDP, -l is listening only, and -n keeps addresses and ports numeric.
| Concept | Windows | macOS | Linux |
|---|---|---|---|
| Listening ports (the attack surface a firewall exposes or blocks) | Get-NetTCPConnection -State Listen | netstat -an -p tcp | ss -tuln |
| Which interface a service listens on (local-only versus every interface) | Get-NetTCPConnection -State Listen | netstat -an -p tcp | ss -tuln |
These are the exact fragments the model serves — also available as an ordered study guide.
A firewall stands between a machine (or a whole network) and everything else, and it decides one thing about every packet that tries to cross: does this get through, or does it get dropped. That decision is made against a set of rules the firewall keeps, not against the packet's good intentions, which it has no way to read anyway.
The idea is narrow on purpose. A firewall does not inspect what a program does with traffic once it arrives, and it does not vouch for anyone; it only sits at the door and checks each packet against its rules before letting it in or out. Everything else in this concept is what those rules look at, the order they run in, and what the firewall does when no rule has anything to say.
The reason to bother with a door at all is that every service listening for connections is a way in, and a firewall is how you decide which of those ways stay open. Keep that framing and the rest follows.
A firewall rule matches on the identifying marks a packet already carries. There are four that matter: the source address it came from, the destination address it is headed to, the port, and the protocol (TCP, UDP, and the like). These are the same addresses and ports that ip_addressing and the network layers give every packet, so a firewall is reading fields that are there whether or not anyone is watching.
The fifth mark is not on the packet but on the situation: direction. The same packet means different things arriving from outside than it does leaving from inside, so rules are written per direction — inbound traffic is judged by one set, outbound by another. A rule can be as broad as "any address on port 443" or as narrow as one source talking to one destination on one port.
None of this involves understanding the packet's contents. A firewall works entirely from the envelope — who, where, which port, which protocol, which way — which is exactly why it can decide quickly and why a rule is only ever as precise as the marks it names.
A firewall holds its rules as an ordered list and tests a packet against them from the top down. The moment a rule matches, that rule decides the packet's fate — allow it or drop it — and no rule below is ever consulted like a bouncer reading down a guest list and acting on the first entry that matches the person at the door. This is first-match-wins, and it is the single fact that makes rule order load-bearing.
Because the first match ends the search, order is not a matter of tidiness. A broad rule placed above a specific one can swallow every packet the specific rule was meant to catch, leaving that later rule as dead code that never runs. Put a wide ALLOW above a narrow DROP and the thing you meant to block sails through; swap them and it does not. The rules did not change, only their order did.
So reading a ruleset means reading it in sequence, the way the firewall does, and asking of each packet which rule it hits first. The answer, not the intent of any single line, is what actually happens.
Not every packet matches a rule. When one falls all the way through the list without a single rule firing, the firewall still has to do something with it, and that something is the default policy. There are two possible defaults, and the choice between them decides everything the rules did not.
Default-deny drops anything no rule explicitly allowed like a guest list where anyone whose name is not written down is turned away; default-allow lets through anything no rule explicitly blocked. Default-deny is the safer posture, and the reason is asymmetry: with default-deny you have to name every kind of traffic you want, so a forgotten rule fails closed and merely blocks something useful. With default-allow, a forgotten rule fails open and silently lets something dangerous through. One mistake costs you a working service; the other costs you the protection.
That is why the recommended stance is to deny by default and allow by exception — start from a closed door and open exactly the traffic you can name. The default is not a fallback you can ignore; it is the rule that governs the whole unlisted world.
A stateless firewall judges every packet on its own, with no memory of any packet before it. That is simple, but it creates a problem: when your machine reaches out to a server, the server's reply is inbound traffic, and a stateless filter has no way to tell that reply apart from an unsolicited stranger. To let replies back in, you would have to leave a standing rule open for them — which also leaves it open to everyone else.
A stateful firewall solves this by remembering. It keeps a state table, a record of the connections that are currently active, and adds an entry when your machine opens one like a doorkeeper who notes who stepped out so that person's return is expected and let back in. When a packet arrives, the firewall checks whether it belongs to a connection already in that table; if it is the return traffic for something you started, it is allowed, and if it matches no entry, it is treated as the unsolicited inbound it is and dropped.
The payoff is that you get replies to your own traffic without leaving a door propped open for anyone else. Connection tracking makes a distinction — return traffic versus a fresh knock at the door — that per-packet filtering simply cannot make reliably.
Filtering is applied per direction, and the two directions usually get opposite defaults. Most host firewalls block unsolicited inbound traffic while allowing outbound: Windows Firewall, for instance, blocks incoming connections unless they are solicited or match a rule, and allows outgoing connections unless a rule says otherwise. The machine may freely reach out; the world may not freely reach in.
That asymmetry is deliberate. Traffic you start is traffic you chose, so letting it out — and letting its replies back, if the firewall is stateful — is low risk. Traffic arriving unbidden is a stranger at the door, and the safe default is to turn it away. The direction of the first packet, not the direction of the reply, is what marks a connection as yours or theirs.
The direct consequence is that running a service others can reach is never automatic. A game server or a web server sits waiting for inbound connections, and inbound is exactly what the default blocks, so the port has to be opened on purpose. Reachability is something you grant, not something you get for free.
The same rule-matching machinery runs in two very different places. A host firewall runs on a single machine and protects only that machine — Windows Firewall ships with the operating system and is enabled by default, and Linux and macOS have their own. A network firewall runs at the boundary of a whole segment and guards every machine behind it, filtering traffic as it crosses in or out of that network.
The two are complements, not rivals. A network firewall at the edge stops a great deal before it ever reaches the machines inside, but it cannot see traffic that stays within the segment, and it is one policy for many hosts. A host firewall has the last word for its own machine and can be as specific as that one machine's job requires. Defense usually wants both: a coarse filter at the door and a fine one on each desk.
Either way, the rules themselves are the thing worth guarding. Changing a firewall's rules is a privileged operation, because anyone who can rewrite them can open any door they like — least privilege applies to the rulebook exactly as it applies to the files behind it.
Every port a machine leaves open to the world is a way in, and the sum of those ways in is its attack surface — everything an outsider could try to reach. A firewall is the tool that decides the size of that surface, and the whole craft of using one is keeping the surface no larger than the job actually needs.
Making a game server reachable is the exact case. The server listens on one port for players, and the honest firewall change is to allow that one port and nothing else, on a machine whose default is to block unsolicited inbound. Open the whole range "to be safe" and you have done the opposite: you have handed the outside world every listening service on the box, not just the game. One opened port is a door; an opened range is a missing wall.
This is least privilege pointed at the network — grant the minimum access the task requires and no more. A firewall does not make a machine safe on its own, but it is where you get to decide how much of the machine the internet is allowed to touch, and a small, deliberate surface is the difference the rules are there to buy.