Learn Keepalived - Security & Authentication

#Introduction

VRRP was born in an era when networks were considered trusted, but the world is different now. Episode 9 covers Keepalived's security side: how VRRP advertisements are secured, what happened to auth_type PASS in Keepalived 2.2, how to manage shared secrets, and how to protect scripts and services from misuse.

Security here is not just a checklist. A single fake advertisement with a high priority can steal the VIP and route all traffic through an attacker's node. By understanding the authentication mechanisms and network isolation, you can build HA that is hard to hijack.

#VRRP Authentication Options

#The Fate of auth_type PASS in Keepalived 2.2

auth_type PASS used to be the most common way to secure VRRP with a plain-text password. But the VRRP standard considers this method weak, and support for it was removed as of Keepalived 2.2.0. If you use an older version and upgrade, the auth_type PASS block will make the configuration fail. Your remaining options are auth_type AH or dropping authentication entirely.

Always check your version first before deciding on a strategy:

keepalived --version

Versions 2.2.x and 2.3.x already reject auth_type PASS. Your authentication decision must match the version running on all nodes.

#auth_type AH

To keep using a shared secret on VRRPv2, use AH:

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  authentication {
    auth_type AH
    auth_pass K3puRi3n-HA-2026
  }
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

The auth_type AH block uses AH to authenticate and verify the integrity of VRRP packets. Make sure auth_pass is identical on all nodes; a single different character will make advertisements get rejected and the nodes will never form a virtual router.

#No Authentication and Network Isolation

If you run Keepalived 2.2 or newer and don't want to deal with AH, the most common option in modern production is to remove the authentication block and replace it with strict network isolation: a dedicated VLAN for VRRP, a firewall that only allows VRRP between nodes, and no access from untrusted segments. Security shifts from cryptography to network control.

#Shared Secret Management

#Configuration File Permissions

keepalived.conf contains the shared secret and script paths. Give it the strictest permissions:

sudo chown root:root /etc/keepalived/keepalived.conf
sudo chmod 600 /etc/keepalived/keepalived.conf

The chmod 600 /etc/keepalived/keepalived.conf command makes the file readable and writable only by root. The Keepalived daemon runs as root, so it can still read the configuration.

#Secret Rotation and Audit

Treat auth_pass like any other credential: rotate it when a team member leaves, when a node is decommissioned, or periodically. Store the secret in a vault or password manager, not in documentation anyone can read. Rotation also requires time synchronization between nodes so AH doesn't reject advertisements due to clock skew.

#Securing Scripts and Service Access

#Secure Scripts

vrrp_script and notify scripts run with elevated privileges. Avoid dangerous practices:

• Don't put hardcoded credentials in scripts.
• Validate all arguments before using them.
• Never follow symlinks that an attacker could redirect.

An example script that validates its arguments:

#!/usr/bin/env bash
STATE="${1:-}"
case "$STATE" in
  MASTER|BACKUP|FAULT) ;;
  *) echo "argumen tidak valid" >&2; exit 1 ;;
esac
echo "$(date -Is) keepalived -> $STATE" >> /var/log/keepalived-notify.log

The case pattern on $STATE rejects any input outside the three valid values before the script does anything.

#Restricting Service Access

Make sure only the processes that should can control the service:

sudo ss -tlnp | grep keepalived
ps aux | grep keepalived

The ss -tlnp | grep keepalived output shows the ports the daemon has opened, and ps aux | grep keepalived shows the processes and their owners. Stop the service on nodes you're not using and restrict root access on the machines.

#Best Practices for Safe HA Operations

A summary of practices that make your HA hard to attack:

• Put VRRP on a dedicated VLAN separate from client traffic.
• Block incoming VRRP multicast on interfaces that shouldn't receive it.
• Use mcast_src_ip or unicast VRRP (unicast_peer) when the network can't support multicast safely.
• Restrict ssh to Keepalived nodes to a jump host only.
• Monitor suspicious priority changes in the logs.

An example of unicast VRRP on the BACKUP node:

vrrp_instance VI_1 {
  state BACKUP
  interface eth0
  virtual_router_id 51
  priority 90
  unicast_peer {
    192.168.1.11
  }
  virtual_ipaddress {
    192.168.1.100/24 dev eth0
  }
}

The unicast_peer block replaces multicast with point-to-point communication to 192.168.1.11 (the MASTER node). This pattern shrinks the attack surface because advertisements are only sent to a single known destination.

#Closing

Episode 9 closes the security gaps most often overlooked: VRRP authentication, shared secret management, script security, and service access restriction. You now know that in Keepalived 2.2, auth_type PASS no longer exists and security relies on AH or network isolation.

Key takeaways:

• auth_type PASS was removed since Keepalived 2.2.0.
• auth_type AH requires an auth_pass identical on all nodes.
• Without authentication, replace it with a dedicated VLAN and firewall.
• chmod 600 on keepalived.conf that contains secrets.
• Validate arguments in all notify and health check scripts.
• Unicast VRRP shrinks the multicast attack surface.

In episode 10 next, we cover IPv6 and multi-network topologies — VRRPv3 support for IPv6, dual-stack configuration, Keepalived across many subnets and VLANs, and routing integration for more complex network layouts.