How to restrict Wi-Fi sharing via Mobile Hotspot ?

sparktcs

Dear members,
We are seeking valuable solution from PFsense members on how to restrict/block users that are connected to the devices using another hotspot.

Like for example :- We have wireless solution with voucher guest control (Captive Portal) and issuing limited period single user vouchers to users. Now, we came to know that,users are misusing the issued vouchers by sharing their connection to other customer through his mobile hotspot facility. As far as our concerned, this is major loophole and needs to be restrict/block at the earliest.

I hope the the issue above is clear and awaiting for somebody to help us to solve the issue as much as earlier.

Really appreciated any one prompt response.
Thank you.

stephenw10

There is no easy way to do that. The only way I'm aware of is to use TTL values to detect traffic that has an extra hop in the route. That's what, for example, mobile providers use to allow/disallow tethering so they can charge you for it. There nothing included in pfSense to do that for you.

Steve

sparktcs

@stephenw10

Thanks lot
However, Do you know the solution for the same other than PFsense?

stephenw10

Not in any detail, I have never attempted it personally.

It requires you to re-write the packet TTL value to 1 such that any additional hops timeout the connection. There are some threads here on the forum discussing it. Mostly from the other direction!

Steve

sparktcs

@stephenw10
Any link ,plz

johnpoz

@stephenw10 said in How to restrict Wi-Fi sharing via Mobile Hotspot ?:

t requires you to re-write the packet TTL value to 1

What it requires is to look at the TTL and if not the standard, to drop it.

As traffic flows through a router/tether etc - this is a hop, and the ttl should reduce by 1. So what pfsense would need to do is say hey that is not a standard 64 or 128 or 256 ttl, its <63 or <128 - so it must have gone through a nat, or a hop and should be dropped.

But its also possible that the device doing the "sharing" of its connection could mangle the ttl so it doesn't reduce by 1.

Keep in mind you have to account for multiple ttl values, because different OSes or even applications might set a different default ttl on its traffic.

Now I believe what @stephenw10 is suggesting in writing the ttl to 1, would be on the return traffic going back to the client from pfsense. If you set this ttl to 1, the hotspot or tether device should drop the traffic vs sending it on to its "clients"

So if you rewrite the ttl outbound of interface your captive portal is on, where your wireless is to 1, no downstream router/tether/hop should pass this traffic to anything behind them. Then again their device could say screw that and pass on the traffic anyway.. You have cat and mouse game for sure ;) With trying to prevent downstream sharing, and devices wanting to share their connection and not be detected..

There was an old thread around here about mangle the ttl leaving pfsense wan - with the scrub function

here is thread I found where the scrub function was moved too

https://forum.netgate.com/topic/124490/normalizing-ttl-across-all-packets-leaving-wan-interface

This was in response to this old thread.

https://forum.netgate.com/topic/4435/modify-ttl-value-for-security-reasons

But not sure how that could be modified for outbound on the lan side interface.. This was in those old use cases used to alter the ttl so your isp didn't know you were not directly connected to their device.

My understanding is that Mikrotik has some easy way to mangle the ttls..

If this is something people desire both inbound and outbound of pfsense to be able to mangle the ttl, has a feature request been put in.. Seem there is multiple threads about this as of late.

stephenw10

Mmm, exactly. You'll note all those threads are coming at the problem from the other direction; trying to use pfSense bypass the restriction. Which of course implies it can be done so any restriction you add can be bypassed by a determined enough user.
Anyway neither is supported in pfSense directly. You have to script something.

Steve

NogBadTheBad

I had a play with snort earlier and set up an Aruba 11D that will act as a wi-fi router up to a test subnet.

Managed to get it to pick up packets with a ttl of 63 with the following:-

alert ip 172.16.7.0/24 any -> !$HOME_NET any (msg: "Possible hotspot TTL 63"; \
	threshold:type limit, track by_src, count 1, seconds 300; \
	ttl:63; sid:2000001;rev:1;classtype:misc-activity;)

Where 172.16.7.0/24 is the test subnet and .100 the AP wan interface.

