IP Cyber Security Unit 2: Firewalls. IP Cyber Security Unit 2: Firewalls.

IP Cyber Security Unit 2: Firewalls

UNIT 2: Firewalls UNIT 4: Firewalls Learning Objectives:
By the end of this chapter, you should be able to discuss: Firewalls in general (basic operation, architecture, the problem of overload). Main border firewalls using stateful inspection. Screening firewalls using static packet inspection. Network address translation (NAT). Application proxy firewalls. Antivirus filtering. Demilitarized zones (DMZs). Host firewalls. Firewall management. Hard problems for firewall filtering.

UNIT 2 Content : Firewalls in general basic operation and architecture Main border firewalls using stateful inspection Screening firewalls using static packet inspection Network addresses translation (NAT). Application proxy firewalls Antivirus filtering. Demilitarized zones (DMZs)+IDS/IPS

Security Technology (Measures or Tools)
Firewalls A system or group of systems that enforce a network access control policy Filters data packets in and out of intended target Strength relies on configuration Governs the flow of data into and out of a Local Area Network Separates a private network (LAN) from the public IP Net Will defend the following attacks: Denial of Services (DoS) Attacks Unauthorized Access Port-scanning and Probing Intrusion Detection Systems Complements firewalls to detect if internal assets are being hacked or exploited Network-based Intrusion Detection Monitors real-time network traffic for malicious activity Similar to a network sniffer Sends alarms for network traffic that meets certain attack patterns or signatures Host-based Intrusion Detection Monitors computer or server files for anomalies Sends alarms for network traffic that meets a predetermined attack signature Denial of Service (DoS) attacks Website Defacements Malicious Code and Trojans

Virus Protection Software should be installed on all network servers, as well as computers Shall include the latest versions, as well as signature files (detected viruses) Should screen all software coming into your computer or network system (files, attachments, programs, etc.) Will defend the following attacks: Viruses and Worms Malicious Code and Trojans Authentication and Authorization Authentication Comes in (3) forms: What you have, know, or are Have – Smartcard, token Know – Password or PIN Are – Fingerprint, Retina scan Two factor authentication is the strongest – (2) out of the (3) listed means (i.e. ATM card) Password (most common) Should be at least (8) mixed characters and numbers Should be changed at least every (90) days Should have a timeout of (3) attempts Authorization What an individual has access to once authenticated Unauthorized access

Encryption Protects data in transit or stored on disk The act of ciphering and enciphering data through the use of shared software keys, data cannot be accessed without the appropriate software keys Common use of encryption includes the following technologies: Virtual Private Networking (VPN): Used to secure data transfer across the IP Net Secure Sockets Layer: Used to secure client to server web-based transactions S-MIME: Used to secure transactions Wireless Equivalency Privacy (WEP) protocol: Used to secure wireless transactions Will defend the following attacks: Data sniffing and spoofing Wireless attacks

Assessment and Auditing
Assessment (Risk and Vulnerability) Process by which an organization identifies what needs to be done to achieve sufficient security Involves identifying and analyzing threats, vulnerabilities, attacks, and corrective actions Key driver in the Information Security process Should be conducted by a third-party Include manual and automated (vulnerability scanners) methods Auditing Compare the state of a network or system against a set of standards or policy Will defend the following attacks: Identify weaknesses and vulnerabilities that address all of the mentioned attacks Data and Information Backups Must have for disaster recovery and business continuity Should include daily and periodic (weekly) backups Should be stored off-site, at least (20) miles away from geographic location, and have 24X7 access Should be kept for at least (30) days while rotating stockpile Used to respond and replace information that is compromised by all the mentioned attacks

The Unprotected Network
What could possibly be wrong with this setup? Hackers paradise & administrators nightmare!

What Can We Do? Fortunately firewalls can give us very good protection against attacks from the IP Net. The only problem is that there are numerous firewall strategies. In order to choose the right strategy we need to know a bit more about the underlying communication protocol TCP/IP.

Intranets An intranet is a network that employs the same types of services, applications, and protocols present in an IP Net implementation, without involving external connectivity Intranets are typically implemented behind firewall environments.

Intranets

Extranets Extranet is usually a business-to-business intranet Controlled access to remote users via some form of authentication and encryption such as provided by a VPN Extranets employ TCP/IP protocols, along with the same standard applications and services

Type of Firewalls Firewalls fall into four broad categories Packet filters Circuit level Application level Stateful multilayer

1. Packet Filtering

A Simple Packet Filter Firewall
This must be really secure...?

Packet Filter

Two Packet Filters Is a Must

2. Circuit level Circuit level gateways work at the session layer of the OSI model, or the TCP layer of TCP/IP Monitor TCP handshaking between packets to determine whether a requested session is legitimate.

Circuit Level

3. Application Level Application level gateways, also called proxies, are similar to circuit-level gateways except that they are application specific Gateway that is configured to be a web proxy will not allow any ftp, gopher, telnet or other traffic through

Application Level

Proxy Firewall

4. Stateful Multilayer Stateful multilayer inspection firewalls combine the aspects of the other three types of firewalls They filter packets at the network layer, determine whether session packets are legitimate and evaluate contents of packets at the application layer

Stateful Multilayer

A Stateful firewall Can Do That
A stateful firewall is an advanced packet filter that keeps track of the state of the network connections going through it. Whenever a packet arraives to the stateful firewall, it checks whether it matches an ongoing connection. If a match is found the packet can pass through.

Masquerading Firewall

Stateful Inspection Takes Us Further
A stateful inspecting firewall is not limited to the network TCP/IP protocols. For known applications it looks at the application protocol as well. This enables the firewall to detect when a communication link does something out of the ordinary It also enables the firewall to filter out certain parts of the data transmitted. For the HTTP protocol it may filter out javascripts For the SMTP protocol it may filter out certain types of attachments.

General Performance

Well-Known Port Numbers
Primary Protocol Application 20 TCP FTP Data Traffic 21 FTP Supervisory Connection Passwords sent in the clear 23 Telnet Passwords sent in the clear 25 Simple Mail Transfer Protocol (SMTP)

Primary Protocol Application 53 TCP Domain Name System (DNS) 69 UDP Trivial File Transfer Protocol (TFTP) No login necessary 80 Hypertext Transfer Protocol (HTTP) 110 Post Office Protocol (POP)

Primary Protocol Application TCP NETBIOS service for peer-to-peer file sharing in older versions of Windows 143 IP Net Message Access Protocol (IMAP) for downloading to client 161 UDP Simple Network Management Protocol (SNMP) 443 HTP over SSL/TLS

Firewalls Hardened Server IP Net Firewall Allowed Legitimate Packet
Attacker IDS Legitimate Packet Hardened Client PC Internal Corporate Network Log File Legitimate Host Network Management Console

Firewall Hardened Server IP Net Firewall IDS Attack Packet Attacker
Denied Attack Packet Hardened Client PC Internal Corporate Network Log File Legitimate Host Network Management Console

Firewall Architecture (Single Site)
Main Border Firewall Internal Firewall Screening Router Firewall IP NET x Subnet Public Webserver External DNS Server Host Firewall Host Firewall 4.2. Firewall Architectures Although small firms typically have a single firewall at their border with the IP Net, major sites in large firms use multiple types of firewalls. The specific mix of firewalls that a firm selects is called its firewall architecture (see Figure 2 for typical firewall architecture at a single site). In this chapter, we will look at the most common elements of firewall architectures. The specific mix of firewalls that a firm selects is called its firewall architecture (see Figure 4-2 a,b). Most firms have multiple firewalls. Their arrangement is called the firm’s firewall architecture Most firms have multiple firewalls. Their arrangement is called the firm’s firewall architecture SMTP Application Proxy Server HTTP Application Proxy Server Marketing Client on x Subnet Accounting Server on x Subnet

Defense in Depth with Firewalls
IP Net Screening Border Router with Packet Filter Firewall Software Application Firewall , HTTP, etc. Client with Host Firewall Software Main Firewall: Stateful Inspection Firewall Site

Basic Firewall Operation
1. IP Net (Not Trusted) Attacker 2. IP Net Border Firewall 4.1. Introduction Basic Operation: Firewalls are like guard gates or military checkpoints. Figures 4-1-a,b,c,d show that a firewall examines each incoming packet. This examination process is called filtering. 1. Internal Corporate Network (Trusted)

3. Attack Packet 1. IP Net (Not Trusted) Attacker 2. Border Firewall The Basic Firewall Operation: The Basic Pass/Deny Filtering Decision The figure shows that the firewall does two things when a packet arrives. First, it makes a basic pass/deny filtering decision for each packet. If a packet is identified as an attack packet, the firewall denies (drops) the packet so that it does not enter the network. In turn, if the firewall does not identify the packet as an attack packet, the firewall passes the packet, permitting it to enter the network. The figure shows that the firewall does two things when a packet arrives. First, it makes a basic pass/deny filtering decision for each packet. If a packet is identified as an attack packet, the firewall denies (drops) the packet so that it does not enter the network. Note: Hardened Servers and Clients: Hardened Servers (i.e. Servers with latest software Operating System OS updates from the OS vendor) and Hardened Clients Provide Defense in Depth against vulnerabilities. Security updates are called Service-Packs Logging Second, the firewall also records information about each dropped packet in a log file. Every day or so, the network administrator should examine this log file to understand the ever-changing threat environment. The log will show attacks and general and can shed light on specific incidents. The log entries can also indicate if the firewall is working properly. Ingress Filtering In ingress filtering, the firewall examines packets entering the network from the outside, typically from the IP Net. The purpose of ingress filtering is to stop packets sent by outside attackers from entering the firm’s internal network. Ingress filtering is what most people think of when they hear about firewall filtering. Egress Filtering In egress filtering, in contrast, the firewall filters packets when they are leaving the internal network. In Chapter 4, we saw that when attackers scan networks, they typically send probe packets into the network. Reply packets generated in response to these probes reveal information about the network and its hosts to attackers. Egress filtering can prevent probe replies from getting back to hackers. In addition, if an internal host has been compromised by a hacker or virus, that host may send attack packets out to other hosts on the IP Net. Dropping outgoing attack packets makes the firm a good citizen, and log file entries for the dropped packets tell the firm that an internal host has been compromised. Stopping outgoing attack packets may also keep the firm from being sued by other firms that are hit by attack packets. 4. Dropped Packet (Ingress/from) 4. Log File

5. Passed Legitimate Packet (Ingress/from) 5. Legitimate Packet 1. IP Net (Not Trusted) Legitimate User 2. IP Net Border Firewall 1. Internal Corporate Network (Trusted)

7. Passed Packet (Egress/to) 1. IP Net (Not Trusted) Attacker 2. IP Net Border Firewall 7. Dropped Packet (Egress/to) 4. Log File 1. Internal Corporate Network (Trusted)

6. Attack Packet that Got Through Firewall 6. Hardened Client PC 1. IP Net (Not Trusted) Attacker 2. IP Net Border Firewall 6. Hardened Server 1. Internal Corporate Network (Trusted)

Border Firewall 1. IP Net (Not Trusted) Attacker 2. IP Net Border
4.4. Border Firewalls: During the early 1990s, firewalls were sometimes advertised as “silver bullets” that would protect corporations from all attacks. A border firewall placed between a corporate network and the IP Net would stop all attacks (Fig. 4-3 a, b, c, d, and e). To the outside world, the firm would look “hard and crunchy.” Inside, however, hosts could be left unsecured. (The internal network could be left “soft and chewy”). Leaving internal hosts unsecured would reduce security expenses dramatically. Limitations of Border Firewalls Unfortunately, border firewalls can not stop all attack packets. Imperfect Filtering: In reality, the pass/deny decisions of firewalls were never perfect. Inevitably, some attack packets always got through to victim hosts. Border firewalls never provided total protection from IP Net-based attacks. Internal Attacks: In addition, many attacks are initiated within the firm. Border firewalls sitting between the firm and the IP Net will do nothing to stop internal attacks. Bypassing the Firewall: While it would be nice to have only a single point of entry to the firm, at the IP Net border, this is impossible in practice. If attackers can compromise wireless LAN access points, their traffic will enter without going through the firewall. More simply, employees bring notebook computers, PDAs, and memory media and out of into the firm constantly. Extending the Perimeter: As discussed later in this chapter, border firewalls often do not filter the encrypted data streams of virtual private networks (VPNs). This further limits the ability of border firewalls to provide protection. Defense in Depth In response to the inability of border firewalls to stop all attacks, firms have to use defense in depth, in which they require the attacker to break through several lines of defense. As Figure 4.2 illustrates, they have internal firewalls that separate parts of the internal network. They also place host firewalls on many individual clients and servers. Firms also harden their clients and servers against attack in other ways. Enduring Role: Although the border firewall is no longer viewed as a magic bullet, it is still one of the most potent tools in a firm’s security arsenal. It stops the vast majority of attacks against the site. It simply is not a cure for all security problems. The Danger of Overload: What if a firewall is overloaded, so that it cannot examine all arriving packets? Will the firewall pass the packets it cannot examine, or will it drop them? The answer is that if a firewall becomes overloaded, it drops all packets that it cannot process. This is the safest approach, because it will not allow unchecked attack packets into the firm. However, dropping all packets during overload effectively creates a self-inflicted denial-of-service attack against the firm by dropping legitimate packets as well. It is critical for firms to purchase firewalls with sufficient processing power to handle the traffic they will have to examine. If a firewall becomes overloaded, it drops all packets it cannot filter. Even if a firewall can handle the traffic when it is purchased, it may run out of capacity later. First, traffic nearly always increases over time. Second, as new threats appear, the firewall administer must write more filtering rules, and these additional filtering rules may be more complex than earlier rules and therefore take longer to process. In addition, during denial-of-service attacks and heavy scanning attacks, traffic can increase dramatically. If a firewall cannot deal with traffic surges during major attacks, it can do more damage than it prevents. As processors become faster over time, firewalls will be able to handle more traffic. However, traffic has been increasing very rapidly in most firms, sometimes outracing the benefits of growing processor speeds. Buying firewalls that can always operate at wire speed, that is, the maximum possible speed of incoming traffic is expensive but essential. 1. Internal Corporate Network (Trusted)

Border Firewall 6. Attack Packet that Got Through Firewall 6. Hardened
Client PC 1. IP Net (Not Trusted) Attacker 2. IP Net Border Firewall Hardened Hosts Provide Defense in Depth 6. Hardened Server 1. Internal Corporate Network (Trusted)

Packet Filter RuleBase
Source Address Source Port Destination Address Destination Port Action Description Any > 1023 Allow Rule to allow return TCP Connections to internal subnet Deny Prevent Firewall system itself from directly connecting to anything Prevent External users from directly accessing the Firewall system. Internal Users can access External servers SMTP (25) Allow External Users to send in HTTP (80) Allow External Users to access WWW server "Catch-All" Rule -Everything not previously allowed is explicitly denied Any type of access from the inside to the outside is allowed. No access originating from the outside to the inside is allowed except for SMTP and HTTP. SMTP and HTTP servers are positioned “behind” the firewall.

