Metode sunt destule sa detectezi asa ceva dar iata un tool interesant aici. E un tool GUI, care poate fi setat sa faca si detectie la anumite intervale si mai stie sa citeasca si lista de servere autorizate in AD.

Tip: Masina de pe care il rulati trebuie sa aiba IP fix.

DNS Round Robin este un mecanism de balansare a incarcarii serverelor, sau altfel zis, de distribuire a conexiunilor catre mai multe servere. Nu o sa explic scenariile pentru care este folosit ci o sa ma concentrez pe modul de functionare. Sa luam exemplul in care avem 4 servere web care au acelasi continut (static), si dorim sa distribuim conexiunile care vin catre numele DNS test.winadmin.local spre toate cele 4 servere. Prima data va trebui sa cream urmatoarele inregistrari in DNS:

test.winadmin.local. IN A 192.168.1.10

test.winadmin.local. IN A 192.168.1.20

test.winadmin.local. IN A 192.168.1.30

test.winadmin.local. IN A 192.168.1.40

Daca serverul nostru DNS are activata optiunea Round Robin, atunci cand un client va incerca sa rezolve test.winadmin.local, serverul ii va raspunde cu toate cele 4 IP-uri care rezolva catre numele test.winadmin.local.

Ok, o sa spuneti ca teoria si manualele Microsoft spun cu totul altceva, bla, bla. Nici o problema, intr-un fel si manualul are dreptate. Raspunsul serverului este de fapt o lista, care contine toate IP-urile de mai sus, si din care clientul il va folosi pe primul din lista. La fiecare interogare noua, serverul va roti IP-urile din lista, in asa fel incat de fiecare data clientul va avea o lista cu IP-urile dar in alta ordine. Putem vedea ce primeste clientul folosing nslookup:

De ce totusi 192.168.0.40 ramane primul in lista? Pentru ca serverul DNS are activata optiunea “Enable netmask ordering”. Aceasta optiune aranjeaza IP-urile in lista pe baza IP-ului de la care a venit cererea, in asa fel incat sa ofere cea mai apropiata adresa de client. Netmask ordering are prioritate peste round robin, asa ca daca ambele optiuni sunt activate (default) IP-urile din acelasi subnet (se face un simplu match in binar) cu clientul vor fi primele in lista.

Mai sus am testat cu NSLOOKUP pentru ca trece peste cache-ul local si imi arata direct raspunsul serverului. Daca as fi incercat doar cu ping raspunsul ar fi fost cache-uit local. Putem dezactiva cache-ul de DNS oprind serviciul DNS Client pe statia de pe care testam. Serviciul este responsabil pentru cache-uirea raspunsurilor, asa ca daca il oprim nu o sa mai fie nevoie sa rulam ipconfig /flushdns dupa fiecare test. Stati fara grija, serviciul nu este responsabil pentru functionarea interogarilor, asa ca in scenarii de troubleshooting e chiar recomandata oprirea lui. Se face cu NET STOP DNSCACHE.

Iata si exemplu de captura cu Wireshark:

Sa revenim, ca de aici incepe “distractia”. Ce IP alege clientul din lista care tocmai a primit-o? Normal ar trebui sa il ia pe primul, ca sa poata beneficia de Netmask Ordering . Doar ca nu functioneaza ca in carti. Clientul mai face si el Netmask Ordering local sau altfel spus Subnet Prioritization. Deci indiferent daca noi am activat pe server optiunea Netmask Ordering sau nu, clientul alege cel mai apropiat IP. Si uite asa Round Robin-ul in clipa asta se duce pe rapa mai ales atunci cand avem in lista un IP din acelasi subnet cu clientul.

Ca sa dezactivam Subnet Prioritization pe client trebuie sa adaugam urmatoarea cheie in registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters\PrioritizeRecordData de tipul REG_DWORD si valoarea 0.

Insa optiunea asta merge doar pe Windows 2000/XP/2003. Sa va mai zic ca la Windows Vista lucrurile s-au schimbat? Complicat, nu? De Vista nu prea stiu mare lucru pentru ca este un OS mort si nici nu are rost sa-mi mai pierd timpul facand research pe el.

