Instructor: Firewall configurations. 2 2
Now, in the past, most of our network security 3 3
was focused on boundary defense. 4 4
The thought process was, 5 5
that if you could secure your boundaries, 6 6
then you could stop attackers 7 7
but we all know these days, that just simply isn't true. 8 8
Let me give you an analogy to show you the flaw 9 9
in this boundary defense logic that's so heavily relied 10 10
on using firewalls. 11 11
Now, let's pretend you live 12 12
in a small gated community with about 20 other houses. 13 13
Now you want to ensure that nobody could break in, 14 14
so the neighborhood watch gets together and you guys vote 15 15
on putting in a big security gate at the end of the street. 16 16
This way, only residents 17 17
and their guests could get into the compound. 18 18
Now the gate is installed 19 19
and you start feeling relief and you're assured 20 20
that nobody can get into your house or steal anything 21 21
because you have this big security gate there. 22 22
So you start leaving your doors unlocked 23 23
and your windows open whenever you leave the house 24 24
because after all, you trust all your neighbors. 25 25
Well, one day you find your laptop has been stolen 26 26
from your home office. 27 27
Now, how could this be? 28 28
Only people who live here can get 29 29
into that neighborhood, right? 30 30
And you trust all of them, 31 31
so how can anything be stolen? 32 32
Well, you check the security camera feed 33 33
and you find out that one of your neighbor's 34 34
teenage children had some friends over that weekend, 35 35
and one of the friends walked over to your house, 36 36
saw the door was open, 37 37
went into your office and took your laptop. 38 38
Alright, Jason, I get it. 39 39
I get it. 40 40
You can't trust everybody, right? 41 41
That's the point of the story. 42 42
Well, no, that's not the point of the story. 43 43
The point of the story is 44 44
that this is just like a computer network. 45 45
That security gate is like a firewall, 46 46
it allows people in and out, based on a rule set. 47 47
Are you a resident or are you not a resident? 48 48
Are you a guest or resident or are you not a guest? 49 49
Now it's designed to keep things out, 50 50
but if somebody who is trusted, like your users, goes ahead 51 51
and opens it to let that bad factor in, in this case 52 52
that opportunistic teenager who stole your laptop, 53 53
then guess what? 54 54
The firewall isn't enough on its own. 55 55
Now, I'm not saying firewalls are bad. 56 56
In fact, firewalls are an essential part 57 57
of a layered defense strategy, 58 58
but they are just one of the layers of defense 59 59
that we need to combine with other defenses. 60 60
So we need to take that network-based defense 61 61
like a firewall and combine it with a host-based defense, 62 62
like a host intrusion detection 63 63
or host intrusion prevention system. 64 64
Now, we do this with a lot of other controls 65 65
and that's how we get good layer defense. 66 66
Now, this doesn't mean that we should abandon firewalls 67 67
altogether though, but we have to realize, 68 68
we can't solely rely on them 69 69
as a perimeter protection to protect us 70 70
from everything anymore. 71 71
Because of this, 72 72
we're going to continue to talk about firewalls in this lesson 73 73
but as we go through the rest of this course section 74 74
by section, we're going to keep expanding our defenses 75 75
and talking about lots of other things that we can add. 76 76
This way, we'll have a full gamut of protections, 77 77
so we aren't relying on a single security gate alone 78 78
like a firewall. 79 79
Now, from your Network+ studies 80 80
and your Security+ studies, 81 81
you're familiar with what a firewall is 82 82
and what it does. 83 83
Now, there's lots of places you could put a firewall 84 84
in your network and the most common of which is going to be 85 85
on the exterior. 86 86
So you're going to have your ISP or your router 87 87
or your modem, and then that's going to connect to a firewall. 88 88
You can see that here in the picture on the right. 89 89
We have that screened subnet firewall. 90 90
Now, inside of that we have this thing called an extranet 91 91
and this is basically our screened subnet, 92 92
it's our demilitarized zone, 93 93
and then we have another firewall before we leave that area 94 94
and go into the core of our network, 95 95
which then gives us all the access 96 96
that all of our devices are going to use. 97 97
Now, this screened subnet segment is what I'm going to focus on 98 98
for just a moment here. 99 99
Inside of here is where we would put things 100 100
like servers, web hosts, email, VoIP systems, VPN trunks, 101 101
and things like that. 102 102
Now, when we talk about a screened subnet, 103 103
you should remember from your Network+ 104 104
and your Security+ studies that a screened subnet 105 105
is this physical or logical subnetwork that contains 106 106
and exposes an organization's external-facing services 107 107
to an untrusted usually larger network, 108 108
such as the internet. 109 109
This screened subnet is the modern term 110 110
for what used to be called a DMZ. 111 111
Now, it doesn't have to be just the internet though. 112 112
If we have third party suppliers that we connect to, 113 113
we should have a firewall between us and them as well 114 114
and they should be put 115 115
into this untrusted screened subnet as well, 116 116
because we don't trust all of our suppliers inherently. 117 117
Again, this is concepts you should already know 118 118
and we're just doing a quick review. 119 119
Let's talk about ACLs for a moment. 120 120
Now, ACLs are your firewall rule sets 121 121
and we've already covered this a little bit in this course. 122 122
Now, when you deal with an ACL, 123 123
these are going to be processed from top to bottom 124 124
where the most specific rules are at the top, 125 125
and the least specific 126 126
or most generic rules are going to be at the bottom. 127 127
Now, there are some basic rules that we have to talk 128 128
about when we think about ACLS, 129 129
and then we're going to take a quick look at one. 130 130
First, you need to block incoming requests 131 131
from internal or private, loopback, and multicast IP ranges. 132 132
If you have something coming 133 133
from a 192.168.something.something IP, 134 134
and it's coming from the internet, well 135 135
you know that's a non-routable IP 136 136
and so you should be blocking that, 137 137
that should not be allowed to come into your network. 138 138
Similarly, if you start seeing source IP addresses coming 139 139
from areas that are reserved, these are things 140 140
that you want to make sure are getting blocked 141 141
because they are not going to be holding anything good 142 142
for your network. 143 143
Second, you want to block incoming requests 144 144
from protocols that should only be used locally. 145 145
For instance, 146 146
ICMP, DHCP, OSPF, SMB, and other things. 147 147
If you have something like Windows File Sharing, 148 148
that shouldn't happen over the internet, 149 149
it should only happen inside your local network. 150 150
So again, you should be blocking that 151 151
at the firewall at the exterior of your network. 152 152
If somebody has a VPN, they'll be able to tunnel 153 153
in through the firewall and then use those protocols, 154 154
but if they're coming straight from the internet, 155 155
they should not be using those protocols on your network. 156 156
The third thing you want to consider is how 157 157
you're going to configure IPv6. 158 158
I recommend you configure IPv6 159 159
to either block all IPv6 traffic 160 160
or you allow it to only authorized hosts and ports. 161 161
Now, the reason this is recommended 162 162
is because a lot of hosts run dual-stack 163 163
TCP IP implementations 164 164
with IPv6 enabled by default, 165 165
and a lot of organizations are still running Ipv4 only, 166 166
but they don't turn off IPv6 on those hosts, 167 167
and this misconfiguration could allow adversaries 168 168
unfiltered access into your network using 169 169
that IPv6 area because a lot of administrators 170 170
haven't locked down IPv6 well yet. 171 171
So keep that in mind 172 172
as you're doing your configurations of your firewalls 173 173
and as you're reviewing configurations of your firewalls. 174 174
Now, let's go ahead and take a look at a basic access list. 175 175
This one comes from a Cisco firewall, but on the exam, 176 176
they may of showed you one 177 177
from a Cisco firewall or any other firewall. 178 178
It doesn't really matter because CompTIA is vendor agnostic. 179 179
But if you can read a basic firewall log like this, 180 180
you'll do fine on the exam. 181 181
Now, let's start out with the first line, 182 182
IP access list extended from DMZ. 183 183
This just says what this access list is. 184 184
In this case, it's what I'm using for a DMZ. 185 185
The second line is a remark line. 186 186
This tells you what the next section is going to talk about, 187 187
basically it's a comet. 188 188
These are going to be responses to HTTP requests 189 189
and then we get a bunch of permit statements. 190 190
Now, as we go through these permit statements, 191 191
this is going to tell you permit or deny, 192 192
what is the action involved. 193 193
In this case, we're going to permit something from happening. 194 194
Now when we permit it 195 195
we're going to allow it and we're going to allow TCP traffic, 196 196
so we have permit tcp. 197 197
And then we have the IP address that's going to be associated 198 198
with it. 199 199
In this case, we're going to permit TCP traffic 200 200
from IP address 10.0.2.0. 201 201
The next thing is going to be our wild card mask. 202 202
Now, this looks a little funny 203 203
if you're used to Network+. 204 204
You see that it's 0.0.0.255 205 205
and this is because Cisco uses a reverse wildcard. 206 206
So really you can read this going back 207 207
to your subnet mask as 255.255.255.0. 208 208
This is just a Cisco thing. 209 209
Don't let it get you confused. 210 210
But essentially what this is saying is 211 211
that we are permitting TCP traffic 212 212
for any IP that is 10.0.2.something. 213 213
So anything 214 214
in that IP range will be permitted under this rule. 215 215
Then the next part is eq, which says equals. 216 216
So this IP that has whatever's 217 217
beyond the equal sign will be allowed, 218 218
and in this case, we're equaling www. 219 219
What that means is port 80, if somebody has made a request 220 220
over port 80 for one of these IPs, it's going to be allowed. 221 221
And then the next part is any which says this is 222 222
going to be any IP is the destination that we're going to, 223 223
and then we're going to have an established connection. 224 224
So anytime we have an established connection 225 225
from 10.0.2.something to some website over port 80, 226 226
we're going to allow that traffic to happen. 227 227
Essentially, this says we are going to allow somebody 228 228
within our network to go out and access a website. 229 229
That's all this line says. 230 230
And as you go through and you can read these, 231 231
you can start figuring 232 232
out what is permitted and what is denied. 233 233
Now, in this case, everything here is permitted 234 234
because we are doing explicit permissions. 235 235
We are saying yes, these things are allowed, but when we get 236 236
down to the bottom, you'll see deny IP, any any. 237 237
And with this means, this is an explicit deny. 238 238
It's saying anything that is not already allowed, 239 239
we are going to deny. 240 240
So if we go down this list, 241 241
you'll see things like www, 443, echo reply, domain, 242 242
these are the things that are allowed, 243 243
and when I talk about domain here, we're talking about DNS. 244 244
That's the way that Cisco talks about DNS servers. 245 245
So this is basically saying equals port 53, 246 246
but as you look through this, 247 247
these are all the things that are allowed going 248 248
from the DMZ. 249 249
The DMZ can go out 250 250
and get web traffic over port 80 or port 443. 251 251
It can reply to echo requests, which is ICMP. 252 252
It can use port 53 both as UDP and TCP. 253 253
These are the things that this thing is allowed to do 254 254
from this range. 255 255
Now, when I get down to the last statement, 256 256
if any of those things didn't happen, for instance 257 257
somebody tried to go to port 21 and access FTP, 258 258
what would happen? 259 259
We would get down to that last statement 260 260
which is deny any any, 261 261
this means deny any IP going from any IP to any IP, 262 262
and this ACLs configured essentially as a allow list. 263 263
Only the things allowed, permitted are going to happen. 264 264
Everything else will get blocked. 265 265
Now, another thing we need to talk 266 266
about with this deny is what is deny really going to do? 267 267
Well, it can do two things. 268 268
It can drop or it can reject. 269 269
Now, I know those sound like the same thing 270 270
but in firewalls, that is actually a different action. 271 271
You can configure your firewall 272 272
of how it's going to respond 273 273
when it hits a deny statement, is it going to 274 274
drop that traffic or is it going to reject it? 275 275
Now, any deny rule can either drop a packet 276 276
or explicitly reject it by sending a TCP reset 277 277
if you're doing a TCP connection, 278 278
or an ICP port or protocol unreachable 279 279
if you're using UDP back to the requester. 280 280
Now, why would you want to drop something versus rejecting it? 281 281
Well, by dropping traffic, it makes it harder 282 282
for an adversary to identify port states more accurately. 283 283
For instance, there's a thing called firewalking. 284 284
And firewalking allows an attacker to 285 285
use this reconnaissance technique to enumerate 286 286
your firewall configuration and attempt to figure 287 287
out what hosts are sitting behind it. 288 288
So if you have a firewall, 289 289
you don't want people to see what's behind there. 290 290
You don't want them to see your servers and your host, but 291 291
if an attacker uses firewalking, 292 292
they can actually go through your firewall 293 293
and figure those things out. 294 294
Now, you might say, how do they do that? 295 295
Well, firewalking is going to occur when 296 296
an attacker finds an open port on a firewall 297 297
and then they send a packet with a TTL, 298 298
a time to live of one past the firewall to find its host. 299 299
So maybe I found 300 300
that this particular firewall ACL had port 80 open 301 301
because they're running a web server. 302 302
I can then use that port to get 303 303
into the network and then see what other servers are around 304 304
by attempting to enumerate different servers 305 305
within that network, that's the way firewalking works. 306 306
Now, how do you stop firewalking? 307 307
Well, the easiest way is 308 308
by blocking outgoing ICMP status messages. 309 309
This will prevent firewalking 310 310
because I said, they're going to send something in 311 311
with a time to live of one past the firewall. 312 312
That means, when that time to live expires 313 313
by default, it's going to send back an ICMP 314 314
status saying destination unreachable. 315 315
Well, if you block outgoing ICMP, 316 316
they'll never get that message 317 317
and therefore firewalking will be prevented. 318 318
Now, speaking of all these things, leaving our network 319 319
and going back out, how do we filter these things? 320 320
Well, this is known as egress filtering, 321 321
and the way we do this is we apply ACL rules 322 322
to the traffic leaving our network to prevent malware 323 323
from communicating to command and control servers 324 324
or people fingerprinting our network 325 325
or people firewalking our network 326 326
or just stopping anything from leaving our network. 327 327
But the big area that we're concerned 328 328
with right now is malware, 329 329
because we have all these malware that can be beaconing out 330 330
and if we can block it 331 331
at the firewall and they can't reach their C2 server, 332 332
they then can't do anything bad to us. 333 333
So what are some of the best practices 334 334
for configuring egress filters to be able to 335 335
prevent these things from happening to us and make sure 336 336
that we are not going to be targets of something bad? 337 337
Well, the first thing you want to do is only 338 338
allow whitelisted application ports 339 339
and destination addresses 340 340
to be allowed to leave your network. 341 341
As you saw in the ACL I showed you before, 342 342
we only permitted a couple of things. 343 343
We allowed port 80 and port 443 and port 53, 344 344
that was it. 345 345
We wanted to make sure we kept it as tight 346 346
as possible to make sure nothing bad left our network. 347 347
By using this allow list approach, you really 348 348
can control what's leaving your network a lot better 349 349
and make yourself a lot more secure. 350 350
The second thing you want to do is restrict DNS lookups 351 351
to trusted and authorized DNS services. 352 352
We talked about secure and recursive DNS lookups previously 353 353
and this is basically that same idea. 354 354
If we restrict the DNS lookups 355 355
to our own DNS servers or our ISP's DNS servers 356 356
or something like Google's DNS servers that we trust, 357 357
we can then be assured that these are good things. 358 358
And so we can actually lock that down by using ACLs 359 359
and defining where, which IPs we can use port 53 over. 360 360
The third thing we want to talk about here is blocking access 361 361
to known bad IP addresses, known as a block list. 362 362
We've talked about this before and we talked about this 363 363
with fast flux networks where it wasn't very effective 364 364
against that, but it is effective 365 365
against a wide variety of other things. 366 366
Now, when you have a known bad IP address, 367 367
you want to drop that traffic, 368 368
you don't want to respond back to it, 369 369
you don't want to send 'em a reset packet, 370 370
you just want the traffic to go away 371 371
so they don't know that you dropped it. 372 372
The fourth step is to block all internet access 373 373
from host subnets that don't need it. 374 374
So for example, do you have some ICS and SCADA systems 375 375
'cause you work for a big manufacturing plant? 376 376
Do they really need to connect to the internet? 377 377
Well, if they don't, block access from it. 378 378
That way they can remain on your network 379 379
but they can't touch the outside world. 380 380
And if they can't touch the outside world, 381 381
then hopefully the outside world can't touch them either. 382 382
So that's another best practice when we talk about egress. 383 383
Now, while all these best practices can help, 384 384
they're not going to eliminate a hundred percent of malware C2, 385 385
because a lot of these things will also operate 386 386
over social media or cloud-based HTTPS connections. 387 387
For example, if somebody has access to a Slack server, 388 388
you can run malware over that. 389 389
If somebody has access to Facebook Messenger, 390 390
you can run malware over that. 391 391
All of these things can be turned 392 392
into malware C2 services by an appropriate attacker. 393 393
But by doing some of this egress management 394 394
and blocking things down and locking things 395 395
down to an allow list, you can eliminate a lot 396 396
of those threat vectors, and then you can focus on 397 397
the ones remaining by using other techniques. 398 398
Now the next concept we want to talk 399 399
about is the the concept of a black hole. 400 400
And this is another way to configure things 401 401
within your ACLs. 402 402
A black hole is a means of mitigating denial of service 403 403
or intrusion attack 404 404
by silently dropping or discarding the traffic. 405 405
Essentially you black hole it, you throw it away, 406 406
and that way it doesn't get to the intended target. 407 407
Now, blackholing can be very effective for you. 408 408
It's actually a lot more effective 409 409
than using an ACL on a firewall. 410 410
Now why is that? 411 411
Now blackholing can be done 412 412
either at the firewall level or the router level. 413 413
The problem is if you do it at the firewall level, 414 414
you're going to be using a lot of processing power 415 415
to process all those ACL rules 416 416
and black hole that traffic. 417 417
But if you do it at the router level, 418 418
it actually is going to be a lot more efficient. 419 419
So if you're going against 420 420
a distributed denial of service attack, 421 421
you should use blackholing to stop that DDoS attack 422 422
at the routing level. 423 423
So if you're trying to prevent 424 424
a distributed denial of service attack, 425 425
you're better off doing this at the routing layer. 426 426
Blackholing can be used to stop the DDoS attack 427 427
at the routing layer by sending traffic 428 428
to the null interface. 429 429
Now, the null interface is something that's 430 430
on a Cisco router for example, 431 431
and all it does is it drops any traffic that comes to it. 432 432
It's basically saying, throw this away, don't respond to it, 433 433
we don't care about it, and it silently drops 434 434
that traffic and allows you to go about your day. 435 435
Now, black hole routing can be more beneficial 436 436
than other ways of doing things like going through ACLs 437 437
and the reason is it uses a lot less resources 438 438
like I said, than processing an ACL. 439 439
But the challenge here is 440 440
that when you do it at the routing layer, 441 441
you could have legitimate users that lose access too. 442 442
This is because a lot of times attackers don't just have 443 443
a known block of bad IPs. 444 444
Instead, they're using IPs like everybody else is using. 445 445
And so maybe the guy in the apartment 446 446
next door to me is using an internet connection that goes 447 447
through my ISP just like I am, 448 448
and he's part of this distributed denial of service attack. 449 449
If you decide to do a /24 450 450
and block everybody on that subnet, 451 451
you might block me too and I might be a legitimate customer. 452 452
And so that's one of the issues here 453 453
that you have to deal with 454 454
when you start dealing with blackholing. 455 455
So this is just something you have to keep 456 456
in mind as you're trying to create a black hole 457 457
and protect your networks. 458 458
Now, what is a really good use case for a black hole? 459 459
Well, one of them is to use them against dark nets. 460 460
Now, a dark net is any unused physical network ports 461 461
or unused IP address space 462 462
within a local network that's going to be used by an attacker. 463 463
Essentially, let's say you're working for a large company, 464 464
you've got thousands of computers. 465 465
Well, you might have some kind of a /16 assigned to you, 466 466
but you're only using a thousand 467 467
or 2000 out of those 16,000 IPs. 468 468
What are you doing with the rest of them? 469 469
Well, if you want to have a better security posture, 470 470
you should take all those extra IPs that you're not using 471 471
and route them into a black hole. 472 472
That way if an attacker is able to jump into one, 473 473
they're automatically going to get routed 474 474
into the black hole and not into your regular network. 475 475
This redirection of all your dark nets 476 476
to a black hole until they're needed 477 477
for business operations is a great security practice 478 478
and it only takes seconds to implement. 479 479
The last thing I want to talk 480 480
about is the concept of a sinkhole. 481 481
Now a sinkhole is very similar to a black hole 482 482
but it's a little bit different. 483 483
Sometimes people use these terms interchangeably 484 484
but they do have a little variation. 485 485
When we talk about a sinkhole, 486 486
this is a denial of service attack mitigation strategy 487 487
much like a black hole, 488 488
but instead it directs all that traffic that's 489 489
trying to flood a target IP 490 490
to a different network for analysis. 491 491
So instead of just dropping that traffic 492 492
and making it go away like a black hole does, 493 493
we're going to send it off for analysis 494 494
into some network that can handle it 495 495
and get that amount of traffic. 496 496
Now, sinkholing is better than blackholing 497 497
if you want to be able to determine the cause 498 498
of your DDoS attack. 499 499
This way, you can gather the traffic 500 500
and you can analyze it as needed. 501 501
Now, there are a lot of different ways to do black holes 502 502
and sinkholes, 503 503
and it really depends on your use case, but for most of us, 504 504
we just want to protect our networks. 505 505
And so the easiest way to implement 506 506
either of these solutions will be to use something 507 507
like CloudFlare or Akamai. 508 508
Both of these are large ISPs that specialize 509 509
in DDoS mitigation services, and they do this 510 510
by acting as a sinkhole network provider 511 511
for you to scrub any of the traffic 512 512
and then provide the legitimate traffic back to you. 513 513
This helps mitigate the problem 514 514
of legitimate traffic getting blocked 515 515
during a DDoS attack by forwarding it on 516 516
while blocking the malicious traffic for you.