Instal·lació de certificats SSL a servidors HTTPS

Accedir a un servidor SSL requereix de l’ús de certificats per encriptar i validar la comunicació. Si som fidels debots de la “Virgen del Puño” i volem estalviar-nos uns eurus, podem instal·lar una entitat certificadora de Windows (o pels més debots encara de la “Virgen del Puño Ensangrentao”, fer servir el openssl de Linux), i crear el nostre propi certificat.

Amb això podem tenir un servidor que encripta les comunicacions, però en cap cas estem validant que el servidor amb el que alegrement estem intercanviant les dades sigui el nostre, ja que pot ser un atacant que fa ús d’una eina d’atac man-in-the-middle. Quan accedim al servidor, ens demanarà si creiem que el certificat que se’ns mostra és vàlid. Al dir que si, estem creient cegament que estem accedint al servidor que se’ns diu, però ningú pot assegurar que estem accedint a un atacant que està al mig de la comunicació.

Per si de cas encara algú es pensa que això dels atacs man-in-the-middle es cosa de paranoics retorçats, o que és ciencia ficció, adjunto un link perquè qualsevol persona pugui fer un atac d’aquests amb 3 o 4 clicks del mouse: http://ettercap.sourceforge.net/

Tornem al principi. Si volem posar un servidor SSL a Internet, cal que tinguem un certificat. Aquest certificat cal comprar-lo a una entitat certificadora, que no és més que una empresa amb un cert prestigi que avala la nostra identitat. D’aquesta manera, si algú veu que tenim un certificat d’aquesta empresa, doncs es creurà que no som un atacant, sinó que som un servidor segur per enviar les seves dades.

De empreses que facin d’entitat certificadora n’hi ha moltes. Les més interessants, però, són les que han aconseguit que el Internet Explorer o el Firefox les integrin en el seu interior. Així, a l’accedir al servidor, el navegador ja coneix la CA (entitat certificadora) que ha generat el certificat de servidor, i ja ens reconeix automàticament el servidor com a vàlid, sempre que el nom del certificat coincideixi amb el nom que hem escrit a la barra d’adreces del navegador.

Però hi ha una cosa que cal fer prèviament per posar en marxa el servidor, i mostraré aqui els 4 passos:

- Generar un CSR amb les dades bàsiques per obtenir el certificat: nom, empresa, país, nom dns complet del certificat, i alguna altra dada.

- Enviar el CSR a l’entitat, i aquesta després de validar-ho amb les dades del WHOIS o algun altre requeriment (i cobrar-nos, clar), ens envien el certificat ja generat.

- L’instal·lem en el servidor. Aquest servidor cal que tingui el port 443 (HTTPS) obert cap a Internet. Si és un altre port, pot ser que ens trobem problemes si el client està en una xarxa amb proxy, però sinó funcionarà igual. També es recomanable que no estigui a la xarxa interna, sinó que es trobi en una DMZ. Si algú no sap que és, hi ha un altre article en el bloc que ho comenta.

- En el servidor també cal que mirem si funciona la cadena de certificació. Si la màquina servidora ja reconeix la entitat root (de la llista que porta internament), cal que posem també la CA que ens ha generat el certificat com a Entitat intermèdia. Per això necessitem el certificat de la CA. En el cas de Windows només cal posar “mmc”, afegir el complement de certificats del My Computer, i afegir el certificat on posi entidades emisoras de certificados intermedias. També hem de validar que el certificat del servidor està posat a la part “personal”, i també validarem que la empresa que crea el certificat està posada a la part de Entidades emisoras de certificados raiz de terceros.

En aquest punt ja tenim el servidor operatiu. Ara ens deixarà connectar-nos sense problemes sempre i quan el navegador ja reconegui la entitat certificadora i l’empresa que l’ha generat (seguint la cadena de certificats). Pot passar, en el cas de les PDA sobretot, que el navegador que ens cal no reconegui aquesta entitat, perquè porten menys integrades de sèrie. Aleshores només hem de posar la entitat certificadora previament a la PDA, perquè la reconegui.

Cal recordar que els certificats no són eterns, i per tant caldrà renovar cada any, o cada dos anys el certificat, seguint aquest procés.

