apt-get upgrade を頻繁に実行して、Web サーバーを安全に保つのに十分ですか?

通常はトラブルに巻き込まれる多くの問題が取り除かれました (つまり、ホストしているアプリが完全に安全であると仮定して)。実用的な観点からは、これらを考慮する必要があります。

しかし、おそらくあなたはそれらを認識しているので、いくつかの保護手段を講じています.それでは、残りについて話しましょう。

最初は、おそらく「ときどき」更新を実行するべきではありません。ほとんどのディストリビューションはセキュリティ アナウンス メーリング リストを運営しており、そこで脆弱性がアナウンスされるとすぐに公開されます (まあ、その前に公開されることが多いですが、あなたの状況では、世界中のすべてのセキュリティ リストを実際に監視することはできません)。これらはトラフィックの少ないリストであるため、実際にディストリビューションを購読し、そこから通知を受け取ったらアップグレードする必要があります.

多くの場合、メンテナーは兆候を実際に探しているわけではないため、さりげなくメンテナンスされているサーバーは、長期間にわたってブルート フォースまたは辞書攻撃を受ける可能性があります。その場合は、通常の対策 (ssh パスワード認証なし、ssh と apache での fail2ban) を適用し、理想的には疑わしいアクティビティが発生したときに監視アラートを設定することをお勧めします。それがメンテナンス (時間) の予算を超えている場合は、定期的にログインしてそれらを手動で確認する習慣をつけてください。

従来、セキュリティの一部とは考えられていませんでしたが、新しいサーバーをすばやく起動できるようにしたいと考えています。これは、サーバー構成スクリプト (Ansible、Chef などのツールはいずれにしてもシステム管理に役立ちます) と、テスト済みの自動バックアップ システムを意味します。サーバーが侵害された場合、永久に侵害されたと想定して消去する必要があります。データの定期的なバックアップを取っていない場合、それは最悪です.

いいえ。これは違う 安全を確保するのに十分です。

しばらくはセキュリティを確保できますが、セキュリティは複雑でペースが速いため、長期的なセキュリティには十分ではありません .もし皆があなたの質問と同じ仮説を立てていたら、今ではインターネットは 1 つの大きなボットネットになっていたでしょう.

いいえ、この質問をパッケージに限定しないでください。サーバーのセキュリティを全体的に見てみましょう。これを読んでいる人なら誰でも、実際にどれだけの要素が動いているかがわかります。

• APT (Ubuntu のリポジトリなど) は、ソフトウェア スタックの一部のみをカバーします。 (たとえば) Wordpress やその他の一般的な PHP ライブラリを使用していて、それがレポ管理されていない場合は、それも更新する必要があります。より大きなフレームワークには、これを自動化するメカニズムがありますが、常にうまくいくとは限らないため、バックアップを取り、サービスの状態を監視していることを確認してください。

• すべて自分で書いたので、スクリプト キディから安全だと思いますか?自動化された SQL インジェクションと XSS エクスプロイト ボットが走り回っており、すべてのクエリ文字列とフォームを同じように突っ込んでいます。

  これは、実際には、優れたフレームワークが、これらの攻撃のニュアンスを理解しない不十分なプログラマーから保護するのに役立つ場所の 1 つです。有能なプログラマーにコードを監査してもらうことも、ここでの不安を和らげるのに役立ちます。

• PHP (または Python、または実行しているもの) は、本当にどこにでも書き込みできる必要がありますか? 構成を強化 多くの攻撃を軽減します。理想的には、ウェブアプリができる唯一の場所 書き込む場所はデータベースであり、スクリプトが実行されることのない場所です (例:静的ファイルの提供のみを許可する nginx ルール)。

  PHP のデフォルト (少なくとも人々がそれらを使用する方法) により、PHP は webroot のどこでも PHP を読み書きできます。これは、Web サイトが悪用された場合に深刻な影響を及ぼします。

• そして、更新スケジュールは積極的に有害です。 「たまに」って一体何？重大なリモート セキュリティ バグの半減期は短いですが、0 日からパッチが利用可能になるまでにはすでに遅延があり、一部のエクスプロイトはパッチからリバース エンジニアリングされています (スローポークをキャッチするため)。

  月に 1 回だけ更新プログラムを適用している場合は、悪用可能なソフトウェアが実際に実行されている可能性が非常に高くなります。 TL;DR:自動更新を使用してください。

• ディストリビューションのバージョンは永遠に続くわけではありません。賢明で Ubuntu の LTS バージョンを選択した場合、最初のリリースから 5 年間の猶予があります。その時間内にさらに 2 つの LTS バージョンが公開され、選択肢が提供されます。

  「新しい方が良い」という暴挙に出て、サーバーをセットアップしたときに 16.10 を使用した場合、9 か月の猶予があります。 .うん。その後、18.04 LTS でリラックスできるようになる前に、17.04、17.10 にアップグレードする必要があります。

  お使いの Ubuntu のバージョンが失効した場合、1 日中 dist-upgrade できますが、セキュリティ アップグレードは得られません。

• また、LAMP スタック自体は、標準の Web サーバーに対する唯一の攻撃ベクトルではありません。

  • する必要がある SSH 構成を強化する:のみ SSH キーを使用し、パスワードを無効にし、ポートを回避し、ルート ログインを無効にし、総当たり攻撃を監視し、fail2ban でそれらをブロックします。 .
  • ufw を使用して他のサービスをファイアウォールで遮断する (その他)
  • データベースを公開しないでください (必要 でない限り) し、ファイアウォールで着信 IP をロックダウンします)。
  • ランダムな PHP スクリプトをインストールしたままにしないでください。 それらを忘れれば、そうする ハッキングされる

