ソフトウェアの現状確認とアップグレード：止められないUNIXサーバのセキュリティ対策（2）（2/2 ページ）

» 2003年06月28日 00時00分公開

[木村靖，三井物産GTI]

ソフトウェアのアップグレード

　ソフトウェアのアップグレードは、迅速かつ安全に行う必要がある。そのためには、もし検証用のマシンがあれば、まずはそこで正常に動作するかどうかを確認するのが望ましい。そうでない場合は、問題が発生した時のことを考え、即座にアップグレード前の状態に戻せるような準備が必要となる。

　そういったことを踏まえつつ、パッケージシステムを用いたアップグレードの方法をいくつか紹介する。

●チェックサムを確認

　インターネット経由などでソースやバイナリファイルを取得した場合、多少面倒だが必ずファイルの正当性（チェックサム）の確認を行うことをお勧めする。なぜなら以前より、OpenSSH、Sendmailなどにトロイの木馬（バックドア）が埋め込まれたまま配布されたという事例が実際にあったからだ。いくら提供元からダウンロードしたからといって、そのファイルが100％安全であるとは思わない方が賢明だろう。

CA-2002-28: Trojan Horse Sendmail Distribution
CA-2002-24: Trojan Horse OpenSSH Distribution

　ダウンロードしたファイルの正当性を確認するには、提供元によって手段は異なるが、MD5、SHA1によるハッシュ値やPGPの署名を使用することが多い。例えばMD5の場合、次のように確認を行う。

$ cat apache_1.3.27.tar.gz.md5
MD5 (apache_1.3.27.tar.gz) = 65b89365a65dcad71d4402b4862beeaa
$ md5 apache_1.3.27.tar.gz
MD5 (apache_1.3.27.tar.gz) = 65b89365a65dcad71d4402b4862beeaa

　上記の出力結果より、apache_1.3.27.tar.gz.md5の内容と、md5コマンド（LinuxやSolarisはmd5sum）で出力したソースプログラムのハッシュ値が一致（正当である）していることを確認できる。

　同様のことを、RPMの場合は--checksigオプション（-K）で行える。

$ rpm --checksig --nogpg apache-1.3.27-2.i386.rpm
apache-1.3.27-2.i386.rpm: md5 OK

　“md5 OK”と表示されたら、このファイルの正当性（書き換え、破損していない）が証明される。

　また、パッケージの作成者のPGP（GPG）による署名も確認したい場合は、--nogpgを外せばよい。ただし、署名を確認する場合は、あらかじめパッケージ作成者の公開鍵をインポート（gpg --import公開鍵ファイル）しておく必要がある。公開鍵は、Red Hat提供のRPMの場合は、/usr/share/rhn/RPM-GPG-KEYかRed HatのWebサイトより入手可能だ。

　そのほか、*BSDで利用されるportsやpkgsrcでは、対象ソースファイルを自動取得する際に、取得ファイルのSHA1のハッシュ値を自動的にチェックし、もし違っていれば、その後の処理を停止するようになっている。

●RPMパッケージのアップグレード

　RPMによって管理されているソフトウェアのアップグレードは、rpmコマンドを使う。以下はrpm 4.0.4を元に説明する。

アップグレード（rpm -F）

RPMのアップグレードを行う場合、-Fまたは-Uオプションを指定する。両者の違いは、-Fがインストールされていない場合にインストールを行わないが、-Uは行う。そのため既存のパッケージを確実に更新したい場合は-Fを使用するとよい。

    # rpm -Fvh パッケージ名

-F：既存パッケージを更新

-v：結果の詳細表示

-h：インジケータ（#）を表示

例：apacheを更新する

    # rpm -Fvh --test apache-1.3.27-2.i386.rpm
    Preparing... ########################################### [100%]
    # rpm -Fvh apache-1.3.27-2.i386.rpm
    Preparing... ########################################### [100%]
    1:apache warning: /etc/httpd/conf/httpd.conf created as /etc/httpd/conf/httpd.conf.rpmnew
    ########################################### [100%]

実際のアップグレードを行う前に、--testで正しくインストールされるかどうかシミュレーションするとよい。失敗すると、上記のようなインジケータが表示されない。　

元に戻す

元に戻したい場合は、-Uと--oldpackageオプションの指定と、元のパッケージが必要になる。

    # rpm -Uvh --oldpackage 元のパッケージ

例：Apache 1.3.27 から 1.3.23 に戻す（ダウングレード）

    # rpm -Uvh --oldpackage apache-1.3.23-11.i386.rpm
    Preparing... ########################################### [100%]
    1:apache warning: /etc/httpd/conf/httpd.conf created as /etc/httpd/conf/httpd.conf.rpmnew
    ########################################### [100%]

もちろん、設定ファイルが初期値と異なる場合は、それらも元に戻す必要がある。

●Solarisパッケージのアップグレード

　Solarisバイナリパッケージのアップグレードは、pkgaddコマンドで行う。

アップグレード

    # pkgadd -d . デバイス

-d：パッケージファイルの場所。. はパッケージファイルが現在位置（カレントディレクトリ）にあることを示す