Dar stiu ca exista acest KB http://support.microsoft.com/default.aspx?scid=kb;EN-US;968920 care explica despre cum sa dezactivezi Subnet Prioritization. Iar algoritmul dupa care ar trebui sa aleaga IP-ul e descris aici : http://www.ietf.org/rfc/rfc3484.txt.

Si cum nu se putea altfel, modul de procesare a raspunsurilor serverului DNS s-a schimbat din nou in Windows 7. In Windows 7, valoarea pentru OverrideDefaultAddressSelection din KB-ul de mai sus e implicit 1.

Cu toate astea, Windows 7 ignora ordinea inregistrarilor primite de server si alege random (CRED, pentru ca nu am reusit sa stabilesc un pattern si nici nu am acces la codul sursa) o inregistrare din lista. Nu am reusit sa gasesc nici un mod prin care sa il fortez sa foloseasca primul IP din lista returnata de server.

 UPDATE: Se pare ca by default Windows 7 respecta raspunsul primit de server si alege primul IP din lista. Totusi, in cazul testului facut mai sus, cu IP-urile de acolo si cu un client cu ip-ul 192.168.0.131, lucrurile o iau razna. Daca reuseste cineva sa repete testul il rog sa ma anunte.

Pffff .. cam complicat Round Robin-ul asta pentru o singur bifa in consola DNS.

Combinatia Windows Vista sau 7 + wlan + vmware player sau workstation instalat – poate duce la mesajul de eroare din titlu atunci cand incercati sa initiati o conexiune VPN din meniul Connect To. Rezolvarea clasica e sa te duci in Network Connections din Control Panel si sa initiezi conexiunea de acolo.

O alta varianta intalnita pe net ar fi sa umbli in network binding order si sa speri ca nu o sa se mai intample.

Eu am mai descoperit ca daca restartezi serviciul WLAN Auto Config lucrurile revin la normal (conexiunea la WLAN se va pierde pentru cateva secunde). Tot e mai bine decat un reboot.

In ultimii ani am intalnit destul de des termenul DNS Poisoning (DNS Pollution sau DNS Cache Poisoning) si am vazut si ceva security hotfixuri legate de aceasta tehnica.  Cineva m-a intrebat de curand cum functioneaza. E o tehnica destul de veche dar interesanta. Sa explicam pe scurt:

1. Incercam sa facem o interogare pe domeniul dnstest.winadmin.ro

2. Serverul autoritar pentru inregistrarea dnstest.winadmin.ro este unul din NS-urile care imi tine zona winadmin.ro

3. Si aici intervine smecheria. Serverul meu raspunde ceva de genu: nu am inregistrarea dnstest, dar am delegat-o catre NS-ul www.google.com. Si ca sa nu te mai chinui ia si IP-ul lui www.google.com si tine-l in cache.

- va imaginati ca IP-ul returnat nu duce in nici un caz la google.

- daca serverul DNS are incredere in raspuns si cachuieste informatia – we are fucked up.

4. Probabil ca nu vom reusi sa accesam dnstest.winadmin.ro dar asta nu e important pentru atacator.

5. Nu are rost sa mai spun unde se vor duce cererile urmatoare catre www.google.com.

Foarte multe servere DNS au fost redirectate in acest fel tocmai pentru ca permiteau recursion. Azi am putea spune ca e destul de safe daca esti patch-uit bine, insa asteptam DNSSEC care o sa rezolve astfel de hibe.
DNS-ul e treaba serioasa. De asta nici nu recomand companiilor sa foloseasca forward catre serverele providerului.

PS: remember China Golden Shield Project?

Link-ul il gasiti in Navigation bar sau aici:

http://www.winadmin.ro/dnstools/dnspage.php

Ideea era veche si o discutasem pe ITBoard imediat dupa ce se inchisese dnsstuff.com pentru public. Nefiind un mare specialist in php nu am avut timp sa pun online decat cateva tool-uri. Daca doriti si altele imi puteti spune si poate le punem pe pagina.

Sper sa va fie de folos!

