DOC PREVIEW
Berkeley COMPSCI 161 - Firewall & Network-based Intrusion Detection

This preview shows page 1-2-3-4 out of 12 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Firewall & Network-based Intrusion DetectionDawn [email protected]• Reference Monitor– Software Fault Isolation– System call interposition3How to Protect Policy Checker?• In different user process or in kernel• Relying on the trust to kernel• Can we do better?4Virtual Machine Monitors• Virtual machine: execution envrionment that gives the illusion of a real machine• VMM – sits below OS– Much smaller than OS, easier to verify/get right– Natual place to enforce security policies– Policy checker does not need to rely on OS• Examples– VMWare– Xen5Virtual Machine Introspection based Policy Enforcement6Sample Security Policies• Enforce memory access• Enforce NIC access: e.g., prevent promiscuous mode• Raw socket detector• Signature detector• Program integrity checker• Lie detector for rootkits7Summary of VMM-based Enforcement• VMM is much smaller, easier for correctness• See entire system state, powerful policies• Much higher performance overhead8Moving to yet another level• Inline reference monitor• System call interposition• VMM introspection• Can we move it to yet another level?9Network-level Security Policy Enforcement• Firewalls– Peremiter defense– Btw internet & intranet– Block traffic violating security policy– Central chokepoint uses single place to easily enforce a security policy on 1,000’s of machines» Similar to airport security – few entrancesInternetInternalNetwork10Packet Filters• Simplest kind of firewall is a packet filter– Router with list of access control rules– Router checks each received packet against security rules to decide to forward or drop it– Each rule specifies which packets it applies to based on a packet’s header fields» Specify source and destination IP addrs, port numbers, and protocol names, or wild cards» Each rule also specifies an action for matching packets: ALLOW or DROP» <ACTION> <PRTCL> <SRC:PT> -> <DEST:PT>– List of rules is examined one-by-one» First matching rule determines how packet will be handled11Security Policy based on IP Header• A TCP service is specified by machine’s IP address and TCP port number on it– Web server www.cs.berkeley.edu at 169.229.60.105, port 80– Mail service at 169.229.60.93, port 25– UDP services similarly identified• Identify each svc with triplet (m,r,p):– m is machine’s IP addr (A.B.C.D/[MASK])– r is a TCP/UDP protocol identifier– p is the port number– Example: official web servers on subnet 1.2.3.x -> add(1.2.3.0/24, TCP, 80) to allowed list12Example Ruleset• What does this ruleset do?–drop tcp *:* -> *:23–allow * *:* -> *:*• Answer: – Blocks all TCP pkts destined to port 23 (telnet)» Telnet uses cleartext passwords!– Forwards all other traffic• Problems?• No notion of a connection, or of inbound vsoutbound connections– Drops outbound telnet connections from inside users– This is a default-allow policy!!13Another Example• Want to allow:– Inbound mail connections to our mail server (1.2.3.4:25)– All outbound connections– Nothing else– Consider this ruleset:» allow tcp *:* -> 1.2.3.4:25» allow tcp {int_hosts}:* -> *:*» drop * *:* -> *:*• This policy doesn't work…– TCP connections are bidirectional– 3-way handshake: send SYN, receive SYN|ACK, send ACK, send DATA w/ACK bit14Problem: Outbound Connections Fail• Inside host opens TCP connection to port 80 on external machine:– Initial SYN packet passed through by rule 2– SYN|ACK packet coming back is dropped» Fails rule 1 (not destined for port 25)» Fails rule 2 (source not inside host)» Matches rule 3 -> DROP• Distinguish between 2 kinds of inbound pkts– Allow inbound packets associated with an outbound connection to pass– Restrict inbound packets associated with an inbound connection15Inbound versus Outbound Connections• Key idea: use a feature of TCP!– ACK bit set on all packets except first one– Recipients discard any TCP packet with ACK bit set, if packet is not associated with an existing TCP connection• Solution ruleset? – allow tcp *:* -> 1.2.3.4:25 – allow tcp {int_hosts}:* -> *:* – allow tcp *:* -> {int_hosts}:* (if ACK bit set)– drop * *:* -> *:*– Rules 1 and 3 allow inbound connections to port 25 on machine 1.2.3.4– Rules 2 and 3 allow outbound connections to any port16Example Using This Ruleset• Outside attacker trying to exploit finger service (TCP port 79) vulnerability– Tries to open an inbound TCP connection to our finger server• Attempt #1:Sends SYN pkt to int. machine– Pkt doesn’t have ACK bit set, so fw rule drops it• Attempt #2: Sends SYN|ACK pkt to internalmachine– FW permits pkt, then dropped by TCP stack (ACK bit set but isn’t part of existing connection)• We can specify policies restricting inbound connections arbitrarily17IP Spoofing: Another Security Hole• IP protocol doesn’t prevent attacker from sending pkt with wrong (spoofed) src addr– Most routers ignore src addrs• Suppose 1.2.3.7 is an internal host– Attacker sends spoofed TCP SYN packet» Src addr 1.2.3.7, dest addr target internal machine, destport 79 – rule 2 allows– Target replies with SYN|ACK pkt to 1.2.3.7 and waits for ACK (to finish 3-way handshake)– Attacker sends spoofed TCP ACK packet– Attacker then sends data packet18Attack Analysis• Attack allows connections to internal hosts– Violates of our security policy– Allows attacker to exploit any security holes» Ex: finger service vulnerability– Caveat: » Attacker has to “guess” Initial Sequence Number set by target in SYN|ACK packet sent to 1.2.3.7 (many ways to guess…)• Modified Solution – Packet filter marks each packet with incoming interface ID, and rules match IDs» Recall: Router has 2+ interfaces, forwards packets from one to another19New Solution• New ruleset– Int. interface: in, ext. interface: out– allow tcp *:*/out -> 1.2.3.4:25/in– allow tcp *:*/in -> *:*/out– allow tcp *:*/out -> *:*/in (if ACK bit set)– drop * *:* -> *:*– Allows inbound packets only if destined to 1.2.3.4:25(rule 1), or, if ACK bit set (rule 3)– Drops all other inbound packets• Clean solution: defeats IP spoofing threat– Simplifies ruleset admin (no hardcode internal hosts list)20Other Kinds of Firewalls• Packet filters are quite crude firewalls– Network level using TCP, UDP, and IP headers• Alternative: examine data field contents–


View Full Document

Berkeley COMPSCI 161 - Firewall & Network-based Intrusion Detection

Documents in this Course
Rootkits

Rootkits

11 pages

Load more
Download Firewall & Network-based Intrusion Detection
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Firewall & Network-based Intrusion Detection and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Firewall & Network-based Intrusion Detection 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?