How to secure access from outside LAN cables (WiFi APs, cameras)?

[Meeho]

What would be a good way to secure a network from unauthorized access via external LAN drops?

I am somewhat less concerned about the IP cameras, but my outside WiFi APs are connected to a Guest and various private (V)LANs, and their ethernet cables are more easily accessible.

HP Aruba managed switch (2930F)
Ubiquity U6 APs
Hikvision IP cameras

 

[MrGuvernment]

You need some gear like CIsco ISA (pain in the butt) to control ports / mac addresses.

Where are your AP's located that someone could get to one and unplug the cable and connect a device to it? And why do you think someone would do that?


If you have your devices on a separate VLAN with very strict ACLs for Inet access and not allowing any other VLAN's access, if someone did get on it, they should not be able to do anything anyways.

 

[Meeho]

You need some gear like CIsco ISA (pain in the butt) to control ports / mac addresses.

Managed switch + OPNsense is what I have to work with. I would like to avoid additional devices if at all possible.

Where are your AP's located that someone could get to one and unplug the cable and connect a device to it? And why do you think someone would do that?

My backyard. If they can they will mindset.

If you have your devices on a separate VLAN with very strict ACLs for Inet access and not allowing any other VLAN's access, if someone did get on it, they should not be able to do anything anyways.

Could you elaborate on this? What sort of ACLs?

 

[SamirD]

I'd use mac binding/filtering on the port if it's possible in the switch or at the router.

 

[Meeho]

I'd use mac binding/filtering on the port if it's possible in the switch or at the router.

That was my initial thought, to limit port access to the WAP's MAC (not very secure but would be passable) but if I understood correctly, the WAP passes the WiFi clients' MAC address to the switch so that's not doable.

 

[SamirD]

That was my initial thought, to limit port access to the WAP's MAC (not very secure but would be passable) but if I understood correctly, the WAP passes the WiFi clients' MAC address to the switch so that's not doable.

No, I meant each wireless device as you should know what those devices should be for the non-guest vlans.

 

[Meeho]

No, I meant each wireless device as you should know what those devices should be for the non-guest vlans.

Aha. It's not a fixed list, but is a limited one. That would be doable.

 

[SamirD]

Aha. It's not a fixed list, but is a limited one. That would be doable.

Keep in mind it's also not bulletproof as someone with a valid mac address from sniffing the air could then use that to get into the network, but that's a lot of work and would only come from a highly targeted attack.

 

[Machupo]

Sounds like a job for 802.1x

 

[hity645]

So your concern is someone can unplug your AP and gain access to your network?

If so, why not use cable locks so you need a key to remove the patch cable?

 

[uberjon]

Maybe use a poe injector that isn't smart enough to turn off power to an incompatible device.

 

[toast0]

Sounds like a job for 802.1x

802.1x isn't very good; you can put most dumb switches between the actual port and the device and the device will authorize the port, then you can pull the plug on that device and the port remains authorized until the switch drops the link.

If you really care, you need to force a VPN for your LAN; then every packet will be encrypted and validated against an active session.

 

[Meeho]

Sounds like a job for 802.1x

That was my thought, but my belief was that I would use it to authenticate the AP, but it seems it can only be used to authenticate individual users? Or can the AP itself be authenticated?

So your concern is someone can unplug your AP and gain access to your network?

If so, why not use cable locks so you need a key to remove the patch cable?

Don't believe it would fit (especially the key). Besides, one could always cut the cable.

Maybe use a poe injector that isn't smart enough to turn off power to an incompatible device.

Not sure what you mean. It wouldn't help if the intruding device doesn't need PoE.

802.1x isn't very good; you can put most dumb switches between the actual port and the device and the device will authorize the port, then you can pull the plug on that device and the port remains authorized until the switch drops the link.

If you really care, you need to force a VPN for your LAN; then every packet will be encrypted and validated against an active session.

I don't think the Unify AP supports VPN.

 

[uberjon]

Not sure what you mean. It wouldn't help if the intruding device doesn't need PoE

If it doesn't support Poe wouldn't it fry the nic? That was my idea.

 

[BlueLineSwinger]

If it doesn't support Poe wouldn't it fry the nic? That was my idea.

Not if its proper 802.3af/at/bt PoE. Such PoE-capable NICs have certain characteristics that let the switch know it is safe to negotiate PoE parameters and power the line. If those are not present in the NIC, no negotiation occurs and the line is unpowered.

There may be some passive/proprietary PoE implementations that could potentially fry a host's NIC. Generally, these should be avoided wherever possible.

https://en.wikipedia.org/wiki/Power_over_Ethernet#Powering_devices

 

[zdziisek]

Maybe it is obvious, but good password is also a must. There are several list of common used passwords like here, here and here. I see every time unchanged/unset passwords or something obvious/easy to guess. I recommend some good system (like first letters of some poem or song - enhanced by numbers and special chars).

 

[Meeho]

Maybe it is obvious, but good password is also a must. There are several list of common used passwords like here, here and here. I see every time unchanged/unset passwords or something obvious/easy to guess. I recommend some good system (like first letters of some poem or song - enhanced by numbers and special chars).

Main services like NAS or firewall are password protected, but I would still like to lock network access.