Advanced Internet Security

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

2. Roadmap • Part 2: Filtering Technology • IP, TCP, ICMP filtering • static filtering: ipchains • dynamic (stateful) filtering: iptables • Application level filtering: proxies • Filtering limits, WAFs Part 1: Firewall Architecture • The purpose of a firewall • IP components important for firewalls • Firewall Types • Firewall limits • 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.

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

4. 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 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?

5. 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 NIS/NFS • U9 Databases • 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.

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

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

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

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

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

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

12. 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 simplyjumping 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. Atypical 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.

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

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

15. Security aspects of IP 192.168.1.2 • Can read all traffic from 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!

16. Three ways of spoofing Spoofing host pretending to be 192.168.1.2 sourceaddr: 192.168.1.2 destaddr: 192.168.1.3 192.168.1.2 192.168.1.3 replies can create a DOS attack on target host • Spoofer can read replies: hijacking attack • Spoofer doesn’t 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 192.168.1.2, executed by first victim 192.168.1.3 (e.g echo-reply attack) • (from Zwicky, Cooper, Chapman pg.98ff).

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

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

19. TCP SYN Flooding: Denial-of-Service client server SYN 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

20. TCP Probing client server SYN 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

21. TCP Sequence number guessing (1) server 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)

22. TCP Sequence number guessing (2) client (Spoofer) server (allows connection requests from spoofed IP address) SYN 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.

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

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

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

26. 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) Firewall internal network address external network address NIC1 NIC2 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.

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

28. Network Address Translation masquerading host (dual-homed) ISP 192.168.1.10 switch 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 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.

29. Static Packet Filter (screening router) • Rules: e.g. • do not allow external connection init • do not allow internl connections to external port 23 • 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.

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

31. Dynamic Packet Filter • Rules: e.g. • do not allow external connection init • do not allow internl connections to external port 23 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.

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

33. 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. NIC 1 NIC 0 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 later)

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

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

36. 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 Pros and Cons of Application Gateways 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

37. Firewalls and end-to-end encryption Firewall 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)

38. Firewall Requirements external network Correct firewall rules implementing security policy hardened OS Resource Firewall 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 bases.

39. 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“.

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

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

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

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

44. Screened Host Internal network • Rules: e.g. • do not allow external connection init • provide mail and http service through proxies Packet Filter Internet 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 web-server).

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

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

47. Rules: e.g. • allow external connection init for e-business services • do not allow direct internet connections Multiple DMZ 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 services This design separates incoming service requests from outgoing connections. Filter rules are easier if separation of functions can be achieved.

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

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

50. Using private VLANs to isolate hosts private vlan private vlan Host Host 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.