A network of IP address , with the “0” indicating that the network has addresses that range from to The firewall would normally accept a packet and examine its source and destination addresses and ports, and determine what protocol is in use. Firewall starts at the top of the rulebase and work down through the rules – whenever it finds a rule that permits or denies the packet, it takes the appropriate action: Accept: firewall passes the packet through the firewall as requested, subject to whatever logging capabilities may or may not be in place. Deny: firewall drops the packet, without passing it through the firewall. Once the packet is dropped, an error message is returned to the source system. The “Deny” action may or may not generate log entries depending on the firewall’s rule base configuration. Discard: firewall not only drops the packet, but it does not return an error message to the source system. This particular action is used to implement the “black hole” methodology in which a firewall does not reveal its presence to an outsider. “Discard” action may or may not generate log entries.

A first rule permits return packets from external systems to return to the internal systems, thus completing the connection – it is assumed that if a connection to an external system was permitted, then the return packets from the external system should be permitted as well. The second rule prohibits the firewall from forwarding any packets with a source address from the firewall – this would indicate that an attacker is spoofing the firewall’s address, hoping that the firewall would pass this packet to an internal destination, which might then accept the packet since it would appear to have come from the trusted firewall. The third rule simply blocks external packets from directly accessing the firewall. The fourth rule allows internal systems to connect to external systems, using any external addresses and any protocol. Rules 5 and 6 allow external packets past the firewall if they contain SMTP data or HTTP data – and web, respectively. The final rule blocks any other packets from the outside.

UNIT 2 Content : Firewalls in general basic operation and architecture Main border firewalls using stateful inspection Screening firewalls using static packet inspection Network addresses translation (NAT). Application proxy firewalls Antivirus filtering. Demilitarized zones (DMZs)+IDS/IPS.

Opening Connections in Stateful Inspection Firewalls
Default Behavior Permit connections initiated by an internal host (ingress) Deny connections initiated by an external host (egress) Can change default behavior with access control lists (ACLs) for ingress and egress Automatically Accept Connection Attempt IP Net Router Automatically Deny Connection Attempt

Permitting Incoming Connections in a Stateful Inspection Firewall
Default Behavior Can be Modified by Access Control Lists (ACLs) Ingress ACL permits some externally-initiated connections to be opened Egress ACL prohibits some internally-initiated connections from being opened On basis of IP address, TCP or UDP port number, and/or IP protocol Sets of if-then rules applied in order 4.7. Access Control Lists (ACLs) for Connection Openings Although the default behavior of stateful inspection firewalls works most of the time, organizations may need to permit some externally-initiated connections and not allow some internally-initiated connections. In other words, the default behavior for connection openings may need to be superseded. Access Control Lists (ACLs) To modify the default behavior for connection openings, the firewall administer creates access control lists (ACLs). These are sets of rules. Each rule permits a specific externally-originated connection (say to a public server) or denies a specific internally-originated connection (say to prevent access to a competitor’s FTP server). Figure 4.5. illustrates stateful inspection ingress ACL. By the way, “ACL” usually is pronounced “ah.-kel,” although spelling out “a-c-l” is also common.”) If-Then Format Figure 4.5. show that ACL Rules follow an if-then format. If the packet does not match a rule, the firewall does not take action based on that rule. However, if the packet’s field values match criteria values, then we say that the packet matches the rule. Based on the “then” part of the rule, the firewall will either permit or deny the connection-opening attempt. Sequential Rule Evaluation When a packet is evaluated, it is evaluated against the rules in the ACL sequentially. The packet is first evaluated against the first rule, then against the second, and so forth. This sequential processing continues until a rule results in a pass or deny decision or until the last rule in the ACL is reached. Although sequential evaluation is simple to understand, it is very easy to make errors when creating ACLs by making slight misorderings in the rules. We will see examples of this. Well-Known Port Numbers ACL rules typically involve TCP or UDP port numbers. Servers have well-known port numbers, and these well-known port numbers designate a specific application running on the server. For example, Port 80 is the well-known port number for HTTP. To prevent access to servers, stateful firewalls by default block incoming TCP and UDP connections to well-known destination port numbers. Figure 4.6. a,b,c show some of the well-known port numbers that are frequently referred to in ACLs. Port Access and Server Access In Figure 4.5, Rule 1 permits connections if the TCP destination port number is 80 (HTTP). This permits access to all internal webservers. In turn, Rule 2 permits connections if the TCP destination port is 25 (which is the well-known destination port for mail servers). However, it only permits Port 25 connections to a single mail server, This obviously is safer than opening connections to any internal mail server. Protocol-Based Rules IP packets contain protocol fields that describe the contents of the data field. Typical IP protocol values are 1 for ICMP, 6 for TCP, and 17 for UDP. However, other protocol values are encountered under certain circumstances. IPsec requires two openings in firewalls so that external devices can reach IPsec gateways. (In Figure 4, the IPsec gateway is ) First, traffic going to TCP Port 500 permits the initial IP Net Key Exchange (IKE) connection to the server. Rule 3 permits this. In addition, IPsec Encapsulating Security Payload (ESP) traffic needs to reach the IPsec gateway. EPS traffic is carried in packets that have 51 in the protocol field. Rule 4 permits this protocol-based rule. Deny ALL The final rule, Rule 5, is Deny ALL. Any attempts to open connections from the outside other than the exceptions listed in the ACL are subject to the stateful firewall’s default behavior, which is to block them. The deny rule implements the default behavior of blocking all externally-initiated connection attempts. After Connections are Established Stateful firewalls have simple default behavior for deciding whether to allow a connection, although ACLs complicate the decision considerably. However, for ongoing connections, things are always very simple. If a packet does not attempt to open a connection, the stateful inspection firewall passes the packet if it is part of an approved connection; otherwise, it drops the packet. As Figure 4-7 a,b,c show, a connection consists of internal and external sockets. TCP Connections: For example, suppose that a packet arriving from the outside has the source IP address , a TCP source port number 80, a destination IP address , and a TCP destination port number This matches the existing approved connection in the first row. Therefore, the packet will be passed. UDP Connections: Although UDP is connectionless, stateful firewalls can handle UDP as well as TCP. They create state table entries with the IP addresses and UDP port numbers of the two communicating hosts, as shown in Figure 7. Attack Attempts: However, suppose that a host that is sending from the inside of the network to the outside has the source IP address (a spoofed IP address) and the TCP destination port 80. In Figure 8, we see that this does not match any row in the state table. The packet is not part of an approved connection and will be dropped and logged. Arriving packets that are not connection opening attempts and that do not match a row in the state table are dropped

Permitting Incoming Connections in a Stateful Inspection Firewall (Ingress ACL)
1. If TCP destination port = 80, Allow Connection [Pass all HTTP traffic to any webserver. (Port 80 = HTTP)] 2. If TCP destination port = 25 AND destination IP address = , Allow Connection [Pass all SMTP traffic to a specific host (mail server), Port 25 = SMTP] Safer than Rule 1

Rule based on IP protocol value.
Permitting Incoming Connections in a Stateful Inspection Firewall (Ingress ACL) 3. If TCP destination port = 500, AND destination IP address = , Allow Connection [Pass all IP Net Key Exchange traffic to the firm’s IPsec gateway, ] 4. If protocol = 51, AND destination IP address = , Allow Connection [Pass all encrypted ESP traffic to the firm’s IPsec gateway, Protocol 51 is IPsec ESP Encapsulating Security Payload ] Rule based on IP protocol value.

5. Deny ALL [Deny all other externally-initiated connections]
Permitting Incoming Connections in a Stateful Inspection Firewall (Ingress ACL) 5. Deny ALL [Deny all other externally-initiated connections] (Use the default behavior of stateful inspection firewalls for all other connection-opening attempts)

Stateful Firewall Default Operation
Internally initiated communication is allowed. X Internal Host Externally initiated communication is stopped. External Host

Main Border Firewall Stateful Inspection
Stateful Firewall Operation If accept a connection… Record the two IP addresses and port numbers in state table as OK (open) Accept future packets between these hosts and ports with no further inspection This stops most IP Net-level attacks Does not address application-level attacks

Main Border Firewall Stateful Inspection I
2. Establish Connection 1. TCP SYN Segment From: :62600 To: :80 3. TCP SYN Segment From: :62600 To: :80 External Webserver Again: Outgoing Connections Allowed By Default Permitted outgoing Connections are Placed in the Connection table Stateful Firewall Internal Client PC Connection Table Type Internal IP Internal Port External IP External Port Status TCP 62600 80 OK

External Webserver 6. TCP SYN/ACK Segment From: :80 To: :62600 Stateful Firewall 4. TCP SYN/ACK Segment From: :80 To: :62600 Internal Client PC 5. Check Connection OK; Pass the Packet Connection Table Type Internal IP Internal Port External IP External Port Status TCP 62600 80 OK

Stateful Firewall Operation For UDP, also record two IP addresses and port numbers in the state table Connection Table Type Internal IP Internal Port External IP External Port Status TCP 62600 80 OK UDP 63206 69 OK

Main Border Firewall Stateful Inspection II
Attacker Spoofing External Webserver 1. Spoofed TCP SYN/ACK Segment From: :80 To: :64640 Internal Client PC 2. Check Connection Table: No Connection Match: Drop Connection Table 5.8. Comments: Simplicity and Therefore Speed and Low Cost Although creating connections is somewhat complex, most packets are not connection-opening attempts. Rather, they are subsequent packets in a recognized connection or they are attack packets that are not part of legitimate connections. For the vast majority of packets, then, the stateful firewall does a simple table lookup and decides immediately if the packet should be permitted or not. This simplicity makes stateful inspection firewalls very fast per packet examined and therefore inexpensive. Safety The absence of additional examination beyond checking for a packet being part of a connection might seem like a serious limitation. However, very few IP Net level attacks can get through a stateful inspection firewall unless the administrator creates incorrect ACLs. Of course, separate filtering must be done for application level attacks. Dominance for Main Border Firewalls The combination of high safety and low cost makes stateful inspection firewalls extremely popular. In fact, the vast majority of main border firewalls use stateful inspection. 4.9. Beyond Stateful Inspection Although stateful inspection is the primary filtering mechanism of main border firewalls, most main border firewalls are integrated firewalls that offer other types of filtering as well. They usually do several of the other inspection methods we will see later in this chapter, including intrusion prevention for denial-of-service attacks and limited application content inspection (although not the application relaying we will see in the section on application firewalls). Main border firewall functionality is driven by needs and pragmatism, not by purity in using stateful inspection Type Internal IP Internal Port External IP External Port Status TCP 62600 80 OK UDP 63206 69 OK

Stateful Inspection Firewall in Perspective
Simplicity and Therefore Low Cost Connection opening decisions are somewhat complex But most packets are part of approved ongoing connections Filtering ongoing packets is extremely simple Therefore, stateful inspection is fast and inexpensive

Low Cost Safety Stops nearly all IP Net-level attacks (Application-level filtering still needed) Dominance for Main Border Firewalls Nearly all use stateful inspection

Beyond Stateful Inspection Most main border firewalls also use other inspection methods Denial-of-service filtering Limited application content filtering Etc.

Firewall Architecture (Single Site)
1. Screening Router Last Rule=Permit All IP Net x Subnet Public Webserver External DNS Server SMTP Relay Proxy HTTP Proxy Server Marketing Client on x Subnet Accounting Server on x Subnet

Static Packet Inspection on Screening Router Firewalls
Screening Firewall Routers Add filtering to the border router to stop scanning TCP/IP probes packets at IP level that contains IP addresses and Port numbers Filter out many high-frequency, low-complexity attacks For ingress filtering, reduce the load on the main border firewall 4.10. Static Packet Filtering What is Static Packet Filtering? Typically, screening firewall routers do not use stateful inspection. Rather, they usually use an older firewall filtering technique called static packet filtering. Static packet filtering has two defining characteristics. Limited Header Filtering First, static packet filtering only examines the contents of the IP header, the TCP header, the UDP header, and the ICMP header. It does not look at application messages at all, however. However, not all attacks can be filtered this way (Fig. 4 11). Examining Packets in Isolation: Second, static packet filtering examines packets one at a time in isolation. These further limits what static packet filtering can do. For instance, suppose that an attacker sends a TCP SYN/ACK segment to an internal host. This looks like a legitimate response to an internally-generated SYN message, so static packet filter firewalls normally permit TCP SYN/ACK attack packets to go through. Comments: Although static packet filtering has limitations, it is acceptable for a screening firewall router that attempts to reduce the number of attack packets entering the network. In addition, as noted earlier, screening firewall routers make a good last point of defense for outgoing packets.

High Cost for Sufficient Performance Must add inspection software for the router (expensive) Usually must upgrade router processing speed and memory (expensive)

Good Location for Egress Filtering Stops all replies to probe packets Including those from the border router itself

Static Packet Filter Firewall
Corporate Network The IP Net Permit (Pass) IP-H TCP-H Application Message IP-H UDP-H Application Message Deny (Drop) IP-H ICMP-H ICMP Message Log File Only IP, TCP, UDP and ICMP Headers Examined

Static Packet Filter Firewall
Corporate Network The IP Net Permit (Pass) IP-H TCP-H Application Message IP-H UDP-H Application Message Deny (Drop) IP-H ICMP-H ICMP Message Arriving Packets Examined One at a Time, in Isolation; This Misses Many Arracks Log File

Use Static Packet Filtering Require complex access control lists (ACLs) Because need an ACL statement for each rule

