Do it by hand Android

1. Filter DNS for every app on this phone

1. Decide which resolver filters. AdGuard DNS, NextDNS, Mullvad and Cloudflare's 1.1.1.1 for Families each publish a filtering resolver; Quad9 filters malware domains but not ads. A Pi-hole or AdGuard Home on your own network is the same thing for every device at once, and the router section below hands it out. If this phone uses a VPN or iCloud Private Relay, that brings its own resolver and wins: set the filter there, or accept that the rows below describe the VPN's resolver.

   Why: A browser blocker protects one browser; the system resolver covers every app that uses it, which is most of them. Apps with their own resolver still bypass it, which the network section tests. More

   Sources: AdGuard DNS, public servers and setup · NextDNS · Mullvad, DNS over HTTPS and DNS over TLS · Cloudflare, 1.1.1.1 for Families · Quad9, service addresses and features · Pi-hole documentation

2. Set Private DNS to the resolver's hostname. Settings, Network & internet, Private DNS (search Settings for it if the path differs; Samsung keeps it under Connections, More connection settings): choose "Private DNS provider hostname" and enter the hostname the resolver publishes, such as dns.adguard-dns.com or the NextDNS profile's hostname. Private DNS is DNS over TLS, so the lookups are encrypted on every network the phone joins. Apps that bring their own resolver still bypass it.

   Clean: Private DNS shows the hostname, and the browser check's filtering DNS row names the provider.

   A finding: "Automatic" means the phone uses whatever the network hands out, encrypted if that resolver offers it, filtered only if the network filters.

   Why this matters

   Sources: Google, Manage advanced network settings on your Android phone (Private DNS) · Android Developers Blog, DNS over TLS support in Android P · AdGuard DNS, public servers and setup

3. Prove it. Open /scan in Chrome or Firefox and run the check: the filtering DNS row names AdGuard or NextDNS when either is the resolver. Both resolvers also have a self-check on their own pages.

   Clean: The provider you chose in the filtering DNS row.

   A finding: "None seen" with Private DNS set means a VPN is in the way, or the network blocks DNS over TLS (port 853), in which case the phone falls back to the network's resolver.

   Why this matters

   Sources: AdGuard DNS, public servers and setup · NextDNS

2. A content blocker in the browser

1. Use a browser that takes a blocker, or lean on Private DNS. Chrome for Android takes no extensions. Firefox for Android installs uBlock Origin from Mozilla's add-ons site; Brave carries its own blocker. Otherwise the Private DNS step above is the filter for every app, browsers included, and the only one most Android phones have.

   Clean: In Firefox with uBlock Origin, the browser check reports baits hidden and a load difference. In Chrome with Private DNS set to a filtering resolver, the filtering DNS row names the provider and the request row shows a difference while the hiding row stays at "not observed".

   A finding: No difference in any row with Private DNS on means the phone is on a network that overrides it, or a VPN is in the way.

   Sources: Mozilla, add-ons for Firefox for Android · uBlock Origin

3. Updates, the nearest thing to Lockdown Mode

1. Check the security patch level. Settings, About phone, Android version: the security update line is the month of the last patch level the phone received. Google publishes what each month fixes in the Android Security Bulletins. Install what is offered, and treat a phone whose vendor has stopped sending updates as one to replace.

   Clean: A patch level from the last month or two.

   A finding: A patch level a year old carries every bug the bulletins have listed since, many of them in the browser engine ads are rendered by.

   Sources: Google, Check and update your Android version · Android Security Bulletins

4. Take away the advertising identifier

1. Delete the advertising ID. Settings, Google, Ads (on older phones, the Google Settings app, then Ads): Delete advertising ID, or Reset advertising ID where delete is not offered, and turn off ad personalization.

   Clean: No advertising ID, or one reset today.

   A finding: Targeted ads are how a target is picked; without the identifier the ad network has less to aim with. It does not remove ads.

   Why this matters

   Source: Google Play Help, Advertising ID

