Bacula セキュリティ

投稿者: | 2014年6月11日

Bacula セキュリティ

  • 本ドキュメントでのセキュリティ とはファイルをリストアできること、を意味する。したがってこのマニュアルのCritical Items Chapter を参照してください。
  • クライアント(bacula-fd) がすべてのシステムファイルにアクセス可能であるためには、
    root で動作する必要がある。
  • ディレクタはroot で動作している必要は無い
  • ストレージデーモンをroot で動作させる必要は無い。だが、それが確実にテープドライ
    ブをオープンすることが出来るようにしておくこと。デフォルトではroot のみがアクセスできるように制限がかかっている。さらに、ストレージデーモンをroot で動作させていない場合、テープドライブのパラメータは、ほとんどのOS で自動的には設定されない。というのも、これらの関数は、残念ながらroot の可能であるから。
  • Bacula 設定ファイルへのアクセスを制限する必要がある。そのためにパスワードはどこ
    あらでも読み取り可能であってはならない。Bacula のデーモンはパスワードで保護さ
    れているCRAM-MD5 を使用している(すなわち、パスワード自体がネットワーク越し
    に送られることは無い)。こうすることで、誰もがデーモンにアクセスできる、という状
    況を作らないことが出来る。これは妥当でうまく出来た保護であるが、エキスパートに
    はクラックされる可能性がある。
  • 推奨されているポート、9101、9102、9103 を使用している場合、これらのポートを外部
    のアクセスから保護する必要がある。ファイアーウォールを使用する、そして/あるい
    は、tcp wrapper を使用する(etc/hosts.allow)。
  • デフォルトでは、すべてのデータはネットワーク越しに暗号化されずに送信される。しかしBaculaはTSL(Transport Layer Security)をサポートするので、送信データを暗号化する事が出来る。
    *このマニュアルのTLS (SSL) Communications Encryption を参照。
  • Bacula のワーキングディレクトリは、Bacula のデーモンだけが読み書きできるように必
    ずしておく。
  • MySQL を使用している場合、root 権限で動作させる必要は無い。
  • デフォルトのBacula のgrant-mysql-permissions スクリプトはMySQL データベースをパスワードなしで使用するすべての権限を付与するスクリプトである。安全性を求めるなら、制限を強めること!
  • Don’t forget that Bacula is a network program, so anyone anywhere on the network with the console program and the Director’s password can access Bacula and the backed up data.
  • Bacula はネットワークプログラムであるため、コンソールプログラムを持ち、ディレクタのパスワードを持っていれば、ネットワーク上にいる全ての人が、Bacula 及びバックアップされたデータにアクセスできてしまう事は留意して欲しい。
  • DirAddress、FDAddress、あるいはSDAddress レコードを対象となるデーモン設定ファ
    イルで使用し、Bacula を利用する事が可能なIP アドレスを限定できる。
  • より高い安全性を求める場合、環境変数または安全なファイルでそれを受け渡すように
    する。更なる情報については、Backing Up Your Bacula Database – Security Considerations を参照の事。
  • もし貴方のデータベースをデフォルトのスクリプトを利用してバックアップしており、パスワードがデータベース上にある場合、パスワードはコマンドラインオプションとしてスクリプトに引き渡される事になるため、任意のユーザーがパスワード情報を見れる事になる。より安全に運用したい場合、環境変数もしくは安全なファイルでパスワードを引き渡す必要がある。Backing Up Your Bacula Database – Security も参照して欲しい。

後方互換

Baculaの主なゴールとして何年も前に記録したテープ・ディスクボリュームを確実にリストア可能にする事です。新しいバージョンのBacula が古いフォーマットのテープを読み込むことが出来なければならないことを意味します。最初に突き当たる問題は、数年経過後に、ハードウェアが動く事、ふたつ目の問題は、メディアの状態が良い事、そしてOS がドライブへ接続でき、最後に、Bacula が古いフォーマットを認識でる事となります。『Baculaが古いフォーマットを認識できる』事以外は私達には関与できないため、ユーザーの皆様側で計画する必要があります。

 

Since the very beginning of Bacula (January 2000) until today (December 2005), there have been two major Bacula tape formats. The second format was introduced in version 1.27 in November of 2002, and it has not changed since then. In principle, Bacula can still read the original format, but I haven’t tried it lately so who knows …

Though the tape format is fixed, the kinds of data that we can put on the tapes are extensible, and that is how we added new features such as ACLs, Win32 data, encrypted data, … Obviously, an older version of Bacula would not know how to read these newer data streams, but each newer version of Bacula should know how to read all the older streams.

If you want to be 100should:

1. Try reading old tapes from time to time – e.g. at least once a year.

2. Keep statically linked copies of every version of Bacula that you use in production then if for some reason, we botch up old tape compatibility, you can always pull out an old copy of Bacula …

The second point is probably overkill but if you want to be sure, it may save you someday.

Configuring and Testing TCP Wrappers

TCP Wrappers are implemented if you turn them on when configuring (./configure --with-tcp-wrappers). With this code enabled, you may control who may access your daemons. This control is done by modifying the file: /etc/hosts.allow. The program name that Bacula uses when applying these access restrictions is the name you specify in the daemon configuration file (see below for examples). 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 exact name of the package you need loaded to build with TCP wrappers depends on the system. For example, on SuSE, the TCP wrappers libraries needed to link Bacula are contained in the tcpd-devel package. On Red Hat, the package is named tcp_wrappers.

