FMProxy on David Hamann

FMProxy – Tunneling support, session dashboard and some more

Fri, 14 Aug 2026 00:00:00 +0000

A few months back I wrote about the first FMProxy release, giving an overview about past research and the idea of the proxy as a product.

We used the time since to add features, fix bugs and improve stability of the proxy. Here are a few of the new things worth mentioning:

Support for HTTP tunneling

A few beta testers reached out asking how the proxy would affect the “HTTP tunneling” feature of Pro/Server.

In the beginning we didn’t support it at all, but from version 0.4.0 this channel can now be used with all of FMProxy’s detection capabilities. You just have to enable it during installation:

sudo ./install.sh --features=tunneling

For some background information, here is how FileMaker Server’s “HTTP tunneling” roughly works and what FMProxy does slightly different:

Nginx, shipped and configured with FileMaker Server, accepts WebSocket connections coming from FileMaker Pro and passes them on to an additional listener of fmserverd (by default TCP/8091, started when the feature is enabled via the Admin Console).

FMProxy works by starting its own WebSocket listener on a separate port (by default TCP/8092). To let FMProxy accept the traffic, the Nginx configuration must be adjusted from this:

location ^~ /fms/ws {
 proxy_pass http://127.0.0.1:8091/fms/ws;
 proxy_read_timeout 600s;
 proxy_send_timeout 600s;
 keepalive_timeout 600s;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 proxy_set_header Host $http_host;
 proxy_set_header X-Forwarded-Host $host:$server_port;
}

To this:

location ^~ /fms/ws {
 proxy_pass http://127.0.0.1:8092/fms/ws; # <-- this guy has changed
 proxy_read_timeout 600s;
 proxy_send_timeout 600s;
 keepalive_timeout 600s;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 proxy_set_header Host $http_host;
 proxy_set_header X-Forwarded-Host $host:$server_port;
 proxy_set_header X-Forwarded-For $remote_addr; # <-- and this guy was added
}

As you can see, we just modify the upstream port from 8091 to 8092 and add the X-Forwarded-For header with the remote address of the connecting client. The latter is necessary to transport the actual address of a client to FMProxy – otherwise, we would just have the address of the Nginx proxy itself (which would always be 127.0.0.1 and not very helpful in the logs).

The modification can be taken care of by the installer if you give it the explicit instruction (see feature flag above).

One thing to note: tunneling with FMProxy works slightly different than without it. When tunneling is enabled, FMProxy will not pass the traffic it receives from Nginx to FileMaker Server’s tunneling listener, but rather unwrap it itself and send it to the always available data port (stock config TCP/5003, usually adjusted to 5004 by FMProxy).

Due to this, enabling or disabling the HTTP tunneling feature in the FileMaker Server Admin Console has no effect anymore (i.e. FMProxy’s HTTP tunneling feature also works when FileMaker Server’s tunneling is turned off).

We do this to prevent rewrapping the GIOP messages again (after unwrapping and analysis) and having to manage and keep alive another WebSocket connection. In practice, you should not notice the difference, except that FileMaker’s Get(NetworkProtocol) will return TCP/IP instead of HTTPS even for tunneled connections.

If you require it, you can even have a mixed setup:

Use FMProxy for native traffic, disable HTTP tunneling completely
Use FMProxy for native traffic, skip it for HTTP tunneling (tunneling will still work, but will be invisible to FMProxy)
Use FMProxy for both native and tunnelling traffic

Note that – just like with FileMaker Server itself – traffic via the native channel (i.e. by default 5003) cannot be disabled.

Due to Nginx always being the frontend for the tunneling feature, certificates for tunneling are also always managed by Nginx (as TLS is terminated by Nginx). A certificate configured for FMProxy will not have an effect on the tunneling feature. You can use the FileMaker Admin Console (or fmsadmin) to configure the certificates for Nginx. Just make sure to do a reload of FMProxy in case you use the same certificates for FMProxy.

This brings us to the next new feature: TLS hot reloading.

TLS Hot Reloading

Since FileMaker clients connect directly to FMProxy (using the native, i.e. non-tunnel channel), they also negotiate TLS with FMProxy (not FileMaker Server).

This gives us the opportunity to do what FileMaker Server currently cannot do: swap TLS certificates without restarting the server and without clients being forced to re-connect or scripts stopping mid-execution.

We do this by reacting to a SIGHUP signal and then read the configured TLS certificate/key again. One caveat: if you replace the certificate via the FileMaker Server Admin Console (or fmsadmin), you have to perform one additional FileMaker Server config change afterwards.