In acest tutorial vor urma pasii necesari pentru a configura si hosta o zona DNS pe un server Windows. Configurarea zonei DNS este primul task care trebuie facut atunci cand vrem sa hostam un website. Prima parte din tutorial este specifica domeniilor RO (achizitionate de la RNC – www.rotld.ro), insa principiul este cam acelasi pentru orice zona DNS.

Considerand ca ati achizitionat domeniul scurt.ro de la RNC si ati primit datele de conectare pe www.rotld.ro :

1. Logati-va la ROTLD, www.rotld.ro, si intrati in Administrare Domenii=>Online

2. Va duceti la NameServers

3. Acolo vedeti jos “formularul “ – apasati si definiti nameserver-ul (poate fi NS ca in exemplu sau altceva – atentie ca trebuie sa se potriveasca cu inregistrarea NS din zona; o sa vedem mai tarziu in tutorial)

4. Acum revenim la nameserver si punem ns.scurt.ro

5. Primim mesajul “Actualizarea a fost facuta cu succes!”

Acum ca am terminat de setat nameserverul la RNC e timpul sa setam zona DNS si pe serverul care o va hosta. In exemplul nostru vom folosin un Windows Server 2008.  Inainte de toate trebuie sa instalam serviciul DNS (folosim consola Server Manager).

Deschidem consola DNS din Administrative tools:

Definim zona exact ca in screenshoturile de mai jos:

Fiecare zona va fi stocata intr-un fisier local pe disk cu numele numezona.dns. Acesta poate fi folosit si pentru a muta zona pe un alt server.

Pentru zonele expuse in Internet nu este recomandat sa setam Dynamic updates.

Asa arata zona dupa configurare. Bineinteles ca nu o putem lasa asa si trebuie sa o “aranjam” putin.

In “properties” pe zona gasiti tab-ul  Start of Authority. Acesta este responsabil pentru configurarea inregistrarii SOA din zona.

Majoritatea administratorilor lasa informatiile de aici nemodificate. Wrong. Trebuie completate ca in exemplul de mai jos. Serial number ar trebui sa respecte urmatoarea regula: YYYYMMDDNN (an/luna/zi/numar modificare).

Windows-ul automat adauga numele serverului ca NS in zona. Acesta trebuie corectat si puse informatiile care sunt relevante pentru cei ce acceseaza zona din internet.

Adaugam numele serverului care l-am definit ca NS la RNC; IP-ul este chiar IP-ul serverului pe care ne aflam.

Si asa arata zona acum.

E cazul sa cream inregistrari in zona. Deja exista NS (am definit-o mai sus ca nameserver).

Mai adaugam o inregistrare dar la nume lasam blank. Aceasta este folosita pentru cazul in care vrem sa accesam websiteul folosind doar “scurt.ro” (fara nici un alt hostname in fata, gen www.scurt.ro).

Acum ca am creat inregistrarile e timpul sa testam ce am setat:

Din cate se poate vedea nameserverul este vizibil in internet si putem rezolva si inregistrari in zona.

Nota: Request timed out la ping nu are nici o relevanta in cazul nostru. Am vrut doar sa rezolvam numele scurt.ro la o adresa IP.

In partea a doua vom discuta si despre alte inregistrari din zona DNS si ceva setari specifice IIS in cazul in care ne hotaram sa hostam un website.

Nota: Articolul este scris la initiativa lui Andrei Ignat.

Chiar citeam intr-un alt articol aici pe site despre o problema cauzata de aceasta optiune din Internet Explorer:

Sfatul meu e urmatorul: daca nu stiti nimic despre aceasta optiune si aveti doar o vaga banuiala, atunci nu o folositi. O sa incerc sa explic acum cum functioneaza acest proces de detectie automata a setarilor (sa vedem si ce setari).

Optiunea “automatic configuration” se refera la capabilitatea browserului de a-si autoconfigura setarile pentru serverele proxy. Acest lucru se face prin rularea unui javascript script care se afla pe un server web. Scriptul mai este numit si Proxy Auto Config (PAC) si o descriere a formatului o gasiti aici. In screenshotul de mai sus se vede ca exista si optiunea sa specificati manual locatia scriptului.

