「apt-get upgrade」を頻繁に実行して、Webサーバーを安全に保つことができますか？
仮定：
- Webアプリを実行している通常のLAMP Webサーバー。 （例：AWS EC2 + Apache2 + MySQL + Php7）
- スーパーハッカーや政府機関などの直接の標的にはなりません。
- 上記の点に関連して、ソーシャルエンジニアリングやWebアプリ自体は安全ではありません。
誰に狙われた？
自動スキャンとエクスプロイト。他にありますか？
が走っています apt-get update && apt-get upgradeウェブサーバーを安全に保つのに十分な頻度で？
いいえの場合
新興企業にとってWebサーバーを適度に安全に保つために、サーバーを管理している「平均的な」Webアプリプログラマーが他に何をすべきか。
場合によります...
はい、それは常に多くのものに依存します。一般的なWebアプリプログラマーが認識しているかどうかに関係なく、最も一般的なケース（パレートの原則）の前提条件を含めてください。
通常は問題が発生する多くの問題を削除しました（つまり、ホストしているアプリが完全に安全であると想定しています）。実用的な観点からは、それらを絶対に考慮する必要があります。
しかし、おそらくあなたはそれらを知っているので、いくつかの保護対策を講じています。それでは残りについて話しましょう。
まず、おそらく「あまり頻繁に」更新を実行すべきではありません。ほとんどのディストリビューションはセキュリティ発表メーリングリストを運営しており、そこで脆弱性が発表されるとすぐに、それはかなり一般に公開されます（まあ、それはその前にあることが多いですが、状況によっては世界中のすべてのセキュリティリストを実際に監視することはできません）。これらはトラフィックの少ないリストなので、通知を受け取ったらディストリビューションにサブスクライブしてアップグレードする必要があります。
多くの場合、メンテナが実際に兆候を探しているわけではないので、何気なくメンテナンスされているサーバーが、ブルートフォースやディクショナリ攻撃に長期間さらされる可能性があります。次に、通常の対策（sshパスワード認証なし、sshとApacheでのfail2ban）を適用し、不審なアクティビティが発生したときに監視アラートを設定することをお勧めします。それがメンテナンス（時間）の予算を超えている場合は、定期的にログインしてそれらを手動で確認するようにしてください。
従来、セキュリティの一部とは考えられていませんでしたが、新しいサーバーをすばやく起動できるようにしたいと考えています。これは、サーバー構成スクリプト（Ansible、Chefなどのツールがシステム管理に役立つ）と、テストした自動バックアップシステムを意味します。サーバーが侵害された場合、それが永久に危険にさらされていると思い込んで、それを消去する必要があります。データの定期的なバックアップをとっていなかった場合、それはうんざりです。
更新を頻繁に実行する場合（つまり、「毎回」ではなく少なくとも毎日）、サーバーを安全に保つ可能性が高い 。
ただし、 Shellshock または ImageTragick のような重大なバグが時々発生します。また、安全でないサーバー構成は攻撃を可能にする可能性があります。つまり、通常の更新を実行するだけではなく、次のようなアクションを実行する必要があります。
- 最小限のシステムを実行して、攻撃の対象を減らします。つまり、不要なソフトウェアをインストールしません。
- 外部からアクセス可能なサービスを制限することにより、攻撃対象領域を減らします。つまり、パスワードベースのSSHログインを許可しない（キーベースのみ）、不要なサービスを実行しないなど
- 重要な更新の影響を確実に理解する
- システムが攻撃されることを期待し、影響を軽減しようとします。たとえば、chroot、jail、またはコンテナー内から外部からアクセスできるサービスを実行します。
- ログイン失敗などの重要なイベントを記録し、ログを理解して、実際にログを分析する
それでも、最もよく使用される初期の攻撃ベクトルは、おそらくWordpressまたは他のCMSなどの安全でないWebアプリケーションです。
最近のほとんどのLinuxディストリビューションには、なんらかの自動更新ソリューションが付属しています。サーバーで有効にすることを検討する必要があります。これにより、サーバーが攻撃に対して脆弱になる時間が大幅に短縮されます。
Debianについて言及しているので、 nattended-upgrades の設定を検討する必要があります。 RedHatにはyum-cronがあり、SuseはYaSTを介してそれらを取得できます。
これらのアップグレードは通常、セキュリティパッチに限定されており、システムを破壊することはほとんどありませんが、完全に不可能ではありません。最終的には、このアプローチのリスクとメリットに重みを付けるのはあなた次第です。
apt-get upgradeは、すでにインストールされているパッケージの新しいバージョンのみをインストールします。現在インストールされていないパッケージはインストールされません。また、新しいバージョンが現在インストールされていないパッケージに依存している場合、既にインストールされているパッケージはアップグレードされません。
DebianとUbuntuでは、カーネルの各バージョンは個別のパッケージに入れられ、バージョンがその名前に含まれています。また、常に利用可能な最新のカーネルに依存する仮想パッケージがあり、依存関係はバージョンごとに変更されます。たとえば、今のところ linux-image-generic in xenial はlinux-image-4.4.0-63-genericに依存します。このスキームでは、古いバージョンのカーネルをインストールしたままにして、新しいバージョンのカーネルがハードウェアと互換性がないことが判明した場合に備えています。
ただし、これはapt-get upgradeが新しいカーネルをインストールしないことを意味します-そのためにはapt-get dist-upgradeが必要です。ただし、パッケージを削除する可能性もあるので、多くの人は自動での使用を避けています。 Ubuntuの新しいバージョンでは、apt upgradeを使用できます。これにより、新しい依存関係がインストールされますが、パッケージは削除されません。
また、OpenSSLをアップグレードするときは、少なくともそのライブラリを使用するサービスをリロードする必要があります。 Ubuntuでは、システムは安全側にとどまるために再起動を要求するだけであり、多くの人々は自動再起動に対しても予約があります。
ここにはすでにいくつかの良い答えがあります。しかし、私はいくつかのギャップを埋め、既存の回答のいくつかでは対処されていないように見えるいくつかのことを指摘したいと思いました。
スーパーハッカーや政府機関などの直接の標的にはなっていません
これは危険な視点です。多くの小規模組織は、このコアアイデアのバリエーションに基づいて破産を余儀なくされています。サーバーをハッキングする用途や理由を見つける可能性がある人を実際に予測することはできません。政府やスーパーハッカーがシステムを標的にしている可能性があるのは、まさにこの種の根本的な想定によるものです。彼らはあなたのアプリケーションやデータに興味がないかもしれません、彼らはただ無害な「ジャンプオフ」ポイントをより価値のある標的へのより大きなまたはより複雑なハックの一部として使用したいだけかもしれません。
Webアプリを実行している通常のLAMP Webサーバー。 （例：AWS EC2 + Apache2 + MySQL + Php7）
「正常」に注意してください。設定が思ったほど普通ではないかもしれません。多くは、インストールした内容とパッケージがどのリポジトリから来たかに依存します。知っておくべきバリエーションのいくつかは次のとおりです-
分布タイプ。たとえば、Ubuntu LTSディストリビューションと非LTSディストリビューションの間には大きな違いがあります。経験則として、LTS以外のディストリビューションは通常、更新の頻度が高く、更新（または更新の確認-下記を参照）をより頻繁に実行することが重要です。
リポジトリタイプ。 Ubuntuを含むほとんどのディストリビューションには、さまざまなタイプのリポジトリーがあります。 Ubuntuが管理するコアリポジトリには、通常、かなり堅牢なテストサイクルを経て、かなりタイムリーに更新を受け取ります。次に、コア配布チームによって保守されていない「contrib」タイプのリポジトリがあります。これらは、サードパーティのパートナー、他のユーザー、または開発グループです。これらのリポジトリが何に重点を置いているかは大きく異なります。時々、彼らはセキュリティに重点を置き、安定性に重点を置きますが、セキュリティよりも安定性に重点を置く人もいます。ソフトウェアをインストールしたリポジトリを理解することが重要です。
インストールされているものを知っています。あまりにも頻繁に、セキュリティが侵害されて見落とされたパッケージで発生した侵害を発見したという話を耳にします-デフォルトでインストールされたものか、LAMPスタックに必要なもののいずれかですが、あなたが深く埋め込んだまたは微妙な依存関係ではありません知っている。不要なパッケージ（特に、いくつかのパッケージに異常な依存関係があるため、判別が難しいもの）を削除したことを確認してください。
補助図書館。インストールされているが、aptエコシステムによって管理されていない追加のライブラリを見落とすことがよくあります。たとえば、PHPライブラリは、ディストリビューションの標準ロードに含まれていない、または他の依存関係のためにシステム上に構築する必要のある特別な目的に必要でした。一般的な例は、商用データベース用のPHPデータベースドライバーです。前回PHPベースのスタックを管理する必要があったときから状況は改善されたようですが、OracleのPHPドライバーをビルドする必要があったときのことを思い出すことができます。プロセスは比較的簡単なものでしたが、依存ライブラリがアップグレードされた後、ライブラリがパッチされたバージョンにリンクされていることを確認するために、そのドライバを再構築することを忘れないでください。これは、openSSLなどの問題にもなります。ディストリビューションはアップグレードされたバージョンの共有ライブラリをインストールする場合がありますが、アプリケーションが実際に既知の脆弱性を持つ古いライブラリではなく、アップグレードされたライブラリを使用していることを確認するために、追加のアクションが必要になる場合があります。
更新を毎日チェックしてから、これらの更新を確認して、システムの破壊の重要性と可能性を評価する必要があります。 Ubuntuのapt-updateプロセスはかなり堅牢で、問題が発生することはほとんどありませんが、ときどき発生します。特にLTSバージョンの場合、安定性が重視されるため、更新プロセスは慎重になる傾向があるため、apt-getアップグレードを実行するだけでなく、確認する必要があります。たとえば、依存関係の問題や不安定性や破損が発生する可能性があるため、「dist-upgrade」を実行する必要がある場合があります。 Ubuntuは、注意を払う必要があることを明確にする方法として意図的にこれを行います。つまり、apt-getのアップグレードは、問題を壊さないように信頼できますが、すべてのセキュリティ修正をインストールしない場合があります。 apt-get dist-upgradeは、すべてのセキュリティ更新が確実に適用されるように働きますが、問題が発生する可能性があるため、管理者はさらに注意する必要があります。
残念なことに、ここには実際のショートカットはありません。現実には、開発者と専任管理者の両方を雇用する余裕がない中小企業で働いている開発者がいる不完全な状況にいるのです。限られたリソースをビジネスへのリスクを最小化する方法で適用し、ビジネスがこれらのリスクが何であるかを理解し、可能性と結果を理解することを保証する必要があります。 。最善を願っていますが、悪いことを計画していることを確認してください。信頼できるテスト済みのバックアップを用意します。更新プログラムを適用する前に、更新プログラムが何を行うかを理解してください。セキュリティリストを監視して、新たに出現する脅威を認識し、危険性を評価し、ログを確認して想定を確認します。毎日更新を確認します。更新を毎日適用しないことを決定することは非常に正当ですが、更新とは何か、パッチが何であるかを評価し、情報に基づいて決定を行うことができるようになった後にのみです。
上記の点に関連して、ソーシャルエンジニアリングやWebアプリ自体は安全ではありません。
あなたが知っていると知っていると信じることは、世界を分けることができます。セキュリティアセスメントで気づかなかった脆弱性が判明した回数を失いました。 PHP（またはその他の関連するレイヤー）にはまだ発見されていない脆弱性が存在する可能性が高いです。セキュリティの専門家がアプリケーションを評価するとき、彼らはそれが安全であることを決して表明しません。彼らは脆弱性が検出されなかったと言いますが、それは存在しないことを意味しません。
これは間違いなく良い方法であり、サーバーのセキュリティルーチンの一部である必要があります。セキュリティプランでこれ以上のことを行う必要があるかどうかは言いがたいですが、これを基盤としていない優れたセキュリティプランを見たことはありません。
インストールされたソフトウェアやサービスにパッチを適用しないと、セキュリティ上のリスクが高くなります。これらのパッケージで発見されたバグや脆弱性は、悪用によってボックスへの完全なアクセスをもたらすことが多いためです。それは、攻撃者が試みる最初の、最初ではないにしても、1つのことです。
しかし、システムの設定ミスも、攻撃者がシステムを侵害する主な方法の1つです。ソフトウェアにパッチを当てるだけでは、必ずしも設定ミスが修正されるわけではありません。時々それが起こりますが、それはアプリの最初のインストールによって設定ミスが生まれたためです。
注目すべき点の1つは、サービスのいずれかがrootとして実行されているかどうかです。それが良い考えであるケースは多くありませんが、サービスをrootとして実行しているのは、それをインストールした人がそれ以上のことを知らなかったか、非サービスとして実行することができなかったためです。 rootユーザー。それはほんの一例です。
使用されているオペレーティングシステムが何であれ、OSを強化する方法についてはベストプラクティスがあります。そこから始めて、MySql、Apacheなど、インストールされているすべてのサービス/パッケージを具体的に強化します。
展開中にOSとすべてのサービスがベストプラクティスに従って明確に実行された場合、その後はパッチの適用のみが必要になる可能性があります。
それはまだ確実ではないので、私はおそらく言う。それは、変更プロセスと、プロセスが適切なセキュリティの維持に対応しているかどうかに依存します。提案された変更はセキュリティのために精査されていますか？チェックアウトにはセキュリティ固有のテストが含まれていますか？これらの質問に対する答えは通常ノーであり、したがって、管理者によるミスが発生し、捕捉されない可能性があります。
基本的に、Webサーバーを安全に保つことはできません。ゼロデイエクスプロイトがあり、発見から数時間以内に修正される可能性がありますが、それまでにすでにエクスプロイトされています。優れたホスティング会社は、そのような脅威に対して非常にタイムリーに行動できるかもしれません。ただし、管理対象サーバーは高価です（ホスティング業者の管理スタッフは何の価値もないと仮定します）。ただし、現在の脅威を排除するためにこれが必要であると判断した場合、サーバーをオフラインにすることを決定し、可用性ではなく安全性を優先する-これは間違っている可能性があるあなたが常に箱を上げて応答性を必要とするならば、一種の安全性。 1時間の停止でどれだけのお金といくつの命を失うのですか？
データ漏洩は他の場所でも発生する可能性があります。バックアップは安全に保管されていますか？ （リモートアクセスおよび物理アクセスから保護します。1つのケースでは、ライブWebサイトからではなく、バックアップからのデータ漏出を実証することができました）誰かがサーバールームに侵入するのは簡単ですか？ Lex Luthorのような超犯罪者が直接あなたを攻撃する必要はありません（結局のところ、彼は40のケーキの直後です）、あなたは副次的な被害を受ける可能性があります。そして、はい、私は秘密のサーバーファームを見ました（ケース1：誤ったドアを誤って開いた、どうやら一部の馬鹿はロックを忘れてしまった、他の馬鹿は外側にドアハンドルを置くことに決めた、ケース2：知りたい平方メートルでスペースをとることができるいくつかの共有ストレージ施設で、チップボードの後ろから非常に多くの冷たい熱があった理由）。理論的には、専門の会社が運営し、実際には...まあ。チャンスをつかみ、いくつかのサーバーまたはドライブを持ち上げ、eBayで販売し、その後幸運を祈る人もいます。
見落とされがちなのは、インフラストラクチャに対するリモート攻撃です。厳密に言えば、これはサーバーのセキュリティレベルとは関係ありませんが、誰かが管理インフラストラクチャまたはapt-get更新用のソフトウェアパッケージを提供するプロキシを攻撃した場合、セキュリティは依然として何らかの形で低下します..。はい、一部の人々は楽しみのためにそのようなことをします。
AWS EC2はそのようなシナリオに関してかなり安全であると思いますが、AWS EC2は例としてのみ提供されており、OPの質問の事実ではありません（Webアプリケーション自体は安全であるというステートメントとは異なり、これはおそらくSQLインジェクションなどに関するすべての戦争の話を議論しないようにしてください）。