PortWall detects credential brute-force / stuffing and escalates a persistent attacker to a time-boxed block. There are two distinct kinds, and it's important not to confuse them:
- Web / HTTP brute-force — against your sites' login forms, seen through the WAF. Built in on Windows and on the Linux appliance; you switch it on per site by giving the site's login page (see below).
- Windows-account brute-force — RDP / SMB / local-account logon attacks, read from the Windows Security log (event 4625). On by default.
Website logins
PortWall watches one page per site: its login page. Give it under the site's login path - on Windows on the Site Policies page, on the appliance under Sites › Edit › Login & spam protection - for example /wp-login.php for WordPress. Only requests to that page are recorded, so it costs nothing on a busy site. A site without a login path is not watched.
A login attempt counts as failed when the login form is submitted and the site does not redirect - a successful form login normally sends the visitor on to another page, while a failed one shows the form again, or answers 401 or 403. An address that keeps failing is blocked for a limited time, through the same blocks as every other brute-force source; addresses on your allowlist are never blocked. Two settings beside the login path cover sites that behave differently:
- Success status — for an app or API that answers a successful login with a status such as
200rather than a redirect. A redirect still counts as a success. - Failure pattern — for an app whose answer is the same either way: text that appears only on the page a failed login returns, such as
Invalid password. With a pattern set, the page's text decides, not its status.
The CMS preset in the same place (WordPress or forum) adds limits on how often one visitor can use the login, comment and sign-up pages, and for WordPress blocks xmlrpc abuse and the listing of user names. Rate overrides change the preset's limits, in requests per minute, for example xmlrpc=15,login=30.
Windows-account detection (the 4625 source)
This catches someone hammering RDP or SMB on the box itself — attacks a WAF structurally cannot see because they never reach HTTP. It is on by default: the installer puts the worker in the Event Log Readers group so it can read the Security log immediately, no path needed.
To turn it off (or back on), toggle the Windows accounts (RDP / SMB / network logon) source on the Brute-force page; changes apply within ~30 seconds, no restart.
Mail servers, SQL Server & other text logs
Services that authenticate their own accounts (not Windows accounts) write their failures to their own text logs. PortWall tails such a log and extracts the attacker's IP with a regex — so the regex must capture the client IP in a named group (?<ip>…) on a failed-auth line. These sources ship disabled; enable the one you run and confirm its log path.
Mail servers. Pick your mail server from the preset dropdown on the source and it fills the folder, filename pattern and regex for you (choose Other to enter your own). The built-in presets:
| Mail server | Default log folder | Filename | Failure-line regex |
|---|---|---|---|
| hMailServer | C:\Program Files (x86)\hMailServer\Logs |
hmailserver_*.log |
(?i)"(?<ip>(?!127\.)(?!::1")[0-9a-fA-F:.]+)"\s+"SENT: .*(?:authentication failed|invalid user name or password) |
| MailEnable | …\Mail Enable\Logging\SMTP |
*.log |
(?i)SMTP-IN\s+--\s+\S+\s+(?<ip>[0-9a-fA-F:.]+)\s+AUTH\b.*?\b535\s+Invalid Username or Password |
| SmarterMail | C:\SmarterMail\Logs |
*smtpLog.log |
(?i)SMTP-IN\s+\S+\s+\d+\s+(?<ip>[0-9a-fA-F:.]+)\s+AUTH\b.*?\b535\s+Invalid Username or Password(?:.*?(?<user>\S+@\S+))? |
These mail servers start a new log file each day, so the source is pointed at the folder with a filename glob (the newest match is followed as it rotates) — not a single pinned file.
Behind a spam filter / relay? A mail server fronted by a local filter records every attacker as
127.0.0.1(which is allowlisted and can never be blocked). Point the source at the filter's log instead. A filter that only handles SMTP still leaves IMAP/POP3 arriving directly, so those are worth a second source.
SQL Server appends to one fixed file (ERRORLOG), so leave the glob empty. Its failed-login line is matched with Login failed for user '(?<user>[^']*)'.*CLIENT: (?<ip>[0-9a-fA-F:.]+).
The filename glob is only for logs that rotate by name (a new file per day). For a service that appends to one fixed file, leave it empty — clearing it sticks.
Reading the Overview card
The Brute-force card is evidence-first — it reports what PortWall actually detected, not just what a flag says:
- Detecting attacks (green) — PortWall recorded Windows-auth failures, so the source is working, e.g. "detecting Windows-account attacks — 40 in the last 24h."
- Off, N undetected (amber) — the Windows Security-log source is off, and Windows recorded N real failed logons that went undetected. This is a genuine gap, not noise: someone is probing RDP/SMB and you're not seeing it. Turn the source on if you want those caught. It is separate from web brute-force, which is unaffected.
- On but detecting none while Windows shows failures (red) — the source is on but not reading the log; confirm the worker is in Event Log Readers and restart it.
Per-service buckets (windows-auth/smb, windows-auth/rdp, …) are all counted — a detection on any of them shows the source as working.
Blocks & activity
The Brute-force page shows recent failed-auth events (by service) and the currently-active brute-force blocks. A single source that crosses the threshold is escalated to a network block for a bounded time; a distributed campaign against one site is flagged separately.