This setting is UseSecureConnection which FileMaker Server resets to 1 when you import a certificate. Since the proxy talks to FileMaker Server on localhost without TLS, this setting has to be set to 0.

If it is not reset, the proxy won’t be able to connect to FileMaker Server after the next restart (which would happen eventually :-)).

If you would want to automate the whole process, it could look something like this:

#!/bin/bash

# 1.) Replace certificates (either manually or via FMS admin console). No
# restart of FMS is required.

# 2.) If you've replaced the certificates via admin console/api/fmsadmin, tell
# FileMaker Server to revert back to clear connections (proxy to FMS). If
# you skip this step, the proxy won't be able to connect to FMS anymore
# after the next FMS restart.
# Ignore the message "Please restart the FileMaker Server service to apply
# the change." from fmsadmin – it's not required!
/usr/bin/fmsadmin set serverprefs UseSecureConnection=0

# 3.) Finally, tell FMProxy to reload certificate files (from configured paths)
/usr/bin/systemctl reload fmproxy

# Note: if you want to run this process scheduled/headless, you will need to
# load/pass credentials to fmsadmin as there will be no interactive terminal.

If you don’t manage your certificates with FileMaker Server, a plain /usr/bin/systemctl reload fmproxy is enough. The reload command is really just an alias for kill -s HUP <fmproxy PID>.

Now that you can swap certificates on the fly, how can you see which clients were originally presented with which certificate? With an interactive session dashboard!

Live session dashboard

Installing FMProxy with sudo ./install.sh --features=dashboard will enable a small HTTP server providing live information about currently connected clients/sessions. By default, it will run on port 5353 (bound to loopback).

If you would like to process this information yourself, you can send requests in short intervals to http://127.0.0.1:5353/sessions. This will give you a snapshot JSON representation of what’s currently in FMProxy’s session store.

If you would rather like to see the data within a user interface, you can run the new fmproxy dashboard command. The dashboard will query the same data, but present it interactively in a way that looks something like this:

FMProxy sessions: 1 generated 2026-08-14T13:26:20.200422035+00:00 refresh 2s (↑/↓ or j/k to move, q/Esc to quit)
┌Sessions───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Session IP Channel Connected Tickle Host Username Platform Client Serial DBs TLS Persistent ID│
│ 0x49613320 10.10.99.41:65434 native 5m 48s workstation-01 david.hamann MacOS/26.6.1 Pro 26.0.2 AAAAA-BBBBB-CCCCC-DDDD… 2 73d1ff…ed5874 d8e69c…cec60a│
│ │
│ │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌Session───────────────────────────────────────────────────────────────────────────┐┌Network & databases──────────────────────────────────────────────────────┐┌Paths───────────────────────────────────────────────────────┐
│ID 0x49613320 ││IPs 10.10.99.41, fd7a:2c19:8e4b:0d63:c1f2:9a07:56be:e814, ││Root /Macintosh HD/ │
│Connect ID c3326149ff17e00598ef72be2e790045 ││fd7a:2c19:8e4b:0d63:3b95:71dc:a2f0:4c67 ││Preferences /Macintosh HD/Users/a/Library/Preferences/ │
│Persistent ID d8e69ccc68f742028b5658188bcec60a ││MACs 5e:b3:91:d4:6f:71, 5e:b3:91:d4:6f:3d, 5e:b3:91:d4:6f:a8, ││Documents /Macintosh HD/Users/a/Documents/ │
│Channel native ││5e:b3:91:d4:6f:c2, 5e:b3:91:d4:6f:15, 5e:b3:91:d4:6f:e9, ││Desktop /Macintosh HD/Users/a/Desktop/ │
│Host workstation-01 ││0a:47:d2:8b:31:6c, 0a:47:d2:8b:31:b4, 0a:47:d2:8b:31:27, ││Applications /Macintosh HD/Applications/ │
│User david.hamann ││0a:47:d2:8b:31:6c, e2:9f:44:07:ca:d3, 96:1b:5d:e8:74:2f, ││ │
│Platform MacOS ││2a:f5:60:19:8c:b7, 2a:f5:60:19:8c:43 ││ │
│OS 26.6.1 ││Path fmnet:/fms02.davidhamann.de/test.fmp12 ││ │
│Language English ││Printer Xerox(R) B230 Printer ││ │
│Client Pro 26.0.2 ││ ││ │
│Serial AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF-GGGGG ││Databases (2) ││ │
│Connected 2026-08-14T13:20:43.971578165+00:00 ││test.fmp12 as admin (0x02) [auth] ││ │
│Last tickle 2026-08-14T13:25:32.056192169+00:00 (48s ago) ││FMServer_Sample.fmp12 ││ │
│TLS 73d1ffc4fe4ef21b1f70d7b3d96d9f7dcbd5a1a94415745c2f7f91f649ed5874 ││ ││ │
│ ││ ││ │
└──────────────────────────────────────────────────────────────────────────────────┘└─────────────────────────────────────────────────────────────────────────┘└────────────────────────────────────────────────────────────┘

