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

## Introduction
DMARC, or Domain-Based Message Authentication, Reporting, and Conformance is another DNS-based email tool. It’s built on top of SPF and DKIM and has two main uses. First, it can be used to help troubleshoot complex SPF and/or DKIM rules. Second, it can be used to collect forged emails for later analysis. Let’s take a look at the DMARC records in use for punkgrok.org. We do this by looking at the TXT DNS records for _dmarc.punkgrok.org, as follows:

The output should be similar to the following:
```shell
; <<>> DiG 9.8.3-P1 <<>> _dmarc.punkgrok.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16424
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_dmarc.punkgrok.org.           IN      TXT
;; ANSWER SECTION:
_dmarc.punkgrok.org.    14400   IN      TXT
  "v=DMARC1\; p=quarantine\; rua=mailto:postmaster@punkgrok.org\;"
;; Query time: 123 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sun Jul 1 12:43:59 2018
;; MSG SIZE rcvd: 114
```

Let’s take a look at what DNS tells us here. The part we’re most interested in is here:
```shell
"v=DMARC1\; p=quarantine\; rua=mailto:postmaster@punkgrok.org\;"
```
> Note: Your output might look slightly different

Just like SPF and DKIM, we see a configuration that’s specified by tags. And again we see that the first tag is the version number.

### Policy tag
The second tag in this example is the policy tag.
```shell
p=quarantine
```
This tells the receiving mail server what to do with an incoming email that fails validation. There are three valid values for this: none, quarantine, and reject. Section 6.1 of the DMARC spec defines these three policies as follows: (https://tools.ietf.org/html/rfc7489#section-6.1)
1. `None`: The Domain Owner requests no specific action be taken regarding delivery of messages. 
2. `Quarantine`: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean “place into spam folder,” “scrutinize with additional intensity,” and/or “flag as suspicious.” 
3. `Reject`: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction.

### Reporting URI for aggregate data
Next, we see `rua`, which stands for “reporting URI(s) for aggregate data.” This lets the domain admin specify one or more email addresses to which aggregate reports of validation failures should be set. This functionality can be used to debug SPF and DKIM issues. This can also be used to analyze information about who is sending forged emails.

It’s hard to find mistakes in configurations for DKIM or SPF because the DNS records that drive them are interpreted by servers owned by other organizations. If we mess something up, our outbound emails will just get dropped and we won’t know why. With DMARC reporting, we can at least see what emails were getting dropped by other organizations and work backwards from that to fix it. If there are problems with SPF and/or DKIM, it’s common to encounter them when working with a third party that sends emails on your behalf, such as a marketing partner. If you want them to be able to send emails for you, you need to include them in your SPF and DKIM configurations. For one example of the kind of coordination problem that can pop up, consider what happens if your marketing partner changes their public IPs but you don’t update your SPF records. When your marketing emails reach the recipients’ mail servers, they’ll check the SPF records, see that they no longer match, and your marketing emails will start getting dropped but you won’t know why. With DMARC, you can find out what happened.

Another use of the DMARC report is to find IPs that are sending forged emails for your domain. You can’t do much about it directly, but you can send the reports to spam clearing houses that maintain reputation scores for IP ranges and domains.

There are more options to DMARC configuration, but we’ve covered the parts you’re most likely to want to use. For more details, see the [DMARC website](https://dmarc.org/) or [RFC 7489](https://tools.ietf.org/html/rfc7489).


 <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> 

# Introduction
DMARC, or Domain-Based Message Authentication, Reporting, and Conformance is another DNS-based email tool. It’s built on top of SPF and DKIM and has two main uses. First, it can be used to help troubleshoot complex SPF and/or DKIM rules. Second, it can be used to collect forged emails for later analysis. Let’s take a look at the DMARC records in use for punkgrok.org. We do this by looking at the TXT DNS records for _dmarc.punkgrok.org, as follows:

The output should be similar to the following:
```shell
; <<>> DiG 9.8.3-P1 <<>> _dmarc.punkgrok.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16424
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_dmarc.punkgrok.org.           IN      TXT
;; ANSWER SECTION:
_dmarc.punkgrok.org.    14400   IN      TXT
  "v=DMARC1\; p=quarantine\; rua=mailto:postmaster@punkgrok.org\;"
;; Query time: 123 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sun Jul 1 12:43:59 2018
;; MSG SIZE rcvd: 114
```

Let’s take a look at what DNS tells us here. The part we’re most interested in is here:
```shell
"v=DMARC1\; p=quarantine\; rua=mailto:postmaster@punkgrok.org\;"
```
> Note: Your output might look slightly different

Just like SPF and DKIM, we see a configuration that’s specified by tags. And again we see that the first tag is the version number.

## Policy tag
The second tag in this example is the policy tag.
```shell
p=quarantine
```
This tells the receiving mail server what to do with an incoming email that fails validation. There are three valid values for this: none, quarantine, and reject. Section 6.1 of the DMARC spec defines these three policies as follows: (https://tools.ietf.org/html/rfc7489#section-6.1)
1. `None`: The Domain Owner requests no specific action be taken regarding delivery of messages. 
2. `Quarantine`: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean “place into spam folder,” “scrutinize with additional intensity,” and/or “flag as suspicious.” 
3. `Reject`: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction.

## Reporting URI for aggregate data
Next, we see `rua`, which stands for “reporting URI(s) for aggregate data.” This lets the domain admin specify one or more email addresses to which aggregate reports of validation failures should be set. This functionality can be used to debug SPF and DKIM issues. This can also be used to analyze information about who is sending forged emails.

It’s hard to find mistakes in configurations for DKIM or SPF because the DNS records that drive them are interpreted by servers owned by other organizations. If we mess something up, our outbound emails will just get dropped and we won’t know why. With DMARC reporting, we can at least see what emails were getting dropped by other organizations and work backwards from that to fix it. If there are problems with SPF and/or DKIM, it’s common to encounter them when working with a third party that sends emails on your behalf, such as a marketing partner. If you want them to be able to send emails for you, you need to include them in your SPF and DKIM configurations. For one example of the kind of coordination problem that can pop up, consider what happens if your marketing partner changes their public IPs but you don’t update your SPF records. When your marketing emails reach the recipients’ mail servers, they’ll check the SPF records, see that they no longer match, and your marketing emails will start getting dropped but you won’t know why. With DMARC, you can find out what happened.

Another use of the DMARC report is to find IPs that are sending forged emails for your domain. You can’t do much about it directly, but you can send the reports to spam clearing houses that maintain reputation scores for IP ranges and domains.

There are more options to DMARC configuration, but we’ve covered the parts you’re most likely to want to use. For more details, see the [DMARC website](https://dmarc.org/) or [RFC 7489](https://tools.ietf.org/html/rfc7489).


 <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 discuss Domain-Based Message Authenticatioin, Reporting, and Conference and how it can help defend against phishing attacks.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

DNS-Based Defense: DMARC

Introduction #