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

It will be useful to be able to query DNS records to understand these defenses and configure them for your domains. If you’re running a Unix-like operating system like Mac OS or Linux, you’ll have a program called dig installed. You can run dig at the command line. You can read the man page for more details, but for our purposes, all you need to know is to run dig with two arguments—the host or domain you want to learn more about and the keyword txt. That will look like this:

## The Problem with Email
Phishing emails that appear to have been sent from your domain are going to be more effective than phishing emails sent from other domains. So we’re going to take a look at three technologies that you can use to help prevent phishers forging emails that appear to be sent from your domain—SPF, DKIM, and DMARC.

First let’s look at a problem with email. Email is sent using a protocol called SMTP, or Simple Mail Transfer Protocol. SMTP is the protocol that allows mail servers from all over the internet to send email to one another. It’s too complex to cover in detail here. Check out Educative's course [Grokking Computer Networking](https://www.educative.io/courses/grokking-computer-networking/email-smtp), if you wish to learn more about it. What we’ll emphasize here is that SMTP lets anyone send email from any address. That’s problematic, and it’s part of why there’s so much spam.

Let’s suppose, as we often do, that Alice wants to email Bob. When bob.com receives an incoming email claiming to be from alice@alice.com, there’s nothing in SMTP that lets the bob.com mail server determine whether this email is legitimate or not. No matter what authentication is in place on the legitimate alice.com SMTP server, anyone can connect to bob.com’s SMTP server and claim to be sending legitimate email from alice.com.

Solving this requires answering some tricky questions about identity. Who is bob.com to say who can and can’t send email from alice.com addresses? Turns out that we already have a robust system for distributing authoritative information about domains. That system is the Domain Name System (DNS). We can leverage that system to narrow the scope of fraudulent emails.

The DNS system maintains records for all of the domains on the internet. DNS supports multiple record types. The first record type most people think of is the A record type. This is what lets us use a convenient machine name like www.pragprog.com instead of having to remember an IP address like 54.243.36.130. But there are other record types as well. One of these types is the TXT record type. TXT record types are meant for associating textual data with a domain. Generally, TXT records are meant to be parsed by programs, rather than read by humans. As we’ll see with SPF, DKIM, and DMARC, we can use the ability to store a little bit of data in a trusted, authoritative location like a DNS record to help bob.com answer the difficult question of whether an incoming email from alice.com is legitimate. Adding these DNS-based defenses will keep phishers from being able to forge emails that appear to come from your domain. This will help both the people in your organization and in organizations that you regularly collaborate with.

### SPF
Sender Policy Framework (SPF) is a technology that enables the administrators of a domain to specify which computers are authorized to send an email on behalf of that domain. SPF leverages the Domain Name System (DNS) to distribute this information. This lets a mail server determine whether incoming email is legitimate. If incoming mail claims to have been sent from foo.com, the mail server that receives it can look at the DNS records for foo.com and see if the computer that’s sending it the email is on the list of approved computers.
Going back to our example, if alice.com specifies an SPF record like this:
```shell
“v=spf1 ip4:1.2.3.4 -all”
```
then when bob.com receives an email that claims to be from alice@alice.com, bob.com has a way to determine its authenticity. If it’s 1.2.3.4 that’s connecting to bob.com to send the email, then it’s legitimate. If it was sent by any other IP address, it’s a forgery.

