Regarding the replay attack messages, was Re:
[Linux-HA]FAQ on replay attack
gshi at ncsa.uiuc.edu
Wed Mar 2 15:25:36 MST 2005
At 03:11 PM 3/2/2005 -0700, you wrote:
>On Tue, 2005-03-01 at 16:47, Guochun Shi wrote:
>> At 04:34 PM 3/1/2005 -0700, you wrote:
>> >Thanks for posting that Guochun. (See below for the FAQ entry.)
>> >I have a question regarding this which I hope I've not missed in some
>> >archived messages.
>> >I have some code on my system such that, when the node that currently
>> >holds the resources (active-node) detects the other node (passive-node)
>> >beginning to heartbeat, the active-node queries and possibly updates the
>> >software on the passive-node. This includes the OS version of the
>> >passive-node in which case it forces the passive-node to reboot. Other
>> >things which are potentially updated are the network settings and
>> >various software packages on the passive node.
>> >All of this is automated and I would really like to avoid having to
>> >restart heartbeat on the active-node if possible.
>> >Can you give me some idea of what exactly triggers the "replay attack"
>> >condition and how I might automate configuring my new passive-node so
>> >that I don't run into it?
>> The replay attack will be triggered if the generation number in /var/lib/heartbeat/hb_generation
>> is smaller than the last run-- which the active node knows. Reinstalling a machine from scratch will
>> result in replay attack since hb_generation will reset to 1. Make sure you don't remove or
>> overwrite hb_generation, you will be fine.
>Thanks again for the response, Guochun. One final question and I think
>I know what I will have to do. Does one of the hb_api callbacks provide
>either a way to get the generation expected for the other node or an
>indication that the other node failed the generation test and what its
>generation should have been?
There is no api for that now. The correct generation number is indicated in error message:
> >> Mar 16 19:31:43 silas heartbeat: ERROR: should_drop_message:
> >> attempted replay attack [paul]?
> >> [gen = 1, curgen = 10]
it should be curgen+1 or more
>If I could get the latter I can have the existing node try to force a
>generation change on the new node. If the new node doesn't accept this
>change then I have bigger problems anyway.
The new node will accept that.
You can stop heartbeat, modify the hb_generation file and start heartbeat. It should work fine
>> >Thanks greatly,
>> >On Tue, 2005-03-01 at 15:25, Guochun Shi wrote:
>> >> here it is:
>> >> I reinstalled a machine, and now I'm getting "attempted replay attack"
>> >> messages
>> >> We just reinstalled our master node (paul) and heartbeat (1.2.0) is
>> >> saying this on the slave node (silas - which has the resources):
>> >> Mar 16 19:31:43 silas heartbeat: ERROR: should_drop_message:
>> >> attempted replay attack [paul]?
>> >> [gen = 1, curgen = 10]
>> >> Mar 16 19:32:15 silas last message repeated 38 times
>> >> Mar 16 19:33:17 silas last message repeated 62 times
>> >> What should we do to get the resources back on the master node ?
>> >> Put 11 (curgen+1) in /var/lib/heartbeat/hb_generation on paul - from
>> >> this log it should have a 1 (gen) in there now.
>> >> Basically, it should be one larger than the curgen number from the
>> >> message above.
>> >> Then if you restart heartbeat on the master node (paul), all should be
>> >> well. This is the result of a feature called ReplayAttackProtection.
>> >> You can also just restart heartbeat on both nodes, if you prefer.
>> >> So, if you put any number larger than curgen into the hb_generation
>> >> file on paul, on the machine you reinstalled, and restart, heartbeat
>> >> will be happy.
>> >> -Guochun
>> >> At 02:17 PM 3/1/2005 -0700, you wrote:
>> >> > There are references in some old emails regarding the "replay
>> >> > attack"
>> >> > messages the comments on this in the FAQ. Unfortunately, the link
>> >> > for
>> >> > the FAQ in those emails (wiki.trick.ca) doesn't work. Is there a
>> >> > new
>> >> > link?
>> >> >
>> >> > Thanks
>> >> >
>> >> > Scott
>> >Linux-HA mailing list
>> >Linux-HA at lists.linux-ha.org
>> Linux-HA mailing list
>> Linux-HA at lists.linux-ha.org
>Linux-HA mailing list
>Linux-HA at lists.linux-ha.org
More information about the Linux-HA