Advanced Internet Security Firewalls: Types and Architectures Lecture on Walter Kriha

Advanced Internet Security

Firewalls: Types and Architectures

Lecture on

Walter Kriha

Roadmap

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

See www.sans.org 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 www.jeffsutherland.org). Against which vulnerabilities could a firewall help?

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

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

See www.sans.org/top20 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 sans.org 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.

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 NIS/NFS

•U9 Databases

•U10 Kernel

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

SANS top 20 of 2007

See: http://www.sans.org/top20/?portal=485775ea765a22161a865ce32fcfc20e

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

Top Trends 2008

See www.sans.org/top20 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 sans.org 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.

-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 focus

-Embedded control security getting critical (cars, homes)

-A huge security industrie has established itself – this could be considered a problem in itself. Security of applications cannot be an “add-on”.

Current Trends

See http://www.sans.org/top-cyber-security-risks/trends.php

-OS Security constantly better than application security. Shorter patch times too

- Rising attacks on mobile/smart devices and embedded control systems

- Alternative platforms (apple, linux) now becoming targets as well

- Specially crafted zero-day attack code (stuxxnet etc.)

- Web Application Security is still bad (input validation problems, old web-applications) and shows a constant rate of vulnerabilities (unlike OS)

- Questionable activities of security companies

- Attacks on the mind (phishing, pharming, social networks)

- Password guessing still very effective

The purpose of a firewall

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.

Firewall

Security Policy:-HTTP client-ftp client etc.

„black-hats“ „white-hats“

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 logged

• Force authentication through proxies

Not all firewall types support everything, e.g. static packet filters usually do not authenticate.

Software Architecture, Security and Network Topology

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 analysisOne 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?

Firewall

Security Policy:-HTTP client-ftp client etc.

„white-hats“

insecure operating systems

dangerous services and misconfigured software

unsuspecting users (viruses)

bad tcp/ip implementations that crash easily (DOS)

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 ISP.

• 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

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!

192.168.1.2-Can read all traffic from 192.168.1.2

-Can pretend to be any host

Three ways of spoofing

a) Spoofer can read replies: hijacking attack

b) Spoofer doesn’t need the reply: DOS attack or remote copy of a new passwd or .rhosts file to target using TCP sequence guessing

c) Spoofer tries DOS attack at host 192.168.1.2, executed by first victim 192.168.1.3 (e.g echo-reply attack)

(from Zwicky, Cooper, Chapman pg.98ff).

192.168.1.2

Spoofing host pretending to be 192.168.1.2

192.168.1.3 sourceaddr: 192.168.1.2 destaddr: 192.168.1.3

replies can create a DOS attack on target host

Idlescan attacks

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: C‘t 23/2003 or www.insecure.org/nmap/idlescan.html

victim

Scanning host sends regular messages to idle host and checks IP ID count.

idle

sourceaddr: idle host

destaddr: victim host

victim host replies to spoofed packages to idle host. The replies different if ports on the victim host are open or closed.

Scanning host sends spoofed packages to victim host.

Scanning host sees jumps in IP ID counts depending on port status on victim host

Security aspects of TCP

While providing a reliable connection TCP has a number of security weaknesses. Many stacks are also not stable and will crash under attack.

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 (Syn-Floods)

TCP SYN Flooding: Denial-of-Service

client server

Client info stored

SYN

SYN,ACK(SYN)

SYN (instead of request)

Client never sends request, only SYN, Server buffer gets filled and other clients cannot connect

Client info stored

...

Client info stored

TCP Probing

client server

Client info stored

SYN

SYN,ACK(SYN)

RESET (cancel connection initiation)

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

Client info deleted,

initiation NOT logged

TCP Sequence number guessing (1)

client (Spoofer), using its REAL IP address

server

generates response which possibly tells spoofer which operating system type and version is used. This will tell client which sequence nr. algorithm is used.Some public service initiation to

learn seq. nr.

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)

Spoofer now knows OS specifics of server and uses public services to learn about the CURRENT TCP Sequence number

ICMP probing

server Sequence Number returned

TCP Sequence number guessing (2)

client (Spoofer)

server (allows connection requests from spoofed IP address)

New server sequence number generated

SYN

SYN,ACK(SYN) Seq.Nr. 667

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.

Server accepts and performs request

Spoofer: Request Seq.Nr. 668

Spoofer cannot see request but guesses sequence nr. from past experience

Security aspects of ICMP