Com crear una SAN iSCSI barata, barata

A vegades per fer proves va bé tenir una SAN disponible pel VMWARE. Així podem fer proves de balanceig, etc.

Podem crear aquesta SAN mitjançant eines gratuïtes (per a ús personal) com el StarWind, de la companyia RocketDivision.

El trobem a: http://www.rocketdivision.com/download_starwind.html 

Només cal instal·lar aquest servei en qualsevol PC amb prou disc per les nostres proves i assignar-li uns quants giges a la unitat iSCSI.

Aleshores després de configurar el VMkernel per l’iSCSI, al fer un Rescan de la IP del nostre PC apareixerà el volum de dades compartit.

Hi ha més eines, però aquesta l’he provat i va bé.

Està clar que el rendiment que obtindrem amb aquesta eina i un PC amb un disc IDE o SATA no és per despentinar-se, però es vàlid per un entorn de test.

Com crear una imatge amb Boot CD de Windows PE per un HP DL360 G5

Hem instal·lat un server amb tots els programes, pedaços, etc, i volem fer una imatge, per poder tornar enrera, per deplegar-la en un altre servidor, etc.

Podem usar alguna de les eines de tota la vida: Ghost, Acronis, etc, o bé podem fer servir el magnific entorn de Windows PE.

Què és el Windows PE? És el substitut dels discs d’arrencada de MS-DOS que tants i tants problemes ens han portat.

Per fer un disc d’arrencada de Windows PE necessitem diverses coses (totes gratuïtes):

- Windows Automated Installation Kit (AIK)

- Drivers de Xarxa del servidor

- Drivers de l’storage del servidor (si volem accedir a la SAN, també podem posar drivers de la tarja FC, però no crec que sigui una bona opció)

 

Aleshores instal·lem el WAIK. Un cop instal·lat, utilitzem la comanda copype.cmd per desplegar la instalació del Windows PE.

PAS 1)

copype x86 c:\winpe_x86

(també pot ser amd64 o ia64, segons l’arquitectura que tinguem).

Això ens crea en la carpeta c:\winpe_x86 una estructura d’arbre com aquesta:

c:\winpe_x86

c:\winpe_x86\mount

c:\winpe_x86\ISO

A dins de la carpeta, trobem els arxius necessaris per crear una ISO amb els drivers estandard i l’idioma anglés.

PAS 2)

Necessitem tenir el imagex dins de les eines del CD, per tant cal que el copiem de C:\archivos de programa\Windows AIK\Tools\<arquitectura>\imagex.exe, i el posem a c:\winpe_x86\ISO.

També necessitarem copiar la carpeta \servicing de C:\archivos de programa\Windows AIK\Tools\Servicing dins de c:\winpe_x86\ISO\Servicing.

I per últim, dues DLL de C:\windows\system32\msxml6.dll i msxml6r.dll, també a c:\winpe_x86\ISO\Servicing.

PAS 3)

Creem un arxiu que ens exclogui del imageX els arxius tipus tmp, el pagefile, etc. Aquest arxiu s’ha de dir  Wimscript.ini, i ha d’estar a c:\winpe_x86\ISO. Ho podem fer amb el notepad. El seu contingut seria aquest:

 
[ExclusionList]
ntfs.log
hiberfil.sys
pagefile.sys
“System Volume Information”
RECYCLER
Windows\CSC

[CompressionExclusionList]
*.mp3
*.zip
*.cab
\WINDOWS\inf\*.pnf
 

PAS 4)

Per instal·lar els drivers, només cal baixar-los i descomprimir-los en una carpeta. Després muntar la winpe.wim que ens ha generat la comanda anterior:

1) MUNTAR IMATGE: imagex /mountrw c:\winpe_x86\winpe.wim l c:\winpe_x86\mount

2) CARREGAR DRIVER: peimg /inf=<nom_del_inf> c:\winpe_x86\mount\windows

3) PREPARAR IMATGE: peimg /prep c:\winpe_x86\mount\windows

4) DESMUNTAR IMATGE: imagex /unmount /commit

