How to restrict Wi-Fi sharing via Mobile Hotspot ?

[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:-

[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.

[sparktcs]

@jknott
How it is configure it ?

[JKnott]

@sparktcs

That I couldn't tell you, as I've never done it. But if that's done, it will immediately kill DHCP, DNS and everything else. Others here can tell you more about adjusting TTL.

[johnpoz]

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

Why not set the incoming TTL to 1?.

incoming to where? Pfsense?

This board is about pfsense - incoming would mean to what we are here talking about pfsense.

Setting the ttl to 1 would be leaving pfsense back to the client..

clients to internet ttl 127---> pfsense --> out to isp ttl 126

return traffic some ttl by time it gets to pfsense ---> to client ttl 1

When it hits the sharing device, it should not pass it on to the client..

But in that setup pfsense processed all the traffic.. Why not just block it here

client to internet ttl 127 ---> pfsense = DROP..

Neither option is full proof, and can lead to issues. You don't know, the sharing device might already mangle the ttl, so you don't see an odd ttl, they might set it to 255 as it leaves.

Or maybe the sharing devices says hey I don't care if the ttl is 1, Im going to pass it on to my client anyway..

Either way there is really no way to do this currently in pfsense. You could do some dropping of traffic in snort when you see odd ttl, or you could alert so you know hey this IP might be sharing the connection. This would the lease likely to cause any issues. But let you know IP is possible sharing the connection.

But I am not aware of way you could do anything with the traffic as it is returning to the client from pfsense.

There for sure is no way to do this easy in the gui. If the request is to be able to mangle ttls, or drop ttls that don't meet some criteria - that should be a feature request or a bounty..