Hardening Apache 、 Hardening PHP および Securing SSH については、すでにここで質問があります。
この傾向を続けるために、私は人々がLinuxサーバーを強化するためにどのような措置をとるかに興味があります。新しいサーバーをセットアップするとき、人々は常にどのような手順を踏むのかと同様に、それはアプリケーション固有ではありません。 tmpパーティションをnoexecに設定したり、特定のサービスをアンインストール/無効化したりするなど。
必要なアプリケーションとプロセスを特定し、チェックリストを適用して、それらのインストールを回避するか、最悪の場合、最初のビルド後にそれらをアンインストールします。
ここで私は、デフォルトでまだ非常に多くのディストリビューションに進んでいるように見えるそれらの一般的な犯人を考えています!
次のステップは潜在的な脆弱なサービスを通過し、それらへのアクセスを制限することです
「Linuxサーバー」スペースには、巨大な ディストリビューションの範囲 が含まれ、それぞれに独自のデフォルトの構成更新戦略、パッケージ管理ツールチェーン、およびデフォルトのサービスとオープンポートへのアプローチがあります。また、幅広い展開シナリオがあります。Webサーバーの強化は、Linuxベースのルーターの強化とはかなり異なります。最も気になるディストリビューションとユースケースについて尋ねることで、より良いアドバイスを得ることができます。
その意味で、私はここでUbuntuセキュリティに関連するソースをポイントすることで対処しますが、これの多くは他の状況で役立ちます。
良い紹介はここにあります: http://www.andrewault.net/2010/05/17/securing-an-ubuntu-server/
コミュニティは、ユーザビリティが影響を受けている場合でもセキュリティに重点を置くいくつかのより厳しいデフォルトと強化のヒントをここで説明しています: https://help.ubuntu.com/community/StricterDefaults
ここに、Ubuntuのセキュリティ機能のマトリックスと概要を示します。他の場所で見つけたチェックリストの調査に役立ちます。 https://wiki.ubuntu.com/Security/Features
いくつかのテストを自分で実行する方法を確認するには、 http://people.canonical.com/~kees/demo/ec2-session.log のトランスクリプトを確認してください。 http://people.canonical.com/~kees/demo/
何をするために必要なものの概要: https://wiki.ubuntu.com/Security/Privileges
Ubuntuのセキュリティチームのwikiには、他にもいくつか便利なものがあります。 https://wiki.ubuntu.com/Security/
ポイントインタイムシステムの強化は有益な偉業ですが、サーバーを安全に展開することを本当に定義するのは、maintain that state。
サーバーのセキュリティを強化し、セットアップに意味のある変更を適用するために推奨される構成変更の詳細を示す品質チェックリスト(以下のリンクを参照)を選択してください。さらに良いことに、 Puppet ( http://www.puppetlabs.com/ )を介して推奨事項をコード化します。これは双方にメリットがあり、安全に展開できます。強化された構成を長期にわたって維持するための戦いのチャンスです。
ボーナス:攻撃モデリング/脅威モデリングを実行します( http://taosecurity.blogspot.com/2007/06/threat-model-vs- attack-model.html )防御的な努力に集中します。たとえば、次のような質問をします。
攻撃者はどのようにしてこれらのサーバーにアクセスできますか?
彼らの成功の可能性を減らすために私ができることは何ですか?
2番目の質問への回答を特定の構成変更(強化)に変換するか、追加のコントロールを実装します。もちろん、ゲームは1つの脅威が成功する可能性を最小限に抑えることです。これには時間がかかりますが、行った変更と、なぜ誰かがそれを行うのが良いと言ったために無計画に変更を行ったのかを理解することができます。
ロギングとレビューで素晴らしいを得ます。防止は常に失敗します。この現実に対抗するには、ロギングを強化して、インシデントをより迅速に特定して対応し、より迅速に回復できるようにします。 Linuxで防御を強化し、ロギングを強化するための私のお気に入りのツールは、 [〜#〜] ossec [〜#〜] ( http://www.ossec.net/ )です。 [〜#〜] ossec [〜#〜] に含まれているルールのカスタマイズに余分な時間を費やすことは、価値のあるアクティビティです(たとえば、アラートする追加のディレクトリとファイルを一覧表示する)それらが変更された場合、ルールを追加するか、既存のルールの重大度を上げて認証の異常を警告し、mysqlユーザーテーブルへの変更を監視するルールを追加します( http://blog.rootshell.be/2011/01/ 07/auditing-mysql-db-integrity-with-ossec / )、ad infininitum)。 Richard BejtlichがSeven cool open source projects for defenders( http://taosecurity.blogspot.com/2011/01/seven-cool-open-source)というタイトルのタイムリーなブログエントリを投稿しました-projects-for.html )
サーバー防御の継続的な検証をサポートするために、インターネットセンターで継続的に Nessus ( http://www.nessus.org/nessus/ )を実行できます。セキュリティ(CIS)Linux監査テンプレート。結果をベースラインとして使用し、変更を監視し、発見された弱点を修正します。
要約すると:
1)既存の尊重されているセキュリティ強化チェックリストを利用して、環境に適したカスタムチェックリストを作成できるようにします(できれば攻撃/脅威のモデリングアクティビティを実行し、構成管理フレームワークを選択した後)。
2)監視機能の強化:ロギングの強化(つまり、監視するアクティビティに十分なログを生成するようにシステムを調整)、HIDSを展開します(例: [〜#〜] ossec [〜#〜] )、展開ログ分析ツール(例: logwatch - http://sourceforge.net/projects/logwatch/ )、おそらくネットワークフローをキャプチャ(例: softflowd )
3)システムの熱心な擁護者になることを誰かの責任にする
4)継続的に監査とテストを行い、実行していると思われることが実行されていることを確認します。
ベンチマーク/チェックリストリソース:。
http://cisecurity.org/ Center for Internet Security(CIS)は、非営利企業であり、そのベンチマークおよびメトリック部門は、不十分な技術的セキュリティに起因するビジネスおよびeコマースの混乱のリスクを軽減するのに役立ちます。コントロール。この部門は、企業にセキュリティ構成のコンセンサスベストプラクティス標準を提供するとともに、情報セキュリティステータスを測定し、セキュリティ投資に関する合理的な意思決定を行うためのリソースを提供します。
http://iase.disa.mil/stigs/checklist/ 国防情報システム局(DISA)
http://web.nvd.nist.gov/view/ncp/repository
http://csrc.nist.gov/fdcc/faq-common_security_configurations.html
NISTによって定義された全国チェックリストプログラム(NCP)SP 800-70 Rev. 1は、公的に利用可能なセキュリティチェックリスト(またはベンチマーク)の米国政府リポジトリであり、オペレーティングシステムとアプリケーションのセキュリティ構成の設定に関する詳細な低レベルのガイダンス。
Sansのチェックリスト から始めるよりもはるかに悪いことができます。
これに対する私の唯一の批判は、展開されたシステムのセキュリティの管理に特に重点が置かれていないことです。特に、ベンダーパッチが最新であることの確認、適切なアクセス許可モデルの計画、IDS例外レポートの管理などです。
まず、サーバーの目的と、防御しようとしている脅威モデルを理解する必要があります。使い捨てサーバーですか?複数のユーザーがアクセスできますか?複数のユーザーがアクセスできる場合、それらすべてを信頼しますか、そうではありませんか?
このサーバーはネットワークサービスにのみ使用され、マシンにアカウントを持っている誰かからの攻撃の脅威に対処する必要がないと仮定します。これが私が取るステップです:
ファイアウォールを有効にします。iptables
を使用してローカルファイアウォールを設定します。 default-denyポリシーを使用しています。ファイアウォールポリシーで明示的に許可されていない限り、すべての着信接続はデフォルトでブロックされます。世界にエクスポートすることを目的としたサービスへの着信接続を有効にします(たとえば、これがメールサーバーの場合はポート25、これがWebサーバーの場合はポート80/443など)。 iptables
はステートフルフィルタリングを強力にサポートしているため、接続が確立されると、その接続に関連付けられているすべてのパケットが許可されます。
すべてのパッケージをアップグレードし、自動更新を有効にします。Linuxディストリビューションをすべてのパッケージの最新バージョン(Fedoraではyum upgrade
)に更新しますが、構成に適したものは何でも)。また、1日に1回更新を自動的に取得してインストールするようにcronスクリプトを設定しました(Fedoraではyum -y upgrade
)。更新によって一部のサービスが中断されるリスクがあるため、経験豊富なシステム管理者の中には自動更新を勧めない人もいることを理解しています。古くなったパッケージによるセキュリティ侵害のリスクとそのリスクを比較検討する必要があります。個人的には、自動更新の使いやすさと便利さはサービスが壊れるリスクに見合う価値があると思いますが、これはすべての運用設定において正しい答えではないかもしれません。
SELinuxを有効にします。SELinuxは、公開されたサービスに対する攻撃に対する第2層の防御を提供します。それは時々少し苦痛になるかもしれません(それは時々私に問題を引き起こし、デバッグするのが難しい方法でサービスを壊します)が、セキュリティが重要な設定では、それは価値があると思います。
リモート管理用にSSHをセットアップします。SSHをセットアップして、マシンをリモート管理できるようにする必要があります。クライアント側でDSA秘密鍵を生成し、パスフレーズで暗号化し、対応する公開鍵をサーバーのauthorized_keysファイルにインストールして、秘密鍵を使用してログインすることをお勧めします。サーバーのsshd_config
構成ファイルもカスタマイズすることができます。 PasswordAuthenticationを無効にし、公開鍵を使用してログインするよう要求することを検討してください。パスワード認証は、秘密鍵に問題が発生した場合に役立つフォールバックですが、人間は推測可能なパスワードを選択することが多いため、リスクも大きくなります。非常に高品質のパスワードを選択するために信頼できないシステム上の他のユーザーがいる場合、PasswordAuthenticationを無効にすることができます。それがあなただけで、すべてのパスワードの信頼性が非常に高い場合は、有効のままにしておくことができます。 rootがSSH経由でログインするのを妨げませんが、違った感じになるかもしれません。
複数のシステム管理者がいる場合は、それらのアカウントを設定します。それぞれにSudo
アクセス権を与えるか、個別のrootアカウントを設定します各システム管理者用。
DNSSECを有効にします。DNSスプーフィングのリスクを減らすために、可能な限りDNSSECでホスト名を検証するローカルキャッシングDNSサーバーを実行するようにサーバーを構成します。
次に、世界に公開されているサービスごとに、そのサービスを保護するための予防策を講じます。たとえば、暗号化(メールサーバーのSTARTTLSなど)とchrootまたはサンドボックスサーバーを可能な限り有効にします。ただし、詳細はサービスごとに異なります。したがって、実行するサービスごとに個別の質問を送信し、そのサービスをロックする方法についてアドバイスを求めることをお勧めします。
すでにかなりの強化が適用されているLinuxディストリビューションを探している場合は、 Openwall Linux を強くお勧めします。
(コメント:サーバーで信頼できないユーザーを指定すると、セキュリティを強化することがはるかに難しくなります。攻撃対象領域がはるかに大きくなります。それが問題である場合は、別の方法で自分をロックする方法について質問することをお勧めしますサーバー上のアカウントを持つローカルユーザーによる攻撃から保護するためのサーバー。これを行うための一連の手法はまったく異なります。)
そして、Grsecurity/PAXカーネルパッチはどうですか?これらには、カーネルレベルでサーバーを強化するための非常に素晴らしい機能が含まれています。
概要:
Red Hatの場合、NSAは強化に関するアドバイスを提供します。 Red Hat Enterprise Linux 5の構成ガイダンス-NSA/CSS 。
これらはCentOSやその他の派生物にも役立つはずです。
RHELの場合、 Center for Internet Security の CIS Red Hat Enterprise Linux 5ベンチマーク は適切なリソースのように見えます。
あなたがすでにより大きな問題を抱えているよりも、不要なパッケージ/サービスをアンインストールすることによってシステムを保護しようとしている場合。これらのパッケージは、最初からインストールされているべきではありません。
最小限のシステムをインストールし、本当に必要なパッケージのみを追加する必要があります。同じことがカーネルにも当てはまります。必要な機能のみを備えた独自のカーネルをコンパイルします。すべてをサポートするディストリビューションカーネルを使用しないでください(とにかく95%は必要ありません)。