5) COPIAR .WIM: Ara ja hem generat un nou arxiu .WIM. Només cal tornar a generar la ISO, amb el PAS 5)

 

PAS 5)

Crear la ISO:

oscdimg -n -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso

Després d’uns minuts, ja tenim un CD llest per arrencar el servidor. En arrencar, ens apareix una línia de comandes. Aleshores només cal veure a quina unitat ha muntat el CD, i executar el IMAGEX amb els paràmetres adeqüats:

Aquí tenim una seqüència típica:

- diskpart / list volume –> Aqui veiem on està el CDROM

- Canviem al unitat D: (o on estigui el CDROM)

- Podem usar com a unitat destí una unitat física, un USB o bé una unitat de xarxa, fent un “net use * \\servidor\carpeta /user:domini\usuari <password>”

 imagex /capture c: e:\imatge.wim “imatge del sistema”. Aqui hem posat e:, que seria la unitat destí.

Adjunto uns links de aquest procés:

ImageX Command-Line Options

Add a Device Driver to an Offline Windows PE Image

Crear enllaços simbòlics a Windows amb NTFS (Symbolic Link)

Des de Windows 2000 es poden crear enllaços simbòlics a objectes de NTFS. Aquests enllaços es comporten com els symbolic links de tota la vida a Unix (els creats amb el ln)

L’únic problema és que Microsoft no proporciona de sèrie les comandes per crear-los. Però per sort tenim diverses alternatives.

Kit de recursos de Windows 2000: linkd / delrp

CD de Windows: mountvol

Podem veure com s’utilitzen aquestes comandes aquí:

Cómo crear y manipular puntos de unión de NTFS

I després tenim la comanda del arxi-conegut Marc Russinovich, Junction 1.05

Ho podem trobar (al technet) en aquesta adreça:

http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

Problemes amb SIDHistory després d’un ADMT v3

Després d’una migració dels usuaris i grups d’un domini a un altre, ens trobem que no podem accedir als recursos anteriors, tot i que el SID History s’ha migrat correctament.

Primer el que cal fer és revisar que el SID History s’hagi migrat correctament. Per comprovar-ho, arrenquem el ADSIEDIT.MSC, desde Inici / Ejecutar.

Un cop a l’ADSIEDIT, busquem el nom de l’usuari a la part del DOMAIN, baixant per l’estructura d’arbre. En el usuari, baixem fins el valor Object SID. L’anotem.

Després anem a l’usuari ja migrat i fent el mateix procediment, busquem el SIDHistory. El valor d’aquest atribut ha de ser el mateix que hem trobat a Object SID.

Si està en blanc, cal que revisem els passos de la migració amb ADMT v3:

- Activar les auditories de “Account Management” en dos dominis

- Que els dos dominis estiguin en Mode Nadiu de 2000 o 2003.

- Crear un grup (sense usuaris) anomenat <domini_vell>$$$

- Que els dos servidors tinguin una relació de confiança en un sentit i en l’altre

- Que els dos servidors es puguin fer PING amb el nom NETBIOS i el nom DNS.

Si tot i així no va, podem revisar el SID Filtering.

Cal revisar amb la comanda NETDOM TRUST com està el SIDFiltering i el QUARANTINE.

Han d’estar el QUARANTINE desactivat ‘no’ (per defecte) i el EnableSIDHistory a ‘yes’

Les comandes són:

NETDOM TRUST <origen> /domain:<destí> /enableSIDHistory –> per veure l’estat

NETDOM TRUST <origen> /domain:<destí> /enableSIDHistory yes –> per activar

NETDOM TRUST <origen> /domain:<destí> /enableSIDHistory no –> per desactivar

NETDOM TRUST <origen> /domain:<destí> /quarantine –> per veure l’estat

NETDOM TRUST <origen> /domain:<destí> /quarantine yes –> per activar

NETDOM TRUST <origen> /domain:<destí> /quarantine no –> per desactivar

cal posar-les als dos servidors dels dos dominis.

Reiniciar la cache dels offline Folders

