Secure Your Database: A Step-by-Step Guide Print

For FileMaker Server and the databases it hosts.

Overview

FileMaker security works in layers, and each layer covers for the others. Claris is clear that accounts and privilege sets alone don't make a secure app. A well-built privilege set won't help if the server is open to the internet on the default test certificate, and a locked-down server won't help if the Admin account has a blank password.

This guide works from the inside out:

• Part 1: Your database files. Accounts, privileges, scripts and encryption. You need FileMaker Pro and an account with Full Access.
• Part 2: FileMaker Server. The Admin Console settings that apply to every hosted file. You need your Admin Console login.
• Part 3: The server machine and network. The operating system, firewall and traffic filtering around FileMaker Server.

Each step has three parts: why it matters, how to check where you stand, and how to fix it. You can do the steps in any order inside a part, but do the parts in order.

Part 1: Your database files

Open each hosted file in FileMaker Pro with a Full Access account, then choose File > Manage > Security. Security is set per file, so in a multi-file solution repeat these steps in every file.

Step 1. Secure the Admin and Guest accounts

Why. Every new file starts with two accounts. Admin has Full Access and, by default, no password. Guest is inactive by default and, if you turn it on, gets Read-Only Access unless you change it.

Check. In Manage Security, look at the account list. Try opening the file with the account name Admin and an empty password. If it opens, anyone can get in. Also check whether Guest is active.

Fix. Create your own Full Access account with a strong password first. Then give Admin a strong password, or rename it, or make it inactive. Leave Guest inactive unless the solution truly needs it. Write the Full Access credentials down and store them somewhere safe: if you lose them, you may not be able to open or change the file. Keep at least one active account with Full Access.

Step 2. Give every person their own account

Why. Claris calls shared accounts a security risk. You can't tell who did what, and you can't remove one person's access without changing everyone's.

Check. Read the account list. Look for logins like "office", "sales" or "temp", and for accounts belonging to people who have left.

Fix. Create an individual account for each person and delete or deactivate the shared and stale ones. When you set a new account's first password, check the box that makes the person change it at next login. Whoever manages accounts needs to be on an account with Full Access, or on a privilege set that allows managing accounts.

Step 3. Give each privilege set only the access it needs

Why. Full Access is the only privilege set that can change accounts and privileges or open Manage Database. Anyone who has it can change the whole solution.

Check. In Manage Security, look at which accounts use Full Access. Then open each privilege set and review what it allows.

Fix. Keep Full Access for developers. Duplicate Data Entry Only or Read-Only Access (the predefined sets) and adjust the copy for each job. In each privilege set:

• Set Minimum password length and Must be changed every [n] days. These apply to FileMaker file accounts only, not external server accounts.
• Turn on Disconnect user from server when idle.
• Turn off Allow exporting for anyone who doesn't need to export data.

Step 4. Turn off access methods you don't use

Why. Extended privileges decide how a privilege set may connect: FileMaker Pro and Go, WebDirect, the Data API, OData, ODBC/JDBC, XML publishing, or URLs that run scripts. Every method you leave on is another way in.

Check. Open each privilege set and look at its extended privileges.

Fix. Clear every extended privilege the privilege set doesn't need. Enabling an extended privilege only makes access allowable, because sharing for that method also has to be turned on. Part 2 covers the server side of this.

Step 5. Check File Options

Why. A file with no privileges set up logs in as Admin automatically. Even a file you've secured can keep a leftover automatic login.

Check. Open the File menu, choose File Options, and look at how the file logs in when it opens.

Fix. Make the file prompt for an account name and password instead of logging in on its own.

Step 6. Review scripts that run with full access

Why. A script set to run with full access privileges can do things the person running it isn't allowed to do, such as delete or export records. It applies only inside the file where the script is defined, and it doesn't carry into sub-scripts unless they have it turned on too.

Check. In Manage Security, edit a privilege set and set Scripts to Custom privileges. The Notes column shows which scripts run with full access.

Fix. For each of those scripts, read what it does. In any privilege set that doesn't need to run one, set it to Executable only or No access.

More on script steps that reach outside the file, external data sources and container fields will come in a separate deep dive.

Step 7. Encrypt the file

Why. Encryption at rest protects the file itself. Without it, anyone who copies the file, a backup or a drive can read it.

Check. Evaluate the function Get ( EncryptionState ), for example in the Data Viewer. It returns 0 if the file is not encrypted. If it is encrypted, it returns 1 followed by the shared ID.

