Termenul de NAT one to one (sau Full Cone NAT) se refera la posibilitatea ca device-ul care face NAT sa mapeze in tabela lui de translatare o adresa dedicata si permanenta pentru IP-ul translatat.

Imi este cam greu sa explic principiile de baza asa ca doritorii pot citi mai multe aici: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html

In mare as putea sa spun ca ISA/TMG nu o sa faca niciodata Full Cone NAT asa cum este descris la Cisco. Asta si pentru ca este un firewall, iar principiul descris de Cisco este mult prea permisiv. In schimb anumite parti din acest model pot fi implementate cu ISA/TMG.

O sa incerc sa descriu doua din scenariile in care este nevoie de acest model de NAT, si cum pot fi ele realizate cu ISA/TMG.

Ca exemplu am luat o infrastructura care are 3 servere aflate in spatele unui firewall tip ISA/TMG.

In primul scenariu, se cere ca fiecare dintre serverele din reteaua interna sa poata fi accesat din exterior prin RDP pe portul default TCP 3389.

Hmm, pai cu un singur IP pe interfata externa normal ca nu se poate. Solutia trebuie sa arate cam asa:

Observati ca de data asta firewall-ul are mai multe IP-uri externe. Publicand portul 3389 pe fiecare IP in parte putem sa realizam foarte usor ceea ce s-a cerut. Server1 va putea fi accesat prin 193.68.17.1:3389, Server2 prin 193.68.17.2:3389 si asa mai departe. Acest scenariu poate fi realizat cu ISA2004/2006/TMG fara nici un fel de problema (prin Server Publishing). Multi “specialisti” cauta sa faca asa ceva cu ISA, insa auzind din diverse locuri ca ISA nu stie de NAT one-to-one renunta.

Acum sa luam un alt caz, foarte discutat si pentru care chiar era nevoie de o imbunatatire.  Cazul “outbound” in care un server din spatele lui ISA comunica cu un server din extern iar traficul trebuie sa iasa pe un IP dedicat. Cam toate discutiile de pe Internet se refera la scenariul cu serverul de email (care bineinteles ca are IP-ul lui dedicat si diferit de cel primar al lui ISA) care trebuie sa iasa in extern pe un anumit IP (de regula acelasi cu MX-ul, sau ca se se potriveasca cu nu stiu ce inregistrare PTR). Ei, cazul asta nu merge pe ISA 2004/2006. Toate conexiunile outbound ies prin IP-ul primar de pe interfata externa a lui ISA.

Cu toate ca e un inconvenient, nu e un capat de lume, dar multi se impotmolesc in asta.

Incepand cu TMG (probabil datorita valurilor de comentarii si sugestii de pe Internet) a fost introdusa si posibilitatea de a mapa traficul outbound pe un anumit IP (adica exact de ziceam mai sus), functionalitatea numindu-se Enhanced NAT. Nu e ceva foarte visibil in interfata TMG si din acest motiv o sa arat cum se face.

Obiectul de tip Computer de mai sus, contine IP-ul serverului de email.

External se refera la tot ce nu e cuprins in alta retea definita in TMG (adica tot ce e extern).

IP-urile respective trebuie sa fie adaugate pe interfata de retea externa.

Nota: cu 4 IP-uri pe placa externa, interfata TMG nu imi afisa nici un IP in lista. Probabil ca e un bug sau ceva specific setup-ului meu. Cu 2 a mers fara probleme.

In momentul acesta mai este inca un pas de facut. Sa mutam regula nou facuta inaintea celei generale de NAT (numita Internet Access).

Dupa aplicarea setarilor, traficul outbound de la serverul de mail va iesi prin IP-ul dedicat, restul prin IP-ul default de pe interfata externa.

Sper sa mai fi clarificat cate ceva si sa va fie de folos articolul,

Andrei.

UPDATE: Pe ISA 2004/2006 acest lucru poate fi facut cu IPBinder de la Collective Software. Atentie ca mesajul lor de marketing spune ca TMG nu stie sa faca asa ceva. WRONG. Mai sus aveti dovada ca poate.

Anumite componente ale produsului sunt schimbate semnificativ fata de vechile versiuni, insa acestea fiind destul de low level, nu vor fi observate de un administrator obisnuit. Si ma refer in special la integrarea cu Windows Filtering Platform.

Cate ceva despre system requirements:

- 64bit processor – dual core

- 2Gb RAM

