Port knocking for Windows Server with single packet authorization

What a logon looks like

1. RDP (port 3389) is blocked for the entire internet. A scanner does not see the port as open, an exploit never reaches the RDP service.
2. On your laptop you run sbc knock server.example.com rdp. This sends a single UDP packet to the server's SPA port (default 62201).
3. ServerBouncer checks the packet: device known, Ed25519 signature valid, time within 60 seconds, packet not seen before.
4. If everything checks out, ServerBouncer opens RDP only for your IP address and only for the requested duration (default 60 minutes).
5. You connect with Remote Desktop as usual. The grant closes automatically afterwards – your running session stays connected.

The server never replies to the knock packet, not even on errors. To an attacker the SPA port looks exactly like a closed port. You can tell the grant worked because the RDP connection then succeeds.

Setting up the server

1. Turn on SPA in the configuration file serverbouncer.json: Access:SpaEnabled = true, optionally a different port via Access:SpaPort (default 62201).
2. Create a protected service, e.g. sbc access services set rdp --ports 3389 --protocol both. ServerBouncer first checks whether this would lock you out and warns you if so.
3. Register devices – one key per client (see below). Devices can be removed individually, so a lost laptop is locked out immediately.

Does a port have to be open on the server?

Yes, exactly one: the UDP port for SPA (default 62201, configurable). ServerBouncer creates the Windows Firewall rule for it automatically while SPA is running and removes it when SPA is off. All protected services such as RDP stay closed.

If there is another firewall or a NAT router in front of the server (e.g. at your hosting provider or data center), UDP 62201 must be forwarded to the server there – just like RDP is forwarded today.

Why is an open UDP port harmless? The listener first applies a per-sender rate limit, then checks format and signature. It never replies, executes nothing and opens nothing without a valid signature from a registered device. Forged packets are not counted as attacks either, so nobody can get other people's addresses blocked.

Requirements

• ServerBouncer with SPA enabled on the server, UDP port 62201 reachable from the client.
• Correct time on client and server (60 seconds tolerance). With Windows' automatic time sync this is the normal case.
• A registered device key on the client.
• The grant applies to the IP address that reaches the server. Behind a router or corporate proxy with NAT this is its public address – the grant then applies to all devices behind that address while it lasts. Keep the duration short.

Setting up a client (Windows)

The client is the command-line tool sbc.exe that ships with ServerBouncer. knock and device keygen need no administrator rights.

1. Create a key on the client:
   sbc access device keygen laptop-anna
   The private key stays on the client, protected with DPAPI in the Windows user profile. Only the public key is printed.
2. Register the public key on the server:
   sbc access device add laptop-anna --public-key <key>
   or in the web UI under Access → Devices.
3. Knock and connect:
   sbc knock server.example.com rdp --minutes 30
   then open Remote Desktop as usual.

On the server itself it is even shorter: sbc access device add <name> creates the key and registers it in one step.

macOS, Linux, iOS and Android

Today the client is available for Windows only. The packet format is open and documented (UDP, Ed25519-signed, at most 256 bytes); clients for more platforms are on the roadmap:

• macOS and Linux: a command-line client with the same commands as on Windows.
• iOS and Android: an app that knocks with one tap before you open your RDP client.

Until then there are two options for devices without a Windows client: a Windows machine that knocks for you (the grant then applies to its address – useful when both are behind the same connection), or a time-limited grant for your IP address that an administrator creates in the web UI or with sbc access grant rdp <ip>.

And if something goes wrong?

• Whitelisted addresses (e.g. your office) are always allowed and need no knock.
• Running sessions are never disconnected, even when the grant expires.
• At the server console, sbc access open --local opens all protected services for a limited time (emergency access).
• Every grant, device and emergency opening is recorded in the audit log and the Windows event log.

Why this also helps against exploits

Brute-force protection reacts to failed logons. An exploit against RDP needs no logon. If the port is blocked for every address without a grant, the attacker's packet never reaches the service – which is why it is the only defense that also stops unknown exploits.