Quan usem la característica dels Offline Folders es crea una carpeta en C:\WINDOWS o C:\WINNT anomenada \CSC.

 Aquí disposem d’uns arxius sense extensió i una base de dades per controlar aquests arxius (en Windows Vista han millorat el CSC i els arxius tenen el mateix nom que els originals).

 Aquesta base de dades a vegades queda corrupta (com no!), i cal reiniciar-la.

 La solució proposada per Microsoft és Reinitialize, i consisteix en el següent:

• Anem a la carpeta, al menú “Tools”, a la opció “Folder Options”
• Busquem la pestanya Offline Folders
• Apretant SHIFT+DELETE li donem a “Delete Files”
• Reiniciem el PC

Això fa que la cache es reinicïi, reconstruint-se novament quan reinicia el PC. Si teniem algun arxiu sense sincronitzar, es perdrà. Aquest canvi no es pot desfer.

Com sempre podeu veure l’article que parla d’això aquí:

Managing Files, Folders, and Search Methods

Com canviar la política per defecte GPO de Windows

En sistemes molt tancats, a vegades perdem els permisos per poder fer algunes coses fins i tot en la pròpia màquina local. En aquest cas, poder restablir la política local (que editem amb GPEDIT.MSC o SECPOL.MSC) a una per defecte, per poder arreglar els desperfectes que la política del domini ha causat.

 Existeixen una sèrie de plantilles (templates) que venen per defecte amb el sistema operatiu que són la configuració inicial recomanada del sistema. Són les següents:

•	Default security (Setup security.inf)	Configuració inicial de la instal·lació del windows. Només per troubleshooting.
•	Domain controller default security (DC security.inf):	Política per defecte dels DCs
•	Compatible (Compatws.inf)	Política per maximitzar la compatibilitat amb aplicacions que no segueixen els estàndards	NOTA: No aplicar als controladors de domini.
•	Secure (Secure*.inf)	Política més segura però sense afectar a la majoría de programes
•	Highly Secure (hisec*.inf)	Política molt segura. Pot comprometre el funcionament d’alguns programes
•	System root security (Rootsec.inf)	Política per resetejar els permisos de l’unitat de sistema. Usar en cas de recovery
•	No Terminal Server user SID (Notssid.inf)

Per aplicar aquestes polítiques només cal que seguim aquests passos:

Aplicar una plantilla de seguretat

loadTOCNode(2, ’summary’);

1.	Fem click a Start, click a Run, escribim mmc i fem click a OK.
2.	Al menú File, fem click a Add/Remove Snap-in.
3.	Fem Click a Add.
4.	A la llista de Available Stand Alone Snap-ins, fem click sobre Security Configuration and Analysis, fem click a Add, després fen click a Close, i després OK.
5.	Al panell esquerre, fem click a Security Configuration and Analysis i revisem les instruccions al panell dret.
6.	Botó de la dreta a Security Configuration and Analysis, i busquem Open Database.
7.	A la casella File name, escribim un nom per la BBDD (o un nom nou si l’hem de crear), i aleshores fem Open.
8.	Seleccionem la plantilla de seguretat que volem aplicar (generalment Setup Security.inf), i aleshores fem click a Open per importar les entrades que hem seleccionat a la Base de dades.
9.	Amb botó de la dreta sobre Security Configuration and Analysis al panell esquerre, fem click sobre Configure Computer Now.

Aquest article el podem trobar aquí

Blue Screen en VMWARE al actualitzar de NT 4.0 a Windows 2003

Al fer l’upgrade d’una màquina de VMWARE en NT 4.0 a Windows 2003 apareix una pantalla blava amb l’error stop ID 0×0000007B.

Això és degut al tipus de controlador SCSI que incorpora el sistema operatiu.

 Windows NT 4.0 (igual que Windows 2000 i XP) incorpora el driver de BUSLogic, mentre que Windows 2003 incorpora només el driver de LSILogic.

 Es per això que al crear una màquina per Windows NT 4.0/Windows 2000 o XP cal especificar que el driver SCSI és BUSLogic, i si la màquina és per Windows 2003, caldrà especificar que es LSILogic.

 El mateix assistent del VMWare ja incorpora aquests canvis, però si fem upgrade de la màquina a Windows 2003, el driver no està inclòs al sistema operatiu, i el Windows mostra l’error INACCESSIBLE_BOOT_DEVICE.

 Per seguir amb la instalació del Windows 2003 cal que retoquem l’arxiu .VMX i afegim aquesta línia:

