On 9/13/10 7:49 AM, "Max Arnold" <lwa...@gmail.com> wrote:
> On Mon, Sep 13, 2010 at 05:58:51PM +0400, Seva Gluschenko wrote:
>> Well, from my point of view, you have to add policy server's public
>> key to ppkeys/ on clients and to accept on trust certain ranges of IP
>> addresses reserved for clients. This way clients will trust the server
>> according to the pre-loaded key, and server will trust clients. The
>> trick is, you'll need to purge clients's keys from server's ppkeys/
>> directory to prevent authorization failures because of keys mess. The
>> threat is, an attacker could try controlling clients using the trusted
>> IP range, so you should avoid distribution of trustkeysfrom
>> configuration to clients.
>
> This is sad... Tracking random ISP address pools is a painful and
> error-prone task. I want either unique client id/password or signed
> SSL certificate with my own CA in order to authenticate clients and
> control their access to policy server without relying on IP/DNS data.
>
> Anyway, thank you for clarification.
I wonder if cert-based capabilities will be in nova?
A hacker that "controls" clients can not post anything back to the policy
server(s)... So the threat is somewhat mitigated, and hopefully your
IDS/IPS is firing.
That said, I don't believe anything is stopping you (just like with cfengine
2.x) from disabling the security features you don't like and implementing
them yourself. Stunnel is one approach I've heard discussed.
--
Mike Hoskins : micho...@cisco.com : +1 (415) 506-UNIX (8649)
He knows not how to know who knows not also how to unknow.
-- Sir Richard Burton
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