5. No firewall to check on the phone

1. The router's firewall is the one that matters here. Android has no user-facing firewall. The phone accepts few connections from the network by itself; what stands between it and the internet is the router's firewall, and what stands between it and other devices is the network it joins. Avoid untrusted Wi-Fi, or use a VPN on it, and put untrusted devices at home on the guest network. The router section below is the phone's firewall section.

   Source: CISA, Home Network Security

6. The router, from any platform

Every device on the network trusts the router for its address, its resolver and its path out. These steps are done on the router's own pages; the script's router and upnp rows read what it announces without signing in.

1. Open the admin page and change the printed password. The gateway address is the one the script's router row names, or the default gateway in your network settings (often 192.168.0.1, 192.168.1.1 or 192.168.8.1). Open it in a browser. If the password is still the one printed on the router, or the vendor's default, change it now: it is the one credential that protects every setting below.

   Clean: The page asks for a password only you know, over HTTPS where the router offers it.

   A finding: A password printed on the device is known to anyone who has seen the device, and vendor defaults are in every list an attacker tries first.

   Why this matters

   Source: CISA, Home Network Security

2. Hand out your filtering resolver by DHCP. In the router's LAN or DHCP settings, set the DNS server that devices receive to your filtering resolver (the Pi-hole's or AdGuard Home's LAN address, or the public resolver from section 1), and leave the router's own address out of the list. A device that takes DHCP then uses the filter without any setup of its own.

   Clean: The script's resolver row, or ipconfig /all, scutil --dns or resolvectl status, shows the filter's address and not the gateway's.

   A finding: The gateway's own address as the resolver means the router forwards to whatever it was set to, usually the ISP, and nothing filters.

   Why this matters

   Sources: Pi-hole, Post-Install: point the router's DHCP at the Pi-hole · AdGuard Home, Getting Started · Cloudflare, set up 1.1.1.1 on a router

3. Turn UPnP off unless something you run needs it. Find UPnP (sometimes "automatic port forwarding") in the router's advanced or NAT settings and turn it off. If a game console or a service needs it, leave it on and read the port-mapping table (the script's upnp row, or the router's port-forwarding page) once a month.

   Clean: No UPnP gateway answers the search, or the mapping table is empty.

   A finding: A mapping to a remote-desktop, file-sharing or SSH port that nobody asked for is a hole in the firewall; a program on the LAN opened it without a password.

   Why this matters

   Sources: CISA, Home Network Security · CERT/CC, VU#357851: UPnP requests accepted over router WAN interfaces · Open Connectivity Foundation, UPnP Internet Gateway Device v2.0

4. Turn remote management off, and keep the admin page on HTTPS. Find remote management (also "remote access", "WAN access" or "cloud management") and turn it off, so the admin page answers only from the LAN. Prefer the HTTPS address for the admin page where the router offers one; a self-signed certificate on a home router is normal.

   Clean: From outside the network (a phone on mobile data), the public address does not answer on ports 80, 443 or 8443. The script's router row shows HTTP redirecting to HTTPS.

   A finding: An admin page reachable from the internet is reachable by everyone, and it is where a router's known vulnerabilities are usually exploited.

   Why this matters

   Sources: CISA, Home Network Security · CERT/CC, VU#357851: UPnP requests accepted over router WAN interfaces

5. Note the firmware version and look it up. The firmware version is on the router's status or administration page (the script's router row prints the model the router announces over UPnP). Check the vendor's support page for a newer release and turn automatic updates on if the router has them. Then search this site's Vulnerabilities table for the vendor and model: a CVE marked KEV is one CISA has seen exploited.

   Clean: The installed version is the vendor's newest, and no KEV entry names the model.

   A finding: A router on the KEV list with older firmware is a finding today, not at the next update. The router check planned for this server will do the matching automatically.

   Why this matters

   Sources: CISA, Home Network Security · CISA, Known Exploited Vulnerabilities catalog