Screening Firewall Router Ingress (out to in) ACL
1. If source IP address = 10.*.*.*, DENY [private IP address range] 2. If source IP address = *.* to *.*, DENY [private IP address range] 3. If source IP address = *.*, DENY [private IP address range] 4. If source IP address = *.*, DENY [internal IP address range] 5. If source IP address = , DENY [black- holed IP address of attacker] 4.11. Static Packet Filtering Access Control Lists Stateful firewalls have simple default behavior: Drop all attempts to make connections from the outside; allow all attempts to make connections from the inside. Allow ongoing packets if they are part of a previously approved connection. For screening firewall routers, however, filtering decisions have to be specified in detail, using static packet firewall access control lists (ACLs). Figure shows a static packet filter firewall ACL for ingress. We will see an egress ACL for this screening firewall router later, in Figure 4.13. If this segment gets through, the internal host realizes that it never sent a TCP SYN packet to the external host. It sends out a TCP RST segment in response. The packet containing the TCP RST response message contains the IP address of the internal host. This is useful information to the attacker. Ingress Filtering Based on Source IP addresses Figure 4-12 is the ingress ACL for a hypothetical screening firewall router with packet inspection. The first five rules deny packets based upon source IP addresses. Each rule identifies a source IP address that cannot possibly be legitimate. Private IP Addresses: The first three rules deny packets from private IP addresses ranges, which should only be used inside organizations. These ranges are: 10.x.x.x ( /8) x.x to x.x ( /12) x.x ( /16) Private IP addresses should never appear in packets traveling through the IP Net. Packets with private source IP addresses are crafted (hand-built by an attacker) and are designed to keep their origin anonymous. Internal IP Addresses: The fourth rule in Figure 4-12 filters out incoming packets from the firm’s own public IP address range (60.47.*.*). These are internal addresses that should not be seen in the source IP addresses of packets arriving from the outside, unless the firm has multiple sites. If a firm has multiple sites, the IP address range used within the particular site protected by the border firewall should be filtered out. Black-Holed Address: The fifth rule filters out a specific IP address ( ) that is being “black holed” (blocked) because it has been used recently by an adversary to attack the firm. Unfortunately, attackers can often switch spoofed source IP addresses rapidly, and black holing is ineffective in such cases. In Some static packet filter firewalls also drop packets from “bogons,” that is, IP address ranges that have not been assigned for use but that may be assigned in the future. In addition, firewall administrators must be certain that the black-holed IP address does not also belong to a legitimate server to which internal clients need access. TCP Ingress Filtering RST Generation: Rule 6 drops all packets whose SYN and FIN bits are both set (have the value “1”). As we saw in the last chapter, no legitimate message would request both to open a connection and to close the same connection. Real-world ACLs typically deny several combinations of TCP flag bits that are designed to elicit RST segments. Passes to Specific Servers: Rule 7 passes packets carrying TCP segments to a particular internal webserver, Two ports must be available on this machine—Port 80 (HTTP), and Port 443 (HTTP over SSL/TLS, which is used when the method is Note that Rule 7 needs to come before Rule 8, which denies connections to Ports 80 and 443 on all machines. If the rules were accidentally reversed, the packet would be filtered out before it reached the pass rule. In general, exceptions to a deny rule must come before the deny rule. Ingress Rules Based on Other TCP Port Addresses Blocking FTP and Telnet: Rules 9, 10, and 11 block a number of incoming connection requests for popular services that the company does not provide to clients beyond its borders. These include FTP (TCP Port 20 for data transfers and TCP Port 21 for supervisory connections and Telnet (TCP Port 23). FTP and Telnet are particularly vulnerable to sniffing because they usually send passwords in the clear, without encryption. The supervisory connection on Port 21 is set up first and persists throughout the connection. A separate Port 20 data connection is set up for each file transfer. Blocking NetBIOS Probes: Next comes Rule 12, which blocks incoming packets to TCP Ports 135 through 139. These ports are used by NetBIOS for access to shared directories and printers in older Windows peer-to-peer networking. Many users do not protect their shared files adequately. This rule prevents hackers from reaching open shares (unprotected shared directories and servers). UNIX r Services and SSH: Rules 13 and 14 block “r” services, which allow access without logging in if the source IP address in the packet matches one of the addresses in an admission list. IP address spoofing is devastatingly effective against such hosts. These r services run only on Unix computers. These r services include, among others, rlogin on TCP Port 513 and rsh on TCP Port 514. The rlogin command allows logging in without giving a password. The rsh command allows a user to start up a shell (user interface) program on a computer without logging in to the host. This allows the attacker to execute a long series of commands. Rule 15 also blocks the safer SSH (secure shell) protocol on TCP Port 22. SSH allows Telnet-like access to servers but with good security. Unfortunately, SSH Version 1 had inadequate security, and many servers that support SSH Version 2 access also accept Version 1 connections as a default. In any case, SSH is used legitimately primarily for the external management of internal servers, routers, and firewalls; this is not done in the firm in this example, so blocking SSH is wise. UDP Ingress Filtering For UDP traffic, there is only a single rule in the ACL. Rule 16 blocks Trivial File Transfer Protocol traffic to UDP Port destination 69. TFTP permits outside clients to get files to or from an internal computer without having to log in. This is useful to attackers, who load TFTP servers onto compromised as a way to steal files from them. ICMP Ingress Filtering As noted, ICMP headers have two diagnostic fields: type and code. Type defines the general kind of supervisory information the ICMP message contains. Code further specifies the kind of supervisory information in the ICMP message. ICMP is a dangerous protocol because of its power as a network diagnostic tool. Rule 17 allows a single ICMP type to enter the network—Type 0 (echo reply). This type has no code. This rule allows internal hosts to ping external hosts and receive replies. The next rule drops all remaining ICMP messages. Allowing only ICMP echo replies in ingress filtering is common practice in the industry. Again, ordering is critical. If Rule 18 came before Rule 17, not even echo replies would pass. Pass All: In screening firewall routers, the last rule always is Pass All for both ingress and egress filtering. Any packet that is not identified as being an attack packet in earlier rules is permitted to pass. Remaining attacks will be stopped by the main firewall (or by a subsequent application proxy firewall). Egress Filtering ACL: Figure 4-12 showed an ingress filtering ACL for packets arriving from the IP Net. However, egress filtering (outbound filtering) also is important. Figure 4-13 shows an egress filtering ACL for the screening firewall router we have been discussing. Source IP address Egress Filtering: To be a good neighbor, a firm never should allow attack packets to be sent from inside the firm to another firm. Although few firms have internal hackers, compromised hosts often are used to send illegitimate packets. Most attack packets have spoofed source IP addresses. The first rule filters out all packets that do not have the site’s particular internal IP address range. ICMP Egress Filtering: Rule 2 allows ICMP echo messages to leave the firm so that internal hosts can ping external hosts. Rule 3 then denies all other outbound ICMP messages. As noted, many types of ICMP messages are error advisement messages are used in scanning attacks. Stopping outgoing error advisement messages will prevent worms that infest internal hosts from doing outbound scanning to find new victims and from notifying the worm writer that the computer has been compromised. Reset (RST) Egress Filtering: Rule 4 filters TCP reset (RST) segments that are sent when the hacker sends TCP segments that cause the target host to reject the connection. This rejection generates a TCP RST segment (that has the RST bit set). Packets carrying TCP RST segments have the target host’s IP address in the source IP address field and so should not be permitted to get back to the attacker. Of course, this rule also prevents legitimate RSTs from getting to external hosts. Stopping a Trojan Horse with Egress Filtering: Rule 5 is a temporary rule. A Trojan horse that is spreading rapidly at the time this ACL is being examined communicates to the outside world using TCP source port The ACL drops all communication from this port in order to prevent the Trojan horse from communicating with the attacker who placed it there. Most Trojan horses are more flexible in how they communicate with the outside world, making static packet filtering very difficult. Rule 8 illustrates that ACL builders often place temporary rules in their ACLs to deal with short-term threats. Pass All: The final rule is Pass All, which passes all other packets. Again, this is a screening firewall. It stops certain specified traffic passes on the rest.

Screening Firewall Router Ingress ACL
6. If TCP SYN=1 AND FIN=1, DENY [crafted attack packet that makes no sense, asking both to open a connection and to close a connection] 7. If destination IP address = AND TCP destination port = 80 OR 443, PASS [connection to a public webserver via HTTP and HTTP over SSL/TLS] 8. If TCP destination port = 80 OR 443, DENY [prevent communication to other internal webservers] Note: Rule 7 MUST come before Rule 8

9. If TCP destination port = 20, DENY [FTP data connection] 10. If TCP destination port = 21, DENY [FTP supervisory control connection] 11. If TCP destination port = 23, DENY [Telnet data connection] 12. If TCP destination port = 135 through 139, DENY [File/Print Sharing for Windows clients]

13. If TCP destination port = 513, DENY [Unix rlogin without password] 14. If TCP destination port = 514, DENY [Unix rsh launch shell without login] 15. If TCP destination port = 22, DENY [SSH for secure login, but Version 1 was not secure] 16. If UDP destination port = 69, DENY [Trivial File Transfer Protocol; no login necessary]

17. If ICMP Type = 0, PASS [allow incoming echo reply messages] 18. If ICMP, DENY [drop all other incoming ICMP packets] 19. PASS ALL [pass all other packets; it is the job of the main border firewall to stop attacks not found by the screening firewall router]

Screening Firewall Router Egress (in to out) ACL
1 If source IP address NOT = *.*, DENY [not in internal IP address range so must be spoofed] 2. If ICMP Type = 8, PASS [allow outgoing echo messages, that is, pings] 3. If ICMP, DENY [drop all other outgoing ICMP messages] Again, order is important.

Screening Firewall Router Egress ACL
4. If TCP RST=1, DENY [do not allow outgoing resets; used in host scanning] 5. If TCP source port = 1234, DENY [port of a currently-widespread Trojan horse] 6. PASS ALL [screening firewalls have PASS ALL as their last rule]

NAT and PAT Because the firewall keeps track of all live connections through it, the firewall is able to make both NAT and PAT, or any combination thereof. NAT: Network Address Translation PAT: Port Address Translation A firewall performing NAT or PAT is often referred to as a masquerading firewall.

Network Address Translation (NAT)
Here, we look at several filtering methods that firewalls use to make pass/deny decisions about arriving packets. There is one IP Net-level method used in several types of firewalls that does not actually filter packets but that effectively provides a great deal of protection. This is network address translation (NAT). It is used in firewalls that use different types of examination methods as a second type of protection. 4.11. Network Address Translation (NAT) Here, we look at several filtering methods that firewalls use to make pass/deny decisions about arriving packets. However, there is one IP Net-level method used in several types of firewalls that does not actually filter packets but that effectively provides a great deal of protection. This is network address translation (NAT). It is used in firewalls that use different types of examination methods as a second type of protection. Sniffers Figure show that hackers sometimes can place sniffers outside of corporation networks. As packets from these corporate networks pass through the sniffer, the sniffer captures them and notes source IP addresses and source port numbers. This allows the attacker to learn about the network without sending probe packets into the network. Most importantly, it can learn the IP addresses of internal hosts and then send attack packets to these IP addresses and specific port numbers. NAT Operation Figure 4.14 illustrates how a process called network address translation (NAT) can thwart sniffers. Packet Creation: First, the internal client sends a packet to an external server. This packet contains the client’s real IP address, The UDP datagram or TCP segment it carries has the ephemeral port number This is the socket :61000. Network and Port Address Translation: The NAT firewall intercepts all outgoing traffic and replaces source IP addresses and source port numbers with stand-in IP addresses and port numbers. In this case, the stand-in IP address is , and the stand-in port number is So the stand-in socket in the outgoing packet is :55380. Translation Table: The NAT firewall then places the real and stand-in sockets in a row in the NAT firewall’s translation table. The NAT firewall then sends the packet to the server. Response Packet: When the server replies, it will send a packet with destination IP address and destination Port When this packet reaches the firm, the border router sends it to the NAT firewall (unless the router itself does NAT). Restoration: The NAT firewall notes that the socket :55380 exist in its translation table. It therefore replaces the stand-in destination IP address and stand-in destination port number with and The firewall sends this packet to the client PC. Comments on NAT: Sniffers and NAT: It might seem like attackers could simply learn stand-in IP addresses and port numbers and send probing packets to these IP addresses and port numbers. The NAT function in the firewall would send these packets on to the host. Although this is true, most sessions between pairs of hosts are brief. By the time an attacker learns an IP address and port number and sends back probe packets, that row in the translation table usually no longer exists. The probes will not get through. Of course, if sniffers can sample quickly and send back attack packets immediately, these could indeed get through to the internal host. However, if the attacker sent a probe packet to an end host, the response would still only contain transient stand-in IP addresses and port numbers. The one real danger comes from, attack packets designed to exploit the host, such as packets designed to take over control of the computer. These are a real threat if attacker reaction time is fast. NAT/PAT: Although the firewalls we are discussing are called NAT firewalls, they translate both network addresses (IP addresses) and port numbers. Therefore, it would seem appropriate to call them NAT/PAT firewalls. This is seldom done, but it is important to understand that NAT does not only translate network IP addresses but port numbers as well. Problems with Certain Protocols: Certain protocols, including the important IPsec virtual public network protocol (VPN) have problems with network address translation (NAT). Although there is work-around for these problem protocols, security often is compromised by using work-around. One work-around is to use static rows in state tables that never change; this obviously makes internal hosts easier to attack. Another is to permit certain protocols to bypass NAT, again losing security. Several home access routers that provide NAT have a “VPN” port that permits NAT bypassing. Using NAT for Address Multiplication: Even firms that do not use NAT for security often use it to give them more internal IP addresses. Sometimes, firms are assigned only 254 public IP addresses or even fewer. They might have more computers needing IP Net access than they have assigned public IP addresses. These firms use public IP addresses on the IP Net side of the NAT firewall. Internally, however, they use private IP address ranges that are restricted to internal use within a firm. Port address translation allows more than 16,000 internal/external dialogs to use a single public IP address but different port numbers. Therefore, even if a firm is given only 254 public IP addresses or even fewer, it can still have thousands of internal computers. If IP Version 6 becomes popular, IP addresses will no longer be scarce, and address multiplication will no longer be an attractive aspect of NAT. However, the security that NAT provides should continue to make it popular.

The problem: Sniffers on the IP Net can read packets to and from organizations Reveals IP addresses and port numbers of hosts Provides considerable information about potential victims without the risks of sending probing attacks Solution: Hide IP addresses and port numbers of internal hosts.

From , Port 61000 NAT From , Port 55380 1 Server Host 2 IP Net Client 3 4 To , Port 55380 To , Port 61000 Internal External IP Addr Port IP Addr Port 61000 55380 . . . . . . . . . . . .

Server Host IP Net Client NAT Firewall 3 4 Sniffer To , Port 61000 To , Port 55380 Internal External IP Addr Port IP Addr Port Translation Table 61000 55380 . . . . . . . . . . . .

By themselves, provide a great deal of protection against attacks
Comments on NAT Sniffers on the IP Net cannot learn internal IP addresses and port numbers Only learn the translated address and port number By themselves, provide a great deal of protection against attacks External attackers cannot create a connection to an internal computers

Sniffers and NAT Comments on NAT
Sniffers can read stand-in IP addresses and port numbers Can send back packets to these stand-in values; NAT will deliver them to the real host

NAT/PAT Comments on NAT
NAT does more than network (IP) address translation Also does port number translation Should be called NAT/PAT, but NAT is the common term

Problems with Certain Protocols
Comments on NAT Problems with Certain Protocols Virtual private networks VoIP, etc.

Box: Using NAT for Address Multiplication
Comments on NAT Box: Using NAT for Address Multiplication Firm may only be given a limited number of public IP addresses Must use these in packets sent to the IP Net May use private IP addresses internally

Using NAT for Address Multiplication
Comments on NAT Using NAT for Address Multiplication For each public IP address, there can be a separate connection for each possible port Address , Port = 2000 Address , Port = 2001 Etc. Each connection can be linked to a different internal IP address Can have thousands of internal IP addresses for each public IP address

Application Proxy Firewalls
So far, we have looked at IP Net-level methods. Static packet filter firewalls, stateful firewalls, and NAT do nothing to prevent attacks at the application level. If a packet does not contain an IP Net-level attack, it is passed even if it contains a virus or other harmful application content. This is unfortunate because application messages contain information that is potentially valuable for detecting many types of attacks. Application proxy firewalls make up for this oversight by explicitly filtering application messages. Application Proxy Operation: Figure 4.15 illustrates how an application proxy firewall works. This is an HTTP application proxy firewall, with an HTTP proxy program. Proxy Program: On an application proxy firewall, the program that provides the protection is called a proxy program. A proxy is someone or something that acts on behalf of another. We will see in the next few paragraphs why these programs are called proxies. The proxy on the application proxy firewall in Figure 17 is an HTTP proxy program. On an application proxy firewall, the program that provides the protection is called a proxy program. Client Initiation: The client initiates an interaction by sending an HTTP request message. The client places this HTTP request message within a TCP segment that is delivered within an IP packet. Application Proxy Firewall Reception: The HTTP request message does not go directly to the destination HTTP server. Instead, it goes to the application proxy firewall. The HTTP proxy program on the firewall examines the application message and either passes or drops the HTTP request message based on the application content. We will look at specific pass/deny considerations later. Application Proxy Firewall Transmission: If the packet is acceptable, the HTTP proxy puts the HTTP request message in a new TCP segment and new IP packet. It sends this IP packet on to the HTTP server. The Response: The HTTP server, in response to the HTTP request message, finds the requested file and sends the file back in an HTTP response message. This response goes to the application proxy firewall. Ingress Filtering: When the application proxy firewall receives the HTTP response message, the HTTP proxy filters the message’s application content, either passing or denying the packet. Again, we will look at specific filtering issues later. Client Receipt: Finally, the HTTP proxy puts the HTTP response message in a new TCP segment in a new IP packet and sends the packet on to the requesting client. Client/Server Relaying In effect, the application proxy firewall relays messages between the client and the server. Consequently, this approach is called relay operation. To the Client: To the client, the application proxy firewall acts as a server. The client sends the firewall HTTP request messages and gets back HTTP response messages, just as if the application proxy firewall were an HTTP server. To the HTTP Server: To the HTTP server, in turn, the application proxy firewall appears to be a client. The firewall sends the server HTTP request messages, and the server sends back HTTP response messages. The application proxy firewall works transparently, and the server is unaware that it is not talking to the client. Full Protocol Support: Clients and servers can send many different types of application messages in any complex protocol such as HTTP. The HTTP proxy on the application proxy firewall can handle all HTTP request messages a client can send and all HTTP response messages the server can send back. The proxy supports the full HTTP protocol. Slow Processing Speed: Although relay operation has many advantages, which we will see in the next section, it has one serious disadvantage. It is slow and therefore expensive per packet handled. Having to emulate a server and then a client or a client and then a server for many connections is highly processing-intensive. Consequently, application proxy firewalls usually can only handle moderate traffic loads. Core Protections Provided by Relaying Just by the way its relay operation, an application proxy firewall provides three core protections automatically. Figure 18 shows these core protections. IP Address Hiding: Suppose an attacker has a sniffer that reads all packets passing over the connection between the company and the IP Net. If there is no application proxy firewall (or NAT) in place, the source IP addresses of outgoing packets will reveal the IP addresses of internal hosts, identifying potential victims to exploit. However, if there is an application proxy firewall before the router leading to the IP Net, the source IP address in every outgoing packet passed through the application proxy firewall will be the application proxy firewall’s own IP address. The attacker will learn nothing but the IP address of the application proxy firewall. Like NAT, application proxy firewalls do not reveal the IP addresses of internal hosts. Protections Offered Automatically by Relaying: IP Address Hiding: Sniffer only Learns IP Address of Firewall Protections Offered Automatically by Relaying: Removes Headers from Arriving Packet: Eliminates Header-Based Attacks Packet Header Destruction: Figure illustrates another automatic protection that application proxy firewalls provide—the destruction of all packet headers before the application message. The application proxy firewall decapsulates the application message from the packet in which the application message arrives. In doing so, it discards the IP and TCP or UDP headers. This stops all attacks based on IP, TCP, and UDP headers. This includes almost all scanning attacks. Only application-based attacks can get through proxy firewalls. Protocol Enforcement: Many static packet filter and stateful firewalls permit all packets to or from Port 80 and other common application ports to pass without further inspection. Consequently, many attack programs attempt to communicate with their partners over one of these commonly passed ports, especially Port 80, which is the port most commonly left open. Running an application on a port designated for another application is called port spoofing. It also is illustrated in Figure 4-16. With an application proxy firewall, port spoofing is difficult. The application proxy firewall acts like a server to the client, as we have just seen. The HTTP proxy expects the client to be sending HTTP commands, and if the client tries to speak a different protocol, the HTTP proxy will not understand the messages and will break the connection. If all Port 80 connections to external hosts must pass through the application proxy firewall, port spoofing should be very difficult. HTTP Tunneling Unfortunately, as application proxy firewalls have gotten better at protocol enforcement, some peer-to-peer file transfer vendors and attackers have moved to HTTP tunneling, in which the application actually uses HTTP, placing application messages in HTTP request and response bodies. HTTP tunneling allows the application to get through HTTP proxy firewalls. Although application proxy firewalls are getting better about HTTP tunneling, attempts to stop this attack vector usually are far from perfect. HTTP Content Filtering In addition to the three automatic core protections that are always provided by application proxy firewalls (header destruction, IP address hiding, and protocol fidelity), application proxy firewalls provide special protection based on the particular application being proxied. We will look at this first with HTTP. Command Filtering: Application-specific filtering can be used to prevent internal or external hosts from using certain commands. For example, the HTTP GET command, which is used to retrieve files, normally is permitted by an HTTP proxy. However, the HTTP POST command can be used to send files out of firms. These files could contain intellectual property. An HTTP proxy might be configured to reject HTTP request messages using the POST command to thwart attempts to send out trade secrets via HTTP request messages on Port 80. Host or URL Filtering: In addition, the company might want to filter all messages to and from specific hosts and URLs. For instance, black lists of offending hosts and URLs have been developed for pornography sites and other sites that should not be visited by employees. Many firms drop all HTTP traffic to and from sites on these black lists. Other firms only permit HTTP traffic to specific URLs on the firm’s white list of approved sites. MIME and File Extension Filtering: In HTTP response messages, the header contains a MIME field that specifies the format of the file being delivered in the body. Many HTTP proxies delete files with certain MIME types. Unfortunately, MIME typing is not well-standardized, so HTTP proxies typically also filter out executable or potentially executable files by banning a number of file extensions, such as .bat, .bin, .cmd, .com, .dll, .exe, .lnk, .pif, .scr, and .vbs. Zipped files (.zip) are especially dangerous because their contents cannot be read—not even the file type of the zipped file. HTML Script Filtering: HTTP proxies often can do limited content filtering, although they rarely do antivirus filtering. Most commonly, HTTP proxies will strip out scripts from HTML bodies. Multiple Proxies Application proxies use application-specific relaying, in which they act as both a client and a host when packets arrive. Consequently, separate application proxies are needed for each application being filtered, as Figure 4-17 illustrates. A small firm might run all application proxies on a single application proxy firewall, as in Figure In small firms, traffic volume will not justify the cost of multiple application proxy firewalls. However, larger firms try to use one application proxy firewall per application proxy. This way, if an application proxy firewall is compromised, only one application proxy is compromised.

Application Proxy Firewall
2. Filtering 3. Examined HTTP Request From 1. HTTP Request From Browser HTTP Proxy Webserver Application Application Proxy Firewall Filtering: Blocked URLs, Post Commands, etc. Webserver Client PC

Application Proxy Firewall Operation
4. HTTP Response to 6. Examined HTTP Response To Browser HTTP Proxy Webserver Application 5. Filtering on Hostname, URL, MIME, etc. Webserver Client PC Application Proxy Firewall

Client Server Relaying Relay operation: Proxy acts as a server to the client and a client to the server Full protocol support Slow processing per packet

HTTP Content Filtering Command filtering (POST) Host or URL filtering MIME and file extension filtering HTML script filtering

Core Protections IP address hiding (sniffer will only see the application proxy firewall’s IP address) Packet header destruction Stopping protocol spoofing with protocol enforcement Problem with HTTP Tunneling

Core Protections Due to Application Proxy Firewall Relay Operation
Sniffer Packet from Packet from Application Proxy Firewall Internal Host Webserver

Header Removed Arriving Packet New Packet X App MSG (HTTP) App MSG (HTTP) Orig. TCP Hdr Orig. IP Hdr App MSG (HTTP) New TCP Hdr New IP Hdr Application Proxy Firewall Attacker Webserver

Trojan Horse X 1. Trojan Transmits on Port 80 to Get Through IP Net-Level Firewall Application Proxy Firewall Internal Client PC Attacker 2. Protocol is Not HTTP Firewall Stops The Transmission

Application Proxy Firewall Operation
A Separate Proxy Program is Needed for Each Application Filtered on the Firewall FTP Proxy SMTP ( ) Proxy Webserver Client PC Outbound Filtering on Put Inbound and Outbound Filtering on Obsolete Commands, Content Application Proxy Firewall

Multiple Proxies Each application to be filtered needs a separate proxy program Small firms usually use a single application proxy firewall with multiple application proxies Large firms usually use a single application proxy firewall per proxy

Other Application Proxies FTP (prohibit Put, limit file sizes, etc.) SMTP (Prohibit obsolete commands, delete attachments, limit attachment size, MIME type) Web Services (work in progress) 4.13 Other Application Proxies FTP Content Filtering FTP is another application whose commands can be filtered. Many companies allow FTP Get commands, which retrieve files from external FTP hosts. However, FTP Put commands, which are used to upload files to external servers, might be filtered to prevent proprietary files from being sent out of the firm this way. Some firms forbid all outgoing FTP file transfers because attackers often use FTP to send intellectual property out of a firm. Some FTP proxies also stop file transfers beyond a certain size. This prevents documents containing large amounts of the firm’s intellectual property from being sent out. In some cases, firms place special character strings in sensitive documents as “digital watermarks.” If a file going out of the firm contains one of these digital watermark strings, it will not be permitted to leave. SMTP Filtering transmission is governed by the Simple Mail Transfer Protocol (SMTP). SMTP proxies usually examine SMTP messages for a group of obsolete commands that are no longer used legitimately but that are used by attackers. For instance, the obsolete WIZ command gives the attacker full control of the mail server. SNMP proxies may also delete attachments based on MIME type or file extension. Or, if they do not delete attachments, they may limit attachment file size. Some delete all attachments. Web Services Filtering Web services are programs that accept commands and input data over the IP Net and can send back responses to calling programs. For instance, a Web service for product pricing might accept a command giving part number, quantity, discount, shipping priority, and other ordering information. It would send back a response giving the price. Web services usually are carried within the bodies of HTTP messages. These bodies follow the SOAP formatting standard, which in turn is based on XML. Certain Web service firewalls or XML firewalls can scan incoming SOAP messages. However, Web services firewalls are a work in progress because Web services standards are still in flux. If a Web service request is sent via HTTP, as it usually is, HTTP headers carrying SOAP messages should have a SOAPaction field that describes the service being requested. HTTP proxies can use this information to filter requests to Web services. Several other applications can be proxied. For instance, an SNMP proxy can limit what data objects in the MIB can be queried from the outside.

Proxy Firewall Advantages
We can safely allow any kind of network traffic from the inside to the outside, as long as we use a proxy to do it. To the outside it seems that only the firewall exists. It is impossible to send any network packets directly to the internal hosts or vice versa.

Proxy Firewall Disadvantages
For every network service we wish to use we must install a proxy designed exactly for that service on the firewall. Furthermore, every network service we wish to use, we must use a client that is able to use a proxy. What can we do if no proxy exists for a given service?

Proxy Friewall In general proxy firewalls are considered very secure.
Unfortunately they are not very flexible Ideally we wish to be able to use any client software.

Circuit Firewalls Circuit Firewalls
Non application-specific application proxy firewalls Create connections at the application layer Provide IP address hiding and header destruction, but not protocol enforcement Do not provide content filtering Do provide authentication SOCKS V5 is the dominant standard for circuit firewalls 4.14. Circuit Firewalls Not all applications have content characteristics that can be filtered usefully. For some applications that cannot be content-filtered well, companies may use general-purpose proxy application proxy firewalls called circuit firewalls. Circuit Firewall Applications Figure 4.18 shows that circuit firewalls establish a connection between specific ports on a pair of hosts. After establishing this circuit, the circuit firewall basically gets out of the way, passing all messages. This might sound like a stateful firewall, but it still provides relaying and so provides two of the core protections of application proxy firewalls (IP address hiding and header destruction), although it does not provide protocol fidelity. Nor does the circuit firewall examine application message content. On the positive side, the circuit firewall typically does require authentication to qualify connections before establishing them. SOCKS The most widely used circuit firewalls follow the SOCKS Version 5 protocol. Although SOCKS offers a standardized way of building circuit firewalls, SOCKS has a number of limitations. Most seriously, SOCKS software is not built into most host computers and must be added to each client PC and server.

Circuit Firewall Generic Type of Application Firewall
1. Authentication 3. Passed Transmission: No Filtering 2. Transmission 4. Reply 5. Passed Reply: No Filtering Webserver Circuit Firewall (SOCKS v5) External Client

Antivirus Filtering 4.16. Antivirus Filtering
Separating Antivirus Filtering from Other Filtering One quirk of firewall architectures is that firewalls usually do not do antivirus filtering. This is true of both main border firewalls and application proxy firewalls. However, some firewalls (but not all) pass application messages that need antivirus filtering to a separate antivirus server for antivirus filtering. Firewalls usually do not do antivirus filtering: For example, Figure 4.21 shows that Checkpoint’s popular FireWall-1 main border firewall uses the Content Vectoring Protocol created by Checkpoint to pass packets from FireWall-1 to other servers for content filtering. All major antivirus vendors work with this protocol. As processors become faster, this separation may no longer be necessary for processing reasons. However, separating antivirus processing from main border firewall processing has another major advantage: it allows companies to purchase separate best-of-breed products for their main border firewall, their application firewalls, and their antivirus filtering servers. Antivirus Filtering Antivirus programs examine files for malware (evil software). This obviously includes viruses, but it also includes worms, Trojan horses of various types, spyware, and adware. We looked at malware attacks in Chapter 4. The name “antivirus program” actually is inaccurate and reflects the fact that viruses were the first type of malware detected by these programs. However, calling anti27 malware programs “antivirus programs” is well-established practice. When a file is examined, the antivirus program uses a number of techniques to look for malware. In most cases, the antivirus program checks the file against malware signatures of known viruses, worms, and other types of malware. These signatures usually are strings of characters found within specific malware files. Antivirus companies are engaged in an arms race with malware writers, and malware detection techniques have become quite complex. In general, antivirus companies have been able to keep up with malware evolution. Antivirus programs can even detect malware that is zipped or encrypted. However, antivirus firms live in fear of nightmare malware technologies that will require so many CPU processing cycles to detect that antivirus programs will work too slowly to be useful. Creating New Signatures Antivirus firms have sophisticated techniques for detecting new viruses, worms, and other types of malware. They have sensors in many customer firms that detect suspicious files. Sensors forward these files to an antivirus firm. At the antivirus firm, suspicious files are processed automatically to determine if they are really parts of already-known attacks. Only a handful of suspicious files reach human attention for final classification. Once a new malware program is discovered, the antivirus firms determine a signature—a string of characters or other another signature that will identify the malware quickly and reliably. This new signature is then added to the firm’s signatures database. Another problem is that antivirus programs have subscription periods. After the subscription period passes, the software usually is not removed from the server or client PCs, but no new updates can be downloaded. This is the worst of all worlds because the user may believe that his or her computer is still protected despite the fact that it is useless against all new threats. Updating Antivirus Programs Of course, the new signature does no good until it is downloaded to an antivirus server or to an antivirus program on a client PC. All antivirus programs have mechanisms for checking with the antivirus vendor to see if new signatures are available. The antivirus program then either notifies the owner or downloads the updates automatically. Sometimes the update process also downloads program patches to add new functionality to the antivirus program or to fix vulnerabilities. Although updating should go smoothly, some users turn updating off or schedule it so infrequently that it does little good for a long time after new malware programs appear. Given the rate at which new malware spreads today, automatic updating should be done at daily or even more frequently. Where to Filter? A major issue for companies is where to do antivirus filtering—on client PCs, on servers, at outsourcing firms before the mail is delivered, or some combination of the three. PC Antivirus Programs: Traditionally, antivirus filtering has been done on individual client PCs. The problem with this approach is that it relies on user updating efforts, and as discussed earlier, users often fail to update their antivirus programs. Sometimes users even turn off their antivirus program because it slows them down, seem to interfere with other programs, or will not let them open an attachment they want to open. Antivirus Filtering on the Server: Increasingly, firms are also doing antivirus filtering on the server or on an antivirus server. Incoming messages are filtered before the user sees them. Outgoing messages are filtered too. Systems administrators, who manage servers, are more likely to maintain the antivirus software than end users at client PCs. Outsourcing Antivirus Filtering: By changing the MX record on domain name system servers that point to their firm, companies can redirect incoming mail to an outsourcing service. This service will filter the mail and pass the cleaned-up mail on to the corporation. Outsourcing antivirus filtering reduces internal corporate staff labor time and takes advantage of the expertise that outsourcing firms have because of their specialization in antivirus filtering. Defense in Depth: Many firms use two of the preceding options and sometimes all three. Although they do filtering on a server or at an outsourcing firm, they also install antivirus programs on individual PCs to provide defense in depth. Spam: Spam (unsolicited commercial ) usually is handled in the same way as antivirus filtering. Spam filters can be installed on client PCs, installed on mail servers, or located at outsourcing firms. Unfortunately, while antivirus programs have few false positives (declaring something to be spam when it is not) and few false negatives (not identifying malware), antispam program only catch most spam and because of false positives have a tendency to drop some legitimate messages as spam. To differentiate spam from the Hormel meat product Spam, unsolicited commercial is spelled with a lower-case “s” except in titles and at the beginnings of sentences. Incidentally, Spam is not an abbreviation for spongy pink animal matter.

Normally, Firewalls Do Not Do Antivirus Filtering
Pass packets needing antivirus filtering to an antivirus server

Checkpoint’s FireWall-1 and Antivirus Filtering
2. Statefully Filtered Packet 1. Arriving Packet 3. DoS Protection Optional Authentications Internal Client External Server FireWall-1 Firewall 4. Content Vectoring Protocol Statefully Filtered Packet Plus Application Inspection Third-Party Application Inspection Firewall

Examine Application Messages for Many Forms of Malware
Antivirus Filtering Examine Application Messages for Many Forms of Malware Not just viruses Worms, Trojan horses, spyware, adware

Detection is Based on Signatures
Antivirus Filtering Detection is Based on Signatures Strings of characters found within specific malware files Create a new signature for each piece of malware, add it to signatures database Antivirus filter vendors worry about signatures so complex that signature-based detection will be too slow to be useful

Updating Antivirus Programs
Antivirus Filtering Updating Antivirus Programs All antivirus programs have an updating feature To get new signatures and program upgrades Without updates, programs cannot handle new threats Users may turn off updating or update too rarely Users may let subscriptions lapse; program remains, but get no new updates

Antivirus Filtering Where to Filter? On individual user PCs
The traditional approach to antivirus filtering But users often fail to update May even turn off the antivirus program because it is inconvenient

Antivirus Filtering Where to Filter? On the e-mail server
Filters mail before the user gets it Systems administrators are likely to maintain the filtering

Antivirus Filtering Where to Filter? E-mail outsourcing companies
Filter mail before it gets to the firm Outsourcers have expertise This reduces corporate labor costs

Antivirus Filtering Where to Filter? Defense in Depth
Filter in two locations or all three

Antivirus Filtering Spam Unsolicited commercial Also can be filtered on individual PCs, on servers, or at outsourcing firms Not as precise as antivirus filtering Too many false negatives (failing to label spam messages as spam) Too many false positives (labeling good messages as spam) Very dangerous.

Host Firewalls 4.18. Host Firewalls:
As a last line of defense, many companies install host firewalls on their client PCs and servers. Attacks that get through the main border firewall and other firewalls have to be stopped at individual hosts. Host firewalls give defense in depth. Host Firewalls Placed on clients and servers. Last line of defense. Precise protection because few host functions to protect. Client PC Firewalls: Client PC owners have long been able to buy client PC firewalls from third parties, but few did. Windows 2000 advanced the state of Windows security by offering a stateful firewall, the IP Net Connection Facility (ICF). Unfortunately, ICF was not turned on by default. Nor was it turned on by default when it was offered on Windows XP. In addition, while users could turn it on and tailor their ingress filtering somewhat, ICF offered no egress filtering at all. When Microsoft released Windows XP Service Pack 2 in late 2004, XP was given a new stateful inspection firewall, the Windows Firewall. Windows Firewall is somewhat better than ICF, and, more importantly, it is turned on by default. However, like ICF before it, Windows Firewall did not do egress filtering. The main reason for this omission was that egress filtering requires complex decisions by users. A stateful firewall for egress filtering constantly asks questions like “Program xyhgx.dll is attempting to connect to the IP Net. Allow or Deny?” Most users lack the knowledge to make such decisions intelligently. Unfortunately, however, giving up on egress filtering meant that Windows Firewall is unable to prevent spyware from sending out important and sometimes crucial information. Egress filtering could also stop the PC from unleashing zombie attacks and from being a spam relay. 4.19. Server Firewalls: Server hosts can also be given firewalls. These server firewalls come in two types. IP Net-Level Firewalls: Host IP Net-level firewalls implement stateful inspection. Most servers offer only one or a few services, so it usually is possible to precisely specify which few ingress ports should be left open to externally-originated connections. For instance, as noted earlier, e-commerce servers need to permit connections to Port 80 and Port 443, but all other ports should be left closed. Server Application-Specific Firewalls: Servers can also have server application-specific firewalls that do not provide relay protection but that can do application-specific content filtering. Server application firewalls are needed because IP Net-level filtering cannot stop application-level attacks. For instance, a database firewall will examine incoming SQL request messages to look for attempts to do buffer overflow attacks, SQL injection attacks, and other common types of attacks on databases. Similarly, HTTP application firewalls will examine the fields in incoming HTTP request messages for forbidden commands, attempted buffer overflow attacks, and attempts to access protected parts of the server. Server application-specific firewalls can even be linked to specific products. For instance, several server firewalls specifically protect the Microsoft IIS webserver application program. The more specific the firewall is to a particular application program, the better it can protect it.

Host Firewalls IP Net 172.18.9.x Subnet Public Webserver 60.47.3.9
External DNS Server Host Firewall Host Firewall 6. DMZ SMTP Relay Proxy HTTP Proxy Server Marketing Client on x Subnet Accounting Server on x Subnet 5. Server Host Firewall

Host Firewalls Host Firewalls Firewalls on clients and servers
Give defense in depth

Host Firewalls Client PC Firewalls Third party PC firewalls are common
Windows XP introduced the IP Net Connection Facility (ICF) Stateful inspection firewall Not turned on by default No egress filtering Can open selected ports for ingress filtering

Host Firewalls Client PC Firewalls
Windows XP Service Pack 2 (Late 2004) introduced the Windows Firewall Upgrade to ICF Turned on by default Can open selected ports for ingress filtering Still no egress filtering

Why no egress filtering on PC firewalls?
Host Firewalls Why no egress filtering on PC firewalls? Ingress filtering requires no or little user intervention Egress filtering requires users to decide what programs can communicate over the IP Net—a difficult task Does not stop spyware, other outbound attack communication

Host Firewalls Server Firewalls IP Net-level firewalls
Precise because only need to open a few specific ports Application-Specific Firewalls Filtering rules linked to specific protocols (SQL, HTTP, etc.) Filtering sometimes linked to specific application programs (Microsoft’s IIS, etc.)

Home Firewall PC Firewall Always-On Connection IP Net Service Provider
Home PC IP Net Service Provider UTP Cord Coaxial Cable Broadband Modem Windows XP has an internal firewall Originally called the IP Net Connection Firewall Disabled by default After Service Pack 2 called the Windows Firewall Enabled by default 4.24. Other Firewall Examples: 1- Home Firewalls 2- SOHO Firewall Router: SOHO stands for Small Office Home Office and used to allow small and limited number of Users PC’s to share one IP Net connection through ISDN, ADSL, DSL,…. lines.

SOHO Firewall Router IP Net Service Provider UTP Ethernet Switch UTP User PC UTP Broadband Modem (DSL or Cable) SOHO Router --- DHCP Sever, NAT Firewall, and Limited Application Firewall User PC User PC Many Access Routers Combine the Router and Ethernet Switch in a Single Box

Many firewalls, particularly those based on Stateful Inspection Security Technology (Measures or Tools), have maintained successful defense arsenals against network assaults. As a result, a growing number of attacks attempt to exploit vulnerabilities in network applications rather than target the firewall directly. This important shift in attack methodology requires that firewalls provide not only access control and network-level attack protection, but also understand application behavior to protect against application attacks and hazards. The application layer attracts numerous attacks for several reasons. First, it is the layer that contains a hacker’s ultimate goal—actual user data. Second, the application layer supports many protocols (HTTP, CIFS, VoIP, SNMP, SMTP, SQL, FTP, DNS, etc.), so it houses numerous potential attack methods. And third, detecting and defending against attacks at the application layer is more difficult than at lower layers because more vulnerabilities arise in this layer.

Comments Stateful Inspection vs. Application Layer Filtering:
Application layer filtering is considered to be the more secure method, Why? When using stateful inspection you are only looking at the envelope’s information to determine whether or not you will accept the letter. With Application Level Filtering Security Technology (Measures or Tools), you are opening the envelope to inspect the letter itself.

Stateful inspection firewalls cannot defend internal systems against application specific attacks such as buffer overflows or code exploits. These firewalls rely on the software running on internal systems for security in protecting against these types of attacks. Often customers will not secure internal systems and applications because they are given a false sense of security from their firewall. Application Layer Filtering firewalls offer a more secure method of handling traffic without exposing internal machines to application specific attacks. By verifying incoming data against an application level filter, they can intercept these types of attacks before reaching internal systems.

Comments Stateful Inspection vs. Application Layer Filtering
3) Stateful inspection firewalls may not detect inserted ‘destructive’ data that may be within a session that appears safe. Because stateful inspection firewalls do not inspect each packet for application information, a remote user can establish a session with a stateful inspection firewall to pass ‘destructive’ data. Once a session is established on a valid port, a remote user can embed potentially harmful data within a seemingly safe packet. Due to the fact that the application data can not be verified, the stateful inspection firewall would be unable to check the data of the incoming packets to verify whether they are harmful or not.

4) Stateful inspection firewalls do not provide the same level of logging that application level filters can. Because stateful inspection firewalls do not intercept the application data, they are limited to the information that they can log. Application level filters allow for more detailed logging.

