4 hours 25 minutes

Video Transcription

not every device is going to have a NATO to out it will next supplicant there some devices that you want to allow in your network that don't have the ability to speak. 802 out, one x
A lot of times printers fall into this category, right? There's some printers that you can plug them in. They can get an I P address, but they just don't have a NATO to don't want X supplicant. You can't put a certificate on them, but you still want to allow them on the network, and you want to identify them as printers and put him in the right villain.
In this case, you can configure something called Mac off bypass on the switches or on the authenticator. And the way this works is when the printer comes online. The authenticator The switch sees that internal that link state. It sees that new connection, and it sends an IV identity request because it's configured to authenticate.
Well, the printer doesn't know what that is because the sprint the printer doesn't speak, eat or it doesn't speak 802.1 x, so it's just going to sit there. It's not gonna respond.
The authenticator can be configured to send a certain number of responses back or keep request back. And then after it doesn't get a response after a certain number. In this case, let's say it sends it back three times after there's no response received. The switch goes into what's called MAC off bypass.
It then takes the Mac address of that device that it sees connected,
and it puts it into a radius. Request a special, especially formulated radius request called a Radius Mac off request. And it sends it back to that authentication server.
Now the Radius Server. When it gets this type of requests, it knows because of how the request is for made it formatted because it's ah Mac authentication request
that it needs to identify this device based on its Mac address.
So the Radius server goes and it communicates with the back end database server.
This could be an l adapt in a base or some other type of database, but there needs to be some type of database on the back end that has a list of assets in the environment. What their Mac addresses are and more importantly, in the next step where those devices air connected,
this could be, Ah, this could be done manually. It can be done via scripts that go out and do auto detection of devices on the network.
But at the end of the day, you won't have a database that says this device has this Mac address. It's on this port on this switch.
So the authentication server goes back and it says, Hey, what is this Mac address? It doesn't look up.
The database says this is a printer, and by the way, it's this type of print of the, you know, because of its Mac address. It's a Lexmark, whatever. Whatever printer.
At that point, the authentication server can look in its policies and say, OK, do we allow this particular type of printer on our network?
Yes, we do. Okay, cool. Let's send back a radius access decision to the authenticator. Wilson. Becca. Yes, it's allowed on the network, and by the way, it's a printer. So if you have a printer villain, you can put it on the printer V land.
The decision is finalized and in the villains are open and the device is put on the correct Bela.
Now this works pretty well, but there's one fairly significant security flaw with this,
and that is
that's static database. So we're on the right hand side. We talked about having that database of devices and what switch ports there on and what their Mac addresses are. But if you have a static database of devices,
it's fairly easy, especially in the in the case of a printer,
I could walk by a printer. I could print out a test page. That test page has the Mac address of the printer on it. I can then spoof that Mac address and put that Mac address on my own laptop. Make my make my laptop spoof that Mac. And then I can plug my laptop into that printer port. And that authentication we just saw would go off without a hitch,
and the network would think I'm a printer and it's gonna allow me on.
And now I'm on the device and I'm not. I'm on the network, and I'm not what I said. I waas
So one thing you can do to prevent this is you can instead of that being a static database on the back end,
you can have that database configured to ingest net flow data
and net flow data is just all the routers in your environment have the ability to to capture net flow data to look at all of the sessions going through that router and identify for each session. What's the port? What's the source? Address? Destination Address Source. Port Destination Port. What is that high level metadata look like for that network session
so you can start to capture? This is just one way you can. You can create dynamic databases. You can capture that net flow data into the database.
And if you see that printer start to do something that printer shouldn't do, for example, let's say that printer starts communicating on TCP Port 23.
That net flow date is gonna be sent to that back in database. And when the database sees that, it's gonna say, hold on a second. Printers don't communicate on TCP 23. That's a that's a telnet session that's more like something and in user would do. And the database will re categorize that device from being a printer to being an in user. So now the database has changed
that Mac addresses now classified as an in user in the database.
It's changed, but there's but the device is still the printer still out there. The printer is still out there on the network, and it's still communicating,
so at that point you want your database as soon as it detects a category change,
the database could be configured to go out there and connect to that switch via S and MP and bounce the port. Do a port reset and that port reset will force that whole authentication process to start over again. But this time, when the Mac address is sent to the authentication server and the authentication server looks it up
instead of the database saying, That's a printer, it's going to say
that's an in user we sought communicating on 23. It's an in user,
Um, the authentication service says, Oh, no, My policy says if you're a Nen user, you have to have a certificate. We don't Mac off bypass in users, so it's going to send back a access denied message to the switch, and the device is either going to be placed in the guest villain or it's not gonna be allowed on the network,
so that wraps up our section on network access control. Next up, we're going to talk a little bit about wireless and some of the wireless encryption, some of the security around that.

Up Next

Infrastructure Security

This course will cover the concepts needed to identify and prevent threats across an enterprise environment. The course content will cover the practical application of security principles, models, and technology covered in previous courses.

Instructed By

Instructor Profile Image
Scott Russ
Security Architect at Nerdery