CSE543 - Computer and Network Security Module:...

CMPSC443 - Introduction to Computer and Network Security Page

CSE543 - Computer and Network SecurityModule: Firewalls

Professor Trent Jaeger

1Thursday, October 31, 13


Problem• All network flows were possible‣ Into or out of our network‣ To/from individual hosts and their processes‣ We need to control access to protect confidentiality, integrity

and secrecy• What mechanism do we need?



Firewalls• A firewall ... is a physical barrier inside a building or

vehicle, designed to limit the spread of fire, heat and structural collapse.



Filtering: Firewalls• Filtering traffic based on policy‣ Policy determines what is acceptable traffic‣ Access control over traffic‣ Accept or deny

• May perform other duties‣ Logging (forensics, SLA)‣ Flagging (intrusion detection)‣ QoS (differentiated services)

Application

Network

Link



X-Listing•Blacklisting - specifying specific connectivity that

is explicitly disallowed‣ E.g., prevent connections from badguys.com

•Whitelisting - specifying specific connectivity that explicitly allowed‣ E.g., allow connections from goodguys.com

• These is useful for IP filtering, SPAM mitigation, …• Q: What access control policies do these

represent?



Stateful, Proxy, and Transparent • Single packet may not contain sufficient data to

make access control decision‣ Stateful: allows historical context consideration

‣ Firewall collects data over time• e.g., TCP packet is part of established session

• Firewalls can affect network traffic‣ Transparent: appear as a single router (network)

‣ Proxy: receives, interprets, and reinitiates communication (application)

‣ Transparent good for speed (routers), proxies good for complex state (applications)



DMZ (De-militarized Zone)

(servers)

LANInternet LAN

• Zone between LAN and Internet (public facing)



Practical Issues and Limitations• Network layer firewalls are dominant‣ DMZs allow multi-tiered fire-walling‣ Tools are widely available and mature‣ Personal firewalls gaining popularity

• Issues‣ Network perimeters not quite as clear as before

• E.g., telecommuters, VPNs, wireless, …

‣ Every access point must be protected• E.g., this is why war-dialing/driving is effective

‣ Hard to debug, maintain consistency and correctness‣ Often seen by non-security personnel as impediment

• E.g., Just open port X so I can use my wonder widget …



IP Firewall Policy• Specifies what traffic is (not) allowed‣ Maps attributes to address and ports

‣ Example: HTTP should be allowed to any external host, but inbound only to web-server



Practical Firewall Implementations• Primary task is to filter packets‣ But systems and requirements are complex

• Consider‣ All the protocols and services‣ Stateless vs. stateful firewalls‣ Network function: NAT, forwarding, etc.

• Practical implementation: Linux iptables‣ http://www.netfilter.org/documentation/HOWTO/packet-

filtering-HOWTO.html‣ http://linux.web.cern.ch/linux/scientific3/docs/rhel-rg-en-3/ch-

iptables.html10

Thursday, October 31, 13

http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html




http://linux.web.cern.ch/linux/scientific3/docs/rhel-rg-en-3/ch-iptables.html





Netfilter hook• Series of hooks in Linux network protocol stack • An iptable rule set is evaluated at each‣ “PREROUTING”: before routing ‣ “INPUT”: inbound to local destination‣ “FORWARD”: inbound but routed off host‣ “OUTPUT”: outbound to remote destination‣ “POSTROUTING”: after routing

11

Preroute

Input

Forward PostrouteRouting

Output



iptables Concepts

• Table: all the firewall rules• Chain: list of rules associated with the chain identifier, e.g.,

hook name• Match: when all a rule’s field match the packet• Target: operation to execute on a packet given a match

12

The iptables firewall looks in the firewall table to seek if a rule in the chain associated with the current hook matches a packet, and executes the rule’s target if it does.



iptables Commands

• Commands‣ Append rule to end or specific location in chain‣ Delete a specific rule in a chain‣ Flush a chain‣ List a chain ‣ Create a new user-specified chain‣ Replace a rule