Specifying a single IP address is the simplest example to understand, but it’s not very flexible. Fortunately, SPF gives us a couple of other options for additional flexibility. Instead of just being able to specify a single IP address, SPF lets us specify multiple IPs and/or multiple CIDR blocks. If you need a refresher on CIDR, refer to [What Is a CIDR Range?](https://www.educative.io/courses/practical-security-defending-your-systems/nmap#joe-asks-what-is-a-cidr-range). SPR also lets us defer to the SPF decisions of other computers. This is a key to using SPF with a hosted email solution like Gmail or Outlook 365. Looking back to the dig output for punkgrok.org, we can see that I’ve delegated SPF decisions to _spf.google.com because I use Gmail to handle all my mail at punkgrok.org.

The last part of the SPF record for us to investigate is the `-all` at the end of the line. This is how SPF lets us specify what to do when an email is received from an unapproved computer. The two most common options are `-all`, which is a hard fail, and `~all`, which is a soft fail. An email that hard fails should not be presented to the end-user. An email that soft fails should be presented to the end-user, but with a warning that it might be spam.

There are more options to SPF configuration, but we’ve covered the parts you’re most likely to want to use. For more details, see the [SPF Project](http://www.openspf.org/) or [RFC 7208](https://tools.ietf.org/html/rfc7208).


 <font size="6">  &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;   </font> 

# The Problem with Email
Phishing emails that appear to have been sent from your domain are going to be more effective than phishing emails sent from other domains. So we’re going to take a look at three technologies that you can use to help prevent phishers forging emails that appear to be sent from your domain—SPF, DKIM, and DMARC.

First let’s look at a problem with email. Email is sent using a protocol called SMTP, or Simple Mail Transfer Protocol. SMTP is the protocol that allows mail servers from all over the internet to send email to one another. It’s too complex to cover in detail here. Check out Educative's course [Grokking Computer Networking](https://www.educative.io/courses/grokking-computer-networking/email-smtp), if you wish to learn more about it. What we’ll emphasize here is that SMTP lets anyone send email from any address. That’s problematic, and it’s part of why there’s so much spam.

Let’s suppose, as we often do, that Alice wants to email Bob. When bob.com receives an incoming email claiming to be from alice@alice.com, there’s nothing in SMTP that lets the bob.com mail server determine whether this email is legitimate or not. No matter what authentication is in place on the legitimate alice.com SMTP server, anyone can connect to bob.com’s SMTP server and claim to be sending legitimate email from alice.com.

Solving this requires answering some tricky questions about identity. Who is bob.com to say who can and can’t send email from alice.com addresses? Turns out that we already have a robust system for distributing authoritative information about domains. That system is the Domain Name System (DNS). We can leverage that system to narrow the scope of fraudulent emails.

The DNS system maintains records for all of the domains on the internet. DNS supports multiple record types. The first record type most people think of is the A record type. This is what lets us use a convenient machine name like www.pragprog.com instead of having to remember an IP address like 54.243.36.130. But there are other record types as well. One of these types is the TXT record type. TXT record types are meant for associating textual data with a domain. Generally, TXT records are meant to be parsed by programs, rather than read by humans. As we’ll see with SPF, DKIM, and DMARC, we can use the ability to store a little bit of data in a trusted, authoritative location like a DNS record to help bob.com answer the difficult question of whether an incoming email from alice.com is legitimate. Adding these DNS-based defenses will keep phishers from being able to forge emails that appear to come from your domain. This will help both the people in your organization and in organizations that you regularly collaborate with.

## SPF
Sender Policy Framework (SPF) is a technology that enables the administrators of a domain to specify which computers are authorized to send an email on behalf of that domain. SPF leverages the Domain Name System (DNS) to distribute this information. This lets a mail server determine whether incoming email is legitimate. If incoming mail claims to have been sent from foo.com, the mail server that receives it can look at the DNS records for foo.com and see if the computer that’s sending it the email is on the list of approved computers.
Going back to our example, if alice.com specifies an SPF record like this:
```shell
“v=spf1 ip4:1.2.3.4 -all”
```
then when bob.com receives an email that claims to be from alice@alice.com, bob.com has a way to determine its authenticity. If it’s 1.2.3.4 that’s connecting to bob.com to send the email, then it’s legitimate. If it was sent by any other IP address, it’s a forgery.

Specifying a single IP address is the simplest example to understand, but it’s not very flexible. Fortunately, SPF gives us a couple of other options for additional flexibility. Instead of just being able to specify a single IP address, SPF lets us specify multiple IPs and/or multiple CIDR blocks. If you need a refresher on CIDR, refer to [What Is a CIDR Range?](https://www.educative.io/courses/practical-security-defending-your-systems/nmap#joe-asks-what-is-a-cidr-range). SPR also lets us defer to the SPF decisions of other computers. This is a key to using SPF with a hosted email solution like Gmail or Outlook 365. Looking back to the dig output for punkgrok.org, we can see that I’ve delegated SPF decisions to _spf.google.com because I use Gmail to handle all my mail at punkgrok.org.

The last part of the SPF record for us to investigate is the `-all` at the end of the line. This is how SPF lets us specify what to do when an email is received from an unapproved computer. The two most common options are `-all`, which is a hard fail, and `~all`, which is a soft fail. An email that hard fails should not be presented to the end-user. An email that soft fails should be presented to the end-user, but with a warning that it might be spam.

There are more options to SPF configuration, but we’ve covered the parts you’re most likely to want to use. For more details, see the [SPF Project](http://www.openspf.org/) or [RFC 7208](https://tools.ietf.org/html/rfc7208).


 <font size="6">  &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;   </font> 

In this lesson, we will explore Sender Policy Framework (SPF), a DNS-based defense against phishing.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

DNS-Based Defense SPF

The Problem with Email