it-swarm-ja.tech

パブリックDNSのプライベートIPアドレス

ファイアウォールの背後にSMTPのみのメールサーバーがあり、メールのパブリックAレコードがあります。このメールサーバーにアクセスする唯一の方法は、同じファイアウォールの背後にある別のサーバーからです。独自のプライベートDNSサーバーは実行しません。

プライベートIPアドレスをパブリックDNSサーバーのAレコードとして使用するのは良い考えですか、またはこれらのサーバーレコードを各サーバーのローカルホストファイルに保存するのが最善ですか?

62
Geoff Dalgas

一部の人々は、パブリックDNSレコードでプライベートIPアドレスを開示するべきではないと言うでしょう...プライベートシステムを悪用するために必要となる可能性のあるいくつかの情報について、潜在的な攻撃者に足を踏み入れていると考えています。

個人的には、難読化はセキュリティの悪い形だと思います。特にIPアドレスの場合は、一般に推測が容易であるため、これは現実的なセキュリティの妥協とは思いません。

ここで最も重要な考慮事項は、パブリックユーザーがホストされているアプリケーションの通常のパブリックサービスの一部としてこのDNSレコードを取得しないようにすることです。つまり、外部DNSルックアップは、どういうわけか、到達できないアドレスへの解決を開始します。

それを除けば、プライベートアドレスAレコードをパブリックスペースに配置することが問題になる根本的な理由はありません。特に、それらをホストする代替DNSサーバーがない場合。

このレコードをパブリックDNSスペースに配置することにした場合は、同じサーバー上に別のゾーンを作成して、すべての「プライベート」レコードを保持することを検討してください。これにより、それらがプライベートであることが意図されていることが明確になります。ただし、Aレコードが1つだけの場合は、おそらく気にしません。

63
Tall Jeff

しばらく前に、NANOGリストでこのトピックについて長い議論をしました。私はいつもそれは悪い考えだと思っていましたが、実際にはそれほど悪い考えではないことがわかりました。困難は主にrDNSルックアップ(プライベートアドレスの場合、外部の世界では機能しない)に起因します。VPNなどのアドレスへのアクセスを提供する場合、VPNクライアントが適切に保護されていることを確認することが重要です。 VPNがダウンしているときの「リーク」トラフィック。

私はそれのために行くと言います。攻撃者が名前を内部アドレスに解決できることから意味のあるものを入手できる場合、より大きなセキュリティの問題が発生しています。

36
womble

一般に、RFC1918アドレスをパブリックDNSに導入すると、将来のある時点で、実際の問題ではないとしても混乱が生じます。 IP、ホストレコード、またはゾーンのプライベートDNSビューを使用して、ファイアウォールの背後にあるRFC1918アドレスを使用しますが、パブリックビューには含めません。

提出された他の応答に基づいて私の応答を明確にするために、RFC1918アドレスをパブリックDNSに導入することは、偽のパスであり、セキュリティの問題ではないと思います。問題のトラブルシューティングを依頼され、DNSでRFC1918アドレスを見つけた場合、私は非常にゆっくりと話し始め、最近再起動したかどうかを尋ねます。多分それは私の側の控えめなことです、私は知りません。しかし、私が言ったように、それは必要なことではなく、ある時点で混乱や誤解(コンピュータではなく人間)を引き起こす可能性があります。なぜそれを危険にさらすのですか?

8
jj33

いいえ、プライベートIPアドレスをパブリックDNSに配置しないでください。

まず、情報が漏洩しますが、それは比較的小さな問題です。

MXレコードがその特定のHostエントリを指している場合のさらに悪い問題は、そこにメールを送信しようとする誰もがせいぜいメール配信タイムアウトを取得することです。

送信者のメールソフトウェアによっては、バウンスが発生する場合があります。

さらに悪いことに、RFC1918アドレス空間(ネットワーク内で使用する必要があります)を使用していて、送信者もそうである場合、代わりにメールを独自のネットワークに配信しようとする可能性があります。

例えば:

  • ネットワークには内部メールサーバーがありますが、スプリットDNSはありません
  • したがって、管理者はパブリックIPアドレスと内部IPアドレスの両方をDNSに配置します
  • mXレコードは両方を指します。

 $Origin example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP

  • これを見た誰かmight 192.168.1.2への接続を試みる
  • 彼らがルートを持っていないので、最良の場合、それは跳ねます
  • しかし、192.168.1.2を使用するサーバーも持っている場合、メールは間違った場所に送られます

はい、それは壊れた構成ですが、私はこれが(そしてもっと悪いことは)起こるのを見てきました。

いいえ、それはDNSのせいではなく、指示されたことを実行しているだけです。

5
Alnitak

可能性は低いですが、MITM攻撃のいくつかに備えている可能性があります。

私の懸念はこれでしょう。そのメールサーバーをポイントするように設定されたメールクライアントを持つユーザーの1人がラップトップを他のネットワークに接続するとします。他のネットワークでも同じRFC1918が使用されている場合はどうなりますか。そのラップトップは、smtpサーバーへのログインを試み、ユーザーの資格情報を、それを持たないサーバーに提供する可能性があります。これは、SMTPについて述べ、SSLが必要な場合については言及しなかったため、特に当てはまります。

3
Zoredache