Application Layer Filtering Firewall:
The traditional argument for the use of stateful inspection Security Technology (Measures or Tools) has always been that they achieve similar levels of security as other firewall technologies, but with greater throughput capabilities. This is a faulty concept based on two points: Application level filtering has always been seen as a more secure alternative to stateful inspection. Stateful inspection does not give a similar level of security as application level filtering for the reasons mentioned above. It is a less secure alternative. 2) With current operating system and hardware advances, the idea of application level filtering being slower than stateful inspection is no longer valid. Stateful Inspection Firewall can achieve a throughput of near line speed for 10 Mbps or 100 Mbps networks and do not exceed these speeds, meaning that a company’s link to the IP Net will have a bottleneck for throughput.

The Demilitarized Zone (DMZ)
In Figure which shows site firewall architecture, the main border firewall is tri-homed, meaning that it has three NICs that each connects to a different subnet. One subnet leads only to the screening firewall router (This is the x subnet.) Another subnet ( x) leads to the firm’s internal network. The third subnet ( x) is called the demilitarized zone (DMZ). The DMZ is a subnet that contains all of the servers and application proxy firewalls that must be open to the outside world. Because these hosts are accessible to attackers on the IP Net, they will face constant attack. Consequently, they must be especially hardened against attack. Security professionals call hardened hosts in the DMZ bastion hosts. Servers that must be accessed from outside are placed in a special subnet called the Demilitarized Zone (DMZ). Security Implications Attackers cannot get to Other subnets from there. DMZ servers are specially hardened.Hardened hosts in the DMZ are called Bastion Hosts Tri-homing allows the border firewall to create separate access rules for the DMZ and the internal subnet. The firewall makes access to the DMZ relatively easy for external IP Net users. However, it does not permit any externally-initiated. The term “demilitarized zone (DMZ)” stems from the Korean War. After the armistice was signed, a narrow buffer zone was established in which neither side could station its forces. However, both sides realized that future attacks would have to come through the DMZ. Consequently, both sides placed heavy troop concentrations at the edges of the DMZ. Instead of being the intended place of peace, the DMZ is the likely focal point of future struggles. Similarly, hosts placed in firewall DMZs are assumed to be major targets for attacks. In castles, bastions are parts of the castle that extend outward from the main wall. During attacks, bastions will bear the initial brunt of the attack. Consequently, they are studded with narrow windows (called loops) for firing arrows and other defenses against attack. Connections from the IP Net directly to internal clients and servers on the internal subnet. Only externally-initiated connections to hosts in the DMZ make any sense, so only they are allowed. What about connections between the DMZ and the internal subnet? Some DMZ servers need to connect to internal servers. For instance, e-commerce application servers in the DMZ may have to connect to internal databases. To give another example, an proxy application server will need to connect to the internal server. All connections between the DMZ and the internal subnet are dangerous and so are strongly limited and controlled. Tri-homing, overall, makes it easier to develop rules that control access to public-facing hosts and internal hosts. Hosts in the DMZ In general, DMZs have three kinds of hosts. Public Servers: In Figure 2, the DMZ has a public webserver ( ). If it had a public FTP server or another public server, it would also place them in the DMZ. Application Proxy Firewalls in the DMZ: In addition to being a good place for public servers, the DMZ is a good place for application proxy firewalls, which also must be connected to the outside world. Application proxy firewalls placed in the DMZ can be used to enforce a policy that all communication with the outside world must pass through the DMZ. HTTP Application Proxy Server: For example, the DMZ is the obvious place to put the HTTP application proxy server ( ), which must connect to the outside world. Note that this firewall provides only HTTP protection, so if it is compromised, other application proxies will not be compromised as well. SMTP Proxy Server: Figure also shows an SMTP application proxy server ( ), which connects internally only to the firm’s main SMTP mail server (not shown). The SMTP application proxy firewall uses a different mail program than the internal mail host. This way, an attacker would have to take over both hosts to do damage. This would require two different exploits to be used within the attack. This would at least slow attackers, if not stop them entirely. External DNS Server: The DMZ in Figure contains an external DNS server, , which is created to be accessed by the outside world. This external DNS server knows only the host names and IP addresses of bastion hosts in the DMZ. This way, outside attackers cannot use the DNS server in the DMZ to learn about hosts on the internal protected network.

