Build the idea first, then use the next activity to check it.
Filtering by service, not just by host
Adding protocol and port to a rule, and the three answers a blocked port can give you.
What you will be able to do
- Write a rule that permits one service rather than one host
- Explain why a port-specific permit is the least-privilege form
- Distinguish an open, refused and filtered port from the response
- Say why dropping beats rejecting for a rule meant to be quiet
Before this: You need first-match ordering and the implicit deny from "Filtering traffic with an ACL", and ports from "TCP, UDP and ports".
Why it matters: A rule that permits one host to reach another permits every service on it - the database, the management interface, whatever gets installed next year. Naming the service is the difference between an access list that expresses an intention and one that merely approximates it.
An access list that names only addresses answers the question "may these two machines talk". That is rarely the question anyone actually asked. The real request is almost always about a service - the web team needs the application port, the auditor needs to read one system, the guest network needs the internet and nothing internal.
Adding the service to a rule
A rule can match on the transport protocol and the destination port as well as the addresses. Same first-match ordering, same implicit deny at the end - one more field to match on.
# Permits everything between these two hosts
permit src 10.30.10.25 dst 10.30.30.10
# Permits one service, and nothing else, between the same two
permit src 10.30.10.25 dst 10.30.30.10 tcp dport 443
The destination port is the one that identifies the service, because it is the port the server listens on. The source port is chosen at random by the client for each connection and is not useful to match on - matching it is a common early mistake and produces a rule that works once and then stops.
Return traffic
A request going out needs a reply coming back, and the reply arrives at the random source port the client chose. A stateless list has to permit a wide range of ports inbound to allow replies at all, which undoes much of the precision just gained.
Matching on connection state solves this properly. The firewall tracks which connections it permitted outbound and admits the replies belonging to them, without a rule that would permit anyone to start a new connection inbound.
# Replies to connections we already allowed out
permit ct state established,related
# One service, inbound, from one source
permit src 10.30.10.25 dst 10.30.30.10 tcp dport 443
The three answers
When a connection to a port does not succeed, the way it fails tells you something specific. This is worth knowing both for diagnosis and because it decides how a deny rule should be written.
| Result | What happened | What it means |
|---|---|---|
| Open | The connection completed | Something is listening and nothing filtered it |
| Refused | A reset came back immediately | The packet reached the host and got a reply - either nothing is listening, or a rule rejected it |
| Filtered | No response at all, until timeout | Something silently discarded it |
The distinguishing signal is time. A refusal returns instantly because something answered. A drop takes the full timeout because nothing did. Both look like "it did not connect" if you are not watching for the difference.
Dropping against rejecting
| Action | Response sent | Effect on a scanner | Effect on a legitimate client |
|---|---|---|---|
| Drop | None | Slow - each port costs a full timeout | Slow failure, less clear error |
| Reject | An immediate reset or ICMP message | Fast - the scan completes quickly | Fast failure, clearer error |
Dropping is the right default at a boundary facing anything untrusted: it costs an attacker time and reveals nothing about what is there. Rejecting is kinder inside a network you control, where a fast clear failure saves someone an afternoon of diagnosis and there is no scanner to frustrate.
An audit that found more than the rule said
The rule permitting the web tier to reach the application tier was written by address, because at the time the application server ran one service. It now also runs the database, on its default port. Nothing in the access list changed and nothing looks wrong in it - the web servers simply gained direct database access the day that service started, and the rule that granted it was written years earlier for a different reason.
Verifying by behaviour
A rule that reads correctly can still not work, and a learner who achieved the same result differently should not be marked wrong. Checking a filter means testing what actually happens from the machine that matters.
# Should connect
nc -w 3 10.30.30.10 443
# Should time out with no response at all
nc -w 3 10.30.30.10 3306
Terminology
- Destination port
- The port the server listens on, and the one that identifies a service in a rule.
- Stateful filtering
- Tracking permitted connections so replies are admitted without a rule allowing new inbound connections.
- Filtered
- A port whose traffic is silently discarded, giving no response.
- Refused
- A port that answered with a reset - either nothing listening, or a rejecting rule.
Key takeaways
- Match the destination port to permit a service; the source port is random and useless to match.
- An address-only permit grants every service on that host, including future ones.
- Matching connection state admits replies without permitting new inbound connections.
- Open, refused and filtered are three distinct outcomes, distinguished by whether anything replied.
- Over TCP, a refusal cannot be told apart from a stopped service.
- Drop at an untrusted boundary; reject inside a network where clear errors help more than they cost.
Ready to keep going?
Create a free account to save your progress and take the knowledge check.