read. It’s a terriﬁc 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 ﬁxed 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!
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 oﬀ from correct DNS information! (Imagine highway networks if GPS suddenly failed. Yeah.)
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 ﬁrst 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.
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.
Convince an endpoint or DNS resolver of an incorrect match between domain name and IP address: e.g. send wisc.edu traﬃc to the IP address of an attacker’s machine. ✦ DNS ﬂooding ✦ Send a ton of legitimate-looking DNS requests to a DNS server. Watch it fall over dead, or drop legitimate requests. ✦ “DNS ampliﬁcation” 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.)
tells lots of folks on the network where you’re surﬁng. ✦ “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 traﬃc on your local network, and whoever’s providing you with Internet access (your ISP, the coﬀeeshop’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 ﬁx(ish) and one in-progress ﬁx ✦ Current ﬁx(ish): Cloudﬂare’s 188.8.131.52 DNS service. I recommend it, even though it’s unwise to rely on one company for anything this serious! ✦ In-progress ﬁx: secure DNS. “Oblivious DNS” uses public/private keys to hash domains between your device and DNS servers, to avoid Eves.
✦ 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. Proﬁt, 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.
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 oﬀ a server. Ouch.) ✦ DNSSEC is exploitable to create DDoS attacks. ✦ It’s better than nothing, but it needs work.
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 certiﬁcate 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…
layer (aka “link layer”) Internet layer Transport layer Application layer Responsible for doing end-user things. Protocols: speciﬁc 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
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] spooﬁng” attacks against almost all protocols in the network layer cake, as well as content-alteration attacks.
“only what you need to know right now” vast oversimpliﬁcation) ✦ Cables: ﬁber 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 ﬁnd 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
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 diﬀerent 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!
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 staﬀ computers, public-access computers (yikes! super- easy to attack!), and a public wiﬁ network (ARGH HIGH-RISK). ✦ Put the staﬀ computers on one switch, the public computers on another, wiﬁ equipment on a third. Connect all switches to a fourth switch. ✦ The fourth switch acts as the blockade cop: it sends staﬀ data only to the staﬀ switch, public-computer data only to the public-computer switch, wiﬁ data only to the wiﬁ switch. ✦ If one part of your network has more or diﬀerent attack risks than another, this can keep attacks conﬁned and limit damage from them. ✦ The segmentation I described for our library means attackers can’t easily snoop on (or migrate into) the staﬀ network from public machines or wiﬁ.
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 exﬁltrated lots of.
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 ✦ Wiﬁ APs are not designed to encrypt traﬃc 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.)
✦ 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 spooﬁng” ✦ 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 spooﬁng to work. Means getting past routers/ﬁrewalls, and being on the right network segment! ✦ Addressing: “Ethernet frame” ✦ Header with MAC addresses of the data’s source and destination machines.
into small PACKETS for sending ✦ This helps the Internet recover better/faster from network problems. ✦ Packets take diﬀerent 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 ﬁxed 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 diﬀerent.
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).
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.
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 ﬁrewalls and IDSes into believing that someone inside the target network initiated the connection— which means the connection gets less scrutiny for Bad Stuﬀ.
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 ﬁrewalled. ✦ 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 ﬁrewalls!
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) traﬃc? ✦ 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?!”
its best to detect and block attacks coming in from the Internet. ✦ On Linux, the commonest ﬁrewall 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 ﬁrewalls.” Think of these as ﬁrewall-software-in-a-box.) ✦ Endpoints often have their own ﬁrewalls as well, and that’s usually a decent idea! I encourage you to ﬁnd out about and turn on ﬁrewalls in Windows, Mac OS, or Linux (whichever you use).
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 ﬁrewall 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 speciﬁcally to evade ﬁlters. ✦ One weakness in initial ﬁltering approaches: they were one-packet-at- a-time (“stateless”). So attackers split attacks into multiple packets!
reassembling packets). They can ﬁnd and ﬁlter more attacks this way. ✦ “Stateful” means something like “aware of [a packet’s] context.” ✦ Even so, the ﬁrewall is still relying on signatures —clues in the headers. ✦ And as always, attackers can and do design attacks that don’t look like what ﬁrewalls are used to seeing! ✦ Stateful ﬁrewalls 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…
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 oﬀ, 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 ﬁrewall is much more likely to leave it alone!
they try to stop attacks from the outside network before they can aﬀect anything on the inside. ✦ Issues with this: ✦ Once an attacker gets past the ﬁrewall, the ﬁrewall 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.
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 ﬁrewall 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 ﬁrewall “reject requests to port 80 unless they’re to this speciﬁc IP address” but that gets very messy very fast for the systems administrator (IP addresses change!). ✦ Solution: Have two perimeters. ✦ Put stuﬀ with more modest Internet-communication needs behind the inner (stricter, more secure) perimeter. ✦ Put stuﬀ like web servers that communicate more broadly behind the outer ﬁrewall, but NOT the inner one. The area between is the DMZ.
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/conﬁguring 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 proliﬁc 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.