„Fragmentation needed“ and „Don‘t fragment“ are the most useful ICMP messages. Most others should be disabled because they are used for network scanning.

-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

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?

Firewall

external network address internal network address

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)

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 protection.

NIC1 NIC2

Well known portsService Port Protocol

echo 7 UDP/TCP

ftp-data port 20 TCP

ftp control port 21 TCP

telnet 23 TCP

smtp 25 TCP

dns 53 UDP

finger 79 TCP

http 80 TCP

nntp 119 TCP

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

switch

masquerading host (dual-homed)

eth1: w.x.y.10

eth0: 192.168.1.13

192.168.1.10

192.168.1.11

192.168.1.12

w.x.y.11

ISP

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)

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.

Packet Filter

Internal network

-source/destination address

-protocol (tcp, udp, icmp)

-source/destination port

-message type (ICMP)

-size

-interface

-networks

-connection direction

-content of data

Rules: e.g.

-do not allow external connection init

-do not allow internl connections to external port 23

Problematic Protocols

• connectionless (UDP)

• multi-port (e.g. one well-know and one random port)

• 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

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.

Packet Filter

Internal network

in addition to static filters:

- history of connections and packets

Rules: e.g.



packetstatepacket

statepacketstate

content level filtering

„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

Firewall

Security Policy:-all downloads filtered for malicious code-all pages checked for explicit language

-certain URLs are „verboten“

internal network

connection to pornographic site

virus/trojanillegal URL

Application Gateway (Proxy)

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 later)

NIC0

Internal network

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.

Rules: e.g.

-do not allow user X to use http

-run mail server proxy

Application Gateway on dual homed host

NIC1

MailProxy

httpProxy

MailServer

Web Application Firewall (WAF)

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… www.kriha.de/krihaorg/blog5.html#i72)

WAF Web-Application

-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

Firewall Proxy helper software

• FWTK: toolkit with lots of proxies• SOCKS• 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 knowledge

• 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 et.al. 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

Firewall

Internal network

Partner network

VPN tunnel

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

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 bases.

Firewall

Resource

Correct firewall rulesimplementing security policy

hardened OS no bypass

external network

Firewall Systemic Problems (1)

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

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

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, intrawalls)- 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 alarm3) 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

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 et.al. 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).

Internal networkRules: e.g.


-provide mail and http service through proxies

mail proxyhttp

proxy

bastion host

Packet Filter

Internet

Screened Subnet

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 Internet.

Outer Packet Filter

Internal network

Rules: e.g.


-allow direct ssh connect from inside


mail proxyhttp

proxy

bastion host

InnerPacket Filter

perimeter

network

bastion host

DMZ with multiple split perimeter networks

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.

Outer Packet Filter

Internal network

Rules: e.g.


-do not allow direct internet connections


mail proxy

httpproxy

InnerPacket Filter

outer DMZ

bastion host (dual homed)

inner DMZ

DNS server application server

Web Server

Multiple DMZ

This design separates incoming service requests from outgoing connections. Filter rules are easier if separation of functions can be achieved.

Outer Packet Filter

Internal network

Rules: e.g.

-allow external connection init for e-business services


mail proxy

httpproxy

InnerPacket Filter

outer DMZ


inner DMZ


Web Server

Outer Packet Filter

InnerPacket Filter

bastion host


-allow direct outgoing connections for some services

Firewall scalability problems (1)

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.

Packet Filter

Internal network

Rules: e.g.



Firewall scalability problems (2)

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.

Outer Packet Filter

Internal network

Rules: e.g.




mail proxy

httpproxy

InnerPacket Filter

outer DMZ


inner DMZ


Web Server

more and more holes in the inner packet filter

Using private VLANs to isolate hosts

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 ecommerceonline.com for examples). There is no free lunch with firewalls.

firewall (rules)

programmable switch

Host Host Host Host Host

private vlan

inter-cell call

private vlan

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 firewallsinner DMZ

outer DMZ

mail server

DNS server

appl. server

datacenter lan

ISP

Distributed DOS attack

TCP Stack DOS attack

Intranet break inproxy server attack

Server hopping attack

SNMP or remote admin attack

data sniffing 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

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.

DB Server

DB clients

linux box with bridge support and netfilter filtering enabled

the transparent firewall has NO IP address visible to clients

Personal Firewalls

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.

ISP/InternetHome

Dial-up or ADSL connection

check for viruses, service requests, cookies, backdoor use, run unknown code in sandboxes

PF

The problems of personal firewalls

• They rely on the operating system for their own protection

