Instructor: Email Server Security. 2 2
In this lesson, we're going to start talking 3 3
about some of the security measures that you can implement 4 4
on your email servers. 5 5
Now, the first thing you have to think about 6 6
is that spoofing attacks can be mitigated 7 7
by configuring authentication for your email server systems. 8 8
And there's a couple of ways to do this 9 9
and we're going to talk about those in this lesson. 10 10
We have things like SPF, DKIM, DMARC, and Cousin Domains. 11 11
Let's talk about each of these as we go through this lesson. 12 12
First, SPF, or the Sender Policy Framework. 13 13
This is a DNS record that identifies 14 14
the host authorized to send mail for the domain, 15 15
and there's only going to be one allowed 16 16
for each and every domain. 17 17
Now, as you look at them, 18 18
you're going to have something that looks like this. 19 19
And this is a DNS record called a TXT record. 20 20
You'll notice it has the @, and then says v=spf1, 21 21
which is Sender Policy Framework 1. 22 22
It's the first one. 23 23
It then has mx, which is the mail server record. 24 24
And then it says, include:_spf.google.com, 25 25
and include:email.freshdesk.com -all. 26 26
Now, what is this telling you? 27 27
Well, this is actually the SPF record for my email server. 28 28
Now, why do we have google.com there? 29 29
Well, it's because we use G Suite from Google 30 30
and so Google is our email service provider. 31 31
We don't run our own email server. 32 32
Instead, we let them do it. 33 33
And we've given them authorization to do that, 34 34
that they are authorized to send email on our behalf 35 35
by including that SPF statement. 36 36
Now, the second one there, you might be wondering, 37 37
"What's that for? 38 38
I thought you could only have one?" 39 39
Well, you can only have one SPF statement 40 40
but this entire thing is one line 41 41
when written in DNS. 42 42
And this whole thing from TXT all the way to all 43 43
is one single line, and that is one single SPF statement. 44 44
I can authorize multiple servers to send on my behalf 45 45
but I can only do it in one DNS line as you see here. 46 46
And what Freshdesk is is our trouble ticket system. 47 47
If you email support@diontraining, 48 48
it's going to go to Freshdesk. 49 49
But if you email my personal email @diontraining, 50 50
it's going to go over to Google 51 51
because that's who does our personal emails for our company. 52 52
And so you have to include both of those 53 53
and anything else that's going to be authorized 54 54
to send on your behalf inside this statement. 55 55
Now, what is this SPF statement really doing? 56 56
Well, when you receive an email from me, 57 57
your server is going to go and check the DNS record. 58 58
And it's going to say, "Does the email address, 59 59
the envelope return header that I have, that return path, 60 60
when I look that up, does it match one of the servers 61 61
inside of this mail record?" 62 62
If it does, you're authorized to receive it 63 63
and it's likely not spam. 64 64
If it doesn't, that means somebody 65 65
might be trying to spam my domain 66 66
and pretend they're me sending it to you. 67 67
And this is all done in the background 68 68
by your email service provider before you get my emails. 69 69
Now, the next thing we need to talk about 70 70
is D-K-I-M, or DKIM. 71 71
Now, this is DomainKeys Identified Mail. 72 72
This provides a cryptographic authentication mechanism 73 73
for mail using a public key published as a DNS record. 74 74
Now, when you look up an SPF or DKIM, 75 75
you're going to see something like this. 76 76
Here's an example showing you the mail for adobe.com. 77 77
You can see the DMARC at the top, 78 78
which we'll talk about in a minute, 79 79
you'll see the SPF, which we just talked about, 80 80
and then you'll see DKIM, 81 81
which is what we're talking about now. 82 82
Notice DKIM looks like Base64 encoding, essentially. 83 83
It's basically a very long cryptographic authentication key, 84 84
and you can see it there on the screen. 85 85
Now, DKIM can either replace or be used with SPF. 86 86
Now, once you've configured DKIM, 87 87
what ends up happening 88 88
is that when you send an outgoing email, 89 89
your domain MTA is actually going to calculate a hash value 90 90
of the selected message headers. 91 91
It's then going to sign that hash using its private key. 92 92
Now, this key here is what's known as your public key. 93 93
And so when you send this message over, 94 94
it has that hash value that's been encrypted. 95 95
When it gets it, it's going to decrypt that hash value, 96 96
it's going to run your headers through the hash again, 97 97
and compare the two. 98 98
If they match, 99 99
that means then nothing was modified in transit 100 100
and they can trust that message. 101 101
Essentially, it's like a digital signature for an email 102 102
but this is done by the servers, 103 103
not by the individual account. 104 104
And so you're verifying that the server actually sent it, 105 105
not that the person actually sent it. 106 106
That's the idea here when you deal with a DKIM. 107 107
The next one we're going to talk about is DMARC. 108 108
And DMARC is the Domain-Based Message Authentication, 109 109
Reporting, and Conformance. 110 110
This is basically a framework. 111 111
And this framework is used 112 112
for ensuring proper application of SPF and DKIM, 113 113
utilizing a policy that's published as a DNS record. 114 114
And I showed you that very briefly 115 115
in the last image on your screen 116 116
when I showed you the DMARC as the top line of that image. 117 117
If you want to go back and take a look at that, 118 118
you can at this time. 119 119
Now, when you're dealing with DMARC, 120 120
you can use this either with SPF, 121 121
with DKIM, or using both. 122 122
Because remember, 123 123
SPF and DKIM don't have to be used together, 124 124
you can use one, or the other, or you can use both. 125 125
And DMARC is going to be used with one, the other, or both. 126 126
Now, when you're dealing with DMARC, 127 127
this is what it looks like. 128 128
So how does all of this work together? 129 129
Well, first, you have to make sure that your SPF, 130 130
your DKIM, and your DMARC are all on the DNS server. 131 131
Once you have all those records there, 132 132
that's what starts this whole process. 133 133
Now, once you've done that once, 134 134
everything else is going to follow up 135 135
each and every time you want to send a message. 136 136
In this example, we're going to have two messages being sent. 137 137
One from the SMTP server, 138 138
which is authorized and being shown as green, 139 139
and one from an adversary who's trying to spoof your domain, 140 140
which is going to be shown in red. 141 141
Let's start with the one that's authorized. 142 142
Here's listed as 2A. 143 143
Your sender is going to send that message over to the MTA. 144 144
It goes to the MTA, which is your message transfer agent, 145 145
and it's going to end up taking that message 146 146
with the SPF or DKIM header in it. 147 147
Now, let's stick with this message for a minute 148 148
and then we'll come back to the adversary. 149 149
Once the MTA has that message, 150 150
it's going to go ahead and look at that message 151 151
and process that message. 152 152
When it does that, 153 153
part of that is going to be looking up the sender DMARC policy 154 154
and the SPF and DKIM records via DNS, 155 155
just like we talked about 156 156
in the last three or four minutes here. 157 157
Now, once the MTA does that, if it's legitimate, 158 158
that message can be placed into the receiver's mailbox 159 159
on the IMAP server 160 160
and wait for the person to be able to read their message 161 161
using their mail user agent. 162 162
That's all good because they know this message was authentic 163 163
because it compared those values against the SPF, the DKIM, 164 164
or the DMARC based on the policy that was set up. 165 165
Now, if we look at the adversary on the other hand, 166 166
when they send the message, it still goes to the MTA 167 167
because it has to get to the MTA to get to that end user. 168 168
Once it gets there though, 169 169
the MTA's going to check it versus that DMARC policy, 170 170
looking at the SPF or DKIM records. 171 171
Once it does that, if they don't match, 172 172
it's going to reject that message, delete it, or quarantine it, 173 173
and it throws it away, as you could see in 5B. 174 174
Again, this is the way this stuff works. 175 175
And by using this DKIM, DMARC, and SPF together, 176 176
we can add some security into our organizations. 177 177
Now using SPF, and DKIM, and DMARC 178 178
does not solve the problem of cousin domains though. 179 179
Now, what's a cousin domain you might ask? 180 180
Well, a cousin domain is a Domain Name System domain 181 181
that looks similar to another name 182 182
when it's rendered by a mail user agent. 183 183
Now, what I mean by that 184 184
is if you get something that looks very similar 185 185
to your real domain. 186 186
For instance, here I have diontraining.com, 187 187
which is my website. 188 188
Now, a cousin domain to that 189 189
might be something like diontrainimg.com. 190 190
Notice the last N has now been changed to an M, 191 191
making it diontranimg.com. 192 192
If you were going through your email very quickly, 193 193
you may not notice the difference 194 194
'cause they look very similar. 195 195
Or maybe you get something like this, diontraning.com. 196 196
I dropped one of the I's. 197 197
And again, it looks very similar. 198 198
And so if you're not looking carefully, 199 199
and I set up that domain to be a cousin domain, 200 200
I buy that domain name, 201 201
I actually set up DKIM records for it, 202 202
and SPF records, and DMARC policy for it, 203 203
your MTA is going to think that is a legitimate email. 204 204
And it is. 205 205
It's a legitimate email 206 206
from diontraning.com, not diontraining.com, 207 207
and so that would be one of the issues. 208 208
Alternatively, you might get an email like this, 209 209
looks like support@diontraining.com. 210 210
Great. 211 211
Or is it look like this, support@deiontranimg.com. 212 212
Again, they both look very similar. 213 213
And if you're not paying close attention, 214 214
somebody can use that as a way into your organization 215 215
because it will pass the MTA's verification 216 216
against the DMARC policies, the SPF, and the DKIM 217 217
if they sent those records correctly.