A Deep Dive on Cybersecurity

This is a direct continuation off our last article, A Deep Dive on Networking. More specifically, we’ll be moving into some networking concepts that deal with security.

The Session Layer

In the last article, we talked about the OSI layer — we covered virtually everything except layers 5 and 6. We also cut quite a large chunk off layer 7, which I hinted at with the very end of the article (spoiler: its the web proxy). So let’s order this to focus on these last 3 layers in order, and end on some more info about what a cyberattack really looks like.

So, we’ve already covered how two IPs connect with one another, and how they send information to each over over a channel. But we sort of skimmed over how they establish that channel in the first place. At the time, I simplified things by describing them purely in the speed and reliability we could get the data across, but not how to keep it secure. After all, we don’t want a third party coming in and seeing what we’re downloading!

So, before we actually send data like HTTP or SMTP over TCP/UDP (all terms we learned last article), we need to make sure that the coast is clear. This is what session security is all about.

There are two methods of session security: SSL and TLS. And by two methods of session security, I mean there is only one method of session security, and that’s TLS — but SSL was the standard for quite awhile, and older cybersecurity experts still have a habit of calling session security “SSL”, so we use both names.

The move from SSL to TLS was complicated — there was a lot going on behind the scenes, and many small updates made TLS superior, such as PFS and 0-RRT. But before I explain what those terms mean, I have to explain to you how session security works — and with it the number one reason SSL was abandoned in favor of TLS.

If one IP (for simplicity… IP1) wants to connect to another (IP2), it’ll start by asking IP2 for its public key. IP2 sends over the requested key, and IP1 encrypts it given the instructions to create a session key. IP1 sends back over the session key and, if all goes well, IP2 will be able to decrypt it using its private key.

Key-based encryption is something that can use its very own article, so for simplicity’s sake just assume that these keys allow each other to interpret the packets that the other IP is sending. Now, it’s worth noting that the session structure I just described to you is not TLS. It’s actually the old method, SSL.

You see, SSL used an asymmetric encryption known as RSA. It is asymmetric in how IP2 has to be doing the majority of the work in sending its public key over and then decrypting using its private. This system worked well enough, with two issues: the first was that it was slow. The second, perhaps more worrisome, is that if the private key had been snatched, every single piece of data ever sent or received by IP2 is up for grabs. Combine that with the fact that RSA’s security encryption is quantumly solvable (read: if given a quantum computer and enough time, you can find every person’s private key) and you start to realize that maybe we should be using something else.

Fortunately, two people — whose last names are presumably “Diffie” and “Hellman” — created a new encryption, Diffie-Hellman, which served as a symmetric encryption. This time we didn’t need private or public keys — the two servers simply engaged in the same (rather complicated and too low level for this post) mathematical encryption process in order to come out with the same session key. This came with a lot of small advantages, including the two I previewed to you — PFS,
or “Perfect Forward Secrecy”, which means that every session key is unique and therefore there is no master (private) key which would allow you to see all previous comms, and 0-RRT (Zero Round Trip Time) which meant you are now able to reuse old session keys since they each have their own built-in security.

The Presentation Layer

The presentation layer is arguably the most vague and opaque of the OSI layers. There’s not much to it that we haven’t already discussed previously, but it does give us the opportunity to present a security concept we have not yet touched:

One way to “present” a packet across a connection (or as we now know it, a session) is by wrapping it in some sort of security. There are two major forms of this — GRE and ESP. The GRE focuses on privacy, while ESP focuses on encryption — usually people combo these two together alongside a VPN for extra-good corporate security.

The focus of the GRE is just to obfuscate the header. As you now know, the header of a packet contains all sorts of IP-identifying information that sort of ruins the point of a VPN. The purpose of a GRE is to wrap the real header in a dummy header, therefore hiding its true intentions. Any authorized users of the packet (such as the VPN or the destination IP) will be able to read its true contents, but everyone else will have to dig deeper to find the actual header.

