Advanced Internet Security - PowerPoint PPT Presentation

1 / 69
About This Presentation

Advanced Internet Security


Platform Security is still bad (browsers, databases etc., malware threats, spam) ... But clever firewall tools like WAFs can really make a difference ( 'defense ... – PowerPoint PPT presentation

Number of Views:133
Avg rating:3.0/5.0
Slides: 70
Provided by: kri71


Transcript and Presenter's Notes

Title: Advanced Internet Security

Advanced Internet Security
Lecture on
  • Firewalls Types and Architectures

Walter Kriha
  • Part 1 Firewall Architecture
  • The purpose of a firewall
  • IP components important for firewalls
  • Firewall Types
  • Firewall limits
  • Part 2 Filtering Technology
  • IP, TCP, ICMP filtering
  • static filtering ipchains
  • dynamic (stateful) filtering iptables
  • Application level filtering proxies
  • Filtering limits, WAFs
  • Part 3 Services and Protocols
  • frequently needed services and their problems
  • dangerous services,
  • Middleware protocols
  • Service Security Analysis
  • Part 4 Securing Web Applications
  • Attacks and Mitigation
  • End-to-End Security
  • Web Application Servers
  • Reverse Proxies and DMZ
  • Authentication and Authorization

We will deal with firewall issues rather in
detail as they have a lot of impact on software
architecture as well.
Goals for today
What makes firewalls both necessary and
possible? Understand different types and concepts
of firewalls Learn what firewalls can use to do
their job and recognize their limits Understand
the whole range of firewalls from personal to
demilitarized zones to distributed.
The next sessions will cover filtering in detail
and also a lot of important services and
middleware that creates issues with firewalls.
Top Ten Vulnerabilities Windows
2002 W1 Internet Information Services (IIS) W2
Microsoft Data Access Components (MDAC) -- Remote
Data Services W3 Microsoft SQL Server W4
NETBIOS -- Unprotected Windows Networking Shares
W5 Anonymous Logon -- Null Sessions W6 LAN
Manager Authentication -- Weak LM Hashing W7
General Windows Authentication -- Accounts with
No Passwords or Weak Passwords W8 Internet
Explorer W9 Remote Registry Access W10 Windows
Scripting Host
  • 2004
  • W1 Web Servers Services
  • W2 Workstation Service
  • W3 Windows Remote Access Services
  • W4 Microsoft SQL Server (MSSQL)
  • W5 Windows Authentication
  • W6 Web Browsers
  • W7 File-Sharing Applications
  • W8 LSAS Exposures
  • W9 Mail Client
  • W10 Instant Messaging

See for future top ten lists. The
U.S. General Services Administration released
their updated top 20 security vulnerabilities on
2 October. These cause about 80 of the hacking
incidents on the internet. (quoted after Jeff
Sutherland from Against
which vulnerabilities could a firewall help?
Top Ten Unix Vulnerabilities
2002 U1 Remote Procedure Calls (RPC) U2 Apache
Web Server U3 Secure Shell (SSH) U4 Simple
Network Management Protoc ol (SNMP) U5 File
Transfer Protocol (FTP) U6 R-Services -- Trust
Relationships U7 Line Printer Daemon (LPD) U8
Sendmail U9 BIND/DNS U10 General Unix
Authentication -- Accounts with No Passwords or
Weak Passwords
  • 2004
  • U1 BIND Domain Name System
  • U2 Web Server
  • U3 Authentication
  • U4 Version Control Systems
  • U5 Mail Transport Service
  • U6 Simple Network Management Protocol (SNMP)
  • U7 Open Secure Sockets Layer (SSL)
  • U8 Misconfiguration of Enterprise Services
  • U9 Databases
  • U10 Kernel

See for future top ten
lists. Bind service is especially critical
because large numbers of outdated and insecure
versions are still in use. Note that CVS is also
quite high on the list. Apache Web Server
security problems are discussed on in
detail (e.g. using suExec properly, chrooting).
The sans report also lists important ports and
has excellent links on kernel tuning (hardening)
for security etc.
SANS top 20 of 2007
Client-side Vulnerabilities in C1. Web Browsers
C2. Office Software C3. Email Clients C4.
Media Players Server-side Vulnerabilities in
S1. Web Applications S2. Windows Services S3.
Unix and Mac OS Services S4. Backup Software
S5. Anti-virus Software S6. Management Servers
S7. Database Software
Security Policy and Personnel H1. Excessive
User Rights and Unauthorized Devices H2.
Phishing/Spear PhishingH3. Unencrypted Laptops
and Removable Media Application Abuse A1.
Instant Messaging A2. Peer-to-Peer Programs
Network Devices N1. VoIP Servers and
Phones Zero Day Attacks Z1. Zero Day Attacks
See http//
Top Trends 2008
  • Platform Security is still bad (browsers,
    databases etc., malware threats, spam)
  • Network security has gotten better
  • Application Security is really bad (input
    validation problems, old web-applications)
  • Old Bestsellers are new bestsellers the usual
    suspects prevail (web servers, browsers)
  • PDAs and smartphones are quickly moving into the
  • Embedded control security getting critical (cars,
  • A huge security industrie has established itself
    this could be considered a problem in itself.
    Security of applications cannot be an add-on.

See for current top ten
lists. Bind service is especially critical
because large numbers of outdated and insecure
versions are still in use. Note that CVS is also
quite high on the list. Apache Web Server
security problems are discussed on in
detail (e.g. using suExec properly, chrooting).
The sans report also lists important ports and
has excellent links on kernel tuning (hardening)
for security etc.
The purpose of a firewall
  • Security Policy
  • HTTP client
  • ftp client etc.

A firewall inspects, restricts and logs traffic
between different protection zones. It is also
called a Policy Enforcement Point or Choke
Control Point An intermediary in a location that
allows control of the flow of data and traffic in
accordance with a defined security prolicy.
Security and network topology are frequently
mixed into one concept. Most simple firewalls
have a good side to be protected and a bad
side from which dangerous requests are expected.
What Firewalls can do
  • Traffic can be blocked if unwanted (DOS-attacks,
    dangerous service requests)
  • traffic can be re-directed to other systems
    (transparent proxies)
  • hide the internal network (IP address, hostname,
    services) which may be more vulnerable
  • All traffic can be checked (viruses), changed and
  • Force authentication through proxies

Not all firewall types support everything, e.g.
static packet filters usually do not
Software Architecture, Security and Network
Network firewalls have a topology based concept
of security separation and segmentation. This
collides e.g. with mobile users, reorganizations
etc. and makes access control policies complex.
Software uses grouping (etc. roles) and sessions
to achieve security. Session concepts can
interfere with loadbalancing. End-to-end security
interferes with content oriented filtering. The
tight connection of security administration and
network design/administration is a special
problem in understanding firewalls.
Service-oriented requirements analysis
One approach that is effective in determining
what your firewall should do is the process of
service-oriented requirements analysis. Rather
than simply jumping to technical details about
what a firewall should provide, take a step back
and list the network services that you want to
take advantage of and relate them to your
security policy. A typical set is
World-wide web including FTP Email
USENET news (sometimes) Telnet outgoing to
remote sites (sometimes) Define security
requirements for services. Based on the list of
services you want to provide to your users,
consider whether or not you have any special
requirements that may mandate additional security
services. Determine what kinds of audit trail or
records (if any) you require relating to
transactions through your network.
In our firewall examples later we will always
list some rules to be enforced, e.g. no direct
connection to the Internet, no incoming
connection requests etc.
What needs protection and Why?
insecure operating systems
  • Security Policy
  • HTTP client
  • ftp client etc.

bad tcp/ip implementations that crash easily (DOS)
dangerous services and misconfigured software
unsuspecting users (viruses)
software bugs allowing takeover and remote control
The limits of firewalls
  • Configuration can become extremely complicated
  • Not all content can be inspected due to
    performance reasons
  • Insiders can pierce firewalls easily
  • DOS attacks frequently need to be solved at the
  • New forms of attacks are developed every day and
    can surprise a firewall.

Bad platform security and vulnerable applications
are a constant threat to security and are hard to
fight with firewalls only. But clever firewall
tools like WAFs can really make a difference (
defense in depth)
Security aspects of IP
  • Can read all traffic from
  • Can pretend to be any host

Sniffing and Spoofing are basic features of the
IP protocol. It has NO provisions for
authentication, confidentiality or integrity.
Just putting a host next to another allows the
security of both to be compromised. Reachability
through networks creates already the chance for
compromise. And focus of security is also always
on HOST and not e.g. on USER. You can see the
difference if you look at your e-mail address
your identity is derived from a hostname!
Three ways of spoofing
Spoofing host pretending to be
sourceaddr destaddr
replies can create a DOS attack on target host
  • Spoofer can read replies hijacking attack
  • Spoofer doesnt need the reply DOS attack or
    remote copy of a new passwd or .rhosts file to
    target using TCP sequence guessing
  • Spoofer tries DOS attack at host,
    executed by first victim (e.g
    echo-reply attack)
  • (from Zwicky, Cooper, Chapman pg.98ff).

Idlescan attacks
Scanning host sends regular messages to idle host
and checks IP ID count.
Scanning host sends spoofed packages to victim
sourceaddr idle host destaddr victim host
Scanning host sees jumps in IP ID counts
depending on port status on victim host
victim host replies to spoofed packages to idle
host. The replies different if ports on the
victim host are open or closed.
Most operating systems perform a simple increment
of the ip identification field for each new
package. They do not keep separate counters per
connection/partner IP address. By watching the
changes in the IP ID field an attacker can gather
intelligence about the load on a host or on its
connections. This can be even used for an
indirect scan attack without direct connection
between attacker and victim. Details Ct 23/2003
Security aspects of TCP
Some service running on port 23. What could it
be? On 6577?
Well known ports are just that no guarantee
TCP sequence number generation should be random.
Many implementations are predictable and allow
session takeover
TCP connection init allows DOS attacks
While providing a reliable connection TCP has a
number of security weaknesses. Many stacks are
also not stable and will crash under attack.
TCP SYN Flooding Denial-of-Service
Client info stored
SYN (instead of request)
Client info stored
Client info stored
Client never sends request, only SYN, Server
buffer gets filled and other clients cannot
TCP Probing
Client info stored
RESET (cancel connection initiation)
Client info deleted, initiation NOT logged
Client sends RESET, to avoid establishing a real
connection or creating a DOS condition. The whole
purpose was to get a reaction from a server on a
specified port (probing). Usually those aborted
connection requests are NOT logged on server side
TCP Sequence number guessing (1)
client (Spoofer), using its REAL IP address
ICMP probing
generates response which possibly tells spoofer
which operating system type and version is used.
This will tell client which sequence nr.
algorithm is used.
Spoofer now knows OS specifics of server and uses
public services to learn about the CURRENT TCP
Sequence number
Some public service initiation to learn seq. nr.
server Sequence Number returned
Now spoofer knows sequence number as well and can
guess the next one the server will use (see next
slide). It is essential for the client to know as
much as possible about the OS running on the
server to be able to use known vulnerabilities of
the specific version (or the whole product line)
TCP Sequence number guessing (2)
client (Spoofer)
server (allows connection requests from spoofed
IP address)
New server sequence number generated
Spoofer cannot see request but guesses sequence
nr. from past experience
SYN,ACK(SYN) Seq.Nr. 667
Spoofer Request Seq.Nr. 668
Server accepts and performs request
Many TCP-Stacks do not generate true random
sequence numbers but use constant offsets or time
based offsets. This allows spoofers to guess the
new numbers and take over the session or implant
a command.
Security aspects of ICMP
  • Probe network topologies through ping messages
    (ICMP echo-request)
  • Probe for operating systems versions etc. which
    can be derived from error messages etc.
  • Perform denial of service attacks with echo-reply
    requests to spoofed or broadcast addresses
  • Steer packets through firewalls using source
    routing information

Fragmentation needed and Dont fragment are
the most useful ICMP messages. Most others should
be disabled because they are used for network
General attacks on tcp/ip stacks
  • wrong and illegal flags in headers
  • wrong and overlapping fragments
  • hidden information in ICMP packets
  • wrong servers on well-known ports
  • oversize packets

In general every possible combination of values
for tcp/ip headers can be tried to either crash
the server/firewall or reduce processing speed or
finally find a leak into the system. Newly
written stacks are especially vulnerable for this
kind of crazy attacks.
Filtering Technology
  • Static (stateless) packet filters
  • Dynamic (stateful) packet filters
  • Application Gateways (Proxies)

These are the most important filter technologies
right now. Complexity increases from static to
dynamic to application level filtering. So do
performance problems.
On what can we trigger?
IP Header Parameters (e.g. protocol tcp or udp)
TCP Header Parameters (e.g port and direction)
ICMP Header Parameters (e.g. packet size, types)
internal network address
external network address
destination/source address
destination/source address
Advanced filtering can be performed on the
content of messages (e.g. http proxy checking
URLs), the history of packets from a certain
source etc. Not every firewall type allows all
kinds of filtering. In large scale environments
application level filtering has become the
dominant way of filtering requests with packet
filters providing additional borders of
Well known ports
Ports between 0 and 1023 are so called well-known
or protected ports. This means that on secure
systems only those services which are known to
run on those ports should really be running at
these ports and that on Unix systems root
privileges are required to open a port for
listening. Ports beyond 1023 are public and not
strictly regulated. In any case there is NO
GUARANTEE whatsoever that e.g. the service on
port 23 really is a telnet server. Still, if you
only allow connections to well-known ports the
firewall can try to do a protocol detection and
stop the connection if it believes there is no
telnet protocol going on at port 23. This is much
easier than guessing the protocol/service for
every port in use.
Network Address Translation
masquerading host (dual-homed)
eth1 w.x.y.10
NAT (or masquerading) hides internal hosts and ip
numbers. Certain ip numbers are not routed and
the masquerading host translated those into only
ONE externally visible number the one assigned
to its outgoing network interface. To hosts on
the internet every request coming from the
internal network will look like a request from
the masquerading host. This host keeps a table of
connections und maps requests back and forth.
Important only outgoing connection requests will
be allowed. To allow certain protocols which use
outside callbacks or pass internal ip-address
information in the tcp data segment, special
modules are needed which keep state information
or open ports expecting an outside callback.
Problems with tunneling protocols.
Static Packet Filter (screening router)
  • Rules e.g.
  • do not allow external connection init
  • do not allow internl connections to external port
  • source/destination address
  • protocol (tcp, udp, icmp)
  • source/destination port
  • message type (ICMP)
  • size
  • interface
  • networks
  • connection direction
  • content of data

Packet Filter
Internal network
A static packet filter is a router that
selectively (driven by the firewall rules)
forwards packets or rejects/denies them. It has
NO MEMORY of previous packets and cannot e.g.
restrict access based on time (x requests per
hour from source address y). A static packet
filter is programmed e.g. with ip-chains
commands. We will look at the details of
filtering in the next session.
Problematic Protocols
  • connectionless (UDP)
  • multi-port (e.g. one well-know and one random
  • external connection initialization
  • no standard ports
  • complex actions with remote control features
  • no clear separation of client and server

Examples of critical protocols are most
multi-media or peer-to-peer programs Netmeeting,
multimedia software, napster etc. Naturally,
those high-bandwidth protocols seek to use
multiple ports/channels concurrently. Support for
those protocols usually requires special plug-ins
for screening routers or special proxy software.
Filtering those protocols requires considerable
state on packet filters and advanced content
analysis routines.
Dynamic Packet Filter
  • Rules e.g.
  • do not allow external connection init
  • do not allow internl connections to external port

Packet Filter
packet state
packet state
  • in addition to static filters
  • history of connections and packets

packet state
Internal network
A dynamic packet filter can change its behavior
depending on previous packets. The deal much
better with complicated protocols where e.g.
external connections follow after internal
control messages. The price they pay is
performance and a higher risk of denial of
service attacks because of their state keeping
behavior. We will see an example of advanced
packet filtering using the new netfilter/ip-tables
capability in Linux next week.
content level filtering
  • Security Policy
  • all downloads filtered for malicious code
  • all pages checked for explicit language
  • certain URLs are verboten

illegal URL
connection to pornographic site
internal network
Intelligent filtering as content level
filtering is also called provides a lot of
control. Again at the price of increasing
performance requirements and scalability problems
Application Gateway (Proxy)
  • Rules e.g.
  • do not allow user X to use http
  • run mail server proxy

Mail Server
Special proxy software connects internal and
external networks The proxy software is
specialized on a specific service or protocol and
does a lot of content inspection Forced
(out-of-band) authentication and transparent
proxying are other tasks.
Mail Proxy
http Proxy
Application Gateway on dual homed host
Internal network
An Application Gateway truly separates internal
from external network a classic example of
default is deny. For every service that should
be provided a separate proxy component
specialized for the service is required. A very
common proxy e.g. is SQUID for http proxying.
Save ftp-services etc. are all provided by proxy
servers which need not really run on the
Application Gateway. The Gateway is a very
interesting target for DOS attacks and break-ins.
Additional measures should be taken to reduce the
risk of having this bastion compromised. (see DMZ
Web Application Firewall (WAF)
  • Keep state on application protocol (e.g. remember
    hidden fields)
  • Allow fine-grained control and filtering on
    application level
  • Configurable/programmable for many applictions.
    Might need training.
  • Requires no application changes
  • can suppress javascript pieces, error messages
    from apps
  • Filters Web-services and XML protocols

For the features see the excellent study and
evaluation by Sebastion Roth on this topic (2nd
Security Day at HDM). The WAF can be your last
resort if your old web-application shows
vulnerabilities (see so you are famous now
Firewall Proxy helper software
  • FWTK toolkit with lots of proxies
  • SQUID, a http proxy (open source) and distributed
    cache architecture.

An application gateway depends on its proxy
software. Some very good packages exist which
provide proxies for most services (ftp, telnet
etc.) The Firewall Toolkit is well known for its
functionality. See the BSI firewall study for
information on commercial proxy packages.
Pros and Cons of Application Gateways
  • Excellent logging due to protocol or service
  • user authentication/ authorization possible
  • Transparent operation possible
  • True network separation
  • Caching (e.g. SQUID for http)
  • intelligent filtering
  • Possible performance bottleneck (see BSI study
    for numbers)
  • Always special software proxies required
  • An interesting target for attackers

Again, the BSI study makes it pretty clear that
proxy based filtering is the way to go for larger
installations and that performance is still a
problem but not a killer. See Zwicky for
more information on proxies. If you want to
provide web services, so called reverse proxies
are an important means for central authentication
and authorization
Firewalls and end-to-end encryption
VPN tunnel
Internal network
Partner network
Encrypted end-to-end connections like Virtual
Private Networks basically disable the firewalls
function of a choke point or policy enforcement
point It cannot filter because it is not able to
inspect the packages. This is one of the
disadvantages of VPNs, besides connecting whole
networks. The section on distributed firewalls
shows alternatives to this approach. Another
alternative is the use of a SCIP proxy (see
services lecture later)
Firewall Requirements
external network
Correct firewall rules implementing security
hardened OS
no bypass
The correct implementation of a security policy
(who can connect to whom via which protocol etc.)
is a core requirement. Others are that the
firewall cannot be bypassed (which means it is
either close to the resources it needs to protect
or that the resources have no connections that go
around the firewall) and that is can resist
attacks (tamper proof) which is usually achieved
by running the firewall on trusted computing
Firewall Systemic Problems (1)
  • Security Policy
  • do not allow incoming
  • connections

buddy of internal user or a host the internal
user was tricked into contacting (trojan horse)
internal network
Attacks from inside a firewall assumes an
asymmetric trust relation the outside is BAD.
Preventing connections from outside can easily
be circumvented e.g p2p proxy servers connect 2
machines, each of them behind a firewall. Or
check the firewall-piercing HOWTO.
Firewall/NAT Systemic Problems (2)
  • Protocols like SIP use internal addresses within
    protocol data (to, from, route). Application
    that use dynamic port numbers cannot get its data
    streams through firewalls deploying
    default-deny filtering policy unless the
    firewalls understand the application.
  • If the firewalls deploy address translation the
    application cannot signal the end addresses
    unless told translation association by firewall.
    (Jirji Kuthan, GMD Focus). Kuthan proposes
    interaction between firewalls and applications.
    ALGs are not a general solution because
    encryption e.g. makes them useless.

Firewall Control Protocol
This picture has been taken from the SIP tutorial
(GMD Focus, see resources). The purpose of FCP is
to dynamically open and close ports in the
firewall and control address translation (NAT).
Firewall Types
  • 1) Network based firewalls (Perimeter firewalls,
  • - Screening Routers
  • - Application Gateways
  • - Web Application Firewalls (WAFs)
  • - Screened hosts (bastion hosts)
  • - screened subnets
  • - Demilitarized zones (DMZ)
  • 2) Host based software firewalls e.g. personal
    firewalls like zone alarm
  • 3) Network edge distributed firewalls (embedded
    control as well)

A firewall is not a piece of hardware or
software. It is a concept including network
topologies, services, hosts etc. and can consist
of many hosts playing together to perform the
policy enforcement.
Types of Network Firewalls
  • Static packet filter
  • dynamic packet filter
  • Application Gateway
  • Screened Host
  • Screened Subnet
  • DMZ with perimeter networks
  • Split DMZ with multiple perimeter networks
  • Multiple pVLAN based DMZs
  • Transparent Firewall

Screened Host
Internal network
  • Rules e.g.
  • do not allow external connection init
  • provide mail and http service through proxies

Packet Filter
mail proxy
http proxy
bastion host
A screened host runs in the internal network. It
offers proxy services to internal clíents which
cannot cónnect directly to the internet. The
screened host is protected by a packet filter.
One of the problems of screend host architectures
is that if the host is compromized, there is no
more protection for the internal network. Zwicky mention that this architecture is only
suited for networks with very strong host
security and non-critical servers running on the
screened host (e.g. no web-server).
Screened Subnet
Internal network
  • Rules e.g.
  • do not allow external connection init
  • allow direct ssh connect from inside
  • provide mail and http service through proxies

Outer Packet Filter
Inner Packet Filter
mail proxy
http proxy
bastion host
perimeter network
bastion host
A perimeter network lies between Internet and
Intranet. The important point is that the
internal network is completely separated from the
perimeter network and even if a bastion host on
the perimeter network is compromised, it cannot
snoop on the internal network. Compare this with
the screened host architecture before. The
packetfilters force all traffic through the proxy
services on the bastion host or allow selected
clients or protocols to connect directly to the
DMZ with multiple split perimeter networks
  • Rules e.g.
  • do not allow external connection init
  • do not allow direct internet connections
  • provide mail and http service through proxies

DNS server
application server
mail proxy
Outer Packet Filter
http proxy
Inner Packet Filter
bastion host (dual homed)
Internal network
Web Server
outer DMZ
inner DMZ
Server that do not need a connection to the
internal network run in the outer DMZ, still
protected by one packet filter. More critical
servers (e.g. application servers that need DB
connections to the internal net) run in the inner
DMZ. Protected by a dual homed bastion host that
cleanly separates internal from external net.
Multiple DMZ
  • Rules e.g.
  • allow external connection init for e-business
  • do not allow direct internet connections

DNS server
application server
mail proxy
Outer Packet Filter
http proxy
Inner Packet Filter
bastion host (dual homed)
Web Server
Internal network
outer DMZ
inner DMZ
Outer Packet Filter
Inner Packet Filter
bastion host
  • provide mail and http service through proxies
  • allow direct outgoing connections for some

This design separates incoming service requests
from outgoing connections. Filter rules are
easier if separation of functions can be achieved.
Firewall scalability problems (1)
  • Rules e.g.
  • do not allow external connection init
  • do not allow internl connections to external port

Packet Filter
Internal network
The larger the internal network becomes, the more
requests for open ports and services the firewall
team will receive. This can turn a packet filter
into a kind of swiss cheese with more holes than
protection left. This is turn is a consequence of
the firewall being a choke point that controls
access for a whole network.
Firewall scalability problems (2)
  • Rules e.g.
  • do not allow external connection init
  • do not allow direct internet connections
  • provide mail and http service through proxies

DNS server
application server
mail proxy
Outer Packet Filter
http proxy
Inner Packet Filter
more and more holes in the inner packet filter
bastion host (dual homed)
Internal network
Web Server
outer DMZ
inner DMZ
As the e-business of the company grows, more and
more services are installed in the inner DMZ.
This will require that the inner packet filter
lets more and more protocols pass through because
the services need them (DB connections, internal
host access etc.). Another bad side-effect is
that the likelihood of one of the services being
compromised increases and that this compromised
service in turn does snooping on the other
services in the inner DMZ.
Using private VLANs to isolate hosts
private vlan
private vlan
inter-cell call
programmable switch
firewall (rules)
Based on private virtual lans, intelligent
switches and network security cells a large scale
firewall is designed to fit an international
company. The vlan becomes private by routing
all requests through the firewall cell internal
ones as well as cross cell requests. Several
firewalls have been collapsed into one to ensure
rule consistency. Critics note that the
complexity of the programmable switch is a new
risk in itself. If the highly complex switch is
compromised, most of the security is gone. (see
articles on for examples).
There is no free lunch with firewalls.
The problems of network firewalls
New protocols (multi-port, dynamic) require more
and more holes in the firewall More and more
machines in the DMZ and Intranet also mean more
and more holes in the firewall. The machines are
effectively unprotected from each other. The
protected machines need to TRUST the firewall and
that it is not compromised Support for mobile
users is weak (bound to network segments) VPNs
tunnel perimeter firewalls without being checked.
They can connect networks. (should they?)
Attacks against network firewalls
inner DMZ
outer DMZ
mail server
appl. server
Server hopping attack
Distributed DOS attack
data sniffing attack
DNS server
TCP Stack DOS attack
SNMP or remote admin attack
datacenter lan
Intranet break in
proxy server attack
The firewall complex itself can be attacked in
various ways against high-volume distributed DOS
attacks only filtering at the ISP can help.
Broken TCP packets should not crash routers.
Routers need to fail securely. Remote admin
interfaces need to use strong authentication.
Private vlans isolate servers in inner and outer
DMZ from each other. Proxies running on
application gateways need to be stable and
backdoor-free. They should be able to run in
transparent mode (invisible). Switches need to
prevent data sniffing in the innter DMZ (which
deals with confidential data already and has
connections to the intranet). Masquerading hide
internal network structures.
Transparent Firewalls
DB clients
linux box with bridge support and netfilter
filtering enabled
DB Server
the transparent firewall has NO IP address
visible to clients
A bridge works on OSI layer 2 and connects
different parts of ONE network. It does NOT
provide routing. Clients of a DB server believe
that the server is in the same network and use
direct mac address based addresses. The bridging
firewall listens to all packets like a switch and
knows how to forward packets from the left side
to the right. But it also inspects each packet
and uses the netfilter (iptables) framework to
filter ip based protocols as well. The lack of an
IP address makes the firewall itself resistent
against IP based attacks how could somebody
attack a box without an IP address? In other
words network connections do not terminate at a
transparent firewall. The DB server can be in a
different network as well. In this case the
firewall would perform the necessary arp
responses to make clients believe that the DB
server belongs to their network. Loadbalancers
can use similiar technologies.
Personal Firewalls
Dial-up or ADSL connection
check for viruses, service requests, cookies,
backdoor use, run unknown code in sandboxes
They need to protect data AND function of a PC
currently trojans that dial very exensive 190
numbers seem to be a threat to private users. How
does a personal firewall protect the dialing
software if it runs on an insecure OS? Management
is done by users which often do not have the
knowledge to configure the firewall properly
(e.g. disable important filters) while the basic
categories of low/medium/high protection is too
coarse grained.
The problems of personal firewalls
  • They rely on the operating system for their own
  • Unwitting) Users can disable their functions
  • Malicious code can disable their function
  • Management in different networks for mobile
    users (when should the firewall block a
    non-routeable number? If the PC is
    using a dial-up connection directly then yes, if
    the PC is running inside the company network
    (docked) it should not, otherwise e.g. Windows
    domain services do not work.

Host based software firewalls who protects whom?
Personal Firewall
The PF needs the OS to run
The PF tries to protect the OS
Operating System
This is a circular relation. An OS without
separation of users, access control and proper
authentication cannot protect the functions of a
personal firewall component. The PF on the other
hand cannot upgrade a vulnerable OS into a
trusted computing base. Personal firewalls have
been easy to compromise in the past.
Personal Firewall Architecture
PF GUI module
Remote Control daemon
user mode
PF data about known problems, configurations etc.
Management module (logging, tracking,
notifications etc.)
Sandbox running unsafe application
OS kernel
Security enhancements
Network stack and device drivers
A personal firewall tries to block dangerous
requests or connections, controls the system
configuration and possibly provides a sandbox
security environment. To achieve this both user
mode and kernel mode code is added to the system.
Some of the tasks are purely related to
configuration and cannot be handled by the OS
itself because it is a general purpose piece of
software. Other security changes should probably
be provided by the OS in the first place. Note
the many interfaces between firewall and OS! (see
N.Pohlmann at
Attacks against personal firewalls
The trojan horse disables PF but makes it look
like PF is still working
The trojan horse connects to some server and
loads a remote control program (subseven,
user downloads trojan horse and runs it.
The unwitting user together with very weak
personal operating system security make these
attacks possible. To understand the importance of
operating system security see The Inevitability
of Failure The flawed assumptions of security in
modern computing environments (P.Loscocco,
D.Smalley NSA)
Managed personal firewalls
PF Manager
Centralized management of distributed personal
firewalls inside the company. (see Haffner, Managing Distributed Personal Firewalls
with Smart Data Servers). The individual PCs can
move freely on the intranet. This solution solves
the management problem associated with personal
firewalls users cannot configure them properly
and companies do not want to rely on individual
configurations anyway. An important question is
is there a trust relationship between the
personal firewall component and the user(s) of
those machines? Or are they tamper proof against
hostile users?
Host based firewalls
Rules could be much simpler with additional host
based firewalls
DNS server
application server
mail proxy
Outer Packet Filter
http proxy
Inner Packet Filter
bastion host (dual homed)
Internal network
Web Server
outer DMZ
inner DMZ
Within a DMZ the security provided by the bastion
host and routers does not scale the more hosts
the more chance of compromise is given. One way
to improve isolation is using advanced
switches/firewall combinations. Another would be
to add software firewalls to all hosts in a DMZ
which can provide a fine grained control of
connections. This solution is circular like the
personal firewall as well but since the OS on
those hosts is usually much more trustworthy than
on a PC it may work. Still, a hostile user with
root privileges could theoretically disable the
host based firewall.
Host Based Firewalls Advantages
  • Topology independence no assumptions about
    friend vs. enemy borders.
  • Good support for mobile users.
  • Performance Filtering and protection happens
    locally per host and not centralized.
  • Availability Perimeter firewalls need to be
    highly available because ALL hosts depend on
    them. If a host based firewall goes down in most
    cases its host goes with it.
  • Verification Host based firewalls only protect
    one host. This means the rules can be much
    simpler and easier to verify.
  • Cost Large scale centralized firewalls are very
    expensive due to their high-availability

Host based firewalls can work in conjunction with
perimeter firewalls. See Martin Englund,
Securing Systems with Host-based Firwalls (Sun
Distributed network edge firewalls
Rules could be much simpler with additional host
based firewalls
DNS server
application server
mail proxy
Outer Packet Filter
http proxy
Inner Packet Filter
bastion host (dual homed)
Internal network
Web Server
outer DMZ
inner DMZ
Host based firewalls always depend on the host
security and to some degree on user behavior. By
implanting the firewall into the NIC and
providing a tamper resistant package with regular
tracking, a simple and extremely reliable
filtering mechanism could be built.
Representatives of this approach say that host
based firewalls are going too far and that
firewalls should stop at the edge, e.g. the
network interface card to be tamper resistant.
(see the paper about Security at the network
edge under resources)
Shared servers
company A
company B
Shared server A -WEB -mail -SQL
Shared server B -WEB -mail -SQL
internal lan
internal lan
Both internal NICs (AI, BI) are configured to
block all traffic from the shared servers to the
internal lans. The shared servers cannot sniff on
the internal lans. Web, mail and sql traffic is
allowed through if it originates in the internal
lans. A VPN runs between both external NICs and
all other connections are blocked. This allows
both companies to share information without
opening their networks to each other. (from
Secure Computing, Security at the network edge)
Simple verification of firewalls
linux home firewall
DSL connection
Modem connection
run tcpdump or pppdump
new IP address
check for internal holes in the firewall
run nmap against own firewall from outside
Tools like nmap ( ) can be used
to scan your firewall for potential holes. Proof
of correctnes of highly complex firewall rules is
not yet automated.
Advanced verification of firewalls
Monitoring (dimstat)
web server
mail server
load generators
load generators
Picture of the test environment from BSI Firewall
Study II. Categories of verification are
Administration (roles, authentication, remote
control), Auditing (separation from
administration, remote), Filtering (packet
filter, proxies), Logging (separate network)
Behavior (fail save, users, integrity),
Interfaces (IDS, VPN, Virus Scanners), Clustering
and High-Availibility. From BSI Firewall Study II
The limits
Victim Host
Application Protocol and connection
connection tracking plus application protocol
insert syscalls into app.protocol
An attacker plants a small proxy via a buffer
overflow into a running application with
established connection. Now the attacker sends
small operating system calls inside regular
application protocol calls to the proxy (Zecke)
which sends them to OS and returns results. No
new connection is needed and the statefule
firewall which even inspects the application
protocol will find nothing unusual as the zecke
calls are within the data portions of the
application protocol. The attack code is not
fully downloaded to the victims which makes
detection very hard (also for IDS). See Tobis
Klein, resources
Resources (1)
  • Elizabeth D. Zwicky, Simon Cooper, Brent Chapman
    Building Internet Firewalls (also available in
    German this book covers most types of firewalls
    and also discusses services, protocols and
    middleware. Use the first part as a general
    introduction and the rest as a dictionary if
    users request certain services.)
  • Bundesamt für Sicherheit in der
    Informationstechnik. Conducted a well known
    firewall study in 1997 AND 2001 which is
    available for free in english and german! Go get
    it! http//
    l/fw01eng/fwstuden.htm They also ship a CD with
    basic security hints for home-users.
  • (bugtraq vulnerability DB)
  • , excellent white papers
    on all aspects of security (not just firewalls)

Resources (2)
  • , the source for linux-HOWTOs,
    excellent articles on linux security, firewalls,
    masquerading, dsl, ipchains/iptables, firewall
    piercing etc.
  • Know your enemy, a forensic analysis. Lance
    Spitzner, http//
    Must read! Other very good papers from Lance
  • http//
    olicy.pdf What firewalls can do.
  • Matt Curtin, Marcus Ranum, Firewall FAQ
  • Common TCP/IP and services weaknesses
    http// ,
    Stephen McGibbon.

Resources (3)
  • Help to interpret firewall logs or personal
    firewall messages http//
  • Use tcp-wrappers correctly http//www.bhodisoft.c
  • How to secure a windows 2000 system
    http// (9
    MB - no this is NOT a unix kernel for w2k)
  • Architecture and Applications for a Distributed
    Embedded Firewall http//
  • Security at the network edge a distributed
    firewall architecture http//www.securecomputing.
    com/pdf/dist_firewall_arch.pdf PLEASE READ TILL
    NEXT TIME! (12 pages)
  • Norbert Pohlmann, Firewall Systeme,
    http// explains
    threats (in german!). Good book btw. Available in
    english and german
  • More to firewalls http//

Resources (4)
  • Personal Firewalls, one more step towards
    comprehensive security, by Norbert Pohlmann
    1/article/021/article.html , an overview of
    personal firewall architecture
  • Rolf Spenneberg, Transparente Firewalls mit
    Linux IX Magazine Nov.2003, pg. Describes the
    concept of an inline firewall which works like a
    bridge but does additional packet filtering. The
    firewall itself has NO ip address and is
    therefore not susceptible to ip based attacks.
  • Session Initiation Protocol (SIP)
  • SIP Tutorial from GMD focus http//
    sip/siptutorial.pdf An excellent resource on SIP
  • Firwall Control Protocol proposal from Jirji
    Kuthan http//
  • Linux Magazin 04/05 page 6 Zecke from Tobias
    Klein. A syscall proxy which uses an existing
    application protocol to transport syscalls from
    the attacker to the victim and routes results
    back. Stateful inspection and application level
    tracking do not help as the same connection and
    established protocol are used
Write a Comment
User Comments (0)