Fix. Use the Database Encryption feature (Developer Utilities in FileMaker Pro). You will set an encryption password and a shared ID. Give related files the same shared ID so they can open each other without extra prompts. You can also protect specific fields with the Crypt functions, but that does not replace encrypting the file.

Step 8. Plan for the encryption password

Why. When FileMaker Server opens an encrypted file, someone has to supply the encryption password. If every copy is lost, the file and its backups may be permanently unreadable.

Check. Find out where your encryption password lives and who else knows where. Also check whether Admin Console has the password saved for each file.

Fix. Store the password in a password manager and tell a second trusted person where it is. Then decide how restarts should work. If the server saves the password, files reopen by themselves after a restart. If it doesn't, each encrypted file stays closed until an administrator enters the password. Saving is convenient, and not saving is stricter. Choose one on purpose, because a surprise restart will test your choice.

Part 2: FileMaker Server

These settings apply to every file the server hosts. You need access to Admin Console.

Step 9. Run a supported version and keep it current

Why. Claris ships security fixes as updates to supported versions, and the fixes address real problems. Claris's stated policy is to support each major version for two years from release, and a version that ages out stops getting fixes. For example, the 21.1.7 release fixed an Admin Console path traversal and cross-site scripting in a WebDirect custom homepage, and 21.1.8 fixed a path traversal in system script schedules that allowed remote code execution.

Check. Look at the version shown in Admin Console and compare it with the latest release for your major version. Note when that major version was released, then look up its end-of-support date in the support dates Claris publishes. The stated policy is two years from release, but the exact date is the one that counts. The Dashboard shows product updates and notifications.

Fix. Update to the newest release of your major version. If your version has reached its end-of-support date, move to a version Claris still supports. Read the release notes for security sections each time.

Before you move to a new major version:

• Check who connects. A major version of FileMaker Server typically accepts FileMaker Pro and Go clients up to two major versions older than itself, and a newer client needs a recent enough server. Check with the people who connect, and upgrade their FileMaker Pro and Go as well where needed.
• Check operating system compatibility on both sides: the server machine and every computer or device that connects. Claris publishes technical specifications for each version that list supported systems.

Step 10. Lock down Admin Console

Why. Admin Console controls the whole server. Anyone with access can also make local copies of your databases.

Check. Review who has an Admin Console login. Look at Administration > Restrict Access to see whether access is limited by IP address.

Fix.

• Use a long, unique password for the Admin Console account.
• Turn on Restrict Access and list the IP addresses that need it. The address 127.0.0.1 is always allowed. Check the list before you save, because a wrong list can lock you out.
• Use administrator roles to give staff limited access instead of sharing the main login.
• Keep the list of people with access short.

If you host with ODITech: you have full Admin Console access, but please don't turn on Restrict Access or change the Admin Console password yourself. Our automated maintenance and support use that login and need that access, so either change can stop them from working. If you want Admin Console limited to certain IP addresses or the password changed, contact us and we'll do it so everything keeps working. We also monitor Admin Console logins for brute-force attacks and block abusers automatically.

Step 11. Keep Filter databases on

Why. When Filter databases in Client Applications is enabled, users see only the databases their accounts can open. That keeps your file list away from people probing for a way in.

Check. In Admin Console, open Configuration > FileMaker Clients and look at Filter databases in Client Applications.

Fix. Set it to Enabled. That is the default, and Claris warns that disabling it may expose your database list to unauthorized people.

Step 12. Install a real SSL certificate

Why. The certificate that ships with FileMaker Server is intended for testing. Claris recommends a custom certificate from a trusted certificate authority.

Check. Open your server's address in a web browser. You should see no certificate warning, and the name on the certificate should match your server's name.

Fix. Request a certificate for your server's domain name and import it in Admin Console under Configuration > SSL Certificate. FileMaker Server 21 introduced built-in scripts for free Let's Encrypt certificates on macOS and Ubuntu (not Windows), and version 22 and newer lets you request and renew them from Admin Console. The domain name must be reachable on port 80 while Let's Encrypt validates it. According to Claris, importing a custom certificate turns on SSL for all Database Server client connections, and web clients are limited to HTTPS.

