Server security

Transcript

1. Server security Dorothea Salo
2. Standards design again: BGP ✦ I won’t rehash what you read. It’s a terrific piece. ✦ A few things to focus on: ✦ Tension between security and Getting Things Done (“rough consensus and running code”). Getting Things Done tends to win; it sure did with BGP. This is a net negative for security, which requires a much more deliberate and thoughtful approach. ✦ Lemon market! Consumers wouldn’t buy more-expensive-but-more- secure equipment! ✦ The crisis-reactivity of security, so often. Nothing gets fixed until something breaks so incredibly damagingly and obviously that longstanding problems can’t be ignored any longer. ✦ Nation-states are consciously and deliberately attacking the Internet. I’ve been glossing over this because political science is not my thing, but I hope you’ve been noticing!
3. Domain Name System (DNS)
4. Hugely important system: DNS ✦ DOMAIN NAME SYSTEM ✦ matches domain names like wisc.edu to the IP address(es) of the machines (webservers, mail servers, etc) that the domains live on ✦ DNS RESOLVER: takes a domain name, “resolves” it to its IP address ✦ Hierarchical: relies on “[DNS] ROOT SERVERS” ✦ So when your phone needs the IP address for wisc.edu, it (usually) contacts the DNS resolver for the network the phone is on. If that resolver knows, it answers. If not, the resolver asks the next DNS resolver up in its network, and so on up (to a root server, if necessary) until it gets an answer to pass back to your phone. ✦ Dyn, which got Mirai-botnet DDoSed: not actually a DNS root server, but an incredibly well-used and important resolver! So without it, an awful lot of networks were cut off from correct DNS information! (Imagine highway networks if GPS suddenly failed. Yeah.)
5. How do you get a domain name in the first place? ✦ And how is it mapped to the IP address of the machine(s) hosting the domain? ✦ First, you register the domain name with a domain REGISTRAR. ✦ Registrar checks to be sure the domain name isn’t already taken. ✦ If it’s not, you pay the registrar money and give them your personal information, and bam! domain is yours, until your registration expires. ✦ Next, you get a (web)HOST for your new domain. ✦ Practically the first thing your new host will tell you is the name(s) of its “nameserver(s).” These are DNS resolvers that keep track of the IP addresses of all the host’s machines, as well as which domain name is hosted on which machine. ✦ You tell your registrar about your host’s nameservers so the registrar knows where to send machines asking for the IP address of your domain name.
6. Learning a domain’s registrar, host, and nameservers ✦ Command line: type whois dsalo.info ✦ If this doesn’t work, open your browser and go to whois.net. ✦ In the response, lines starting with Registrar: are, unsurprisingly, registrar information. ✦ The registrar I use is NameCheap. ✦ Lines starting with Name Server: are, also unsurprisingly, nameserver information. ✦ Most times, the webhost will be human-readable in the nameserver’s name. You can see that I’m hosted by reclaimhosting.com, right? ✦ Notice that the Registrant: info is obfuscated. ✦ I don’t need to tell you why I do that, do I? I didn’t think I did.
7. Attacks on or via DNS ✦ DNS [cache] poisoning ✦ Convince an endpoint or DNS resolver of an incorrect match between domain name and IP address: e.g. send wisc.edu traffic to the IP address of an attacker’s machine. ✦ DNS flooding ✦ Send a ton of legitimate-looking DNS requests to a DNS server. Watch it fall over dead, or drop legitimate requests. ✦ “DNS amplification” a similar nasty trick: attacker sends a ton of DNS requests to various DNS servers, directing them to respond to the target’s IP address. Watch target’s Internet connection die! ✦ DNS/domain hijacking ✦ Modify a domain’s DNS (nameserver) records at its domain registrar to point to the wrong place. (If you’ve ever lost a domain name and had it taken over by some sleazy ad purveyor… yeah, it’s like that.)
8. DNS and surveillance ✦ A DNS request from your device tells lots of folks on the network where you’re surfing. ✦ “Somebody gimme the IP address for AshleyMadison.com!” That’s an extreme example, but yes, domain names can be revealing metadata. ✦ Snoopers include: all DNS servers between you and your answer, anybody listening to DNS traffic on your local network, and whoever’s providing you with Internet access (your ISP, the coffeeshop’s ISP…) ✦ And in fact, US ISPs can now legally collect and sell this information, tying it directly to you. Gee, thanks for overruling the FTC, Congress! ✦ One current fix(ish) and one in-progress fix ✦ Current fix(ish): Cloudflare’s 1.1.1.1 DNS service. I recommend it, even though it’s unwise to rely on one company for anything this serious! ✦ In-progress fix: secure DNS. “Oblivious DNS” uses public/private keys to hash domains between your device and DNS servers, to avoid Eves.
9. DNS typosquatting and homograph attacks ✦ Typosquatting: a longtime thing ✦ Grab a domain that’s a letter-transposition (googel.com) or easy typo (googld.com) away from a super-common destination. Put ads or malware on it. Profit, you garbage human you! ✦ HOMOGRAPH ATTACK: like typosquatting with Unicode ✦ UNICODE: system for representing lots of writing systems on computers ✦ DNS changed to allow Unicode in domain names around 2010. ✦ Many writing systems have letters that resemble letters in other writing systems! So an attacker can register a domain that looks like google.com… but isn’t, because the letters aren’t from the English alphabet. ✦ Phish and malware away! Human beings will have a terribly hard time noticing they aren’t going to the right domain, even if they check the URLs they’re clicking on (which most don’t anyway). ✦ You don’t absolutely need Unicode for this (0 and O, 1 and l), but it helps.
10. DNSSEC ✦ Is Schneier’s “long wait” over? ✦ DNSSEC lets a device authenticate (via digital signatures) that a DNS response is coming from somewhere trustworthy. ✦ It hasn’t been a perfect solution so far. ✦ It can reveal the existence of subdomains (e.g. library.wisc.edu is a subdomain of wisc.edu) that the domain owner didn’t want revealed. ✦ Keeping private keys truly private, when they’re fueling a public protocol, can be tough. (The Heartbleed bug was exploitable to grab private keys off a server. Ouch.) ✦ DNSSEC is exploitable to create DDoS attacks. ✦ It’s better than nothing, but it needs work.
11. Questions? Ask them! This lecture is copyright 2018 by Dorothea Salo. It is available under a Creative Commons Attribution 4.0 International license.
12. How networks work: a primer
13. Networks are layer cakes! ✦ (You may hear someone talk about “the [seven-layer] OSI model” for networks. Pull a Patsy here: it’s only a model, and it’s not how real networks work, so I’m skipping it. Memorize it for cybersec certificate testing when you must, then forget it exists.) ✦ Each “layer” of a fully-functioning network has one or more (usually more) associated PROTOCOLs. ✦ PROTOCOL: agreed-upon method for two devices on a network to interact, in order to handle and/or exchange data. ✦ The “P” in a lot of internet-related acronyms: HTTP, SMTP, IP, TCP… ✦ Because networks exist to move data between machines, expect each layer and its protocol(s) to have an associated addressing system. ✦ Metaphor: letter inside envelope inside envelope inside envelope…
14. Here’s the cake (“TCP/IP model” “Internet protocol model”) Network access layer (aka “link layer”) Internet layer Transport layer Application layer Responsible for doing end-user things. Protocols: specific to the software or service you’re using, e.g. HTTP(S) for the web, SMTP and IMAP for email. Responsible for reassembling data and presenting it to applications. Protocols include: TCP, UDP. This is the “port” layer. Responsible for chopping up data into packets, addressing packets, and getting them across networks. Protocols include: IP, BGP Responsible for connecting devices to the local network. Protocols: ARP, DHCP, Ethernet, 802.11x, various cellular-network protocols
15. Hackable envelopes! ✦ You’re Eve. You’re intercepting snailmail between Alice and Bob. You don’t want them to know. ✦ What you probably do is open the envelope carefully, read the contents, then reseal and resend it. ✦ (By the way, in the US tampering with snailmail is ILLEGAL. DO NOT.) ✦ You have at least two other options, though: ✦ You can alter/replace the contents in the envelope and reseal it. ✦ You can alter (“spoof”) either the sender’s or recipient’s address on the envelope by sticking a new label on the envelope. (Send Alice’s tax return to a blackmailer instead of Alice’s accountant Bob!) ✦ There are “[address] spoofing” attacks against almost all protocols in the network layer cake, as well as content-alteration attacks.
16. Each cake layer, one at a time from the bottom up
17. Network access layer, wired: cables, hubs, switches, routers ✦ (an “only what you need to know right now” vast oversimplification) ✦ Cables: fiber or “CAT-#” where # is usually 5 or 6 ✦ It’s very, very hard to surveil data traveling over a cable—even harder to do so undetectably. Other parts of the link layer are usually weaker. ✦ Network hubs: Practically nobody uses these any more, and for good reason. ✦ Designed to spray all incoming data at all attached devices, trusting each device to grab only what is intended for it. ✦ This is. Um. Inherently insecure and unprivate! Useful for infosec workers, though—they’re the only folks who still find hubs useful. ✦ Network switches: Smarter than hubs ✦ Only sends data to the attached device the data is intended for. ✦ Routers: Connect networks to other networks
18. Neighborhood access: an analogy to NETWORK SEGMENTATION ✦ Imagine a bunch of cul-de-sacs with houses. ✦ Imagine that there’s a police blockade at the entry to each cul-de-sac. ✦ Within a cul-de-sac, a car carrying data can park at any house. ✦ But it can’t get to a different cul-de-sac without running into a blockade! ✦ So the cul-de-sacs are segmented—separated from one another. ✦ Cul-de-sac = network, and that’s network segmentation in a nutshell!
19. Important switch security trick: NETWORK SEGMENTATION ✦ You can connect switches to other switches! ✦ This enables you to isolate one part of your internal network from the other parts, building cul-de-sacs. ✦ Imagine a library with staff computers, public-access computers (yikes! super- easy to attack!), and a public wifi network (ARGH HIGH-RISK). ✦ Put the staff computers on one switch, the public computers on another, wifi equipment on a third. Connect all switches to a fourth switch. ✦ The fourth switch acts as the blockade cop: it sends staff data only to the staff switch, public-computer data only to the public-computer switch, wifi data only to the wifi switch. ✦ If one part of your network has more or different attack risks than another, this can keep attacks confined and limit damage from them. ✦ The segmentation I described for our library means attackers can’t easily snoop on (or migrate into) the staff network from public machines or wifi.
20. In practice, network segmentation is often done with software rather than hardware these days. But I find hardware-based segmentation easier to understand, so.
21. Our buddies at Equifax! ✦ The House report points out that Equifax’s network was not appropriately segmented. ✦ This means that some machines were too easy to get to once the attacker was inside the network. ✦ This helped the attacker, once they got into the web server via Apache Struts, migrate across Equifax’s systems until they found the Big Personal Data Database that they then exfiltrated lots of.
22. Network access layer, wireless: wifi, cellular, other ✦ Wifi: the 802.11x series of protocols, where “x” may be “a” “b” “g” “n” or “ac” (with more coming) ✦ Hardware: “ACCESS POINT,” usually wired, to relay data to/from switches and/or routers; “REPEATER” to increase AP coverage ✦ Wifi APs are not designed to encrypt traffic between them and attached devices!!!!! (Yes, this is total protocol design FAIL.) ✦ Cellular: a grab-bag of protocols ✦ Others: mesh networks, whitespace broadband, various other ideas ✦ Few have much market penetration; I mention them just so you know they exist. (Mesh networks in particular are pretty great.)
23. Access layer addressing and packaging ✦ ARP: Address Resolution Protocol ✦ Network switch, to all attached devices: “Hey, I got some data for IP address 127.0.0.1. Raise your hand (and give me your network card’s MAC address) if you’re the machine on the network that has the IP address 127.0.0.1!” ✦ That machine responds: “That’s me; here’s my MAC address.” ✦ Common attack: “ARP spoofing” ✦ Attacker responds: “That’s me; here’s my MAC address. Yep. Totally 100% me.” ✦ The switch may not check! It will cluelessly send data to the wrong machine. (Again, clever attackers turn this into a full man-in-the-middle attack, relaying data between switch and destination as though nothing had happened.) ✦ Attacker has to attach a device to (or pwn a device on) the internal network (a switch!) for ARP spoofing to work. Means getting past routers/firewalls, and being on the right network segment! ✦ Addressing: “Ethernet frame” ✦ Header with MAC addresses of the data’s source and destination machines.
24. Next layer up: Internet layer (IP) ✦ Chops up data into small PACKETS for sending ✦ This helps the Internet recover better/faster from network problems. ✦ Packets take different routes through the network to their destinations. ✦ Two IP versions: IPv4 and IPv6 ✦ Why? IPv4 did not envision the Internet’s growth! IPv4 doesn’t have enough addresses to give out to all the machines that want them. ✦ But while Internet engineers fixed this with IPv6, they added in other bells and whistles too, some of them security-related. ✦ Addressing: “IP header” ✦ Like Ethernet frames, contains source and destination addresses; they’re just IP addresses rather than MAC addresses. ✦ (All addressing headers have more info than just addresses, but I’m eliding it—not least because I’m super-bad at reading headers.) ✦ IPv4 and IPv6 headers are completely different.
25. Third layer: transport layer ✦ TCP: Transfer Control Protocol ✦ Maintains connections (“SOCKETS”) between machines exchanging data. ✦ Keeps track of which packets belong to what larger set of data in which order. ✦ Labels packets with their dataset and which piece of it they are on the way out; reads the labels and reassembles the data on the way in. ✦ Addressing: “TCP header” ✦ Again, source and destination addresses: this time, port numbers. ✦ Also contains packet-sequencing data (“this is the Nth packet in dataset number M.”) ✦ UDP: “User Datagram Protocol” ✦ Not anywhere near as common as TCP; its major uses today are as part of DHCP (assigning IP addresses to devices just joining a network) and the Domain Name System (hold that thought).
26. The TCP SYN-ACK dance (“three-way handshake”) ✦ Source: sends SYN packet to destination ✦ Stands for “synchronize.” There’s a special spot (“SYN bit”) in the TCP header for labeling a packet a SYN packet. ✦ Destination: sends SYN-ACK packet back ✦ ACK = “acknowledgement.” Again, there’s an ACK bit in the header, so a SYN-ACK packet has both SYN and ACK bits set. ✦ Source: sends ACK packet ✦ And then source and destination have a “TCP socket” (= connection) and start exchanging data. ✦ Similar dance when the destination is done getting data from the source.
27. TCP handshake attacks ✦ SYN flooding ✦ Send a lot of SYN packets to the target. Target then SYN-ACKs. Attacker remains silent (never sending ACK). Target waits… and waits… and if it’s waiting for enough ACKs, it falls over dead. ✦ One DDoS attack technique (though these days it’s heavily defended against, so not as common as it used to be) ✦ “Split-handshake” attacks ✦ There’s another (rare) kind of TCP handshake. It’s possible for an attacker to pretend it’s doing the rare TCP handshake, then “change its mind” and start in from the SYN-ACK part of the regular three- way TCP handshake. ✦ This can confuse targets and their firewalls and IDSes into believing that someone inside the target network initiated the connection— which means the connection gets less scrutiny for Bad Stuff.
28. TCP handshakes and firewalls ✦ Let’s say a source sends a SYN packet to a destination port that’s closed. ✦ Knocking on a closed door. “Hey, port 80, is there a website here?” ✦ To say “No. Port’s closed. Go away!” the destination returns a RST (“reset”) packet instead of a SYN-ACK packet. ✦ Oh! Hey! Now attackers have an easy way to detect open vs. closed ports! Um. ✦ Firewalls shut this down by never allowing RSTs. ✦ So attackers can’t know if a port is truly closed, or just firewalled. ✦ Even better, they can’t tell whether the problem is actually network congestion, so they send more SYNs… slowly… which slows down attack speed. Yay firewalls!
29. I think that’s enough to go on with. Questions? Ask them! This lecture is copyright 2018 by Dorothea Salo. It is available under a Creative Commons Attribution 4.0 International license.
30. Network security and its headaches
31. The basic dilemma ✦ Networks are for communication. ✦ Attackers from the outside network communicate with the inside network. ✦ But so do non-attackers! ✦ How do you distinguish attackers from non- attackers? How do you distinguish attacks from ordinary (or even unusual-but-unmalicious) traffic? ✦ Keep in mind that false positives—mistaking a non-attacker for an attacker—have real consequences! “Hey, why did my laptop’s Internet suddenly break?!”
32. What’s a firewall? ✦ A piece of software that does its best to detect and block attacks coming in from the Internet. ✦ On Linux, the commonest firewall software is called “iptables.” ✦ Works on packet headers/metadata. Does not try to inspect the actual data (“payload”)! ✦ Firewall software usually lives on/near the router(s) between a given network and the larger Internet. ✦ (You may read or hear about “hardware firewalls.” Think of these as firewall-software-in-a-box.) ✦ Endpoints often have their own firewalls as well, and that’s usually a decent idea! I encourage you to find out about and turn on firewalls in Windows, Mac OS, or Linux (whichever you use).
33. The signature approach to firewall filtering ✦ Like malware files, network-based attacks sometimes have obvious “signatures.” ✦ For example, “telnet” is an ancient insecure protocol that basically nobody except attackers presently uses. So anybody asking for a telnet connection can be presumed to be an attacker. ✦ So a firewall can watch for attack signatures and both block the attacker’s packets and stop the network responding to the attacker. ✦ Attackers have responded by designing attacks specifically to evade filters. ✦ One weakness in initial filtering approaches: they were one-packet-at- a-time (“stateless”). So attackers split attacks into multiple packets!
34. “Stateful” firewalls ✦ These examine whole streams of data (by reassembling packets). They can find and filter more attacks this way. ✦ “Stateful” means something like “aware of [a packet’s] context.” ✦ Even so, the firewall is still relying on signatures —clues in the headers. ✦ And as always, attackers can and do design attacks that don’t look like what firewalls are used to seeing! ✦ Stateful firewalls have to be carefully tuned. ✦ What counts as an attack for a given network varies, depending on what services and software are running inside that network. ✦ For example, is there a web server in there somewhere? If not, anyone asking for HTTP(S) data is an attacker. But if there IS a web server…
35. Inside-out vs. outside-in ✦ Firewalls inspect packets coming from the Internet a lot more closely than packets going out to the Internet from the inside network. ✦ You can probably intuitively see why this would be so. But if your insider-threat alarms are going off, good for you! ✦ Attacker responses: ✦ Gain network access physically (get into the building!). ✦ Pwn a machine (or a person!) inside the network, of course. ✦ If a total pwning isn’t possible, try to con a machine inside the network into initiating a network connection with the attacker’s outside machine. (If you see the phrase “REVERSE SHELL,” this is what that means.) Because an inside machine made the initial connection, the firewall is much more likely to leave it alone!
36. Perimeter defense problems ✦ Firewalls are “perimeter defenses,” meaning that they try to stop attacks from the outside network before they can affect anything on the inside. ✦ Issues with this: ✦ Once an attacker gets past the firewall, the firewall can’t do anything about the attack! (Once a burglar picks the lock on your house…) ✦ One single perimeter won’t work for the entire inside network. Some machines need more (or less) protection than others! So a single perimeter will both over- and under-protect.
37. DMZs ✦ Within a network, different endpoints have different Internet-communication needs. ✦ An employee’s laptop should reject all attempts to connect to it as though it were a web server. A web server, obviously, should not! ✦ So should the firewall protecting the whole network (laptop and server included) accept all incoming requests on port 80, or reject them all? ✦ In practice, it is possible to tell a firewall “reject requests to port 80 unless they’re to this specific IP address” but that gets very messy very fast for the systems administrator (IP addresses change!). ✦ Solution: Have two perimeters. ✦ Put stuff with more modest Internet-communication needs behind the inner (stricter, more secure) perimeter. ✦ Put stuff like web servers that communicate more broadly behind the outer firewall, but NOT the inner one. The area between is the DMZ.
38. IDSes/IPSes/SIEMs ✦ Intrusion Detection System: like a firewall, but also inspects data/payloads, internal network, sometimes even endpoints ✦ Reports/logs apparent intrusions (attacks), but classically does not do anything else with them, because IDSes are false-positive-prone. ✦ Intrusion Prevention System: like an IDS, but blocks attacks once it detects them ✦ Tuning/configuring IPSes is CRITICAL because of the false-positives problem. ✦ Security Incident and Event Management ✦ Firewalls and IDSes and IPSes and other security tools are proliferating like… a very prolific thing. They all emit logs and alerts and reports. ✦ SIEM tools try to tame the log/alert/report chaos, e.g. reducing false positives, auto-building human-readable displays, etc. ✦ Confused? Reasonable. It’s a confusing space.
39. Questions? Ask them! This lecture is copyright 2018 by Dorothea Salo. It is available under a Creative Commons Attribution 4.0 International license.