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

ワームの発生は止められない」記事へのコメント

  • 独善的な意見ですね。
    誰もが、サーバーの管理をして給料をもらっているわけではない。 サーバー管理より優先度が高い別の仕事をメインにやりながら サーバー管理もやらされている人は少なくない。
    日がな一日セキュリティホールつぶし遊びをしていれば ソレで済む暇なオタクばかりじゃないんだよ、世の中は。
    • 元トピが独善的な意見である事は概ね同意です。
      ただ、こちらの書き込みをされた方の文章も独善的ですね。

      今回の問題はかなり広域なサーバーに影響を与えるにも関わらず、
      修正まで公開を待てなかったISSに多少の問題があった様な気がします。
      以前、自分もセキュリティ関係でとある会社のソフトウエアに報告をした事がありますが、
      相手の反応を待って修正パッチが公開された頃に、警鐘の意味を込めて
      「この様なセキュリティホールがある」と謳った事があります。

      私の所属する会社でもApache 1.3.24(FreeBSD)が動いております。
      これ、一刻も早くバージョンアップしたいのですが、
      • >目下のサービスが止まる事の方を重要視します
        FreeBSDではApacheを使ったことないのですが、Linuxの場合はApacheを動作させたままrpmでバイナリを入れ替えても、動作には影響ないんですけど?
        なので、停止するのはApacheを再起動するための1-2秒間だけで済むはずなんですけどねぇ。
        私だったら、サーバーの負荷が少ない時間帯にこっそりと入れ替えちゃいますね(笑)
        #でもこういう客に限って、1時間くらい停止してても気が付かなかったりする。
        親コメント
        • >なので、停止するのはApacheを再起動するための1-2秒間だけで済むはずなんですけどねぇ。

          御意。ぼくの管理下にあるサーバはslackベースですが、apacheの入れ替えをする手順は、

          (1) テストマシン(本番マシンと同様の構成)で新apacheのビルド&インストール
          (2) テストマシンでの新apacheのチェック(ややこしいCGIとかがあるのでこれは必須)
          (3) 新apacheのバイナリをパック。及びpkgを作成(お客さんへの配布用)
          (4) 本番マシンに仮のディレクトリで新apacheを展開
          (5) 旧apacheの停止、旧apacheディレクトリの名前を保存名に変更、新apacheのディレクトリを本来の名前に変更、新apacheの起動、を(1コマンドラインorスクリプトで)一気に行う

          となります。HTTPサービスの停止時間は、まあ、数秒でしょうね。apacheをアップデートするのに、旧apacheを停止してから延々とビルド等を行う必要は更々無い訳です。また「テストマシンなんか無いよ」と言われる方には、この際ですから用意しましょう、と申し上げたいです。大体、本番サーバが壊れた時のバックアップ機があれば、それをテスト用にも使える訳ですし。バックアップ機の定期チェックも出来て一石二鳥でしょう。
          親コメント
          • >>「テストマシンなんか無いよ」と言われる方には、この際ですから用意しましょう、と申し上げたいです。

            FreeBSD の話になりますが,独立したマシンの代わりに Jail を用意するのも今後の定番になりそうですから指摘しておきます.
            シビアな管理者であれば,本番のサーバもなんらかの Sand Box での実行を考慮すべきですね.
            親コメント
            • >FreeBSD の話になりますが,独立したマシンの代わりに Jail を用意
              >するのも今後の定番になりそうですから指摘しておきます.

              jailは、満足なテストが出来ない場合があり、必ずしもテストマシンの代わりにはならない場合もあるでしょう。

              >シビアな管理者であれば,本番のサーバもなんらかの Sand Box での
              >実行を考慮すべきですね.

              確かに人様が作られた(サーバ)ソフトウェアで、プログラム的な欠陥から特権的なオペレーションが可能になってしまうものに関しては、jailは有効です。ですが、それよりは最初から特権的なオペレーションが不可能なソフトウェアの構成の方がより良い構成では無いでしょうか。ぼくはその様にソフトウェアを作成しています。

              まあ、とは言え、その様なソフトウェアでもプログラミングをしくる可能性は0では無いですし、設定をミスる場合もあるでしょうから、jailの中で動かす事はベルトと吊りバンド併用的な、考慮すべき方法論の1つですね。設定や構成がより複雑になりかねないと言うデメリットも勘案して、無用の事であるない、採用するしないは、実装者and/or運用者の判断でしょう。
              親コメント
          • そうともばかりは言えないかと。

            ミッションクリティカルな場合、まずユーザーへのサービスを停止します。
            #Apacheを止めるって意味じゃないですよ。「業」としてのサービスです。
            その後初めて入れ替えが出来ます。
            で、当然それだけではユーザーへのサービスを再開する事は出来ず、
            運営責任者同伴で一通りの試験をして問題が無いと確認し、きちんと承認を
            貰ってからで無いとユーザーのサービスは再開出来ないって事になりますから。

            因みに、作業中は同伴している運営責任者から、
            「1分止めるとウン十万円の損害なんだよねぇ。」
            って御託が必ずと言って付いてくるのが何かと。

            >また「テストマシンなんか無いよ」と言われる方に は、この際ですから
            >用意しましょう、と申し上げたいです。大体、本番サーバが壊れた時
            >のバックアップ機があ れば、それをテスト用にも使える訳ですし。
            >バックアップ機の定期チェックも出来て一石二鳥でしょう。
            ちょっと甘いのでは?って気も。
            ここ数年企業はどこもシブイですから。
            某一部上場企業でもバックアップ機の購入契約を延期延期と引き伸ばすの
            が珍しく無いです。
            また、今までの場合のバックアップやテスト機はどうだった?って言えば、
            往々にして担当の私物だったり。が、どこも不況で収入が落ち込んでいる
            現状では、それもままならない状況が続いている所も多いですし。

            親コメント
            • 業としてのサービスですね?apacheの様な単体アプリケーションがどうこうという話ではなくて。

              ミッションクリティカルなシステム、ぼくが絡んだものは、テスト環境(本番データを使用、外部へのサービス提供は無し)で検証を行って、が手順でしたが。勿論、ソフトウェア移行の後に本番サーバで最終試験はしますが、それは移行後の確認ですね。世間一般の業として行われているミッションクリティカルな用途では、テストとは現物合わせ、つまりサービスを提供を止めないとテストは出来ない、と言う、いわば情けないマネジメントで行われているのが普通なのでしょうか?是非この点についてご教授をお願いしたいです。

              バックアップ/予備機が用意出来ず、サービスを行なっている会社は、まあ存じております。悪徳というか、ハコモノ重視のSIに乗せられて、えらく高いマシン(パフォーマンスもC/Pも決して良くはありません)を買ってしまい、予備機を買う金が無くなってしまった、とかで。人事を尽くさず天佑神助に期待、しかし残念ながら神様はそう甘い顔ばかりもしてくれず、メンテが入るまでの3日間はサーバが止まりっぱなし、の様な格好良い姿を世間に晒す訳です。こういうマネジメントは論外とは思いますが、現実にその様な事が行われているのもまた事実。その様なマネジメントが通用するとすれば、ソフトウェアのアップデートとかも無しと言うか無視となるのでは、と考えてしまいます。実際、セキュリティホールの博物館と化してたりします(笑)。
              親コメント
              • >世間一般の業 として行われているミッションクリティカルな用途
                >では、テストとは現物合わせ、つまりサー ビスを提供を止めないと
                >テストは出来ない、と言う、いわば情けないマネジメントで行われ
                >ているのが普通なのでしょうか?

                ちょっと異なるかな?
                テスト環境でのテストはやります。が、それによる結果確認は飽く迄
                テスト環境のものであって、実機のものではありません。故に、実機での
                再確認が必要となるのですが。

                実際、微細な差によりトラブル発生ってのも無いとは言えないですし。
                まあ、モノに依って(例えば、ページが見れなくて客がいらつく程度なら)
                は端折れる事もあるでしょうけど、1件の取引がウン十万ウン百万って
                なって来ると、
                「ちょっとしたトラブルで消えちゃいました」
                とは言えませんので。

                つまり、どのレベル迄保証するのかの程度問題って事。
                保証基準が甘ければ確認も簡単短時間で済むけども、保証基準がキツイと
                そうお手軽って訳にもいかない。
                #尚且つ、運用試験手順書には、「運用試験は自動で行うだけでなく、
                #必ず複数の人間が手入力して確認する」と書かれてたりするので、
                #更に時間は嵩む訳で。

                また、サービスを止める時は、必須1秒であっても、取引先の時計の誤差
                なんかも考慮して安全マージンを取り、10分間とか告知するのも普通だと思います。

                >バックアップ/予備機が用意出来ず、サービスを行なっている会社
                >は、まあ存じております。

                いや、上場企業のIT担当ですら、
                「使わないバックアップ機はカネの無駄。」
                と言いきる人もいます。
                ましてや有象無象の企業ではサポート契約なしバックアップ無しってのも
                珍しく無く、実際にソフトウェアアップデート無しって例も幾つもあります。
                一応担当者にメールとFAXで通知は入れているんですが、結局
                実害無しの為、放置されっぱなしってのも多いです。
                まあ、相手も予算があっての行動ですし、こちらもボランティアとして
                行う訳にもいかない(対処は出来てもその後に発生するトラブルの可能性
                に対しての保証が契約していない個人では出来ない)です。
                それなら、せめてアップデート手順を担当者教えてって思っても、
                よっぽど責任感が強い人はともかく、大抵は新たな責任の発生を
                嫌って「触れない」と言ってくるのが多いですし。
                #まあ、外注に出すってのはそれらの保証と責任を買うわけだから
                #それ自体は理解出来ない訳で無いが。

                故に、野良サーバは増えつづけるのでは無いかと。

                親コメント
              • 余裕があるとこんなのも飼ってられるんだなぁという意味では 非常にためになりました。
              • 止められない(ユーザサイドから見て)、ミスれない(ワンミスがウン十万ウン百万、但し米ドル)であるからこそ、テスト環境を実際に限りなく近づけ、実機での検証の時間を最小限にする、が、そこの思想なのです。保証基準が甘いなどとはとんでもない、恐怖のダブルバインド状態にあるそこの方針に比べれば、何だかんだと実機でテストを繰り返す事も可、は、かなり気が楽なシステムだと思いますよ。

                実際の所、ミッションクリティカルなシステムはその様なタイトな運用が行われているものにしかコミットしていません。(日本の)世間一般にはどの様な方針で運用が行われているのか分からなかったため、ご教授を願いました。そこまでのタイトな要求は(多分日本で、だと思いますが)ミッションクリティカルなシステムの運用に求められていない、がお答えの様ですね。勉強になりました。

                「使わないバックアップ機はカネの無駄」と言い切るIT担当者、ありがちですね。敷衍すれば「セキュリティホール潰しなんざ金の無駄」となる訳で。振り返ってapacheの事に話を戻すと、タレコミにある様に「脆弱なApacheサーバを放置している管理者」が最大の問題児であるという意見には激しく同意してしまいます。それが独善的である、出来ない事を強要してる、等の意見は、将に現状のpoorなマネジメントを是認している事で、「ぼく、悪くないもん!」的なオコチャマ発想と考えたりします。
                親コメント
              • 全てが技術屋の理想通りなら本当に素晴らしいですよね。

                実際にミッションクリティカルな業務であったとしても、それに使用する
                予算を決めるのはそのその責任者であり会社ですから。
                が、だからと言って運用を行わない訳には行かない。
                となれば、永遠の暫定仕様のシステムってのが発生するのが往々にあります。
                結果、ミッションクリティカルにも関わらず、それに即した構成に
                なってないシステムが多々存在るのが『現実』ってものです。
                #って、元々理想論を外した問題の出る例を出していた筈ですので、
                #「それはおかしいですね」って言われれば「そうですね」としか
                #言えないんですが。
                もっと端的に、「ケチった結果」ってのも多いし。

                >タレコミにある様に「脆弱なApacheサーバを放置している管理者」
                >が最大の問題児 であるという意見には激しく同意してしまいます。

                最大かどうかはさておき、問題であるのは確かでしょう。
                が、それの基準が余りにも曖昧なレベルで他を責める書きこみが
                多いのがちょっと。
                パッチの適応が1時間であっても半日でも2・3日でも、危険を放置
                している期間が存在するのは同じ。
                確かに放置している期間が長い方が危険度は高いでしょう。
                でも、それをOK・NGと別ける厳密な基準ってのは無いんですよ。
                それを主観的な基準により「自分はOKそれより遅いとNG」的に
                表現されていたりすると「なんだかなぁ」と思ってしまいます。
                他人の目から見れば、その「俺的自分はOK」ってのでも遅すぎて
                話にならないって可能性もありますし逆もありえますし。

                実際、各サーバに人間を複数配してワッチをし、いざという時の為に
                バックアップ機材・要因を揃え、必ず人間が24時間監視しているって会社
                ってどんだけあります?
                それによりセキュリティレベルが上がるのは確かですよ。
                でも、ここで他人の怠慢を最大理由にしている人でもまずそこ迄は行って
                無いのでは?
                でも、本当にセキュリティを重要視するプラントなんかでは常識
                ですから、不可能でも非現実的でもないので、完璧を目指すのであれば
                やるべきではありませんか?

                で、もしあなたがそこ迄やらないのであれば、その理由が即ち、他の仕事
                にかまけてメンテを一日二日延ばしにする管理者の理由だと思いますが。
                #やっているなら「凄いですねぇ」と素直に賞賛しますよ。

                親コメント
        • 沢山の方々のご意見を聞けて随分勉強になりました。
          ちなみに、1秒でも2秒でも「停止」は「停止」です。
          結構厳しいんですよ、対社外の契約は。自分のせいでは無くても信用問題に関わります。
          それに自分の所では常にサーバを監視していますので、止まったという記録はlogに
          残ってしまいます。
          そして、万が一デーモンが起動してこなかったら?
          担当の勝手でその様な事態を引き起こしてしまったら、会社にどれだけの損害を与えるかわかりません。
          サーバ管理者である以上、常にリスクマネージメントを行う必要があります。
          勝手に入れ替えができ、万が一止まっても全然平気なモノなら良いのですが・・・

          結局、別契約で使用していたロードバランサを一時的に利用しました。
          同じ構成のテストマシンを併用し、コネクションを見ながら0になったらアップデート。
          というカタチにしました。
          停止時間は限りなく0に近い状態でアップデートできました。
          ま、一番苦労したのは上と契約先担当の説得でしたけど(苦笑
          親コメント

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

処理中...