IP Net x Subnet Public Webserver External DNS Server 6. DMZ SMTP Relay Proxy HTTP Proxy Server Marketing Client on x Subnet Accounting Server on x Subnet 5. Server Host Firewall

Subnet for servers and application proxy firewalls accessible via the IP Net Hosts in the DMZ must be especially hardened because they will be attacked by hackers Hardened hosts in the DMZ are called bastion hosts

Uses Tri-Homed Main Firewalls 3 NICs, each attached to a different subnet One subnet to the border router One subnet for the DMZ (accessible to the outside world) One subnet for the internal network Access from the subnet to the IP Net is strongly controlled Access from the DMZ is also strongly controlled

Hosts in the DMZ Public servers (public webservers, FTP servers, etc.) Application proxy firewalls External DNS server that only knows host names for hosts in the DMZ

DMZ Environment Can be created out of a network connecting two firewalls Boundary router filter packets protecting server First firewall provide access control and protection from server if they are hacked

Intrusion Detection Systems (IDSs)
UNIT 5 Intrusion Detection Systems (IDSs) and Intrusion Prevention Systems (IPSs) Learning Objectives: This UNIT addresses: The security goals IDS serve How to select and configure IDS for specific system and network environments How to manage the output of IDS How to integrate IDS functions with the rest of the organizational security infrastructure. By the end of this chapter, you should be able to discuss Intrusion detection systems (IDSs) and intrusion prevention systems (IPSs). 5.1. INTRODUCTION Intrusion detection systems (IDSs) are software or hardware systems that automate the process of monitoring the events occurring in a computer system or network, analyzing them for signs of security problems. As network attacks have increased in number and severity over the past few years, intrusion detection systems have become a necessary addition to the security infrastructure of most organizations. Definition of Intrusion Detection Systems IDS: Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of intrusions, defined as attempts to compromise the confidentiality, integrity, availability, or to bypass the security mechanisms of a computer or network. Intrusions are caused by attackers accessing the systems from: The NET Authorized users of the systems who attempt to gain additional privileges for which they are not authorized Authorized users who misuse the privileges given to them. Intrusion Detection Systems (IDSs) are software or hardware products that automate this monitoring and analysis process. Reasons to use IDSs: To prevent problem behaviors by increasing the supervision of risk of discovery and punishment for those who would attack or otherwise abuse the system, To detect attacks and other security violations that are not prevented by other security measures, To detect and deal with the preambles to attacks (commonly experienced as network probes) To document the existing threat to an organization To act as quality control for security design and administration, especially of large and complex enterprises To provide useful information about intrusions that do take place, allowing improved diagnosis, recovery, and correction of attacks. Definition of Intrusion Prevention Systems IPS: IPSs are more sophisticated than IDSs. It uses IDS filtration method and used to stop some kind of attack without identifying them. It is in form of ASIC for faster processing. IPS detect attacks and stop them. 1) IPS tasks when detects attack: Dropping packets Limiting traffic by limiting the bandwidth (to protect against DOS attacks) Limiting network overloading.

