Computer Networking Firewalls

Definition of Firewall

A computer networking firewall implements a security policy either in respect of network traffic traversing a router or gateway operating between 2 networks, or on a host computer in respect of network traffic between one or more of that host computer's network connections and the host computer itself.

Security Policy

A security policy in this context is a decision about network traffic that should be allowed and/or traffic that should be blocked.


A router is a device that routes traffic between networks and which operates at the network layer. In practice firewalls must also be able to make accept or reject decisions in respect of routed packets based on information relevant to the transport layer.


A gateway is a device which intercepts and relays network traffic in respect of a particular application, and which proxies this traffic such that the server providing this application sees client traffic as if it were originating and terminating at the gateway. The location of the gateway might be transparent to the client in some cases, or part of the client configuration in other cases.

Where a gateway acts as a network firewall, its security influence will be restricted to the application/s which it proxies. A router between the client and a proxy which intercepts and redirects client requests for particular applications, (e.g. HTTP based on port 80 or for outgoing SMTP based on port 25) to specific gateways is acting as an integral part of the firewall provided by this redirecting proxy service. Application gateways might have traffic management and network efficiency purposes in addition to security purposes or both.

Gateways can be used to implement higher level security policies. For example a school may restrict the web sites its pupils can visit without using a circumvention proxy, e.g. based on a restricted sites list.

Gilmore's Law

"The Net treats censorship as damage and routes around it" John Gilmore

While firewalls can be circumvented and VPNs used to pierce firewalls, school pupils can be disciplined and residents of dictatorships arrested by police for network security policy circumventions. For these purposes a firewall is best seen as one line of defence, and not as the entire defence.

Marcus Ranum's Ultimate Firewall

For some light amusement a solution has been proposed which prevents 100% of attacks occuring over a network.

Network Address Translation Firewalls

Strictly speaking this is a routing technique for the purpose of connecting a LAN using unroutable in-house LAN allocatable addresses to the Internet. Due to the shortage of IP version 4 addresses, this approach is increasingly used for internal networks. The security advantage is that the default SNAT configuration of consumer- grade (i.e. broadband) routers provides an inherent firewall, which blocks server requests from clients on the WAN side of the router to hosts on the LAN side, while allowing all client requests from the LAN side to be serviced from the WAN side. Given the low cost and security benefits of these devices, and the relative administrative insecurity of most consumer PCs, this approach is now generally recommendable as the standard means to connect even a single Windows host to a broadband connection, in preference to use of (or occasionally together with) a broadband modem.

An NAT firewall is stateful, as it is concerned with maintaining transport layer connections, as well as translating addresses on network layer packets. Knowing which packets to allow through the firewall depends upon whether these are part of a legitimately initiated session.

Source NAT (SNAT)

Private IP addresses are reserved in RFC 1918 and use netblocks, and To allow servers outside the firewall/router to respond to clients inside, the router must:

Destination NAT (DNAT)

DNAT enables servers located inside the firewall protected LAN to be accessed by clients located outside. Here the router must:

Port Address Translation

Typical NAT capable firewalls can often usefully change port numbers on SNAT sessions, to enable a server located inside the firewall to provide a particular service, e.g. DNS or SMTP using different or differently-configured server programs to respond to internal LAN requests and to external WAN requests. For example a host might be configured to provide outgoing SMTP service for the LAN on port 25 and incoming SMTP service on port 2525. The firewall will translate the port numbering for DNAT'ed incoming SMTP requests from 25 to 2525 and will also translate outgoing responses on this port intelligently.

Packet filtering and session spoofing

A packet filtering firewall can operate statelessly based on the legitimacy of the source and destination addresses on IP packets. One problem this solves is IP spoofing. In this kind of attack trust relationships between computers are exploited by sending packets purporting to come from a trusted computer, but where the origin is forged. For a firewall to defeat this attack, packets with origins internal to the network should be blocked if coming from outside (ingress filtering). Packets with origin addresses external to the network should be blocked if coming from the inside (egress filtering).

Session spoofing involves interpolation of IP packets into a TCP session presumed to have been initiated between trusted hosts. For example, an attacker can predict when a web server will contact a back end SQL database server based on input to the web server provided by the attacker. This attack has been made more difficult by making the initial packet numbers within TCP sessions less predictable.