Nota: merge si cu un core si doar 1Gb RAM, insa performantele lasa de dorit (de folosit in configuratia asta numai in mediu de test)

- 2.5Gb spatiu pe disk

- 2 placi de retea (pentru operarea in firewall mode)

- Windows 2008 SP2 sau R2 (x64)

- .Net Framework 3.5 SP1

- Windows Installer 4.5

- nu este suportata instalarea pe domain controller

- este suportata instalarea in VM

Astea sunt cerintele asa in mare. Restul de componente (roluri & features) sunt instalate de catre TMG Preparation Tool.

Mai multe detalii puteti gasi aici:

http://technet.microsoft.com/en-us/library/dd896981.aspx

Scenariu pentru care m-am decis sa fac acest tutorial arata cam asa:

Un server cu 2 placi de retea, una conectata la Internet si una in LAN, pe care ruleaza Windows 2008R2 + TMG 2010. In LAN am sisteme stand alone fara domain controller. Sau daca am, in acest scenariu nu doresc integrarea TMG cu Active Directory.

Inainte de a incepe instalarea este bine sa configurati partea de networking si sa va asigurati ca aveti conectivitata in retelele conectate, altfel dupa instalarea TMG lucrurile se complica, filtrarile de pe TMG facand diagnosticul mai dificil.

Tip:denumiti adapatoarele de retea cu nume sugestive.

Gateway se seteaza numai pe placa externa. In scenariul fara AD, setam DNS doar pe placa externa a serverului.

Inainte de pornirea setup-ului e bine sa actualizam sistemul de operare cu ultimele update-uri pentru a evita urmatoarele reboot-uri.

Preparation tool-ul imi instaleaza toate componentele necesare pentru ca TMG sa se poate instala. Cei care s-au jucat cu versiunea beta cunosc chinul de a instala manual aceste componente.

Normal ca vom dori sa instalam si serviciile TMG si consola de administrare.

Si abia in clipa asta incepe instalarea propriu zisa a TMG-ului.

Nota: Instalarea nu mai este la fel de rapida ca la versiunile ISA2000/2004/2006.

Acum urmeaza pasul cel mai important. Definirea zonei de adrese interne. Atentie! Aici trebuie sa puneti doar range-urile de adrese interne. Wizard-ul o poate face pentru voi selectand placa de retea interna (o sa adauge subnetul la care este atasata placa).

Instalaea este completa, acum urmeaza setup-ul initial care mi se pare enervant. As fi preferat sa ma lase sa imi fac eu regulile asa cum vreau fara nici o interventie din partea lui. Oricum este folositor pentru cei fara prea mare experienta cu acest produs.

Aici selectati modelul retelei voastre. Ceea ce am selectat eu mai jos se refera la un server cu 2 placi de retea care face legatura intre extern si intern. In lista se mai afla, modelul cu TMG in spatele altui firewall, si modelul cu TMG doar cu o placa de retea, folosit doar pentru webp proxy, caching si publishing.

Network template-urile iti definesc relatiile dintre retelele conectatae la TMG.

Avem si optiunea sa joinam serverul la domeniu insa nu o sa o facem pentru ca am spus ca mergem pe scenariul cu server standalone.

Web Protection se licentiaza separat ca subscriptie, insa din clipa in care instalati TMG aveti acces la acest feature cat trial 120 de zile.

Recomand sa bifati si Enable URL Filtering pentru ca este un feature foarte util.

NIS aka Network Inspection System este modulul de IPS si inspecteaza traficul pe baza unor semnaturi publicate de catre MS. Foarte util atunci cand nu a aparut fix pentru anumite vulnerabilitati, insa exista un model pentru traficul facut de exploit.

Acum instalarea si configurarea initiala a produsului fiind completa, rulam acest Web Access wizard, care ne poate ajuta sa definim primele reguli de acces.

Nota: by default dupa instalare, TMG blocheaza tot traficul (aproape) in & out, asa ca fara sa definiti reguli de acces, nu o sa functioneze nimic.

Urmatoarea optine va crea o regula care va bloca tot traficul ce se incadreaza in anumite categorii predefinite in TMG.

Categoriile le vedeti in fereastra urmatoare iar in spate sta serviciul Microsoft Reputation Service (o imensa baza de date folosita pentru a clasificata site-urile de pe Internet).

Urmatoarea optiune se refera la scanarea malware a traficului web ce trece prin TMG.