Intrusion Detection System (IDS)
1. Suspicious Packet Intrusion Detection System (IDS) 4. Alarm Security Administrator 2. Suspicious Packet Passed Internet Attacker? Hardened Server 3. Log Suspicious Packet 2) Attack Identification Confidence Spectrum IDSs create too many false alarms to be used in stopping attacks Some attacks can be detected with more confidence than others At first, record what the IPS would have stopped if it had been allowed to stop attacks Later, let the IPS stop high-confidence attacks May later let the IPS stop attacks with somewhat lower detection confidence 3) IPSs Use IDS Filtering Methods But actually stop attacks instead of just issuing warnings 4) Traditional IDSs do Processing in Software Too slow to be placed in-line with the packet stream, so cannot stop attacks 5) Unlike IDSs, use Application Specific Integrated Circuits (ASICs) Fast processing in hardware Can be placed in-line with the packet stream and so can stop attacks 6) Attack Identification Confidence Spectrum 7) Actions Drop packets Limit bandwidth of attack stream to a server When attack packets and legitimate packets to a host cannot be separated accurately Still affects legitimate packets to that host Protects other traffic from overload Corporate Network Log File

IDS and IPS Placement IDS Alert Attack Packet Internal Network Border
Router IPS Internet 5.2. Firewalls Versus IDSs and IPSs: Many homes and cars have burglar alarms that sound off if there is suspicious movement. Similarly, as Figure 5.1. illustrates, many corporations install intrusion detection systems (IDSs), which examine streams of packets to look for suspicious activities that indicate possible attacks. If an IDS detects an apparently serious attack, it sends an alarm message to the security administrator. IDSs are slow and cannot be in-line with the packet stream. IPSs use ASICs for speed; can be in-line with the packet stream. Therefore can stop attacks. As shown in fig. 5.2 IDS and IPS can be placed in one system to provide extra instrusion detection and prevention. It is easy to confuse IDSs with firewalls. Figure 5.3. a,b emphasizes the key differences between these two sibling technologies. The main diffrences between firewall, IDS, and IPS are: 1) Sophistication in Filtering Message stream analysis, not just individual packets Reassemble fragmented application messages Deep packet inspection: both internet-level headers and application headers 2) Firewalls Versus IDSs Firewalls drop packets IDSs only generate alarms Too many false positives (false alarms) to drop suspicious packets safely 3) IDSs versus IPSs IDSs merely send alarms IPSs, using the same filtering mechanisms, actually drops suspicious packets with high confidence of being attacks 4) Dropping Packets First, and most obviously, firewalls drop packet while IDSs merely warn when suspicious traffic occur. The reason for this is that firewalls only drop proven attack packets, while IDSs also identify packets that are merely suspicious. Dropping merely suspicious packets, many of which are legitimate, would create a self-inflicted denial-of-service attack on the firms. Firewalls drop packet while IDSs merely warn when suspicious traffic occur. Consider an analogy. To arrest a suspect, a police officer must have “probable cause”—a reasonably high level of proof. However, if an officer spots suspicious activities, he or she may investigate even if there is not sufficient proof to make an arrest. 5) Logging Packets Both firewalls and IDSs log packets, permitting later analysis. 6) Sophistication in Filtering Another difference between IDSs and firewalls is that IDSs use more sophisticated forms of filtering to detect malicious packets. 7) Message Stream Analysis: While firewalls look at individual packets or ask whether a packet is part of a connection, IDSs look at whole streams of packets to detect patterns of suspicious behavior. This allows them to detect many attacks that traditional firewalls cannot. To give the simplest example, a single SYN segment sent to a server is not suspicious, but many sent SYN segments to that server indicate a possible DoS attack. 8) Reassembling and Normalizing Application Messages: In addition, IDSs often have to assemble individual application messages from a sequence of packets. Large application messages are broken up (fragmented) and sent in multiple TCP segments. Each of these TCP segments is sent in a different packet. IDSs must identify the packets that carry a single application message and reassemble (defragment) the application message before they can analyze it. They then normalize application messages into standard format (there often are multiple ways to format a message) to reduce the number of filtering rules. Deep Packet Inspection: IDSs also do deep packet inspection, in which they look at the contents of the header fields in messages at all layers. At the application layer, they look at the contents of individual fields, applying rules appropriate for that field. For instance, they look for data values in a particular field in an HTTP message that are too large for that particular field. This application content inspection does not use relaying as application proxy firewalls do, but it is still fairly effective. 9) Alarm Generation Another key difference is that firewalls do not set off alarms when they drop packets. They drop them silently. In contrast, IDSs actively alert the security administrator when the network appears to be under attack. This allows the security administrator to take action quickly. Remember that the IDS passes the packets that it considered to be suspicious, so these packets have entered the network and may do damage. 10) Precision and False Alarms As just noted, firewalls do not drop packets unless they are quite sure that these packets are attacks. IDSs, in contrast, generate alarms if they are merely suspicious. In fact, IDSs typically generate far too many false positives (false alarms) because many apparent attacks turn out to be legitimate data flows. Like the little boy who cried wolf too many times, IDSs tend to be ignored if exhausted security staff members receive too many false positives. (Think about how you feel about a neighbor’s car alarm that keeps going off at night because a cat walks on its hood.) Many firms will not even consider using IDSs. A security administrator can reduce false positives by tuning the IDS, that is, configuring the IDS with rules appropriate for the administrator’s particular firm. For example, the administrator may only allow alarms to be sent for potential attacks that are judged to be severe by the IDS. This is relatively simple to do. The security administrator can also tune the IDS by having it not check for attacks that make no sense in the organization’s context. For instance, if a firm only has Windows client PCs, it can tune out egress detection rules for Macintosh and UNIX clients. In addition, if a webserver is a Microsoft IIS webserver, the IDS should not check for attacks that only are effective against UNIX webservers or vice versa. Unfortunately, context-based tuning, while fairly effective, is highly labor-intensive. 11) Sophistication in Filtering Message stream analysis: not just individual packets. E.g. single SYN segment sent to a server is not suspicious, but many sent SYN segments indicate possible DOS attack. Reassemble fragmented application messages: IDS identify packets that carry a single application and reassembles it for analysis. Deep packet inspection: both internet-level headers and application headers. E.g. IDS look for data values in a particular field in an HPPT message that are too large for that particular field for suspicious applications Attack Packet IDSs are slow and cannot be in-line with the packet stream. IPSs use ASICs for speed; can be in-line with the packet stream. Therefore can stop attacks.

Firewalls, IDSs, and IPSs
Drops Packets? Yes No Logs Packets Sophistication in Filtering Medium High

Firewalls, IDSs, and IPSs
Sophistication in Filtering Medium High Creates Alarms? No Yes Sometimes Precision Low without Tuning

Event Correlation in An Integrated Log File
1. 8:45:05.03 Packet from to (network IDS log entry) 2. 8:45:05.45 Host Failed login attempt for account Lee (Host log entry) 3. 8:45:06.03 Packet from to (network IDS log entry) 5.4. Integrated IDS Logs The integrated log file shown in Figure 5.4. a,b,c,d,e contains entries from many IDSs on the network and on hosts. Figure 26 shows the details of an integrated log file. Note that the first log entry, from a NIDS, shows that a packet to came from The next entry, 0.42 seconds later, shows a failed log in attempt to account Lee on server This entry is from the HIDS on Putting these two pieces of information, we are reasonably confident that the login attempt came from Putting together events from log entries on multiple devices is called event correlation. A firm using a distributed IDS needs to synchronize the clocks on all of its IDSs. Otherwise, event correlation will be impossible. Most firms do this by using the Network Time Protocol (NTP), which allows multiple devices to synchronize their time with a single time server. Too Much Processing for In-Line Operation IDS examination methodologies are sophisticated and therefore highly processing-intensive. Consequently, as Figure 27 shows, IDSs typically are not placed in-line with (in the path of) the main packet stream but rather are placed on a parallel path. (An overloaded IDS in-line with the data stream would create its own denial-of-service attack.) This keeps IDSs from slowing down packet delivery, but non-inline processing means that while IDSs can detect attacks, they cannot possibly stop them. Processing Capacity Even when IDSs are placed offline, they must have the capacity to filter all traffic passing through them. Otherwise, it would miss many attack packets during attacks that generate a large amount of traffic. An IDS that works unless an attack is occurring is not very valuable. If an IDS cannot handle the capacity, one partial remedy is to have it only look for certain kinds of attacks. Intrusion prevention systems (IPSs) grew out of IDS processing. However, although IPSs primarily use IDS filtering methods, IPSs actually stop some kinds of attacks instead of merely identifying them and generating alarms as IDSs do. Figure 24 emphasizes this difference. ASICs for Faster Processing A key development leading to IPSs has been the emergence of application5 specific integrated circuits (ASICs), which can do processing in hardware. Hardware processing is much faster than software processing, allowing IPSs to be placed in-line with the packet stream, as Figure 27 illustrates. Being in-line, IPSs are not limited to detecting attacks. When they detect attacks starting, they can actually stop them. This is why they are called intrusion prevention systems. The Attack Identification Confidence Spectrum When experienced security professionals who have worked with IDSs hear about IPSs, they usually cringe at first. Given the number of false positives that IDSs generate, the thought of allowing these unreliable filtering mechanisms to actually stop traffic is deeply disturbing. In practice, however, there always is an attack identification confidence spectrum in intrusion detection. Some attacks, especially simple denial-of-service attacks, can be identified with a high degree of confidence. (In fact, many border firewalls today already identify and stop DoS attacks regardless of their main filtering Security Technology (Measures or Tools).) Other attacks cannot be identified with such high confidence, however. When organizations install IPSs, they typically do not use them to prevent attacks immediately. Rather, companies have the IPSs record what they would have stopped had they been allowed to stop attacks. If the IPS appears to be working well, companies usually have their IPSs stop attacks at the high-confidence end of the attack identification confidence spectrum. In time, they may even move to having their IPS stop attacks for which identification confidence is not quite so high. Actions What do IPSs do when they identify an attack? Dropping Packets In many cases, the IPS will simply drop attack packets, acting like a traditional firewall. This is dangerous but decisive. Limiting Traffic In other cases, the IPS limits suspicious traffic to a certain percentage of the total bandwidth. Bandwidth limitation can ensure that even if peer-to-peer file sharing traffic and other illegitimate traffic cannot be identified with precision and dropped, this undesirable traffic at least will not result in an overloaded network. DoS attacks at a particular server can also be limited in volume. Of course, bandwidth limitation may limit legitimate along with undesirable traffic.

4. 8:45:12.30 Packet from to (network IDS log entry) 5. 8:45: Host Failed login attempt for account Lee (Host log entry) 6. 8:45:13.27 Packet from to (network IDS log entry)

7. 8:45:30.45 Packet from to (network IDS log entry) 8. 8:45:30.59 Host Successful login for account Lee (Host log entry) 9. 8:45:31.11 Packet from to (network IDS log entry)

10. 9:05:12.25 Packet from to TFTP request (network IDS log entry) 11. (no corresponding host log entry) 12. 9:05: Series of packets from to TFTP response (network IDS) 13. (no more host log entries)

:10:48.52 Packet from to TCP SYN=1, Dest. Port 25 (network IDS) :10:48.54 Packet from to TCP RST=1, Src. Port 25 (network IDS) :10.48:58 Packet from to TCP SYN=1, Dest. Port 25 (network IDS) 17. 9:10:49.07 Packet from to TCP RST=1, Src. Port 25 (network IDS) 18. Several hundred packets like 14-17, each increasing the target IP address by 1)