Partea de “automatic” se bazeaza pe protocolul WPAD (Web Proxy Auto Discovery protocol) care este responsabil pentru localizarea scriptului de autoconfigurare. In acest scenariu scriptul trebuie sa se numeasca wpad.dat. Scriptul poate fi localizat de browser prin doua metode:

1. Optiunea DHCP 252 (atentie ca nu toate browserele suporta aceasta optiune iar pe unele OS-uri nu toti userii o pot folosi (W2K); documentati-va inainte).

La nivel de DHCP putem distribui locatia scriptului de configurare (wpad.dat) pentru toti clientii serverului. Valoarea optiunii arata ceva in genul:

http://servername.domain.local:80/wpad.dat

In functie de serverul de la care isi iau IP, sau scopul din care li se aloca IP, clientii pot primi fisiere de configurare diferite. Avantajul optiunii DHCP este ca ai ceva mai multa flexibilitate asupra locatiei in care se afla scriptul (inclusiv port).

2. DNS. Din ce am vazut pana acum, e cea mai populara metoda.

Metoda se bazeaza pe existenta inregistrarii WPAD in zona DNS din care face parte clientul. Sa luam exemplu in care calculatorul meu are setat ca primary DNS suffix zona domain.local. In momentul in care pornesc browserul, acesta va cauta inregistrarea DNS WPAD in zona domain.local (wpad.domain.local).

Mai exact va incerca sa downloadeze scriptul de aici: http://wpad.domain.local/wpad.dat. In caz ca nu reuseste va mai incerca:

http://wpad.local/wpad.dat 

Daca ierarhia mea DNS ar fi fost mai mare, ar fi existat mai multe cautari. In caz ca nu il gaseste browserul va functiona fara setarile proxy (sau cu cele specificate manual).

Atentie: optiunea DHCP 252 are prioritate in fata cautarii in DNS a inregistrarii WPAD.

Concluzia:  Automatic configuration bazat pe protocolul WPAD si PAC poate fi folosit pentru a schimba setarile de proxy ale sistemelor din retea indiferent ca acestea se afla intr-un domeniu Active Directory sau nu. (Active Directory chiar complica implementarea WPAD in unele scenarii single domain; in acest caz e recomandata folosirea GPO). Daca nu ai serverul cu scriptul WPAD, hostul in DNS sau optiunea in DHCP – DISABLE IT.

Pentru a seta adresa IP statica folosim urmatoarea comanda :

netsh interface ip set address name=”Local Area Connection” static 192.168.1.10 255.255.255.0 192.168.1.1

Comanda necesara pentru a seta “preferred DNS server” este

netsh interface ip set dns “Local Area Connection” static 192.168.1.5

iar pentru “alternate DNS server” :

netsh interface ip add dns “Local Area Connection” 192.168.1.6

Daca folosim si WINS :

netsh interface ip set wins “Local Area Connection” static 192.168.1.6

Cum facem sa rulam toate aceste comenzi,sau o parte din ele, fara prea mult efort (asta e pentru lazy admins, ca mine): foarte simplu, deschidem un notepad, copiem toate comenzile dorite, fiecare pe cate o linie si salvam fisierul cu extensia bat. Cu un dublu click pe fisierul bat se vor rula local toate comenzile.

Pentru a trece de pe static pe dhcp e si mai simplu :

netsh interface ip set address “Local Area Connection” dhcp

iar pentru dns :

netsh interface ip set dns “Local Area Connection” dhcp

Si tot pentru lazy admins : cu psexec.exe (din PSTOOLS) putem modifica setarile TCPIP si de la distanta :

Ex:

psexec.exe \\computer netsh interface ip set address name=”Local Area Connection” static 192.168.1.10 255.255.255.0 192.168.1.1

sau :

Psexec.exe \\computer netsh interface ip set dns “Local Area Connection” dhcp

Sau putem rula comanda sau comenzile pe mai multe computere astfel:

Psexec.exe @computers.txt –c setari.bat

Computers.txt contine numele sau adresele IP ale computerelor vizate