As you can see above, you can get quite a lot of information from a connecting client (even before authentication) – OS, client version, serial number, connection channel, etc. is all there. And to answer the question from the last section: you can also get the fingerprint of the TLS certificate used during initial handshake.

To view other sessions, just use arrow keys or j/k to navigate up and down.

Miscellaneous

For a list of bug fixes and other changes, head over to the release notes.

Stay up-to-date and discuss

If you want get a notification for new releases or discuss things about the proxy, feel free to join our new mailing list.

We don’t have any pricing yet. So you can still freely download new versions of FMProxy from our server with the only restriction that they expire 60 days after release.

FMProxy – A Security Proxy for FileMaker Server

Sat, 30 May 2026 00:00:00 +0000

TL;DR Alex Dubov and I just released the first public version of FMProxy, a security proxy for FileMaker Server. We are currently looking for beta testers. Want to try it out? Get your copy for Ubuntu Server x86_64 or arm_64. Make sure to read the trial docs (pdf).

Introduction and Research background

In the last few years, Alex Dubov and I have independently been researching the security of the FileMaker platform.

We both reported bugs directly to Claris and via the Apple Bug Bounty program.

While these reports led to fixes/improvements in the product, the full timeline – from discovery through reporting, validation, release, and eventual installation on customer servers – was often stretched over many months.

Early last year, during the discovery of more security-relevant issues, we teamed up to see if we can not only do the security research but also directly work on a solution ourselves.

The idea was to build a tool that would continuously analyze traffic to detect current threats, even before official patches for certain vulnerabilities were being provided. And on top of that, give administrators more visibility into connecting clients and their configurations/fingerprints.

At the Vienna Calling conference in June 2025 (yes, nearly a year ago – things take a while ;-)), we demonstrated a few newly discovered vulnerabilities in the latest version of FileMaker Server (denial of service, session hijacking and privilege escalation) and showed a preview of the proxy server we developed, which could detect – and in some cases prevent – exploitation of known and yet to be discovered vulnerabilities.

At the time, it was just a proof-of-concept on our local machines. We used the time since then to develop the proxy server to a point where it can now be easily installed and reliably run next to FileMaker Server on Ubuntu Linux.

To understand what the proxy inspects, it helps to first look at how clients talk to the server.

How do FileMaker clients communicate and what does the proxy look at?

FileMaker Pro and Go communicate with FileMaker Server using CORBA’s GIOP (General Inter-ORB Protocol), usually wrapped in TLS.

Let’s check briefly how the communication over this protocol works.

Looking at a traffic capture of FileMaker Pro/Go to FileMaker Server, we can see that GIOP packets contain a header specifying the message type (such as Request or Reply), and a body with several data fields in accordance with that type. These fields carry, for example, the request id, operation and of course the actual payload data.

The majority of packets you will see when observing FileMaker traffic are of the type Request and Reply, with the requests predominantly using the Perform operation.

A simple example:

A FileMaker Pro client wants to retrieve account information (or record data or any other data) for a certain database hosted on a FileMaker Server. To request this data, it sends a GIOP packet with the Request message type, Perform operation, and some payload in a proprietary format to the server.

This (unfortunately not publicly documented) payload contains, amongst other data, a session ID (also see Alex’s authentication bypass article), a command instructing the server to return specific data, and a location described as a hierarchical path to a data structure in the hosted database file (in this example a location where account information is stored). This path structure is the same as you would find in an fmp12 file (see my analysis of the format here).

Example:

12 00 00 00 = Request ID 18
50 65 72 66 6f 72 6d = Perform (0x50 = ascii “P”, 0x65 = ascii “e”, …)
Get data at path: 0x17, 0x01, 0x05, 0x02 (where 0x02 is the account ID)

The server will then answer (assuming the request was valid and the client authenticated) with a Reply packet containing the data at the requested path. In the case of a user account this data contains fields for name, privilege set, etc. and can be parsed as described in the fmp12 file format post linked above.

Example:

12 00 00 00 = Request ID 18 (matches this reply to the request)
00 00 00 00 = Status -> No Exception
d0 00 00 00 = Length of message (208 bytes)
80 06 04 10 = NOP, 06 = code for key-value type, key 04, length 0x10 (16), some value
06 10 05 1b 3e 37 33 34 = type 06, key 0x10 (16), length 5, value = admin ^ 0x5a