• あなたの説明には監視はありません。あなたは盲目です。そこに何かが入り込み、スパムを送り出したり、ウェブページに感染したりした場合、何か悪いことが起こったとどのように判断できますか? プロセス監視。 git に対する定期的なファイル比較 (サーバーからの読み取り専用アクセスであることを確認してください)。

• ISP のセキュリティ (物理的およびリモート) を考慮してください。 10 セント硬貨の「ホスト」 (別名 CPanel パイレーツ) は、月額 2 ドルの無制限のホスティング プランを使い果たして、専用サーバー施設と同じリソースをセキュリティに投資しているのでしょうか?周りの人に聞いて、侵害の履歴を調査してください。

• そして、あなた .これらすべてをコーディングするコンピューターのセキュリティは、サーバーとほぼ同じくらい重要です。同じパスワードを使用する場合は、責任があります。 SSH キーを物理的な FIDO-UF2 キーで保護します。

私は約 15 年間 DevOps を行ってきましたが、 仕事で学ぶことができるものですが、サーバー全体を台無しにし、作業成果物を駆除するために数週間の作業を引き起こすには、1 回の侵害 (1 人のティーンエイジャーと 1 つのボット) だけが必要です。

意識している 何が実行され、何が公開されているかを把握することで、自分が何をしているかについてより適切な決定を下すことができます。これが誰かがサーバーの監査プロセスを開始するのに役立つことを願っています.

しかし、平均的な Web アプリ プログラマーであるあなたが、この種のことを深く掘り下げたくない場合、サーバーを実行する必要がありますか? それは深刻な質問です。絶対にすべきではないとは言いませんが、これらすべてを無視した場合、サーバーがハッキングされ、クライアントがお金を失い、個人の顧客情報 (請求データなど) を公開し、訴えられた場合、あなたはどうなりますか? ?そのレベルの損失と賠償責任に対する保険に加入していますか?

しかし、これが、マネージド サービスがダム サーバーよりもはるかにコストがかかる理由です。

バックアップのおかげで...

完全なシステム バックアップは、セキュリティのために維持できる最悪のものである可能性があります。 — ハッキングされた場合に使用したくなるからです。彼らの唯一の場所は、ハードウェア障害からの回復です。

ハッキングでそれらを使用する際の問題は、さらに以前の時点にリセットすることです.スタックのさらに多くの欠陥が明らかになり、さらに多くのエクスプロイトがあなたを陥れた穴に存在します. そのサーバーをオンラインに戻すと、すぐにハッキングされる可能性があります。 着信トラフィックをファイアウォールで遮断し、パッケージのアップグレードを行うことができます。可能性があります 助けてくれますが、この時点では、何があなたを襲ったのか、いつあなたを襲ったのかはまだわかりません.あなたが見た症状 (ページへの広告挿入、メールでのスパムのバウンス) に基づいて、すべての仮定を立てています。ハッキングはその数か月前に行われた可能性があります。

それらは明らかに何もないよりはましであり、ディスクが死んでしまった場合でも問題ありませんが、繰り返しになりますが、セキュリティにとってゴミです。 .

優れたバックアップはレシピです

サイト全体をまったく新しいサーバーに復元する方法を誰かに案内できる、平易な文書または Ansible/Puppet/Chef ルーチンのような技術的な何かが必要です。考慮事項:

• インストールするパッケージのリスト
• 行う構成変更のリスト
• バージョン管理からウェブサイトのソースを復元する方法
• データベース ダンプ*、およびバージョン管理されていないその他の静的ファイルを復元する方法

これは個人的なバックアップとしても機能するため、ここで詳しく説明できるほど、より良い結果が得られます。 . 私ならクライアントは知っている 死ぬ、彼らはテスト済み 直接管理しているハードウェアにサイトを復元する計画を立てています。

適切なスクリプトによる復元には、5 分もかかりません。そのため、スクリプト化された復元とディスク イメージの復元の間の時間差も最小限に抑えられます。

サーバーを維持する可能性は高く ほとんど 更新を頻繁に実行する場合は安全です (つまり、「時々」ではなく、少なくとも毎日)。

ただし、Shellshock や ImageTragick などの重大なバグがときどき発生します。また、安全でないサーバー構成は、攻撃を可能にする可能性があります。これは、定期的な更新を実行するだけでなく、次のようなアクションも実行する必要があることを意味します:

• 最小限のシステムを実行することで攻撃対象領域を減らします。つまり、不要なソフトウェアをインストールしない
• 外部からアクセスできるサービスを制限することで攻撃対象領域を減らします。つまり、パスワード ベースの SSH ログインを許可しない (キー ベースのみ)、不要なサービスを実行しないなど
• 重要な更新の影響を理解していることを確認してください
• システムが攻撃されることを予期し、影響を軽減しようとします。たとえば、chroot、jail、またはコンテナー内で外部からアクセスできるサービスを実行することにより、影響を軽減しようとします
• 失敗したログインなどの重要なイベントを記録し、ログを理解し、実際にログを分析する

それでも、最もよく使用される最初の攻撃ベクトルは、Wordpress やその他の CMS などの安全でない Web アプリケーションである可能性があります。しかし、Web アプリケーションは完全に安全であると想定していたので、実際に安全であることを願っています.