Hi, 14.09.2007 22:53,, Mike Mestnik wrote:: > 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.
It will probably take more than the two of us, even... my comments were not meant to be the complete list of options. Rather, they only reflected what I do, but obviously my need for security is different to yours. >>> 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. Ok, this assumes some things - a highly insecure network (rather realistic, I fear...) and no firewalling or tcp wrappers preventing connections from unauthorized hosts to your FD. In fact, I'd also say that your assumed initial security problem - the CGI+sym-link attack - would probably allow an intruder to access the password file directly. > 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. Note that I assume you've got the basic CA infrastructure set up already. A valid assumption in a security concerned environment, IMO. > 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. Quite true, but see above. Also, using, for example, some script around ssl, it would be rather simple to create a new certificate, a signing request, have it signed, and packed with the needed (intermediate) certificates for transer and installation. Of course this is not something you can learn to do in half an hour, but your netcat-through-ssh approach also needs some experience. > 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! Also beyond the scope of most users ;-) >>> 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." But it's harder to revoke access for the compromised system. From a security standpoint, it's not wise to use the same key from multiple systems. > 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? You see? Quite a number of connections to manage :-) >>> 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. The above items can be done in different ways - using a script it's possible to only have to issue one single command. Myself, I typically use TinyCA, so for me this is some mouse-pushing and, of course, some typing for all the data you need for x509-certificates. But IMO, this information makes managing the certificates later easier. For a ssh infrastructure, you have to document which key pairs are used for which connection, and who received or supplied which keys somewhere, too. > 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. Apart from the graphical TinyCA, there are some minimal CA implementations available. For example, OpenVPN has something called easy-rsa, and for OpenSwan there is valuable information available. 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
