How to Restrict a Web Admin Interface to Trusted IP Addresses

The instruction everyone gets and few execute well

When PaperCut disclosed the August 2026 zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program., giving developers 'zero days' to fix it. in NG and MF, its first mitigation was not a patch. It was: use firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. rules or network access controls so the web interface cannot be reached from untrusted internet addresses. The same sentence appears in nearly every emergency advisory for an on-premises product, because it works regardless of what the bug turns out to be.

The problem is that "restrict to trusted IPs" is a goal, not a procedure. This guide turns it into one. The examples reference a print server on TCP 9191, but the patterns apply to any administrative web interface.

Step 1: Establish what "reachable" means today

Before changing anything, confirm the current exposure from outside your network. Use an external vantage point, whether a cloud VM, a phone on cellular, or an attack-surface scanning service, to test the interface's port. Do not rely on the firewall rule base to tell you; NAT rules, legacy port forwards, and cloud security groups drift from documentation.

Also enumerate what talks to the interface internally. For a print server that typically includes admin workstations, multifunction devices doing badge validation, a mobile-print gateway, and possibly a monitoring system. You will need this list in step 3.

Step 2: Block at the edge first

The fastest and most reliable control is at the internet perimeter. Remove or disable any inbound NAT or port-forward rule that maps a public address to the interface's port. If the server lives in a cloud VPC, edit the security group or network ACL to drop the public source. This single change ends the internet exposure and should be done within the hour of an advisory like PaperCut's, before the more nuanced work.

If a legitimate external need exists, such as an MSP administering the server, do not re-add the public rule with a narrower source. Move that access to a VPN or a proxy (steps 4 and 5). Public source-IP allowlists are brittle: the MSP's egress address changes, someone widens the rule to fix it, and the exposure returns.

Step 3: Allowlist on the host

Edge controls do not protect against an attacker already inside the network, and "remotely exploitable" includes the internal LAN. Add a host-level rule so the interface port accepts connections only from the sources enumerated in step 1.

On Windows, that is an inbound Windows Firewall rule scoped to the port with a remote-address list; on Linux, an nftables or iptables rule with the same shape. Keep the list tight: admin jump hosts or the admin VLAN, the device subnet if the devices genuinely call the web port, and the integration systems. Workstations that only submit print jobs do not need the admin port and should not be in the list.

Host rules are the control that survives a network change. If the server is moved, re-addressed, or cloned into a new VLAN, the allowlist moves with it.

Step 4: Front it with an authenticating reverse proxy

Some workflows genuinely need the interface reachable from unmanaged networks. Mobile printing and self-service release pages are the print-world examples. The answer is not to expose the admin console but to put a reverse proxy in front that terminates TLS, requires authentication (ideally your SSO with MFA), and forwards only the specific paths the workflow needs.

The proxy becomes the only thing reachable from outside, and it does not run as SYSTEM or hold directory credentials. When the next zero-day hits the application behind it, the unauthenticated attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. is the proxy's login page, not the application's request handlers. Pair this with the host allowlist from step 3 so the application accepts connections only from the proxy.

Step 5: Gate administration behind VPN or ZTNA

Administrative access should come through a VPN or a zero-trust access broker that ties the connection to an authenticated identity and a managed device. That gives you a source address you control (the VPN pool or the broker's connector) to put in the host allowlist, and it gives you an audit trail that a raw firewall rule never will.

For the MSP case, issue them named VPN accounts with MFA rather than a static allowlisted address. When the engagement ends, the account is disabled and the access is gone.

Step 6: Handle the workflows that break

Restrictions fail in production when they break something people rely on. Expect these:

• **Devices that call the server on the admin port.** Multifunction devices often validate badges or fetch configuration from the same port as the admin console. Allowlist the device subnet, not individual devices, and confirm with a test badge release before rolling out.
• **Monitoring and backup.** Health checks that hit the web interface will alert when blocked. Add the monitoring source to the allowlist or move the check to a port that is not administrative.
• **Vendor support sessions.** Support engineers may need temporary access. Provide it through the VPN path with a time-boxed account, and document that a public rule is never the answer.
• **Hard-coded URLs.** Mobile print apps and intranet links may point straight at the server. Re-point them at the proxy and set a redirect for the transition.

Step 7: Verify and keep it verified

Repeat the external test from step 1. Then add the check to your regular attack-surface scan so drift is caught. A rule that was correct on the day of the advisory and silently reverted two months later is the most common way this control fails. The explainer on why print management servers are a high-value target describes how that reversion typically happens: a ticket, a quick fix, no review.

Why this ordering

Edge block first because it is fastest and stops the mass-scanning population. Host allowlist second because it holds against internal attackers and survives infrastructure changes. Proxy and VPN third because they preserve legitimate workflows without reintroducing exposure. Doing the steps in that order means you are protected within the first hour and properly architected by the end of the week.

If the server was exposed before you did any of this, restricting access does not undo a compromise that already happened. Follow the process in the guide on hunting for compromise before the vendor publishes indicators to find out whether it did.