That being said… you can dig deeper, and its pretty trivial to do so if you just have GRE by itself. So that’s where ESP comes in — ESP encrypts the entire packet so that it isn’t accessible by any packet sniffers/interceptors. In that case, all anyone is getting is — at most — the fake dummy header that the GRE assigned. Funny enough, this ties all the way back to our conversation on IPv6, as one of the major features of v6 (outside of expanding the availability of public IP addresses) was built-in packet encryption and session security which IPv4 did not have.

The Application Layer (and the value of a Proxy)

Speaking of VPNs, I mentioned that people often confuse the abilities of a VPN with that of a web proxy, one of the major players of Layer 7.

Layer 7 is the final layer, and pretty much involves everything that happens right before a packet reaches its target. There is a lot going on at this layer, and I could probably dedicate an entire article to it. Instead, I’m going to focus on just the proxies, which is arguably the biggest “value” concept in the Layer 7 ecosystem.

A proxy, at a fundamental level, takes packet data such as HTTP and forwards it to different places based on different use-cases. For example, if you’re trying to connect to a popular site, the server’s proxy (known as a “reverse proxy”) might forward you to a different server hosting the same site in order to balance the load and make sure the website doesn’t go down due to too many people trying to access it. In our VPN example from last article, a client’s proxy (known as a “forward proxy”) might tell the server, “Actually, we’re in Canada”, thus giving the client access to the Canadian Netflix results rather than the Netflix results of their home country.

But of course, this is the cybersecurity section, as you might imagine proxies have a lot of security purposes too. A proxy might block access to something you shouldn’t be viewing, or if it thinks your connection is sketchy it might send you to a sandbox environment where you can’t actually effect the servers. Proxies can even do something called a “TLS Intercept”, where it intercepts TLS-encrypted traffic coming towards the web server just to make extra sure this session wasn’t organized by a nefarious client.

You know, this talk of “blocking access to nefarious connections” reminds me of something… we still haven’t even mentioned the most common and well-known cybersecurity tool of them all!

Oh, Yeah — Firewalls!

The cybersecurity tools you know well — firewalls and anti-viruses — mostly live outside the OSI paradigm. A firewall, for example, is based within the realm of routing. Remember when I said BGP was “policy-based”? Well, most policies are those defined by firewalls: based around the content and context of a packet, BGP will drop the packets that firewalls ask it to.

Historically, there are three different types of firewalls: Stateless, Stateful, and — most recently — Next-Gen. You can tell when product marketing took over the naming conventions.

In a stateless firewall, all we’re looking at is the packet header. Source IP, Destination IP, and all that other miscellaneous metadata attached. If it’s coming from a sketchy source, or there’s some other weird inconsistency or red flag in the header, we drop it. This type of firewall worked for a long time, until hackers got a bit more clever: they realized that if this was all the information firewalls were taking in, they could intercept an ongoing connection and sent out a packet which, on its surface, looks like it belongs with the rest — but in reality has a dangerous payload.

This is where stateful firewalls come into play. As you could imagine, the “state” in this case is the state, or flow, of the connection. For example, if we are expecting 20 packets of data from a Source IP, and we end up getting 21, then we know something fishy is going on and that we should look into things further. This takes a bit more time to calculate then the stateless firewalls, but are usually worth the improved security.

Now, there should be one glaring red flag for you as to how this is done. Why the hell are we looking at the headers? Couldn’t we just check out the data itself, see the obvious malware written in plaintext, and just drop the packet that way?

Well, there’s two reasons we didn’t do this. The first is related to the fact that snooping on everyone’s connection 24/7 is a huge privacy issue. But as we all know privacy is a secondary concern, and so the real reason stopping companies from doing this was speed: if you tried to inspect the data of every single packet, the connection would slow to an unusable crawl. We had to wait until technology sped up in order to do this.

