Prywatny adres IP w publicznym DNS

Za zaporą ogniową znajduje się tylko serwer pocztowy SMTP, który będzie miał publiczny rekord poczty. . Jedynym sposobem uzyskania dostępu do tego serwera poczty jest inny serwer za tą samą zaporą ogniową. Nie prowadzimy własnego prywatnego serwera DNS.

Czy dobrym pomysłem jest użycie prywatnego adresu IP jako rekordu A na publicznym serwerze DNS - czy najlepiej przechowywać te rekordy serwera w pliku lokalnych hostów każdego serwera?

Niektórzy twierdzą, że żadne publiczne rekordy DNS nigdy nie powinny ujawniać prywatnych adresów IP ... z myślą, że dajesz potencjalnym atakującym dostęp do niektórych informacji, które mogą być wymagane do wykorzystania systemów prywatnych.

Osobiście uważam, że zaciemnianie jest słabą formą bezpieczeństwa, szczególnie gdy mówimy o adresach IP, ponieważ ogólnie i tak łatwo je zgadnąć, więc nie uważam tego za realistyczny kompromis bezpieczeństwa.

Większe znaczenie ma tutaj upewnienie się, że użytkownicy publiczni nie pobierają tego rekordu DNS w ramach normalnych usług publicznych hostowanej aplikacji. tzn. zewnętrzne wyszukiwania DNS zaczynają jakoś rozpoznawać adres, na który nie mogą się dostać.

Poza tym nie widzę żadnego podstawowego powodu, dla którego umieszczenie rekordów adresu prywatnego A w przestrzeni publicznej jest problemem ... zwłaszcza, gdy nie ma alternatywnego serwera DNS, na którym można by je hostować.

Jeśli zdecydujesz się umieścić ten rekord w publicznej przestrzeni DNS, możesz rozważyć utworzenie oddzielnej strefy na tym samym serwerze, w której będą przechowywane wszystkie „prywatne” rekordy. To sprawi, że będą wyraźniejsze, że mają być prywatne ... jednak dla jednej płyty A prawdopodobnie nie zawracałbym sobie głowy.

Długo rozmawiałem na ten temat z listą NANOG. Chociaż zawsze myślałem, że to zły pomysł, okazuje się, że nie jest to taki zły pomysł w praktyce. Trudności pochodzą głównie z wyszukiwań rDNS (które dla adresów prywatnych po prostu nie działają w świecie zewnętrznym), a gdy zapewniasz dostęp do adresów przez VPN lub podobny, ważne jest, aby upewnić się, że klienci VPN są odpowiednio chronieni przed „przeciekający” ruch, gdy VPN nie działa.

Mówię idź po to. Jeśli osoba atakująca może uzyskać coś znaczącego z możliwości rozpoznawania nazw na adresy wewnętrzne, masz większe problemy z bezpieczeństwem.

Ogólnie rzecz biorąc, wprowadzenie adresów RFC1918 do publicznego DNS spowoduje zamieszanie, jeśli nie prawdziwy problem, w pewnym momencie w przyszłości. Użyj adresów IP, rekordów hosta lub prywatnego widoku DNS swojej strefy, aby użyć adresów RFC1918 za zaporą, ale nie uwzględniaj ich w widoku publicznym.

Aby wyjaśnić moją odpowiedź na podstawie drugiej przesłanej odpowiedzi, myślę, że wprowadzenie adresów RFC1918 do publicznego DNS jest faux pas, a nie kwestią bezpieczeństwa. Jeśli ktoś zadzwoni do mnie, aby rozwiązać problem, i natknę się na adresy RFC1918 w ich DNS, zacznę mówić bardzo wolno i pytam, czy ostatnio uruchomił się ponownie. Może to snobizm z mojej strony, nie wiem. Ale jak powiedziałem, nie jest to konieczne i może w pewnym momencie spowodować zamieszanie i nieporozumienia (ludzkie, a nie komputerowe). Po co ryzykować?

Nie, nie umieszczaj swoich prywatnych adresów IP w publicznym DNS.

Po pierwsze, przecieka informacja, chociaż jest to stosunkowo niewielki problem.

Najgorszy problem, jeśli rekordy MX wskazują na ten konkretny wpis hosta, polega na tym, że każdy, kto spróbuje wysłać do niego pocztę, w najlepszym wypadku uzyska limit czasu dostarczenia poczty.

W zależności od oprogramowania pocztowego nadawcy mogą otrzymywać odbicia.

Co gorsza, jeśli używasz przestrzeni adresowej RFC1918 (którą powinieneś, wewnątrz swojej sieci), a nadawca też, istnieje szansa, że ​​zamiast tego spróbuje dostarczyć pocztę do własnej sieci.

Na przykład:

• sieć ma wewnętrzny serwer pocztowy, ale nie ma podzielonego DNS
• Administrator umieszcza zatem w DNS zarówno publiczny, jak i wewnętrzny adres IP
• i rekordy MX wskazują zarówno:

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

• ktoś, kto to zobaczy, może spróbować połączyć się z 192.168.1.2
• najlepszy przypadek, odbija się, ponieważ nie mają trasy
• ale jeśli mają również serwer korzystający z 192.168.1.2, poczta trafi w niewłaściwe miejsce

Tak, to zepsuta konfiguracja, ale widziałem, że tak się dzieje (i gorzej).

