omame
commented
6 years ago How about this approach? Kinda like the way Saltstack handles the minions registration.
- There is no need to preseed the nodes in the server config.
- The human confirmation can happen through the admin channel or pm to the admins.
- A message will be sent if something unusual happens that triggers a new registration. This will catch the attention of the admins.
Additionally, I propose to accept a set of pre-shared keys, not just one. This can have two advantages:
- Key rotation becomes trivial.
- Different classes of agents can use different keys. This can act as a bulkhead in case of a successful attack.
pcarranza
When thinking about securing the remote execution some thoughts are:
Unique Remote ID Tagging Remote Meeseeks are identified by a unique UUID that must match the established UUID in the Meeseeks "master" configuration. This is needed for a Remote Meesseeks to register with the Master Meeseeks.
Cert Based Authentication of Command When registering a Remote Meeseeks with the Master Meeseeks this should take place over a TLS API call session with a registration endpoint, to start the registration the UUID must match the UUID that has been configured in the Meeseeks Master. Upon a match of UUID for registration the Master Meeseeks should generate a cert for the Remote Meeseeks that is signed by the Master Meeseeks. Once this is established the Remote Meeseeks will not execute jobs unless they have been signed by the Master Meeseeks.
Time Based Validation (to prevent replay attacks) In the metadata of the command submission the Master Meeseeks should submit a timestamp that is generated at command invocation time. The Remote Meeseeks should check the timestamp against its system time and refuse the execution of the command if the skew is greater than an acceptable threshold. This threshold should have a default time of 60s