Nou in TMG exista optiunea de a face inspectie pe conexiuni HTTPS. Cu toate ca wizard-ul sugereaza activarea optiunii de inspectie HTTPS, recomand ca in aceasta etapa sa nu o activati si sa selectati Allow all HTTPS traffic. Activarea acestei optiuni fara sa intelegi foarte bine ce face si fara sa anunti end user-ul despre cum se poate schimba experienta lui de navigare pe web, poate crea probleme.

Urmeaza partea de web caching, unde e bine sa specificam dimensiunea cache-ului (in functie de spatiul pe care il avem la dispozitie si de traficul la care este supus serverul).

Si acum sa inspectam putin consola de administrare. Primul lucru observat sunt cele doua butoane Apply & Discard. Pentru a salva regula nou creata si setarile din Wizardul de configurare e nevoie sa aplicam modificarile cu Apply.

Mai jos am pus cateva imagini din consola:

Cam aici in Firewall Policy se desfasoara majoritatea activitatii de administrare.

Web access policy este de fapt un alt view al regulilor, dar doar pentru cele care contin protocoalele HTTP si FTP.

Putem observa aici ca prima regula blocheaza accesul la anumite categorii, iar ce trece mai departe este permis de urmatoarea regula.

Mai departe, m-am conectat pe un sistem din reteaua interna si am incercat sa accesez o pagina de pe internet. Inainte de asta am configurat in Internet Explorer adresa TMG-ului ca si web proxy. Este necesar sa configurez IE-ul asa pentru ca in regulile de acces nu am si regula pentru traficul DNS, iar clientul neputand sa interogheze servere DNS externe trebuie sa apeleze la TMG pentru rezolutia de nume.

Sesiunea web proxy poate fi vazuta in interfata de administrare si pot afla detalii mai amanuntite despre modul in care s-a efectuat conexiunea.

Si iata ca TMG functioneaza si este gata pentru a imbunatati performantele conexiunii la internet si pentru a bloca traficul de tip malware sau cel catre destinatii riscante pentru utilizatorii din reteaua mea.

Atat de aceasta data, insa voi mai reveni si cu alte scenarii si detalii de configurare mai avansate despre acest produs.

Doar ca nu am auzit noi, insa in realitate mai exista tool-uri pentru asa ceva. Articolul din link-ul de mai jos prezinta cateva tool-uri cunoscute:

http://www.techmixer.com/free-bootable-antivirus-rescue-cds-download-list/

Singura problema cu acest tip de devirusare ar fi ca in unele cazuri va fi nevoie sa faci si un sistem repair dupa. Dar macar stii ca ai devirusat sistemul.

Detalii aici: http://blogs.technet.com/wsus/archive/2010/03/31/microsoft-security-essentials-anti-malware-definitions-now-available-via-wsus.aspx

Deschidem consola Forefront Client Security și selectăm tabul Policy Management.

Selectăm New pentru a crea o politică nouă.

Îi dăm un nume și introducem un comentariu, ca să știm și peste 2 ani ce face politica respectivă

În tabul Protection selectăm dacă dorim protecție antivirus și/sau antispyware.

Selectăm când și cum să se scaneze calculatoarele (Full sau Quick) și dacă dorim scanare de tipul Security State Assessment.

Practic, SSA scanează unele aplicații, servicii, parole care nu expiră, utilizatorul Guest activat, actualizări neinstalate etc., ceva gen Microsoft Baseline Security Analyzer.

Mai multe detalii despre Security State Assessment găsiți aici http://technet.microsoft.com/en-us/library/bb418876.aspx, inclusiv lista cu tot ce se scanează.

În tabul Advanced configurăm când calculatoarele verifică dacă sunt definiții noi și, foarte important, putem alege dacă permitem verificarea de definiții de pe Microsoft Updates când calculatoarele nu au acces la WSUS.

Jos, la Client options, selectăm dacă permitem utilizatorilor să modifice setările făcute sau dacă au acces la consola antivirusului sau văd doar iconița acestuia în task bar.

În tabul Overrides specificăm ce se întâmplă dacă un virus anume este găsit sau o vulnerabilitate dintr-o anumită clasificare.

În tabul Reporting specificăm nivelul de raportare. Din experiența mea, nivelul 3 pare a fi cel mai ok.

După ce am creat politica, aceasta trebuie trimisă la clienți (calculatoare). Selectăm Deploy.

Metoda de deployment diferă în funcție de infrastructura fiecăruia. În cazul meu, toate serverele sunt într-un OU, deci metoda cea mai simplă pentru mine va fi să creez politica pe OUul respectiv.