6. Wi-Fi: the strongest encryption the router offers, and WPS off. In the wireless settings choose WPA3 Personal, or WPA2 with AES where WPA3 is not offered, turn Wi-Fi Protected Setup (WPS) off, and put guests and smart-home devices on a guest network if the router has one, so a weak device cannot see the rest.

   Clean: The network shows as WPA3 or WPA2 in a device's Wi-Fi details, and WPS is off.

   A finding: WPS and WEP are both ways onto the network that do not need the password.

   Source: CISA, Home Network Security

7. The network: what the internet sees, and what walks past the filter

Two directions. Inbound: the public record of your address, read from a public index rather than scanned. Outbound: whether a device can carry its own resolver past the network's filter.

1. Read what the internet sees of your address. Find your public address on the router's status page (the script prints it when the router's UPnP service is on), then open https://internetdb.shodan.io/ followed by the address. It is a free lookup of what Shodan's own crawlers last saw there: ports, hostnames, CVEs. It is a record, not a live scan, and this site never scans you.

   Clean: "No information available": nothing answered the crawlers.

   A finding: Any port listed is reachable by anyone, and that record is the first thing an attacker reads. Match each port to a UPnP mapping, a port forward or remote management, and close what you did not open.

   Why this matters

   Source: Shodan, InternetDB

2. Test whether plain DNS can bypass the filter. Ask a public resolver directly, past the network's own: a computer on the same Wi-Fi: dig +short ad.doubleclick.net @8.8.8.8 (a phone has no terminal for this; the browser check's filtering DNS row is the phone's own view). The script's bypass rows do the same against 8.8.8.8 and 1.1.1.1.

   Clean: A timeout or a sinkholed answer (0.0.0.0, or no such name): the router blocks port 53 outbound or redirects it to the filter, so a device cannot pick its own resolver.

   A finding: A real address means any device or app that brings its own resolver walks past the network filter. The fix is a rule on the router: redirect outbound port 53 to the filter, or block it except from the filter. Pi-hole's FAQ walks through it.

   Why this matters

   Sources: Pi-hole FAQ, configuring devices to use the Pi-hole · Pi-hole documentation

3. Test whether DNS over HTTPS leaves the network. Ask a public DoH endpoint from a device on the LAN: from a computer, curl -s 'https://dns.google/resolve?name=ad.doubleclick.net&type=A'. An answer with an address means the encrypted path is open. Blocking it is a choice: a filtering resolver that offers DoH itself (AdGuard, NextDNS, Mullvad all do) is the better end state, with the known public DoH endpoints blocked on the router for everything else.

   Clean: No answer, or an answer without an address, from the public endpoints you have not chosen; your own filtering resolver answers over DoH.

   A finding: An app with its own DoH walks past the filter the same way plain DNS does, and nothing on the network sees the names it asks for.

   Why this matters

   Sources: RFC 8484, DNS queries over HTTPS · RFC 7858, DNS over TLS

4. Know whether IPv6 reaches the device. Check for a public IPv6 address on the device: the Wi-Fi details screen, which lists an IPv6 address when the router delegates one. An address starting with 2 or 3 is public; the router's IPv6 firewall is what stands between it and the internet, because there is no NAT in the way. In the router's IPv6 settings, confirm the firewall is on and that inbound is blocked by default.

   Clean: No public IPv6 address, or one with the router's IPv6 firewall on.

   A finding: A public IPv6 address behind a router with its IPv6 firewall off is a device on the open internet, whatever the IPv4 side looks like.

   Source: RFC 6092, simple security in IPv6 residential gateways

8. The past

1. If you need to know about the past, read the phone with MVT. Amnesty International's Mobile Verification Toolkit reads an Android phone over USB debugging, or a backup, against its published indicators. Its methodology page is the guide to follow. A clean result is not a clean bill of health; a concrete reason to think you were targeted is a reason to use a helpline, not a tool.

   Why this matters

   Sources: MVT, Android methodology · Amnesty International, Mobile Verification Toolkit · Access Now, Digital Security Helpline