Internet Firewalls

Definitions: firewall, policy, router, gateway, proxy

NAT: Network Address Translation
Source NAT, Destination NAT, Port forwarding
NAT firewall compromise via UPnP/IGD
Packet filtering and session spoofing
Port knocking
IPtables firewalls
Shorewall
 Definition of firewall

A computer networking firewall implements a se-

curity policy either:

a. in respect of network traffic traversing a router or

gateway operating between 2 networks, or

b. on a host computer in respect of network traffic

between one or more of that host computer's net-
work 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.

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

John Gilmore

While VPNs or circumvention proxies can be used to

pierce firewalls, school pupils can be disciplined and
residents of dictatorships arrested by police for net-
work security policy evasions. For these purposes a
firewall is better seen as a line of defence, and not as
the entire defence.
 Router

A router is a device that routes traffic between net-

works and which operates at the network layer. In
practice firewalls must also be able to make ac-
cept or reject decisions in respect of routed pack-
ets based on information relevant to the transport
layer.

http://en.wikipedia.org/wiki/Network_layer
http://en.wikipedia.org/wiki/Transport_layer
 Gateway 1

A gateway is a device which intercepts and relays net-

work traffic in respect of a particular application, and
which proxies this traffic such that the server provid-
ing this application sees client traffic as if it were ori-
ginating 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.
 Gateway 2
A router between the client and a proxy which inter-
cepts and redirects client requests for particular ap-
plications, (e.g. HTTP based on port 80 or for outgo-
ing 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 secur-

ity policies. For example a school may restrict the web
sites its pupils can visit e.g. based on a restricted sites
list.
Marcus Ranum's Ultimate Firewall
http://www.ranum.com/security/computer_security/papers/a1-firewall/
Network Address Translation Firewalls

Strictly speaking this is a routing technique for the purpose of

connecting a LAN using unroutable in-house LAN allocat-
able addresses to the Internet. Due to the shortage of IP ver-
sion 4 addresses, this approach is increasingly used for in-
ternal networks.

The security advantage is that the default SNAT configuration

of many consumer- grade (i.e. broadband) routers provides
an inherent firewall, which blocks server requests from cli-
ents 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.
 NAT Firewalls 2

Given the low cost and security benefits of these devices, and
the relative insecurity of most consumer PCs, this approach is
recommended as the standard means to connect even a single
Windows host to a broadband connection, in preference to dir-
ect use of a broadband modem which exposes the PC to ex-
ternal server requests and port scans.

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
192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. To allow servers
outside the firewall/router to respond to clients inside, the
router must:

● Translate outgoing IP source packet headers from the internal

host addresses to the WAN IP address of the router, so that the
session is masqueraded as coming from the NAT firewall.
● Remember the association between service requests and the in-

ternal IP addresses these come from.

● Forward replies from the client service request by the external

server to the client.

● Enable the client-server session or connection to continue on

another port as requested by the external server, forwarding any

responses by the server to the client.
 Destination NAT (DNAT)

DNAT enables servers located inside the firewall protected LAN

to be accessed by clients located outside. Here the router must:

● Translate incoming IP destination packet headers from the fire-

wall/router WAN IP address to the internal address of the serv-
er.
● Remember the association between service requests and the ex-

ternal IP addresses these come from.

● Forward replies to the client service request by the internal

server to the external client.

● Enable the client-server session or connection to continue on

another port as requested by the internal server, forwarding any

responses by the client to the server.
 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 pro-
grams 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.
 NAT firewall compromise via UPnP/IGD

The UPnP (Universal Plug and Play) Protocol is intended to

enable simple firewall rules to be setup automatically using
the Internet Gateway Device service, so that computer users
can install more complex services without needing to know
anything about these.

Unfortunately this protocol isn't authenticated. UPnP assumes

LAN requests to be trustworthy. The IGD service can
change port forwarding, DNS, WiFi and other configurations
on the fly. If a UPnP/IGD user visits a website containing
malicious Adobe Flash content this can initiate HTTP re-
quests which will compromise the firewall. An attack of this
nature has been reported in connection with BT's Home Hub
product.
 Packet filtering

A packet filtering firewall can operate statelessly based on the

legitimacy of the source and destination addresses on IP pack-
ets. One problem this solves is IP spoofing. In this kind of at-
tack 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 at-
tack, 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).

