こんにちは！インフラやセキュリティの世界へようこそ。技術書を開いたはいいものの、見慣れない英単語や複雑な数字の羅列に圧倒されて、「もう無理……」とそっと本を閉じそうになった経験はありませんか？
大丈夫です、安心してください。今回は、企業ネットワークの心臓部であるActive Directory（AD）を直撃する危険な脅威、「ポート389番（LDAP）とポート636番（LDAPS）」をテーマに、誰もが直感的にイメージできる例え話を使って、一歩ずつ優しく紐解いていきます。
難解なパケットの解析はプロに任せて、まずは「この通信が現実世界では何を意味しているのか」を一緒に楽しく理解していきましょう！
—
1. 会社の「身分証明書管理センター」を狙う影
皆さんの会社や学校には、社員証や学生証を発行・管理する総務部や人事部のような場所がありますよね。「誰がどんな役職で、どの部屋に入れて、どんな権限を持っているのか」という名簿がすべてそこに保管されています。
ITの世界において、この「巨大な社員名簿と権限の管理センター」の役割を果たしているのが、Active Directory（AD）などのディレクトリサービスです。そして、私たちがパソコンにログインするときや、プリンターを使おうとするとき、パソコンはこの管理センターに向かって「ねぇ、私のパスワード合ってる？ この部屋に入っていい？」とひそひそと確認の連絡を入れています。
この確認のやり取りで使われる専用の「合言葉（プロトコル）」が LDAP（Lightweight Directory Access Protocol） であり、その通信に使われる郵便受けの番号（ポート番号）が、今回主役となる TCPの389番 なのです。
そして、もう一つの主役である TCPの636番（LDAPS） は、その郵便受けのセキュリティをガチガチに固めた「鍵付きの安全な専用ボックス（暗号化通信）」だと思ってください。
—
2. なぜ、ポート389番と636番が狙われるのか？
攻撃者（ハッカー）の視点に立ってみましょう。もし彼らが企業ネットワークへの侵入に成功したとき、真っ先に手に入れたいものは何だと思いますか？ そう、一般社員のパソコンではありません。ネットワーク全体の鍵を握る「最高権限管理者（ドメイン管理者）」のアカウントです。
ディレクトリサービス（ポート389番/636番）は、いわば「会社全体のすべての合鍵がしまってある金庫の番人」です。攻撃者はここに対して、次のような汚い手口を使って襲いかかります。
ブルートフォース攻撃（総当たり攻撃）
自動化されたプログラムを使い、「パスワードは『Password123』かな？『Admin!2024』かな？」と、ポート389番の窓口に対して何千回、何万回も力づくでドアをノックし続けます。郵便配達員になりすました怪しい人物が、オフィスの裏口の鍵を片っ端からガチャガチャ回しているような状態です。
認証情報収集（Kerberoastingなど）
正規のユーザーやサービスのふりをして、LDAPの窓口から暗号化されたパスワードの断片をこっそり持ち出し、会社の外の強力なコンピューターでゆっくり時間をかけて解読してしまう手口です。窓口の人が「あ、名簿を見たいんですね、どうぞ」と、あまりに簡単に情報を渡してしまうと、こうしてパスワードが破られてしまいます。
—
3. 暗号化されていない「389番」の恐怖
ここで、ポート389番（LDAP）とポート636番（LDAPS）の決定的な違いについてお話ししておきましょう。
日常で例えるなら、ポート389番は「ハガキ」、ポート636番は「鍵のかかった頑丈なジュラルミンのアタッシュケース」です。
- ポート389番（LDAP）： 通信の中身が暗号化されません。つまり、社内ネットワークのどこかで悪い人がネットワークのケーブルを盗聴（パケットキャプチャ）していたら、あなたが入力したIDやパスワードが、「丸見えの文字」としてそのまま空中を飛んでいってしまうのです。
- ポート636番（LDAPS）： 通信がSSL/TLSという強力な技術で暗号化されます。たとえ途中で盗聴されても、金庫の暗証番号のようなめちゃくちゃな暗号の羅列に見えるだけで、中身を読み取られることはありません。
「じゃあ、全部636番（LDAPS）にすればいいじゃない！」その通りです！現代のセキュリティにおいては、暗号化されていない古い389番の通信を野放しにしておくことは、玄関の鍵を全開にして寝るようなものなのです。
—
4. 実務で使える！ドメインコントローラーを守るための設定と対策
それでは、インフラエンジニアとして私たちが現場で実行できる具体的な防御策を見ていきましょう。ここでは、Windows ServerのActive Directory環境やネットワーク機器を想定した設定・対策のポイントをコード例やパラメータ設定を交えて解説します。
対策1：LDAP署名（LDAP Signing）の強制
ポート389番を完全に塞ぐことができないレガシーなシステムがある場合でもせめて「通信の改ざんやなりすまし」を防ぐために、LDAP署名を有効化します。これにより、途中で通信内容を書き換えられるリスクを断ち切ります。
グループポリシー（GPO）やローカルセキュリティポリシーにおいて、以下のレジストリまたはポリシー設定を適用します。
# グループポリシーでの設定パス
[コンピューターの構成] -> [ポリシー] -> [Windows の設定] -> [セキュリティの設定] -> [ローカル ポリシー] -> [セキュリティ オプション]
# 設定すべき項目と推奨値
- ドメイン コントローラー: LDAP サーバー署名要件 (Domain controller: LDAP server signing requirements)
-> 設定値: 「署名が必要 (Require signing)」に変更します。対策2：ファイアウォールでのポート制御（不要な389番の遮断）
ネットワークの境界や、ドメインコントローラー（DC）の前段にあるファイアウォールでは、原則として暗号化されていない TCP/389 への外部からのアクセスを厳しく制限します。
Linuxの iptables や一般的なネットワーク機器のACL（アクセスコントロールリスト）をイメージした設定例を見てみましょう。
# =====================================================================
# ファイアウォール設定サンプル (iptables形式)
# ドメインコントローラーへの不正なアクセスをブロックするルール
# =====================================================================
# 1. 信頼された内部セグメントからの安全なLDAPS (TCP/636) 通信を許可
iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 636 -j ACCEPT
# 2. 暗号化されていないLDAP (TCP/389) は、どうしても必要な特定レガシー機器からの通信のみに限定
iptables -A INPUT -p tcp -s 192.168.10.50 --dport 389 -j ACCEPT
# 3. 上記以外の不審なポート389へのアクセスはすべてドロップ（遮断）する
iptables -A INPUT -p tcp --dport 389 -j DROP
# 4. ポート389へのブルートフォース攻撃を警戒し、ログを記録する設定
iptables -A INPUT -p tcp --dport 389 -m state --state NEW -m recent --set --name LDAP_ATTACK
iptables -A INPUT -p tcp --dport 389 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --name LDAP_ATTACK -j LOG --log-prefix "LDAP_BRUTE_FORCE_ALERT: "この設定では、暗号化されていないポート389へのアクセスを極力絞り込み、短時間に何度も接続を試みる不審な挙動（ブルートフォースの兆候）があれば、即座にシステム管理者にログで警告する仕組みを組み込んでいます。
—
5. おわりに：日々の見守りが最強のセキュリティを生む
今回は、Active Directoryの門番であるポート389番（LDAP）とポート636番（LDAPS）について、郵便配達や身分証明書管理の例えを交えて解説してきました。
- ポート389番は便利だけど、中身が丸見え（ハガキ状態）なので危険がいっぱい。
- ポート636番は鍵付きのアタッシュケース（暗号化）でしっかりと守るべき。
- ブルートフォースや認証情報侵害から社内ネットワークを守るには、暗号化の強制やファイアウォールでの厳格なアクセス制御が不可欠。
セキュリティ対策に「これで完璧」というゴールはありません。しかし、こうした基礎知識を一つずつ押さえて、日々のログに目を光らせる泥臭い工夫の積み重ねこそが、企業の信頼を守る最強の盾となります。
「難しい用語ばかりで不安……」と思っていた方も、今回の記事を通じて、日々のインフラ運用やセキュリティ対策への見方が少し変わったのではないでしょうか？ 一歩ずつ、確実に知識を自分のものにしていきましょう！それでは、また次回の技術解説でお会いしましょう！
コメント