Dan Langille has provided the following information on configuring and testing TCP wrappers with Bacula.

If you read hosts_options(5), you will see an option called twist. This option replaces the current process by an instance of the specified shell command. Typically, something like this is used:

ALL : ALL \
 : severity auth.info \
 : twist /bin/echo "You are not welcome to use %d from %h."

The libwrap code tries to avoid twist if it runs in a resident process, but that test will not protect the first hosts_access() call. This will result in the process (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated if the first connection to their port results in the twist option being invoked. The potential, and I stress potential, exists for an attacker to prevent the daemons from running. This situation is eliminated if your /etc/hosts.allow file contains an appropriate rule set. The following example is sufficient:

undef-fd : localhost : allow
undef-sd : localhost : allow
undef-dir : localhost : allow
undef-fd : ALL : deny
undef-sd : ALL : deny
undef-dir : ALL : deny

You must adjust the names to be the same as the Name directives found in each of the daemon configuration files. They are, in general, not the same as the binary daemon names. It is not possible to use the daemon names because multiple daemons may be running on the same machine but with different configurations.

In these examples, the Director is undef-dir, the Storage Daemon is undef-sd, and the File Daemon is undef-fd. Adjust to suit your situation. The above example rules assume that the SD, FD, and DIR all reside on the same box. If you have a remote FD client, then the following rule set on the remote client will suffice:

undef-fd : director.example.org : allow
undef-fd : ALL : deny

where director.example.org is the host which will be contacting the client (ie. the box on which the Bacula Director daemon runs). The use of “ALL : deny” ensures that the twist option (if present) is not invoked. To properly test your configuration, start the daemon(s), then attempt to connect from an IP address which should be able to connect. You should see something like this:

$ telnet undef 9103
Trying 192.168.0.56...
Connected to undef.example.org.
Escape character is '^]'.
Connection closed by foreign host.
$

This is the correct response. If you see this:

$ telnet undef 9103
Trying 192.168.0.56...
Connected to undef.example.org.
Escape character is '^]'.
You are not welcome to use undef-sd from xeon.example.org.
Connection closed by foreign host.
$

then twist has been invoked and your configuration is not correct and you need to add the deny statement. It is important to note that your testing must include restarting the daemons after each connection attempt. You can also tcpdchk(8) and tcpdmatch(8) to validate your /etc/hosts.allow rules. Here is a simple test using tcpdmatch:

$ tcpdmatch undef-dir xeon.example.org
warning: undef-dir: no such process name in /etc/inetd.conf
client: hostname xeon.example.org
client: address 192.168.0.18
server: process undef-dir
matched: /etc/hosts.allow line 40
option: allow
access: granted

If you are running Bacula as a standalone daemon, the warning above can be safely ignored. Here is an example which indicates that your rules are missing a deny statement and the twist option has been invoked.

$ tcpdmatch undef-dir 10.0.0.1
warning: undef-dir: no such process name in /etc/inetd.conf
client: address 10.0.0.1
server: process undef-dir
matched: /etc/hosts.allow line 91
option: severity auth.info
option: twist /bin/echo "You are not welcome to use
  undef-dir from 10.0.0.1."
access: delegated

Running as non-root

Security advice from Dan Langille:

It is a good idea to run daemons with the lowest possible privileges. In other words, if you can, don’t run applications as root which do not have to be root. The Storage Daemon and the Director Daemon do not need to be root. The File Daemon needs to be root in order to access all files on your system. In order to run as non-root, you need to create a user and a group. Choosing bacula as both the user name and the group name sounds like a good idea to me.

The FreeBSD port creates this user and group for you. Here is what those entries looked like on my FreeBSD laptop:

bacula:*:1002:1002::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin

I used vipw to create this entry. I selected a User ID and Group ID of 1002 as they were unused on my system.

I also created a group in /etc/group:

bacula:*:1002:

The bacula user (as opposed to the Bacula daemon) will have a home directory of /var/db/bacula which is the default location for the Bacula database.

Now that you have both a bacula user and a bacula group, you can secure the bacula home directory by issuing this command:

chown -R bacula:bacula /var/db/bacula/

This ensures that only the bacula user can access this directory. It also means that if we run the Director and the Storage daemon as bacula, those daemons also have restricted access. This would not be the case if they were running as root.

It is important to note that the storage daemon actually needs to be in the operator group for normal access to tape drives etc (at least on a FreeBSD system, that’s how things are set up by default) Such devices are normally chown root:operator. It is easier and less error prone to make Bacula a member of that group than it is to play around with system permissions.

Starting the Bacula daemons

To start the bacula daemons on a FreeBSD system, issue the following command:

/usr/local/etc/rc.d/bacula-dir start
/usr/local/etc/rc.d/bacula-sd  start
/usr/local/etc/rc.d/bacula-fd  start

To confirm they are all running:

$ ps auwx | grep bacula
root   63418 0.0 0.3 1856 1036 ?? Ss 4:09PM 0:00.00
    /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
bacula 63416 0.0 0.3 2040 1172 ?? Ss 4:09PM 0:00.01
    /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
bacula 63422 0.0 0.4 2360 1440 ?? Ss 4:09PM 0:00.00
    /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf
カテゴリー: