Audit didn't like "customer" access touching internal network while sharing AP's - does it matter?

Posted by ADynes@reddit | sysadmin | View on Reddit | 47 comments

We are using Ubiquiti access points with a Cisco 9x00 at the top of the stack in each office doing the inter VLAN routing. Access points broadcast a SSID for customers/vendors, a SSID for internal users, and a SSID for a handful of wireless printers and approved IoT devices (cameras, wireless displays, etc). Each is assigned a different VLAN, each VLAN has it's own subnet. When I initially set everything up I didn't want a separate DHCP server for customers so I used our existing DHCP server. I put in a ACL on the switch relaying port 67 from the customer side directly to the DHCP server on the secure side so customers would get a IP from our standard DHCP server and we could manage everything from one place. I also put in a deny all ACL after that rule for both incoming and outgoing traffic from that subnet. DNS on the customer side is [1.1.1.1/8.8.8.8](http://1.1.1.1/8.8.8.8) and the gateway is directly out our firewall. It's been setup like this for 13+ years now. We did extensive testing initially to make sure the two sides didn't "touch" other then for DHCP. They would like us to have a separate DHCP just for customers/vendors. I asked if they found any actual vulnerabilities. They said no but we should have it separate. I feel with proper ACL's on the Cisco switches, and the fact they couldn't actually show me a vulnerability that adding another DHCP is just to check a box without actually making things any better. Is my thinking wrong?

47 Comments

[-]

Boring_Astronaut8509@reddit

Hey, I totally get where you’re coming from. From a purely technical standpoint, if your ACLs are solid and VLANs are truly segmented, the current setup is reasonably secure. The “audit wants separation” approach is often more about compliance boxes than real-world risk. That said, auditors tend to focus on principle-of-least-privilege and clean separation, even if no real vulnerability is evident. Splitting DHCP could prevent mistakes or misconfigurations down the line - like a misapplied ACL accidentally exposing the internal network - but it does add operational overhead, especially across multiple branches. One middle ground could be using your firewall to handle DHCP for guest VLANs, like you mentioned. That keeps separation, satisfies auditors, and avoids spinning up extra servers or complex replication. In my experience, auditors tend to accept this as a legitimate compromise if documented properly.

teeweehoo@reddit

What they are proposing is sometimes called Defence in Depth. The basic idea is to design a system that will be secure, even if its compromised. For example what if there was a windows DHCP zero day, or if there was some kind of unintended information disclosure (DHCP request for MAC Address with a reserved IP for example?).

ExceptionEX@reddit

I mean I wouldnt do that, and it's fairly easy to have a separate DHCP service for each so not sure if that is the hill I would die on.

catwiesel@reddit

typing this post out took more time and brain power than literally setting up ANY existing or new virtual dhcp server for the customer dhcp Is the "existing dhcp" server running on a windows box? assuming you have AD, you have DHCP, so I am also assuming that may be the existing DHCP server. fun fact, if that would be the case you would need CALs for the customers as well

HappyVlane@reddit

Auditor is correct in not liking it. Guests shouldn't interact with any internal resources. Doesn't matter if it's DNS or DHCP.

Darkace911@reddit

Meraki for it's faults makes this too easy. Click a button and never worry about it again on that SSID.

Tymanthius@reddit

I mean, sure it'd be better to have a fully separate physical network for guests. But it's not practical. What you did is fine for most.

omenoracle@reddit

I’ve never seen a customer deploy separate physical access points for the guest network.

gamebrigada@reddit

You should never allow lowest security networks to access highest security networks in any capacity, especially DC's. If you absolutely require it, it should be DMZ'ed or reverse proxied with all of the application layer security, but never just direct access. This is a pretty basic security rule of thumb. Why? Because RCE's come up all the time for stuff like this. Here's catered examples for your usecase. [https://www.cve.org/CVERecord?id=CVE-2019-1206](https://www.cve.org/CVERecord?id=CVE-2019-1206) Here's another. [https://www.cve.org/CVERecord?id=CVE-2019-0626](https://www.cve.org/CVERecord?id=CVE-2019-0626) Someone exploiting running code from your network that receives the least security attention, on your most secure asset is nightmare fuel.

dudeman2009@reddit

I would personally separate out DHCP. Chances are nothing bad will happen. However, you can't get away from the phrase "chances are". Unfortunately that's cross zone traffic, doesn't matter what it is, it's still cross zone. The easiest solution is to stand up a simple DHCP server and rebuild pools in it however you want to separate the sites, then run your DHCP relay to that device for all guest subnets. I don't know what your infrastructure is, but I work in healthcare and we have an entirely separate ISP circuit for our visitor, completely separate firewalls. The only things that co-mingle are the access points that broadcast all SSIDs, then tunnel all traffic back to the controller where it's split out from there to the two separate networks. Compliance wise, there is only a tiny area where any cross zone traffic could occur IF an exploit was found ONLY in either the access points themselves, or the access point controller. Nothing else in the network is an attack vector for the production network. Short of running completely separate wireless infrastructure (a nightmare here) it's the best option.

Nikumba@reddit

Our guest wifi has a DHCP server from the firewall, and in separate vlans from our internet firewall that way the guest wifi traffic does not touch our internal network.

WhAtEvErYoUmEaN101@reddit

Kid named DHCP relay

sryan2k1@reddit

You need DHCP relay, not exposing the DHCP server to the other VLANs directly.

Resident-Artichoke85@reddit

Or just stand up a guest/vendor DHCP server in a DMZ outside of your normal internal environment (and still use DHCP relay).

zorander6@reddit

I had an auditor tell a client of mine that we should use MAC address filtering for all wireless devices... in 2016.

Gainside@reddit

your right. its not insecure altogether but auditors care about optics and “clean separations” as much as actual risk. Decide if pushing back is worth the time, or if a small guest-DHCP VM is the path of least resistance.

derango@reddit

It’s not the best. You’re right it’s probably fine but there’s more chances for a config mishap exposing things that shouldn’t be exposed. Personally I wouldn’t have used the same dhcp server.

This is what DHCP Relay is for

No it isn't.

Yes it is. We have globally redundant infoblox appliances that serve 100+ offices worldwide. They do everything, internal, guest, external, etc. With DHCP relay the clients never talk to the DHCP server directly and nothing has to be exposed. We're not half assing some firewall DHCP scope per site when it's all central.

pmormr@reddit

We just run guest DHCP from the site's local firewall instead of our main server for most sites. I've also seen entirely separate networks for guest slapped on top. Think like meraki that only handles guest wifi, in full isolation mode, uplinked through the firewall via a public Internet VRF. It's about as clean as it gets, which is probably why they're asking, but it's a pretty inefficient way to do it.

vppencilsharpening@reddit

For guest networks we let the firewall handle DHCP and use a range that is very different than our corporate network (think 10.100 for corporate and 192.168 for guest). That is in addition to separate VLANs/Network Zones in the firewall with an explicit deny rule between zones.

AviationLogic@reddit

This seems like the easy way, just get a controller and let it do DHCP.

snebsnek@reddit

It matters enough that Toast _always_ deploy a completely separate access point. Otherwise, the security relies on your setup being correct. Auditors can't guarantee that will always be the case, so they don't like it "by default".

Nope, they haven't mandated that in years. You have to sign some paperwork saying you understand the risks and they will bill you if you break it and get them to fix it, but they allow riding arbitrary VLANs on customer provided wifi these days.

YeahUAre2@reddit

That is because of PCI requirements however.

IowaITAdmin@reddit

Have the firewall hand out DHCP for the guest VLAN.

anxiousinfotech@reddit

That's what we always do. I've gotten push back on it in the past from IT leaders who want a single source for everything. It helped being a Windows shop being able to say 'then we need a CAL for every guest that gets a DHCP address'...

cheetah1cj@reddit

My company has the firewall hand out DHCP for all devices that get it, internal and guest. This is probably largely due to having 56 separate buildings across 36 locations, so we don't want DHCP to rely on an IPsec tunnel for DHCP and aren't going to have physical servers in every building; but I also think it makes sense, DHCP is not necessarily a security risk.

It's fairly trivial to consume all of the IPs in the DHCP scope that you have access to, but I feel like all this gets an attacker is attention.

Big_Statistician2566@reddit

As a former SysAdmin/IT Manager, now cybersecurity engineer: If everything is setup right, there is no problem having an internal and external WiFi served by the same L3 AP assuming they have different VLANs. What I did once in this scenario was made the guest WiFi the native VLAN with MAC filtering hardcoding internal assets to the internal VLAN. Guest access egress was over our backup internet connection with google public dns servers. Internal WiFi was on a VLAN separate from the wired LAN with specific RBAC access rules for approved resources. The potential problem with running both off the same AP is there is a higher potential for there to be a mistake which causes an access breach. That being said, one could say that about any VLAN configuration if there is a mistake. We’ve never had an auditor argue about it.

Shulsen@reddit

Just in case, if you use a Windows Server for DHCP, your guests will technically need a Server CAL. So another reason to use a separate server for DHCP at the very least if you are primary a Windows shop.

ADynes@reddit (OP)

We bought enough for every employee plus an additional 20. With that said the vast majority of devices connected to our customer Wireless are actually our own people's cell phones and personal devices. I doubt we've ever hit over 15 non-employees actually connecting to it.

--RedDawg--@reddit

I couldn't find a specific EULA to back it up, but I don't think that works legally. Microsoft's site says it should be an EC license for the customers, or you have to get a license for each customer. I dont think there is an argument for concurrent license as a company with 3 shifts that dont overlap cant just buy cals for 1/3rd of the company and have the cals rotate every shift change. And auditor would call that out. Same would apply to the customers which is why the EC license exists. https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license End of the day, nobody is getting fined as there is no way for MS to know or prove anything in any case. Its just an interesting licensing question.

You can't share user CALs across concurrently employed employees. Somewhere in the wording of user CALs they specifically say employees. So it may even be questionable to use them for guests.

tech2but1@reddit

I know this is correct but it sounds completely ludicrous.

Abn0rm@reddit

You airgap between guest and corp networks, only thing they should have in common is the internet connection (and firewall if you setup the guest dhcp on that of course).

Frothyleet@reddit

It's usually very easy to set up a separate DHCP server for your guest wireless - easy enough that it easily justifies the edge-case security concerns around sharing your "internal" DHCP. If correctly configured, your DHCP server is not an immediate security threat. However, future network config changes could unintentionally expose more attack surface, or a new Windows DHCP vulnerability could pop up. The benefits don't really outweigh the risk.

1a2b3c4d_1a2b3c4d@reddit

> just to check a box without actually making things any better. It makes it fool proof, becuase someday you may have a junior or contracvtor that comes oin and changes your ACL, then you are fucked. If you have an isolated system, you are not fucked. It's not about you, it's about the potential for disaster.

Rhythm_Killer@reddit

Don’t know exactly in this case, but an audit is always against a fixed standard or framework or scope, they should be able to point out where this is listed as a requirement of that standard or framework. Plenty of auditors from the big companies like to start cosplaying as consultants and trying to pull you up on various best practices they have spotted; always push back hard on this, they are there to do a very well defined job and they have no business deviating from it. Anything they put in the official write up will be used to beat you up and you may be required to remediate on a dire timescale, so you or ideally the manager needs to keep them in the scope.

Fallingdamage@reddit

Seems like what you did was more complicated than just setting up another SSID with its own DHCP server and only allowing egress traffic to the WAN.

goingslowfast@reddit

If your system relies on perfect configuration, remember that humans aren’t perfect. It isn’t an unreasonable cost to ensure that human error doesn’t cause you a security issue

thortgot@reddit

Have the firewall handle DHCP for guest networks. Not because of audit but licensing. Dont buy CALs for guests. It also removes DNS "snooping" that could be done by guests.

You'll get mixed reviews on whether or not it's a good practice, I've seen a few companies (including my current one) have the firewall handle all DHCP. Hopefully you audit team should allow for compensating controls. Every organization will have certain security requirements that may not line up with your company, so most auditors will let you have an exception as long as you show something is in place that mitigates the risk (your ACL should do that).

FunkadelicToaster@reddit

Eh,. could go either way. We have our firewall handling the guest VLAN DHCP.

Adorable-Lake-8818@reddit

u/ADynes As others are saying, your going to get a mixed bag of responses. At the end of the day it's a question of Time, Effort, and Availability. If you guys are in an environment where your needing extreme security (Government / Government contractor / Medical with HIPPA) then you won't even be asking this question \[I hope, because you should have the budget and resources to splinter your network appropriately\]. Based off my assumption, you should be good. Just going forward note that you guys are to splinter it further (maybe just isolate the AP's and leave them pulling DHCP from a local router at each branch, with instructions that if a customer / external vendor is saying they can't hit the internet to re-boot the AP, and if that doesn't work to reboot their branch router and then their AP, or whatever you guys want to do). Does it suck? Yes. Yes it does. That means even more support time for local branch bullshit, and that gets compounded into your T1 support queue for each branch... that being said, it should be the job the branch manager and junior branch manager to support their own wireless spectrum.

Remarkable-Guess-856@reddit

I would agree with that...

Reply to Post

47 Comments