Dacă ne uităm acum in Group Policy Management Console, o să vedem politica creată pe OUul specificat de mine. Politica ia un nume ciudat dar ar fi bine să nu-i schimbăm numele.

Dacă din consola Forefront modificăm politica, obligatoriu trebuie să-i dăm din nou Deploy.

Să vedem cum arată clientul de antivirus pe un server care a primit și a instalat deja FCS folosind WSUSul.

Două lucruri mai trebuie făcute pentru a avea o infrastructură funcțională 100%:

1. Crearea unui group policy pentru Windows Update. Acesta trebuie configurat să permită instalarea automată a actualizărilor care nu deranjează utilizatorii și nici nu cer restart (Allow Automatic Updates immediate installation) și specificarea serverului de WSUS (Specify intranet Microsoft update service location).
2. În consola WSUS, la Options – Automatic Approvals, trebuie creată o regulă care va aproba și instala definițiile pentru FCS.
   

Cam atât pentru o configurație minimă a produsului Forefront Client Security.

Instalarea, în mare parte, se face cu Next-Next și introducerea unor detalii mici. O să public mai jos doar pozele la pașii unde trebuie modificate anumite lucruri sau e ceva de comentat, în rest mergem pe setările implicite.

Primul pas la care ne oprim, este alegerea rolurilor pe care le vom instala. După cum știm, FCS poate fi instalat doar pe hardware x86, oficial. Neoficial, Distribution Server (practic un WSUS) poate fi și pe un server x64. Acest rol nu face altcevadecât să forțeze WSUSul să facă o sincronizare la fiecare oră. Și cum acest lucru poate fi setat din WSUS, Microsoftul neoficial suportă WSUSul instalat pe un server x64. Neoficial, pentru că, acum ceva timp echipa de produs a anunțat pe blogul său că FCS poate folosi un WSUS instalat pe x64 dar documentația produsului nu a fost actualizată cu acest mic detaliu.

Deci dacă aveți un WSUS instalat pe un server x64, nu instalați acest rol pe serverul respectiv. Doar modificați manual numarul de sincronizări pe care le va face WSUSul ținând cont de faptul că pe zi apar maxim 3 definiții pentru FCS.

Deci selectăm toate rolurile în afară de Distribution Server.

La pasul următor alegem serverul pe care avem instalat SQL-ul și pe care se va instala MOMul. În cazul meu serverul se cheamă Forefront.

Management group name îl voi lăsa implicit și o să specific doar un utilizator de domeniu care are acces read și write la SQL server.

În pagina următoare specificăm serverul pe care se va instala baza de date a FCS. Eu am modificat dimensiunea bazei de date pentru că nu am nevoie de 15 GB pentru ea.

Pe pagina următoare nu modificăm nimic.

Se verifică dacă sunt îndeplinite cerințele software și hardware. În cazul meu, nu e o problemă gravă deci pot să continui.

Se instalează FCS și dacă totul este ok, apăsăm Close.

Din meniul Start -  All Programs, deschidem Microsoft Forefront Client Security Console.

Și acum începe configurarea. Aici specificăm fiecare rol pe ce server este (în caz că nu am instalat totul pe același server).

Se verifică dacă cele specificate există și pot fi accesate.

Și acum se fac ultimele configurări și setări necesare FCSului.

Gata. Avem FCSul instalat.

Pentru a instala clientul de antivirus și antispyware pe calculatoare în domeniu, e nevoie de crearea de politici. Lucru pe care îl voi face în articolul viitor.

E vorba de http://www.microsoft.com/technet/security/Bulletin/MS10-015.mspx�
Ca cei care au testat inainte si nu au dat buzna nu au patit nimic serios.

Mai multe detalii la http://blogs.technet.com/msrc/archive/2010/02/11/restart-issues-after-installing-ms10-015.aspx

FCS este un produs care chiar mi-a plăcut. Sincer. Este foarte ușor de instalat, configurat, folosit și administrat.

Dacă încep să vorbesc despre System Requirements, o să o fac un pic altfel. Nu o să înșir toată lista cu SO și resurse necesare pe care le putem folosi, ci o să spun doar ce nu putem folosi sau nu este suportat. Fac asta pentru că ce suportă este deja de mult timp pe piață și nu toate produsele noi sunt suportate.

Deci, aici găsiți toată lista cu cerințele necesare: http://technet.microsoft.com/en-us/library/bb404245.aspx