Port Knocking

Those checking their server logs will be aware of typically automated attempts to "brute force" system logins. This involves guessing popular passwords, typically on a SSH (secure shell) server. The following commands:

cd /var/log
grep sshd auth.log | grep password | grep root

Showed 209 logged attempts on the root password - including:

Jan 23 21:38:30 copsewood sshd[529]: Failed password for root from ::ffff: port 37219 ssh2
Jan 23 21:38:31 copsewood sshd[531]: Failed password for root from ::ffff: port 37247 ssh2
Jan 23 21:38:32 copsewood sshd[533]: Failed password for root from ::ffff: port 37280 ssh2
Jan 23 21:38:32 copsewood sshd[535]: Failed password for root from ::ffff: port 37308 ssh2

One approach to defeat such attacks is to configure a firewall so that the sshd (secure shell daemon) server program will only allow traffic through the firewall from a particular set of IP addresses. This is going to be too restrictive if you need to fix a server problem when you receive an automated SMS watchdog text message while on holiday and need to use the nearest Internet access point.

A more flexible firewall solution is to use a port knocking daemon (PND) which scans firewall logs for a specific and secret sequence of port knocks. When the correct port-knocking sequence is received, the PND will reconfigure the firewall temporarily to allow the IP address from which the knocking pattern was received access to the SSH service port (22)

For more information see the Wikipedia Port Knocking article.

However to make your firewall dynamic enough to respond in this manner you will need more sophisticated means to configure it, as well as having good real-time information about port-knocking packets received by the firewall.



iptables is a networking administration command-line tool on Linux which interfaces to the kernel-provided Netfilter modules. This allows for stateless and stateful firewalls and NAT. It is useful to think of IPtables as being a specialised firewall-creation programming language.

Programs in this language are made up of a set of chains, comparable to a subroutine or function in conventional programming. These chains are made up of individual rules and are contained within particular "tables". A chain can be called from another, and can return to its caller.

Flow Diagram

iptables flow diagram

