Network Security (Part #2)
Last week: TLS, Anonymous Communication
This week: Firewalls, Denial-of-Service, DNS Security
SFL @ TU Dortmund
Copyright By PowCoder代写 加微信 powcoder
Network Security
• Cryptography forms the basis for secure communication • Cryptography guarantees integrity and confidentiality
• But cryptography on its own does not meet all security goals
• How can we…
• …reliably authenticate our communication partners? (authenticity)
• …prevent others to learn about our identity? (anonymity)
• …prevent unauthorized parties to access network services?
(network-based access control)
• …protect against attackers aiming to render services offline? (availability)
• …obtain these guarantees even in existing protocols such as HTTP and DNS?
Firewalling
Firewalls: Introduction (1/2)
• Need for firewalls
• Sensitive networks are connected to Internet
• Access from the outside if without protection
• Heterogeneous environment that is vulnerable to … … software error exploitation (e.g., remote code execution) … reconnaissance attacks (e.g., scanning to find all clients) … data leakage (e.g., sensitive documents leave systems)
Organization’s Network
Firewalls: Introduction (2/2)
• Firewalling concept
• Protects an organization (inside) from Internet (outside)
• All traffic between inside and outside passes firewall • Policies determine which traffic may pass
Policies in our example:
Everyone should be able to reach our web server (www). Our remote branch may contact our FTP and DB server, too. Block any other traffic. (“default policy”)
Organization’s Network
Firewall (assumption: fully trusted)
Firewall Policies
• Firewall policies are connection-aware and use packet headers • Source and destination IP address / ports (UDP/TCP)
• IP protocol field (e.g., indicating ICMP/UDP/TCP) • Physical interface
• Define (ordered!) list of stateful rules, plus default policy 默认=丢弃:丢弃规则不允许的流量(“允许列表”)。
• Default = discard: drop traffic not allowed by rules (“allowlisting”) 默认=转发:允许未被规则丢弃的流量(“阻断列表”)
• Default = forward: allow traffic not dropped by rules (“blocklisting”) allowlisting中的默认值是，丢弃所有规则不允许的流量;
blocklisting中的默认值是，转发所有黑名单以外的流量。
允许所有源地址的流量
allow * * $WWW
仅允许来自某些分支的流量
allow $BRANCH * $FTP
http;https 80, 443
everyone to web server
our branch to FTP server
our branch to DB server
allow * * *
拒绝所有不满足上面allow条件的流量 discard * * *
ESTABLISHED
allow responses & follow-up traffic
默认策略:拒绝任何其他流量
default policy: deny any other traffic
Connection Tracking
new: 捕获了TCP handshake
established: 所有通讯和服务器的响应也需要通过防火墙，这时使用establisched状态
• Stateful firewalls track UDP/TCP connections • Connection states
• NEW: packet starts new connection/stream 数据包与现有连接相关联
• ESTABLISHED: packet is associated to existing connection
• RELATED: packet starts new connection associated to existing one (e.g., the
FTP protocol requires two TCP connections)
数据包启动与现有连接相关的新连接(例如:FTP协议需要两个TCP连接)。FTP协议需要两个TCP连接) • Delete connections if they are closed
• Timeout to deprecate inactive connections • e.g., 5 days for TCP, and 3 minutes for UDP
Firewall Placement
• Firewall placements: centralized or decentralized 堡垒主机
• Bastion host
– Special host to shield entire network with one host
– System hardened against intrusions/attacks (“secure”)
• Host-based firewall / Personal firewall
– Firewall that protects a single host (not a network)
– Either for server (host-based FW) or for client (personal FW)
– Ideally used in addition to bastion host for host-tailored rules
DMZ Networks
• DMZ: Demilitarized Zone • Separate internal from
external network (DMZ)
• Only DMZ is accessible from the outside
• Place servers that need remote access in DMZ
• All others (and clients) are in internal network, which is more restrictive
Firewall: Limitations
• Limitations
• Cannot protect against attacks that bypass firewall
• Limited protection against internal threats (insider)
• Networks bridges (e.g., open WiFi) undermine policies • Infiltrations of devices while outside (laptop, phone, …)
Denial-of-Service Attacks
Denial-of-Service
• Denial-of-Service (DoS)
• Attempt to disrupt a host, service or network
• Crash a target, or exhaust its resources (CPU, memory, bandwidth)
• DoS attack motives • Extortion
• Distraction (from other attacks)
• Hacktivism / vandalism
• Operational tactics (political, economical, …) • Financial damage
Denial-of-Service
• Examples from the history
• 1996: First in-the-wild SYN flood attack
• 2000: First large-scale DoS attack; Yahoo down for ~1h • 2005: MyTob DoS worm spreads on Windows PCs
• 2007: Estonia becomes target of nation-wide DDoS
• 2010: Operation Payback against VISA/Mastercard/… • 2015: DD4BC (Distributed DoS for Bitcoins)
• 2016: ~600 Gbit/s amplification attack against BBC • 2020: ~2.3 Tbit/s amplification attack against AWS •…
ICMP/UDP Floods
• Floods exhaust the target bandwidth (BW)
• Repeatedly send requests to target at high frequency • Successful if BWattacker >> BWtarget
• Examples
• ICMP Flood
ICMP ECHO Request ICMP ECHO Reply
ICMP ECHO Request
ICMP ECHO Reply ICMP ECHO Request
ICMP ECHO Reply
UDP Flood
Similar to ICMP flood
Choose UDP-based protocol
Issue many protocol-specific requests that will be answered by target
Target (e.g., web server)
SYN Floods (1/3): Attack
• SYN floods target the TCP stack
• SYN packet provokes server to open a half-way established TCP connection
• Server has to keep state for such connections
– Server remembers the sequence/acknowledge numbers
– Attacker does not care, as they will never complete handshake
→ Attacker can exhaust server memory by initiating many connections
• Attacker ignores SYN/ACKs
• Server has half-established TCP connections after this
TCP SYN (sport 1234, dport 80) TCP SYN/ACK (sport 80, dport 1234)
TCP SYN (sport 2345, dport 80)
TCP SYN/ACK (sport 80, dport 2345) TCP SYN (sport 3456, dport 80)
TCP SYN/ACK (sport 80, dport 3456)
SYN Floods (2/3): SYN cookies
• SYN floods are “unfair”
• Server has to remember its SEQ numbers (→stateful) • Client sends random SEQ numbers (→stateless)
• SYN cookies solve this challenge
• Idea: Encode source information in SEQ number (cookie) of SYN/ACK packet
• Server sends SYN/ACK and then “forgets” connection
• When server receives final ACK, it will validate the ACK number (cookie + 1), and if successful, reserves resources for TCP connection
SYN Floods (3/3): SYN cookies
• Cookie: 32-bit value derived from t, m, and s
• t (5 bits): wrap-around timer, increments every 64 secs
• m (3 bits): maximum segment size chosen by client • s (24 bits): HMAC over five-tuple
s = HMAC(IPserver | Portserver | IPclient | Portclient | t, secret)
C L I E N T
TCP SYN/ACK, SEQ = c TCP ACK, ACK = c+1
Compute cookie c = t|m|s
Use cookie as SEQ number in SYN/ACK
Extract cookie from ACK number (c’ = ACK – 1)
Validate c’; reserve TCP connection if valid: c’-1 =?= t’|m’|s’, where t’/m’/s’ are computed as stated above, but on ACK (not SEQ) packet
S E R V E R
Deny connection if c’ is invalid
Note: SYN cookie implementations are more complex (see “net/ipv4/syncookies.c”), but follow this idea
Distributed Denial-of-Service (DDoS)
• DDoS: DoS with multiple attack sources
• Attacker may control a botnet (network of malware-infected systems) to
launch DDoS attacks
• Volunteers may synchronize to perform DDoS attack
• DDoS effect: more attack resources than a single source
Reflection Attacks
• Send IP-spoofed request to reflector • Set source IP address to victim’s IP
• Reflectors serve connectionless protocol (ICMP, UDP, …) • Answer will be reflected to victim, instead of attacker
• Attack source remains hidden; appears distributed
(66.66.66.66) Rn
Reflectors
Amplification Attacks
• Reflectors may allow for amplifying responses • Response may be significantly larger than request
• Response may have multiple packets (instead of one) • 14+ UDP-based protocols have amplification vectors
(DNS, NTP, SSDP, NetBios, …)
(66.66.66.66) Rn
Reflectors
C. Rossow: “Amplification Hell: Revisiting Network Protocols for DDoS Abuse”, NDSS 2014.
HTTP-based Attacks: HTTP Flood (1/2)
• HTTP requests consume resources at server • Maintain TCP connection
• Read and parse HTTP request
• Fetch resources (files, DB content, …) to answer request →all this adds quickly to lots of memory/computations
• HTTP floods overload a server with requests • Require less bandwidth than UDP/ICMP floods • Attacker needs only little resources
HTTP-based Attacks: HTTP Flood (2/2)
• Perform request, but never retrieve response • Issue GET/POST request, but never recv() the reply
• Server will prepare the response and start sending
• Server has to keep response in memory until timeout
• Variation: slow-read attack
• Attack above could be detectable by server
• Instead: mimic slow client and read byte-by-byte
HTTP-based Attacks: Slowloris
• Slowloris
• Send incomplete HTTP request
• E.g., send one header per TCP segment
• Server has to wait until request is fully received
GET /my/website.htm HTTP/1.1 User-Agent: Slowloris Attack Tool 1.0 Host: www.victim.org
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Web server
HTTP-based Attacks: R.U.D.Y.
• R.U.D.Y. (Are You Dead Yet) Attack
• Send POST request and specify large content length
• Then slowly send POST body (parameter by parameter) • Server will have to keep incomplete body in memory
POST /my/script.cgi HTTP/1.1
Content-Type: application/x-www-form-urlencoded Content-Length: 666666
Web server
received 3 bytes, 666663 coming
great, 7 bytes, just 666659 to go
now at 11 bytes, still 666655 missing
HTTP-based Attacks: Compression bombs
• HTTP supports compressed requests/responses
• Body can be gzip-compressed
• Intuition: Attacker sends small compressed payload that inflates to large
content when decompressed (zip bomb)
• Attack fills memory of attacker while unpacking
decompress
Web server
POST /upload HTTP/1.1 Content-Encoding: gzip
G. Pellegrino et al.: “A Security Study of Data Compression in Network Services”, USENIX Security 2015.
DNS-based Attacks: Water Torture Attack (a.k.a. NXDOMAIN attack or random subdomain attack)
• Overload authoritative name server with queries
• Vary the domain prefix to avoid being cached
• Instead of directly sending requests, use open resolvers
– Water torture is a seemingly distributed attack (many sources)
– Open resolvers will retry lookups if NS is overloaded
ORN NS for victim.org Open resolvers
DoS Defenses (1/3): Upstream filters
• Upstream filters at higher-level providers
• Stop the attack traffic as early as possible
• Higher-level ISPs have more bandwidth than victim
• General ideas
• Blackholing
– Block all traffic to target IP address
– Target becomes unavailable, target network remains operative
• Scrubbing
– Redirect traffic to scrubbing center that has “enough” resources
– Apply traffic filters before directing clean traffic to victim
DoS Defenses (2/3): Anti-Spoofing
• Block spoofed traffic
• Providers only allow traffic to leave their network if it is using IP addresses
that belong to the provider
• Identify spoofing source
• IP traceback: mark packets along the route
• Each router appends its IP address
• Similar to Record Route option, but router-enforced
• Probabilistic marking schemes (mark every nth packet)
DoS Defenses (3/3): Traffic Shaping
• Traffic shaping
• Rate limiting: Allow only up to a maximum request/packet frequency per
client/network
• CAPTCHAs: Let clients solve tests before they can continue using service (mostly HTTP)
• Reputation-based blocking
– Identify attackers (if possible) and block them
– Identify benign clients and block anyone else
Security & Privacy in DNS
DNS – A Brief Recap
• Interplay between client, resolver(s) and authoritative name servers • Application queries stub resolver for recursive lookup
• Stub resolver forwards query to recursive resolver
• Recursive resolver iteratively queries authoritative NSes
Application Cache
Stub Resolver Cache
www.exmpl.de?
iterative queries www.exmpl.de?
NS .de @ …
www.exmpl.de? NS exmpl.de @ …
www.exmpl.de? 1.2.3.4
. (root) de. exmpl.de.
Recursive Resolver
recursive query
gethostbyname()
authoritative name servers
DNS Caching Attacks
• Caches of resolvers are valuable attack target
• Cache snooping: Inspect the contents to see usage of resolver ( ) • Cache poisoning: Insert/manipulate entries to redirect clients ( )
Application Cache
Stub Resolver Cache
www.exmpl.de?
iterative queries www.exmpl.de?
Recursive Resolver
NS .de @ …
www.exmpl.de? NS exmpl.de @ …
www.exmpl.de?
www.exmpl.de? www.exmpl.de @ 1.2.3.4
recursive query
www.exmpl.de @ 6.6.6.6
gethostbyname()
authoritative name servers
DNS Cache Snooping
• Attack goal: Did a client recently visit domain X? • Threat model: Attacker and victim use same resolver
• Basic idea: Attacker probes resolver for cached entries
• Probes do not ask for recursion (set RD=0) to prevent “poisoning” the cache
• Threat to security and privacy
• Find out which sites have been visited
– Of which bank is the victim a customer?
– Does the victim visit certain (possibly illegal?) websites?
• Find out visiting patterns
– When does the victim visit a website (inspect TTL)?
[Snooping]: http://cs.unc.edu/~fabian/course_papers/cache_snooping.pdf
DNS Cache Poisoning
• Attack goal: Inject attacker-specified RRs to resolver cache
• An attacker that controls the cache also controls future DNS lookups
• Various malicious goals • MITM attacks
• Redirect clients to malicious web sites
• Redirect mail traffic to mail server under attacker control • Disable domains (e.g., censorship, extortion, etc.)
• Main techniques:
• Response spoofing
• Out-of-bailiwick responses
DNS Cache Poisoning via Response Spoofing (1/3)
• Response spoofing
• Threat model: Attacker can trigger arbitrary domain requests to recursive
resolver of the victim
• Basic idea: Attacker guesses when the resolver queries a domain and aims to send fake responses
• Steps to response spoofing
1. Trigger name resolution
2. Send fake response to poison cache
3. Genuine response arrives later & is ignored
target.de? target.de @ 6.6.6.6
target.de?
target.de @ 1.2.3.4 de.
Recursive Resolver
DNS Cache Poisoning via Response Spoofing (2/3)
• Ways to trigger requests to target domain
• Recursive resolver serves name resolution to everyone
(is configured to be an open resolver), or
• Lure user behind resolver to visit an attacker-controlled web site (elements point to target domain)
• Send email with embedded elements that point to target domain
target.de? target.de @ 6.6.6.6
target.de?
target.de @ 1.2.3.4 de.
Recursive Resolver
DNS Cache Poisoning via Response Spoofing (3/3)
• How can an attacker build a “correct” response?
• Resolver will only accept certain responses
• Several conditions have to be met in the faked response
– Domain name has to match domain name of request
– Source IP address has to be the one of the authoritative NS
– Destination port has to be the request’s source port
– Message ID has to match request’s message ID
target.de? src = 6.6.6.6, dst = 8.8.8.8, sport = 5678, dport = 53, DNS ID = 0x4711
target.de @ 6.6.6.6, src = 1.2.3.4, dst = 8.8.8.8, sport = 53, dport = 53, DNS ID = XXXX target.de @ 6.6.6.6, src = 1.2.3.4, dst = 8.8.8.8, sport = 53, dport = 53, DNS ID = YYYY target.de @ 6.6.6.6, src = 1.2.3.4, dst = 8.8.8.8, sport = 53, dport = 53, DNS ID = ZZZZ
target.de? src = 8.8.8.8, dst = 1.2.3.4, sport = 53, dport = 53, DNS ID = 0x0815 target.de @ 1.2.3.4, src = 8.8.8.8, dst = 1.2.3.4, sport = 53, dport = 53, DNS ID = 0x0815
Recursive Resolver
DNS Response Spoofing Defenses (Part #1)
• Defense: Increase entropy of iterative requests
• Randomize source port (instead of static port 53)
– Additional ~216 bits that the attacker has to match
– Subset of non-privileged ports (> 1023) is used
• 0x20 bit encoding
– Randomize the capitalization of requested domains
– DNS is case-insensitive, but auth. NS preserve capitalization
– Example: request wWw.exAmpLE.coM (bits: 0100010011001)
– Replies not matching the exact capitalization are ignored
[0x20Encoding]: https://classes.soe.ucsc.edu/cmps223/Spring09/Dagon%2008.pdf
DNS Cache Poisoning via Out-of-Bailiwick Responses (1/2)
• Out-of-bailiwick responses
• Threat model: Attacker can trigger name resolution and controls its own
authoritative NS for arbitrary domain
• Basic idea: Inject responses to unrelated target domains and hope that resolver will cache them
www.attacker.de?
Recursive Resolver
www.attacker.de? NS @ 7.8.9.0
www.attacker.de?
www.target.de @ 6.6.6.6
attacker.de.
• Defense: resolver has to check if reply is in-bailiwick (i.e., is in the authority of the responding name server)
[Schuba1993]: https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf (Section 3.3.4)
DNS Cache Poisoning via Out-of-Bailiwick Responses (2/2)
• Kaminsky attack
• Basic idea: Hijack authority records (and not answer) and trigger multiple
name lookups via NX subdomains
• Gives attacker control over an entire zone
• Endlessly many trials with arbitrary subdomains: Significantly increases chance for success
nx11111.target.de?
NXDOMAIN nx11111.target.de; Auth: target.de NS ns.target.de; Glue: ns.target.de @ 6.6.6.6
nx22222.target.de?
NXDOMAIN nx22222.target.de; Auth: target.de NS ns.target.de; Glue: ns.target.de @ 6.6.6.6
nx33333.target.de?
NXDOMAIN nx33333.target.de; Auth: target.de NS ns.target.de; Glue: ns.target.de @ 6.6.6.6
Recursive Resolver
[IETF2008]: https://www.ietf.org/mail-archive/web/dnsop/current/pdf2jgx6rzxN4.pdf
DNS Security Protocols: DNSSEC & DoT/DoH
• DNS over TLS/HTTPS (DoT/DoH) provides
• Confidentiality and integrity on the client-to-resolver path☺
• Massive centralization of the (historically hierarchical) DNS communication to few resolvers
• DoT/DoH does not provide guarantees about/beyond resolver
• DNSSEC provides • Data integrity
• Origin authentication
• Authenticated denial of existence
• DNSSEC does not…
• …provide confidentiality
• …protect client-to-resolver communication
DNS over TLS/HTTPS
• DNSSEC signs DNS resource records
• Off-the-shelf public-key cryptography signatures • Attacker cannot spoof signed records
• Additional DNSSEC resource record types
•RRSIGcontains signature
•DNSKEYcontains public key to verify signature •DScertifiesDNSKEYrecords (parent zone becomes “CA”→transitive trust) •NSEC/NSEC3for provable NXDOMAIN responses
RRSIG example for A record of “dfn.de”
$ dig +dnssec dfn.de A
dfn.de. 60 IN A 194.95.245.140 dfn.de. 60 IN RRSIG A 13 2 60 20201202145850 20201108110910 15867 dfn.de. Y5o1ydn6zKjlzHS9eVLt0yNsUmTpOBlFcUjjZujuAylPgAX85/SgFk9W i0WDD61ihd4DVnzOANH+TkMoldptXQ==
DNSSEC: Deployment Status
• Root zone and many TLDs are signed by now
• Only signed TLDs can have DNSSEC-protected SLDs
• DoT/DoH wrap DNS traffic in TLS/HTTPS, respectively
• Application is client side (e.g., browser)
• DNS resolver is
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com