Menu
▾
▴
[Bacula-bugs] [bacula 0000534]: bacula-fd with built in tcp wrapper accepts tcp connections from anywhere
|
From: <bac...@li...> - 2006-02-06 12:03:57
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000534 ====================================================================== Reported By: david Assigned To: kern ====================================================================== Project: bacula Bug ID: 534 Category: File Daemon Reproducibility: always Severity: feature Priority: normal Status: assigned ====================================================================== Date Submitted: 01-25-2006 10:53 PST Last Modified: 02-06-2006 04:03 PST ====================================================================== Summary: bacula-fd with built in tcp wrapper accepts tcp connections from anywhere Description: compiled/installed bacula-fd version 1.38.5 on recent debian linux pc with --with-tcp-wrappers option given to ./configure. /etc/services has bacula-fd port 9102 tcp listed. /etc/hosts.deny has entry bacula-fd: ALL to block access from all hosts. /etc/hosts.allow has no entry that matches bacula-fd. FileDaemon is started by /etc/init.d/bacula start. Daemon now accepts connections from backup server. The Manual at http://www.bacula.org/rel-manual/Bacula_Security_Issues.html reads: "TCP Wrappers are implemented if you turn them on when configuring (./configure --with-libwrap). With this code enabled, you may control who may access your daemons. This control is done by modifying the file: /etc/hosts.allow. You must not use the twist option in your /etc/hosts.allow or it will terminate the Bacula daemon when a connection is refused." The option "--with-libwrap" mentioned in the manual does not work and results in no TCP Wrappers support. Correct option '--with-tcp-wrappers' was used to configure/compile instead, configure tells me 'TCP Wrappers support: yes -lwrap' Obviously I cannot fully control connections to the bacula-fd. I am not sure what "The program name that Bacula uses when applying these access restrictions is the name you specify in the daemon configuration file." means. Maybe there has to be an entry in bacula-fd.conf for the feature to work? I could not find an entry associated with tcp-wrappers in the manual for bacula-fd. (Note that above instructions are incomplete, it only tells you to configure hosts.allow, not adding bacula to hosts.deny will probably result in unrestricted access, unless a more general entry in hosts.deny matches bacula-fd!) I did not use the "twist-option". This might compromise security of sites relying on tcp-wrappers for security. ====================================================================== ---------------------------------------------------------------------- Dan Langille - 01-25-2006 11:02 PST ---------------------------------------------------------------------- yes, --with-tcp-wrappers is the correct usage. re /etc/hosts.allow: most modern implementations of tpcwrappers allows you to specify both ALLOW and DENY instructions within /etc/hosts.allow. We do expect people to do a bit of reading here, especially when it concerns their chosen OS. As for the name, I think it depends on the incoming connection. For example, if your FD will be contacted by the Director named bacula-dir, you want this: bacula-dir : bast.example.org : allow ---------------------------------------------------------------------- kelvin - 02-05-2006 08:56 PST ---------------------------------------------------------------------- I have compiled the bacula-fd with TCP wrappers on RedHat and Fedora systems and it works fine. The name to use in hosts.allow and hosts.deny is _not_ bacula-fd but whatever is listed as the name in the FileDaemon section of bacula-fd.conf . ---------------------------------------------------------------------- david - 02-06-2006 04:03 PST ---------------------------------------------------------------------- AFAIK in /etc/hosts.allow the first field refers to the service used, as stated in /etc/services. If bacula-dir is specified, the statement refers to incoming connections to the director daemon (TCP port 9101). Such a statement only makes sense on the backup server, as the bacula-dir is only running there. A typical client machine will only run bacula-fd (TCP port 9102) and only entries for that service (named "bacula-fd" in /etc/services) should be neccessary on any client. Entries for other specific services should not affect bacula-fd. The Example given by Mr. Langille will allow the host with DNS-name bast.example.org to connect to the local director (or to whatever service /etc/service associates with bacula-dir). This does not yet restrict any incoming connection. On my system, default is for all incoming connections to be allowed, unless they are denied. If Mr. Langille does not have a _restriction_ for bacula-dir (or for a group of services including it, such as "ALL") in /etc/hosts.deny, the system will most likely per default allow any connection regardless of the entry. I do not think that this approach helps restricting incoming connections to the _file _daemon_ on the client, anyway. The name bacula-dir in hosts.allow is _not_ a hostname but the name of a service. My problem was not to allow incoming connections, but to block them. As written in the original note, _any_ connection was accepted, even if _all_ incoming connections should have been blocked. If I add the following line to my inetd.conf : "bacula-fd stream tcp nowait root /sbin/tcpd /sbin/bacula-fd -i -u root -g root -v -c /etc/bacula/bacula-fd.conf" and restart inetd, the file daemon gets started via inetd and everything works as it should. Only if I rely on the builtin libwrap it does not. Mr. kelvin, I can compile bacula-fd with libwrap without error, all the backups will work just fine, but the file daemon will allow connections from all hosts. I only want the backup server to be given access to the file daemon. Please check for yourself, try "telnet backup.client.name 9102" to connect to port 9102 of your backup client (replacing "backup.client.name" with the name of any of your clients). If you can connect, access is granted (to do anything useful, you still have to know the Password). You can try this from different hosts. Ideally, only your backup server should be able to do this. Are you sure your setup works like that? Are you running bacula-fd standalone (started from an init-script) or via inetd/xinetd? I understand that you will finally use the hostname of your backup server in an entry in /etc/hosts.allow to grant it access, e.g. "bacula-fd: backup.server.host: ALLOW". I would suggest to try blocking incoming traffic to the bacula-fd first e.g. by putting "bacula-fd: ALL" into /etc/hosts.deny, and only to add that line to hosts.allow later on. This way you will see that restricting access works, which is what libwrap is all about. Regards, David. Bug History Date Modified Username Field Change ====================================================================== 01-25-06 10:53 david New Bug 01-25-06 11:02 Dan Langille Bugnote Added: 0001440 01-30-06 07:21 kern Assigned To => kern 01-30-06 07:21 kern Status new => assigned 02-05-06 08:56 kelvin Bugnote Added: 0001443 02-05-06 08:59 kelvin Bug Monitored: kelvin 02-06-06 04:03 david Bugnote Added: 0001444 ====================================================================== |