パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Apacheの脆弱性を狙うWormが遂に登場」記事へのコメント

  • by tag (10007) on 2002年07月01日 1時05分 (#116494) 日記
    今回はおおごとになりそうだと思い、先々週に1.3.26が公開さ
    れた時にバージョンアップしました。しかし、面倒な作業を減
    らそうと、ちょっといい加減なやりかたをしてしまったかもし
    れません。

    皆さんは、どういうふうにバージョンアップをしていますか。
    教えて下さい。(できれば、どれくらい手抜きができるか、教
    えて下さい。)

    Solarisではmake時にインストールディレクトリを指定してい
    ます。/usr/local/apacheはそこへのリンクにしてあります。
    新バージョンが出た時には、版指定ディレクトリへインストー
    ルします。confファイルの変更を調べ、特に重大な変更がなけ
    れば、旧のconfでの設定情報を移植します。テストサーバ(例
    えば10080番ポートで起動)で動きをチェックし、最低限の表
    示がちゃんとなされることを確認します。コンテンツ管理者に
    も動作をチェックしてもらいます。ちなみに、コンテンツは普
    通のHTMLファイルと簡単なCGIだけです。

    これだけチェックして、/usr/local/apacheのリンクを新版に
    変更し、外部公開用ポート(80番ポート)のapacheを再起動し
    ました。

    単純なコンテンツしかないので、こんな簡便なやり方で、えい
    やっとできるのですが、もうちょっと慎重に動作検証したほう
    がいいでしょうか?

    FreeBSDでもapacheを動かしているのですが、こちらはバージョ
    ン対応のディレクトリはないですね。古いバイナリは1.3.19
    だった(更新サボってました)のですが、1.3.26のバイナリを
    作り、それだけを置き換えておきました。モジュールの再コン
    パイルが必要だという議論がありましたが、僕のサーバでは不
    必要でした。

    RedHat LINUXではapacheを動かしていなかったの、更新は必要
    なかったのですが、もしやるとしたらrpmで置き換えるしかな
    いのですかね。うまく動かなかった時に元に戻れるか、ちょっ
    と不安ですが、大丈夫でしょうか。

    今回のように緊急に置き換えが必要な時、皆さんはどういうふ
    うに作業しているんですか。教えて下さい。
    • >今回のように緊急に置き換えが必要な時、皆さんはどういうふ
      >うに作業しているんですか。教えて下さい。

      構成の複雑さによりけりじゃないですかね。
      上書きはモジュールがバージョンの差異で不具合を起こすことも
      ありますからバッサリ上書きというのもぞっとしないですが、
      単に./configureした程度のものなら、私ならバッサリやります。
      普通は仰るとおりにシンボリックリンクを使用するのが安全でしょう。
      非常に込み入ったことをしているなら作業に時間がかかって
      危険かもしれませんが。

      この間PHP-4.2.1が動いてる1.3.24を1.3.26に入れ替えましたが、
      そのときは急ぎだったのでhttpdと標準モジュールだけすげ替えました。
      一応CHANGESには目を通して大丈夫だろうという算段でやったのですが、
      今のところ問題ないように見えます(実は節穴だったりして)。
      httpd.confもだいぶいじってますが大丈夫でした。

      しかし、大事なのは緊急に備えて日頃から使用しているアプリケーションの
      動向をチェックしておくことでしょうね。それにつきます。
      ほったらかしにしておいて緊急時にあわてるのは避けたいです。
      #業務多忙な管理者には酷なことかもしれませんが。

      あと、このあたりのスレッド [apache.or.jp]なんかは参考になります。
      親コメント
    •  サーバの構成や、運用の携帯などで方法は様々ですが、一番良いのはごっそりバージョンアップするのがいいとは思いますが

       構成によっては危弱性のあるバージョンでもTransfer-Encoding: chunkedをBadRequestされたケースもありました。

       この場合特に急がず、ゆっくりと情報収集してごっそりバージョンアップできますね。

       また、運用的にもうすぐコンテンツが終了でサーバ自体を使わなくなるというケースもありました。これはPHP4.1.2の他、追加モジュールがあったので、すべてをあげるはさすがに怖く、コンテンツ終了まで祈って逃げ切りたい衝動を抑えつつ、危弱性をとりあえず回避させるDSOモジュールがBugTraqにあげられてましたので、こちらを入れることで逃げ切ることにしました。

      BugTraqにあげられた文章
      http://archives.neohapsis.com/archives/bugtraq/2002-06/0282.html
      ソースのDL先
      http://www.awayweb.com/pub/src/

      また、つい先日メンテナンスでサイトを停止させてもらった後にこの問題が出たサイトについても上の方法で次回のメンテナンスが出来るまで回避することにしました。

      ごっそりやる場合はやっぱり、テスト機などでなるべく同構成に近い形でテストを繰り返してやるような形ですね。

      RPMの場合設定ファイルのバックアップを取得してごっそりアップグレードして、不具合があったらダウングレード(http://www.awayweb.com/pub/src/)じゃだめなのかな?(う、やたことない)

      ソースの場合は、私の場合/usr/local/apacheなどひとまとまりになってることが多いのでそれごとまるまるバックアップとしてコピーして、新しいのを./configure make make install。

      でも構築時のconfig.status等を保存しているので、それを元にconfigのオプションを同一にしています。

      こんなとこかな。いずれにしてもドキドキですよね(笑
      --
      ---Shogo Sato
      親コメント
    • $./configure --オプションいくつか
      $make
      #apachectl stop
      #make install
      #apachectl start
      ですが、何か?
      親コメント

人生unstable -- あるハッカー

処理中...