19. 9:14:18.52 Packet from to TCP SYN=1, Dest. Port 25 (network IDS) 20. 9:14:27.58 Packet from to TCP SYN=1, ACK=1, Src. Port 25 (NIDS) 21. 9:14:28.07 Packet from to TCP ACK=1, Dest. Port 25 (network IDS) 22. 9: Packet from to SMTP (network IDS) (This would really be several packets back and forth.) 23. 9:15:48.18 Packet from to SMTP (network IDS) (This would really be several packets back and forth.) 24. Several thousand packets similar to 22 and 23

Distributed IDS Stand-Alone Stand-Alone Host IDS (HIDS) Manager Site
Agent Log File Transfer in Batch Mode or Real Time Log File Main Border Firewall Agent 5.3. IDS Placement Where should a company place its IDSs? Figure 5.5. shows that there are two main choices. Network IDSs (NIDSs) First, network IDSs (NIDSs), as their name suggests, are placed on the network. This allows them to read traffic going to and from multiple internal and external hosts. Unfortunately, NIDSs only see the traffic passing through their locations. In modern switched networks, this is limiting. Placing a NIDS at the border is attractive, because it will see all attacks coming through the Internet. However, internal monitoring is also needed. Early LAN switches created problems for NIDSs because these switches only allowed a NIDS to monitor a single port on the switch. Most core switches, however, permit an IDS to sample traffic from any port or from all ports simultaneously. There are several types of IDSs available today, characterized by different monitoring and analysis approaches. Each approach has distinct advantages and disadvantages. All approaches can be described in terms of a generic process model for IDSs. Host IDSs (HIDSs) Second, host IDSs (HIDSs) are placed on individual hosts, usually servers. HIDSs are attractive because they will filter traffic even if a host is in a network blind spot where no NIDS can see the traffic. HIDSs always work. Another advantage of a HIDS is that it can be precisely tuned. For instance, on a Unix mail server running the SENDMAIL mail server program, only rules for filtering SMTP and POP or IMAP need to be considered, and rules specific to other host operating systems and mail programs can be turned off. On the negative side, HIDSs only see a single host. If a company tries to remedy this situation my installing HIDSs on many or all of its servers, the purchase cost management labor can become considerable. Distributed IDSs Given the relative advantages and disadvantages of NIDSs and HIDSs, larger firms often select “all of the above.” Figure 25 shows a distributed IDS with multiple host IDSs and network IDSs. Individual NIDSs and HIDSs in the system have agents that communicate with a central IDS manager. Whether or nor agents store their log files locally, they send their log entries to the manager for placement in an integrated log file for analysis. It is most efficient to send groups of log entries in periodic batch transfers. However, if an attacker takes over a computer, one of their first actions is likely to be to delete IDS log files and disable the IDS. This effectively destroys log entries that could be used to understand how the attacker got access to the system. In contrast to batch transfers, real-time transfers send each log file as it is created. This is less efficient than batch transfers, but real-time transfer is effective in preserving log entries during attacks. (One of the first things an attacker does is to delete log files on a compromised computer.) Agent Stand-Alone Network IDS (NIDS) (Inside Firewall) Internal Switch-Based Network IDS (NIDS) Stand-Alone Network IDS (NIDS) (Outside Firewall)

Major types of IDSs: Information Sources: the different sources of event information used to determine whether an intrusion has taken place. These sources can be drawn from different levels of the system, with network, host, and application monitoring. Analysis: the part of intrusion detection systems that actually organizes and makes sense of the events derived from the information sources, deciding when those events indicate that intrusions are occurring or have already taken place. The most common analysis approaches are misuse detection and anomaly detection. Response: the set of actions that the system takes once it detects intrusions. These are typically grouped into active and passive measures, with active measures involving some automated intervention on the part of the system, and passive measures involving reporting IDS findings to take action based on those reports 5.4. Major types of IDSs: IDS and IPS types depend on the following parameters Information Sources: the different sources of event information used to determine whether an intrusion has taken place. These sources can be drawn from different levels of the system, with network, host, and application monitoring. Analysis: the part of intrusion detection systems that actually organizes and makes sense of the events derived from the information sources, deciding when those events indicate that intrusions are occurring or have already taken place. The most common analysis approaches are misuse detection and anomaly detection. Response: the set of actions that the system takes once it detects intrusions. These are typically grouped into active and passive measures, with active measures involving some automated intervention on the part of the system, and passive measures involving reporting IDS findings to take action based on those reports

IDS Architecture: The architecture of IDS refers to how the functional components of the IDS are arranged with respect to each other. The primary architectural components are: The Host The system on which the IDS software runs The Target the system that the IDS are monitoring for problems.. 5.5. IDS Architecture: The architecture of IDS refers to how the functional components of the IDS are arranged with respect to each other. The primary architectural components are: The Host The system on which the IDS software runs The Target the system that the IDS are monitoring for problems.. Host-Target Co-location: IDSs may ran on the systems they protected. This was due to the fact that most systems were mainframe systems, and the cost of computers made a separate IDS is high. This presented a problem from a security point of view, as any attacker that successfully attacked the target system could simply disable the IDS as an integral portion of the attack. Host-Target Separation: With the advent of workstations and personal computers, most IDS architects moved towards running the IDS control and analysis systems on a separate system, hence separating the IDS host and target systems. This improved the security of the IDS as this made it much easier to hide the existence of the IDS from attackers Goals: There are two overarching goals stated for IDS: Accountability: Accountability is the capability to link a given activity or event back to the party responsible for initiating it. This is essential to bring criminal charges against an attacker. Accountability is difficult in TCP/IP networks, where the protocols allow attackers to forge the identity of source addresses or other source identifiers. It is also extremely difficult to enforce accountability in any system that employs weak identification and authentication mechanisms. Response: Response is the capability to recognize a given activity or event as an attack and then taking action to block or otherwise affect its ultimate goal. The goal statement associated with response is “I don’t care who attacks my system as long as I can recognize that the attack is taking place and block it.” Note that the requirements of detection are quite different for response than for accountability.

IDS Centralized Control Strategy:
5.6. IDS Control Strategy: Control Strategy describes how the elements of an IDS is controlled, and how the input and output of the IDS is managed. As shown in Fig a,b,c there are 3 strategies to control the IDS: 1) Centralized: Fig. 5.6.a. Under centralized control strategies, all monitoring, detection and reporting is controlled directly from a central location. 2) Partially Distributed IDS Fig. 5.6.b. Monitoring and detection is controlled from a local control node, with hierarchical reporting to one or more central location(s). 3) Fully Distributed IDS Fig. 5.6.c: Monitoring and detection is done using an agent-based approach, where response decisions are made at the point of analysis

IDS Partially Distributed Control Strategy:

IDS Fully Distributed Control Strategy:

Timing Timing refers to the elapsed time between the events that are monitored and the analysis of those events. Interval-Based (Batch Mode) In interval-based IDSs, the information flow from monitoring points to analysis engines is not continuous. The information is handled in a fashion similar to “store and forward” communications schemes. Many early host-based IDSs used this timing scheme, as they relied on OS audit trails, which were generated as files. Interval based IDSs are precluded from performing active responses. Real-Time (Continuous) Real-time IDSs operate on continuous information feeds from information sources. This is the predominant timing scheme for network based IDSs, which gather information from network traffic streams. In this document, we use the term “real-time” as it is used in process control situations. This means that detection performed by “real-time” IDS yields results quickly enough to allow the IDS to take actions. 5.7. IDS Timing Control Strategy: Timing refers to the elapsed time between the events that are monitored and the analysis of those events. 1) Interval-Based (Batch Mode) In interval-based IDSs, the information flow from monitoring points to analysis engines is not continuous. The information is handled in a fashion similar to “store and forward” communications schemes. Many early host-based IDSs used this timing scheme, as they relied on OS audit trails, which were generated as files. Interval based IDSs are precluded from performing active responses. 2) Real-Time (Continuous) Real-time IDSs operate on continuous information feeds from information sources. This is the predominant timing scheme for network based IDSs, which gather information from network traffic streams. In this document, we use the term “real-time” as it is used in process control situations. This means that detection performed by “real-time” IDS yields results quickly enough to allow the IDS to take actions.

Information Sources The most common way to classify IDSs is to group them by information source. Some IDSs analyze network packets, captured from network backbones or LAN segments (DMZ) , to find attackers. Other IDSs analyze information sources generated by the OS or application software for signs of intrusion. 5.8. IDS Information Sources: The most common way to classify IDSs is to group them by information source. Some IDSs analyze network packets, captured from network backbones or LAN segments (DMZ) , to find attackers. Other IDSs analyze information sources generated by the OS or application software for signs of intrusion.

NIDS and HIDS Stand-Alone Stand-Alone Host IDS (HIDS) Manager Site
Agent Log File Transfer in Batch Mode or Real Time Log File Main Border Firewall Agent 5.10. Network-Based IDSs (NIDS) Figure 5.7. shows that there are two main choices. NIDS and HIDS 1) Definition of Network IDSs (NIDSs): The majority of commercial IDS are network based. These IDSs detect attacks by capturing and analyzing network packets. Listening on a network segment or switch, one network-based IDS can monitor the network traffic affecting multiple hosts that are connected to the network segment, thereby protecting those hosts. Network-based IDSs often consist of a set of single-purpose sensors or hosts placed at various points (DMZ) in a network. These units monitor network traffic, performing local analysis of that traffic and reporting attacks to a central management console. As the sensors are limited to running the IDS, they can be more easily secured against attack. Many of these sensors are designed to run in “hide” mode, in order to make it more difficult for an attacker to determine their presence and location. 2) Advantages of Network-Based IDSs: A few well-placed network-based IDSs can monitor a large network. The deployment of network-based IDSs has little impact upon an existing network. Network-based IDSs are usually passive devices that listen on a network wire without interfering with the normal operation of a network. Thus, it is usually easy to include network-based IDSs with minimal effort. Network-based IDSs can be made very secure against attack and even made invisible to many attackers. 3) Disadvantages of Network-Based IDSs: Network-based IDSs may have difficulty processing all packets in a large or busy network and may fail to recognize an attack launched during periods of high traffic. Some vendors implement IDSs in hardware, which is much faster. The need to analyze packets quickly also forces vendors to both detect fewer attacks and also detect attacks with as little computing resource as possible, which can reduce detection effectiveness. Many of the advantages of network-based IDSs don’t apply to more modern switch-based networks. Switches subdivide networks into many small segments and provide dedicated links between hosts serviced by the same switch. Most switches do not provide universal monitoring ports and this limits the monitoring range of a network-based IDS sensor to a single host. Even when switches provide such monitoring ports, often the single port cannot mirror all traffic traversing the switch. Network-based IDSs cannot analyze encrypted information. This problem is increasing as organizations (and attackers) use VPN. Most network-based IDSs cannot tell whether or not an attack was successful; they can only detect that an attack was initiated. This means that after a network-based IDS detects an attack, administrators must manually investigate each attacked host to determine whether it was indeed penetrated. Some network-based IDSs have problems dealing with network based attacks that involve fragmenting packets. These malformed packets cause the IDSs to become unstable and crash. Agent Stand-Alone Network IDS (NIDS) (Inside Firewall) Internal Switch-Based Network IDS (NIDS) Stand-Alone Network IDS (NIDS) (Outside Firewall)

NIDS and HIDS Stand-Alone Stand-Alone Host IDS (HIDS) Manager Site
Agent Log File Transfer in Batch Mode or Real Time Log File Main Border Firewall Agent 5.11. Host -Based IDSs (HIDS) Figure 5.7. again shows that there are two main choices. NIDS and HIDS Definition of HIDS: Host-based IDSs operate on information collected from within an individual computer system. This point allows host based IDSs to analyze activities with great reliability and precision, determining exactly which processes and users are involved in a particular attack on the OS. Host-based IDSs can “see” the outcome of an attempted attack, as they can directly access and monitor the data files and system processes usually targeted by attacks. Host-based IDSs utilize information sources of two types, OS audit trails, and system logs. OS audit trails are usually generated at the kernel level of the OS, and are therefore more detailed and better protected than system logs. System logs are much smaller than audit trails. Some host-based IDSs are designed to support a centralized IDS management and reporting infrastructure that can allow a single management console to track many hosts. Others generate messages in formats that are compatible with NMS. 2) Advantages of Host-Based IDSs Host-based IDSs, with their ability to monitor events local to a host, can detect attacks that cannot be seen by a network-based IDS. Host-based IDSs can often operate in an environment in which network traffic is encrypted, when the host-based information sources are generated before data is encrypted and/or after the data is decrypted at the destination host Host-based IDSs are unaffected by switched networks. When Host-based IDSs operate on OS audit trails, they can help detect Trojan horse or other attacks that involve software integrity breaches. These appear as inconsistencies in process execution. 3) Disadvantages of Host-Based IDS: Host-based IDSs are harder to manage, as information must be configured and managed for every host monitored. Since the information sources reside on the host targeted by attacks, the IDS may be attacked and disabled by the attack. Host-based IDSs are not well suited for detecting network scans or other such surveillance that targets an entire network, because IDS only sees network packets received by its host. Host-based IDSs can be disabled by certain DOS. When host-based IDSs use OS audit trails as an information source, the amount of information can be huge, requiring additional local storage on the system. Host-based IDSs use the computing resources of the hosts they are monitoring, therefore inflicting the performance. Agent Stand-Alone Network IDS (NIDS) (Inside Firewall) Internal Switch-Based Network IDS (NIDS) Stand-Alone Network IDS (NIDS) (Outside Firewall)

Application-Based IDSs
Application-based IDSs are a special subset of host-based IDSs that analyze the events transpiring within a software application. The most common information sources used by application-based IDSs are the application’s transaction log files. The ability to interface with the application directly, with significant domain or application-specific knowledge included in the analysis engine, allows application-based IDSs to detect suspicious behavior due to authorized users exceeding their authorization. This is because such problems are more likely to appear in the interaction between the user, the data, and the application. 5.12. Application -Based IDSs: Definition of Application -Based IDSs: Application-based IDSs are a special subset of host-based IDSs that analyze the events transpiring within a software application. The most common information sources used by application-based IDSs are the application’s transaction log files. The ability to interface with the application directly, with significant domain or application-specific knowledge included in the analysis engine, allows application-based IDSs to detect suspicious behavior due to authorized users exceeding their authorization. This is because such problems are more likely to appear in the interaction between the user, the data, and the application. 2) Advantages of Application-Based IDSs: Application-based IDSs can monitor the interaction between user and application, which allows them to trace unauthorized activity to individual users. Application-based IDSs can often work in encrypted environments, since they interface with the application at transaction endpoints, where information is presented to users in unencrypted form. 3) Disadvantages of Application-Based IDSs: Application-based IDSs may be more unprotected than host-based IDSs to attacks as the applications logs are not as well protected as the OS audit trails used for host-based IDSs. As Application-based IDSs monitor events at the user level of abstraction, they usually cannot detect Trojan horse or other software tampering attacks. Therefore, it is advisable to use Application-based IDS in combination with Host-based and/or Network-based IDSs.

