Gain insights into effective security techniques including patching, cryptography, and phishing prevention. Explore practices to make systems resistant and vulnerabilities more detectable, enhancing defense against attacks.

docker.tar.gz

network-commands

node

It seems like hardly a week goes by without a high-profile computer breach. Why do these happen? How can you prevent them? This course doesn’t have all the answers, but it does outline practices that make life harder for attackers and that will help tide you over until you get a full-time security team in place.

In this course, you will learn 5 simple, yet effective, techniques for preventing attackers from getting into your system. These techniques are related to: patching, software vulnerabilities, cryptography, windows security, and phishing. Within each chapter you will learn the best practices for preventing vulnerabilities and how to make them more detectable. 

This course is based on the Pragmatic Programmers’ book, Practical Security, and is aimed at developers, admins, team leads, architects, technology generalists, and all others who stand guard against the things that disrupt the network.

Practical Security: Simple Practices for Defending Your Systems

## TLS: Encryption in transit
So far, the encryption we’ve discussed is for encryption at rest—that is, the encryption we use when storing or retrieving data. We also need to consider encryption in transit, the encryption used to protect data sent over the network. Just as we don’t want to write our own crypto for encryption at rest, we shouldn’t write our own crypto for encryption in transit. We use the same criteria we used earlier in this chapter—use a trustworthy implementation of well-researched algorithms. 

Today, the best candidate we have for encryption in transit is TLS 1.3. At the time of this writing, TLS 1.3 support isn’t pervasive, however, so you may need to use TLS 1.2 in the short term. That’s ok; properly configured TLS 1.2 is a strong choice as well. But going forward, your preference should be to use TLS 1.3 and only use TLS 1.2 if you depend on software that doesn’t support TLS 1.3 yet.

