Vraag Privé IP-adres in openbare DNS


We hebben een SMTP-mailserver achter een firewall die een openbare A-record van e-mail heeft..  De enige manier om toegang te krijgen tot deze mailserver is van een andere server achter dezelfde firewall. We hebben geen eigen DNS-server.

Is het een goed idee om het privé-IP-adres te gebruiken als een A-record in een openbare DNS-server - of is het het beste om deze serverrecords in elk lokaal hostsbestand van een server te bewaren?


52
2018-05-05 02:21


oorsprong




antwoorden:


Sommige mensen zullen zeggen dat geen openbare DNS-records ooit privé-IP-adressen zouden mogen openbaren ... met het idee dat u potentiële aanvallers een deel van de informatie geeft die nodig kan zijn om particuliere systemen te exploiteren.

Persoonlijk denk ik dat verduistering een slechte vorm van beveiliging is, vooral wanneer we het hebben over IP-adressen, omdat ze in het algemeen gemakkelijk te raden zijn, dus ik zie dit niet als een realistisch veiligheidscompromis.

De grotere overweging hierbij is ervoor te zorgen dat uw openbare gebruikers deze DNS-record niet opnemen als onderdeel van de normale openbare services van uw gehoste toepassing. dat wil zeggen: externe DNS-lookups beginnen op de een of andere manier op te lossen naar een adres dat ze niet kunnen bereiken.

Afgezien daarvan zie ik geen fundamentele reden waarom het plaatsen van privé-adres A-records in de openbare ruimte een probleem is .... vooral wanneer je geen alternatieve DNS-server hebt om ze te hosten.

Als u besluit om deze record in de openbare DNS-ruimte te plaatsen, kunt u overwegen een aparte zone op dezelfde server te maken om alle 'privé'-records te bewaren. Dit maakt het duidelijker dat ze bedoeld zijn als privé ... maar voor slechts één A-record zou ik waarschijnlijk niet de moeite nemen.


51
2018-05-05 02:37



+1, zie reactie op het antwoord van womble voor reden :) - Mihai Limbăşan
Dit is een goed voorbeeld van een probleem met dit idee: merit.edu/mail.archives/nanog/2006-09/msg00364.html - sucuri
Is dit advies nog steeds van toepassing als je gevoelige servers hebt met openbare IP-adressen, maar achter een firewall die de toegang beperkt? Als de openbare DNS voor de openbare IP-adressen een routekaart van de infrastructuur geeft, is dat dan niet iets voor een aanvaller? Host-identificatie? - Kenny
@Kenny Ja, in theorie heeft dit wel enig nut, maar het is informatie die niet moeilijk te krijgen is, omdat het bereik van openbare IP-adressen sowieso gemakkelijk te vinden is. Ik heb dit soort dingen in het antwoord behandeld en toegevoegd aan dat idee zou ik zeggen dat als je afhankelijk bent van het verbergen van IP-adressen of hostnamen als elke vorm van materiële verdedigingslinie, je al veel veel grotere problemen hebt. - Tall Jeff
@Kenny Op dit punt is het zeker wenselijk om de hoeveelheid informatie die openbaar zichtbaar is te minimaliseren en u wilt niet iets onthullen dat u niet nodig had of dat u op zijn minst een soort van goede kosten / batenhandel had uitgeschakeld om erover na te denken. Geen argument daar. Afgezien daarvan was de kern van mijn punt (en ik denk dat we het erover eens zijn) eenvoudigweg dat die versluiering een slechte vorm van veiligheid is en dat er geen absoluut goed / slecht is, maar slechts een continuüm van kosten / baten-compromissen om te worden van geval tot geval bekeken, afhankelijk van uw risicotolerantie, enz. - Tall Jeff


Ik had een tijdje geleden een lange discussie over dit onderwerp op de NANOG-lijst. Hoewel ik altijd dacht dat het een slecht idee was, blijkt het in de praktijk niet zo'n slecht idee te zijn. De problemen zijn meestal afkomstig van rDNS-lookups (die voor privéadressen Just Do not Work in de buitenwereld), en wanneer u via een VPN of iets dergelijks toegang verleent tot de adressen, is het belangrijk ervoor te zorgen dat de VPN-clients goed worden beschermd tegen "lekt" verkeer wanneer de VPN uitvalt.

Ik zeg ga ervoor. Als een aanvaller iets zinvols kan doen, van het kunnen omzetten van namen naar interne adressen, zijn er grotere beveiligingsproblemen.


30
2018-05-05 02:30



+1, bedankt dat je een stem van gezond verstand bent in alle FUD-antwoorden op deze vraag. "Beveiligingsrisico" in mijn lagere dorsale regio's, en het zien van routeringsproblemen en DNS-problemen samengevat in een flitsende "doe het niet" -reactie doet me gewoon afvragen over de competentie van mensen die overal netwerken hebben. - Mihai Limbăşan
Correctie: maak dat "routeringsproblemen en DNS-problemen zien" en problemen met authenticatie / identiteit samengevat ". - Mihai Limbăşan