Nie, to nie wina DNS, tylko robi to, co mu polecono.

Chociaż możliwość jest niewielka, myślę, że możesz przygotować się na atak MITM.

Moją obawą byłoby to. Powiedzmy, że jeden z twoich użytkowników z klientem poczty skonfigurowanym do wskazywania tego serwera poczty przenosi laptopa do innej sieci. Co się stanie, jeśli ta inna sieć również będzie mieć ten sam RFC1918 w użyciu. Ten laptop może próbować zalogować się na serwerze smtp i zaoferować poświadczenia użytkownika serwerowi, który nie powinien go mieć. Byłoby to szczególnie prawdziwe, ponieważ powiedziałeś SMTP i nie wspomniałeś, że potrzebujesz SSL.

Dwie opcje to / etc / hosts i umieszczenie prywatnego adresu IP w strefie publicznej. Poleciłbym ten pierwszy. Jeśli reprezentuje to dużą liczbę hostów, powinieneś rozważyć wewnętrzne uruchomienie własnego resolvera, nie jest to takie trudne.

Mogą być z tym subtelne problemy. Jednym z nich jest to, że wspólne rozwiązania ataków DNS Rebind filtrują lokalne wpisy DNS rozwiązane z publicznych serwerów DNS. Możesz albo otworzyć się na ponowne powiązanie ataków, albo adresy lokalne nie działają, lub wymagać bardziej wyrafinowanej konfiguracji (jeśli oprogramowanie / router na to pozwala).

Najlepiej przechowywać go w pliku hosts. Jeśli i tak tylko jedna maszyna ma się z nią połączyć, co zyskasz, umieszczając ją w publicznym DNS?

Jeśli jako prywatny masz na myśli 10.0.0.0/8, 192.168.0.0/16 lub 172.16.0.0/12, to nie rób tego . Większość routerów internetowych rozpoznaje go takim, jakim jest - prywatnym adresem, który nigdy nie może być kierowany do publicznego Internetu w bezpośredni sposób , co pomogło popularności NAT. Każdy, kto próbuje skontaktować się z twoim publicznym serwerem DNS, pobierze prywatny adres IP z DNS, tylko po to, aby wysłać pakiet do ... nigdzie. Podczas gdy ich połączenie próbuje przejść przez Internet na twój prywatny adres, niektóre (po prostu skonfigurowane) routery po prostu zjedzą pakiet żywcem.

Jeśli chcesz, aby wiadomość e-mail z „zewnętrznego” przychodziła „do wewnątrz”, w pewnym momencie pakiet musi przekroczyć zaporę. Sugerowałbym ustawienie adresu DMZ do obsługi tego - jednego publicznego adresu IP, który jest ściśle kontrolowany przez dowolny router / zaporę sieciową, którą masz na swoim miejscu. Istniejąca konfiguracja, którą opisujesz, brzmi dokładnie tak.

EDYCJA: wyjaśnienie zamiaru ... (patrz komentarze poniżej). Jeśli to nie ma sensu, zagłosuję za usunięciem własnego posta.

Przybyłem tutaj, gdy szukałem podobnych informacji i byłem zaskoczony, że wielu twierdzi, że w porządku jest ujawnienie prywatnych adresów IP. Sądzę, że jeśli chodzi o włamanie, nie ma to wielkiego znaczenia, jeśli jesteś w bezpiecznej sieci. Jednak DigitalOcean miał cały ruch sieci lokalnej na dokładnie tych samych kablach, a wszyscy naprawdę mieli dostęp do ruchu wszystkich innych osób (prawdopodobnie wykonalne z atakiem Man in the Middle). Jeśli po prostu dostaniesz komputer w tym samym centrum danych, mając to informacje z pewnością przybliżają Cię o krok do zhakowania mojego ruchu. (Teraz każdy klient ma własną zarezerwowaną prywatną sieć, podobnie jak inne usługi chmurowe, takie jak AWS.)

To powiedziawszy, dzięki własnej usłudze BIND9 możesz łatwo zdefiniować swoje publiczne i prywatne adresy IP. Odbywa się to za pomocą viewfunkcji, która obejmuje warunkowe. Pozwala to na wysłanie zapytania do jednego DNS i uzyskanie odpowiedzi na temat wewnętrznych adresów IP tylko wtedy, gdy pytasz o swój własny wewnętrzny adres IP.

Konfiguracja wymaga dwóch stref. Wybór wykorzystuje match-clients. Oto przykład konfiguracji z serwera DNS dwa w jednym z BIND9 :

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; };
    };
};

Oto strefa zewnętrzna i możemy zobaczyć, że adresy IP nie są prywatne

; 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.

Jeśli chodzi o strefę wewnętrzną, najpierw uwzględniamy strefę zewnętrzną, tak to działa. tzn. jeśli jesteś komputerem wewnętrznym, masz dostęp tylko do strefy wewnętrznej, więc nadal potrzebujesz definicji stref zewnętrznych, stąd $includepolecenie:

$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

Na koniec musisz się upewnić, że wszystkie komputery korzystają teraz z tego DNS i jego urządzeń podrzędnych. Przy założeniu sieci statycznej oznaczałoby to edycję /etc/network/interfacespliku i użycie adresów IP DNS w nameserveropcji. Coś takiego:

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

Teraz powinieneś być gotowy.