Re: [Prelude Hybrid IDS] #172: registration-server daemon - flexability for large and distributed deployments

#172: registration-server daemon - flexability for large and distributed
deployments
----------------------------------------+-----------------------------------
 Reporter:  [email protected]       |        Owner:  yoann
     Type:  enhancement                 |       Status:  new  
 Priority:  normal                      |    Milestone:       
Component:  prelude-manager             |      Version:  0.9  
 Severity:  normal                      |   Resolution:       
 Keywords:  registration server daemon  |  
----------------------------------------+-----------------------------------
Old description:

> The concept of a sensor registration server that can proccess request,
> approval and activation. Not sure on how this would work with the current
> architecture (one-shot passwords?) but this type of break-off my be
> required for large deployments and distributed enviornments. Just like a
> PKI approach where a certificate request can be made per demand and
> approved by the administrator (RA).
>
> Thought of this while trying to think of a way to roll out a large number
> of sensors to devices and administrators across the globe. There is no
> way for me to be there for each activiation. Perhaps a type of (here
> comes the buzzword) configlet that can be given per need.
>
> Open to discussion. Let me know what you think.

New description:

 The concept of a sensor registration server that can process request,
 approval and activation. Not sure on how this would work with the current
 architecture (one-shot passwords?) but this type of break-off my be
 required for large deployments and distributed environments. Just like a
 PKI approach where a certificate request can be made per demand and
 approved by the administrator (RA).

 Thought of this while trying to think of a way to roll out a large number
 of sensors to devices and administrators across the globe. There is no way
 for me to be there for each activation. Perhaps a type of (here comes the
 buzzword) configlet that can be given per need.

 Open to discussion. Let me know what you think.

Comment (by yoann):

 It is true that making Prelude easier to deploy would benefit both end
 users (often having problem with X509 registration and profile), and
 professional making large Prelude deployment.

 We are currently investigating several solutions:

 One would be to make Prelude-Manager handle directly prelude-adduser
 registration request: you could setup a registration password and a
 registration deadline (date when Prelude-Manager won't accept registration
 request anymore) from the Prelude-Manager configuration file.

 Registration would be performed by using prelude-adduser on the sensor,
 with the unique registration password.


 A second, more ambitious solution, would be to change Prelude-Manager to
 allow unauthenticated connection for sensor to request registration.

 Prelude-Manager would queue registration requests, which would have to be
 reviewed and accepted/refused by an user through Prewikka or another
 command line interface.

 Once the registration for a client is accepted, Prelude-Manager would send
 the certificate back to this client, which would then reconnect using the
 new credentials.

 This approach make it very easy to process large deployment, by removing
 any registration needs on both agent and server. The only things the user
 got to do is to review/accept registration requests. However, it has to be
 designed carefully, to prevent possible DOS attempt made easy by
 unauthenticated connection.

-- 
Ticket URL: <https://trac.prelude-ids.org/ticket/172#comment:2>
Prelude Hybrid IDS <http://www.prelude-ids.org>
The Prelude Hybrid Intrusion Detection System suite
_______________________________________________
Prelude-devel site list
[email protected]
http://www.prelude-ids.org/mailman/listinfo/prelude-devel