Din toată pagina aia trebuie să reținem următoarele:

Pentru server:

- Nici un rol al FCS nu poate fi instalat pe un SO x64, deci Windows Server 2008 R2 dispare. Asta oficial, neoficial – vă spun mai târziu.

- SQL Server 2008 iarăși nu este suportat, doar SQL 2005 cu SP1 (pe Windows Server 2003), SP2 sau SP3 (pe Windows Server 2008).

- Minim WSUS 3.0 cu SP1. Cine mai are WSUS 2.0… nu știu de ce îl mai aveți…

Pentru client:

- Nu este suportat Windows 2000 fara SP4 și Rollup 1, XP fără SP2.

Dacă vreți să știți ce porturi trebuie să deschideți, aici găsiți toate detaliile: http://technet.microsoft.com/en-us/library/bb404251.aspx

Acum că știm ce nu putem folosi, să trecem mai departe și să instalăm FCS cu toate rolurile pe un singur server. Dacă aveți nevoie să împărțiți rolurile pe mai multe servere, găsiți aici tot ce vă trebuie: http://technet.microsoft.com/en-us/library/bb418915.aspx

Eu am un Windows Server 2008 cu SP2, actualizat la zi și membru în domeniu. Mai departe o să instalez toate prerechizitele necesare.

1. Microsoft .NET Framework Version 1.1 – http://www.microsoft.com/downloads/details.aspx?familyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en
2. Microsoft .NET Framework 1.1 Service Pack 1 – http://www.microsoft.com/downloads/details.aspx?FamilyID=A8F5654F-088E-40B2-BBDB-A83353618B38&displayLang=en
3. Microsoft .NET Framework 3.0 (teoretic, ar trebui să fie instalat deja, verificați în Server Manager/Features) – http://www.microsoft.com/downloads/details.aspx?FamilyID=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en
4. Folosind Server Manager instalăm IIS și ASP.NET.
   1. Server Manager, click dreapta Roles și selectăm Add Roles.
   2. La Select Server Roles selectăm Web Server (IIS). Next de două ori.
      
   3. Dacă nu sunt selectate deja, selectăm următoarele servicii:
      - Static Content
      - Default Document
      - HTTP Redirection
      - Directory Browsing
      - ASP.NET
      - ISAPI Extension
      - ISAPI Filters
      - Windows Authentication
      - Dynamic Content Compression
      - IIS Metabase Compatibility
      - IIS 6 WMI CompatibilityDacă ni se cere să adăugăm servicii adiționale, acceptăm valorile implicite.

       

   4. Next și Install.
5. Microsoft Report Viewer 2008 SP1 – http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bb196d5d-76c2-4a0e-9458-267d22b6aac6
6. SQL Server 2005 și SQL Server 2005 Service Pack 3.
   1. Instalăm SQL 2005 folosind setările implicite în afară de:
      La Feature Selection selectăm doar:
      Database Services, Reporting Services, Integration Services, Client Components
      

      La Service Account folosim un cont de domeniu și bifăm SQL Server Account:

      

   2. Instalăm SQL Server 2005 SP3.
7. Folosind Server Manager instalăm Group Policy Management Console.
   1. Server Manager, click dreapta Features și selectăm Add Features.
   2. La Select Features selectăm Group Policy Management. Next și Install.
      
8. Folosind Server Manager instalăm Windows Server Update Services 3.0 SP2.
   1. Server Manager, click dreapta Roles și selectăm Add Roles.
   2. La Select Server Roles selectăm Windows Server Update Services.
      
   3. Instalăm WSUS folosind setările implicite în afară de:
      La Database Options selectăm Use an existing database server on this computer.
      

      La Web Site Selection selectăm Create a Windows Server Update Services 3.0 SP2 Web site

      

      În Configuration Wizard, la Choose Product selectăm Forefront Client Security.

      

      La Choose Classifications selectăm Critical, Definition, Security, Service Packs și Updates.

      

9. Ultimul pas pe care îl vom face înainte de a instala FCS este să adăugăm site-ul de reporting la Local Intranet. În cazul meu, voi adăuga http://forefront.
10. Instalăm ultimele actualizări Microsoft.

În următorul articol vom instala FCS cu toate rolurile pe un singur server.

Se apropie. Sunt anuntate 13 buletine – 26 de vulnerabilitati, multe cu remote code execution. Pazea!

http://blogs.technet.com/msrc/archive/2010/02/04/february-2010-bulletin-release-advance-notification.aspx

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?