潜在的に敵対的なネットワーク上のActiveDirectoryドメインの保護
ActiveDirectoryはWindowsServerの最高の機能の1つですが、大きな輝かしいターゲットでもあります。侵害された場合、攻撃者にWindowsネットワークを提供します。
外部に面したWindowsサーバー（私の場合はWebサーバー）がある環境では、Active Directoryを攻撃から保護するためにどのような手順が必要ですか？ドメインメンバーが危険にさらされた場合、どのようにして被害の可能性を減らしますか？最後に、ドメインコントローラーが危険にさらされた場合に、被害の可能性を減らす方法はありますか？
特にActiveDirectory（2003および2008）に関連する情報を探しています。普遍的なベストプラクティス（ログの読み取り、安全な管理者パスワードなど）を提供する必要があります。
DCを除き、ドメイン管理者または同様の特権アカウントを使用してネットワーク上のマシンにログインしないでください。そうすれば、侵害されたシステムはあなたの資格情報を盗むことができません。
Webに面したマシンを管理するための個別の特権アカウントを持っています。
可能であれば、Webに面したマシンにネットワークレベルのファイアウォールを設置します。
可能であれば、Webに面したマシンをDMZ）にします。これは基本的に、内部ネットワークの残りの部分への接続が制限された単なるサブネットです。
ドメインコントローラーが危険にさらされた場合...厳密に言えば、ドメインはなくなり、再構築する必要があります。より実際的には、妥協の種類によって異なり、ケースバイケースで評価する必要があります。厳密に言えば「侵害された」2つのドメインを継承し、1つを再構築し、2つ目を修復しました。考慮すべき要素はたくさんあります。
これが私が使う一般的な方法です。うまくいけば、私はこれらにたくさん追加することができます：
ドメインコントローラーは、独自のネットワークセグメント上にあります。ドメインコントローラーとの間のすべてのトラフィックは、ネットワークファイアウォールを通過する必要があります。
ドメインコントローラーは、外部からアクセス可能なサービスを実行しません。
RPCポート範囲は、すべてのドメインコントローラー/メンバーで既知のポートグループに制限されています。
- 管理ツール->コンポーネントサービス->コンポーネントサービス->コンピューター
- マイコンピュータ->プロパティ->デフォルトプロトコル->コネクション型TCP/IP->プロパティ
- 追加
- ポート範囲を設定します（6051-6071など）。ネットワークが大きくなり、RPCを使用するほど、必要な範囲が広がります。 25〜30台のWindowsマシンのネットワークの場合、20個のポートで十分であることがわかりました。
- ポート範囲の割り当てとデフォルトの動的ポート割り当ての両方を「インターネット範囲」に設定します
- OK
- リブート
ドメインメンバーに、ドメインコントローラーへの次のアクセスのみを許可します（ネットワークファイアウォール、ドメインコントローラーのホストファイアウォール、およびドメインメンバーのホストファイアウォールの両方で、グループポリシーを使用してこれを実施します）。
- TCP/UDPポート53（DNS）
- TCP/UDPポート88（Kerberos）
- UDPポート123（NTP）
- TCP/UDPポート135（RPCエンドポイントマッパー）
- TCP/UDPポート137（NetBIOS）
- UDPポート138（NetBIOS）
- TCPポート139（NetBIOS）
- TCP/UDPポート389（LDAP）
- TCP/UDPポート445（SMB-over-IP）
- TCPポート3268（LDAPグローバルカタログ）
- TCP/UDPポート6051-6071（RPC-上記で選択した範囲に置き換えます）
すべてのドメインコントローラーからドメインコントローラーへのトラフィックがネットワーク経由で暗号化されるようにIPSecポリシーを設定します
グループポリシーを使用して、ホストのファイアウォールでネットワークファイアウォールルールを強化します。具体的には：
- リモートデスクトップを管理ワークステーション/ネットワークに制限する
- SNMPを管理者および監視ワークステーション/ネットワークに制限します
- アウトバウンドsyslog（私はevent-to-syslogを使用）をロギングサーバーに制限します
- アウトバウンドSMTPをメールサーバーに制限する
- 標準の「すべてのイン/アウトをサーバーが必要とするものだけに制限する」戦術
すべてのネットワークサービスをActiveDirectoryユーザーとして実行するように構成します（IISアプリは「svc-servicename」という名前のユーザーの下で実行されます）。これらのユーザーは、nerfed特権を持つ単一のグループに割り当てられ、DomainUsersグループから削除されます。
管理者アカウントの名前を別の名前に変更し、無効なゲストアカウントとして「管理者」を追加します（克服するのは簡単ですが、一部のダムスクリプトをブロックする可能性があります）。
外部に面するサーバーは、HQ/Officeマシンとは別のドメインにあります。一部のログインを簡素化するために一方向の信頼（DMZはHQを信頼）を持っていますが、これを段階的に廃止することを検討しています。
私がかつて読んだMicrosoftのベストプラクティスドキュメントでは、インターネットに直接接続するサーバー（Web、電子メールなど）は、スタンドアロンマシンにするか、企業フォレストとは別のActiveDirectoryフォレストに配置する必要があることが示唆されていました。この個別のフォレストは完全にDMZ内に存在する必要がありますが、企業のADフォレストは完全に企業ファイアウォールの最も厳しい境界内に存在する必要があります。通常の企業コンピューティングリソースよりもインターネットに接続するサーバーにアクセスする必要のあるユーザーははるかに少ないため、この方法でシステムをセットアップしても、ユーザーサポートの面で大幅な追加の管理オーバーヘッドが発生することはありません。ドメインごとに個別のユーザー名とパスワードを覚えておく必要があります。
これはやや反対の見方です。私は、学生（およびバッグの中の1〜3台のデバイス）が接続できる無線LANセグメントを備えた高等教育機関で働いています。これは私たちのインターネット境界ファイアウォールの内側にありますが、それでも、より大きなネットワークのジューシーな良さからある程度ファイアウォールで保護されています。ただし、いくつかの制約があります。
学生がラップトップから印刷できるようにするには、ドメインログインを許可する必要があります。これには、DCへの可視性が必要です。同じことがネットワーク共有にも当てはまります。さらに、学生のラップトップはドメイン化されておらず、その上にあるものを制御することもできません。
私が最初にここに着いたとき、私はこのオープンなWindowsネットワークがまったく生き残るであることに驚いた。しかし、そうしました。はい、スラマーは根絶するための王室の苦痛でした。はい、時々ハッキングされたサーバーがありました（WLAN側ではなくインターネット側から）。全体として、WLANで見られた悪意のあるウェアの量は、マシンのローカルにあるすべてのものをスキャンしてワームを回避するよりも、大量の電子メールを送信することに関心があります。
WLANと興味深いものの間には認証バリアがあり、これが役立ちます。
また、RIAAがトレンターの違反通知を送信したときに、誰がどのIPを使用していたかを確認するために、WLANログインログに永久にアクセスします。
Active Directoryのインストールを保護するためのベストプラクティスガイド を読むことをお勧めします。
信頼できないネットワークで重要だと思うこと：
- 認証トラフィック用のIPSec
- 二要素認証を使用します（スマートカードまたはチャレンジレスポンスは安価です）
- NTLMを無効にする
最初の2つの提案では、PKIサービスをセットアップする必要があります。 PKIの実装は首の痛みを伴う可能性がありますが、非常に興味深い機能を数多く提供し、信頼できない環境で効果的かつ安全に運用できるようにします。
一般的なルールとして、DCはActiveDirectory自体だけです。もちろん、常に達成できるとは限りませんが、公開される可能性のあるサービスの数を減らすことがすべてです。
pass-the-hash（PtH）およびpass-the-ticket（PtT）攻撃を理解する必要があります。これは、これらが主要な手段であるためです。攻撃者はWindowsネットワーク全体に広がります。 MicrosoftにはPtHガイダンスがありますが、セキュリティの問題にまだ精通していない場合は少し複雑になる可能性があります： https://www.Microsoft.com/en-us/download/details.aspx?id=36036
最良の方法は、Microsoftの赤い森のデザインを使用することです。赤い森は、ドメイン管理者アカウントを収容する一方向の信頼を持つ別の森です。余分な労力とサーバーが必要ですが、注意すれば、それなしで95％のメリットを得ることができます。
ADの権限を持つアカウント（ドメイン管理者、ヘルプデスクなど）は、通常のメンバーサーバーまたはワークステーションにログインしないでください。つまり、を設定する必要があります。通常のメンバーマシンにドメイン管理者やその他の特権グループを含めるためのログオン権限を拒否します。
一般に、すべての管理アクティビティは、インターネットにアクセスできず、インターネットにアクセスできるマシンへのIP接続が制限されているシステムで発生する必要があります。
明らかに、サーバーとワークステーションの管理用に別々のアカウントを持っている場合にのみ、その方法でドメイン管理者を制限できます。また、Web /電子メール用に個別の非特権アカウントを用意する必要があります。 この役割の分離は、ネットワークを保護するための重要な側面の1つです。
ドメイン管理者は、[〜＃〜]絶対に[〜＃〜]DMZシステムまたはインターネットに接続されたマシンにログインしないでください。 1つからのRDPもありません。これらのアカウント専用のワークステーションが必要であり、通常のワークステーションアカウントはAD管理ワークステーションにログインできないはずです。通常のワークステーションとAD管理ワークステーションの両方にログインできるアカウントはゼロである必要があります。これにより、攻撃者が1つのワークステーションで管理者/システム特権を取得し、その後他のワークステーションに拡散したときに、これらの高度な特権を持つ資格情報が盗まれるのを防ぎます（通常、ワークステーション管理者がログインします）。
同様に、DMZマシン専用のアカウントが必要であり、アカウントが両方にアクセスできないようにする必要があります= DMZおよび内部資産。個別のDMZドメイン（内部ドメインへの信頼の有無にかかわらず）を設定することもできます。
侵害後にADを回復することは可能ですが、絶対に正しく行う必要があります---そして明らかに、ドメインが稼働している間はダウンタイムが発生します復元され、消毒されました。侵害されたDCからの推定回復は、赤い森を実装する数日前でした。赤い森では12時間未満です。
各セキュリティ対策はソリューション全体の1つであり、残りはすべて必要であることに注意してください。これらの提案はADのセキュリティ保護に固有のものです。ネットワークをセグメント化し、適切なファイアウォール/ ACL制限を設ける必要があります。スマートカード（強く推奨）または適切なパスワードポリシーを使用して、ユーザーアカウントを適切に保護する必要があります。それでも、侵入検知、ウイルス対策、優れた外部ファイアウォール、およびWebプロキシが必要です。