Packet Filtering & FirewallsPacket Filtering & FirewallsPacket Filtering & FirewallsPacket Filtering & Firewalls

Stateless Packet FilteringStateless 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)to examine the rules)

Stateless rulesStateless 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 • 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)

StatefulStateful Packet FilteringPacket 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

Complex ProtocolsComplex 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)

DNS & DNS AttacksDNS & DNS AttacksDNS & DNS AttacksDNS & DNS Attacks

DNS Lookup ExampleDNS Lookup Example

Local DNS

root & edu DNS server

stanford.edu DNS server

www.cs.stanford.edu

ClientLocal DNS resolver

DNS server

cs.stanford.eduDNS 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

CachingCaching• 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 cachedo Save time for nonexistent sites, e.g. misspelling

• Cached data periodically times outo Lifetime (TTL) of data controlled by owner of data

o TTL passed with every record

8

DNS PacketDNS Packet• Query ID:

o 16 bit random value

o Links response to query

(from Steve Friedl)9

Resolver to NS requestResolver to NS request

10

Response to resolverResponse to resolver

Response contains IP addr of next NS server(called “glue”)

Response ignored if Response ignored if unrecognized QueryID

11

Authoritative response to Authoritative response to resolverresolver

bailiwick checking:response is cached ifit is within the same domain of query(i.e. a.com cannot

final answer

(i.e. a.com cannot set NS for b.com)

12

Basic DNS VulnerabilitiesBasic 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 • 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

DNS cache poisoning DNS cache poisoning (a la Kaminsky(a la Kaminsky’’0808))

• Victim machine visits attacker’s web site, downloads Javascript

userbrowser

localDNS

resolver

Query:a.bank.com

a.bank.comQID=x1 ns.bank.com

IPaddrresolver

attackerattacker wins if j: x1 = yj

response is cached andattacker owns bank.com

IPaddr

256 responses:Random QID y1, y2, …NS bank.com=ns.bank.comA ns.bank.com=attackerIP

14

If at first you If at first you don’t don’t succeed …succeed …

• Victim machine visits attacker’s web site, downloads Javascript

userbrowser

localDNS

resolver

Query:

b.bank.com

b.bank.comQID=x2 ns.bank.com

IPaddrresolver

attacker

256 responses:Random QID y1, y2, …NS bank.com=ns.bank.comA ns.bank.com=attackerIP

attacker wins if j: x2 = yj

response is cached andattacker owns bank.com

IPaddr

success after 256 tries (few minutes)15

DefensesDefenses• 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

Questions?Questions?