We saw earlier that just because something is encrypted with AES doesn’t mean it’s encrypted securely. The same applies to TLS 1.2. There are a lot of configuration choices to be made in securely setting up TLS. If you want to learn all about the configuration choices to be made and how to make those choices, read [Bulletproof SSL and TLS](https://www.feistyduck.com/books/bulletproof-ssl-and-tls/) by Ivan Risticć. If you’re in a hurry and just want to know whether your server is well configured or not, check out the [SSL Labs](https://www.ssllabs.com/) server test, also from Ivan Ristić. 

The feedback from the SSL Labs site is quite clear and actionable. It will list common misconfigurations, such as weak cipher suites that are still supported by your servers. This site is kept up-to-date to reflect new research and attacks. Keep at it until you get an A from SSL Labs. Once you have a strong configuration, use that configuration throughout your organization.


> ## Joe asks: What’s the difference between HTTPS, SSL, and TLS? 
>The terminology here is a little confusing. HTTP is the network protocol used to serve up web pages. Great protocol, but insecure because all of the communication is unencrypted. This was fine for allowing scientists to exchange research papers (the use case that Tim Berners-Lee initially had in mind when creating HTTP), but it’s not safe enough for the many uses of the web today. So another protocol called HTTPS, or HTTP Secure, was invented. This encrypted the HTTP traffic before sending it out on the network. Early versions of HTTPS used a protocol called Secure Socket Layer (SSL) to encrypt the HTTP traffic. Versions 1, 2, and 3 of SSL were discovered to have security flaws. The replacement of SSL 3 was not called SSL 4, however. It was a new protocol called Transport Layer Security (TLS). TLS 1.0 and 1.1 have both been found to have flaws, and now we should use TLS 1.2 or TLS 1.3, except when legacy systems require us to use older protocols for backward compatibility. 
These name changes haven’t always taken hold in common usage. It’s still common to hear people talk about websites protected by SSL, regardless of whether the underlying protocol is really SSL 2, SSL 3, TLS 1.0, TLS 1.1, TLS 1.2, or TLS 1.3.


Another aspect of secure TLS configuration is certificates. Certificates are stored on the HTTPS server and are used for a server to establish its identity. Read Bulletproof SSL and TLS for a more detailed explanation of how they work. 

For our purposes, let’s think of them as files that are tied to private keys that need to be kept secure. Think back to our section on decreasing the value of the secrets we must keep. Since certificates and private keys are generated using cryptographically strong sources of randomness instead of easily remembered text, it’s virtually impossible that an adversary would ever be able to compromise them via brute-forcing.

The more likely threat is that a private key would be compromised by gaining access to the server that uses it. So you will want to rotate your certificates at least annually. And you will want to be able to rotate them on short notice in the event your servers are compromised.

 &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; **Q U I Z** &nbsp;

# TLS: Encryption in transit
So far, the encryption we’ve discussed is for encryption at rest—that is, the encryption we use when storing or retrieving data. We also need to consider encryption in transit, the encryption used to protect data sent over the network. Just as we don’t want to write our own crypto for encryption at rest, we shouldn’t write our own crypto for encryption in transit. We use the same criteria we used earlier in this chapter—use a trustworthy implementation of well-researched algorithms. 

Today, the best candidate we have for encryption in transit is TLS 1.3. At the time of this writing, TLS 1.3 support isn’t pervasive, however, so you may need to use TLS 1.2 in the short term. That’s ok; properly configured TLS 1.2 is a strong choice as well. But going forward, your preference should be to use TLS 1.3 and only use TLS 1.2 if you depend on software that doesn’t support TLS 1.3 yet.

We saw earlier that just because something is encrypted with AES doesn’t mean it’s encrypted securely. The same applies to TLS 1.2. There are a lot of configuration choices to be made in securely setting up TLS. If you want to learn all about the configuration choices to be made and how to make those choices, read [Bulletproof SSL and TLS](https://www.feistyduck.com/books/bulletproof-ssl-and-tls/) by Ivan Risticć. If you’re in a hurry and just want to know whether your server is well configured or not, check out the [SSL Labs](https://www.ssllabs.com/) server test, also from Ivan Ristić. 

The feedback from the SSL Labs site is quite clear and actionable. It will list common misconfigurations, such as weak cipher suites that are still supported by your servers. This site is kept up-to-date to reflect new research and attacks. Keep at it until you get an A from SSL Labs. Once you have a strong configuration, use that configuration throughout your organization.


> ## Joe asks: What’s the difference between HTTPS, SSL, and TLS? 
>The terminology here is a little confusing. HTTP is the network protocol used to serve up web pages. Great protocol, but insecure because all of the communication is unencrypted. This was fine for allowing scientists to exchange research papers (the use case that Tim Berners-Lee initially had in mind when creating HTTP), but it’s not safe enough for the many uses of the web today. So another protocol called HTTPS, or HTTP Secure, was invented. This encrypted the HTTP traffic before sending it out on the network. Early versions of HTTPS used a protocol called Secure Socket Layer (SSL) to encrypt the HTTP traffic. Versions 1, 2, and 3 of SSL were discovered to have security flaws. The replacement of SSL 3 was not called SSL 4, however. It was a new protocol called Transport Layer Security (TLS). TLS 1.0 and 1.1 have both been found to have flaws, and now we should use TLS 1.2 or TLS 1.3, except when legacy systems require us to use older protocols for backward compatibility. 
These name changes haven’t always taken hold in common usage. It’s still common to hear people talk about websites protected by SSL, regardless of whether the underlying protocol is really SSL 2, SSL 3, TLS 1.0, TLS 1.1, TLS 1.2, or TLS 1.3.


Another aspect of secure TLS configuration is certificates. Certificates are stored on the HTTPS server and are used for a server to establish its identity. Read Bulletproof SSL and TLS for a more detailed explanation of how they work. 

For our purposes, let’s think of them as files that are tied to private keys that need to be kept secure. Think back to our section on decreasing the value of the secrets we must keep. Since certificates and private keys are generated using cryptographically strong sources of randomness instead of easily remembered text, it’s virtually impossible that an adversary would ever be able to compromise them via brute-forcing.

The more likely threat is that a private key would be compromised by gaining access to the server that uses it. So you will want to rotate your certificates at least annually. And you will want to be able to rotate them on short notice in the event your servers are compromised.

 &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; **Q U I Z** &nbsp;

In this lesson, we will study TLS and learn how to configure it properly.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

TLS Configuration

TLS: Encryption in transit