Network protection
Wi-Fi and connection awareness on phones; port-scan visibility and firewall control on servers.
- Available
- 03
- Limited
- 03
- Not released
- 02
- Coming
- 03
How the attack works
Network attacks start before any login: scanning to find open services, hostile Wi-Fi to sit between you and the internet, and floods to knock a service offline. Visibility comes first — you cannot defend a port you do not know is open.
- STAGE 01
Discovery
Automated scanners probe internet addresses for open ports and identify the software behind them.
- STAGE 02
Position
On local networks, a rogue access point with a familiar name, or spoofed address resolution, puts the attacker in the path.
- STAGE 03
Exploit or intercept
A vulnerable service is attacked, or unencrypted traffic and DNS lookups are read or redirected.
- STAGE 04
Abuse
Compromised machines are enlisted into botnets that scan, send spam or flood other targets.
- Servers with services exposed to the internet
- People on public Wi-Fi in cafés, hotels and airports
- Small offices with flat networks
A common pattern: a newly deployed server receives connection attempts on common ports within minutes of getting a public address, from automated scanners that sweep the whole internet continuously. Any service left open with defaults is found quickly.
Open Wi-Fi, a hostile hotspot or a scanned server port are where many attacks begin. Visibility comes before blocking.
Sensor, rule, evidence, action
Each step carries its own state. A step that is not built is shown as coming, not skipped.
Peer connection counts
The server collector records a peer holding connections on 15 or more distinct remote ports.
AvailableServer agent (Linux)BIDUA-HUB-0002 port scan v2
10 distinct ports from one peer in 60 seconds raises a level-7 incident (ATT&CK T1046). Tested through the real ingest route.
LimitedHubPeer, ports and window
The incident carries the peer, the ports and the window, stamped with the rule id and version.
LimitedAlert; firewall is yours
Administrators change firewall rules from the console. Phones show network type and VPN state; nothing is blocked automatically.
AvailableServer agent, Android 4.50
On phones we report the network type and VPN state, and flag open networks. We do not inspect your traffic.
On servers the agent reports peers that touch many ports, and administrators manage the firewall from the console.
What works today, and what is coming
What works today
06In production or in the current download.
- Server firewall managementAvailable
View and change firewall rules from the console (administrators only).
Server agent (Linux)
- Port-scan incidents from serversLimited
A peer touching 10+ ports in 60 s raises a medium incident; established connections only, so a SYN scan is not seen.
Server agent (Linux)
- DDoS detection on serversLimited
Connection-flood and request-rate rules read by the hub; detect and alert, no automatic blocking.
Server agent (Linux 3.17+, macOS 3.16, Windows 3.14)
- Network type and VPN statusAvailable
Collected from the phone and shown.
Android app 4.48
- DNS protection and blocked-names logAvailable
The phone's DNS filter and a log of names it refused (see Browser and web protection).
Android app 4.48 (4.8 and later)
- Wi-Fi safety score and risk warningsLimited
A 0 to 100 network security score with a reason for every deduction; warnings for open or weak security, a look-alike copy of a Wi-Fi name with different security, a changed router or DNS, a public hotspot and a hotspot that wants a login page, plus a list of networks you trust. The Wi-Fi name needs the location permission and the screen asks for it in plain words. Alerts appear only while a Wi-Fi screen is open (no background watching). Not yet tried on a real phone beyond the first launch.
Android app 4.48
Built, not yet released
02The code exists and is tested in the repository; it has not shipped to users.
- Extra Wi-Fi and network checksNot released
Saved-network access where Android permits it, network-change warnings and optional DNS/TLS comparisons with a chosen baseline. Differences are warning signs, not proof of interception.
- Bluetooth and USB checksNot released
Opt-in repeated tracker-like Bluetooth sightings and USB accessory checks. A sighting does not identify a person, prove tracking or reveal a tracker’s location.
Coming
03Not built yet. Nothing on this list runs today.
- Man-in-the-middle, SSL stripping and ARP spoofing on a phoneComing
Android gives apps no way to see these, so the app shows them as Not available. An optional certificate probe is not built.
Android
- Network reputation and connection blockingComing
Filtering and blocking beyond DNS.
- Evil-twin, ARP-spoofing and MITM detection on computersComing
Needs sensors we do not have yet. Only the macOS desktop module has run on a real machine, for router and DNS change checks.
6 attack families map to this capability
Copied row by row from our engineering register. A family counts as detected only when a rule, a sensor that feeds it and a test that makes it fire all exist.
Feature states above and register statuses measure different things: a feature can be built while the family it addresses stays unobserved, because the register counts sensors and rules, not screens.
| # | Attack family | Status | What the register says |
|---|---|---|---|
| 048 | DDoS / DoS | Partial | Statistical anomaly flags (z-score over a 100-sample window) on the hub's own CPU, memory, disk and network. Hub only; anomalies do not reach correlation; no detection test.Runs in production |
| 049 | Botnet | Partial | Since 2026-10-02 the port-scan rule reads the agent's own events: 10 distinct ports from one peer in 60 seconds raises a medium incident. Only the scanning part of a botnet; established connections only, so a SYN scan is not seen.Runs in production |
| 044 | DNS Tunneling | No sensor | No DNS volume/entropy telemetryNothing runs |
| 045 | Man-in-the-Middle (MITM) | No sensor | VPN/network type is not MITM evidence; no TLS/certificate telemetryNothing runs |
| 046 | ARP Spoofing | No sensor | No ARP telemetry.Nothing runs |
| 047 | Rogue / Evil-Twin Wi-Fi | No sensor | No SSID/BSSID or access-point reputationNothing runs |
What runs where, and what never leaves
Classification happens on the device before anything is queued. Cloud reporting is off by default on consumer devices and turning it off also stops events already queued.
Runs on the device
- Network type and VPN state on the phone
- Wi-Fi safety score, risk warnings and your trusted-network list (Android 4.48); remembered per-network details stay on the phone, and the Wi-Fi name needs the location permission
May reach the cloud
- From servers: peer addresses and port counts, firewall rules and host metrics, to your console
- From an enrolled phone: network type and VPN state
Never leaves
- Your traffic contents — it is not inspected
- The sites you visit over the network
Editions that include it
Android protection you can install today.
> Android phone owners
Local-first protection for your own computer and phone.
> One person, 1–3 devices
Monitoring and protection for Linux servers, with signed agent updates.
> Anyone running servers
One console for your servers, Android devices and alerts.
> Organisations with 5–250 devices
Each feature above names the platform or edition it runs on. An edition's own page lists the full state of that edition.
What to do if…
Practical steps that work whether or not you use our products.
Your server shows a port-scan incident
- 1.List what is listening (ss -tlnp) and close anything that does not need to be public.
- 2.Restrict admin ports (SSH, databases, dashboards) to known addresses or a VPN.
- 3.Scanning is constant background noise; treat it as a prompt to reduce exposure, not as a breach.
You must use public Wi-Fi
- 1.Prefer mobile data for banking.
- 2.Use a VPN you trust, and only HTTPS sites; never click through certificate warnings.
- 3.Forget the network afterwards so the phone does not auto-join a lookalike.
Limits and known gaps
- GAP-01The port-scan rule sees established connections only, so a SYN scan is not visible. It covers only the scanning part of the botnet family.
- GAP-02The register records BE-2 v2 as written on 2026-10-02 and not yet deployed at the time of writing.
- GAP-03DDoS coverage is statistical anomaly flags on the hub's own metrics; anomalies never reach correlation and there is no detection test.
- GAP-04Evil-twin Wi-Fi, MITM, ARP spoofing and DNS tunneling are not observable by the coverage register's strict bar. The Android app adds a look-alike Wi-Fi name warning and a Wi-Fi safety score, but Android gives apps no way to see man-in-the-middle, SSL stripping or ARP spoofing, so those show as Not available. Network type and VPN state are not evidence of a MITM.
- GAP-05An earlier Android dashboard tile reading "No ARP-spoof detected" was hard-coded; the register flags it as misleading copy.
Frequently asked
Do you inspect my traffic?
Will the agent block a scanner automatically?
Capabilities that work alongside it
Password exposure checks, account sign-in safety and hacked-account help today; verified-address monitoring interfaces need a configured provider for results.
A risk score built from real device signals: root, screen lock, encryption, risky apps.
DNS filtering and your own blocked and allowed lists on the phone; page-level browser protection is not built.
Use what works today, and know what does not.
Re-checked against our documentation on 2026-10-14.