Sharing Detection

Sharing Detection is ProxPanel’s defence against the single most common form of revenue loss in residential ISP networks: one subscriber paying for an account and lending it (or selling it) to neighbours. The system uses TTL fingerprinting plus connection-count thresholds to identify subscribers whose traffic profile is inconsistent with a single household.

Detection runs on schedule (default 2 AM) or on demand. It is non-disruptive — by default it only flags suspect accounts. Optionally, the system can auto-disconnect or downgrade subscribers above a configured suspicion threshold; you decide how aggressive to be.

How to get here

• Sidebar → Sharing Detection (people icon).
• Direct URL: /sharing.

Requires sharing.view. Admins and resellers with the permission see results scoped to their subscribers.

Layout

Section	Purpose
Settings panel (top)	Schedule, thresholds, auto-action, save.
Last scan summary	When it ran, how many subscribers checked, how many flagged.
Results table	Per-flagged subscriber: TTL signature, connection count, suspicion level, recommended action.
Manual scan button	Run a scan now for one subscriber, one NAS, or the whole system.

How TTL detection works

Every IP packet carries a TTL (Time-To-Live) value. Operating systems start with characteristic defaults:

OS	Initial TTL
Windows	128
Linux / Android / iOS / macOS	64
Some FreeBSD variants	64
Old / embedded	255

Each router along the path decrements TTL by 1. So a packet leaving the customer’s PC and reaching your BNG carries initial_TTL − (hops − 1). For a typical home — PC → router → BNG — you’d see 127 (Windows) or 63 (Linux).

The detector reads observed TTL values for each subscriber from the MikroTik /ip/firewall/mangle connection table (added by an auto-installed mangle rule that marks the highest TTL it sees per connection). It then analyses the distribution:

Pattern	What it means
All TTLs come from one expected value (63 or 127)	Normal — one OS, behind one router.
Mix of 63 and 127	Multiple OS — household with both Windows and Linux/Android. Could be legit family use, mild suspicion.
TTLs at expected − 1 (62, 126)	Router detected behind router — the subscriber has a second NAT hop. Common in shared-account abuse.
Many different lowered TTLs	Double router + multiple OS — strong indication of multi-household sharing.

Combined with raw connection count — measured per subscriber from /ip/firewall/connection on the MikroTik — the detector assigns a suspicion level.

Suspicion levels

Level	Thresholds (defaults)	Meaning
normal	Single OS, single hop, < 300 connections	No action.
low	Multiple OS or 300+ connections	Possibly a heavy household. Watch list.
medium	Router-decremented TTL or 500+ connections	Likely sharing. Flag for review.
high	Double-router pattern or 800+ connections	Almost certainly sharing. Auto-action threshold.
critical	Both router-decrement AND 800+ connections	Definite.

Thresholds (ConnectionThresholdLow=300, Medium=500, High=800) live in the handler and are configurable in the settings panel.

Settings

Setting	Stored as	Default
Automatic scanning	sharing_detection_enabled	off
Schedule (cron)	sharing_detection_schedule	0 2 * * * (2 AM daily)
TTL threshold for router detection	sharing_detection_ttl_threshold	2 (any TTL ≤ expected-2)
Auto-disconnect	sharing_detection_auto_disconnect	off
Auto-disconnect minimum level	embedded	high
Notify operator on flag	embedded	on (via Communication Rules)

The cron expression accepts any standard 5-field cron — 0 2 * * * for nightly, */30 * * * * for every half-hour (intense; use only during forensics).

Manual scan

Click Scan Now in the top toolbar. You can:

• Scan one subscriber — pick from the autocomplete; the TTL marks are queried in real time. ~3 seconds.
• Scan one NAS — every online subscriber on that NAS. Useful when you’re investigating one MikroTik. 10–30 seconds depending on session count.
• Scan everything — every online subscriber across every NAS. This is the same path the nightly scheduler takes. Can take several minutes on a 30,000-sub panel; uses parallel queries with a per-NAS timeout cap of 5 seconds plus a 10-second overall budget per NAS.

Results refresh inline as they’re computed. The previous run’s results are preserved until you click Clear Results.

What happens when a subscriber is flagged

1. A row is upserted into sharing_detection_results keyed by subscriber.
2. The audit log records the flag with the operator (or “system” for scheduled scans).
3. If Communication Rules include a sharing_flagged event, you receive a notification.
4. If sharing_detection_auto_disconnect is on AND the level meets the configured minimum, the subscriber is disconnected via CoA. Their is_online flag is cleared. The audit log records the disconnect.

The subscriber row itself is not touched — no permanent change is made. The flag is informational unless auto-action is enabled.

Caution

Auto-disconnect should not be the first defence. Start with enabled=on, auto_disconnect=off for a few weeks, review the results, then turn on auto-disconnect once you trust the thresholds. Hair-trigger thresholds can disconnect customers who happen to use a complex home network (gaming router + work-from-home VPN + smart-home hub) and aren’t actually sharing.

Reviewing results

The results table shows, per flagged subscriber:

Column	Notes
Subscriber	Username, full name, reseller.
Connections	Live count from MikroTik at scan time.
TTL values	List of distinct TTLs seen.
TTL status	normal, router_detected, multiple_os, double_router.
Suspicion level	Computed from the above.
Reasons	Free-text bullet list explaining the verdict.
Actions	Disconnect now, ignore (whitelist), open subscriber.

Whitelisting a subscriber suppresses future flags — useful for the IT guy in your building who really does run three OSes and a VPN.

Common workflows

Set up nightly scanning for the first time

1. Open Sharing Detection → Settings.
2. Tick Enable automatic scanning. Leave schedule at 0 2 * * *.
3. Leave Auto-disconnect off for the initial soak.
4. Save. Check back tomorrow morning to see the first set of results.

Investigate a single suspect customer

1. Scan Now → pick “One subscriber” → enter username.
2. Wait ~3 seconds for the result.
3. If level is high or critical, take a screenshot for the customer file before any action.
4. Click Disconnect now, or hand the case off to your retention team for a polite call.

Turn on auto-disconnect after a soak period

1. Review two weeks of flagged results. Whitelist any false positives.
2. Tighten or loosen the thresholds based on what you saw.
3. Tick Auto-disconnect, set minimum level = high.
4. Save. From now on, every scan that flags high or critical will issue a CoA disconnect.

Permissions

Permission	What it gates
sharing.view	Open the page and see results.
sharing.scan	Run manual scans.
sharing.edit	Change settings, enable auto-disconnect.
sharing.whitelist	Mark a subscriber as exempt.

Related pages

• Subscribers — drilling into a flagged subscriber.
• Sessions — see live PPPoE sessions and disconnect manually.
• NAS / Routers — the source of TTL marks; sharing detection only works on MikroTik NAS for now.
• Communication Rules — sharing_flagged event notifications.
• Audit Logs — every flag, whitelist, and auto-disconnect is logged.