Regarding the replay attack messages, was Re: [Linux-HA]FAQ on replay attack

[Guochun Shi]

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.
>> 
>> -Guochun
>
>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[12561]: 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

-Guochun

>Scott
>
>> >Thanks greatly,
>> >
>> >Scott
>> >
>> >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[12561]: 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
>> >http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> 
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA at lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>
>_______________________________________________
>Linux-HA mailing list
>Linux-HA at lists.linux-ha.org
>http://lists.linux-ha.org/mailman/listinfo/linux-ha