Implementing egress filtering at ISP customer-facing routers

helps mitigate DDOS attacks.
 Session spoofing

Session spoofing involves interpolation of IP packets

into a TCP or UDP session presumed to have been ini-
tiated 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. For TCP this attack has been
made more difficult by making the initial packet num-
bers within TCP sessions less predictable.

Dan Kaminsky's 2008 DNS spoofing attack involves

spoofing UDP source addresses and guessing port
numbers.
 Port Knocking 1

This is a custom technique, which has pros and cons.

Those checking their server logs will be aware of
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 attempts on the root password - including:

Jan 23 21:38:30 copsewood sshd[529]: Failed password for root from
::ffff:82.208.151.245 port 37219
 Port Knocking 2
One approach to defeat such attacks is to configure a firewall so
that the sshd (secure shell daemon) server program will only al-
low traffic through the firewall from a particular set of IP ad-
dresses. 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 In-
ternet access point.

A more flexible firewall solution is to use a port knocking dae-

mon (PND) which scans firewall logs for a specific and secret
sequence of port knocks. When the correct port-knocking se-
quence is received, the PND will reconfigure the firewall tem-
porarily to allow the IP address from which the knocking pat-
tern was received access to the SSH service port (22)
 iptables
iptables is a networking administration command-line tool
on Linux which interfaces to the kernel-provided Netfil-
ter modules. This allows for stateless and stateful fire-
walls 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.
 Iptables
chains
flow
diagram

Source:
http://dmiessler.com/
images/DM_NF.PNG
 Organisation of tables and chains

Any user-defined chains can be added to, and

called from the above predefined tables and
chains.
 Iptables targets

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 pro-
cessing. 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 con-
sume 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.
 Iptables extended targets

● REJECT - similar to drop but replying with an error ICMP

packet.
● LOG - host kernel logs the packet.

● ULOG - logs packet using a socket connection to a userspace

program.
● DNAT - rewrites destination address of packet and optionally

port, and causes this rule to be applied to all relevant packets

in session.
● SNAT - rewrites source address of packet and optionally port,

and causes this rule to be applied to all relevant packets in ses-

sion.
● MASQUERADE - similar to SNAT but suited to dynamic

host addresses allocated using DHCP.

 Iptables script example
#!/bin/bash

# iptables script to limit sshd attacks. Have to run this as root on bootup.

# whitelist

iptables -A INPUT -s home.letsystem.org -p tcp -m \

tcp --dport ssh -j ACCEPT

# For outsiders, rate-limit and enjoy

iptables -A INPUT -p tcp -m tcp --dport ssh \

-m state --state NEW \
-m recent --hitcount 3 --seconds 180 --update -j DROP

iptables -A INPUT -p tcp -m tcp --dport ssh \

-m state --state NEW \
-m recent --set -j ACCEPT
 Shorewall
This application is for compiling an iptables based fire-
wall. It allows a firewall configuration to be managed
through a set of text files. This can be done more easily,
but less flexibly than with 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 connected to different network inter-
faces.

The following example Shorewall configuration show

only 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.
 /etc/shorewall/interfaces

#ZONE INTERFACE BROADCASTOPTIONS

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.
 /etc/shorewall/masq

# You have a simple masquerading setup where eth0 connects

# to a DSL or cable modem and eth1 connects to your local
# network with subnet 192.168.0.0/24.
# Your entry in the file can be either:
# eth0 eth1
# or
# eth0 192.168.0.0/24
#
#INTERFACE SUBNET ADDRESS
eth0 eth1
 /etc/shorewall/zones

# 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
#
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
 /etc/shorewall/policy

#This file determines what to do with a new connection

# request
#SOURCE DEST POLICY LOG LEVEL
fw net ACCEPT
fw loc ACCEPT
loc fw ACCEPT
net all DROP info
all all REJECT info
 /etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST SOURCE
ORIGINAL_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 -