05/26/22-17:54:06.556058 ,1,2000001,1,"Possible hotspot TTL 63",UDP,172.16.7.100,56324,1.1.1.1,53,43720,Misc activity,3,alert,Allow
05/26/22-18:00:16.619257 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63410,17.57.146.150,443,0,Misc activity,3,alert,Allow
05/26/22-18:05:16.633911 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63466,17.250.80.105,443,0,Misc activity,3,alert,Allow
05/26/22-18:13:49.475980 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63446,17.57.146.154,5223,0,Misc activity,3,alert,Allow
05/26/22-18:18:55.113972 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63504,17.250.80.166,443,0,Misc activity,3,alert,Allow
05/26/22-18:26:19.196454 ,1,2000001,1,"Possible hotspot TTL 63",UDP,172.16.7.100,61270,1.1.1.1,53,8327,Misc activity,3,alert,Allow
05/26/22-18:33:57.497050 ,1,2000001,1,"Possible hotspot TTL 63",UDP,172.16.7.100,52221,1.1.1.1,53,24179,Misc activity,3,alert,Allow
05/26/22-18:39:43.342478 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63512,23.39.125.62,443,0,Misc activity,3,alert,Allow
05/26/22-18:46:12.775066 ,1,2000001,1,"Possible hotspot TTL 63",UDP,172.16.7.100,54730,1.1.1.1,53,26485,Misc activity,3,alert,Allow
05/26/22-18:53:49.443239 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63501,17.57.146.5,5223,0,Misc activity,3,alert,Allow
05/26/22-18:59:20.057976 ,1,2000001,1,"Possible hotspot TTL 63",UDP,172.16.7.100,49909,1.1.1.1,53,49598,Misc activity,3,alert,Allow
05/26/22-19:04:24.584700 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63518,17.57.146.6,5223,0,Misc activity,3,alert,Allow
05/26/22-19:09:24.569438 ,1,2000001,1,"Possible hotspot TTL 63",TCP,172.16.7.100,63527,17.57.146.87,5223,0,Misc activity,3,alert,Allow

And yes wrong direction

johnpoz

@nogbadthebad no that is really the right direction.. You would want to stop traffic going out, not let it go out pfsense to the internet, just to stop it from going to the client after it has already come back through pfsense.

Best to stop it before it even passes through pfsense in the outbound direction.

I take it snort would notice all ttls that are not standard, like 64 or 128 or 256, etc..

stephenw10

Mmm, that could work if Snort can detect it. If you enabled blocking on that though I could imagine it becoming quite... high maintenance!

johnpoz

@stephenw10 yeah but this would be a good solution because it gives you control, if there is something you need to allow out that has an odd ball ttl, like maybe you have your own downstream router, etc.

The thing is 64 is just one of the standards, different oses and even different applications could use different ttls, but they should all be even

NogBadTheBad

@johnpoz yep snort is looking at all the packets and only alerting when the ttl is 63.

Basically the rule only lists 1 match every 300 seconds otherwise the logs would fill.

I've set my snort to block in both directions but it seems only to block the dst addresses.

NogBadTheBad

@stephenw10 said in How to restrict Wi-Fi sharing via Mobile Hotspot ?:

Mmm, that could work if Snort can detect it. If you enabled blocking on that though I could imagine it becoming quite... high maintenance!

If you do it enough to p**s off the users they'll stop

johnpoz

@nogbadthebad well for example browser on windows going somewhere would set ttl of 128, so it wouldn't catch that traffic. You need more rules looking for say odd ball 127 ttl etc.

NogBadTheBad

I wonder if you could set up a traffic limiter on the interface and get ipfw to rewrite the ttl?

johnpoz

@nogbadthebad there is no real reason to rewrite the ttl, unless you were going to limit to 1 on the return traffic to the client.

The best solution if you ask me is as traffic enters pfsense if the ttl is not a standard ttl like 64 or 128 or 254, drop it.. I am not aware of any applications what would use an odd ball ttl out of the gate..

There are lists out that - here is a sample one

https://subinsb.com/default-device-ttl-values/

Since these are most likely tables or phones doing it - need to figure out what their standard ttl is.. Problem one is 255, if you look for 254, that could be a standard one.. etc..

but looking for say 63 and 127 would be quite common..

stephenw10

Mmm, you want to block the source address really, the rogue router.

johnpoz

@stephenw10 yup that is what I would do, you notice some IP that is sharing its connect - kick the whole thing off.. He will come and ask why not working - say stop sharing!

But just blocking the traffic that is shared - would prob have them scratching their heads to why ;)

NogBadTheBad

@johnpoz said in How to restrict Wi-Fi sharing via Mobile Hotspot ?:

@stephenw10 yup that is what I would do, you notice some IP that is sharing its connect - kick the whole thing off.. He will come and ask why not working - say stop sharing!

But just blocking the traffic that is shared - would prob have them scratching their heads to why ;)

You could run snort in non blocking mode and you'd just see the alerts:-

Screenshot 2022-05-26 at 20.41.45.png

JKnott

@johnpoz said in How to restrict Wi-Fi sharing via Mobile Hotspot ?:

The best solution if you ask me is as traffic enters pfsense if the ttl is not a standard ttl like 64 or 128 or 254, drop it.. I am not aware of any applications what would use an odd ball ttl out of the gate..

Why not set the incoming TTL to 1?. Then the traffic won't reach the devices behind the hotspot.