Outline Firewalls and NAT boxes CSci 5271 Introduction to Computer - PDF document

Outline Firewalls and NAT boxes CSci 5271 Introduction to Computer Security Announcements intermission Day 22: Firewalls, NATs, and IDSes Stephen McCamant Intrusion detection systems University of Minnesota, Computer Science & Engineering Internet addition: middleboxes Security/connectivity tradeoff A lot of security risk comes from a network Original design: middle of net is only routers connection End-to-end principle Attacker could be anywhere in the world Modern reality: more functionality in the network Reducing connectivity makes security easier Security is one major driver Connectivity demand comes from end users What a firewall is Inbound and outbound control Most obvious firewall use: prevent attacks from the Basically, a router that chooses not to forward some outside traffic Often also some control of insiders Based on an a-priori policy Block malware-infected hosts More complex architectures have multiple layers Employees wasting time on Facebook DMZ : area between outer and inner layers, for Selling sensitive info to competitors outward-facing services Nation-state Internet management May want to log or rate-limit, not block Default: deny IPv4 address scarcity Design limit of ✷ ✸✷ hosts Actually less for many reasons Usual whitelist approach: first, block everything Addresses becoming gradually more scarce over a Then allow certain traffic many-year scale Basic: filter packets based on headers Some high-profile exhaustions in 2011 More sophisticated: proxy traffic at a higher level IPv6 adoption still quite low, occasional signs of progress

Network address translation (NAT) Packet filtering rules Match based on: Middlebox that rewrites addresses in packets Source IP address Main use: allow inside network to use non-unique IP Source port addresses Destination IP address Destination port RFC 1918: 10.*, 192.168.*, etc. Packet flags: TCP vs. UDP , TCP ACK, etc. While sharing one outside IP address Inside hosts not addressable from outside Action, e.g. allow or block De-facto firewall Obviously limited in specificity Client and server ports Stateful filtering In general: firewall rules depend on previously-seen traffic TCP servers listen on well-known port numbers Key instance: allow replies to an outbound Often ❁ 1024, e.g. 22 for SSH or 80 for HTTP connection Clients use a kernel-assigned random high port See: port 23746 to port 80 Plain packet filter would need to allow all high-port Allow incoming port 23746 incoming traffic To same inside host Needed to make a NAT practical Circuit-level proxying Application-level proxying Knows about higher-level semantics Firewall forwards TCP connections for inside client Long history for, e.g., email, now HTTP most Standard protocol: SOCKS important Supported by most web browsers More knowledge allows better filtering decisions Wrapper approaches for non-aware apps But, more effort to set up Not much more powerful than packet-level filtering Newer: “transparent proxy” Pretty much a man-in-the-middle Tunneling Tunneling example: HA2 Any data can be transmitted on any channel, if both sides agree E.g., encapsulate IP packets over SSH connection Compare covert channels, steganography Powerful way to subvert firewall Some legitimate uses

Outline Note to early readers Firewalls and NAT boxes This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make sure you have the latest slides for announcements Intrusion detection systems Outline Basic idea: detect attacks The worst attacks are the ones you don’t even know Firewalls and NAT boxes about Best case: stop before damage occurs Announcements intermission Marketed as “prevention” Still good: prompt response Intrusion detection systems Challenge: what is an attack? Network and host-based IDSes Signature matching Network IDS: watch packets similar to firewall Signature is a pattern that matches known bad But don’t know what’s bad until you see it behavior More often implemented offline Typically human-curated to ensure specificity Host-based IDS: look for compromised process or See also: anti-virus scanners user from within machine Anomaly detection Recall: FPs and FNs Learn pattern of normal behavior False positive: detector goes off without real attack “Not normal” is a sign of a potential attack False negative: attack happens without detection Has possibility of finding novel attacks Any detector design is a tradeoff between these (ROC curve) Performance depends on normal behavior too

Signature and anomaly weaknesses Base rate problems If the true incidence is small (low base rate), most Signatures positives will be false Won’t exist for novel attacks Example: screening test for rare disease Often easy to attack around Easy for false positives to overwhelm admins Anomaly detection E.g., 100 attacks out of 10 million packets, 0.01% FP Hard to avoid false positives rate Adversary can train over time How many false alarms? Adversarial challenges Wagner and Soto mimicry attack Host-based IDS based on sequence of syscalls FP/FN statistics based on a fixed set of attacks But attackers won’t keep using techniques that are Compute ❆ ❭ ▼ , where: detected ❆ models allowed sequences ▼ models sequences achieving attacker’s goals Instead, will look for: Further techniques required: Existing attacks that are not detected Minimal changes to attacks Many syscalls made into NOPs Truly novel attacks Replacement subsequences with similar effect Next time Malware and network denial of service