Well eventually technology did, and the Next-Gen Firewall (or NGFW) was born. This is another thing where there’s a ton of smaller fixes and patches and additions (and also the fact that every company has a different definition of NGFW) but for our 101-level knowledge sake you can say the main deal about Next-Gen is that it inspects packet data.

Antivirus works more or less the same way, though its actually not connected to the network but rather the device itself. Old antiviruses had a list of known malware, that they would then cross-reference with every single one of your local files every time you did a scan. As predicted, this took forever. The answer to this was Next-Gen Antivirus (sigh) where the system was always operating, and would simply look for ongoing occurrences — files making changes in the background, trying to connect to the network, etc. etc. — and immediately root out and delete any bad actors.

What is a Security Threat, Anyway?

To wrap this up, I wanted to cover very briefly what we are protecting ourselves against in the first place. In general, there are five attack techniques, and three attack strategies. We’ll do the lightning round on this to speed things up:

Attack Techniques – The bad stuff which hackers use to do bad things.

1. Phishing. One of the oldest and simplest tricks in the book, but also astonishingly effective to this day. You essentially pretend to be someone you’re not, so you can gain access to things you aren’t supposed to have access to. Common types of phishing include making a fake login screen to scrape passwords, or calling a tech support number to gain access to someone’s credentials. Spam also falls under this category (though it could also be used as a DDOS).
2. Malware. This is a pretty generic term, and is just used to describe anything that is a computer program which does bad things. Viruses, worms, adware, etc. are all examples of malware. Surprisingly ransomware, despite technically being malware, does get its own slot on the techniques category.
3. DDOS. With this one, you’re essentially sending a ton of fake packets to a server for the sole purpose of trying to crash its system. This doesn’t really work against bigger companies due to the amount of servers that they have and tools such as proxy load-balancing, but it can still be effective against smaller targets with less servers, or companies who have a focus on server compute instead of server quantity (such as videogames).
4. Man-in-the-middle. Remember the example I gave where a third party could snoop on a connection, and send a dangerous payload that looks exactly like the other data? This is the essence of a MitM attack. Most network-based security is trying to stop this one from happening.
5. Ransomware. The newest addition to the technique roster: its a type of malware that specifically encrypts all your data and asks you pay money to get it decrypted. Usually individuals like you or me don’t have to worry about this one, but its a huge risk for companies with a ton of cash that hackers know they can squeeze a lot out of. Hospitals tend to be prime targets since they need their systems back up ASAP and due to that are pressured to just pay the hacker rather than call in a security firm to decrypt it manually.

Attack Strategies – The means by which hackers get the bad stuff to you.

1. Zero-day. The most common type of strategy, by a huge margin. A zero-day refers to anything that 1) is a bug or loophole in a popular service, and 2) the creator of the service doesn’t know about yet. This can be anything from an unprotected connection that a hacker can snoop on, all the way to a new way of writing a spam email that doesn’t trigger Gmail’s spam filter.
2. APT. If you’ve ever played the games Plague Inc. or Pandemic, you know the best strategy is to maximize spread before you maximize lethality. Ideally you want to infect every person on Earth with zero symptoms to not trigger vaccine research, then all of a sudden dump every point into lethal and watch the population go from 8 billion to zero in less than a year. Well, believe it or not, hacking works the same way! Why ransomware one random computer in a hospital, if you can ransomware the entire hospital? Why ransomware one hospital, when you can ransomware a network of hospitals? The longer you stay undetected, the longer you stay patient, the more damage you can do before getting kicked out.
3. State-sponsored. Oh, now this is a fun one! Sure you could spend years looking for a perfect security bug or quietly nesting in some rich corporate network, or you could just contact your government’s intelligence agency and find targets that way. They give you the resources, the access points, the immunity from jailtime, and you get paid. With that in mind it should come at no surprise as to why so many hacker groups are tied to a specific country’s government.

Anyway, thanks for reading this two-parter! I learned a lot just writing about these topics, and I hope you learned something from reading it. Your normally scheduled programming returns next week!

[Image omitted]