Here is something most FileMaker administrators don't know, and it isn't their fault: FileMaker Server does not notice how many times someone fails to log in. Not after ten attempts, not after ten thousand. There is no counter, no lockout, no alert, and no throttle. An automated attack can grind away at your server indefinitely and the server will never do anything about it.
This is not a setting you've missed. It's a gap in the product.
Why this is different from a configuration problem
Almost every article you'll find about FileMaker security is a checklist of things to configure — use strong passwords, tighten your privilege sets, don't leave the Admin account enabled, turn on encryption at rest. That advice is all sound, and you should follow it.
But notice what it has in common: every item assumes the problem is something you've done wrong. Fix your configuration and you're safe.
Brute-force protection isn't like that. You can have flawless privilege sets, long random passwords, and encryption enabled everywhere it's offered, and an attacker can still sit outside your server making guesses at a rate of thousands per week, forever, with nothing stopping them and nothing recording that it happened. There is no checkbox in the Admin Console that changes this, because the capability doesn't exist to be switched on.
What we actually see
We monitor access logs across the FileMaker servers we manage. The numbers are consistently higher than clients expect.
On a single server, in a single week, we have recorded more than 3,500 failed FileMaker login attempts. On the same server, more than 500 failed attempts in one day. Those figures are typical rather than exceptional — on some servers, at some times, they run considerably higher.
These are not colleagues mistyping passwords. The pattern is unmistakably automated: steady, methodical, working through username and password combinations at machine pace. It does not stop at five o'clock. It runs overnight, through weekends, and over bank holidays, because there is nobody at the other end who needs a rest.
The client, in every one of these cases, had no idea it was happening. There was no reason they should have — nothing in FileMaker Server was going to tell them.
Who is doing this, and why you
The instinctive response to all this is: why would anyone bother attacking us? We're a six-person firm in Northumberland.
It's a fair question, and the answer is that nobody chose you. Automated scanning tools work through the entire addressable internet continuously, probing every server they can reach for anything that answers. They aren't looking for your company. They're looking for a port that responds, and yours does.
This is why organisation size offers no protection at all. We've run FileMaker servers for clients ranging from national infrastructure operators to single-handed practices, and the bot traffic hitting them is broadly the same. The large organisation has a security team to notice it. The small one usually has nobody whose job that is — which makes the small server the easier target, not the less interesting one.
What actually closes the gap
Since FileMaker Server can't respond to repeated failures itself, the response has to happen at the layer beneath it — the operating system, which can see every connection attempt and can act on what it sees.
Login throttling at the OS level
The standard tool for this is Fail2Ban. It watches authentication activity, counts failures by source address, and blocks addresses that cross a threshold. On the servers we harden, more than four failures from the same IP address within a ten-minute window triggers an automatic one-hour block. Addresses that keep coming back are banned permanently.
The effect is straightforward: an attack that could previously run at thousands of attempts per week gets four tries an hour, and usually far fewer before it's banned outright. That doesn't make guessing impossible. It makes it uneconomic, which for an automated tool working through a list of millions of servers amounts to the same thing — it moves on to an easier one.
Closing the ports nothing needs
The second measure is a properly scoped firewall. A FileMaker Server needs a small, specific set of ports open to do its job. Everything else should be shut. Most servers we take over have considerably more exposed than the solution requires, usually because it was easier to open things than to work out what was needed.
This reduces the surface an attacker can even reach. A scan that can't get a response from a port never gets as far as FileMaker Server's login prompt.
Someone reading the logs
The third measure isn't a tool. Blocking is automatic, but noticing patterns isn't — a new attack technique, a sudden change in volume, attempts against a specific named account rather than random ones. That last pattern is the one worth losing sleep over, because it suggests someone knows something about your organisation rather than simply scanning at random.
Reviewing logs is the difference between finding out about an attack afterwards and catching it while it's still an attempt.
How to check your own server
You don't need us to find out where you stand. If you have access to your server, here's what's worth looking at this week.
- Read your FileMaker Server access logs. They're available through the Admin Console. Look specifically at failed authentication entries, and look at the timestamps — activity clustered at three in the morning is not your staff.
- Count, don't skim. A handful of failures a day is normal life. Hundreds is an attack, and the difference is obvious once you've actually counted rather than glanced.
- Check which ports are open to the outside world, and compare that against what your solution genuinely needs. Anything you can't account for should be closed.
- Check whether anything is watching. If you have no Fail2Ban or equivalent running on the host OS, then nothing is blocking anything — regardless of how well FileMaker itself is configured.
- Check your FileMaker Server version. Claris released five FileMaker Server updates in the past year, each containing security fixes. If you can't remember your last update, that's your answer.
If that exercise turns up nothing, genuinely good — you're in better shape than most. If it turns up hundreds of failed logins you'd never seen, you've just learned something important about a server you're responsible for.
Where we come in
We should be straight about the boundary here, because it matters more than a feature list.
Our standard hosting covers the server OS installation and configuration, FileMaker Server setup, an annual FileMaker update, general monitoring and uptime alerts, daily automated backups, and UK-based support. What it does not include is brute-force detection and blocking, advanced firewall work, ongoing log review, or active incident response. Those sit in our separate hardening package.
We're saying that plainly because the alternative — implying that any standard managed hosting deals with this by default — is exactly the assumption that leaves servers exposed in the first place. If you host elsewhere, the useful question to put to your provider isn't "is my server secure?" but "what specifically is watching my FileMaker login attempts, and who reads the result?"
Fail2Ban, a tight firewall and someone reading the logs won't make a server invulnerable, and we'd be wary of anyone who told you otherwise. What they do is raise the cost of attacking you above the point where an automated tool bothers — and make sure that if something does happen, somebody notices.
At the moment, on an unprotected FileMaker Server, nobody would.
Figures quoted in this article are drawn from access logs on servers we manage, gathered during 2026. This article is provided for general information and does not constitute a security audit of any particular system.