WFP blocking
Filters live directly in the Windows Filtering Platform. On Windows Server 2025 a new block is active in under 0.5 s, even with 100,000 active filters.
For Windows Server
Brute-force protection for Windows Server that blocks in the kernel.
ServerBouncer detects attacks on RDP, SMB, Exchange, SQL Server and many other services and blocks attackers through the Windows Filtering Platform. If you like, RDP stays closed for everyone until an authorized device knocks. No cloud, no telemetry – all data stays on your server.
- WFP in the kernel
- Learning mode
- Port knocking (SPA)
- 100% offline
The problem
Every open port is attacked around the clock.
RDP, SMB, OWA, SMTP or SQL Server on the internet see thousands of logon attempts a day. Windows locks accounts at best – not the attackers. And account lockout does nothing against unknown exploits, because they never log on.
- Brute force: many passwords for one account.
- Password spraying: one password for many accounts, slow and distributed.
- Distributed attacks from whole subnets with changing addresses.
- Successful break-ins after many failures – often unnoticed.
- Exploits against RDP and other services, without any logon.
How it works
From the event log to a block in the kernel
ServerBouncer runs as a Windows service, reads the event logs and log files of your services, rates every failure and blocks the source through the Windows Filtering Platform – IPv4 and IPv6 alike.
Features
More than counting failures
Learning mode
For the first 7 days everything is detected but blocks are only simulated. You see exactly what would have happened before protection is live.
Password spraying & subnets
Counters per IP, per user and per subnet (/24, /64) also catch slow, distributed attacks.
Many service profiles
RDP, SMB, Kerberos, IIS, Exchange, mail servers, FTP, SQL Server, MySQL, PostgreSQL, OpenSSH, RRAS/NPS, RD Gateway, SIP, firewall log, regex and JSON-lines logs.
Incidents with reactions
A successful logon after many failures, from a new country or from cloud/Tor/VPN becomes an incident – optionally with disconnect session, disable account or block IP.
Access by knocking (SPA)
RDP is closed for everyone until an authorized device sends a signed packet – the only defense that also stops unknown exploits.
Geo and ASN rules
Countries, ASNs, cloud ranges and Tor per service and port – from locally imported files, without online lookups.
Hardening check
Checks NLA, SMBv1, firewall, audit policy, accounts and RDP exposure. Three safe settings can be fixed with one click.
Behavior detection
Crashes of the RDP service, connections without a logon and suspicious process chains after a break-in are detected.
Inside
A UI that explains its decisions
The web UI shows attempts, blocks and incidents live – and at every step, why something happened.
Operation
Web UI for daily work, CLI for automation
Everything the UI can do also works with sbc – ideal for scripts, images and RMM.
PS> sbc status
Service running · learning mode off
Firewall WFP · self-test ok
Active blocks 1 284
Attempts 24 h 18 902
PS> sbc block 203.0.113.0/24 --minutes 240 --reason "spraying"
Blocked 203.0.113.0/24 for 240 min (all ports)
PS> sbc knock rdp.example.com rdp --minutes 60
Knock sent · rdp open for this device for 60 minLive feed (sample data)
198.51.100.23RDPadministratorblocked
203.0.113.77SMBscanner01failure
2001:db8::4fOWAtest.userfailure
192.0.2.141SQLsablocked
198.51.100.9SSHbackup-svcfailure
203.0.113.200SMTPinfoSpraying
Access grants
RDP closed for everyone – open only for your device
With single packet authorization a protected service such as RDP, SSH or SMB stays blocked by default. Your device sends a single UDP packet signed with Ed25519 using sbc knock. ServerBouncer then opens the port only for that address and only for the chosen time (15 minutes to 12 hours).
- Replay protection, clock check and rate limit
- Whitelist and emergency access at the console
- Protected even without a failed logon: exploits never reach the service
Measured, not estimated
Fast enough for any attack wave
Figures from our load tests and a measurement with real WFP on Windows Server 2025.
~110,000attempts per second in the detection engine
< 40 µsp99 per attempt at 10,000 attempts per minute
< 0.5 suntil a new block is active – with 100,000 WFP filters
100,000active blocks in memory add about 1 s
Works fully offline
- No telemetry, no cloud account
- No outbound connections by default
- Geo data from locally imported files
- Local database: SQLite, SQL Server or PostgreSQL (preview)
Your data stays with you
Security software that does not phone home
Logon attempts, user names and IP addresses are sensitive data. ServerBouncer processes them only on your server. By default the web UI is reachable locally only; LAN access is optional and requires a user account and two-factor sign-in.
Security & privacy in detailFAQ
Frequently asked questions
How does ServerBouncer protect RDP against brute-force attacks?
ServerBouncer reads the Windows logon events, counts failures per IP, per user (password spraying) and per subnet, and blocks attackers in the kernel through the Windows Filtering Platform (WFP). In addition, RDP can be closed entirely with access grants: only an authorized device opens the port with a signed packet.
Is ServerBouncer a fail2ban alternative for Windows?
Yes, the idea is similar: read event logs and log files, count failures, block source IPs. ServerBouncer is built as a Windows service for this, blocks via WFP and ships profiles for RDP, SMB, Kerberos, IIS, Exchange, mail servers, FTP, SQL Server, MySQL, PostgreSQL, OpenSSH, RRAS, NPS, RD Gateway and SIP, plus a web UI and CLI.
Does ServerBouncer need a cloud or an internet connection?
No. ServerBouncer works fully offline, there is no telemetry and no outbound connection by default. Geo data is read from locally imported files. All data stays on the server.
What happens in the first days after installation?
ServerBouncer starts in learning mode (7 days by default): everything is detected and decided, but blocks are only simulated. You see what would have been blocked before protection is switched on.
Which databases are supported?
SQLite is the default. SQL Server (including Express) or PostgreSQL (preview) can be used instead.
Can ServerBouncer be deployed automatically?
Yes. The MSI supports silent installation with properties for port, learning mode, whitelist and a prepared configuration file, for example via GPO, Intune or RMM.
Ready to protect your servers?
ServerBouncer is in early access. We look forward to hearing from you.