Salutations,
On Fri, Sep 14, 2007 at 08:16:25PM +0200, Arno Lehmann wrote:
> Hi,
>
> 14.09.2007 18:09,, Mike Mestnik wrote::
> > On Thu, Sep 13, 2007 at 10:57:27PM +0200, Arno Lehmann wrote:
> ...
> >> Interesting setup... I assume this is to provide some sort of secure
> >> communication, similar to what (earlier, for Bacula) was done using
> >> stunnel or could be achieved both by using encrypted communications in
> >> Bacula, or by setting up a VPN...
> >>
> > It's more like a VPN, but it can ONLY be used to "run nc". A server
> > side proxy is used to add greater security.
>
> Well, if you need an approach like this... actually, I would do this
> differently, but that might be a matter of taste. See below.
>
There are pros and cons to each, it may take both of us to list these
accurately.
> > Bacula currently has the following vulnerability.
> > 1. A "shared" secret. The above method uses pub/priv keys.
>
> As the shared secret only allow one pre-defined communication channel,
> I don't see a big problem here. I.e., when, on a client machine, you
> see the secret the DIR uses to contact the FD, you can not access the
> DIR (or any other part of Bacula) using that secret.
>
One BIG problem, use in privilege escalation attacks.
Let's say a CGI script can be used with a sym-link attack to "read"
files as root. So you read the FD config file, then connect as a
director and backup/restore the password file.
RO access just became RW/Execute.
> > 2. Certificates used for SSL? Do you buy them or use self signed?
>
> Whatever you like... For these purposes - well-defined usage, and the
> clients need to be set up for this particular server anyway - I think
> self-signed certificates are absolutely ok. Of course, if you already
> run a PKI, it would keep things more manageable if you put your
> Bacula-related certificates into the regular trust tree.
>
> > 2a. Setting up a CA and adding that to the root CAs on the DIR side?
> > This would be more difficult and error prone, ssh automates
> > most of this. <With the "Is this the correct fingerprint?">
>
> That, I think, depends. I found that, once you got used to it, using a
> well-defined CA setup is neither more difficult nor more error than
> managing a large number of ssh key pairs. For a very limited number of
> connections, ssh might be easier, though.
>
There are two parts for SSH, there are 3 or more for SSL.
Per connection/service/host/ect
1. Private key, both
2. Puplic key, both
Server cert/CA cert (Daemon's public key), both
3. Certificate, SSL
Certificate request, SSL
The initial setup is greater with SSL and can be a big headache,
especially for ?most? users.
CA private key needs some commands to setup and use, SSL
Server cert will be created by most OSes, ssh
CA public key will need to be copied by hand, SSL
Server public key *copied by any ssh client, ssh
* I do recommend moving this key into the system /etc/ssh folder from
the ~/.ssh user folder. The point is that an ssh client will do the
transfer from server to client for you. There is also a possibility
to use DNS to publish these keys!
> > In this method the client and server "are authenticated" using *cheaper*
> > methods, perhaps just as secure.
>
> Well, if the methods are cheaper really depends on if you already know
> how to operate a CA - plain ssh is simple to set up, but once you have
> more than a handful of connections with multiple identities on each
> end, you are in an administrative nighmare, IMO.
>
Yes, to prevent this I plan to copy the same *private* key onto each
computer that needs it. "If I gen a private key for each system then
at best I will know from what server the key leaked, but there should
be no greater or less access."
Each SD gets a single public key for it's DIR and FDs.
The DIR and FDs get a known_hosts public key for each SD.
The FDs get a public key for it's DIR, not the same for the SD.
The DIR needs to use DNS for it's FDs known_hosts, but using a
sym-link to map a users known_hosts to the system may work.
127.X.X.X addresses can be used to not pollute the port space.
...n1 connect to the Director?
> > I also add points for being easier
> > to setup, like not having to deal with signatures, only the keys need
> > to be setup.
>
> A key is not that much different from a certificate - you create it,
> you move it into place, and you point your software to it.
>
Your missing some steps, I know you know what they are.
Gen a private key, get a public key too.
Create certificate request.
Sign certificate request, get a certificate.
Add private key and certificate.
Move these into place.
Unlike SSH with this method there is no need to put a large list of
"known_hosts" on the director. There is still a lot of work per FD!
Yes, this is a matter of taste. Both methods are vary close.
> Anyway, I understand what you do now, and I think that others might
> find this interesting. How about if you wrote a small article for
> wiki.bacula.org?
>
Perhaps, if I get my facts about SSL and the pros and cons worked out.
> Arno
>
> --
> Arno Lehmann
> IT-Service Lehmann
> www.its-lehmann.de
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
--
/****************************************************************
* Mike Mestnik: Junior Admin 612-395-8932 *
* [EMAIL PROTECTED] VISI Inc. *
****************************************************************/
Alt address: [EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