In het algemeen zal het introduceren van RFC1918-adressen in openbare DNS op enig moment in de toekomst voor verwarring zorgen, zo niet een echt probleem. Gebruik IP's, hostrecords of een persoonlijke DNS-weergave van uw zone om de RFC1918-adressen achter uw firewall te gebruiken, maar deze niet in de openbare weergave op te nemen.

Om mijn antwoord op basis van het andere ingediende antwoord te verduidelijken, denk ik dat het introduceren van RFC1918-adressen in openbare DNS een faux pas is en geen beveiligingsprobleem. Als iemand me oproept om een ​​probleem op te lossen en ik struikel over RFC1918-adressen in hun DNS, begin ik heel langzaam te praten en vraag ik of ze onlangs opnieuw zijn opgestart. Misschien is dat snobbery van mijn kant, ik weet het niet. Maar zoals ik al zei, het is niet noodzakelijk om te doen en het zal waarschijnlijk op een gegeven moment verwarring en miscommunicatie veroorzaken (mens, niet computer). Waarom riskeren?


8
2018-05-05 02:29



Welk (e) probleem (en) zijn dit? Op welke manieren zullen mensen in de war raken? - womble♦
Dus het is ... beleefd ... om 1918-adressen niet in openbare DNS te plaatsen? Ik heb veel problemen gehad die "verborgen" en "gesplitste horizon" DNS-zones hebben veroorzaakt, maar lang niet zoveel veroorzaakt door private IP in publieke DNS. Ik zie het probleem gewoon niet. - womble♦
@womble, computers kunnen in de war raken als ze om wat voor reden dan ook proberen verbinding te maken met die host buiten je netwerk en in plaats van de SMTP-server te krijgen die ze verwachtten, kregen ze wat er op dat IP-adres woonde in de lan waar ze op dat moment mee verbonden waren. Het kan zelfs zo zijn dat een van uw medewerkers die een laptop op een externe computer gebruikt, de gebruikersnaam en het wachtwoord kan uitprinten in platte tekst op het netwerk van iemand anders, alleen omdat ze toevallig ook een 192.168.1.1 hebben - Zoredache
Het probleem dat ik heb met uw antwoord is dat u zinspeelt op problemen, maar geen details verstrekt. Als er redenen zijn om het niet te doen, wil ik er meer over weten, zodat ik een volledig onderbouwde beslissing over het onderwerp kan nemen. - womble♦
Ik zou ook graag willen weten wat "verwarring" kan veroorzaken. De enige "verwarring" die ik kan bedenken is RFC1918-adressen in openbare NS- of MX-records, en dat is een grote fout, geen verwarring. Het beveiligingsprobleem is een rode haring, 90% van de mensen hebben al 192.168.1.0/24 en niemand zal echt de moeite nemen om DNS te controleren op meer, en als je last hebt van lekkende interne netwerken, heb je de laatste tijd je SMTP-headers gecontroleerd? Dat dacht ik al. - Mihai Limbăşan


Nee, plaats uw privé IP-adressen niet in de publieke DNS.

Ten eerste lekt het informatie, hoewel dat een relatief klein probleem is.

Het ergere probleem als uw MX-records naar dat specifieke hostitem verwijzen, is dat iedereen die wel e-mail probeert te verzenden, in het beste geval time-outs voor e-mailbezorging krijgt.

Afhankelijk van de e-mailsoftware van de verzender, kunnen ze bounces krijgen.

Erger nog, als u RFC1918-adresruimte gebruikt (wat u ook in uw netwerk zou moeten doen) en de afzender is dat, dan is de kans groot dat zij de e-mail proberen af ​​te leveren op hun eigen netwerk.

Bijvoorbeeld:

  • netwerk heeft een interne mailserver, maar geen gesplitste DNS
  • admin plaatst daarom zowel openbare als interne IP-adressen in de DNS
  • en MX-records verwijzen naar beide:

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

  • iemand die dit ziet macht probeer verbinding te maken met 192.168.1.2
  • beste geval, het botst, omdat ze geen route hebben
  • maar als ze ook een server hebben die 192.168.1.2 gebruikt, zal de mail naar de verkeerde plaats gaan

Ja, het is een gebroken configuratie, maar ik heb dit (en erger) zien gebeuren.

Nee, het is niet de schuld van DNS, het doet gewoon wat het moet zeggen.


6
2018-05-05 09:35



