Do it by hand macOS

1. Filter DNS for every app on this Mac

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 Mac 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 profile, or set the addresses by hand. The resolver's setup page offers a configuration profile that sets encrypted DNS for every network: download it, then System Settings, General, Device Management, where the profile waits to be installed; read the provider and the servers it names before you install, and stop if they do not match the provider's page. Without a profile: System Settings, Network, the connection, Details, DNS, and add the resolver's addresses; that sets plain DNS for that network only.

   Clean: The profile shows under Device Management, or the DNS tab lists the resolver's addresses.

   A finding: A profile from a page you did not choose can set any resolver it likes; the Device Management list is where to look for one you do not remember installing.

   Why this matters

   Sources: Apple, Use configuration profiles on Mac · Apple, Use DHCP or a manual IP address on Mac (the DNS tab) · AdGuard DNS, public servers and setup · NextDNS

3. Prove it. In Terminal: scutil --dns | grep nameserver shows the resolver in use, and dig +short ad.doubleclick.net asks it for an ad domain. Then run the browser check at /scan: the filtering DNS row names AdGuard or NextDNS when either is the resolver. profiles list names the profiles installed for your user.

   Clean: The resolver you chose, and the ad name answered with 0.0.0.0 or nothing.

   A finding: A real address for the ad name means nothing between this Mac and the internet filters ads by DNS: the resolver is not a filtering one, or a VPN or Private Relay replaced it. One name filtered and one not is a list difference, not a failure.

   Why this matters

   Source: Apple, Use DHCP or a manual IP address on Mac (the DNS tab)

4. Read the hosts file. cat /etc/hosts. macOS ships it with localhost and broadcasthost only. The script's hosts row reads it too.

   Clean: Those two, or entries you or a program you know (a VPN client, a development tool) wrote.

   A finding: An entry that sends a bank's or a vendor's name to an address you do not recognise bypasses DNS entirely.

   Source: hosts(5)

5. Check it stays. A VPN, iCloud Private Relay or a removed profile can replace the resolver. Run the script again after any of them; its resolver and canary rows take ten seconds.

   Source: Apple, Use DHCP or a manual IP address on Mac (the DNS tab)

2. A content blocker in the browser

1. Install uBlock Origin, or uBlock Origin Lite where the browser requires it. Firefox takes uBlock Origin. Chrome and Edge take uBlock Origin Lite, the build written for their newer extension interface. In Safari, content blockers come from the App Store and are turned on under Safari, Settings, Extensions. The blocker's own lists are EasyList and EasyPrivacy plus the author's; leave the defaults on.

   Clean: The browser check at /scan reports baits hidden in the ad hiding row and a load difference in the ad requests row. A blocker that hides nothing but blocks every request (uBlock Origin Lite's default) passes the second row only, which is the better of the two.

   A finding: No difference in the requests row means the blocker is off for this site, or a VPN or extension is sitting in front of it. Reload after changing anything.

   Sources: uBlock Origin · uBlock Origin Lite, for Chrome and Edge · Apple, Get extensions to customize Safari on Mac · EasyList

2. Decide what the browser's own DNS does. Firefox and Chrome can resolve names themselves over DNS over HTTPS, in which case the system resolver from section 1 is not consulted by that browser. Firefox: Settings, Privacy & Security, DNS over HTTPS. Chrome and Edge: Settings, Privacy and security, Security, Use secure DNS. Either point it at the same filtering resolver as the system, or leave it on "use the system resolver".

   Clean: The browser check's filtering DNS row names the provider you chose, the same one the system check in section 1 showed.

   A finding: A provider in that row that differs from section 1 is the browser going its own way.

   Why this matters

   Sources: Mozilla, DNS over HTTPS in Firefox · Google, Manage Chrome safety and security (Use secure DNS) · RFC 8484, DNS queries over HTTPS

3. The Mac's own firewall and what listens

1. Turn the firewall on, with stealth mode. System Settings, Network, Firewall: on. Under Options, turn stealth mode on and block incoming connections for the apps you do not expect to listen. Prove it with /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate --getstealthmode; for the packet filter underneath, sudo pfctl -s info.

   Clean: Both print "enabled". The script's firewall rows read the same.

   A finding: The application firewall stops a program that was not expected to listen from accepting connections from the LAN, which is where a compromised device next door would come from. Off, every listener below is open to the network.

   Why this matters

   Source: Apple, Block connections to your Mac with a firewall

2. Turn off sharing you do not use, and know what listens. System Settings, General, Sharing: Screen Sharing, File Sharing, Remote Login and Remote Management off unless you use them. netstat -an -p tcp | grep LISTEN shows what listens; *.22 is Remote Login, *.5900 Screen Sharing, *.445 File Sharing. The script's listening row names them.

   Clean: Only services you use listen on every address.

   A finding: Remote Login or Screen Sharing on a laptop that joins public networks is reachable by everyone on them, password or not.

   Source: Apple, Set up file sharing on Mac (the Sharing settings)

4. Lockdown Mode, if you are a likely target

1. Turn Lockdown Mode on. System Settings, Privacy & Security, Lockdown Mode. It limits what an attack can do if one gets through: message attachments, web technologies, wired accessories, configuration profiles. It is for people who may be targeted by mercenary spyware, and some things stop working. defaults read .GlobalPreferences LDMGlobalEnabled prints 1 when it is on; the script's lockdown row reads it.

   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

5. Take away the advertising identifier

1. Turn personalized ads off. System Settings, Privacy & Security, Apple Advertising: Personalized Ads off. defaults read com.apple.AdLib allowApplePersonalizedAdvertising prints 0 when it is off; the script reads the same.

   Clean: 0.

   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: Apple, Control personalized ads on the App Store, Apple News and Stocks

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: dig +short ad.doubleclick.net @8.8.8.8. 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: 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: ifconfig | grep inet6. 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. Nothing above says whether anything already happened. The device script reads the state of the device today; the browser traces and indicator matching planned for the device scripts come later. For a phone, Amnesty's Mobile Verification Toolkit reads a backup against its indicators. A concrete reason to think you were targeted is a reason to use a helpline, not a tool.

   Why this matters

   Sources: Amnesty International, Mobile Verification Toolkit · Access Now, Digital Security Helpline · Citizen Lab, how targeted ads became a pipeline for spyware