• plist is a rule spec

13

iptables [-t <table_name>] <cmd> <chain> <plist>



iptables Rule Parameters• Things you can match on ‣ Destination/Source

• IP address range and netmask

‣ Protocol of packet• ICMP, TCP, etc

‣ Incoming/outgoing interface‣ Fragmented only‣ Target on rule match



Test it out• PING on localhost‣ ping -c 1 127.0.0.1

• Add iptables rule to block‣ iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP

• Try ping• Delete the rule‣ iptables -D INPUT 1‣ iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP‣ iptables -F INPUT



Testing• Use loopback to test the rules locally on your machine‣ IP address 127.0.0.1

• ICMP‣ submit ping requests to 127.0.0.1 as above

• TCP‣ submit requests to 127.0.0.1 at specific port‣ server

• nc -l -p 3750• listen at port 3750

‣ client • nc -p 3000 localhost 3750• send from port 3000 to localhost at port 3750



Per Protocol Options• Specialized matching options for rules‣ Specific to protocol

• TCP‣ Source/destination ports‣ SYN‣ TCP flags



Targets• Define what to do with the packet at this time

• ACCEPT/DROP

• QUEUE for user-space application

• LOG any packet that matches

• REJECT drops and returns error packet

• RETURN enables packet to return to previous chain

• <user-specified> passes packet to that chain



Examples iptables -A INPUT -s 200.200.200.2 -j ACCEPT

iptables -A INPUT -s 200.200.200.1 -j DROP

iptables -A INPUT -s 200.200.200.1 -p tcp -j DROP

iptables -A INPUT -s 200.200.200.1 -p tcp --dport telnet -j DROP

iptables -A INPUT -p tcp --destination-port telnet -i ppp0 -j DROP



Deep Packet Inspection• Deep packet inspection looks into the internals of a pack

to look for some application/content context‣ e.g., inspect HTTP for URLs that point to malicious websites‣ Can have serious privacy issues if done by, say COMCAST

• To specify a match in iptables‣ iptables -A INPUT -p tcp -m string --algo bm --string ‘exe’

• matches to packet with content containing ‘exe’

‣ iptables -A INPUT -p tcp -m length --length 10:100 • matches to packet with length between 10 and 100 bytes• Also, can specify ‘greater than 10’ by 10:



Firewall Policy Design• So, what is the problem with the firewall rules...

• This may be a simple problem, but • Rules now have complex actions ‣ What kind of rules can we write in iptables?

• Including stateful rules that we did not discuss

21

FIREMAN: A Toolkit for FIREwall Modeling and ANalysis

Lihua [email protected]

Jianning [email protected]

Zhendong [email protected]

Hao [email protected]

Chen-Nee [email protected]

Prasant [email protected]

University of California, Davis

Abstract

Security concerns are becoming increasingly critical innetworked systems. Firewalls provide important defense fornetwork security. However, misconfigurations in firewallsare very common and significantly weaken the desired se-curity. This paper introduces FIREMAN, a static analysistoolkit for firewall modeling and analysis. By treating fire-wall configurations as specialized programs, FIREMAN ap-plies static analysis techniques to check misconfigurations,such as policy violations, inconsistencies, and inefficien-cies, in individual firewalls as well as among distributedfirewalls. FIREMAN performs symbolic model checking ofthe firewall configurations for all possible IP packets andalong all possible data paths. It is both sound and completebecause of the finite state nature of firewall configurations.FIREMAN is implemented by modeling firewall rules usingbinary decision diagrams (BDDs), which have been usedsuccessfully in hardware verification and model checking.We have experimented with FIREMAN and used it to un-cover several real misconfigurations in enterprise networks,some of which have been subsequently confirmed and cor-rected by the administrators of these networks.

1. Introduction