2つのオプションは、/ etc/hostsと、プライベートIPアドレスをパブリックゾーンに配置することです。前者をお勧めします。これが多数のホストを表す場合は、内部で独自のリゾルバーを実行することを検討する必要がありますが、それほど難しくありません。

3
Dave Cheney

微妙な問題があるかもしれません。 1つは、DNS再バインド攻撃に対する一般的なソリューションが、パブリックDNSサーバーから解決されたローカルDNSエントリをフィルター処理することです。ですから、攻撃を再バインドすることに自分をオープンにするか、ローカルアドレスが機能しないか、またはより高度な構成が必要になります(ソフトウェア/ルーターでさえ許可されている場合)。

2
Nikola Toshev

プライベートで10.0.0.0/8、192.168.0.0/16、または172.16.0.0/12を意味する場合、しないでください。ほとんどのインターネットルーターは、それが何であるかを認識します- プライベートアドレスnever直接インターネットでパブリックインターネットにルーティングする必要があります これは、NATの普及に役立ちました。パブリックDNSサーバーにアクセスしようとすると、DNSからプライベートIPアドレスが取得され、パケットは.... nowhereに送信されます。彼らの接続があなたのプライベートアドレスにインターネットを横断することを試みるとき、途中のいくつかの(まともな設定された)ルーターは単に生きているパケットを食べるでしょう。

「外部」から「内部」にメールを送りたい場合、ある時点で、パケットがファイアウォールを通過する必要があります。これを処理するためにDMZアドレスを設定することをお勧めします-配置しているルーター/ファイアウォールによって厳密に制御される単一のパブリックIPアドレス。記述した既存の設定は、まさにそのように聞こえますそれ。

編集:意図の明確化...(以下のコメントを参照)これが意味をなさない場合は、投票して自分の投稿を削除します。

1
Avery Payne

Hostsファイルに保存することをお勧めします。とにかく1台のマシンだけがそれに接続することになっている場合、それをパブリックDNSに入れることで何が得られますか?

1
sh-beta

同様の情報を探していたところ、私はここにたどり着きました。多くの人があなたのプライベートIPアドレスを漏らしても大丈夫だと言って驚いたハッキングされているという意味では、安全なネットワークを使用している場合でも大きな違いはありません。ただし、DigitalOceanでは、すべてのローカルネットワークトラフィックがまったく同じケーブル上にあり、誰もが実際に他のすべてのトラフィックにアクセスできます(おそらくMan in the Middle攻撃で実行できます)。情報は確かにあなたに私のトラフィックをハッキングする一歩近づきます。 (これで、各クライアントには、AWSなどの他のクラウドサービスと同様に、独自の予約済みプライベートネットワークがあります。)

つまり、独自のBIND9サービスを使用すると、パブリックIPとプライベートIPを簡単に定義できます。これは、条件を含むview機能を使用して行われます。これにより、1つのDNSを照会し、自分の内部IPアドレスの1つから要求する場合にのみ、内部IPに関する回答を取得できます。

セットアップには2つのゾーンが必要です。選択にはmatch-clientsBIND9を使用する2つのDNSサーバー からの設定例を次に示します。

acl slaves {
    195.234.42.0/24;    // XName
    193.218.105.144/28; // XName
    193.24.212.232/29;  // XName
};

acl internals {
    127.0.0.0/8;
    10.0.0.0/24;
};

view "internal" {
    match-clients { internals; };
    recursion yes;
    zone "example.com" {
        type master;
        file "/etc/bind/internals/db.example.com";
    };
};
view "external" {
    match-clients { any; };
    recursion no;
    zone "example.com" {
        type master;
        file "/etc/bind/externals/db.example.com";
        allow-transfer { slaves; };
    };
};

これが外部ゾーンです。IPがプライベートではないことがわかります

; example.com
$TTL    604800
@       IN      SOA     ns1.example.com. root.example.com. (
                     2006020201 ; Serial
                         604800 ; Refresh
                          86400 ; Retry
                        2419200 ; Expire
                         604800); Negative Cache TTL
;
@       IN      NS      ns1
        IN      MX      10 mail
        IN      A       192.0.2.1
ns1     IN      A       192.0.2.1
mail    IN      A       192.0.2.128 ; We have our mail server somewhere else.
www     IN      A       192.0.2.1
client1 IN      A       192.0.2.201 ; We connect to client1 very often.

内部ゾーンについては、最初に外部ゾーンを含めます。つまり、それがどのように機能するかです。つまり、内部コンピュータの場合は内部ゾーンにのみアクセスするため、外部ゾーンの定義が必要なので、$includeコマンド:

$include "/etc/bind/external/db.example.com"
@       IN      A       10.0.0.1
boss    IN      A       10.0.0.100
printer IN      A       10.0.0.101
scrtry  IN      A       10.0.0.102
sip01   IN      A       10.0.0.201
lab     IN      A       10.0.0.103

最後に、すべてのコンピューターがそのDNSとそのスレーブを使用することを確認する必要があります。静的ネットワークを想定すると、/etc/network/interfacesファイルを使用し、nameserverオプションでDNS IPを使用します。このようなもの:

iface eth0 inet static
    ...
    nameserver 10.0.0.1 10.0.0.103 ...

これで準備は完了です。

0
Alexis Wilke