BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

Home›Scan›Do it by hand›Linux

Do it by hand Linux

Pick a platform: Windows · macOS · Linux · iPhone and iPad · Android. Each section is one thing the Scan area checks: how to do it yourself on this computer, what a clean result looks like, what a finding means, and the vendor page each step follows. The router and the network are the same from every platform, so those sections are too.

1. Filter DNS for every app on this computer

  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 computer 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 the resolver where this system keeps it. With systemd-resolved (Ubuntu, Fedora, Debian desktops): in /etc/systemd/resolved.conf set DNS= to the resolver's addresses and DNSOverTLS=yes for one that offers DNS over TLS (AdGuard, NextDNS, Quad9, Mullvad do), then sudo systemctl restart systemd-resolved. With NetworkManager, nmcli connection modify <name> ipv4.dns <address> ipv4.ignore-auto-dns yes sets it per connection. Without either, /etc/resolv.conf is the file.

    Clean: resolvectl status lists the resolver under the link in use, with +DNSOverTLS in the protocols line when that is on.

    A finding: A resolver handed out by DHCP that is the router, or the ISP, filters nothing, and plain port 53 is readable and rewritable on the path.

    Why this matters

    Sources: systemd, resolved.conf (DNS= and DNSOverTLS=) · systemd, resolvectl · NetworkManager, nmcli · RFC 7858, DNS over TLS

  3. Prove it. resolvectl status or cat /etc/resolv.conf shows the resolver; dig +short ad.doubleclick.net (or host, or nslookup) asks it for an ad domain. Then run the browser check at /scan.

    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 computer and the internet filters ads by DNS. One name filtered and one not is a list difference, not a failure.

    Why this matters

    Source: systemd, resolvectl

  4. Read the hosts file. cat /etc/hosts: localhost, the machine's own name, and whatever you added. The script's hosts row reads it too.

    Clean: Entries you recognise.

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

    Source: hosts(5)

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. 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 · 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 host firewall and what listens

  1. Have a firewall on, with inbound dropped by default. Ubuntu and Debian: sudo ufw enable then sudo ufw status verbose; the default is to deny incoming. Fedora and RHEL: sudo firewall-cmd --state and sudo firewall-cmd --list-all. Anything else: sudo nft list ruleset shows the nftables rules. The script's firewall rows read the service states without root and the rules with sudo.

    Clean: One of them active, with an input policy of drop or reject and allow rules only for services you use.

    A finding: No firewall service active means every listener below is reachable from the LAN. A desktop that only ever sits at home behind the router's NAT is exposed to the devices beside it, which is where a compromised device next door comes from.

    Why this matters

    Sources: Ubuntu Server, Firewalls (ufw) · firewalld documentation · nftables wiki

  2. Know what listens. ss -ltnup lists TCP and UDP listeners with the process. A local address of 0.0.0.0, * or [::] means every interface; 127.0.0.1 means this computer only. The script's listening row names the ports worth knowing: 22 (SSH), 445 (Samba), 5900 (VNC), 3389 (RDP).

    Clean: Only services you use listen on every address, and the firewall allows each from the networks that need it.

    A finding: SSH with password logins on every interface of a laptop that joins public networks will be tried by every scanner on them.

    Source: ss(8)

4. 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

5. 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: ip -6 addr show scope global. 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

6. 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