Do it by hand iPhone and iPad

1. Filter DNS for every app on this iPhone or iPad

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 iPhone 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. Install the resolver's encrypted DNS profile. Open the resolver's setup page in Safari (AdGuard DNS and NextDNS both offer a profile; AdGuard's and NextDNS's apps install one for you), download the profile, then Settings, General, VPN & Device Management, where it waits to be installed. Read the provider and the servers it names first, and stop if they do not match the provider's page. A profile sets encrypted DNS for every network the device joins; the per-network DNS setting under Wi-Fi only covers that one network and in the clear. In-app browsers inside Instagram, Facebook and TikTok cannot install a profile; use Safari.

   Clean: The profile shows under VPN & Device Management, and the browser check's filtering DNS row names the provider.

   A finding: A profile you do not remember installing can set any resolver it likes; that list is where to look. A VPN or iCloud Private Relay replaces the resolver for as long as it is on.

   Why this matters

   Sources: Apple, Install or remove configuration profiles on iPhone · AdGuard DNS, public servers and setup · NextDNS

3. Prove it. Open /scan in Safari and run the check: the filtering DNS row names AdGuard or NextDNS when either is the resolver, and the ad requests row shows a load difference once the resolver filters the test host. 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 the profile installed means a VPN, Private Relay or the network is overriding it.

   Why this matters

   Sources: AdGuard DNS, public servers and setup · NextDNS

2. A content blocker in the browser

1. Install a content blocker for Safari. Safari on iPhone and iPad takes content blockers from the App Store (AdGuard, 1Blocker, Wipr and others use Apple's content-blocker interface). After installing one, turn it on under Settings, Apps, Safari, Extensions. In-app browsers inside Instagram, Facebook and TikTok carry no blocker at all; open links in Safari.

   Clean: Safari's Extensions list shows the blocker on, and the browser check's ad hiding row reports baits hidden.

   A finding: A page full of ads in Safari with the blocker on usually means its rules need an update inside the blocker's own app.

   Sources: Apple, Get extensions to customize Safari on iPhone · EasyList

3. Lockdown Mode, if you are a likely target

1. Turn Lockdown Mode on. Settings, Privacy & Security, Lockdown Mode. It limits what an attack can do if one gets through: message attachments, web technologies, wired accessories, configuration profiles, and more. It is for people who may be targeted by mercenary spyware, and some things stop working.

   Clean: On, for anyone with a reason to be targeted; off is the default for everyone else.

   Why this matters

   Source: Apple, About Lockdown Mode

2. Keep automatic updates and Background Security Improvements on. Settings, General, Software Update, Automatic Updates: everything on. Background Security Improvements patch Safari and WebKit between releases, and WebKit is where ad-delivered exploits land.

   Clean: The device is on the current iOS, with automatic updates on.

   A finding: A device a release behind carries every WebKit bug fixed since.

   Sources: Apple, Update iOS on iPhone · Apple, About Background Security Improvements

4. Take away the advertising identifier

1. Stop apps asking to track, and turn personalized ads off. Settings, Privacy & Security, Tracking: Allow Apps to Request to Track off. Settings, Privacy & Security, Apple Advertising: Personalized Ads off.

   Clean: Both off.

   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

   Sources: Apple, If an app asks to track your activity · Apple, Control how Apple delivers advertising to you on iPhone · Apple, Control personalized ads on the App Store, Apple News and Stocks

5. No firewall to check on the phone

1. The router's firewall is the one that matters here. iOS has no firewall setting. 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 a backup with MVT. Amnesty International's Mobile Verification Toolkit reads an encrypted iTunes or Finder backup of the phone against its published indicators. Its documentation is the guide to follow. A clean result is not a clean bill of health: spyware of this grade is built to defeat exactly this kind of check, so a concrete reason to think you were targeted is a reason to use a helpline, not a tool.

   Why this matters

   Sources: MVT, checking an iOS backup · Amnesty International, Mobile Verification Toolkit · Access Now, Digital Security Helpline