Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Computer security wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
TCP congestion control wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Internet protocol suite wikipedia , lookup
Cross-site scripting wikipedia , lookup
Web blocking in the United Kingdom wikipedia , lookup
Deep packet inspection wikipedia , lookup
Network Layer Attacks and Defenses Last updated: Thursday, 25 May 2017 © Prof. Amir Herzberg (except where noted) Computer Science Department, Bar Ilan University http://AmirHerzberg.com 25/05/201704/10/06 http://AmirHerzberg.com 1 Lecture Outline Vulnerabilities and Patches Reconnaissance / Scan attacks Packet filtering and firewalls Intrusion Detecting Systems (IDS) and Evasion Decoys / Honeypots Not in scope (next topic): Application vulnerabilities, attacks and defences Complexity Breeds Vulnerabilities Computer and network systems are complex Everybody cares about security But more about usability, functionality Competitive market with limited penalty to bugs Multi-vendor systems result in ‘finger pointing’ Bugs and vulnerabilities are common, expected Limited risk of liability, impact on reputation Fix security in new release/system increase revenues Result: Many vulnerabilities, exploits and attacks Knowledge is Power: Bug, Exploit, Fix Many vulnerabilities, exploits and attacks Myth: All systems have bugs, attackers find bugs quickly Patch/new version quickly after exploit detected But then attackers find new bug… Mythical timeline: NewOS/App ver1.0 NewOS/App ver1.1 (patch) Detected Bug found, exploited Time Detected Bug found, exploited Time Knowledge is Power: Myths & Reality Many vulnerabilities, exploits and attacks Myth: hackers easily break any system, defense Reality: vulnerabilities are exceptions, easy fix Bugs due to complexity, size, negligence Patches often installed late (why? Lazy/reliability) Most exploits btw warning & patch install NewOS/App ver1.0 Vuln. Detected NewOS/App ver1.1 Time Patch available Exploit Attack using Exploit Time Example: Some DNS Exploits History 1990: Poisoning by out-of-bailiwick glue RR or by spoofed responses (with fixed port, incrementing ID) widely known Bellovin writes on it, also notes that Berkley’s r-utils (rsh etc.) depend on domain name from rDNS tree. Does not publish. 1995: Vixie, Bellovin publish attacks, propose in-bailiwick restriction. 1997: In-bailiwick restriction, random ID fixed in Bind. 1999: Bernstein motivates, implements port randomization. 2005: Windows attacks exploiting poor validation. Patch. 2008: Kaminsky identifies attack (Feb). Patches: ~June. Exploits: ~July. Official disclosure: August. Patch only adds port randomization (like Bernstein) This isn’t enough (as pointed out by Bernstein at 2002). Many servers not patched yet! What of Auto-Install Patches? Authenticated, signed download, version checking Concerns: Reliability Convenience Security Windows: forced re-boot (if not admin) Attacks by vendor (or malware/insider at vendor) Increased risk (why?) Other approaches: Disable feature till patch is `stable` Install patches… but later 04/10/06 Tradeoff reliability vs. security System/Net Management Vulnerabilities So far we discussed product vulnerabilities But often the weakness is due to poor management Few (of many) examples: Not installing patches (we just discussed) From previous topic (sniffing & poisoning): Open proxy (next) 04/10/06 Not invoking options, e.g. `port security` (prev. topic) Placing DNS behind Sequential port assigning NAT Open recursive DNS service Generalizes open recursive DNS service Open Proxy Vulnerability Proxy: connects between client and server (e.g. HTTP) Forwards responses to client’s IP address Normally: service only to internal clients Open proxy: connects any client Two-way (send/receive) internal client spoofing Goals: obtain access, use as `attack base` 6.6.6.x 10.0.0.x 127.5.5.x Eve Alice Bob (web server) 25/05/201704/10/06 http://AmirHerzberg.com 10 Summary: Knowledge is Power Many vulnerabilities, exploits and attacks Unrealistic to block all on all machines Patch installation lag: Attackers: Due to unawareness, reliability, usability concerns … Reconnaissance/scan: detect vulnerabilities, targets Exploit Defences: Detect and Block Esp.: block scan! Eve’s 1st Law: Avoid Detection! Remove traces/logs… Reconnaissance / Scan Attacks Identify vulnerable configurations, applications, OS, applications… and later exploit Attacker’s goals: efficiency… and stealth Intrusion Detection’s `Cry Wolf` Dilemma Too many (false) alarms will reduce attention External scans: only block & log Most scans require just valid IP address Even better: using (mostly) spoofed IP addresses Eve’s first law: avoid detection Examples – how to detect by scan: Open recursive DNS servers `unpatched` DNS servers Or behind Sequential port assigning NAT 25/05/201704/10/06 http://AmirHerzberg.com 12 Network Scans Goal: detect connected computer (IP) Or: detect `reachable’ application (by port) Or: detect OS, appl, configuration, etc. Network scanning cues… Explicit self identification, e.g. HTTP header Implementation differences, bugs TTL, TCP init window size, MSS,… Existence of response? IP Scan / Sweep: Ping (ICMP), SNMP, other Services and ports scans: 04/10/06 TCP Scans (normal or `stealth`, e.g. Syn -> SynAck -> abort) UDP Scans; reply of ICMP `dest port unreachable` (if unused) Detecting Services Scan UDP / ICMP Scans: TCP scans: Send request, get reply – logged, load noticed Or, send junk – ignored or ICMP ‘port unreachable? Find open & exploitable TCP ports Regular TCP connection – logged, load noticed, slow Stealth scans: half-open connection scans or FIN scans – not always logged Log and detect also these events MITM attacker can use random source IP But spoofer must use real IP to get response TCP Scans Valid TCP connection scans Connect, or `SYN-only’ (SYN-SYN/ACK-RST) Responses: none (no machine), RST (closed), ICMP Port Unreachable (blocked), Ack Stealth TCP scans: try to avoid detection… NULL (no flag) FIN XMAS (URG, PSH and FIN all set) Standard response: RST if port closed, none if open Windows: always sends RST Cannot detect open port But may detect Windows machine… Predictable Challenge Scans Detect, then exploit use of sequential identifier Allows blind attacker to spoof responses TCP: initial sequence number If predictable, blind attacker can spoof data in TCP connections! DNS: identifier, port in queries IP: identifier field, used for defragmentation Scan to detect sequential identifier (by old, buggy systems) Perform (limited) MITM attack Identifiers used to ensure `fresh` responses in: In place of random identifier Send two requests, Validate sequential identifiers in responses How can we exploit sequential IP ID? 04/10/06 Allows spoofed (dumb) port scan Spoofed (dumb) port scan • Scan by blind attacker (spoofed src IP) – Against server (Bob), using sequential IP ID Bob Eve “HTTP GET x.htm…”, SenderIP=6.6.6.6 “first packet of x.htm”, IP ID = 345 H “second packet of x.htm”, IP ID = 346 H NULL/XMAS, SRC=1.2.3.4 (spoofed)… TCP RST or none, ID=347 “HTTP GET x.htm…”, SenderIP=6.6.6.6 “first packet of x.htm”, IP ID = 348 H “second packet of x.htm”, IP ID = 349 04/10/06 The Net is Always Scanned! IP addresses are constantly scanned By attackers By `good guys` (checking, selling security…) Vulnerable PC `captured` in <1min 1st line of defense: NAT and/or Firewall Placed between internal network (or PC) and Internet NAT: most scan probes use unallocated port , ignored Most NATs remember external IP, map to internal IP only if external IP and dest port match entry Firewalls: block suspect packets (next topic) 04/10/06 Prevent attacks on internal network (or PC) Often firewall is also NAT Lecture Outline Vulnerabilities and Patches Reconnaissance / Scan attacks Firewalls Definition, motivation Packet filtering firewall: rules Application firewalls Intrusion Detecting Systems (IDS) and Evasion Decoys / Honeypots Not in scope (next topic): Application vulnerabilities, attacks and defences Firewalls – Keeping Attackers Out (1) A secure / trusted machine Placed on the communication path from a protected network to the Internet Controls, inspects and filters the communication Attempts to prevent attacks from outside Read RFC 2979, Behavior of and Requirements for Internet Firewalls 04/10/06 Defense in Depth Military term for multiple lines of defence Allows detection External firewall + inter-department firewalls Intrusion Detection System (IDS) behind firewall Cannot alert on each scan from Network (too many) Redundancy Damage control Beyond blocking: resiliency, backup, recovery Firewalls – Keeping Attackers Out (2) Firewall (improved definition): A secure / trusted machine, or module on a machine On the path between two or more networks / host(s) Controls, inspects and filters the communication One or both networks are protected by firewall Can be used between departments to limit damage Also: fixes common vulnerabilities, e.g. NAT, randomizes ports and ISNs To prevent / limit reconnaissance, exploits 04/10/06 Packet Filter: Router-Firewall A router: forwards packets between two networks Or even a bridge (no routing): `transparent FW` No IP address, subnet…; less overhead, visibility Most basic and common firewall Filters packets to block/detect attacks • Stateless filtering (simpler, fast) or stateful filtering Filtering policy is often called “Access Control List” Typically: specified as a list of rules Rules are pairs: <Selector, Action> Selector identifies which rule applies to the packet Packet Filtering Policy and Rules Packet filtering policy is often a list of rules Each rule is a pair – selector and action Often called Access Control List (ACL) ACL:= Rule || ACL, Rule Rules are usually processed by order Rule:= Selectors Actions Selectors defines if the rule applies to the packet As a function of values of fields in the packet • Example: protocol=UDP, SrcPort=7 (Echo) Actions defines what to do with the packet • Example: silently discard (block echo requests) Packet Filtering: Selectors Selectors defines if the rule applies to the packet Selectors:= Selector || Selectors {AND/OR} Selectors || (Selectors) || NOT Selectors Allows composite selectors (with AND, OR, etc.) A selector: = field operator value Field := {SrcIP, DstIP, SrcPort, DstPort, Protocol, Flags, ICMPType}, TTL, Length, Interface_in} Operator := { =///>/…} Value:= IPADDR || PORT || Protocol || Flag || Types|| Hops Selector is a function of field in packet Stateless rule: value is constant Stateful rule: value can be variable, or: selector a function Examples of Stateless Selectors selector: = field operator value Field := {SrcIP, DstIP, SrcPort, DstPort, Protocol, ICMPType}, TTL, Length, Interface_in} Examples 1 [2]: protocol=UDP [AND DstIP=*.*.*.FF] Example 3: Protocol=UDP AND DstPort=7 (Echo) Block all UDP traffic [to broadcast address] Block incoming UDP Echo requests (`smurf` attack) Example 4: Protocol=ICMP AND ICMPType=8 (Echo) Block incoming ICMP Echo requests (`fraggle` attack) Internet Control Message Protocol ICMP: Internet Control Message Protocol Status, control between routers, hosts Error handling and debugging protocol Unauthenticated protocol 0 Echo Reply Encapsulated in IP header 3 Destination 40 assigned types Unreachable 4 Source Quench Many exploits 04/10/06 E.g. DoS Amplification attack, by echo request to broadcast address Details follow… 5 Redirect 8 Echo 11 Time Exceeded Broadcast Amplification DoS Attacks DoS attack using broadcast capability of UDP / TCP Amplification: (blind) attacker sends 1 packet, victim gets many Implementations: Fraggle (UDP), Smurf (ICMP), etc. Sending spoofed request ‘from’ victim’s IP address Responses are sent to the victim Src=192.3.3.5 Dst=193.5.6.255 Victim 192.3.3.5 Subnet 193.5.6.0/8 04/10/06 Packet Filtering – Actions Actions define what to do with the packet: Allow Log Alert response team Discard (silently) [aka deny, drop] Reject (e.g., send RST for TCP, or Port Unreachable) Apply IP-sec tunneling (encryption, authentication) (more) Examples: Block smurf and fraggle attack packets (UDP, ICMP broadcasts) Block stealth TCP scans Block TCP Stealth Scans Recall: TCP stealth scans detect open TCP ports NULL / FIN / XMAS segment Standard response: RST if port closed, none if open Windows: send RST to all Possible firewall actions: Reject (RST) Discard (drop) If (StlthCtr[SrcIP]++)>MaxStlth: add SrcIP to BlockIPList Reset StlthCtr[ ] periodically Another rule blocks all traffic with SrcIP in BlockIPList Compare: the good, the bad and the ugly! [see notes] Example: Anti-Scan, Broadcast Rules Rule name / Intfc Src Src Dst DPort Protocol Flags Action goal IP Port IP Stealth TCP Scans (In) Stealth TCP Scan (out) Block UDP broadcast Block ICMP broadcast in 156.6.7.6 04/10/06 156.6.7.7 144.4.4.4 out Internet Service Blocking Rules Problem: Many attacks exploit vulnerable services Solution: Block incoming requests Also block outgoing requests to exploitable services Identify by protocol (TCP/UDP/ICMP…), port May fail for new services or non-default ports Better: Allow only specific and essential services And only to designated servers (often in DMZ, see later) Block new and rogue services (e.g., P2P networks) Really rogue services may hide E.g. bot-nets use IRC but use port 80 (like http) Some Vulnerable Services A few (of many) examples of vulnerable services Port Service Exploit 7 Echo Denial of Service, with spoofed source as victim 19 CharGen (random character generator) Denial of Service, especially by sending from port 7 of victim 11 SysStat – list of processes Identify vulnerabilities 79 Finger Bug lets attacker control (some) machines 137-139 NetBIOS Access to files, printers, etc Block Outgoing Spam No “Open Relay / Proxy / Port 25” service Often blacklisted Need to block both outgoing and incoming port 25 Some ISPs block only outgoing… spammer circumvent – how? Send only authenticated mail: From (authenticated) users Rule Per user quotas Relay mail only from authenticated & trusted SMTP-sender Intrfce SrcIP Dialup (1Mb/s) 156.6.7.6 25/05/201704/10/06 SPort in DstIP DPort Flags Action 144.4.4.4 156.6.7.7 1Gb/s (c) Amir Herzberg, http://AmirHerzberg.com 38 Block, but how: Discard or Reject? How to block suspect request? Discard (silently) Reject (send RST) Discard better if packet was malicious Don’t waste resources Don’t expose existence Source IP is often spoofed – don’t ‘attack’ it (victim) Or risk being labeled as attacker, blacklisted… Reject better if connection may be legitimate 04/10/06 Not to delay it Example: Blocking Ident Protocol IDENT protocol (to port 113) – resolves IP Name Invoked by many applications, e.g. rlogin, Windows Rule If fails, they (usually) use reverse DNS Block: incoming? Outgoing? Discard or reject? Intrfce SrcIP SPort in 156.6.7.6 04/10/06 156.6.7.7 DstIP DPort 144.4.4.4 out Flags Action Block Incoming Requests How to block incoming requests? First: TCP (connection-based services) Later: UDP & ICMP (connection-less services) To send a TCP request, must initiate connection Usually the client initiates the connection Note: FTP – server also initiates `data` connection Internal clients initiate from inside Attackers initiate from outside Block incoming TCP connection requests Block Incoming TCP Requests TCP initiation is always by sending a SYN packet Responder sends back a SYN-ACK packet SYN bit is only set in these first two packets Hence: Block incoming SYN packets without an ACK Similarly: block (and alert!) outgoing SYN _with_ Ack Exception: public servers (e.g., external Web servers) Place them on separate subnet: De-Militarized Zone (DMZ) We discuss DMZ later on… Responder SYN Initiator SYNACK Block Incoming TCP Requests Block incoming SYN packets without an ACK And: if some OS also allows SYN with Ack (as 1st packet)? Rule Intrfce SrcIP SPort DstIP DPort Responder SYNACK SYN Initiator 156.6.7.6 in 156.6.7.7 144.4.4.4 out Flags Action Block UDP/ICMP Requests Many UDP & ICMP vulnerabilities and attacks How to block incoming UDP and ICMP requests? Connectionless Can use spoofed IP addresses (don't need reply) Solution 1: Block all UDP, ICMP traffic But some are critical (e.g. DNS) Solution 2: Stateful filtering Allow responses for limited time (after request) Anti-Spoofing Rules (ingress/egress filtering) IP source address spoofing threat ISPs and organizations should prevent spoofing [Read: RFCs 2827, 3013, 3704] • Ingress filtering: spoofed packets from customers Not using assigned IP address Block outgoing broadcasts ? Many ISPs don’t ingress-filter, esp., for hosted servers, domains Legitimate use of unassigned IP (e.g. multihoming) • Egress filtering: spoofed incoming packets from Net Incoming packet using an ‘internal’ IP address Incoming broadcasts Legitimate Use of Unassigned IP st Source Addr: 1 example: multihomed corporation USA-ISP.net Foo.com’s Private Net The Internet MexISP.net Legitimate Use of Unassigned IP, 2nd example: Mobile IP `triangle routing` [See notes…] DstIP: 132.3.3.4 Home IP 132.3.3.4 SrcIP: 132.3.3.4 DstIP: 156.4.5.6 Temp IP 156.4.5.6 DstIP: 132.3.3.4 MobileIP behind Ingress Filter: Must Tunnel via Home Server 144.5.5.6 DstIP: 144.5.5.6 Home IP 132.3.3.4 SrcIP: 156.4.5.6 DstIP: 132.3.3.4 Temp IP 156.4.5.6 DstIP: 144.5.5.6 Anti-Spoofing Rules (ingress/egress filtering) • Egress filtering: packets from Net with internal src IP • Ingress filtering: customer packet with unassigned IP Incoming and outgoing broadcasts Rule Intrfce SrcIP SPort in 156.6.7.6 04/10/06 156.6.7.7 DstIP DPort 144.4.4.4 out Flags Action Aggressive Ingress Filtering When we really care Firewall-to-firewall tunnel (often IP-Sec) Under (DoS) attack Against IP spoofing (of special hosts / networks?) Identify by `code` attached to packets Cryptographic MAC or random identifier One sided filtering? Some ideas, e.g., using TTL... Lengths of paths are almost fixed Few initial choices of TTL, often same in a network Fixed TTL in packets from network Other TTL: suspect spoofed packet Stateful Packet Filtering Need state for many filtering tasks We’ve seen: UDP requests/responses Statistical identification of attack, source Rate control – disconnect from DoS attacker (by IP) Filtering fragmented IP packets Blocking application-specific vulnerabilities Requires application awareness Must reconstruct and analyze application messages Malicious content, e.g. viruses, spoofed web sites, web attacks, etc. Often done by application-level gateway (firewall) Content Filtering by Appl Gateway /FW Packet filter cannot identify application attacks Solution: use separate module / machine Messages may span multiple packets Too complex, much processing, stateful Application Gateway / Firewall Content-filtering server Web Application Firewall (WAF) – e.g. as proxy Intrusion detection / prevention system (IDS/IPS) Use packet filter to enforce content filtering / application firewall 04/10/06 Prevent bypassing (Web) Application Firewall: Goals Virtual patching Positive filtering Input sanitization: remove control chars, restrict length Allow only `clean` inputs (scripts) Prone to interfere with usage Negative filtering Block specific vulnerability `outside` application Block known attacks Prone to miss new attacks Intrusion prevention / detection [later] 04/10/06 Enforcing Application Gateways / WAF Method 1: WAF (Web Application Firewall) as proxy Client connects to gateway & gateway connects to server Simple to implement gateway Client side WAF: requires configuration Two TCP connections (overhead) Method 2: Transparent application gateway / WAF 04/10/06 Client connects to server & gateway ‘captures’ connection Usually a single TCP connection Harder to implement but easier to deploy, faster… WAF/Application Gateway as Proxy Application gateway is ‘visible’ to client Client application is configured to use gateway Requires configuration Sometimes automated Example: HTTP proxy Firewall prevents direct access 04/10/06 Application Gateway Rules Enforcing Use of HTTP Proxy Force use of (filtering) web proxy Allow only outgoing connections Rule Intrfce SrcIP SPort DstIP DPort Flags Action In2Prx In2Net P2Net … CNN.com 1.2.3.4 Proxy: 156.7.8.9 156.6.7.6 04/10/06 in 144.4.4.4 out Internet HTTP Transparent WAF Rules Enforce WAF (& HTTP proxy) transparently Allow only outgoing connections Rule Intrfce SrcIP SPort DstIP DPort 144.4.4.4 04/10/06 156.6.7.7 in Action CNN.com 1.2.3.4 Proxy: 156.7.8.9 156.6.7.6 Flags out De-Militarized Zone (DMZ) Blocking incoming requests is a good practice But we may need to provide some public services: Most vulnerabilities result from service exploits External web FTP servers Incoming mail server Domain name service, Others Solution: De-Militarized Zone (DMZ) 04/10/06 DMZ is a network protected by firewall DMZ contains public-accessible servers DMZ is less secure, but it is separate from the ‘Internal’ network DMZ with Two Firewalls First packet filtering firewall protects internal +DMZ Preferably on different interfaces Second firewall protects only the internal network DMZ is ‘in border’ area WWW DMZ WWW 04/10/06 Mail DMZ with a Single Firewall DMZ: separate interface of packet filter Allow incoming connections: Only from outside Maintain separate internal servers (e.g. web, mail, DNS) Except: sys-admin, (web)mail [separate DMZ?] Mail DMZ WWW 04/10/06 WWW Delivery Agent DNS Incoming Mail Transfer Agent Enforcing of Spam Blocking MTA A: outgoing border MTA A MTA B MSA MDA Alice MUA Bob MUA Domain a.com Domain b.com MTA of a.com MTA B: incoming border MTA of b.com • Firewall rules force SMTP to / from domain to pass via border MTA 04/10/06 (c) Amir Herzberg, http://AmirHerzberg.com Incoming SMTP Rules Incoming SMTP (port 25) to incoming border MTA Allow SMTP (TCP port 25) from Internet to 144.4.4.4 Originator must be border MTA 144.4.4.4 Discard any other incoming TCP port 25 (probable attack) Do not log / alert – expect many such attempts Subnet 144.4.5.* 66.6.6.6 SMTP-Sender MTA 25/05/201704/10/06 144.4.4.4 Incoming Border MTA 144.4.4.2 Local DNS (c) Amir Herzberg, http://AmirHerzberg.com 144.4.5.1 Internal MDA / MTA 65 Outgoing SMTP Rules Outgoing SMTP (port 25): By outgoing border MTA Allow TCP/25 from out-MTA 144.4.4.5 to Internet Allow TCP/25 from MSA to out-MTA (144.4.5.5 to 144.4.4.5) Discard and alert: any other TCP/25 from 144.4.5.* DNS rules? Any other traffic from out-MTA: alert Subnet 144.4.5.* WWW 144.4.5.5 MSA/MTA 25/05/201704/10/06 144.4.4.2 Local DNS (c) Amir Herzberg, http://AmirHerzberg.com 144.4.4.5 Outgoing Border MTA 68 DMZ: Outgoing Connections Block outgoing connections and alert DMZ servers never open connections Few exceptions (e.g. outgoing border MTA, NNTP) May allow specific connections to internal servers E.g., incoming mail (SMTP MTA) [but better `pull`] To / from specific IP & port: can place on separate DMZ DMZ WWW 04/10/06 DNS Mail WWW Delivery Agent Incoming Mail Transfer Agent DMZ Rules… Rule Intrfce SrcIP SPort DMZ WWW 04/10/06 DNS DstIP DPort Flags Mail Action WWW Delivery Agent Incoming Mail Transfer Agent Limitations of Firewalls Firewalls are very important Firewalls are the first (external) line of defense But – Firewalls cannot block all attacks Firewalls cannot filter encrypted traffic (e.g., IPSec) Unknown bug of useful application (e.g. Web) Many firewalls support IP-Sec tunnel mode Many firewalls use IP-Sec tunnel between Firewall and Net This fails if host also encrypts Filtering depends on use of standards 04/10/06 Ports (to identify services), protocols and applications Filtering fails if both ends collude Firewall cannot Isolate Insiders, Trojans! Corrupted Internal PC (Zombie) Attacker Consider malware behind the firewall (‘inside’): Initiate communication to attacker’s site Use port-spoofing or encapsulation to hide the communication protocol Encrypt if firewall scans content If firewall monitors statistics to limit traffic: firewall Use multiple internal addresses Sniff to pick up replies Result: Firewall cannot protect against Insiders & Trojans 25/05/201704/10/06 http://AmirHerzberg.com 72 Intrusion Detection Systems Content-filtering is hard, resource intensive Very hard: blocking attack at real time Performance (buffering) costs Better: detect and respond to intrusion attempts Intrusion Detection System Preferably at reconnaissance (scan) stage Or: to abort attack – Intrusion Prevention System (IPS) Typically: filter out packets with suspect strings Careful: avoid false-positives At least: post-mortem analysis, evaluation of defences Why is content-filtering so hard? Attacker uses evasion techniques… Content Filtering and Evasion Content and application filtering: Critical for security (block, detect) Resource-intensive Filter: known/suspect attacks (`signatures`), addresses (`blacklist`), or attack-mechanisms Evasion: avoid filtering, by… 04/10/06 Content morphing and encoding Content changes signature mismatch Content editing attacks FW/IDS sees one content, victim sees different Insertion/deletion attacks Fragmentation tricks, Request smuggling, … Encrypted content Overloading the IDS system (DoS) Evasion by Morphing Goal: prevent recognition of `attack signature` How? `Morphing`– change attack string… Object code (e.g. virus): Scripts, etc.: easier… : Most of its code is `encrypted` (randomized) A tiny `loader` to decrypt, execute (too small to identify) And/or: add no-ops, etc. (`obfuscate`) Add spaces, change capitalization, e.g. `< ScRiPt >` Different encodings for `same’ characters Better: filter control chars (`<`) [except permitted tags] Identifying attacks by `signature database` is not long-term viable !! 04/10/06 Evasion by Encoding Tricks Non-standard encoding UTF-8 encodes unicode as 1 to 4 bytes Unicode 00000000 0xxx xxxx (Ascii) 1B UTF8 : (0xxx xxxx) Unicode: 00000yyy yyzzzzzz 2B UTF8: 110yyyyy 10zzzzzz How to decode UTF-8 1100000y 10zzzzzz ? 04/10/06 WAF, standard: allow only shortest encodings But server/client may accept also longer encodings! E.g. IIS 4.0 / 5.0 Extended UNICODE Directory Traversal Vulnerability. Decode as 0yzzzzzz Evasion via UTF-7 Auto-Encoding Another evasion technique: hidden UTF-7 encoding Char-set of HTTP response defined by: Explicit charset attribute in header or body Content-Type: text/html; charset=3D[encoding] Implicit, auto-encoding on detecting UTF-7 chars Attack: 04/10/06 Response contains no explicit charset WAF assumes no encoding, finds no script Browser finds UTF-7 char, auto-decodes Decoding reveals mal-script Domain Blacklist Evasion Domain blacklist: suspect domains, block request Popular (IEv7, FF, … ), (currently?) effective Domain Blacklist Evasion: Change domains frequently Redirect to IP address From free web page, or even Google archive… Negligible costs domain blacklists may not be a long term solution What of IP blacklists? 04/10/06 Dynamic DNS, dynamic IP-address redirect Zombies, dial-up Evasion by `Content Editing` Attacks Idea: filter (FW) sees `sanitized/edited` stream Insertion: IDS sees `attXack`, victim sees `attack` E.g. packet with `wrong` IP version (e.g. 2) Merge/split, e.g. request smuggling E.g.: packet with short TTL (dropped before victim) Deletion: IDS sees `ack`, victim sees `attack` Yet, victim receives `real` requests/responses Victim (server) gets two requests FW sees one request (2nd becomes part of 1st) Fragmentation/partitioning tricks 04/10/06 IDS Evasion by Request Smuggling Different parsing between WAF and application server E.g. IIS limits requests to 48KB Fixed/patched Web Application Firewalls (usually) allow longer requests IIS considers data after 48KB as new request Web Application Firewall considers it as body (ignore) Due to no separation between requests! 04/10/06 See: http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf Evasion by Fragmentation/Partitioning IP packet fragments, multi-packet request/response Filters may fail to detect multi-fragment/packet signature Or: exploit implementation differences Requires state, reconstruction by filter If done… may be abused for DoS (waste state) If receiving packet/fragment with already-received ID… Use older or newer contents? Common solution: block all fragments `fragmentation considered harmful` 04/10/06 Evasion by Encrypting Content Send attack over encrypted connection Download over SSL/TLS (https://) Attack over SSH Filter sees only encrypted contents can’t filter `Solutions`: MITM SSL content-filtering 04/10/06 (details) Forbid encrypted traffic (e.g. SSH) Intrusion Detection Systems (IDS) Goals: detect, log, alert Detect known attack signatures / patterns Detect other attacks – based on heuristics & statistics Critical: Must exhibit few false alarms Otherwise they will be ignored Basic types of IDS [compare?]: Network-based IDS Host-based IDS Decoy IDS Types of IDS – comparison Network-based IDS: + Sees (all net) traffic (multiple dest, low-level) - evasion techniques - performance/cost (how to see traffic?) - evasion techniques Host-based IDS + detect attacks from within host - only detect attacks to/from single host, visible to monitor - Fooled by (smart) attacker controling machine! Decoy IDS: great detection… of attack on the decoy… Complements other tools… and must avoid detection! Distributed Intrusion Detection System App GW Remote IDS WWW Host-based IDS Network IDS Decoy IDS DMZ IDS Mail Manager Intrusion Detection System monitor / manager Intrusion Detection – Basic Approaches • Detect Attack Signature Analyze attacks, find identification marks/patterns Example: CharGen (port 19) used only for attacks Detects only identified attacks • Detect Anomaly & Statistical Deviation Learn (automatically) patterns of normal operation vs.patterns of attacks Use to detect attack or deviation from normal behavior Challenge: acceptable false alarm rate Limited success at detecting new attacks • Decoy / Honeypot IDS Detect any activity… Anomaly Detection Goal: Detect new attacks Attack signatures are clearly better for known attacks Learn patterns of normal operation vs. patterns of attacks Use to detect attack or deviation from normal behavior Much research – tools of machine learning Problems: Too few samples of `attacks` Worse: would learning find new (other) attacks? Can we test / benchmark? False Alarms • False Alarm IDS alert on Non-Attack event: eNA • False Positive Rate • FP = Prob(IDS(e)=Alert) for eNA • Number of false alarms is FP * |Log| Realistic numbers: Log events: 1 million / day (even for small systems) With FP of 0.1%, this gives 1000 false alarms (!) Number of real (attack-related) events is much lower System admin likely to ignore alerts Must minimize log events & false positive rates Limited success, especially for new attacks Minimize Log Events Focus on events after the firewall Problem: So why IDS? Detect attacks by malware / insiders Detect firewall failures (e.g. wrong rule) Firewall blocks known attacks And IDS is not too good on unknown attacks May also use inner firewall to block these But not the same firewall & rules Post-mortem analysis and security evaluation Correlate information and decoy/honey-pot IDS Decoy / Honeypot IDS Decoy / Honey-pot / Bait: Decoy has no legitimate traffic An object whose (only) goal is to: Appear to be a desirable target for attack Allow easy detection of attacks on it Waste attacker’s resources in meaningless attacks Traffic & modification alert, log, analysis Except: camouflage traffic Decoys have few (or no) false alarms Decoys detect new attacks There are different types of decoys Types of Decoys Decoys for different objects Email mailbox (for spam) Addresses in address-book (detect abuse by malware) Programs on computer (detect virus contamination) File or records in DB (detect access / modification) Host, router, application (detect access / change) Real or virtual Dedicating real subnet, host, router is expensive Detecting access / modification is easier for a virtual host or a virtual subnet But – attacker may detect that this a virtual decoy Using Decoys Network Decoys Waste attacker resources by simulating many hosts Early detection Detect new attacks Detecting new malware `Intrusion Prevention` (IPS) Viruses – contaminating decoy program Email parasites– decoy entry in address book Worms – contaminate decoy programs, OS Capture Spam and submit to filtering systems Decoy mailbox or decoy host (e.g. HoneyD) Danger of abuse by adversary for DoS Zombies, BotNets and Worms Zombies: compromised, controlled hosts BotNet: Communication, Command and Control: Often self propagating code: worms Attacker control of Zombies Often/usually use Internet Relay Chat (IRC) IRC can efficiently send command to lots of hosts Block IRC by packet filtering? 04/10/06 Fails for IRC over HTTP Detecting and Blocking Worms Worms are malicious programs (malware) Propagates automatically between computers Exploits enabling vulnerability in target computer No human interaction needed to spread Usually, in an application, e.g. buffer overflows Three steps / elements: 04/10/06 Penetration: exploiting vulnerabilities (which?) Infect: select and (try to) penetrate new victims Payload: perform attacker’s function [optional] Worm Attack, begin: 08:00 Immune (e.g. Unix) worm Vulnerable infected 04/10/06 Worm Attack, 1st wave: 08:01 Example: fan out = 3 04/10/06 Worm Attack, 1st wave results Example: fan out = 3 04/10/06 Worm Attack, 2nd wave: 08:02 Attack about complete Blocking now? Too late! 04/10/06 Worms: Need Automated Defense Propagates automatically between computers Can rapidly infect vulnerable hosts No human interaction needed to spread Slammer scanned 90% of Internet in 10 minutes Fast worms: high infection rates loads, detection Stealth worms: infect slowly avoid detection Need: proactive defense against new worms 04/10/06 Automated Detection Automated blocking (for fast worms) Automated recovery (if we can) Example: Code Red Worm Conceals itself in HTTP Packets. Exploits vulnerabilities in IIS Microsoft’s Internet Information Server (IIS) v4&5 Specifically: buffer overflow vulnerability By sending special URL Installs itself, then infects other hosts Multiple versions: CRv1, CRv2, Code Red II Results: 04/10/06 DDoS attack, network latency Backdoor installation Attack with Detecting Hosts Detecting host worm infected 04/10/06 1st Wave, 08:01 Upon detection: Address blocking or Content filtering? 04/10/06 2nd Wave with Address Blocking 04/10/06 3rd Wave with Address Blocking Attack complete: all vulnerable hosts are infected 04/10/06 2nd Wave with Content Filtering 2nd wave – same results as with Address blocking. 04/10/06 3rd Wave with Content Filtering Attack Blocked! 04/10/06 Need Hi-Speed Detection & Recovery Manual detection, recovery: too slow Time is critical: Hi-speed detection (and blocking): To block – preferably, by content To minimize damages, restore services Automated – statistical (?), specific (e.g. buffer overflow - next) Community-based, service ? Hi-speed recovery: 04/10/06 Hardware remote re-boot Software re-boot: using virtual machine e.g. Windows over Linux / `hardened` operating system Also to limit damages Summary Operating system and networks are complex Complexity vulnerabilities Defense in depth Separate Block, detect & react, survive (redundancy), recover Firewall: intranet vs. Internet, and inside intranet Separate code from data, validate code Separate between requests, responses, … Understand adversary model 04/10/06