Hoe is het bezorgen van e-mail aan de verkeerde computer een DNS-probleem? U moet de SMTP-server verifiëren. Dat is een SMTP-configuratieprobleem dat absoluut niets met DNS te maken heeft. Je vergelijkt hier niet eens appels met sinaasappels, je vergelijkt een radioactieve beboterde toast met vijf milligram Lagrange-afgeleide producten op een stok. Als je je zorgen maakt over het verkeerde MX- of A-resultaat, moet je DNSSEC gebruiken in plaats van DNS verantwoordelijk te houden voor wat het niet verantwoordelijk maakt, en als je ten onrechte SMTP naar het verkeerde RFC1918-nummer stuurt, heb je je netwerk verkeerd geconfigureerd of verkeerd ontworpen. - Mihai Limbăşan
(opnieuw gepost voor de verduidelijking) - Mihai Limbăşan
Als iemand in uw netwerk een IP-nummer heeft "verzonnen", functioneert het IP-protocol precies zoals het is ontworpen, d.w.z. zonder beveiliging in gedachten. Wat u vraagt ​​is "hoe kan ik erop vertrouwen dat ik eigenlijk praat met iedereen met wie ik zou moeten praten?" en het antwoord daarop kan niet door IP en / of door DNS worden geleverd, het antwoord daarop wordt geleverd door DNSSEC en / of SSL / TLS en / of een applicatielaagmechanisme. - Mihai Limbăşan
Lees gewoon je reactie op Dave's bericht - je bericht is nu zinvoller :) Ik ben het nog steeds niet eens met het uitgangspunt, maar ik denk niet dat het irrationeel is ... - Mihai Limbăşan
Nee, het ging helemaal niet om authenticatie, alleen om connecties die op de verkeerde plaats terechtkwamen. ik zag overvloed van dat toen Verisign besloot om * .com terug te gebruiken in ~ 2001. - Alnitak


Uw twee opties zijn / etc / hosts en een privé-IP-adres in uw openbare zone plaatsen. Ik zou de eerste aanraden. Als dit een groot aantal hosts vertegenwoordigt, kun je overwegen om intern je eigen resolver te gebruiken, het is niet zo moeilijk.


3
2018-05-05 04:32



Dat is zeker een optie, maar waarom? Wat levert het uitvoeren van een interne resolver of (veel slimmer) met zoiets als BIND views op naast administratieve overhead en onderhoudskosten? Dat is wat ik niet begrijp. - Mihai Limbăşan
Het runnen van je eigen nameserver is geen rocket science. Als uw netwerk voldoende groot is en u / etc / hosts als een hack of tijdrovend beschouwt, moet u een paar resolvers in uw netwerk instellen. Als bijkomend voordeel vermindert u de hoeveelheid dns-verkeer die uw netwerk verlaat en versnelt u de oplossing van veelvoorkomende zoekopdrachten. - Dave Cheney
Ik weet dat het geen rocket science is, maar een overhead voor onderhoud en een potentieel veiligheidsrisico. Zeker een hoger veiligheidsrisico dan het lekken van het bestaan ​​van een RFC1918-netwerk. DNS-verkeer is volkomen verwaarloosbaar - ik host meer dan 80 redelijk grote en drukke zonebestanden op mijn DNS op het werk en wekelijks DNS-verkeer is minder dan 2 minuten aan Youtube. Het versnellen van queryresolutie is eigenlijk het eerste half gezonde argument tegen RFC1918-nummers in DNS dat ik hier heb gezien :) Opgewekt omdat ik eigenlijk een beetje verder ging dan de gebruikelijke reflexen "oh nee, het is een veiligheidsrisico" -reactie :) - Mihai Limbăşan
@Alnitak: ik begrijp waar je vandaan komt maar dat is nog steeds geen DNS-probleem, en ik blijf erbij dat proberen om problemen die ergens anders via DNS ontstaan, te herstellen helemaal geen goed idee is. Problemen moeten worden opgelost bij de bron, niet opgepoetst door DNS-hacks - hacks maken netwerken broos. - Mihai Limbăşan
wel, ja, daar ben ik het mee eens. En het plaatsen van de gegevens van uw private host in de publieke DNS is een hack-oplossing voor het probleem van het niet hebben van een interne DNS-server ... :) Het probleem is dat de hogere lagen niet weten dat deze informatie "privé" zou moeten zijn. - Alnitak


Hoewel de mogelijkheid afgelegen is, denk ik dat je je misschien voor een of andere MITM-aanval inzet.

Mijn zorg zou dit zijn. Laten we zeggen dat een van uw gebruikers met een e-mailclient die is geconfigureerd om naar die mailserver te verwijzen, hun laptop meeneemt naar een ander netwerk. Wat gebeurt er als dat andere netwerk ook dezelfde RFC1918 gebruikt? Die laptop kan proberen in te loggen op de smtp-server en de inloggegevens van de gebruiker aan te bieden aan een server die deze niet zou moeten hebben. Dit zou met name kloppen omdat je SMTP hebt gezegd en niet hebt vermeld dat je SSL nodig hebt.


