Learn Bacula - Daemon Security & Auth

#Introduction

In episode 11, media was up and running. Now we talk about something often ignored until an incident happens: daemon security. Bacula is a system that reads all your server files and stores them on media — if the daemons aren't secured, you've just built a leaky pipe for your most sensitive data.

Fortunately, Bacula has a simple yet strong authentication model: shared passwords per daemon pair. The problem isn't the model — it's the discipline of applying it. Episode 12 covers how to set passwords correctly, understand ports, and design a firewall policy.

#Bacula's Authentication Model

#Three Password Pairs

Bacula uses shared-secret authentication between two components. There are three pairs that must match:

Note the third pair: when the FD sends data to the SD, the Director introduces them, using the same password stored in the Client resource and in the SD.

Director {
  Name = bacula-dir
  Password = "rahasia-sd"
}

Storage {
  Name = FileStorage
  Address = 127.0.0.1
  SDPort = 9102
  Password = "rahasia-sd"
  Device = FileStorage
  MediaType = File
}

#Never Use Defaults

Package installations often ship example configs with passwords like password or secret. Replacing them with strong values is the mandatory first step:

openssl rand -base64 24

Each daemon must have a different password. One Director password shared across all FDs means one leak = every client is open. Use at least a unique password per client (episode 14).

#Ports and Firewall

#Default Ports

bacula-dir  -> TCP 9101
bacula-sd   -> TCP 9102
bacula-fd   -> TCP 9103

All ports can be changed via the DirPort, SDPort, FDPort directives. Changing default ports is one extra security layer (obscurity) — minor effect, but harmless in environments that allow it.

#Firewall Policy

The principle: only open the ports truly needed, only from the right sources. An example with ufw:

sudo ufw allow from 10.0.0.0/24 to any port 9102 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 9103 proto tcp

Rules of thumb:

• FD (9103) should only be reachable by the Director and SD from an internal subnet — an FD client doesn't need to accept connections from the internet.
• SD (9102) should only be reachable by the Director and FD clients — not every host on the network.
• Director (9101) should only be reachable by bconsole/admins — never expose it to the public.

ss -tlnp | grep -E "9101|9102|9103"

#TLS: The Next Level of Security

Password authentication protects who connects, but not the content of the conversation. Without TLS, backup data crosses the network as plaintext — anyone who can sniff traffic can read the backup contents. TLS encrypts all Director↔SD, Director↔FD, and FD↔SD communication.

Bacula supports native TLS on all three daemons, with either self-signed certificates or an internal CA. Full configuration and steps are the main topic of episode 13.

Director {
  ...
  TLS Enable = yes
  TLS CA Certificate File = /etc/bacula/certs/ca.pem
  TLS Certificate = /etc/bacula/certs/director.pem
  TLS Key = /etc/bacula/certs/director.key
}

For now, remember the hierarchy: authentication first (passwords), then integrity (TLS), then surface minimization (firewall/VLAN).

#A Simple Audit

grep -rn "Password" /etc/bacula/ | grep -v "#"
ss -tlnp | grep -E "9101|9102|9103"
ls -l /etc/bacula/

These three checks reveal: what passwords are installed (and whether any are still default), which ports are open, and who can read the configuration. Do this after every installation change.

#Closing

Key takeaways:

• There are three password pairs: director-sd, director-fd, fd-sd — all must be unique and strong.
• Never use default passwords from example configs.
• Ports: 9101 Director, 9102 Storage, 9103 File — open only from the sources needed.
• Firewalls + VLAN minimize the attack surface.
• TLS is the next layer to protect conversation content — the topic of episode 13.

In the next episode, episode 13, we'll enable TLS and secure the network — certificates for the Director, SD, and FD, TLS configuration in all three files, restricting daemon access via firewall and VLAN, data encryption (Enterprise) or stunnel pipeline, and checksum integrity. This is the full security act of Bacula.