How to restrict Wi-Fi sharing via Mobile Hotspot ?
-
@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.
-
I wonder if you could set up a traffic limiter on the interface and get ipfw to rewrite the ttl?
-
@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..
-
Mmm, you want to block the source address really, the rogue router.
-
@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 ;)
-
@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:-
-
@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.
-
@jknott
How it is configure it ? -
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.
-
@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..
-
We have never seriously considered adding this in the past because most people who come here asking about it are really asking: 'please help me break my providers terms of service so I can avoid paying them'. That's hard to support!
Charging per device has always seem pretty pointless to me anyway. Just set data and bandwidth limits and let people use that however they want.
Steve
-
@stephenw10 Something like this would be enough if the TTL from devices reaching my pfsense interface is 64, and my network is 192.168.10.0/27 ?
alert tcp 192.168.10.0/27 any -> any any (ttl:"63"; msg: "connection share"; sid:1; rev:1;)
I wouldn't download any other rules, Snort would run with custom rules only.
-
Incoming from the 'net and being forwarded to the LAN. If it leaves pfsense with TTL 1, it can't be forwarded to hotspot devices, as the TTL will decrement to 0.
-
@mcury said in How to restrict Wi-Fi sharing via Mobile Hotspot ?:
@stephenw10 Something like this would be enough if the TTL from devices reaching my pfsense interface is 64, and my network is 192.168.10.0/27 ?
alert tcp 192.168.10.0/27 any -> any any (ttl:"63"; msg: "connection share"; sid:1; rev:1;)
I wouldn't download any other rules, Snort would run with custom rules only.
Your snort logs will fill up with that, have a look at the rule I posted further up.
It logs 1 occurance every 5 mins.
-
@nogbadthebad Great, I did read this thread and I don't know how I missed that.
Thanks :) -
It works, I just tested using Suricata.
You can disable all active rules, disable promiscuous mode and create that custom rule. -
-
@mcury do you have a tutorial for that sir?
-
@invoker said in How to restrict Wi-Fi sharing via Mobile Hotspot ?:
@mcury do you have a tutorial for that sir?
I did like this:
1- Install Suricata
2- Disable all active rules if you don't need them, disable promiscuous mode and create a custom rule like mentioned by the user @NogBadTheBadalert 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;)
Change 172.16.7.0/24 by your local subnet and test.
Each OS uses a different OS, Windows if I'm not mistaken goes with 128, so you should create a rule to alert or drop when it sees a 127 TTL, Linux and Android uses 64, so you could create another rule to alert or drop when it sees a 63 TTL.
-
If you are creating multiple rules for different ttl lengths remember to increment the sid: value for each rule.