Deploying Network-Based IDSs
5.13. Deploying IDSs Intrusion detection Security Technology (Measures or Tools) is a necessary addition to every large organization’s computer network security infrastructure. Given the importance of today’s IDS products, and the limited security skill level of many system administrators, an effective IDS deployment requires careful planning, preparation, prototyping, testing, and specialized training. It is important to perform a thorough requirements analysis, carefully selecting the intrusion detection strategy and solution that is compatible with the organization’s network infrastructure, policies, and resource level. Deploying Network-Based IDSs: Fig. 5.8. One question that arises when deploying network-based IDSs is where to locate the system sensors. There are many options for placing a network-based IDS with different advantages associated with each: 1) Location 1: Behind each external firewall, in the network DMZ Advantages: Sees attacks, originating from the outside world, that penetrates the network’s defenses. Highlights problems with the network firewall policy or performance Sees attacks that might target the web server or ftp server, which commonly reside in this DMZ Even if the incoming attack is not recognized, the IDS can sometimes recognize the outgoing traffic that results from the compromised server 2) Location: Outside an external firewall (Location 2) Documents number of attacks originating on the Internet that targets the network. 3) On major network backbones: (Location 3) Monitors a large amount of a network’s traffic, thus increasing the possibility of spotting attacks. Detects unauthorized activity by authorized users within the organization’s security perimeter. 4) Location: On critical subnets (Location 4) Detects attacks targeting critical systems and resources. Allows focusing of limited resources to the network assets considered of greatest value. Deploying Host -Based IDSs: Once network-based IDSs are operational, the addition of host-based IDSs can offer enhanced levels of protection. Installing host-based IDSs on every host can be time-consuming, as each IDS has to be installed and configured for each specific host. It is recommend that organizations first install host-based IDSs on critical servers. This will decrease overall deployment costs and allow to focus on alarms generated from the most important hosts. Once the operation of host based IDSs are routine, more security-conscious organizations may consider installing host-based IDSs on the majority of their hosts. In this case, purchase host-based systems that have centralized management and reporting functions. These features will significantly reduce the complexity of managing alerts from a large set of hosts.

Strengths of Intrusion Detection Systems
Monitoring and analysis of system events and user behaviors Testing the security states of system configurations Base lining the security state of a system, then tracking any changes to that baseline Recognizing patterns of system events that correspond to known attacks Recognizing patterns of activity that statistically vary from normal activity 5.14: Strengths and Limitations of Intrusion Detection Systems 1) Strengths of Intrusion Detection Systems Monitoring and analysis of system events and user behaviors Testing the security states of system configurations Base lining the security state of a system, then tracking any changes to that baseline Recognizing patterns of system events that correspond to known attacks Recognizing patterns of activity that statistically vary from normal activity Managing OS audit and logging mechanisms and the data they generate Alerting appropriate staff by appropriate means when attacks are detected. Measuring enforcement of security policies encoded in the analysis engine Providing default information security policies Allowing non-security experts to perform important security monitoring functions. 2) Limitations of Intrusion Detection Systems Intrusion detection systems cannot perform the following functions: Compensating for weak or missing security mechanisms in the protection infrastructure. Such mechanisms include firewalls, identification and authentication, link encryption, access control mechanisms, and virus detection and eradication. Instantaneously detecting, reporting, and responding to an attack, when there is a heavy network or processing load. Detecting newly published attacks or variants of existing attacks. Effectively responding to attacks launched by sophisticated attackers Automatically investigating attacks without human intervention. Resisting attacks that are intended to defeat them Compensating for problems with the fidelity of information sources Dealing effectively with switched networks.

Typical IDS Output Almost all IDSs will output a small summary line about each detected attack: Time/date, Sensor IP address, Vendor specific attack name, Standard attack name (if one exists), Source and destination IP address, Source and destination port numbers Network protocol used by attack. 5.15: Typical IDS Output Almost all IDSs will output a small summary line about each detected attack: Time/date, Sensor IP address, Vendor specific attack name, Standard attack name (if one exists), Source and destination IP address, Source and destination port numbers Network protocol used by attack. Many IDSs will also provide a generic description of each type of attack with following information: Text description of attack, Attack severity level, Type of loss experienced as a result of the attack, The type of vulnerability the attack exploits, List of software types and version numbers that are vulnerable to the attack, Patch/cover information so that computers can resist the attack References to public advisories about the attack or the vulnerability it exploits.

Handling Attacks Text description of attack, Attack severity level,
Type of loss experienced as a result of the attack, The type of vulnerability the attack exploits, List of software types and version numbers that are vulnerable to the attack, Patch/cover information so that computers can resist the attack References to public advisories about the attack or the vulnerability it exploits. 5.16. Handling Attacks: Many IDSs will also provide a generic description of each type of attack with following information: Text description of attack, Attack severity level, Type of loss experienced as a result of the attack, The type of vulnerability the attack exploits, List of software types and version numbers that are vulnerable to the attack, Patch/cover information so that computers can resist the attack References to public advisories about the attack or the vulnerability it exploits. Make provisions to conduct periodic tests (similar to fire drills) of the procedures, in which all organizational parties step through their specific responsibilities and assignments. Train IDS operators on the organization’s Incident Handling Procedure. If the Procedure predates the addition of the IDS to the security infrastructure, consider taking the time to revisit it, amending it to reflect the role of the IDS.

Types of Computer Attacks Detected by IDSs
Three types of computer attacks are most commonly reported by IDSs: System scanning Denial of service (DOS) System penetration. These attacks can be launched locally, on the attacked machine, or remotely, using a network to access the target. An IDS operator must understand the differences between these types of attacks, as each requires a different set of responses. 5.17.Types of Computer Attacks Commonly Detected by IDSs Three types of computer attacks are most commonly reported by IDSs: System scanning Denial of service (DOS) System penetration. These attacks can be launched locally, on the attacked machine, or remotely, using a network to access the target. An IDS operator must understand the differences between these types of attacks, as each requires a different set of responses. 1) Scanning Attacks A scanning attack occurs when an attacker probes a target network or system by sending different kinds of packets. (This is similar to the activity described in Section , regarding network-based vulnerability analysis tools. Indeed, the techniques may be identical, but the motive for performing the activity is quite different!) Using the responses received from the target, the attacker can learn many of the system’s characteristics and vulnerabilities. Thus, a scanning attack acts as a target identification tool for an attacker. Scanning attacks do not penetrate or otherwise compromise systems. Various names for the tools used to perform these activities include: network mappers port mappers network scanners port scanners vulnerability scanners. Scanning attacks may yield: The topology of a target network The types of network traffic allowed through a firewall The active hosts on the network The operating systems those hosts are running The server software they are running The software version numbers for all detected software Vulnerability scanners are a special type of scanner that checks for specific vulnerabilities in hosts. Thus, an attacker can run a vulnerability scanner and it will output a list of hosts (IP addresses) that are likely to be vulnerable to a specific attack. With this information, an attacker can precisely identify victim systems on the target network along with specific attacks that can be used to penetrate those systems. Thus, attackers use scanning software to “case” a target before launching a real attack. Unfortunately for victims, just as it is legal for a person to enter a bank and to survey the visible security system, some lawyers say that it is legal for an attacker to scan a host or network. From the perspective of someone performing a scan, they are legally scouring the Internet to find publicly accessible resources. There are legitimate justifications for scanning activity. Web search engines may scan the Internet looking for new web pages. An individual may scan the Internet looking for free music repositories or for publicly accessible multi-user games. Fundamentally, the same kind of Security Technology (Measures or Tools) that allows one to discover publicly available resources also allows one to analyze a system for security weaknesses (as occurs, as mentioned above, when one uses vulnerability assessment tools). The best IDS signatures for malicious scanning are usually able to discern between legitimate and malicious scanning. Scanning is likely the most common attack as it is the precursor to any serious penetration attempt. If your network is connected to the Internet, it is almost certain that you are scanned, if not daily, at least a couple of times a week. 2) Denial of Service Attacks Denial Of Service (DOS) attacks attempt to slow or shut down targeted network systems or services. In certain Internet communities, DOS attacks are common. For example, Internet Relay Chat users engaged in verbal disputes commonly resort to DOS attacks to win arguments with their opponents. While often used for such trivial purposes, DOS attacks can also be used to shut down major organizations. In well publicized incidents, DOS attacks were charged with causing major losses to electronic commerce operations, whose customers were unable to access them to make purchases. There are two main types of DOS attacks: flaw exploitation and flooding. It is important for an IDS operator to understand the difference between them. a. Flaw exploitation DOS Attacks Flaw exploitation attacks exploit a flaw in the target system’s software in order to cause a processing failure or to cause it to exhaust system resources. An example of such a processing failure is the ‘ping of death’ attack. This attack involved sending an unexpectedly large ping packet to certain Windows systems. The target system could not handle this abnormal packet, and a system crash resulted. With respect to resource exhaustion attacks, the resources targeted include CPU time, memory, disk space, space in a special buffer, or network bandwidth. In many cases, simply patching the software can circumvent this type of DOS attack. b. Flooding DOS Attacks Flooding attacks simply send a system or system component more information than it can handle. In cases where the attacker cannot send a system sufficient information to overwhelm its processing capacity, the attacker may nonetheless be able to monopolize the network connection to the target, thereby denying anyone else use of the resource. With these attacks, there is no flaw in the target system that can be patched. This is why such attacks represent a major source of frustration and concern to organizations. While there are few general solutions to stop flooding attacks, there are several technical modifications that can be made by a target to mitigate such an attack. The term “distributed DOS” (DDOS) is a subset of DOS attacks. DDOS attacks are simply flooding DOS attacks where the attacker uses multiple computers to launch the attack. These attacking computers are centrally controlled by the attacker’s computer and thus act as a single immense attack system. An attacker cannot usually bring down a major ecommerce site by flooding it with network packets from a single host. However, if an attacker gains control of 20,000 hosts and subverts them to run an attack under his direction, then the attacker has a formidable capability to successfully attack the fastest of systems, bringing it to a halt. 3) Penetration Attacks Penetration attacks involve the unauthorized acquisition and/or alteration of system privileges, resources, or data. Consider these integrity and control violations as contrasted to DOS attacks that violate the availability of a resource and to scanning attacks, which don’t do anything illegal. A penetration attack can gain control of a system by exploiting a variety of software flaws. The most common flaws and the security consequences of each are explained and enumerated below. While penetration attacks vary tremendously in details and impact, the most common types are: User to Root: A local user on a host gains complete control of the target host Remote to User: An attacker on the network gains access to a user account on the target host Remote to Root: An attacker on the network gains complete control of the target host Remote Disk Read: An attacker on the network gains the ability to read private data files on the target host without the authorization of the owner Remote Disk Write: An attacker on the network gains the ability to write to private data files on the target host without the authorization of the owner 4) Remote vs. Local Attacks DOS and penetration attacks come in two varieties: local and remote. a. Authorized User Attack: Authorized user attacks are those that start with a legitimate user account on the target system. Most authorized user attacks involve some sort of privilege escalation. b. Public User Attack: Public user attacks, on the other hand, are those launched without any user account or privileged access to the target system. Public user attacks are launched remotely through a network connection using only the public access granted by the target. One typical attack strategy calls for an attacker to use a public user attack to gain initial access to a system. Then, once on the system, the attacker uses authorized user attacks to take complete control of the target. 5) Determining Attacker Location from IDS Output In notifications of a detected attack, IDSs will often report the location of a attacker. This location is most commonly expressed as an source IP address. The reported address is simply the source address that appears in the attack packets. As attackers routinely change IP addresses in attack packets, this does not necessarily represent the true source address of the attacker. The key to determining the significance of the reported source IP address is to classify the type of attack and then determine whether or not the attacker needs to see the reply packets sent by the victim. If the attacker launches a one-way attack, like many flooding DOS attacks, where the attacker does not need to see any reply packets, then the attacker can label his packets with random IP addresses. The attacker is doing the real world equivalent of sending a postcard with a fake return address to fill a mailbox so that no other mail can fit into it. In this case, the attacker cannot receive any reply from the victim. However, if the attacker needs to see the victim’s replies, which is usually true with penetration attacks, then the attacker usually cannot lie about his source IP address. Using the postcard analogy, the attacker needs to know that his postcards got to the victim and therefore must usually label his postcards with his actual address. In general, attackers must use the correct IP address when launching penetration attacks but not with DOS attacks. However, there exists one caveat when dealing with expert attackers. An attacker can send attack packets using a fake source IP address, but arrange to wiretap the victims reply to the faked address. The attacker can do this without having access to the computer at the fake address. This manipulation of IP addressing is called “IP Spoofing.” 6) IDSs and Excessive Attack Reporting Many IDS operators are overwhelmed with the number of attacks reported by IDSs. It is simply impossible for an operator to investigate the hundreds or even thousands of attacks that are reported daily by some IDSs. The underlying problem is not in the number of attacks, but how IDSs report those attacks. Some IDSs report a separate attack each time an attacker accesses a different host. Thus, an attacker scanning a subnet of a thousand hosts could trigger a thousand attack reports. Some vendors have proposed a solution to this problem. Their newest IDSs are beginning to effectively combine redundant entries and to present to the operator those attacks of highest importance first. a. Attack Naming Conventions Until recently, there was no common naming convention for computer attacks or vulnerabilities. This made it very difficult to compare the effectiveness of different IDSs as each vendor’s IDS generated a different list of results when analyzing events reflecting the same set of attacks. This also made it difficult to coordinate the use of more than one type of IDS in a network, as different IDSs would generate different messages when they detected the same attack.

Conclusion It is clear that some form of security for private networks connected to the IP Net is essential A firewall is an important and necessary part of that security, but cannot be expected to perform all the required security functions.

Distributed IDS Stand-Alone Stand-Alone Host IDS (HIDS) Manager Site
Agent Log File Transfer in Batch Mode or Real Time Log File Main Border Firewall Agent Agent Conclusion IDSs are here to stay, with billion dollar firms supporting the development of commercial security products and driving hundreds of millions in annual sales. However, they remain difficult to configure and operate and often can’t be effectively used by the very novice security personnel who need to benefit from them most. Due to the nationwide shortage of experienced security experts, many novices are assigned to deal with the IDSs that protect our nation’s computer systems and networks. Our intention, in writing this document, is to help those who would take on this task. We hope that this publication, in providing actionable information and advice on the topics, serves to acquaint novices with the world of IDSs and computer attacks. The information provided in this bulletin is by no means complete and we recommend further reading and formal training before one takes on the task of configuring and using an intrusion detection system. Stand-Alone Network IDS (NIDS) (Inside Firewall) Internal Switch-Based Network IDS (NIDS) Stand-Alone Network IDS (NIDS) (Outside Firewall)

Many thanks

IP Cyber Security Unit 2: Firewalls. IP Cyber Security Unit 2: Firewalls.

Similar presentations

Presentation on theme: "IP Cyber Security Unit 2: Firewalls. IP Cyber Security Unit 2: Firewalls."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

IP Cyber Security Unit 2: Firewalls. IP Cyber Security Unit 2: Firewalls.

Similar presentations

Presentation on theme: "IP Cyber Security Unit 2: Firewalls. IP Cyber Security Unit 2: Firewalls."— Presentation transcript:

Similar presentations

About project

Feedback