Presentation is loading. Please wait.

Presentation is loading. Please wait.

Packet Filtering & Firewalls. Stateless Packet Filtering Assume We can classify a “good” packet and/or a “bad packet” Each rule can examine that single.

Similar presentations


Presentation on theme: "Packet Filtering & Firewalls. Stateless Packet Filtering Assume We can classify a “good” packet and/or a “bad packet” Each rule can examine that single."— Presentation transcript:

1 Packet Filtering & Firewalls

2 Stateless Packet Filtering Assume We can classify a “good” packet and/or a “bad packet” Each rule can examine that single packet against a good or bad signature/pattern, and accordingly – the packet either passes on or is dropped silently / dropped “loudly” / logged We run our set of black-list (deny) rules first, followed by our white-list (allow) rules. The first rule that matches takes precedence (no need to examine the rules)

3 Stateless rules Source & Destination IP addresses Transport protocol – TCP / UDP Source & Destination Ports TCP & UDP fields (i.e.: TCP Flags) Packet direction (from X interface to Y interface, internal network->world vs. world- >internal network) Usually not used but possible – o Inspecting deeper layers o Pattern matching on packet data (e.g.: shellcode signature)

4 Stateful Packet Filtering To enable faster and more advanced filtering, the FW stores a list of active (and allowed) connections, and associated metadata If a packet matches a known connection – accept it If it doesn’t, we’ll run through our list of rules to see if the connection is valid

5 Complex Protocols Some protocols are complicated – o VoIP & P2P protocols may need to accept incoming connections o FTP uses one port for control and another (incoming) port for bulk data o TFTP uses random ports for both endpoints o Etc. We need to inspect (and modify) the application layer to perform proper packet filtering (i.e.: allow valid connections to enable these protocols)

6 DNS & DNS Attacks

7 DNS Lookup Example Client Local DNS resolver root & edu DNS server stanford.edu DNS server www.cs.stanford.edu NS stanford.edu www.cs.stanford.edu NS cs.stanford.edu A www=IPaddr cs.stanford.edu DNS server DNS record types (partial list): - NS:name server (points to other server) - A:address record (contains IP address) - MX:address in charge of handling email - TXT:generic text (e.g. used to distribute site public keys (DKIM) ) 7

8 Caching DNS responses are cached at each level o Quick response for repeated translations o Useful for finding servers as well as addresses NS records for domains DNS negative queries are cached o Save time for nonexistent sites, e.g. misspelling Cached data periodically times out o Lifetime (TTL) of data controlled by owner of data o TTL passed with every record 8

9 DNS Packet Query ID: o 16 bit random value o Links response to query (from Steve Friedl) 9

10 Resolver to NS request 10

11 Response to resolver Response contains IP addr of next NS server (called “glue”) Response ignored if unrecognized QueryID 11

12 Authoritative response to resolver final answer bailiwick checking: response is cached if it is within the same domain of query (i.e. a.com cannot set NS for b.com) 12

13 Basic DNS Vulnerabilities Users/hosts trust the host-address mapping provided by DNS: o Used as basis for many security policies: Browser same origin policy, URL address bar Obvious problems o Interception of requests or compromise of DNS servers can result in incorrect or malicious responses e.g.: malicious access point in a Cafe o Solution – authenticated requests/responses Provided by DNSSec Unfortunately, DNSSec is not yet commonly implemented 13

14 DNS cache poisoning (a la Kaminsky’08) Victim machine visits attacker’s web site, downloads Javascript user browser local DNS resolver Query: a.bank.com QID=x 1 attacker attacker wins if  j: x 1 = y j response is cached and attacker owns bank.com ns.bank.com IPaddr 256 responses: Random QID y 1, y 2, … NS bank.com=ns.bank.com A ns.bank.com=attackerIP 14

15 If at first you don’t succeed … Victim machine visits attacker’s web site, downloads Javascript user browser local DNS resolver Query: b.bank.com QID=x 2 attacker 256 responses: Random QID y 1, y 2, … NS bank.com=ns.bank.com A ns.bank.com=attackerIP attacker wins if  j: x 2 = y j response is cached and attacker owns bank.com ns.bank.com IPaddr success after  256 tries (few minutes) 15

16 Defenses Increase Query ID size. How? Randomize src port, additional 11 bits Now attack takes several hours Ask every DNS query twice: o Attacker has to guess QueryID correctly twice (32 bits) o But the DNS system cannot handle the load 16

17 Questions?


Download ppt "Packet Filtering & Firewalls. Stateless Packet Filtering Assume We can classify a “good” packet and/or a “bad packet” Each rule can examine that single."

Similar presentations


Ads by Google