class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 24:] .title[Virtual private networks] ] --- # Today ### Network perimeters ### Network threats ### VPNs ### DIY --- # Network security (traditional) .floatright[ <img src="https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Traditional_Single_Layer_DMZ_with_two_flanking_firewalls.png/550px-Traditional_Single_Layer_DMZ_with_two_flanking_firewalls.png"/> .caption[ Source: ["Dgondim" via Wikimedia, CC BY-SA 4.0](https://commons.wikimedia.org/w/index.php?curid=35477121) ] ] ## What's wrong with this picture? -- ### Perimeter defence: * "Good" people inside * "Bad" people outside ??? People don't like to think about insider threats. We like to think of the people we work with as trustworthy in at least two ways: 1. they **have our interests at heart** and 2. they **are competent to protect our interests**. Both are, undoubtably, true for some. However, for organizations that involve thousands of people, there will almost certainly be people for whom _neither_ is true. Even worse, for most people in any organization, _at most one_ of these two aspirations will be accurate, and falling down on either of them is sufficient for an attacker to get an "in". --- # Users' view ### What should you worry about on: * public Wi-Fi (airport, coffee shop, etc.)? -- * institutional Wi-Fi (corporate, University, etc.)? -- * home network (wired or wireless)? -- ### How much should you trust _any_ network? --- # Network threats -- ### Confidentiality -- * Content data (DPI keywords, cookies, advertisements...) -- * Metadata (hostnames, IPs, URLs...) -- ### Integrity * Injecting advertisements -- * Injecting malware --- # Network threats ### Confidentiality * Content data (DPI keywords, cookies, advertisements...) * Metadata (hostnames, IPs, URLs...) .floatright[ ## What's the right solution ## to these problems? ] ### Integrity * Injecting advertisements * Injecting malware ??? The best solution to these problems isn't to use a "more secure" network, it's to use **protocols that don't trust the network**. --- # Using untrusted networks ### The best answer: "so what?" -- * Advice at a "cybersecurity awareness" seminar: "I wouldn't do online banking at a coffee shop" -- — with TLS and CT, **why not??** ??? Advice like this ("don't do important stuff at a coffee shop") is both misleading and **counterproductive**. * It's factually inaccurate: good luck fooling a [browser that supports certificate transparency]({{% ref "/lecture/19" %}}#54)! * If computer security is presented as basically impossible in real-world settings, people won't both trying to keep up. * If security is presented as something that's only for "important stuff", people will leave themselves vulnerable to the _real_ risks. -- * The _real_ risks come from unprotected, "less important" stuff ??? What you _really_ need to worry about isn't the sites that use TLS, it's the old systems that use insecure protocols like HTTP, FTP (yes, this is still used, especially in the "creative" industry) and plain-text email. These protocols can allow an attacker to eavesdrop on credentials or other data and modify data in transit to, e.g., add a malware download to a web page. --- # Administrator's view <img src="https://i.stack.imgur.com/aFNLH.jpg" align="right"/> ### Oooh, the scary cloud? --- # Administrator's view .floatright[ <img src="https://docs.microsoft.com/en-us/azure/security/fundamentals/media/paas-deployments/identity-perimeter.png" width="500"/> .caption[ Source: [Microsoft](https://docs.microsoft.com/en-us/azure/security/fundamentals/paas-deployments) ] ] ### Oooh, the scary cloud? ### A more nuanced view: * _which_ perimeter? ??? There are **lots of perimeters** that we should think about. Let's not think of attackers as simply being "in" or "out"! -- * perimeters can increase attacker's work ??? Software can be improved by providing least-privileged abstractions, such that malicious (or compromised) code is limited in the damage it can do. Static analysis, fuzzing, type- and memory-safe languages, sandboxing and OS-level access control are all incomplete but helpful layers of **defence in depth**. This is a security strategy analogous to the **Swiss cheese model** of risk management we've all learned about in the course of the COVID-19 pandemic. Similarly, networks can be designed to be more sophisticated than a single flat namespace of IPs behind a firewall, where one administrator account can unlock any service on any computer. Every additional step that an attacker has to take to get to their objective increases the work they need to do, the vulnerabilities they need to find, they time they (likely) need to take and **their chance of getting caught**. -- * assume adversaries are **inside** the perimeter(s) ??? As the Dolev-Yao model reminds us, however, increasing the attacker's work factor doesn't mean we can assume that they aren't already inside any given part of a network. Even though we will make the attackers work hard to get through our layers of defence, we should still assume the attacker can strike anywhere. --- # Passing through perimeters -- ### Firewall rules -- ### Proxies -- ### Jump hosts -- ### VPNs -- ### DIY VPN --- # Firewalls ### Purpose ??? We've already seen that firewalls (whether physical or logical) have ports to let some things through. In a computing sense, that's kind of the point: if we didn't want to allow _any_ traffic through, we could replace a firewall with a pair of scissors! This is commonly called an "air gap". -- ### Air gap * no network connectivity at all * common in critical systems ??? Air gaps are commonly employed in critical systems for two reasons: 1. the consequences of an attacker gaining access are severe, partically because 2. the lowest levels of the system are designed with **no security**. -- * other (limited) forms of communication still possible: -- acoustic, optical, RF, temperature... ??? It's worth noting that even air-gapped systems can communicate in very limited and creative ways, including acoustic communication (see [Fansmitter](https://www.sciencedirect.com/science/article/pii/S0167404820300080)), RF communication from a video display ([AirHopper](https://doi.org/10.48550/arXiv.1411.0237)) or the **memory bus** ([AIR-FI](https://arxiv.org/pdf/2012.06884.pdf)), as well as temperature ([Hot or Not (2006)](https://murdoch.is/talks/ccs06hotornot.pdf), [BitWhisper (2015)](https://doi.org/10.1109/CSF.2015.26)). Sometimes it's a little less creative though no less shocking, with **back doors** in allegedly-air-gapped **industrial control systems** [exploited by state-backed actors](https://www.theregister.com/2018/07/24/russia_us_energy_grid_hackers). --- # Proxies -- ### HTTP * e.g., https://qe2a-proxy.mun.ca/Login?url=https://dl.acm.org -- * transparent proxying of HTTP content (including URL rewriting) ??? e.g., on campus, I can run: `curl -v --proxy http://tony.engr.mun.ca:8888 http://myshopify.com` and I'll see that the result has been transparently rewritten, with a new HTTP header added. I could use this functionality to work around network limitations. However, this is also an example of the kind of transparent proxying that someone doing a DNS attack could force on me if I'm using HTTP (not HTTPS)! Adding a new header isn't such a big deal, but I could've added anything, including false information or a drive-by download. -- ### SOCKS * "please open a connection to 123.456.789.012:12345" -- * often run on port 1080 ??? The [SOCKS protocol](https://datatracker.ietf.org/doc/html/rfc1928) can be used to open arbitrary TCP connections and (as of v5) can also forward UDP datagram packets. This can also be very helpful for accessing resources through a firewall, as we'll see next... --- # Selective SOCKS proxying .centered[ <img src="auto-proxy.png"/> ] ??? Browsers will also let you configure SOCKS proxies to use selectively, so that you don't have to use this performance-affecting mechanism all the time, just for the places where it's important to you. -- .floatleft[ ```javascript function FindProxyForURL(url, host) { if (dnsDomainIs(host, ".aits.mun.ca")) { return "SOCKS localhost:1080"; } /* ... */ else { return "DIRECT"; } } ``` ] ??? This example (taken from https://github.com/trombonehero/config/blob/main/.config/mun-proxy.pac) shows how I connect to a local SOCKS proxy for some Memorial services that aren't available outside of Memorial's network. This is helpful for doing some of my work remotely, and it's one example of a situation in which I don't actually need a VPN. --- # Jump hosts > The firewall won't let me SSH directly into my computer! -- .floatright[ <img src="https://webdevolutions.azureedge.net/docs/en/rdm/windows/clip10826.png" width="400"/> .caption[ Source: [Remote Desktop Manager](https://help.remotedesktopmanager.com/overview_whatisrdmjump.html) ] ] -- ### Establish _jump host_ gateway: * Connect to jump host (e.g., via SSH) * Connect from jump host to target * Can allow access logging ??? Using an SSH jump host used to be a manual thing: you would SSH into one host and then SSH into another one, possibly forwarding individual TCP ports if you wanted to access a service on a remote host. These days, however, you can automate the process with a `ProxyJump` configuration directive or the `-J` command-line argument: ``` SSH(1) BSD General Commands Manual SSH(1) NAME ssh - OpenSSH SSH client (remote login program) [...] -J destination Connect to the target host by first making a ssh connection to the jump host described by destination and then establishing a TCP forwarding to the ultimate destination from there. Multiple jump hops may be specified separated by comma characters. This is a shortcut to specify a ProxyJump configuration directive. Note that configuration directives supplied on the command-line generally apply to the destination host and not any specified jump hosts. Use ~/.ssh/config to specify configuration for jump hosts. [...] ``` -- * Can also work around non-sensical security policies 😇 --- # Virtual private network .floatright[ <img src="https://www.juniper.net/documentation/images/g030614.gif" width="500"/> .caption[ Source: [Juniper Networks](https://www.juniper.net/documentation/images/g030614.gif) ] ] ??? A _virtual private network_ is essentially a proxy for **all of your network traffic**. First you connect to a _VPN concentrator_ that's part of your home network (likely in the DMZ) and authenticate to it. Then, you establish a _tunnel_ via IPSec, a UDP-based protocol for wrapping up IP packets and passing them to another host for retransmission. Then, every IP packet that you send from your computer isn't sent directly to the local network, but encapsulated and sent to the VPN concentrator, which actually sends the packet. So, from the perspective of firewalls and other services, your packets look like they're coming from the VPN concentrator rather than your computer. -- ### How: * Route all traffic over IPSec _tunnel_ to... somewhere -- * Packets "pop out" within firewall ??? Having packets pop out "within" your home or corporate network allows them to bypass perimeter firewalls and, e.g., access internal services that aren't presented to the outside world. This is helpful for **limiting access to internal services**. However, it is an **all-or-nothing approach to a perimeter**. This has the potential downside of allowing (or at least not challenging) the designers and administrators of network services to **make poor assumptions about access control**, treating a perimeter as **the ultimate gatekeeper** rather than **one layer of defence in depth**. Many services (and users) would be better served by thinking holistically about remote access requirements and providing least-privileged access as needed instead of exposing "all the things" to remote devices. If you require a VPN to access your corporate email (and only email!), **perhaps you need a better email provider**. -- * ... including DNS! ??? One helpful feature provided by a VPN is making even your DNS queries be served within your home or corporate network. This can allow some services to only be exposed internally, but if you aren't using that functionality, the main benefit is just hiding your DNS queries from whatever provider runs your airport or coffee shop Wi-Fi. Much of that benefit can be achieved with a public DNS service like Cloudfare (1.1.1.1) or Google (8.8.4.4 or 8.8.8.8). Assuming you don't mind **telling _them_ every hostname you want to visit**... --- # Do you need a VPN? ??? Lots of simple use cases don't actually require full VPNs. The secure shell client `ssh` provides for a lot of VPN-like functionality without having to move your entire network interface into a "remote" configuration. -- #### Establish secure tunnel to jump host w/port forwarding, SOCKS: ```sh $ ssh -L 24800:tony.engr.mun.ca:24800 -D 1080 garfield.cs.mun.ca ``` ??? Here, I've shown an example of: * connecting to a server that Memorial's firewall will let me talk to from anywhere in the world (`garfield.cs.mun.ca`), * forwarding a single TCP port from a Memorial-internal machine (port 24800 on `tony.engr.mun.ca`, the port for [Synergy](https://symless.com/synergy) keyboard and mouse sharing) and * running a SOCKS proxy on localhost:1080 that I can use to connect to other Memorial-internal services as if I were connecting from `garfield.cs.mun.ca` -- #### Proxy (some) traffic over it: .floatleft[ <img src="firefox-socks.png" width="500"/> ] -- ## But who will fund the podcasters? ??? That's not to say that VPNs are all bad or that you should never use one. I don't use one very often, but I do have [ProtonVPN](https://protonvpn.com/pricing) installed because it provides a free tier for limited usage and the larger company is pretty privacy-focused. Most of the time, however, TLS, SOCKS and SSH more than meet my needs. --- # Summary ### Network perimeters ### Network threats ### VPNs ### DIY --- class: big, middle The End.