My Firebird database is accessible with default credentials (SYSDBA/masterkey). What should I do?
Firebird’s classic weak spot is the built-in administrator account SYSDBA with its default password masterkey (only the first 8 characters even count). If your server is reachable on port 3050 with that unchanged, anyone can connect as full admin and take your entire database. Here’s how to lock it down.
First: don’t panic — change the SYSDBA password and firewall 3050.
SYSDBA/masterkey is the first credential any scanner tries against Firebird. Block the port and change that password immediately, then assume the database may have been read and act on it.
// the 60-second version
- Firewall port 3050 and bind Firebird to localhost/private.
- Change the
SYSDBApassword — the defaultmasterkeyis public knowledge. - Rotate secrets stored in the data and check for tampering.
- Review logs/connections; restore from backup if data was altered.
01Understand what’s at risk
SYSDBA is Firebird’s superuser; with the default password on a reachable server, an attacker has total control:
- Full read access to every table in every database on the server.
- Modify or destroy data — alter records, drop tables, or hold the database to ransom.
- Server-wide reach — SYSDBA isn’t scoped to one database; it administers them all.
- Secrets in the data — credentials, keys and PII stored in tables are now exposed.
The default masterkey password is documented everywhere, and historically only the first 8 characters were significant. Treat an internet-reachable Firebird with default creds as already accessed, and assume its contents were read.
02Stop the bleeding — firewall and change SYSDBA
ufw deny 3050
Change the SYSDBA password right away:
gsec -user SYSDBA -password masterkey
GSEC> modify SYSDBA -pw <strong-new-secret>
Bind Firebird to localhost or a private interface and reach it from your app host / VPN only.
03Rotate & tighten accounts
- Change SYSDBA to a strong password (use more than 8 meaningful characters on modern Firebird).
- Create least-privilege application users instead of letting apps use SYSDBA.
- Rotate the app’s database credentials wherever they’re configured.
- Rotate any secrets stored inside the database, since the data may have been read.
04Read the logs — who connected?
Check Firebird’s log and your firewall logs for connections from unfamiliar IPs around the exposure window:
grep -iE "connect|login|error" /var/log/firebird/firebird.log
- Connections from unknown hosts — assume the database was read.
- Look for unexpected schema or data changes that indicate tampering.
05Recover if needed
- If data was altered, restore from a known-good backup (
gbak) to a secured instance. - Keep the tampered copy for analysis first.
If the data included personal information, this may trigger breach-notification duties (GDPR and similar). Involve legal/compliance.
06Make sure it can’t happen again
- Never expose the database to the internet — localhost/private + VPN.
- Change all default credentials (SYSDBA and any others) on install.
- Least-privilege app users; encrypt and back up, and test restores.
- Keep Firebird patched and monitor for connections from new IPs.
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.