導入していて良かったは無いのですが、導入しておけば良かったはあります。それは、もうすぐ3年も前になるのですが、かの有名なシェルショックの時です。
当時を知る人であればわかると思いますが、シェルショックはかなり大きな衝撃でした。ほとんど全てのLinuxについて余りにも危険な脆弱性が発見されたからです。私の所でも、ほとんどのサーバーは早急にパッチやアップデートを実施し、事なきを得ました。しかし、一部のサーバーでパッチやアップデートを怠っていて、シェルショックの脆弱性による攻撃を受けてしまいました。
攻撃方法は単純で、Apache HTTP Server上で動作しているCGIを経由してシェルショックの攻撃を行い、/tmpに実行ファイルの設置して、cron経由で定期的に実行させるようになっているというものでした。たしか、仮想通貨のマイニング目的の実行ファイルだったと記憶しています。サーバー負荷が異常に高くなり、サイトの閲覧速度に影響が出たため発覚しました。発覚後、急ぎネットワークから隔離し、そのサーバー以外の被害は無かったのですが、その後の処理がとても大変だったことを記憶しています。それほど重要なWebサーバー(組織トップのホームページとかでは無かった)では無かったことも幸いでした。
もし、このとき、Apache HTTP ServerがSELinuxで制限されていればと思うことがありました。実際に、SELinux配下のApache HTTP Serverでは、シェルショックの攻撃はかなり限定的になり、実際に受けた攻撃を含め、ほとんどの攻撃は成功しません。言ってみれば、ある程度は未然に防げていた攻撃だったと言うことです。
そして怖かったのは、シェルショックが発覚してからそれほど間を開けず(たしか、一週間後ぐらい後)に攻撃されたことです。ほとんどのサーバーはパッチやアップデートも公開された次の日にはあてていましたが、少しでも遅れていたら、多くのサーバーが攻撃が成功していたと思われます。かなりゾッとした記憶があります。
このことがあってからは、外部公開するようなサーバーは基本的にSELinuxを有効にしています。SELinuxをそもそもサポートしていないソフトウェアを使用すると言った事情が無い限りは、原則有効のままで個別のポリシーで対応するようにしています。一番怖いのはシェルショック並みの脆弱性に対するゼロデイ攻撃です。もし、攻撃されても、ある程度防いでくれるSELinuxは最終防衛ラインの要だと思っています(と言っても、全ての脆弱性を防いでくれるわけではありません)。
ほとんどの泥棒は10分以内に侵入できなければ、諦めるという話があります。悪意ある攻撃者も同じです。未知または新規の脆弱性などを使って攻撃するとき、わざわざ強固なSELinuxで固められたサーバーを狙うよりは、セキュリティーが緩めのサーバーを狙った方がはるかに効率的です。そういった点でも、SELinuxは攻撃の予防に役に立っていると思います。
セキュリティを考えれば、SELinuxは手間に見合うだけの価値があると信じています。ツール類や情報もSELinuxが出た当初に比べれば遥かに豊富で簡単になっています。問題が起きたときに発生する手間(本当に大変です)を考えれば、安いコストだと思えませんでしょうか?
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/08/21 23:25