例：gcc 2.95.2 をインストールする

    # compress -d < GNUgcc.2.95.2.SPARC.32bit.Solaris.8.pkg.tar.Z | tar xvf -
    # pkgadd -n -d . GNUgcc

また、Solarisの場合、ソフトウェアによってはパッチで提供される場合がある。その場合、SunSolveよりパッチを個別に入手し、patchaddコマンドで適用する必要がある。

    # patchadd パッチファイル

元に戻す

pkgaddコマンドでインストールしたパッケージは、いったんpkgrmで削除し、元のパッケージファイルを再度pkgaddすることになる。

    # pkgrm 削除するパッケージ名
    # pkgadd -n -d . 前バージョンのパッケージ

pkgrmは、-Aを指定しない限りデフォルトでは設定ファイルなどは削除されないが、より安全に行う場合は個別にバックアップを取っておくとよい。

また、patchaddで適用したパッチを前のものに戻す場合は、patchrmコマンドを使う。

    # patchrm パッチID

●*BSDパッケージ（packages、ports、pkgsrc）

pkg_add、pkg_update

FreeBSDやNetBSDでバイナリパッケージを適用する場合は、pkg_updateやpkg_addコマンドを実行する。

    # pkg_update パッケージファイル（FreeBSD）
    # pkg_add -u パッケージファイル（NetBSD）

-u：インストール済のパッケージをアップグレードする

例：パッケージファイルapacheをアップグレードする。

    # pkg_update apache-1.3.27.tgz （FreeBSD）
    # pkg_add -u apache-1.3.27nb3.tgz （NetBSD）

また、インストール前に、インストールの手順がどのように進むかを確認するには、-nオプションを指定するとよい。

    % pkg_add -n apache-1.3.27nb3.tgz
    parsing: .
    path: /tmp/.
    increasing RLIMIT_NOFILE to max. 1772 open files
    trying PKG_PATH /home/y-kimura/.
    Requested space: 5546012 bytes, free space: 33431179264 bytes in /var/tmp/instmp.02281a
    Package `apache-1.3.27nb3' conflicts with `apache-*ssl-[0-9]*'.
    Package `apache-1.3.27nb3' conflicts with `apache6-[0-9]*'.
    Depends pre-scan: `expat>=1.95.2' required. Depends pre-scan: `libmm>=1.2.1' required. Package `apache-1.3.27nb3' depends on `expat>=1.95.2'.  - expat-1.95.6nb1 already installed.
    Package `apache-1.3.27nb3' depends on `libmm>=1.2.1'.  - libmm-1.2.2 already installed.
    Running install with PRE-INSTALL for apache-1.3.27nb3.
    Running install with POST-INSTALL for apache-1.3.27nb3.

（拡大）

ports、pkgsrc

portsやpkgsrcを使うことで、ソースプログラムの取得、チェックサムの確認、コンパイル、そしてインストールまでの一連の手順を簡単に行うことができる。また、インストールするために必須となるパッケージがインストールされていない場合は、最初にそれらのインストールも自動的に行ってくれる。

    % make
    # make install

または、

    # make clean
    # make update

makeでソースプログラムのコンパイルまでを行い、make install（make update）で実際にインストールされる。また、事前にインストールの手順を確認したい場合は、-nを指定する。

パッケージを生成する

portsやpkgsrcでは、それらをもとにパッケージを生成することもできる。これは同じ構成のサーバが複数台存在した場合に重宝する。なぜならサーバごとにコンパイルの必要がないため、復旧までの時間を短縮することができるからだ。

パッケージを生成する方法としては、ports, pkgsrcによるインストールの際に、make install（update）ではなくmake packageで行う。

    # make package

このほか、pkg_createコマンドで生成する方法も存在する。

元に戻す

*BSD のパッケージを元のバージョンに戻す場合、pkg_updateやpkg_add -uを使う方法もあるが、バージョンアップによりファイル構成などが変更されていることを考慮すると、いったんpkg_deleteで削除し、その後にpkg_addでインストールするのがよいだろう。また、より安全に行うためにも、pkg_deleteの前に、現状の設定ファイルのバックアップを忘れずに取るようにすること。

    # pkg_delete パッケージ名
    # pkg_add 前バージョンのパッケージファイル

なお、portsやpkgsrcの場合は、supやCVSでソースツリーを元に戻す方法もあるが、再度コンパイルする手間などを考えると、前述のパッケージをあらかじめ作っておき、戻すようにした方がよいだろう。

パッケージを作る

　先述のとおりパッケージシステムを利用することで、ソフトウェアのアップグレードなどは、極端にいえばコマンド1つで行える。また、操作方法もソフトウェアに依存することなく一貫して行えるので、同じ構成のサーバが何十台、何百台存在する場合に管理や維持がとても楽になる。

　とはいえ、ベンダが提供するソフトウェアパッケージでは、インストール時に各サイトに合わせた細かな設定が行えない場合がある。そのような時は、自サイト用のパッケージを作るようにする。今回紹介したパッケージシステムの場合、manコマンドや以下のサイトが参考になるので、早速挑戦してみようという管理者は一読することをお勧めする。