Evilcoder.org

[lang_en]

While most people think that Securing your DNS server is practically impossible, I want to give a few hints and tricks to make sure that it's possible to mitigate problems from DNS to your local server.

This setup should actually be followed by everyone that cares about his DNS Server!

There are a few options to protect your DNS server as much as possible.

• Split your DNS servers. The internal networks is most likely to do remote queries, the external network probably only serves your internet zone's. Why have them in one instance? Split the machines where possible, or create different views, so that the internal people can only recurse and the external people can only lookup the domains you host. (SPLIT-DNS)
• Add ACL's and limit recursion; if you cannot do the above, you should try the best as possible to limit the amount of people that can use your DNS server to do remote lookups. Is it really necessary that joe-next-door uses your dns server to visit www.triplexdomain.com ? ISP's are here to service these DNS queries for him

  an Example of an ACL in named:

  acl your-acl-name { 10.0.0.0/8; };

  This matches any host in the 10/8 network.

  Limiting recursion through the ACL

  Add the following to the options {}; statement in named.conf:

  recursion yes;
  allow-recursion { your-acl-name; };

  Do note the semicolons and the brackets!

• Use random query ports. Whilst in the past people had been using static ports for doing remote DNS queries, to make it easily go through firewalls, that's no longer an option. Recently ISC and CERT announced advisory's to address static-query-ports. It makes you very vulnerable to be spoofed, and could mean that secure.yourimportantbusiness.com suddenly points to my evil.notsoimportanthost.com so that I can trick your users into submitting their data on my machine, which I can then use to do very nasty things (like having a free holiday to the bahama's, I like it already!).

  In this case one should point out a DNS server, and tell that it can do queries from port 53 and>1024, I have been using this setup for ages, and I do know that a lot of larger companies also have similiar rules in their external firewalls. This allows the DNS server to pick a lot of random ports to do queries from.

  If you use a recursive DNS (because you are an ISP); then consider using only SSH and BIND on the machine (or whatever product you use). The machine does not need to be firewalled at all then , as long as you disable any unused applications. One could ofcourse filter away the SSH login, but having a stateful filter before a large DNS is just asking for problems (thanks Bjoern and Doug for this information!).

• Use DNS-SEC where possible. Currently not many TLD's support this, but if there is the possibility, you can add a security layer by using it. Ofcourse this does not prevent it forever, but it makes it again harder to do. And security is all about making the barrier too high to try (if the barrier is low, one will try, if it requires too much time or money, people will not do it that easily, though there is always someone that is willing to put in the required resources, keep that in mind).
• Always use the latest available version from your vendor where possible. It's sometimes a pain in your royal behind's to update the services you host. But do realise that mostly by running the latest (stable) release from your vendor, you can close many known holes. Yet it leaves you open for things not yet found ofcourse (but isn't that always the case): do plan these kind of actions and make sure you test such a setup first, or keeping the "old" machine alive till you are confident that everything works. You do not want to explain to some high-ranking boss that you didn't test, or that you cannot return to the old situation. (Something I learned to do is; install a new machine, and it's applications. Test whether the basic things that you expect it to do; still work. Unplug (yes do not power off!) the old machine and plugin the new one. If you worked through it for XX days, then you can backup the old machine (make sure you test the backup before really turning off the machine!) and turn it off.
• Ofcourse managers and people around you will complain that it will require a lot of resources; properly planning things will demand tme and money etc. But you can easily counter that by telling your boss or manager that in case something does go wrong, the damage is most likely higher. Point at your risk-index numbers that you periodically create (right!?) to show what kind of risk is involved.

The above are ofcourse a couple of open-doors, though we (Security People) see enough in the real world to know that the above isn't followed most of the time. Most bigger companies have the resources etc to properly do this, and some indeed use this to do the new setup, but many many many smaller companies are not using these kind of things at all, because it costs too much money. Please try to openly discuss these things with your company if you hit this. You are better off in the end if you properly discussed this, got a "no" anyway, and then things go wrong.

Hopefully the above helps a bit. I wrote this information stream based upon the latest CERT advisory for BIND, and having a few discussions here and there on the FreeBSD-Security Lists. Thanks Doug Barton, Bjoern A Zeeb to give me some thoughts about this (they might not be aware of this yet).

[/lang_en]

[lang_nl]

Terwijl de meeste mensen denken dat het beveiligen van je DNS server nagenoeg onmogelijk is, wil ik toch enkele hints en truckjes geven die het mogelijk maken om zoveel mogelijk problemen te voorkomen voor de DNS server.

Deze instellingen zouden eigenlijk gevolgd moeten worden door iedereen die ook maar een beetje geeft om zijn/haar DNS server!

Er zijn een aantal mogelijkheden om de DNS server zo veilig mogelijk te maken:

• Split de DNS servers, de interne netwerken doen waarschijnlijk queries naar buiten toe, en het externe netwerk serveert waarschijnlijk alleen internet zone's. Waarom zouden deze faciliteiten in één instance moeten zitten? Of in dezelfde 'view'? Verdeel de machines waar mogelijk, of in ieder geval verdeel ze over meerdere views, zodat de interne mensen externe domeinen kunnen bereiken en zodat externe mensen jouw eigen domein kunnen opvragen (SPLIT-DNS).
• Voeg ACL's toe en stel in dat recursieve queries niet zomaar mogen voorkomen. Als dat niet mogelijk is moet je zo goed als mogelijk je best doen om zoveel mogelijk mensen uit te sluiten (uiteraard wel toegang geven tot de mensen die het wel nodig hebben). Is het echt noodzakelijk dat jan de buurman jouw dns server gebruikt om www.triplexdomein.com op te zoeken? Internet Service Providers leveren de faciliteiten om deze queries alsnog te doen

  Een voorbeeld van een ACL in named:

  acl de-naam-van-de-acl { 10.0.0.0/8; };

  Dit verwijst naar alle machines in het 10.0.0.0/8 netwerk.

  Het limiteren van recursieve queries door de ACL:

  Voeg het volgende toe aan het options {}; statement van named.conf:

  recursion yes;
  allow-recursion { de-naam-van-de-acl; };

  Let op de punt-comma en de accolade's!

• Maak gebruik van willekeurige query poorten. Alhoewel men in het verleden statische poorten gebruikte om queries naar externe servers te kunnen doen, zodat het makkelijk door firewalls heen kon gaan, is dat geen optie meer. Recentelijk hebben ISC en CERT
  een beveiligingswaarschuwing eruit gestuurd om statische-query-poorten te addresseren. Dit betekende in het kort dat er heel simpel gespoofed kan worden wat kan betekenen dat veilig.ergbelangrijkewebsite.com ineens verwijst naar gevaarlijk.nietbelangrijkewebsite.com zodat ik bijvoorbeeld onwetende mensen belangrijke gegevens afhandig kan maken. Dit is is op dit moment heel simpel te doen. Ik kan daarmee bv een vakantie naar de Bahama's betalen, niet zo'n slecht idee... toch?

  In dit geval moet de beveiligings policy dusdanig ingesteld staan dat een server queries kan doen vanaf poort 53 en alles hoger dan 1024 (>1024). Deze setup gebruik ik zelf al jaren, en ik weet ook dat een aantal grotere bedrijven deze mogelijkheden ook bieden voor de eigen servers.
  Dit zorgt ervoor dat de DNS server een berg willekeurige poorten kan gebruiken voor externe queries.

  Als er een recursieve DNS Server gehost wordt (omdat je misschien een ISP bent); overweeg dan om alleen SSH en BIND (of welke DNS applicatie er ook gebruikt wordt) te gebruiken op de machine. In dat geval hoeft de machine helemaal niet extra beveiligd te worden met complexe firewall regels, zolang niet gebruikte applicaties maar verwijderd of uitgeschakeld worden. Uiteraard zouden de SSH login mogelijkheden beperkt kunnen worden, maar een stateful filter voor een recursieve dns server is vragen om problemen. (Bedankt Bjoern en Doug voor deze info!).

• Maak gebruik van DNS-Sec(urity) waar mogelijk. Op dit moment ondersteunen niet veel Top-Level-Domains(TLDs) dit, maar zodra mogelijk kan er een extra beveiligings laag toegepast worden door dit te gebruiken. Uiteraard stelt dit het probleem voorlopig uit, maar het maakt het op dit moment te complex/lastig om foutieve informatie te versturen. Immers, beveiliging is er alleen maar om de barriere zo hoog mogelijk te maken zodat het teveel tijd en geld kost om het bedrijf in kwestie aan te vallen, maar houd altijd in het achterhoofd dat er altijd wel iemand bereid is om deze kosten te betalen.
• Maak altijd gebruik van de laatst beschikbare software versies van de leverancier. Soms is het een enorme pijn om de diensten die geleverd worden up to date te houden, maar realiseer je dat het draaien van de laatste software de meeste bekende gaten sluit. Uiteraard houd dit je kwestsbaar voor problemen die tot heden nog niet gevonden zijn. Plan echter de acties en zorg ervoor dat de nieuwe opstelling getest kan worden, of door het instand houden van de machine tot je zeker weet dat alles 100% werkt. Je wilt namelijk niet aan de directie moeten uitleggen dat je niet meer terugkunt naar de oude situatie. Iets waarvan ik geleerd heb om een nieuwe machine op te zetten, met alle benodigde applicaties, testen of alles werkt, zoja haal de oude machine van het netwerk (niet uitzetten!) en koppel de nieuwe. Als dit werkt voor een vooraf bepaalde tijd, kan de oude machine gebackupped worden (altijd doen voor je hem uitzet) en kan hij daarna worden uitgeschakeld.
• Mensen, managers zullen altijd klagen dat dit een enorme berg geld en resources kost, het plannen en dingen kosten nu eenmaal geldt. Maar dit kan je makkelijk kaatsen door de baas en manager te vertellen dat in het geval er iets misgaat, de schade vele malen hoger is dan de kosten die hij nu maakt. Verwijs eventueel naar de index-cijfers die gemaakt zijn (Toch?!) om aan te geven wat de risico's zijn.

Bovenstaande zijn natuurlijk een aantal open deuren, maar wij (beveiligings mensen) zien nog dagelijks dat de meeste mensen deze aanbevelingen niet volgen. Grotere bedrijven hebben meer mogelijkheden om dit goed te doen, en inderdaad sommige kunnen het zich permiteren om een nieuwe infrastructuur op te bouwen, maar vele kleinere bedrijven doen deze dingen niet omdat het teveel geld kost. Probeer openlijke discussies te houden met het bedrijf waar je zit, als je hier tegen aanloopt. Je bent in een betere positie als dit eenmaal bediscussieerd is en toch een nee hebt gekregen, vooral als het daarna inderdaad misgaat.

Hopelijk helpt bovenstaande enigzins, ik heb bovenstaande informatie gebaseerd op de laatste CERT advisory voor BIND en door een X aantal discussies hier en daar op de FreeBSD-security mailinglijsten. Bedankt aan Doug Barton en Bjoern A. Zeeb voor het geven van enige informatie hierover, ook al zal dat onbewust geweest zijn.

[/lang_nl]