답변:
어떤 사람들은 퍼블릭 DNS 레코드에 프라이빗 IP 주소를 공개해서는 안된다고 말할 것입니다. 잠재적 인 공격자에게 프라이빗 시스템을 악용하는 데 필요한 일부 정보를 제공 할 수 있다는 생각으로 말입니다.
개인적으로, 난독 화는 보안의 열악한 형태라고 생각합니다. 특히 IP 주소에 대해서는 일반적으로 추측하기 쉽기 때문에 IP 주소에 대해 이야기 할 때이를 현실적인 보안 타협으로 보지 않습니다.
여기서 더 큰 고려 사항은 공용 사용자가 호스팅 된 응용 프로그램의 일반 공용 서비스의 일부로이 DNS 레코드를 선택하지 않도록하는 것입니다. 즉, 외부 DNS 조회는 어떻게 든 도달 할 수없는 주소로 확인되기 시작합니다.
그 외에도 개인 주소 A 레코드를 공용 공간에 배치하는 것이 문제가되는 근본적인 이유는 없습니다. 특히 호스트 할 대체 DNS 서버가없는 경우에 특히 그렇습니다.
이 레코드를 공용 DNS 공간에 배치하기로 결정한 경우, 모든 "개인"레코드를 보유하기 위해 동일한 서버에서 별도의 영역을 작성하는 것을 고려할 수 있습니다. 이것은 그들이 비공개로 의도되었다는 것을 분명히 할 것입니다 ...하지만 단 하나의 A 레코드에 대해서는 귀찮게하지 않을 것입니다.
나는 NANOG 목록에서이 주제에 대해 오래 전에 토론했다. 나는 그것이 항상 나쁜 생각이라고 생각했지만 실제로는 그렇게 나쁜 생각이 아니라는 것이 밝혀졌습니다. 어려움은 대부분 rDNS 조회 (개인 주소의 경우 외부에서는 작동하지 않음)에서 비롯되며 VPN 등을 통해 주소에 대한 액세스를 제공하는 경우 VPN 클라이언트가 올바르게 보호되도록하는 것이 중요합니다 VPN이 다운되었을 때 트래픽 "누설".
가자고 침입자가 이름을 내부 주소로 확인할 수있어 의미있는 것을 얻을 수 있다면 더 큰 보안 문제가있는 것입니다.
일반적으로 RFC1918 주소를 퍼블릭 DNS에 도입하면 실제 문제는 아니지만 향후 어느 시점에서 혼동을 일으킬 수 있습니다. 방화벽 뒤의 RFC1918 주소를 사용하지만 공용보기에는 포함하지 않으려면 IP, 호스트 레코드 또는 영역의 개인 DNS보기를 사용하십시오.
제출 된 다른 응답을 기반으로 내 응답을 명확하게하기 위해 RFC1918 주소를 퍼블릭 DNS에 도입하는 것은 보안 문제가 아니라 모조품이라고 생각합니다. 누군가 문제를 해결하기 위해 전화를 걸어서 DNS의 RFC1918 주소를 우연히 발견하면 실제로 천천히 말하기 시작하여 최근에 재부팅했는지 묻습니다. 어쩌면 그것은 저의 snobbery 일지 모르겠습니다. 그러나 내가 말했듯이, 그것은 할 필요가 없으며 어느 시점에서 혼란과 오판 (컴퓨터가 아닌 인간)을 일으킬 가능성이 있습니다. 왜 위험합니까?
아니요, 개인 IP 주소를 퍼블릭 DNS에 넣지 마십시오.
첫째, 정보가 유출되지만 이는 비교적 사소한 문제입니다.
MX 레코드가 특정 호스트 항목을 가리키는 경우 더 나쁜 문제는 메일을 보내려고 시도하는 사람은 누구나 메일 배달 시간이 초과되는 것입니다.
발신자의 메일 소프트웨어에 따라 반송 될 수 있습니다.
더 나쁜 것은, RFC1918 주소 공간 (네트워크 내부에 있어야 함)을 사용하고 발신자가 너무 많으면 대신 자신의 네트워크로 메일을 전달하려고 시도 할 가능성이 있습니다.
예를 들면 다음과 같습니다.
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
예, 구성이 손상되었지만이 (그리고 더 나쁜) 일이 발생했습니다.
아니요, 그것은 DNS의 결함이 아니며, 단지 그것이 지시 한 것을하는 것입니다.
가능성은 희박하지만 MITM 공격에 대비할 수 있다고 생각합니다.
내 관심사는 이것입니다. 해당 메일 서버를 가리 키도록 구성된 메일 클라이언트를 가진 사용자 중 한 명이 자신의 랩톱을 다른 네트워크로 가져갑니다. 다른 네트워크에서도 동일한 RFC1918을 사용하면 어떻게됩니까? 해당 랩톱은 smtp 서버에 로그인을 시도하고이를 가져서는 안되는 서버에 사용자의 자격 증명을 제공 할 수 있습니다. SMTP라고 말하고 SSL이 필요한 곳은 언급하지 않았기 때문에 특히 그렇습니다.
두 가지 옵션은 / etc / hosts이며 공개 영역에 개인 IP 주소를 넣는 것입니다. 나는 전자를 추천합니다. 이것이 많은 호스트를 나타내는 경우 자체 리졸버를 내부적으로 실행하는 것을 고려해야합니다. 그렇게 어렵지는 않습니다.
미묘한 문제가있을 수 있습니다. 하나는 DNS 리 바인드 공격에 대한 일반적인 솔루션이 퍼블릭 DNS 서버에서 해결 된 로컬 DNS 항목을 필터링한다는 것입니다. 따라서 공격을 리 바인드하기 위해 자신을 열거 나 로컬 주소가 작동하지 않거나보다 정교한 구성이 필요합니다 (소프트웨어 / 라우터가 허용하는 경우).
hosts 파일에 보관하는 것이 가장 좋습니다. 어쨌든 한 대의 컴퓨터 만 연결해야한다면 퍼블릭 DNS에 넣어서 무엇을 얻을 수 있습니까?
/etc/hosts2,000 대의 모든 머신이이 IP / 이름 쌍을 관리해야하기 때문에 파일 을 사용하는 것은 실용적이지 않습니다 ...
개인에 의해 당신이 10.0.0.0/8하는 192.168.0.0/16 또는 172.16.0.0/12을 의미한다면, 하지 않습니다 . 대부분의 인터넷 라우터는 직접 인식 하여 공개 인터넷으로 라우팅 해서는 안되는 개인 주소를 인식하여 NAT의 인기를 얻었습니다. 퍼블릭 DNS 서버에 접속을 시도하는 사람은 DNS에서 프라이빗 IP 주소를 검색하여 패킷을 .... 그들의 연결이 인터넷을 당신의 개인 주소로 이동 시키려고 시도함에 따라, 길을 따라 일부 (잘 구성된) 라우터는 단순히 패킷을 살아있게 먹을 것입니다.
"내부"로 오는 "외부"에서 전자 메일을 받으려면 패킷이 방화벽을 통과해야합니다. 이 문제를 처리하기 위해 DMZ 주소를 설정하는 것이 좋습니다. 즉, 모든 라우터 / 방화벽에 의해 엄격하게 제어되는 단일 공용 IP 주소입니다. 설명하는 기존 설정은 정확히 그렇게하는 것처럼 들립니다.
편집 : 의도 설명 ... (아래 의견 참조). 이해가되지 않으면 본인의 게시물을 삭제하기 위해 투표합니다.
비슷한 정보를 찾고 있는데 여기에 도착했으며 많은 사람들이 개인 IP 주소를 유출하는 것이 좋다고 놀랐습니다. 해킹당하는 것으로 생각하면 안전한 네트워크에 있다면 큰 차이가 없습니다. 그러나 DigitalOcean은 모든 사람이 다른 모든 트래픽에 실제로 액세스 할 수있는 동일한 케이블로 모든 로컬 네트워크 트래픽을 가졌습니다 (아마도 Man in the Middle 공격으로 가능할 수 있습니다). 동일한 데이터 센터에 컴퓨터를 설치하려는 경우 정보는 확실히 내 트래픽 해킹에 한 걸음 더 다가갑니다. 이제 각 클라이언트에는 AWS와 같은 다른 클라우드 서비스와 마찬가지로 자체 예약 된 개인 네트워크가 있습니다.
BIND9 서비스를 사용하면 퍼블릭 및 프라이빗 IP를 쉽게 정의 할 수 있습니다. view조건부 포함 기능을 사용하여 수행됩니다 . 이를 통해 하나의 DNS를 쿼리하고 자신의 내부 IP 주소 중 하나에서 요청하는 경우에만 내부 IP에 대한 답변을 얻을 수 있습니다.
설정에는 두 개의 영역이 필요합니다. 선택은을 사용합니다 match-clients. 다음은 BIND9 가있는 Two-in-one 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 ...
이제 모든 준비가 완료되었습니다.