Lecture on Advanced Internet Security Firewalls: Types

Lecture on Advanced Internet Security Firewalls: Types and Architectures 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 2004 W1 Internet Information Services (IIS) W1 Web Servers & Services W2 Microsoft Data Access Components (MDAC) -- Remote Data Services W2 Workstation Service 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 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 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?

Top Ten Unix Vulnerabilities 2002 2004 U1 Remote Procedure Calls (RPC) U1 BIND Domain Name System U2 Apache Web Server U2 Web Server U3 Secure Shell (SSH) U3 Authentication U4 Simple Network Management Protoc ol (SNMP) U4 Version Control Systems U5 File Transfer Protocol (FTP) U5 Mail Transport Service U6 R-Services -- Trust Relationships U6 Simple Network Management Protocol (SNMP) U7 Line Printer Daemon (LPD) U7 Open Secure Sockets Layer (SSL) U8 Sendmail U8 Misconfiguration of Enterprise Services NIS/NFS U9 BIND/DNS U9 Databases U10 General Unix Authentication -- Accounts with No Passwords or Weak Passwords U10 Kernel 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.

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 Phishing H3. 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://www.sans.org/top20/?portal 485775ea765a22161a865ce32fcfc20e

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

Current Trends -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 See http://www.sans.org/top-cyber-security-risks/trends.php

The purpose of a firewall Security Policy: -HTTP client -ftp client etc. Firewall „black-hats“ „white-hats“ 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 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 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 Firewall unsuspecting users (viruses) „white-hats“ 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 -Can read all traffic from 192.168.1.2 192.168.1.2 -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 192.168.1.2 192.168.1.3 sourceaddr: 192.168.1.2 destaddr: 192.168.1.3 192.168.1.2 replies can create a DOS attack on target host 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).

Idlescan attacks Scanning host sends regular messages to idle host and checks IP ID count. Scanning host sends spoofed packages to victim host. sourceaddr: idle host destaddr: victim host Scanning host sees jumps in IP ID counts depending on port status on victim host victim idle 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: C‘t 23/2003 or www.insecure.org/nmap/idlescan.html

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 connection init allows DOS attacks (SynFloods) TCP sequence number generation should be random. Many implementations are predictable and allow session takeover 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 SYN server Client info stored SYN,ACK(SYN) SYN (instead of request) Client info stored Client info stored . Client never sends request, only SYN, Server buffer gets filled and other clients cannot connect

TCP Probing client SYN server Client info stored SYN,ACK(SYN) 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 Spoofer now knows OS specifics of server and uses public services to learn about the CURRENT TCP Sequence number ICMP probing Some public service initiation to learn seq. nr. 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. 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) SYN server (allows connection requests from spoofed IP address) New server sequence number generated Spoofer cannot see request but guesses sequence nr. from past experience Spoofer: Request Seq.Nr. 668 SYN,ACK(SYN) Seq.Nr. 667 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 „Don‘t fragment“ are the most useful ICMP messages. Most others should be disabled because they are used for network scanning.

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) external network address TCP Header Parameters (e.g port and direction) ICMP Header Parameters (e.g. packet size, types) internal network address NIC1 NIC2 Firewall 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.

Well known ports Service 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 192.168.1.10 switch masquerading host (dualhomed) ISP 192.168.1.11 eth0: 192.168.1.13 eth1: w.x.y.10 w.x.y.11 192.168.1.12 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 ipaddress 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. -source/destination address -do not allow external connection init -protocol (tcp, udp, icmp) -do not allow internl connections to external port 23 -source/destination port -message type (ICMP) -size -interface -networks Packet Filter -connection direction -content of data 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 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 Rules: e.g. -do not allow external connection init -do not allow internl connections to external port 23 in addition to static filters: - history of connections and packets packet packet state packet state state Packet Filter 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“ virus/trojan illegal URL Firewall 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. Mail Server -do not allow user X to use http -run mail server proxy 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 NIC 1 NIC 0 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 later)

Web Application Firewall (WAF) 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 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)

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 VPN tunnel Partner network Internal 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 policy hardened OS no bypass Resource Firewall 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 Systemic Problems (1) Security Policy: -do not allow incoming connections Firewall 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 ‘defaultdeny’ 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 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 Rules: e.g. Internal network -do not allow external connection init -provide mail and http service through proxies Internet 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 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 webserver).

Rules: e.g. Screened Subnet -do not allow external connection init Internal network -allow direct ssh connect from inside -provide mail and http service through proxies Outer Packet Filter mail proxy http proxy bastion host Inner Packet Filter 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 Internet.

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 Outer Packet Filter mail proxy application server http proxy Inner Packet Filter bastion host (dual homed) Web Server outer DMZ Internal network 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 services -do not allow direct internet connections DNS server Outer Packet Filter mail proxy application server http proxy Inner Packet Filter bastion host (dual homed) Web Server Internal network outer DMZ Outer Packet Filter inner DMZ bastion host Inner Packet Filter -provide mail and http service through proxies -allow direct outgoing connections for some services 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 23 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 Outer Packet Filter mail proxy application server http proxy Inner Packet Filter bastion host (dual homed) Web Server outer DMZ more and more holes in the inner packet filter Internal network 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 Host Host private vlan Host Host Host 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 ecommerceonline.com 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 outer DMZ Server hopping attack Distributed DOS attack ISP inner DMZ mail server DNS server TCP Stack DOS attack SNMP or remote admin attack appl. server data sniffing attack datacenter lan proxy server attack Intranet break in 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.

DB clients Transparent Firewalls 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 Home ISP/Internet PF 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 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 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 Remote Control daemon PF GUI module user mode Application Sandbox running unsafe application OS kernel Management module (logging, tracking, notifications etc.) PF data about known problems, configurations etc. 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 www.scmagazine.com)

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

Managed personal firewalls PF Manager PF PF PF 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?

Host based firewalls Rules: could be much simpler with additional host based firewalls DNS server Outer Packet Filter mail proxy application server http proxy Inner Packet Filter bastion host (dual homed) Web Server outer DMZ Internal network 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 highavailability 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 Rules: could be much simpler with additional host based firewalls DNS server Outer Packet Filter mail proxy application server http proxy Inner Packet Filter bastion host (dual homed) Web Server outer DMZ Internal network 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 internal lan NIC AI Shared server A -WEB -mail -SQL company B NIC AE VPN INTERNET NIC BE Shared server B -WEB -mail -SQL internal lan NIC BI 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 192.168.1.10 ISP DSL connection Modem connection 1 192.168.1.11 check for internal holes in the firewall run tcpdump or pppdump 2 new IP address run nmap against own firewall from outside 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.

Advanced verification of firewalls mail server web server Monitoring (dimstat) firewall 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 Attacker Application Protocol and connection sc Application Zecke Firewall insert syscalls into app.protocol connection tracking plus application protocol inspection syscalls OS 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.) 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.ht m 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.ht ml , 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