2
2018-05-05 02:56



Als de gebruiker een laptop heeft die ze zowel op kantoor als elders gebruiken, is de kans groot dat ze hun hosts-bestand hebben geconfigureerd om naar het interne IP-adres van de MTA te wijzen, of dat ze het IP-adres rechtstreeks in hun MUA-configuratie gebruiken. Hetzelfde eindresultaat. Neem IPv6 mee en de dood van RFC1918, het is de enige manier om er zeker van te zijn ... - womble♦
Uitstekend punt Zoredache. Dit is een interessante aanvalsvector. Afhankelijk van de MUA kan dit het gebruikelijke "iets vervelend gebeurde, klik me om te doen wat je wilde me in de eerste plaats" dialoogvenster te laten zien, anders zou het meteen kunnen mislukken als het SSL-certificaat niet overeenkomt. - Dave Cheney


Het is het beste om het in het hosts-bestand te bewaren. Als er toch maar één machine is die er ooit mee zou moeten verbinden, wat krijg je dan door het in publieke DNS te plaatsen?


1
2018-05-05 15:13





Als u privé bent, bedoelt u een 10.0.0.0/8, een 192.168.0.0/16 of een 172.16.0.0/12, dan niet doen. De meeste internetrouters herkennen het voor wat het is - een privé-adres dat moet nooit op een directe manier naar het openbare internet gerouteerd worden, wat de populariteit van NAT heeft bevorderd. Iedereen die probeert contact te maken met uw openbare DNS-server, haalt het privé-IP-adres op bij DNS, alleen om een ​​pakket te sturen naar .... nergens. Omdat hun verbinding probeert om het internet naar uw privé-adres te doorlopen, zal een (goed geconfigureerde) router onderweg het pakket gewoon levend opeten.

Als u e-mail wilt ontvangen van de "buitenkant" die "binnen" komt, moet het pakket op een gegeven moment uw firewall passeren. Ik zou willen voorstellen om hier een DMZ-adres voor in te stellen - een enkel openbaar IP-adres dat strak wordt beheerd door elke router / firewall die je hebt geïnstalleerd. De bestaande opstelling die u beschrijft, klinkt alsof het precies dat doet.

EDIT: verduidelijking van de intentie ... (zie opmerkingen hieronder). Als dit geen zin heeft, stem ik om mijn eigen bericht te verwijderen.


1
2018-05-05 13:39



Dat is allemaal leuk en waar, maar je hebt geen echte reden gegeven waarom je RFC1918-adressen niet in DNS zou moeten publiceren. U hebt zojuist beschreven wat RFC1918-adressen zijn en dat het mogelijk is om geen route naar sommige van deze adressen te hebben. Hoe verschilt dat van elk ander IP-nummer? Het is mogelijk om geen route naar 198.41.0.4 te hebben - betekent dit dat het verkeerd is om 198.41.0.4 in DNS te publiceren? DNS is een naam resolutie systeem. Het heeft niets te maken met routing, de twee zijn orthogonaal. U sluit twee categorieën problemen samen, wat in feite neerkomt op FUD. - Mihai Limbăşan
De context van de discussie was het gebruik van privé-IP-adressen in a openbaar DNS server. Het punt van de post was om aan te geven dat routers standaard geen particuliere IP-adressen mogen routeren. Ik probeerde je niet aan te geven kan niet gebruik private IP-adressen in een DNS-server, alleen dat u die IP-adressen niet "naar buiten" moet verstrekken. Als dit niet duidelijk genoeg is, trek ik het bericht graag terug. Anders ben ik het daar niet mee eens, het bericht is 100% precies - het netto-effect voor deze persoon is dat / zij zullen problemen hebben / als ze dit doen. - Avery Payne
knikt Jouw reactie onder Alnitak's bericht wist het op :) Bedankt. - Mihai Limbăşan
"Iedereen die probeert contact te maken met uw openbare DNS-server, haalt het persoonlijke IP-adres op bij DNS, alleen om een ​​pakket naar .... nergens te sturen" - Nee, je hebt eigenlijk zojuist DNS-rebinding beschreven en het werkt op enkele van de veiligste routers die er zijn, inclusief mijn PepWave Surf SOHO: rebind.network/rebind - Ohad Schneider


Er kunnen subtiele problemen mee zijn. Een daarvan is dat gemeenschappelijke oplossingen voor DNS Rebind-aanvallen lokale DNS-vermeldingen filteren die zijn opgelost van openbare DNS-servers. Dus open je jezelf om aanvallen opnieuw te verbinden of werken lokale adressen niet, of heb je een meer geavanceerde configuratie nodig (als je software / router dit zelfs toestaat).


1
2017-09-16 08:17



+1 DNS-rebinding is slecht !! medium.com/@brannondorsey/... - Ohad Schneider