scsi0.virtualDev = “lsilogic”

Amb això podrem continuar amb la instal·lació normalment.

Com transmetre informació encriptada

Gràcies al fenòmen anomenat Web 2.0, la gent pot enviar o publicar continguts el multitud de llocs de manera gratuïta. El problema que apareix és el de la privacitat. Tot i que la majoria d’aquests llocs web utilitzen el protocol SSL, on tota la informació queda encriptada perquè ningú la pugui interceptar, els missatges queden emmagatzemats en text pla, el que provoca una inseguretat del que pot arribat a passar amb les nostres dades.

Per tal d’evitar aquest problema i garantir la privacitat, fa molts anys va aparèixer un sistema d’encriptació anomenat PGP (Pretty Good Privacy). Aquest sistema consistia en un mètode de signar i/o encriptar les dades per poder-les transmetre de manera segura a través d’un mitjà insegur.

L’esquema de funcionament és complexe, encara que el podem resumir en els següents conceptes:

Primer vaig a definir alguns conceptes:

1) Clau: es un conjunt de bytes (guardats en un arxiu generalment) que serveixen per realitzar les operacions de encriptat/signat dels missatges. Aquests claus generalment es creen de manera aleatòria.

1a) Clau Simètrica. Es diu clau simètrica quan podem encriptar i desencriptar un missatge amb la mateixa clau. Només cal que els dos interlocutos coneguin aquesta clau per poder enviar el missatge.

1b) Clau Assimètrica. S’anomena clau assimètrica al conjunt de dues claus diferents que permeten encriptar amb una de les claus, desencriptar amb l’altra i no poder aconseguir una clau partint de la base de l’altra.

2) Clau Pública. És la part de la clau assimètrica que hem de passar a tots els interlocutors que vulguem que desencriptin els nostre missatge. La podem passar per qualsevol sistema no-fiable, o bé fins i tot pujar-la a un servidor de claus.

3) Clau Privada. Es la part de la clau assimètrica que farem servir per encriptar el nostre missatge. Cal guardar-la en un lloc segur.

4) Servidor de claus. Es un espai públic a internet on la gent pot intercanviar les claus públiques. Si volem enviar un missatge encriptat a una persona, anem al servidor de claus i busquem la seva clau (generalment indexat pel e-mail)

5) Encriptar. Consisteix en el procés de agafar un text clar i llegible i convertir-lo a un conjunt de simbols ilegibles per qualsevol que no tingui la clau de desencriptació.

6) Signar. Consisteix en realitzar uns càlculs matemàtics sobre el missatge que volem passar per garantir que qualsevol modificacio del missatge original serà detectada. Al rebre un missatge signat podem tenir la certesa que el missatge no s’ha modificat i que prové de la font que especifica.

Un cop introduïts els passos, anem a proposar les eines.

El PGP va ser el sistema original, però al ser d’una empresa privada, ja no es gratuït. Fa uns anys va apareixer el GPG, el GNU PG, que bàsicament és el mateix, i es basa en l’estandard OpenPGP.

Les eines necessàries pel sistema operatiu Windows estan incloses en aquest paquet: GPG4WIN

Podem baixar la versió Lite i instal·lar-la en el nostre PC.

Un cop baixada, caldrà realitzar aquests passos, que no es detallen ja que cada versió del software pot canviar.

1) Crear una clau nova. Això crearà la clau privada i la clau pública. Generalment arrencarà un procés de càlcul de uns nombres aleatòris i ens demanarà una nova password per poder accedir a aquesta clau.

2) Pujar la clau pública a un servidor de claus (opcional)

3) Exportar i passar per qualsevol mètode la nostra clau pública a l’interlocutor que volem que ens envii el correu signat o encriptat. No cal que sigui un camí segur.

4)  Importar la clau pública del nostre interlocutor, que ens haurà passat en un arxiu acabat en .ASC (no sempre ha de ser aixi)

