So there have been a few posts this week about MAC cloning not working.
The solution seems to be that cloning the MAC is not enough. Companies are using sophisticated software to create profiles per device to prevent MAC spoofing. That said, when cloning the MAC, you will also need to clone the IP address of your device to your router.
The request is, on the MAC cloning page, we also need a input field for the IP address,gateway,DNS.
You would just do a static IP and not DHCP then on your WAN/internet interface. Nothing new needed. Doesn’t help mitigate device profiling techniques. MAC is layer-2, and IP is layer-3. Profiling it taking place on the application layer-7. Based on where/what your device(s) talk to, and traffic patterns leveraging machine intelligence, and packet inspection (Palo Alto Networks, Aruba, Cisco, Zscaler — all have their own buzz words).
Encrypting/Trafficking all of your connections through a VPN can help remain anonymous… but if the controller or firewalls are unable to identify, they could also build policy that makes VPN more difficult for unidentified users such as a quarantine VLAN. It is getting more difficult; and most enterprise companies are taking the approach of, if it’s not identifiable, block it.
Not trying to say there’s not a problem. I have experience deploying this stuff, and if it’s done right, it’s pretty hard to bypass. It’s also getting easier for lower-budget businesses to implement — toggle buttons and a couple policies.
I agree, all great points but I still think the next logical step is to also clone the IP address on the WAN side.
I’ll do the honours for you:
Related
Aruba Networks Forum, ClearPass - Preventing MAC Spoofing:
I can add something here. Back in the days when I was dealing with the NAC on the engineering side of things, I remember that all devices were profiled based on the initial information sent to their switches. In addition to that, various security appliances on the network would start bombarding the new clients with all possible requests for information. At the end, the NAC would know things like device type (printer/ipphone/computer/router etc) as well as OS, device vendor and many other things. It looks like the travel router with current abilities does not serve its purpose. There is a need to completely mimic a device like a laptop. For example, once the router is up and running, to enable the repeater function a user needs to go to the router gui and enable something. At that time, there must be an option for the router gui to ask user: do you want this router to completely look like the device you currently are connected to it from? yes/no. That would eliminate the need for the user to do the advanced stuff like do ipconfig, replicate all settings like IP, subnet mask, gateway, DNS IP. I guarantee you an average user would have no idea what all that gibberish means. So the router should be able to collect all of that information from the client using the GUI in the same way any NAC-ish device collects that info from the router.
I was thinking something quite similar. GL already publishes an mobile app for router management; presuming the end user is able to successfully connect to $hotspot, why couldn’t the app read all the necessary details/strings/specs/etc required fr that mobile device & then push via curl to the GL router’s API?
… after all, much of what’s seen in the GL GUI is using json.
There is not even need for an app. Once the user hits “yes I want to mimic my end device”, what happens next:
End device connects to router. Router connects to hotel wifi. NAC on the hotel wifi asks the router some information. Router asks the exact same information the end device and forwards that information to the hotel wifi. No native info/settings are ever transferred to the hotel wifi. Hotel wifi would have no way to differ the router from the end device.
Your logic chain is of course the superiour one… but what happens when $endUser, already suffering fr jetlag/screaming kids, forgets & first connects $phone to $hotspot? They’d be kinda f–k’d, wouldn’t they?
They would still hit that yes button and the router would replicate the same settings as if it was before connecting to the hotel wifi. The only exception would probably be the cookies potentially left by the captive portal
This really does come down to exactly what specific details are required to match the fingerprint, as @Authority rightly raises.
IDK about Apple but on Android devices unsolicited network packets (eg: GL router → $phone) are always dropped so I’d think it’d have to be an app-based solution to push the variables.
From my limited experience dealing with NAC, all attempts to identify the device happen in the first second or so. That could be simply forwarded to the end device from the router.
I may be wrong but to me dropping packets sounds like some kind of built in poor man’s firewall/ips capabilities and would not identify the device in the eyes of a nac.
… which will be dropped.
How dare you, sir! /s
IDK about the most recent versions but Android used to run iptables.
I’d love to get some samples of what these so-called ‘solutions’ such as Aruba Network’s use of Clearpass fingerprints. This whole topic takes me back to spoofing my browser’s User Agent ‘back in the day.’
Dropped in the same manner as if the android was connected directly to the hotel wifi. No difference > mimicking successful.
That is exactly what I am saying. No need to spoof. Just forward to the actual client everything coming from the local IPs or at the lower layers in the first ~second
Yeah, I understand the premise perfectly but it’s a question of traffic initiation. If the GL router solicits a stock Android device, it’ll be dropped as there’s no port listening on $phone. The key aspect I’m focusing in on is:
So how can the GL device get that Layer 7 data if there’s nothing for it to pull from? Thus, I think the $phone would require an app to push it.
… but without samples this is all speculation, of course.
I think that is too far away from the point where the NAC gives a go or no go signal. Anything that does not look right at layer 7 will be dropped by rich man’s layer 7 firewall on the Aruba/whatever, but the device’s status of being online will not change. NAC does its job before all of that.
Again, I am no expert and had too many cocktails on my cruise today, celebrating my multiple device Internet access, having paid for one device only. So I will leave this to the experts
Seconded.
Good on you for not get’n grifted! Drink three for me.
There’s a few technologies behind this… The tried-and-true is 802.1x; traditional NAC which identifies company-owned assets through tools like JAMF, Intune, and other agent-based services to know “This device is ours”.
The one that I think we’re running into is the newer Machine-Learning techniques, Cisco’s done it for years through their NBAR (Network Based Application Recognition) and enhanced with their 9800 controller device profiling (ref: Demonstrate Client Profiling on 9800 Wireless LAN Controller - Cisco).
Aruba has taken it a bit further, especially with their new cloud offering “Aruba Central” which is similar to Cisco Meraki’s cloud controller. ClearPass Device Insight Data Sheet | HPE Aruba Networking (arubanetworks.com).
With device profiling, you’re not leveraging on-device services like JAMF/Intune, and client’s don’t need to “report” anything; like a traditional NAC/802.1x… It leverages application traffic patterns, DHCP request types, and packet inspection combined with application identification to “best match” the client to a profile – based on that profile, you’re then able to set policy.
The references above to listening and responding based on request (ref $phone) would likely work for traditional 802.1x… But, depending on policy if they’re also leveraging the device profiling, it may still not work. It is hard to fool the device profiling - in the sense that if traffic patterns change, or don’t match a device profile, it’ll classify as unknown rather easily. Hotels, and businesses that are service BYOD will likely lean more towards the newer Device Profiling policies, than traditional 802.1x. Seeing as, no one is going to install software on their personal devices so they can identify them. Device Profiling doesn’t require any software or input from users; and simply looks at their traffic patterns and behavior.
Personally, I don’t know a way around the device profiling (unlike traditional NAC/802.1x – which doesn’t look at network traffic as much as device reporting/user/agents/MAC). Device profiling is completely device agnostic, and is a bit tricky.
Maybe a small laptop with 2 x wifi and vpn over stunnel or ssh would work?
Let us just start with a MAC / IP / DNS cloning facility and possibly a built-in basic browser before conquering the rest of the world here. I really hope the GL.iNET’s team are watching this thread…
They better be watching; as @Authority just laid out, this tech. evolution/escalation seems to have a severe risk of torpedoing their entire Travel Router line… if not their reputation.
As for mere MAC, IP, DNS Cloning, I doubt that’ll be a real challenge for 'em; I can see it being nothing more than another well labelled link to an ‘Advanced’ modal/screen that consolidates everything into one GUI/modal window instead of scattered across something like GL GUI → Network → MAC Address then GL GUI → Internet → Etherenet → Modify → Ethernet Settings → Protocol → Static.
I know you’ve voiced issues w/ GL, @Almahadeus, perhaps rightfully deserved but in the case of a ‘cloning facility/feature’, I can’t see a technical issue as a roadblock, only a lack of will to work on the GUI.