Where the firewall sits
◈ 6 cardsThe five basings, the seven topologies as a ladder, the DMZ and the internal firewall’s three purposes, and the argument for putting IPsec in the firewall.
Two questions that are not the same question
The previous lesson answered what does the firewall inspect. This one answers two different questions, and mixing them up is the standing error in this chapter.
Basing asks what does the firewall run on, and there are five answers:
- Bastion host — a system the administrator designates as a critical strong point. It runs a hardened operating system with only essential services; each proxy supports only a subset of its application's command set and may talk only to specific hosts; each keeps detailed audit logs including the duration of every connection; each is independent of the others, so a newly vulnerable proxy can be removed without touching the rest; and each does no disk access beyond reading its configuration file, which lets the executable filesystem be mounted read-only. The economy-of-mechanism argument gets a number here: a full UNIX mail application may run past 20,000 lines while a mail proxy can be under 1,000, and small code is code you can actually audit.
- Host-based — a software module on an individual server, with rules tailored to that host, protection independent of topology, and the useful property that a new server type can be added with its own firewall without altering the network firewall at all.
- Network device — packet filtering and stateful inspection in routers and switches.
- Virtual — in a virtualised environment, possibly implemented in the hypervisor itself.
- Personal — on the workstation, or in the home router.
A bastion host is a role on the basing axis, not a fifth firewall type. It is not an alternative to stateful inspection; it is a description of the machine an application gateway runs on.
Topology asks where does it sit. Read the seven as a ladder from smallest deployment to largest: host-resident · screening router · single bastion inline · single bastion T · double bastion inline · double bastion T · distributed configuration.
Worked example — one network, climbing the ladder
Start with a small office: half a dozen machines and a router to the ISP.
Host-resident only. Every machine runs a personal firewall. What is protected: each host, including against the others. What it costs: nothing to buy, but the policy lives in six places and drifts.
Add a screening router. A single router between the internal and external networks does stateless or full packet filtering. What is newly protected: the whole network gets one policy, and scanning from outside stops at the edge. What it costs: the router is now a security device, and it can only filter — no proxies, no content. This is the typical SOHO answer.
Replace it with a single bastion inline. One firewall device sits between an internal and an external router, and can run stateful filters and application proxies. Newly protected: everything the screening router did, plus per-connection state and application awareness. Cost: a device to buy, harden and maintain. This is the appliance configuration for small to medium organisations. Add a third interface to a DMZ and it becomes single bastion T, common in medium to large organisations.
Then the double bastion inline. The organisation now runs a public website, a mail server and a DNS server — machines that must be externally accessible and still need protection. They go in a DMZ between an external firewall, just inside the boundary router, and an internal firewall protecting the enterprise. Newly protected: three things at once, which is the answer worth memorising, because it is the internal firewall's job description:
- More stringent filtering than the external firewall, guarding enterprise servers and workstations.
- Two-way protection with respect to the DMZ — protecting the internal network from a compromised DMZ host, and protecting DMZ hosts from the internal network.
- Segmentation of the internal network from itself, with further internal firewalls separating servers from workstations.
Purpose 2 is the one candidates never state, and it is worth marks. Note also that a DMZ is defined by sitting between two firewalls — or on a third interface of one — not by what it contains. Putting the DMZ on a separate interface rather than in line gives you double bastion T. Both suit large businesses and government.
Where to put IPsec
A VPN interconnects sites over an insecure network using encryption and authentication in the lower protocol layers, standardly IPsec at the IP level, running in the router or firewall that connects each LAN and therefore transparent to the workstations behind it.
Where the IPsec function is implemented is a favourite exam question, and the reasoning is the content. Put it in a separate box behind the firewall, and VPN traffic crosses the firewall encrypted in both directions — so the firewall can no longer filter it, log it, or scan it for malware. Put it in the boundary router outside the firewall, and it sits on a less secure platform. Therefore: implement IPsec in the firewall. The general principle travels: any encryption placed upstream of an inspection point blinds that inspection point — the same fact that costs a network IDS its visibility, and the same trade-off the TLS-interception argument turns on. Individual dial-in users must run IPsec themselves and maintain high host security, since they are directly Internet-connected and are an attractive route inward.
Distributed firewalls
The last rung combines stand-alone firewall devices with host-resident firewalls under central administrative control: the stand-alone devices give global protection, the host-resident ones give protection against internal attacks, tailored per machine and application. It makes both an internal and an external DMZ sensible — less critical web servers can live in an external DMZ outside the external firewall, defended by their own host-based firewalls.
Its distinguishing operational demand is security monitoring: log aggregation and analysis, firewall statistics, and fine-grained remote monitoring of individual hosts. The reason is structural. A single appliance is one place to look; hundreds of enforcement points are not, so a distributed configuration only works when the evidence from all of them is pulled back together.