Professional Documents
Culture Documents
General Firewall Design: Section 5
General Firewall Design: Section 5
There is no one correct way to implement a firewall. The setup differs from site to
site, depending on the needs of the company.
However, there are common principles that should be considered when designing and
implementing firewalls.
Objectives
1. Understand Firewall Concepts and Purpose
2. Describe Components of Firewalls
3. Understand Advantages and Disadvantages of the Setups
Version 1 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by 5-1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
SUSE LINUX Security
Firewalls are supposed to monitor and control the traffic between two networks.
What traffic is allowed across the firewall and what traffic is blocked is the subject of
the security concept.
The difference between the two networks involved is the level of trust granted to the
users in the respective network.
Usually one has an internal network with known and trusted users and an external
network were the users are not trusted and often not even known, like in the Internet.
However, the same differentiation could apply between two networks in a company,
if part of the network is separated from the rest of the network.
5-2 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by Version 1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
General Firewall Design
Packet Filter
Packet filters decide by means of rules based on the data in IP, ICMP, TCP, and UDP
headers (source address, target address, source port, target port, and flags) what to do
with IP datagrams running through them.
The data stream can be regimented on the IP protocol level and the respective
transport protocols that are built upon it.
Packet filters do not offer detailed filtering based on the content of the IP-packets.
The following figure shows the ISO/OSI layers involved in packet filtering. The
information contained in layer 5 and above is hardly, if ever, taken into consideration
by a packet filter.
Figure 5-1
Version 1 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by 5-3
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
SUSE LINUX Security
A static packet filter has a set of rules that do not change once they are set. This has
certain disadvantages, as usually access to high ports has to be allowed, at least for
certain packets, to allow answers to requests. This can be used by a potential attacker
to gain information about the internal network using scanners like nmap.
If protocols that open an additional connection like FTP are allowed, access to a
whole range of ports has to be allowed. Control of UDP traffic with static packet
filters is not very effective.
A dynamic packet filter changes the filtering rules depending on the connections
being made. If a web page is requested by a browser, the filter allows all packets
belonging to that one connection and no others. All ports not belonging to that
connection remain closed.
With dynamic packet filters, UDP traffic can be filtered much more effectively,
allowing incoming UDP packets only when they are an answer to an outgoing packet.
In the case of protocols using a second connection, the ports for exactly that
connection can be opened up dynamically, while the rest remain closed. In this case,
data within higher ISO/OSI layers is evaluated by the packet filter (for example the
port command within the ftp communication). This kind of connection tracking
requires appropriate kernel modules to be loaded.
Dynamic packet filtering makes the task of a potential attacker much more difficult.
Packet Filters are covered in detail in the section “Packet Filters” on 6-1.
Application-Level Gateway
Application-level gateways with their proxy servers have an essential advantage over
packet filters: They manage without IP routing between the networks they connect.
The IP datagrams are received by the proxy servers on the application level and the
application data will be processed. At this stage all headers of the underlying
protocol levels have already been removed. The determination of the target is done
on the basis of the address data inside the application data (for example, for email on
the basis of the email address or for HTTP on the basis of the URL).
5-4 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by Version 1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
General Firewall Design
The following figure shows the relationship of the ISO/OSI layers and
application-level gateways:
Figure 5-2
Before transmitting the data to the actual target host, the application data will be
passed through the protocol layer downwards, while each protocol layer builds a new
header of its own around the useful data, until finally the packet leaves the physical
level of the ALG. This means that no header data can travel unchanged from one side
of the gateway to the other beneath the application level, as they are created again by
the proxy servers before being sent. Therefore, malicious headers will, in most cases,
be disposed of automatically during the passage through the ALGs.
With ALGs that are aware of the protocol they relay, rules can be set that filter
according to content, client software, user, and other criteria. An example for such an
ALG is the HTTP-proxy squid.
Not for every protocol exists a dedicated proxy software. There are generic proxy
servers, also sometimes called circuit level proxy servers, to relay protocols for
which there is no dedicated proxy. They do not, however, allow the detailed control
as dedicated proxy servers do. In practice they offer more or less the same
functionality and level of security as packet filters. Examples of generic proxy
servers are socks and rinetd.
Version 1 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by 5-5
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
SUSE LINUX Security
Buffer zones between insecure networks and secure ones are referred to as
demilitarized zones (DMZ). Data traffic between public networks and the DMZ is
controlled and regulated through packet filters and application-level gateways exactly
as data traffic between a DMZ and a secure network is.
Figure 5-3
5-6 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by Version 1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
General Firewall Design
Figure 5-4
Version 1 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by 5-7
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
SUSE LINUX Security
Another layout could look like the following. Keep in mind that each additional
computer increases the costs in terms of hardware, energy consumption,
administrative efforts, and know-how required.
Figure 5-5
5-8 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by Version 1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
General Firewall Design
The various technologies described have advantages and disadvantages that make
them more or less suitable for certain tasks.
Packet Filters
Packet filters
n Allow control of the traffic based on IP address, ports, protocol, TCP flags, and
state of the connection.
n Do not require modifications of clients or cooperation on the part of the user.
n Do not put a heavy burden on the network in terms of speed and bandwidth.
n Have limited ways of monitoring the content of the connection.
n Have no way to control the traffic based on the user.
n Cannot effectively control some protocols, such as RPC-based protocols or UDP
with static filters.
Application-Level Gateways
Application-level Gateways
n Allow detailed monitoring and control of the traffic.
n Do not require routing to be enabled.
n Often need modified clients.
n Have dedicated proxy servers only for a few protocols.
n Depending on your bandwidth needs, might need powerful hardware.
Version 1 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by 5-9
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
SUSE LINUX Security
Caution
The classical concept—Internet bad and evil versus Intranet good and nice—is no
longer valid (if it ever was). What used to be the rogue modems in the past are now
wireless cards that allow access to notebooks while they are plugged in to the
corporate LAN.
Notebooks can become infected while accessing the Internet in a hotel or at home.
Infected notebooks access corporate resources via VPN, allowing someone who uses
a backdoor installed on the notebook to access corporate resources.
But not only notebooks are to blame. Local workstations can get infected via email or
by just visiting a site that installs malware without user interaction by exploiting a
browser vulnerability.
And there are other classes of attacks that are not even covered in this course, like
SQL injection. These attacks use legitimate paths through the firewall, like access to
the web server, but target other areas; for example, the database behind the web
server.
Errors in the programming of the web frontend could lead to unauthorized database
access if, for instance, the input in HTML forms is not processed correctly.
A firewall is not a panacea that cures all. You have to know its uses and its
limitations.
5-10 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by Version 1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
General Firewall Design
Summary
Objective Summary
Version 1 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by 5-11
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.
SUSE LINUX Security
5-12 Copyright © 2010 Novell, Inc. Copying or distributing all or part of this manual is protected by Version 1
a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.