(Sourced from:

Organisation of tables and chains

table chains responsibilities
Filter Input, Output, Forward blocking or passing packets
NAT Prerouting, Postrouting, Output rewriting from/to addresses and port numbers
Mangle Prerouting, Input, Forward, Output, Postrouting advanced effects, e.g. including quality of service.

Any user-defined chains can be added to, and called from the above predefined tables and chains.


Each rule has a target, which defines what happens to the packet. Targets are: ACCEPT, DROP, QUEUE, or RETURN, or a target defined by another user-defined chain to which the packet is passed for further processing. The effect of QUEUE is to allow the packet to be processed by a userspace program, e.g. for the purpose of creating a complex tarpit designed to consume massive remote resources in exchange for trivial local resources when malicious packets are received. RETURN allows processing of the packet to continue in the chain's caller module.

Extended targets include:

Connection Tracking

For iptables to act as a stateful firewall, connections are tracked, to enable all packets in a connection to be processed based on a set of rules determined when the first packet in the connection is seen, or when the connection spawns a new TCP session, e.g. to relate modular FTP and HTTP control and file download connections.

keyword type of packet
NEW First packet from client to server initiating session
ESTABLISHED Part of existing session.
RELATED New connection (e.g. on different port) related to existing session.
INVALID e.g. a packet not validly initiating a connection and unrelated to any known session.


This is a higher-level application for controlling an iptables based firewall. It allows a simple or complex firewall configuration to be managed through a set of text files. This can be done more easily, but perhaps with slightly less flexibility than using iptables rules directly. Shorewall enables a multi-homed host to be handled as a set of zones, e.g. a DMZ (demilitarised zone), a LAN and a WAN zone which are connected to different network interfaces.

Below is an example Shorewall configuration showing the parts of the standard files which were changed. The example is taken from a dual Ethernet card Linux PC used as a broadband router for a home network. All of the files below included extensive notes and suggested configurations in the comments sections. Only the added lines of the shorewall configuration and most relevant comments are shown. Not all possible configurations or files are shown - for example you could also use Shorewall to blacklist hosts with specific IP addresses and enforce specific IP address to MAC address combinations on the local network.


net	eth0            detect          dhcp,routefilter,norfc1918
loc	eth1            detect

relevant comments

# norfc1918    - This interface should not receive
# any packets whose source is in one
# of the ranges reserved by RFC 1918
# (i.e., private or "non-routable"
# addresses. If packet mangling is
# enabled in shorewall.conf, packets
# whose destination addresses are
# reserved by RFC 1918 are also rejected.


# Shorewall 1.3 - Masquerade file
# /etc/shorewall/masq
# Use this file to define dynamic NAT (Masquerading) and to define Source NAT
# (SNAT).
#	Example 1:
#		  You have a simple masquerading setup where eth0 connects to
#		  a DSL or cable modem and eth1 connects to your local network
#		  with subnet
#		  Your entry in the file can be either:
#			eth0	eth1
#		  or
#			eth0
eth0	eth1


#	This file is used to define the hosts that are accessible when the 
#	firewall is stopped
eth1		-


# This file determines your network zones. Columns are:
#	ZONE		Short name of the zone
#	DISPLAY		Display name of the zone
#	COMMENTS	Comments about the zone
net	Net		Internet
loc	Local		Local networks


#	This file determines what to do with a new connection request
fw		net		ACCEPT
fw		loc		ACCEPT
loc		fw		ACCEPT
net		all		DROP		info
all		all		REJECT		info


This file is shown in full including various examples.

# Shorewall version 1.3 - Rules File
# /etc/shorewall/rules
#	Rules in this file govern connection establishment. Requests and
#	responses are automatically allowed using connection tracking.
#	In most places where an IP address or subnet is allowed, you
#	can preceed the address/subnet with "!" (e.g., ! to
#	indicate that the rule matches all addresses except the address/subnet
#	given. Notice that no white space is permitted between "!" and the
#	address/subnet.
# Columns are:
#				ACCEPT   -- allow the connection request
#				DROP     -- ignore the request
#				REJECT   -- disallow the request and return an
#					    icmp-unreachable or an RST packet.
#				DNAT     -- Forward the request to another
#					    system (and optionally another
#					    port).
#				DNAT-    -- Advanced users only.
#					    Like DNAT but only generates the
#					    DNAT iptables rule and not
#					    the companion ACCEPT rule.
#				REDIRECT -- Redirect the request to a local
#					    port on the firewall.
#			May optionally be followed by ":" and a syslog log
#			level (e.g, REJECT:info). This causes the packet to be
#			logged at the specified level.
#			Beginning with Shorewall version 1.3.12, you may
#			also specify ULOG (must be in upper case) as a log level.\
#			This will log to the ULOG target and sent to a separate log
#			through use of ulogd
#			(
#	SOURCE		Source hosts to which the rule applies. May be a zone
#                       defined in /etc/shorewall/zones, $FW to indicate the
#			firewall itself, or "all" If the ACTION is DNAT or
#			REDIRECT, sub-zones of the specified zone may be
#			excluded from the rule by following the zone name with
#			"!' and a comma-separated list of sub-zone names.
#			Except when "all" is specified, clients may be further
#			restricted to a list of subnets and/or hosts by
#			appending ":" and a comma-separated list of subnets
#			and/or hosts. Hosts may be specified by IP or MAC
#			address; mac addresses must begin with "~" and must use
#			"-" as a separator.
#			dmz:		Host in the DMZ
#			net:	Subnet on the
#						Internet
#			loc:,
#						Hosts and
# in the local zone.
#			loc:~00-A0-C9-15-39-78  Host in the local zone with
#                                               MAC address 00:A0:C9:15:39:78.
#			Alternatively, clients may be specified by interface
#			by appending ":" to the zone name followed by the
#			interface name. For example, loc:eth1 specifies a
#			client that communicates with the firewall system
#			through eth1. This may be optionally followed by
#			another colon (":") and an IP/MAC/subnet address
#			as described above (e.g., loc:eth1:
#	DEST		Location of Server. May be a zone defined in
#			/etc/shorewall/zones, $FW to indicate the firewall
#			itself or "all"
#			Except when "all" is specified, the server may be
#			further restricted to a particular subnet, host or
#			interface by appending ":" and the subnet, host or
#			interface. See above.
#				Restrictions:
#				1. MAC addresses are not allowed.
#				2. In DNAT rules, only IP addresses are
#				   allowed; no FQDNs or subnet addresses
#				   are permitted.
#			The port that the server is listening on may be
#			included and separated from the server's IP address by
#			":". If omitted, the firewall will not modifiy the
#			destination port. A destination port may only be
#			included if the ACTION is DNAT or REDIRECT.
#			Example: loc: specifies a local
#			server at IP address and listening on port
#			3128. The port number MUST be specified as an integer
#			and not as a name from /etc/services.
#			if the ACTION is REDIRECT, this column needs only to
#			contain the port number on the firewall that the
#			request should be redirected to.
#	PROTO		Protocol - Must be tcp, udp , icmp , a number,
#			all or related. If related, the remainder of the
#			entry must be omitted and connection requests that are
#			related to existing requests will be accepted.
#	DEST PORT(S)    Destination Ports. A comma-separated list of Port
#			names (from /etc/services), port numbers or port
#			ranges; if the protocol is "icmp", this column is
#			interpreted as the destination icmp-type(s).
#			A port range is expressed as <low port>:<high port>.
#			This column is ignored if PROTOCOL = all but must be
#			entered if any of the following ields are supplied.
#			In that case, it is suggested that this field contain
#			 "-"
#			If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
#			only a single Netfilter rule will be generated if in
#			this list and the CLIENT PORT(S) list below:
#			1. There are 15 or less ports listed.
#			2. No port ranges are included.
#			Otherwise, a separate rule will be generated for each
#			port.
#	CLIENT PORT(S)	(Optional) Port(s) used by the client. If omitted,
#			any source port is acceptable. Specified as a comma-
#			separated list of port names, port numbers or port
#			ranges.
#			If you don't want to restrict client ports but need to
#			specify an ADDRESS in the next column, then place "-"
#			in this column.
#			If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
#			only a single Netfilter rule will be generated if in
#			this list and the DEST PORT(S) list above:
#			1. There are 15 or less ports listed.
#			2. No port ranges are included.
#			Otherwise, a separate rule will be generated for each
#			port.
#	ORIGINAL DEST	(0ptional -- only allowed if ACTION is DNAT or 
#                       REDIRECT) If included and different from the IP
#			address given in the SERVER column, this is an address
#			on some interface on the firewall and connections to
#			that address will be forwarded to the IP and port
#			specified in the DEST column.
#			The address may optionally be followed by
#			a colon (":") and a second IP address. This causes
#			Shorewall to use the second IP address as the source
#			address in forwarded packets. See the Shorewall
#			documentation for restrictions concerning this feature.
#			If no source IP address is given, the original source
#			address is not altered.
#	Example: Accept SMTP requests from the DMZ to the internet
#	#                               PORT    PORT(S) DEST
#	ACCEPT	dmz	net	  tcp	smtp
#	Example: Forward all ssh and http connection requests from the internet
#		 to local system
#	#                                       PORT    PORT(S) DEST
#	DNAT	net	loc: tcp	ssh,http
#	Example: Redirect all locally-originating www connection requests to
#		 port 3128 on the firewall (Squid running on the firewall
#		 system) except when the destination address is
#	#                               PORT    PORT(S) DEST
#	REDIRECT loc	3128      tcp	www	 -	!
#	Example: All http requests from the internet to address
#       are to be forwarded to
#	#                               	PORT    PORT(S) DEST
#	DNAT      net	loc: tcp     80      -
#                       	        	PORT    PORT(S)    DEST
# Accept DNS connections from the firewall to the network
ACCEPT		fw	  net		tcp	53
ACCEPT		fw	  net		udp	53
# Accept SSH connections from the local network for administration
ACCEPT		loc	  fw		tcp	22
# Accept Ping Ubiquitously
ACCEPT		loc	fw		icmp	8
ACCEPT		net	fw		icmp	8
# All ICMP are accepted fw->all
ACCEPT  net     fw      tcp     22      -
ACCEPT  net     fw      tcp     8888    -
ACCEPT  net     fw      tcp     9090    -