Best practices

Services built on rpcbind - NFS, mountd, nlockmgr, status, and related RPC programs - don't keep a fixed port-to-program mapping. The same ephemeral port can register as nlockmgr on one scan and unknown or a different RPC program on the next, purely because that's how the RPC portmapper works, not because anything changed about the service itself.

If you run NFS (or another rpcbind-based service) and expect it to keep running, SurfaceDiff will correctly report every one of these fingerprint changes as a separate Service changed incident - that's the system doing its job, reporting a genuine, observed difference between scans. It's just not one you need to review every time.

What to do: mute the specific port once. From the incident, click through to the affected domain, find the port in the "Open ports" section, and click Mute. Future fingerprint changes on that exact host and port stop being emailed to you - though you'll still see a record of them in your incident history, already marked reviewed, not hidden. If the service ever stops responding entirely, or a genuinely new port opens, that's a different incident type (Port closed / Port opened) and isn't affected by this mute.

Reviewed and Resolved apply to one specific incident - they record how that single event was handled, with a required reason, for the audit trail. They don't change whether the same kind of change alerts you again next time. Mute is the one that actually stops future recurrences of that specific finding from reaching your inbox. If something keeps coming back after you've marked it Reviewed a few times, Mute - not repeatedly marking it Reviewed - is what you want.

SurfaceDiff deliberately paces how often it re-checks each open port on a host - fast enough to stay current, slow enough not to look like an attack to automated defenses (fail2ban and similar) running on the target. On a host with many open ports, or one that changes a lot, that pacing means a full re-check of everything can take longer than a single scan cycle.

If it's your own infrastructure, the fix is simple: find SurfaceDiff's current scanning IP for that domain under Settings → Scanning host in your dashboard, and allowlist it wherever the traffic is being filtered - firewall, fail2ban, or WAF. Once our traffic isn't at risk of tripping your own defenses, checks complete faster and more completely - there's nothing to configure on our side, this only affects how your own infrastructure treats the traffic. As of this writing that IP is 194.9.62.184, used below as the example address.

fail2ban (Linux)

# /etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 194.9.62.184

sudo fail2ban-client reload

ignoreip under [DEFAULT] applies to every jail on the host, including ones added later - no restart needed, reload is enough.

UFW (Uncomplicated Firewall, Linux)

sudo ufw allow from 194.9.62.184

pfSense

Firewall → Aliases → add a Host alias (e.g. surfacediff-scanner) for the IP, then Firewall → Rules → WAN and add a Pass rule for that alias, placed above any rule that would otherwise block or rate-limit the traffic.

Cisco ASA

object network SurfaceDiff-Scanner
 host 194.9.62.184
access-list OUTSIDE-IN extended permit ip object SurfaceDiff-Scanner any

Mikrotik RouterOS

/ip firewall address-list add address=194.9.62.184 list=surfacediff-allow
/ip firewall filter add chain=input src-address-list=surfacediff-allow action=accept place-before=0