Setari.bat contine comenzile pe care vrem sa le rulam. Se pot face diverse combinatii. Desigur, nu putem seta IP static la o lista de computere, sau nu stiu eu.

Ca sa fie mai usor, cele doua fisiere le copiem in acelasi folder cu psexec.exe, pentru a nu mai trebui specificata calea catre ele.

Desi cred ca stiti deja, va mai aduc si eu aminte ca rularea remote a comenzilor trebuie facuta cu credentialele unui user care are drepturi de administrator pe computerele vizate.

Sper sa fie de ajutor.

Printre improvmenturile ce tin de DNS in ultimele versiuni de Windows se numara si Conditional Forwarding. Bine, bine, asta era si in 2003. W2K8 vine cu ceva nou aici si anume replicarea Conditional Forwarders pe toate serverele din domeniu (sau forest).

Intr-un scenariu cu un singur server de DNS asa ceva nu ajuta la nimic. Dar in cazul in care avem un forest AD destul de stufos cu multe DC-uri si implicit cu multe servere DNS iar rezolutia de nume e ceva mai “imbarligata” atunci asa ceva ajuta. Sa luam cazul in care facem un trust cu un alt forest. DC-urile mele trebuie sa rezolve nume din celelalt domeniu, iar consultantii au ales sa folosim DNS forwarders (asta pentru ca nu stiu sa foloseasca Stub Zones). Sa setez sau modific forwarders pe toate DC-urile? Cam peste mana, nu?

In W2K8, regulile de conditional forwarding pot fi stocate in AD si pot seta scopul replicarii (toate serverele DNS din domeniu sau forest).

De retinut ca se aplica numai pentru Conditional Forwarding, nu si pentru Forwarding-ul DNS normal (am incercat cu zona . si nu merge ). E de inteles pentru ca scopul acestei optiuni e pentru scenariile de rezolutie interna de nume, nu pentru internet. Daca as aplica asa ceva pe toate serverele din domeniu fara posibilitatea ca sa exclud anumite servere de acolo (cele care raspund ce rezoltia de nume in internet) as da totul peste cap. Asa ca e bine ca optiunea e restrictionata doar pentru Conditional Forwarding.

PS: aruncati o privire si pe Stub Zones. Am dat de multi specialisti care se fereau de asa ceva. Poate si pentru ca documentatia era cam greoaie pe vremuri.

Un scenariu de care m-am lovit in ultimul timp a fost sa monitorizez via script daca anumite sisteme sunt online. Numele sau IP-urile sistemelor le aveam intr-un fisier TXT. Am facut si scriptul, nici o problema pana aici, doar ca lista continea cateva sute de sisteme iar scriptul facut in VBscript rula pentru minute bune pana cand termina toata lista, asta si pentru ca nu poti sa lucrezi multithread in VBscript Un coleg a refacut scriptul in Python si ca sa vezi … aveam outputul in cateva secunde, nu in 15 minute.

Zic, il fac in Powershell, m-am lasat pagubas in scurt timp (nu de tot ca vreau sa-mi fac propriul cmdlet care sa faca asa ceva).

Dupa asta un alt coleg mi-a adus aminte de NMAP, si se pare ca daca nu vrei sa ai de-a face cu scripturi in Python, cam asta e cea mai buna solutie. Iata si un exemplu:

Ceva mai rapid ar fi cu –v in loc de –R (fara –v sau –R output-ul arata doar hosturile care sunt UP)

NMAP are si parametri prin care poti influenta paralelismul, doar ca eu nu i-am vazut sa functioneze si pentru ping scans. Oricum functioneaza multithreading, insa eu nu am reusit sa-l optimizez dupa bunul meu plac; de fiecare data incepe cu o grupa mica de 5 IP-uri.

De fapt a mers cu –max-parallelism 1 cand a facut aceeasi scanare in 60 de secunde.

Si putem sa trimitem totul catre |findstr down pentru a vedea doar host-urile care nu raspund la ping:

PS:In continuare folosesc scriptul facut in Python. Poate o sa-mi termin si cmdlet-ul ca sa am mai multe variante.