If you host with ODITech: we install an SSL certificate on every server by default, issued for your server name (for example, yourname-fms-lax.oditech.com), and we maintain and renew it for you at no charge. On servers running FileMaker Server 22 or newer, we use FileMaker's own Let's Encrypt support. On the others, we use our own automated script that requests the certificate and renews it. If you want to use your own domain name (for example, fms.yourdomain.com), you can purchase a custom SSL certificate from us. Custom certificates renew automatically each year until you cancel, and we offer an installation option for them.

Step 13. Turn off services you don't use

Why. Every service is something that can be attacked, and a bug in a service you never use is still your bug.

Check. In Admin Console, open the Connectors section and review each service: web publishing, WebDirect, the Data API, OData and ODBC/JDBC. The page also holds other settings, such as plugins and, on newer versions, a standby server, and the sections vary depending on your version of FileMaker Server.

Fix. Disable the ones you don't use. For the ones you do use, make sure only the privilege sets that need them have the matching extended privilege (Step 4).

Step 14. Back up, and test a restore

Why. A backup you have never restored is a hope, not a backup.

Check. Look at the schedules in Admin Console. FileMaker Server ships with a daily backup schedule that keeps 7 days of backups. Confirm that schedule is still there, when it last ran, and where the backups are stored, and decide whether 7 days is enough for you.

Fix. Schedule regular backups and keep a copy somewhere other than the server itself. Protect the backup media as carefully as the server. Once, restore a backup to a test location and open it. If your files are encrypted, you will need the encryption password to do that.

If you host with ODITech: we keep a weekly full server snapshot, and you can download your backups from a web-based file browser that you open from our client area. We also offer an off-site backup service that copies everything in your backup folder every day, encrypts it, stores it in another data center, and keeps it for one month.

Part 3: The server machine and the network

Step 15. Give FileMaker Server its own patched machine

Why. Claris advises against running other network services, such as an email server, on the same machine as FileMaker Server. Every extra service is more to patch and more to attack.

Check. List the services running on the machine. Check that the operating system version is one Claris certifies for your FileMaker Server version, and that it has current updates. If it's in your office, check who can physically reach it.

Fix. Move unrelated services elsewhere, update the operating system, and put the machine and its backup media somewhere locked. Turn off old protocols such as SSLv2 and SSLv3 on any other network service the machine runs.

If you host with ODITech: our servers run FileMaker Server and its supporting services and nothing else. We apply operating system updates and FileMaker Server updates for you. Major-version upgrades (for example, 21 to 22) are included with our Pro-active Management service.

Step 16. Open only the ports you need

Why. Claris recommends a firewall on the public side of the deployment. A closed port can't be attacked.

Check. From a machine outside your network, test which ports answer. Compare the result against this list.

Fix. Close anything you don't use. If nobody uses ODBC/JDBC, port 2399 should not answer. Ports 80 and 443 are used by FileMaker Server even when web publishing is off.

If you host with ODITech: every server runs a server firewall, and a separate network firewall adds another layer of protection. By default, only the ports FileMaker Server needs are open. The ODBC/JDBC port is opened on request.

Step 17. Block repeated failed logins

Why. Automated attacks guess passwords all day. Without a block, they eventually get lucky.

Check. Read your logs for the same address failing repeatedly in a short window. If you see a long run of failures and no block, you have no protection.

Fix. Use your firewall or an intrusion-prevention tool to block addresses after repeated failures, and keep passwords long enough that guessing is hopeless.

If you host with ODITech: on every server, repeated failed logins to Admin Console or WebDirect from the same address are blocked automatically, which stops password guessing early. If you get blocked, contact us and we'll remove the block.

Step 18. Filter and watch web requests

Why. Web-facing services such as WebDirect and the Data API get probed constantly. Most of it is junk aimed at paths your solution doesn't have.

Check. Review your web server logs for the paths and files that draw the most errored requests. Sort by count. The top of the list is usually someone scanning.

Fix. Block the abusive paths at your web server or firewall, and repeat the review on a schedule. A filtering layer in front of the server works best, because blocked requests never reach FileMaker.

If you host with ODITech: each week we review which paths and files draw the most errored requests across our servers, and we block the abusive ones on every server.

Keep it secure

• Remove access the day someone leaves. Deactivate their account in Manage Security and take them out of any Admin Console role.
• Review accounts and privilege sets on a schedule.
• Check for FileMaker Server updates each month.
• Plan upgrades before a version goes out of support.

More detail on privilege set design, scripts and external data sources, and patching will come in separate deep dives.