5) Un cop disposem de tot aquest sistema muntat, podem provar de crear un missatge, encriptat amb la clau pública del nostre interlocutor, i fer un copy&paste al client de correu que fem servir habitualment.

6) El nostre interlocutor podrà rebre el missatge, i desencriptar-lo amb la seva clau privada. Ja el pot llegir i ningú més que ell pot veure el contingut.

7) Ens respondrà. Encriptarà amb la nostra clau pública i ens enviarà el missatge. Nosaltres el podrem desencriptar amb la nostra clau privada.

Espero que hagi quedat clar tot el proces d’encriptat/desencriptat de missatges. Si teniu algun dubte, consulteu-me.

Com realitzar un anàlisi d’una pantalla blava BSOD

Hem tingut una pantalla blava. I ara què?

 Està l’opció senzilla d’agafar el Stop ID, i buscar-lo al Google. Això no serveix de massa. Bé, serveix per detectar si es un tema de hardware, per exemple, però gairebé sempre no indica masses coses.

 Aleshores està la opció dels valents, agafar el MEMORY.DMP i analitzar-lo.

Cada vegada que tenim una pantalla blava, apareix un MEMORY.DMP (bé, no sempre, es poden donar casos que no, com podem veure aquí). Suposem que si que el tenim, situat a C:\windows\memory.dmp..

Aleshores necessitem l’eina de debug de Microsoft, el Windbg. El podem trobar aquí.

També necessitarem els simbols. Pels qui no coneixin què es això del simbols, podriem que els programes binaris que executem estan fets en codi màquina. El codi màquina és molt difícil d’analitzar. Per poder fer un anàlisi del codi, afegim els simbols que ha utilitzat el compilador per crear el codi binari. Aquests simbols es treuen en la versió final del programa per accelerar la seva execució. Ve a ser com els Comentaris que els programadors afegeixen al codi per poder fer un anàlisi.

Els simbols depenen del sistema operatiu. Ademés, també depenen del service pack, dels hotfix, etc. Per això el millor es no baixar els simbols, sino que el més interessant és fer que es baixin a mida que calen.

Un cop instal·lat el WinDBG, anem a File / Symbol File Path, i afegim la següent línia:

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

(suposant que tinguem una carpeta C:\WEBSIMBOLS amb espai suficient per anar descarregant els simbols)

Un cop especificat això, cal que carreguem el MEMORY.DMP. Anem a File / Open Crash Dump i especifiquem on esta l’arxiu.

Un cop carregat (i sense que apareixin errors), podem analitzar el crash:

!analyze -v

Aquí comença l’anàlisi. Ens mostrarà quin mòdul és el que falla a MODULE_NAME o a IMAGE_NAME. Un cop identificat, podem fer click directament o bé executar la comanda:

lmv

Aquesta comanda ens volcarà tots els drivers que estaven carregats en el moment de la “petada”. Aleshores podem buscar el mòdul que hem detectat abans per tal de saber quin fabricant és.

Un cop tenim el fabricant, ja es tracta de buscar algún driver més nou, etc.

Si el error que dona es Pool_Corruption, aleshores el problema és més complexe.

Podem fer dues coses:

1) O bé reinstal·lar tots els drivers amb versions més noves, i tornar a passar el service pack (vigilar amb antivirus, impressores, etc).

2) O bé passar el Driver Verifier (verifier.exe), que ens farà una prova d’stress de cada driver.

ATENCIÓ: Cal preveure que la màquina fallarà molt, que es poden perdre dades (controlar tema Backup). També cal tenir el compte que un cop fem Ctrl+Alt+Del del inici de sessió, perdem la possibilitat de tornar a l’estat Last Known Good Configuration, pel que un cop reiniciat amb el driver verifier, caldria esperar sense fer res uns 30 minuts abans d’iniciar sessió, per esperar que falli algún driver.

També caldria habilitat un mode especial del pool per poder rastrejar posteriorment quin és el driver que falla:
How to use the special pool feature to isolate pool damage

Això ja seria troubleshooting avançat, que potser caldria posar en mans de Microsoft, o bé millor reinstal·lar el servidor.