This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag

Homepage

About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2017-12-12 22:06:45

Replay Attack Protection

Heartbeat signs all communications with digital signatures in order to properly authenticate communications as coming from a cluster member. This means that in order to create a new packet, an potential attacker has to know the signing key for cluster communications.

Replay attack protection a security feature which protects cluster communications from what is called a "replay attack". Although all heartbeat packets are cryptographically signed, if an attacker can sniff a packet and play it back later, then they might be able to cause heartbeat to do something it shouldn't do, even without knowing the signature key. So, this feature keeps attackers from being able to do that by small changes to the protocol.

Most protocols have sequence numbers on each packet. And, each time a communication is started the sequence numbers restart from the beginning - so with only sequence numbers, a protocol restart can't be distinguished from replayed packets from an attacker.

So, heartbeats sequence numbers also have a generation number associated them - which always goes up by one each time the protocol is restarted. This way heartbeat knows that the packets it's hearing have never been sent at some time in the past. This generation number has to be stored in non-volatile memory of some kind. Normally, they are stored in /var/lib/heartbeat/hb_generation.

Since the generation number is stored on disk, losing that file makes heartbeat think someone is replaying old packets (because the generation number goes down instead of up).

If you are on a type of machine which doesn't have readily available non-volatile memory (like on disk), see the hbgenmethod directive.

See Also

FAQ item (28) on attempted replay attack