Network security
Firewalls in practice: inside/outside/DMZ zones, rules, stateful inspection, VPN and common misconfigurations.
Lesson 1: The open-network problem
A network with no door
From the previous courses you have a network that works – it can connect anyone to anyone. But that’s now a problem. The company is connected to the internet and inside it has servers and sensitive data. When there’s no boundary between the internet and the inside, anyone in the world can simply connect to them. And inside, everyone trusts everyone – nothing is watching. An open network = an open door.
Step by step
- A company on the internet: inside a SERVER and DATA. Between the internet and the inside there’s no boundary.
- Anyone on the internet sends a packet – and it goes straight inside to the SERVER. Nothing stops it on the way.
- And likewise to the DATA. Inside everyone trusts everyone, so an attacker who gets in can reach everything. That’s a serious problem.
- We need someone at the boundary to decide what may come in and what may not. That gatekeeper is a firewall – and this whole course is about it.
What’s at risk
What can actually happen when a network is open? The attacker needn’t "break" anything – it’s enough that they can see the servers. First they scan what’s running (which ports/services are open). Then they try to reach the sensitive stuff (databases, admin interfaces, backups). And if they succeed, they carry the data out (exfiltration) or settle in. All because nothing stands in their way.
Step by step
- Scan. The attacker first maps what runs on your servers and what’s reachable. For free, just looking.
- Reach. They find an open service and reach the valuable bits – the database, admin interface, backups. In an open network nothing stops them.
- Damage. They take the data out (exfiltration), encrypt it (ransomware) or settle in the network for later. This is where it hurts.
- The common thread: nothing guards the boundary. With a firewall there, most of this would be stopped right at the entrance. Let’s put one there.
The firewall = a gatekeeper
The solution is a firewall – we place it exactly on the boundary between the internet and the internal network. It acts as a gatekeeper: every packet (a chunk of data with an address, from the How networks work course) that wants through is judged against rules and either allowed or blocked. Legitimate things (a customer to the web server) pass; uninvited ones (anyone from the internet to the database) are stopped. Nothing crosses the boundary "just like that".
Step by step
- On the boundary stands a firewall. All traffic between the internet and the inside must now go through it.
- A customer wants the WEB (port 443). That’s fine → the firewall lets it through.
- Someone from the internet wants the DATA. That has no business → the firewall blocks it. The boundary holds.
- A firewall decides by rules, not at random. What those rules look like and how networks split into zones (of trust) is the content of the next lessons.
Lesson 2: Zones: inside, outside, DMZ
Trust zones
A firewall doesn’t work with individual cables but with zones – groups of networks by how much you trust them. The three classics: OUTSIDE (the internet – you trust no one), INSIDE (the internal network – fully trusted) and the DMZ (semi-trusted – for public servers that must be reachable from the internet, e.g. a web server). A zone isn’t a property of the packet but of the firewall’s interface – whichever interface (cable) a packet arrives on decides its zone. The firewall then handles one thing: who from which zone may go to which.
Step by step
- In the middle a firewall, around it three zones. Each has a different trust level. Let’s go through them.
- OUTSIDE = the internet. You trust no one – anything from here is a potential threat.
- INSIDE = your internal network (PCs, servers, data). Fully trusted – this is what you protect.
- DMZ = semi-trusted. Here go public servers (web) that must be reached from the internet – but kept apart from the inside. Who may go where the firewall decides by rules (next modules).
Default deny inbound
The basic firewall rule is really common sense: trust outward, not inward. INSIDE → OUTSIDE (an employee to the internet) is allowed – replies to what you asked for may come back (how the firewall tells a reply from an unsolicited connection comes in the Stateful firewall lesson). But OUTSIDE → INSIDE (someone on the internet starting a connection) is denied by default. No uninvited outsider gets in. Exceptions (e.g. to the web in the DMZ) are made with specific rules.
Step by step
- PC (inside) to the internet: an employee browses. The firewall allows it – and lets the replies back.
- Someone on the internet starts a connection inward: the firewall denies it by default. The uninvited guest doesn’t get in.
- This is the core: trust outward, not inward. Anything that should still get in from outside (the web) is permitted by a targeted rule – and ideally into the DMZ, not straight inside. That’s the next module.
DMZ: public servers apart
Why a DMZ at all? You have a web server that anyone on the internet must reach. If you put it inside and opened a hole to it, an attacker who breaches that web server stands right in your internal network – at the data, at everything. So public servers go in the DMZ: their own zone between the internet and the inside. When the DMZ web is breached, the attacker is trapped in the DMZ and can’t reach the inside (the firewall won’t let them).
Step by step
- Customers must reach the WEB. It’s in the DMZ, so the firewall allows internet → DMZ (web). The web works.
- Say the DMZ web is breached (a vulnerability). The attacker now controls a server in the DMZ. How far can they get?
- From the DMZ the attacker tries to go inside – for the data. The firewall blocks DMZ → inside. They’re trapped in the DMZ.
- That’s the point of a DMZ: the public server is reachable, but its breach doesn’t endanger the inside. A small blast radius. The specific inter-zone rules are the next module.
Rules between zones
Putting it together gives a simple matrix – who from which zone may go where: INSIDE → anywhere (out and to the DMZ, it’s trusted). OUTSIDE → DMZ for the web only (port 443, by a targeted rule). OUTSIDE → INSIDE never (default deny). DMZ → INSIDE never (so a breached web can’t get inside). These four rules are the backbone of almost every firewall.
Step by step
- INSIDE → out and to the DMZ: permitted. The internal network is trusted, it may initiate connections anywhere.
- OUTSIDE → DMZ (web 443): permitted by a targeted rule. Just this one service, nothing more.
- OUTSIDE → INSIDE: denied (default deny). No one reaches internal data from the internet.
- DMZ → INSIDE: denied. Even if the DMZ web falls, the attacker can’t get inside. These four rules = the firewall’s skeleton. What a rule looks like exactly is the next lesson.
The whole picture
Let’s put it together. A firewall splits the network into zones by trust and between them allows only what makes sense: out yes, in by invitation only, public servers off to the side in the DMZ. One design buys you both order and safety. You’ll try this in the web-dmz task: the DMZ web server should be reachable from the internet on port 443, but the internal database should not.
Step by step
- Three zones, one firewall, clear rules. This is a design that protects while keeping the web working.
- INSIDE works normally – out to the internet and to the DMZ web. No restriction for the trusted zone.
- Customers from the internet reach only the DMZ web (443). Exactly what you want.
- But internet → internal database? Blocked. And if the DMZ web fell, it still couldn’t get inside. You’ll now build this in the web-dmz task.
Lesson 3: Anatomy of a rule
What a rule is made of
What does a firewall rule actually look like? It’s a sentence with five parts: an action (permit / deny), a source (from where), a destination (to where), a protocol (TCP/UDP/…) and a port (which service). E.g. "permit traffic from inside to the DMZ web over TCP 443". Every passing packet is compared against these parts – and if they match, the firewall does that action. (The structure is the same as an ACL from the Switching and VLANs course; a firewall adds zones and tracks connection state – coming up in the next lesson.)
Step by step
- A rule = five parts. Let’s go through them on the example "permit inside → DMZ web on 443".
- Action – PERMIT (or DENY). What happens to matching traffic.
- Source and destination – from where (inside) and to where (DMZ web). The rule applies only to this direction.
- Protocol and port – TCP and 443 (HTTPS). This targets exactly one service (the web), not everything.
First-match: order matters
There’s usually more than one rule and the firewall reads them top-down. As soon as a packet matches the first rule, it does that action and reads no further – the first match wins. This means order matters: specific denies must be above general permits, or they’ll never be reached. Watch a packet travel down the list.
Step by step
- Two rules: 1) deny Telnet (23), 2) permit anything to mgmt. A packet for Telnet (23) arrives.
- The firewall reads from the top: rule 1 (deny Telnet) matches → packet denied. Rule 2 is not read.
- And note: if permit anything were on top, it would match first and Telnet would pass – the deny below would never apply. That’s why order matters.
Default deny at the end
And what about traffic that matches no rule? At the end of every firewall there’s an invisible default "deny all" (implicit deny). So: what isn’t explicitly permitted is denied. That’s the safe setting – forgotten traffic is blocked rather than accidentally let through. So you write only permits for what you actually want; the rest is handled by the default deny.
Step by step
- You write only permits: inside out on 443 and outside to the DMZ web. Nothing more.
- But at the end there’s always an invisible "deny all". Everything that didn’t match a permit falls here.
- An outside → internal database packet arrives. It matches no permit → falls to the default deny → denied. Exactly as you want, without writing a special deny.
Example: block Telnet
A concrete real-world example. You connect to the management server (MGMT) – but Telnet (port 23) is unencrypted and dangerous, while SSH (22) is encrypted and safe. So you want: permit SSH, deny Telnet. You make a rule "deny PC → MGMT, TCP 23", and since SSH on 22 doesn’t match the deny, it passes. You’ll try exactly this in the block-telnet task – and mind the rule order.
Step by step
- An admin connects from the PC to the MGMT server. It listens on SSH (22) and Telnet (23).
- SSH (22) is encrypted and safe → let it through. The admin works normally.
- Telnet (23) is unencrypted (passwords in clear text) → you deny it with a rule. The firewall stops it.
- One targeted rule (deny TCP 23) + the default management permit = safe. Mind the order so the deny isn’t below the permit. Build it in the block-telnet task.
Lesson 4: Stateful firewall
The reply problem
Here’s the catch we promised to resolve back in the zones lesson. We learned: inside → outside permitted, outside → inside denied. But when a PC requests a web page, the server sends a reply – and that goes outside → inside! By the default deny it should be blocked and the web wouldn’t work at all. Manually permitting all return traffic from the internet would be a huge hole. So how do you let replies in, but not uninvited connections?
Step by step
- The PC requests the web. That’s inside → outside → the firewall allows it. So far so good.
- The server replies. But the reply goes outside → inside – which is default deny! A dumb firewall would block it and the web wouldn’t work.
- Manually allowing everything back from the internet = flinging the gates wide open. We need a smarter firewall that recognizes the reply to what the PC itself asked for. That’s a stateful firewall – next module.
The connection table
The solution is a stateful firewall. It remembers connections that started from inside. When the PC opens a connection out, the firewall records it in a connection table: who, to where, which port. This table is its memory – it knows what’s "in progress". Thanks to it, it recognizes that an incoming reply belongs to an existing connection and lets it in – without you writing a single extra rule.
Step by step
- The PC is about to open a connection out to the web. The stateful firewall will pay attention.
- The PC opens a connection PC → WEB:443. The firewall lets it through and, crucially, records it.
- The connection table now holds: "PC ↔ WEB:443, active". The firewall remembers this connection started from inside.
- This memory is the whole trick. How the firewall uses it for the reply is the very next module.
Replies pass, unsolicited don’t
Now we use the trick. When traffic comes outside → inside, the firewall first checks the connection table. Does it match an active connection? → it’s a reply to what the PC asked for → let it in. Matches nothing? → no one inside started it → it’s unsolicited → block it. So replies pass on their own and an attacker’s connections don’t. Safe and convenient.
Step by step
- A reply comes from the WEB (outside → inside). The firewall doesn’t pass it blindly – it first checks the table.
- The reply matches the entry "PC ↔ WEB:443" → it’s a requested reply → the firewall lets it through to the PC. The web works.
- Now someone on the internet starts on their own. Nothing matches in the table (no one inside started it) → unsolicited → the firewall blocks it. The attacker doesn’t get in.
- That’s how elegantly it holds: replies yes, unsolicited connections no – and you write no rule for return traffic. That’s the power of a stateful firewall.
UDP and ICMP
One subtlety. TCP has a clear start and end of a connection (a handshake) – state is easy to track. But UDP (e.g. a DNS query) and ICMP (ping) have no "connection" – they’re single messages. How to track them? The firewall creates a temporary entry for them too (pseudo-state) with a timeout: after a query goes out it waits a few seconds for the reply and lets it in; then it discards the entry. Thanks to this a DNS reply or a ping reply passes without you permitting anything by hand.
Step by step
- For TCP the firewall knows exactly when a connection started and ended (handshake, teardown). State is easy to keep.
- But a UDP query (DNS) or ICMP (ping) have no connection – they’re standalone messages. How to let the reply in?
- The firewall still makes a temporary entry with a timeout: "expecting a reply to this DNS query for a few seconds". It then lets that reply in.
- So a DNS reply or ping reply passes in time. A late or unsolicited "reply" won’t (the entry expired). Thus stateful inspection covers connectionless protocols too.
Lesson 5: Shadowed rules and mistakes
A shadowed rule
The most common firewall mistake follows from first-match: a shadowed rule. You want to deny "guest → file-server", but you put that deny BELOW a broad "permit all to the file-server". Because the first match wins, the guest matches the permit on top and your deny never takes effect – it’s in the shadow. It looks like you have protection, but you don’t. Watch.
Step by step
- You want to deny guest → file-server. But the deny is below a broad "permit all to the file-server". A packet from the guest arrives.
- First-match: the guest matches the permit on top → passes. Your deny below is never read. The protection is only on paper.
- Fix: move the deny ABOVE the permit. Now the guest matches the deny first → denied, while the permit still lets others through. This is exactly the shadow-rule task.
An over-permissive rule
The second classic mistake: an over-permissive rule. "Permit any → any" (anything anywhere) is convenient – everything works – but it opens absolutely everything, including what you never meant to allow. A rule should be as narrow as possible: an exact source, destination, protocol and port. Instead of "permit all to the server" prefer "permit only web 443 from the internet to that one server". Less open = less risk.
Step by step
- This single "any → any" rule permits everything. The web works, but… so does everything else.
- An attacker tries internet → internal database – and it passes, because "any → any" permits it. A convenient rule = an open gate.
- Fix: narrow the rule to exactly what you need – "outside → web-server, TCP 443". Everything else falls to the default deny. The principle of least privilege.
A forgotten rule
The third mistake is human: a forgotten rule. A vendor needed remote access (RDP 3389) to one server for a week, so a "temporary" permit was added. The work ended – but the rule stayed. A year later no one knows why it’s there, and it’s an open hole an attacker will eventually find. Rules age and pile up.
Step by step
- A "temporary" permit is added: internet → server, RDP 3389, so a vendor can connect for a week.
- The vendor leaves, the work ends – but no one deletes the rule. It stays for months, years.
- And one day an attacker finds the open RDP from the internet and tries passwords. The forgotten exception became an entry point. That’s why rules must be cleaned up regularly – next module.
Audit and clean-up
The fix for all three mistakes is one: a regular audit (clean-up) of rules. You go through the list looking for three things: shadowed rules (never apply – fix or delete), over-broad rules (narrow them) and forgotten / unused rules (delete). Fewer rules that are narrow and meaningful is safer and clearer than a hundred old exceptions. You’ll try this in the shadow-rule task.
Step by step
- Shadowed. Find rules that order never reaches, and fix the order (or delete).
- Over-broad. Narrow "any → any" and the like to exactly what’s needed.
- Forgotten. Delete temporary exceptions and unused rules. Every rule should have a reason.
- A regular audit keeps the firewall narrow, clean and understandable. That ends the rule theory – now fix one mistake in the shadow-rule task.
Lesson 6: VPN: remote access
Remote access
An employee is working from home and needs the internal server at the company (shared drives, systems). But that’s exactly what the whole course taught us to deny: no one gets in from the internet (default deny). So how do you let your own person in, but not an attacker? Exposing the server to the internet would be a hole. We need something that safely "carries" the remote employee inside.
Step by step
- A HOME employee wants the internal server. Between them is the whole internet and the company firewall.
- Connect directly? The firewall denies it (outside → inside = default deny). And rightly so – otherwise an attacker could connect too.
- We don’t want to open the server to the whole world. We want to let in only a verified employee and protect their traffic even across the internet. The solution = a VPN (next module).
What a VPN does
A VPN (Virtual Private Network) does two things at once. 1) A tunnel: it creates an encrypted "tunnel" across the internet between you and the company – anything passing through is unreadable on the way (even if intercepted). 2) "You’re inside": after logging in the VPN gateway assigns you an address from the internal range (much like DHCP at home) and you behave as if sitting in the office – you reach the internal server normally. And you never "opened" the public internet.
Step by step
- The VPN client and the firewall build an encrypted tunnel across the internet. Everything inside is unreadable to anyone en route.
- After logging in the employee behaves as if sitting in the office – through the tunnel they reach the internal server. The firewall allows it because it came via the authenticated tunnel.
- Two wins at once: safety (encryption) and reach (you’re "inside") – and you never exposed the server to the whole internet. That’s the magic of a VPN.
Remote-access vs site-to-site
A VPN comes in two main forms. Remote-access VPN: one person (laptop, phone) connects to the company via a client – exactly our home-office case. Site-to-site VPN: a permanent encrypted tunnel between two networks (e.g. HQ ↔ branch) that joins whole locations as if they were one network. Employees at the branch don’t even know about it – "it just works".
Step by step
- Remote-access: one employee with a VPN client (laptop, phone) connects into the company. For individuals.
- Site-to-site: a permanent tunnel between two firewalls (HQ ↔ branch). It joins whole networks – users install nothing.
- The same idea (an encrypted tunnel), two scales: one person vs a whole branch. Both terminate at the firewall – and where exactly is the next module.
Where a VPN sits on the firewall
Where does a VPN end? The tunnel typically "unwraps" at the firewall (or a dedicated VPN concentrator) – it verifies the login and places the VPN traffic into its own "VPN" zone. That zone has higher trust than the internet (it’s a verified employee), so it may reach permitted internal servers – but still under the control of rules. If the VPN interface is mistakenly in the "outside" zone, the firewall blocks the logged-in user like anyone from the internet. That exact mistake is the remote-vpn task.
Step by step
- The tunnel from the HOME client ends at the firewall. It verifies the login (credentials, certificate) – is this really our employee?
- After verifying, the firewall puts the traffic into the "VPN" zone – higher trust than outside. It may reach permitted internal servers, still by the rules.
- And there it is: the verified employee reaches the internal server. Mind the pitfall – if the VPN interface were in the "outside" zone, the firewall would block them as a stranger. You’ll fix that in the remote-vpn task.
Lesson 7: The whole path together
VLAN + firewall together
Let’s combine two courses. From the Switching and VLANs course you can split a network into VLANs (users apart, servers apart, guests apart). From this course you know firewalls and zones (boundaries, rules, DMZ). Together they form defence in layers: the firewall guards the boundary (internet ↔ DMZ ↔ inside) and VLANs with ACLs guard traffic inside (users can’t just reach the DB). One layer catches what another lets through.
Step by step
- At the boundary stands the firewall with zones: internet (outside), the WEB in the DMZ and the internal network (inside). You know this from this course.
- And inside the network is split into VLANs (PC in V10, DB in V20) with a CORE L3 and ACLs – from the Switching and VLANs course. Users and data are separated.
- This is defence in depth: a firewall at the boundary + segmentation inside. An attacker must break several independent layers, not one. Let’s walk two scenarios.
Two scenarios
Let’s walk two scenarios and see the layers cooperate. Scenario A (legitimate): a customer from the internet wants the DMZ web – that’s fine, the firewall allows port 443 into the DMZ. Scenario B (attack): someone from the internet (or the breached DMZ web) wants the internal database – here two layers stop them: the firewall (the inside zone is closed) and segmentation (the DB is in its own VLAN with an ACL). Watch.
Step by step
- Scenario A: a customer from the internet to the DMZ web (443). The firewall allows it – that’s exactly what the DMZ is for. The web works.
- Scenario B: an attack from the internet on the internal DB. Layer 1 – the firewall: the inside zone is closed (default deny) → stop. It doesn’t get in.
- And even if the attacker took over the DMZ web and tried the DB from there: layer 2 – segmentation (the DB in its own VLAN + an ACL on CORE) stops them too. Two layers, a double safeguard.
- That’s the point: legitimate traffic passes, an attack hits wall after wall. Firewall + VLANs = more than the sum of parts. With this you have the core of network security down.
What is still missing → Course 6
You have a solid secure network – but one thing is still missing: reliability. All traffic flows through one firewall. What if that single firewall (or its link) fails? The whole company is offline and unprotected at once. One device = a single point of failure. The fix – backup paths and devices, redundancy, high availability – is all of the redundancy and STP course. There you’ll learn how a network survives an outage.
Step by step
- This network is secure and works: all traffic flows through the firewall to the servers. But it hangs on one firewall.
- If that one firewall fails, the company is offline – and if bypassed, unprotected too. A single point of failure.
- We’d want a backup firewall, backup links, devices that fail over by themselves. That’s redundancy and high availability – all of the redundancy and STP course. You have a secure network; now we’ll make it resilient. And before you move on, you can put the whole course into practice – in the task below you’ll build firewall rules on the default deny principle.