私は、「ライブ」のインターネットに面した Web サーバーを保護または構成することについて本当に何も知りません。オペレーティング システムのインストール (および Windows の更新) 以外は、何もしていません。Microsoft や Web からいくつかのガイドを読みましたが、どれも包括的で最新のものではないようです。グーグルは私を裏切りました。
MVC ASP.NET サイトをデプロイします。
新しい Windows サーバーにアプリケーションを展開する準備をしているときに、個人的にチェックすることは何ですか?
これが私たちのすべてです：
Windows ファイアウォールが有効になっていることを確認します。「デフォルトでオフ」のポリシーがあるため、すぐに使用できるルールの設定はかなり安全です。ただし、追加のルールが必要ないことがわかっている場合は、それらのルールを無効にしても問題はありません。公共のインターネット インターフェイスで HTTP を除くほとんどすべてを無効にしますが、Ping が好きなので (Ping が嫌いな人はいますか?)、次のように手動で有効にします。
netsh firewall set icmpsetting 8
管理者アカウントを無効にします。セットアップが完了したら、自分の名前付きアカウントの管理者権限を付与します。デフォルトの管理者アカウントを無効にすると、誰かがハッキングする可能性を (わずかではありますが) 減らすことができます。(もう 1 つの一般的なデフォルト アカウントである Guest は、デフォルトで既に無効になっています。)
管理者権限を持つアカウントでサービスを実行することは避けてください。最近の評判の良いソフトウェアのほとんどは、これについてかなり優れていますが、チェックするのは決して悪いことではありません。たとえば、元のサーバー設定では、Cruise Control サービスに管理者権限がありました。新しいサーバーで再構築したときは、通常のアカウントを使用しました。これは少し手間がかかります (一度にすべてではなく、作業を行うために必要な権限のみを付与する必要があります) が、はるかに安全です。
数年前にロックダウンしなければなりませんでした...
システム管理者として、プロジェクトの早い段階で開発者に関与してください。Web アプリのテスト、展開、運用、保守は SDLC の一部です。
これらのガイドラインは、Linux または Windows の OS に関係なく、一般にすべての DMZ ホストに適用されます。
IIS7 の管理と強化に関する本がいくつかありますが、要約すると次のようになります。
1、システムを踏み台ホストとして扱います。OS をロックダウンし、攻撃面を減らします (サービス、インストールされたアプリのポート、つまり対話型のユーザーや混合ワークロードはなく、指定された管理 DMZ または内部ホストにのみ応答するようにファイアウォール RPC を構成します)。ssh、OOB、管理 LAN アクセス、および AIDE tripwire や osiris などのホスト IDS ベリファイアを検討してください。Web サーバーが機密性の高い場合は、IIS/FW ログに加えて、argus を使用してトラフィック パターンを監視および記録することを検討してください。
システム構成のベースラインを作成し、ベースラインに対して定期的に監査を行い、変更を最小限に抑えるか制御して、これを正確に保ちます。それを自動化します。powershell はあなたの友達です。
米国 NIST は、国家チェックリスト プログラム リポジトリを維持しています。NIST、NSA、および CIS には、以前のバージョンのものであっても、調査する価値のある OS および Web サーバーのチェックリストがあります。構成の提案については、Apache チェックリストも参照してください。addison wesley と OReilly の Apache セキュリティ ブックを参照して、問題を把握してください。
http://checklists.nist.gov/ncp.cfm?prod_category://checklists.nist.gov/ncp.cfm?prod_category http://www.nsa.gov/ia/guidance/security_configuration_guides/web_server_and_browser_guides.shtml www. cisecurity.org は、サブスクライバー向けのチェックリストとベンチマーク ツールを提供しています。最低でも7か8を目指してください。
http://blogs.iis.net/は IIS チームのブログです。補足として、Windows を使用している場合は、使用している MS 製品グループのチーム ブログを常にお読みください。
David Litchfield は、DB と Web アプリの強化に関する書籍を何冊か執筆しています。彼は聞くべき人です。彼のブログを読んでください。
あなたの開発者が Web セキュリティとシステム管理者についての穏やかな紹介 (またはリマインダー) を必要としているなら! 私は Sverre Huseby の "Innocent code" をお勧めします。有用なルールと原則を規定し、物事をゼロから説明します。その優れた強力なアクセス可能な読み取り
もうベースラインを作成して監査しましたか? (変更を加えると、新しいベースラインが作成されます)。
IIS はメタ サービス (FTP.SMTP およびその他のサービスはその下で実行される) であることを思い出してください。生活を楽にし、1 つのボックスで一度にサービスを実行します。IIS メタベースをバックアップします。Tomcat や jboss などのアプリ サーバーを同じボックスにインストールする場合は、それらもセキュリティで保護され、ロックされていることを確認してください。IIS を含むこれらのアプリケーションに対して Web 管理コンソールをセキュリティで保護します。ボックスにもDBが必要な場合。この投稿は同様の方法で活用できます
logging.an 監視されていない公開サーバー (http、imap smtp など) は、専門的な失敗です。ログを確認してそれらをRDMSに送り込み、速いものと遅いもの、厄介なものを探します。ほとんどの場合、脅威は自動化され、骨抜きにされます。可能な場合は、ファイアウォール レベルでそれらを停止します。
許可を得て、P0f と nikto を使用してボックスをスキャンし、フィンガープリントを取得します。Selenium でアプリをテストします。IISおよびすべてのアプリケーションによって、Web サーバーのエラーが慎重かつ制御された方法で処理されるようにします。、3xx、4xx、および 5xx 応答コードのセットアップ エラー ドキュメント。
これですべての作業が完了し、お尻をカバーして、アプリケーション/Web サイトの脆弱性を調べることができます。開発者には優しくしてください。ほとんどの場合、違反や評判/信頼の損害が発生した後にのみこれについて心配します。馬はボルトで固定され、長い間行方不明になっています。今すぐこれに対処してください。それは安価です。脅威ツリーについて開発者に相談してください。
Dos および DDoS 攻撃への対応を検討してください。プラス面では、良好なトラフィック/スラッシュドットと容量の問題を検討してください。開発者やマーケティングと連絡を取り、キャンペーンや新しいサービスの販売に応じて、キャパシティの問題やサーバー/帯域幅のプロビジョニングを処理します。どのような種類のキャンペーンの反応を期待するか (またはリマインドするか) を尋ねてください。プロビジョニングを可能にする十分なリードタイムを前もって計画してください。ネットワークの担当者と友達になって、帯域幅のプロビジョニングについてすぐに話し合うようにしてください。パフォーマンスの低下またはプロビジョニング不足による構成ミスによる利用不能も問題です。 .. システムのパフォーマンス、ディスク、RAM の http および db リクエストを監視する. 通常のパフォーマンスと予想されるパフォーマンスの指標を把握する.. (神様、IIS 用の apachetop はありますか? ;)) 適切な容量を計画します。
この間、あなたは自問するかもしれません：「私は偏執的すぎますか？」. 間違った質問..「私は十分に妄想的ですか?」です。常にセキュリティ曲線の後ろにいること、およびこのリストが網羅的に見えるかもしれないことを覚えて受け入れてください。これはほんの始まりにすぎません。上記のすべては慎重かつ勤勉であり、決して過剰と見なされるべきではありません.
Web サーバーがハッキングされるのは、山火事 (ここでは山火事) のようなもので、ブルー ムーン イベントを除いて、準備することができ、ほぼすべてのことを処理してくれます。改ざんなどをどのように監視し、対応するかを計画します。
セキュリティの悪党やセキュリティのダレク/チキンリトルになることは避けてください。静かに作業し、利害関係者やプロジェクトの同僚と協力してください。セキュリティはイベントではなくプロセスであり、セキュリティの改善と必要なことの受け入れという点で、段階的な見返りを得るには、それらをループに保ち、人々を優しく教育することが最善の方法です. 見下すようなことは避けてください。ただし、砂に線を引く必要がある場合は、戦いを選んでください。それを行うのは数回だけです。
あなたの最大の問題は、おそらくアプリケーションのセキュリティでしょう。アプリ プール ID はローカル管理者のグループのメンバーである必要があると開発者が言ったとしても、信じてはいけません。これは、上記の「管理者としてサービスを実行しないでください」というヒントを少しひねったものです。
その他の 2 つの注目すべき項目: 1) このシステムをバックアップする方法があることを確認します (定期的に、バックアップをテストします)。2) このシステムにパッチを適用する方法があることを確認し、理想的には、それらのパッチを本番環境に導入する前にテストします。自分の良い記憶力に頼らないようにしてください。ただし、無効にするよりも、windowsupdate を使用するようにボックスを設定してもらいたいと思います。
幸運を。ファイアウォールのヒントは非常に貴重です。有効のままにして、tcp/80 と tcp/3389 のインバウンドのみを許可します。
それに応じてロールを使用します。サービス アカウントに使用する権限が少ないほど良いです。すべてを管理者として実行しないようにしてください。
Web アプリケーションを保護しようとしている場合は、OWASPに関する情報を最新の状態に保つ必要があります。ここに宣伝文句があります。
Open Web Application Security Project (OWASP) は、501c3 非営利の世界的な慈善団体で、アプリケーション ソフトウェアのセキュリティの向上に重点を置いています。私たちの使命は、アプリケーション セキュリティを可視化して、人々や組織が真のアプリケーション セキュリティ リスクについて十分な情報に基づいた決定を下せるようにすることです。誰もが自由に OWASP に参加でき、すべての資料はフリーでオープンなソフトウェア ライセンスの下で利用できます。OWASP に関するすべては、こちらの wiki で、最新情報は OWASP ブログでご覧いただけます。お気軽に変更を加えて、サイトを改善してください。世界中の何百人もの人々が、サイトの変更をレビューして品質を確保しています。初めての方は、開始ページをご覧ください。質問やコメントは、多数あるメーリング リストの 1 つに送信してください。ここにある内容を気に入って、私たちの取り組みをサポートしたい場合は、メンバーになることを検討してください。
展開 (サーバー構成、役割など) については、特に Bob と Jeff から多くの良い提案がありました。しばらくの間、攻撃者は完全にメモリ ベースのバックドアやトロイの木馬を使用してきました。最近、サーバーのメモリを検証する新しいタイプのセキュリティ製品を開発しました(Tripwire (Bob の回答を参照) がファイルを検証する方法と同様の手法を使用)。
これはBlockWatchと呼ばれ、主にクラウド/ハイパーバイザー/VM タイプの展開で使用するために設計されていますが、抽出できる場合は物理メモリを検証することもできます。
たとえば、BlockWatch を使用して、カーネルとプロセス アドレス空間のコード セクションが期待どおり (ディスクにインストールした正当なファイル) であることを確認できます。
着信ポート 135、137、138、139、445 をファイアウォールでブロックします。組み込みのもので十分です。Windows Server 2008 は、RDP を直接使用しても ssh と同じくらい安全な最初のサーバーです。