Firewall is a widely deployed mechanism for improvingthe security of enterprise networks. However, configuringa firewall is daunting and error-prone even for an experi-enced administrator. As a result, misconfigurations in fire-walls are common and serious. In examining 37 firewalls inproduction enterprise networks in 2004, Wool found thatall the firewalls were misconfigured and vulnerable, andthat all but one firewall were misconfigured at multipleplaces [31]. As another evidence, Firewall Wizards Secu-rity Mailing List [15] has discussed many real firewall mis-

configurations. The wide and prolonged spread of worms,such as Blaster and Sapphire, demonstrated that many fire-walls were misconfigured, because “well-configured fire-walls could have easily blocked them” [31].

The following script illustrates how easily firewall mis-configurations can happen:

accept tcp 192.168.0.0/16 anydeny tcp 192.168.1.0/24 any 3127

The second rule is configured to deny all the outbound traf-fic to a known backdoor TCP port for the MyDoom.A worm,and is correct by itself. However, if a firewall examineseach rule sequentially and accepts (or rejects) a packet im-mediately when the packet is matched to a rule, a preced-ing rule may shadow subsequent rules matching some com-mon packets. The first rule, which accepts all the outboundtraffic from the local network 192.168.0.0/16, shadows thesecond rule and leaves the hole wide open.

Correctly configuring firewall rules has never been aneasy task. In 1992, Chapman [6] discussed many problemsthat make securely configuring packet filtering a dauntingtask. Some of them, e.g., omission of port numbers infiltering rules, have been addressed by firewall vendors.However, many others are yet to be addressed successfully.Since firewall rules are written in platform-specific, low-level languages, it is difficult to analyze whether these ruleshave implemented a network’s high-level security policiesaccurately. Particularly, it is difficult to analyze the inter-actions among a large number of rules. Moreover, whenlarge enterprises deploy firewalls on multiple network com-ponents, due to dynamic routing, a packet from the samesource to the same destination may be examined by a dif-ferent set of firewalls at different times. It is even moredifficult to reason whether all these sets of firewalls satisfythe end-to-end security policies of the enterprise.

We propose to use static analysis to discover firewallmisconfigurations. Static analysis has been applied success-

Proceedings of the 2006 IEEE Symposium on Security and Privacy (S&P’06) 1081-6011/06 $20.00 © 2006 IEEE



FIREMAN• Static analysis tool for detecting incorrect, inefficient,

or inconsistent firewall rules‣ Using something called binary decision diagrams

• Finds real misconfigurations‣ Classify misconfigurations‣ Applies intra-, inter-, and across firewalls



Misconfigurations• Violations‣ What is the security goal?

• Inconsistencies (possibly between firewalls)‣ Shadowing: Accepts (denies) packets already denied

(accepted)‣ Generalization: Matches superset of preceding, but takes a

different action‣ Correlation: Matches subset of preceding, but takes a

different action

• Inefficiencies ‣ Redundancy: Remove rule and no change‣ Verbosity: Summarize with fewer rules



Analysis• What is static analysis?‣ Analyze without running program (firewall rules)‣ Use code, approximate all possible executions at once

• E.g., track all packets that have been accepted (A), denied (D), diverted (F) at each rule - remaining (R) is implied

• Firewall rules are translated into a rule graph‣ Linear for one rule sequence‣ Firewalls form a tree relative to target

• Problems detected by comparing sets (A, D, F, R, P)‣ (Pj, Deny) where Pj subset Aj - shadowing‣ (Pj, Deny) where Pj intersect Aj = NULL - redundant

• Implemented as a BDD24



Take Away• A firewall is an authorization mechanism for network

flows‣ Control packet flows to subnets, hosts, ports‣ Scan a rulebase for matching rule for packet

• Like Windows ACLs, but with default accept

• We examined the Linux iptables firewall‣ Netfilter hooks provide complete mediation‣ Rule chains can be connected like subroutines

• However, firewall rules may be misconfigured‣ FIREMAN detects violations, inconsistencies, and inefficiencies

using static analysis of rule bases• Compare sets of packets at rule with those accepted, denied, etc.


CSE543 - Computer and Network Security Module:...

Documents

Transcript of CSE543 - Computer and Network Security Module:...