• Unwitting) Users can disable their functions easily

• Malicious code can disable their function

• Management in different networks for mobile users (when should the firewall block a non-routeable 192.168.0.0/16 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

Operating System

The PF tries to protect the OS

The PF needs the OS to run

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 data aboutknown problems,configurations

etc.

PF GUI module

Security enhancements

ApplicationManagement module(logging, tracking, notifications etc.)

RemoteControldaemon

Network stack and device drivers

Sandbox running unsafe application

user mode

OS kernel

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 www.scmagazine.com)

Attacks against personal firewalls

user downloads trojan horse and runs it.

PF

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, backorifice)

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 et.al. NSA)

Managed personal firewalls

Centralized management of distributed personal firewalls inside the company. (see Haffner et.al., 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?

PF Manager

PF PF

PF

Host based firewalls

Outer Packet Filter

Internal network

Rules: could be much simpler with additional host based firewalls

mail proxy

httpproxy

InnerPacket Filter

outer DMZ


inner DMZ


Web Server

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 requirements

Host based firewalls can work in conjunction with perimeter firewalls. See: Martin Englund, Securing Systems with Host-based Firwalls (Sun Blueprint)

Distributed network edge firewalls

Outer Packet Filter

Internal network

Rules: could be much simpler with additional host based firewalls

mail proxy

httpproxy

InnerPacket Filter

outer DMZ


inner DMZ


Web Server

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

Shared serverA

-WEB-mail-SQL

Shared serverB

-WEB-mail-SQL

NICAE

NICBE

NICAI

NICBI

VPN

INTERNET

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)

internal lan internal lan

company A company B

Simple verification of firewalls

Tools like nmap (www.insecure.org ) can be used to scan your firewall for potential holes. Proof of correctnes of highly complex firewall rules is not yet automated.

linux home firewall

run tcpdump or pppdump

192.168.1.10

192.168.1.11

ISP

check for internal holes in the firewall

DSL connection

new IP address

run nmap against own firewall from outside

Modem connection

12

Advanced verification of firewalls

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

Monitoring (dimstat)web servermail server

load generators load generators

firewall

The limits

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

Application Protocol and connection

connection tracking plus application protocol inspection

Victim Host

insert syscalls into app.protocol

Attacker

syscalls

Application

OS

Zecke

Firewall

sc

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.)

• www.bsi.de 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://www.bsi.bund.de/literat/studien/firewall/fw01eng/fwstuden.htm They also ship a CD with basic security hints for home-users.

• www.securityfocus.com (bugtraq vulnerability DB)

• www.esecurityonline.com , excellent white papers on all aspects of security (not just firewalls)

Resources (2)

• www.linuxfaq.com , 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://project.honeynet.org/papers/ Must read! Other very good papers from Lance: http://www.spitzner.net/

• http://csrc.nist.gov/isptg/pdf/06InternetFirewallPolicy.pdf What firewalls can do.

• Matt Curtin, Marcus Ranum, Firewall FAQ: http://www.faqs.org/faqs/firewalls-faq/

• Common TCP/IP and services weaknesses: http://secinf.net/info/fw/steph/tcpip.html , Stephen McGibbon.

Resources (3)

• Help to interpret firewall logs or personal firewall messages: http://www.robertgraham.com/pubs/firewall-seen.html

• Use tcp-wrappers correctly: http://www.bhodisoft.com/bswopes/nhf/ipchains-vs.-hosts.deny.html

• How to secure a windows 2000 system: http://nsa2.www.conxion.com/win2k/download.htm (9 MB - no this is NOT a unix kernel for w2k)

• Architecture and Applications for a Distributed Embedded Firewall: http://www.acsac.org/2001/papers/73.pdf

• 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://www2.mitp.de/0719/0719Kap4.pdf explains threats (in german!). Good book btw. Available in english and german

• More to firewalls: http://www.hit-forum.de/fw-links.html

Resources (4)• Personal Firewalls, one more step towards comprehensive security, by

Norbert Pohlmann http://www.scmagazine.com/scmagazine/sc-online/2001/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) http://www.ietf.org/rfc/rfc3261.txt • SIP Tutorial from GMD focus: http://www.iptel.org/sip/siptutorial.pdf An

excellent resource on SIP• Firwall Control Protocol proposal from Jirji Kuthan:

http://www.iptel.org/fcp/ietf-fcp.ppt • 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

Documents

Advanced Internet Security Firewalls: Types and Architectures Lecture on Walter Kriha