방화벽 뒤에 SMTP 전용 메일 서버가 있으며이 서버에는 공용 A 레코드 레코드가 있습니다. . 이 메일 서버에 액세스 할 수있는 유일한 방법은 동일한 방화벽 뒤에있는 다른 서버를 사용하는 것입니다. 우리는 우리 자신의 개인 DNS 서버를 운영하지 않습니다.
개인 IP 주소를 공용 DNS 서버에서 A 레코드로 사용하는 것이 좋습니까? 아니면 이러한 서버 레코드를 각 서버의 로컬 호스트 파일에 유지하는 것이 가장 좋습니까?
답변
어떤 사람들은 퍼블릭 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 주소 공간 (네트워크 내부에 있어야 함)을 사용하고 발신자가 너무 많으면 대신 자신의 네트워크로 메일을 전달하려고 시도 할 가능성이 있습니다.
예를 들면 다음과 같습니다.
- 네트워크에 내부 메일 서버가 있지만 분할 DNS가 없습니다
- 따라서 관리자는 공개 및 내부 IP 주소를 모두 DNS에 넣습니다.
- MX 레코드는 다음을 모두 가리 킵니다.
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
- 이것을 보는 사람 은 192.168.1.2에 연결하려고 할 수 있습니다.
- 가장 좋은 경우는 경로가 없기 때문에 튀는 것입니다.
- 그러나 그들이 192.168.1.2를 사용하는 서버를 가지고 있다면, 메일은 잘못된 곳으로 갈 것입니다
예, 구성이 손상되었지만이 (그리고 더 나쁜) 일이 발생했습니다.
아니요, 그것은 DNS의 결함이 아니며, 단지 그것이 지시 한 것을하는 것입니다.
답변
가능성은 희박하지만 MITM 공격에 대비할 수 있다고 생각합니다.
내 관심사는 이것입니다. 해당 메일 서버를 가리 키도록 구성된 메일 클라이언트를 가진 사용자 중 한 명이 자신의 랩톱을 다른 네트워크로 가져갑니다. 다른 네트워크에서도 동일한 RFC1918을 사용하면 어떻게됩니까? 해당 랩톱은 smtp 서버에 로그인을 시도하고이를 가져서는 안되는 서버에 사용자의 자격 증명을 제공 할 수 있습니다. SMTP라고 말하고 SSL이 필요한 곳은 언급하지 않았기 때문에 특히 그렇습니다.
답변
두 가지 옵션은 / etc / hosts이며 공개 영역에 개인 IP 주소를 넣는 것입니다. 나는 전자를 추천합니다. 이것이 많은 호스트를 나타내는 경우 자체 리졸버를 내부적으로 실행하는 것을 고려해야합니다. 그렇게 어렵지는 않습니다.
답변
미묘한 문제가있을 수 있습니다. 하나는 DNS 리 바인드 공격에 대한 일반적인 솔루션이 퍼블릭 DNS 서버에서 해결 된 로컬 DNS 항목을 필터링한다는 것입니다. 따라서 공격을 리 바인드하기 위해 자신을 열거 나 로컬 주소가 작동하지 않거나보다 정교한 구성이 필요합니다 (소프트웨어 / 라우터가 허용하는 경우).