Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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?