What can we do with this knowledge and where does FMProxy fit in?

The idea behind FMProxy is that all this data flowing between server and clients is continuously analyzed to give you more information about who is connecting to your server with what kind of client setup (e.g. version, serial number, operating system), and to alert you if there are unusual/suspicious patterns appearing in the network traffic.

FMProxy runs on the same host as FileMaker Server and listens on the default port which FileMaker clients connect to (5003/tcp). To avoid conflicts, the FileMaker Server installation is modified to listen on another port.

Once a client connects to the proxy server, the proxy does two things:

A quick scan of the packet contents to decide if there is any critical issue which should lead to a termination of the connection (a known DoS payload should never reach the FileMaker Server)
If no severe issue is detected in the fast scan, we pass the packet contents to a separate task for deeper analysis while at the same time forwarding it to the target FileMaker Server.

Step 2 is implemented in this way such that it doesn’t couple the analysis overhead with the forwarding of the packet to FileMaker Server, to keep the latency penalty low.

Should the deeper analysis detect any issues (this is mostly unrelated to specific vulnerabilities, but rather a scan for unusual patterns such as a non-“Full Access” account accessing data it shouldn’t have access to), then these cases are logged to a file for further investigation by the server administrator. The logs would typically be forwarded to a central log server with alerting rules.

FMProxy generally tries to only do a minimum set of actions before forwarding data to FileMaker Server and the clients to not cause any interference with regular client-server communications (after all it’s a proprietary protocol and we want to keep traffic unchanged if at all possible). In very few cases we do have to rewrite parts of a packet to make the whole proxy setup feasible.

What can FMProxy actually detect?

Besides access logging, FMProxy currently has detection capabilities that log the following security events. The majority of them don’t focus on specific vulnerabilities, but rather on detecting patterns indicating authorization issues that could be a result of all kinds of vulnerabilities (known or not yet known).

Event ID	Description
SEC-0001	Detection of a request with an unknown session ID. Repeated events of this kind could be an indication of session ID brute-forcing. Session IDs are given out by the server when a client connects (before authentication). If a session ID for an already authenticated client is “guessed” by brute-force, it can allow an attacker to hijack that session and perform actions on behalf of the authenticated client.
SEC-0002	Detection of a client downloading or attempting to download data from a database which is not part of the session used to initiate the download (i.e. no authentication was performed for this database during this session).
SEC-0003	Detection of a client downloading or attempting to download a list of all scripts with an unauthenticated account.
SEC-0004	Detection of a client downloading or attempting to download a list of all scripts with a non-“Full Access” account. This is benign if the authenticated account is not a Full Access account but has the permissions to modify scripts.
SEC-0005	Detection of a client downloading or attempting to download data from a specific database without the corresponding account being authenticated.
SEC-0006	Detection of a client accessing account information for an account other than self while the proxy has insufficient information about the privilege set / permissions of the authenticated account. With data going over the wire the proxy builds a representation of the privileges for different accounts. When a request is made to download data for another account, this representation is in most cases sufficient to judge if it’s a legit request or not. This event will be raised if the information is incomplete to judge the legitimacy of the request.
SEC-0007	Detection of a client accessing account information for an account other than self while being authenticated but not having Full Access privileges. This message is benign if a non-Full Access account is configured with permissions to manage other accounts.
SEC-0008	Detection of a client connecting with a persistent ID which is not present in the list of trusted clients. This event can only appear if the proxy was started with a list of trusted clients.
SEC-0009	Detection of a client connecting with an invalid persistent ID. This could be an indicator of an attacker using a crafted payload using a custom tool. FileMaker clients will always connect with a valid ID.
SEC-0010	Detection of a failed login. This event is always logged when a login fails (e.g. wrong account name / password combination). When automatic logins are configured, you might see this event appearing before a login prompt is shown to a user.
SEC-0011	Detection of known payloads that will crash FileMaker server (denial of service) due to memory issues.
SEC-0012	Detection of successful login.
SEC-0013	Detection of non-FileMaker traffic on the listening port. This event will occur more frequently on public servers which experience probing traffic (bots trying to check for open ports and analyze what software is running).

Want to get your hands on the first version?

If you would like to try out FMProxy in your own lab setup, you can get your copy for Ubuntu Server x86_64 or arm_64. If you would rather test on macOS or Windows, let us know – we have working versions but not a fully automated setup yet. For more information and installation and configuration instructions, please refer to the trial docs (pdf).

The current builds expire every 60 days, so if you would like to follow the progress, just send us an email and we keep you in the loop for new versions and later potential commercial options.