Category: Networking and Internet

OpenVPN roadwarrior over PROXY

Reading time: 2 – 4 minutes

Com ja sabeu fa uns dies em vaig montar un sistema per poder anar pel món amb el portàtil i connectar-me a la xarxa interna de casa, des de qualsevol lloc. Doncs bé hi ha llocs on no tenim una sortida a internet sinó que aquesta és a través d’un proxy, a vegades fins hi tot autenticat. Fins hi tot ens podem trobar en que no tenim ni DNS a la xarxa en la que estem sinó que tot es fa a través de l’HTTP PROXY.

Doncs bé quan ens ho posen tan difícil també podem usar l’OpenVPN per connectar a casa i fins hi tot navegar per internet a través de la xarxa de casa disfrutant de tots els serveis de la xarxa i no amb els ports ‘capats’ com ens obliga el proxy/firewall de torn. L’únic que cal és modificar la configuració del client d’OpenVPN per poder sortir a través del proxy de torn contra el port del servidor de l’OpenVPN que tenim a casa.

Al document on explicava com connectar-nos per VPN a casa, sent nosaltres roadwarriors, vaig posar el servidor al port 443/TCP. Doncs ara veieu el motiu, la idea és que si el servidor esta en aquest port el servidor proxy ens deixa passar a través seu per connectar-hi pensant que on connecteu és una web segura (HTTPs), al accedir a un servei xifrat el proxy/firewall no poden inspeccionar els paquets que passen a través seu i podem establir la VPN usant com a protcol de transport el SSL.

A continuació encomptes d’ensenyar-vos una connexió real amb un proxy d’una empresa el que faig és usar un proxy públic dels que hi ha per poder navegar de forma anònima per internet. Si en voleu una llista la podeu trobar a: llista pública de proxies. Concretament per la configuració de prova jo he usat el 194.80.193.161 pel port 8082. Així doncs al fitxer de configuració del client he afegit:

http-proxy 194.80.193.161 8082

Per disimular encara més el rastre de la vostre VPN podeu usar les següents comandes i el firewall en qüestió, ni tan sols olorarà que monteu una VPN:

http-proxy-option VERSION 1.1
http-proxy-option AGENT "compatible; MSIE 6.0; Windows NT 5.1"

Molt senzill,oi? si el proxy és autenticat podeu consultar el man openvpn les comandes per enviar l’usuari i el password. A mi de moment no m’ha calgut.

Apa doncs ja poden anar posant servidors proxy i firewalls que nosaltres ens les continuarem empescant per sortir a internet com deu mana i no pas reduint internet al servei de web. Que tot i ser dels més usats sempre és limitadíssim.

TinyGentoo i Abyss WebServer

Reading time: 2 – 2 minutes

g.png
TinyGentoo: Un petit howto de com ens podem montar una gentoo ben petitona tan pels nostres projectes embeded com per posar dins d’un DOM o un pendrive.

Parlant de coses petites no em podia oblidar parlar del Abyss Web Server un petit servidor web que vaig descobrir fa molt de temps. Malgrat podria servir per molts petits sistemes de producció el trobo l’eina perfecte per ’embedir’ dins d’un dispositiu mòbil o petit.

Algunes de les seves funcions són més que interessants com per exemple els S.O. soportats: Windows, MacOS X, Linux i FreeBSD. Suporta HTTP/1.1 i a més pot generar continguts amb temps d’execusió amb múltiples sistemes: CGI/1.1 scripts, ISAPI extensions, Server Side Includes (SSI). O sigui, que si voleu també hi podeu instal·lar un motor de PHP. Suporta pàgines d’error personalitzades, protecció per password, control d’accés per IP, anti-leeching i control d’ampla de banda. També diposa d’una interficie via web per configurar el servidor i moltíssimes més coses.

Ara bé lo dolent, la versió més completa és de pagament la versió X2, però la versió X1 és gratuïta i jo diria que és més que suficient per moltíssims projectes. Per cert, per instal·la-lo és tan senzill com descarregar-lo, descomprimir-lo i executar-lo. Connectem al port 9999 a través del navegador: http://localhost:9999 i a configurar-lo via web. Jo diria que no esta disponible el codi font :'(

Un parell de servers web molt lleugers també són:

MySQL crash

Reading time: 2 – 2 minutes

Per un dia que es posa a ploure i estic a casa treballant, tot un plaer per cert. S’ha posat a fer llamps i trons fins que ha marxat la llum uns 2s en un llamp que ha caigut ben aprop i el pitjor és que el SAI no ha tingut temps de fer saltar la bateria i se m’ha reiniciat el server. Cosa que tampoc seria tan greu si no fos perquè he perdut quasi 1h per poder re-iniciar el MySQL… bé per si a algú li passa algo semblan aquí tenius els sintomes i el remei.

Després de mirar els fitxers de logs de /var/log/mysql tan el mysql.err com el mysql.log. No he trobat res que m’indiques quin era l’error de fet, podriem dir que no hi havia res que parles d’erros. Així que m’he decidit a passar al mètode radical i veure quins errors donaven les cirdes a sistema que feia al llençar el servei:

strace -f -o mysql.trace /etc/init.d/mysql start

L’únic que he trobat és un petit inidcador de que el InnoDB no s’iniciava bé. Gràcies a aquesta pista he arribat fins als formus de gentoo on he trobat aquest post: MySQL doesn’t start anymore after upgrade to 4.0.25 tot i que le títol no és gaire indicatiu del meu problema, en un comentari he trobat la solució:

cd /var/lib/mysql
rm ib_logfile0
rm ib_logfile1
rm ibdata1

Tornem a llençar el servei i tot solucionat, s’havien corromput uns fitxers de logs que usa l’storage del motor de MySQL i al borrar-los s’han tornat a generar. Quin patiment per tanta tonteria.

Consum d’ampla de banda de l’OpenVPN

Reading time: 1 – 2 minutes

Com que he de montar algunes VPNs amb GPRS/UMTS i l’OpenVPN entre servidors i clients linux, doncs m’he decidit a fer una prova per fer les estimacions de costos d’aquests enllaços. Així doncs m’he ajudat de l’eina mesure feta pel pancake. Una d’aquelles petites meravelles que ens brinda el GPL. Doncs bé amb el codi que veieu he extret el següent calcul:

time ./mesure -i eth0 -K -p "tcp and port 443"
168
real    60m30.922s
user    0m0.004s
sys     0m0.004s

Com podeu veure he llençat el mesure durant 60min i 30s amb 922ms, el tràfic que s’ha cursat pel port 443 tcp que és on he aixecat i he parat l’VPN durant aquest temps ha estat de 168KBytes. Aquest tràfic sense que per dintre de la VPN passes cap dada meva, simplement dades del propi openvpn per tal de manterir l’enllaç aixecat.

Una altre dada que us pot interessar és que només per aixecar l’enllaç es consumeixen 16KBytes i per baixar-lo uns 2KBytes. Ara cadascu que tregui les seves propies conclusions sobre si és molt o poc.

OpenVPN roadwarrior (client windows)

Reading time: 4 – 6 minutes

Com us comentava al meu anterior article OpenVPN roadwarrior (server i client linux) també podem tenir un roadwarrior de la nostre VPN funcionant amb windows. Així que us descriuré breument com configurar aquest client configuració que és pràcticament idèntica a la del client linux.

El primer que hem de fer és clar, és baixar el paquet de l’openVPN per windows, el podeu trobar a la web de l’openVPN GUI for Windows. Després de descarregar-lo el podeu instal·lar on més us agradi un cop fet això comença la part interessant.

NOTA: si llegiu la documentació de l’openVPN per windows veureu que no he col·locat els fitxers de configuració a les direccions on ell espera trobar-les. I tampoc uso la propietat de servei de windows que pot tenir el programa. Però si ho voleu fer com ‘deu mana’ només cal modificar les rutes i treballar amb el servei de windows encomptes del meu script. Però jo he preferit fer-ho així de cara a tenir un control més personal del programa. Odio la transaparència del windows, prefereixo el meu sistema. Tot són gustos.

NOTA II: els mac també tenen un client d’openVPN anomenat Tunnelblick GUI for mac OS X. Però no tinc el gust de disposar d’un mac per provar i explicar-vos com va, us haureu de conformar amb les instruccions de la seva pàgina web.

Certificiat client

Aquesta part és igual que en linux, o sigui, que podeu mirar el post que us comentava més amunt i sabreu com es fa. Un cop tinguem el certificat client i la clau privada, copiem aquests dos fitxers juntament amb el ‘root CA’ a una carpeta de windows. Jo el que he fet és crear-me una carpeta que es diu openvpn a l’escriptori i dins he creat el directori certs, on hi he copiat els tres fitxers.

Configuració del client

Dins de la carpeta openvpn que comentava dins del punt anterior he creat un fitxer de configuració que es diu local.conf amb el següent contingut:

client
verb 1
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca ./certs/cacert.pem
cert ./certs/vpn-clientwin-cert.pem
key  ./certs/vpn-clientwin-key.pem

Com podeu veure el fitxer és pràcticament identic al de linux, només li he baixat el nivell de debug (verb 1) perquè aquí la sortida de logs es farà per consola i si pugem molt el nivell de debug ens ompla de bassura la consola.

Configuració interficie TAP/Win-32

Després d’instal·lar el paquet d’openvpn per win veureu que teniu una nova interficie de xarxa:

interficie.png

Aquesta interficie com podeu veure l’he renombra i l’he anomenat tun al fitxer de configuració que heu vist més amunt també uso la interficie tun i no la tap que és el nom del driver de l’interficie. La veritat no sé si hi té molt a veure això però havia tingut alguns problemes al configurar i al final m’ha quedat tal com veieu funciona.

Cal que tinguem la interficie configurada en mode DHCP, per tal de que agafi la IP de túnel automàticament:

configuracio.png

Script de llençament

Finalment el que m’he fet és un petit script (.bat) per llençar la VPN l’he anomenat vpn.bat i el contingut és tan senzill com:

cd "H:\Documents and Settings\Oriol\Escritorio\openvpn"
openvpn --config local.conf

Col·locar-me a la carpeta on hi ha tots els fitxers i després llençar l’openvpn informant-lo del fitxer de configuració que ha d’usar. És importnat indicar la carpeta de treball així el fitxer de configuració com podeu veure usa direccions relatives per referir-se als certificats. Molt més senzill que no pas haver d’escriure el ‘peazo’ directori absolut.

Depuració i proves d’ús

Aquí podeu fer les mateixes proes que amb el linux, també veureu que la interficie tun té el ‘cable de xarxa desconnectat’ fins que no es connecta l’VPN que passa a estar en mode ‘connectat’. Si feu un ipconfig /all des de la consola del windows també podreu veure la interficie tun amb la IP de túnel un cop connectada i si feu un route print les rutes estàtiques que li ha assignat el servidor de la VPN al crear-se la mateixa. Recordeu que això el servidor ho feia a través de la comanda push.

OpenVPN roadwarrior (server i client linux)

Reading time: 7 – 12 minutes

Doncs ja fa temps que sóc usuari de l’OpenVPN per mi un dels millors softwares per montar VPNs i pel que sembla no sóc l’únic, ja que a newsforge també es pot llegir un article que defensa el mateix: SSL VPNs and OpenVPN: A lot of lies and a shred of truth. Doncs bé fer un enllaç LAN2LAN ho podeu fer amb molt pocs segons, jo diria que amb menys d’1min. A més permet tan montar-les per tcp, com per udp, a més de passar per sobre de HTTP proxies d’això ja en parlaré en un altre article.

El que vull explicar aquí és com he configurat l’OpenVPN per poder connectar-me des de qualsevol lloc a la xarxa de casa (i d’altres xarxes que ara no venen al cas). L’autenticació i xifrat de l’enllaç el faré amb SSL/TLS. Així doncs quasi tot el que vaig explicar sobre CAs a l’article: HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A. ho podrem aplicar aquí.

L’esquema del que anem a montar el podeu veure en el següent gràfic:

Certificats

Així doncs, anem a resumir el tema dels certificats, com que tenim un servidor i un client, hem de generar el certificat pel servidor i pel client, no cal generar el CA, perquè ja en tenim un de l’article comentat. Així que ens col·loquem al directori ~/CA i creem els 3 fitxers tal i com indica l’article al que ens referim.

Ara tindrem els 3 fitxers de rigor:

newreq.pem -> petició de certificat que fem al CA
newcert.pem -> el certificat que ens torna el CA, després de signar la nostre petició de certificat
newkey.pem -> la clau privada del nostre certificat

Només afegir un comentari: mentre creem els fitxers comentats ens demani el ‘Common Name’ podeu posar algún nom representatiu ara no estem lligats a un nom de domini com en l’article en el que ens basem per crear els certificats. Per tal d’organitzar-nos el que farem és renombrar aquests fitxers amb els següents noms:

newcert.pem -> vpn-server-cert.pem
newkey.pem -> vpn-server-key.pem

La petició de certificat la podem borrar si volem. No la farem servir. Per completar els fitxers que ens fan falta per montar el servidor només cal crear el fitxer de paràmetres Diffie-Hellman. Escencialment ens ajudarà a establir VPNs segures en canals no segurs mentre s’intercanvien les claus simètriques que s’usaran per fer la VPN. Recordeu que les claus assimètriques (certificats que usem) només es fan servir com a mitja per establir un canal segur per on intercanviar una clau simètrica molt més ràpida de xifrar/desxifrar pels extrems que ens permetran mantenir un canal segur i el més ràpid possible.

Bé doncs creem aquest fitxer de paràmetres Diffie-Hellman: (dh1024.pem)

openssl dhparam -out dh1024.pem 1024

Jo només l’he fet de 1024bits però el podeu fer tan segur com volgueu 2048, 4096 o fins on tingueu ganes d’arribar. Jo he preferit no carregar els sistemes amb claus inútilment llargues pel tipus de seguretat que necessito. Bé doncs, ara només cal que creem els certificats del client tal i com hem creat els del servidor i com sempre us recomano canviar-li els noms al nou certificat, jo faré els següents canvis de nom:

newcert.pem -> vpn-client-cert.pem
newkey.pem -> vpn-client-key.pem

NOTA: Si voleu tenir més d’un client que es connecti de forma simultànea a l’VPN heu de crear un certificat per cada client.

Fitxer de configuració del servidor OpenVPN

Ara que ja tenim els certificats apunt els copio al servidor al directori /etc/openvpn/roadwarrior/certs. Anem a veure que hem de fer per preparar el fitxer de configuració, que en Gentoo va a /etc/openvpn/roadwarrior, al fitxer l’anomeno local.conf:

verb 5
status /var/log/openvpn-status.log
user nobody
group nogroup
persist-key
persist-tun
local 2.2.2.2
port 443
proto tcp-server
dev tun
comp-lzo
ca   /etc/openvpn/roadwarrior/certs/cacert.pem
cert /etc/openvpn/roadwarrior/certs/vpn-server-cert.pem
key  /etc/openvpn/roadwarrior/certs/vpn-server-key.pem
dh   /etc/openvpn/roadwarrior/certs/dh1024.pem
server 10.0.1.0 255.255.255.252
keepalive 10 120
push "route 10.0.0.0 255.255.255.0"

Si anem per ordre, a l’inici l’únic que fem és dir-li el nivell de debug que volem que es guardi i a quin fitxer. Després definim que el procés openvpn que tindrem corrent al sistema no tingui privilegis sobre el linux (nobody:nogroup). La part on comencem a tenir informació interessant és on ens indica amb la comanda local quina és la IP del firewall que esta escoltant peticions i ens diu que ho fa pel port 443 i sobre protocol TCP. Pot semblar una mica raro que escolti en un port pensat per ser usat per HTTPs però tinc els meus motius, de totes formes si no us agrada el port el canvieu. En un altre article que parlaré de com montar VPNs sobre HTTP proxies explicaré el perquè del port 443. Després li diem amb quina interficie de túnel treballarem i que usarem compresió per les dades que hi passin.

Arribem a la part de certificats on com veieu usem tots els fitxers que em creat anteriorment i el cacert.perm que és el certificat del ‘root CA’ que varem crear a l’article al que em refereixo tota l’estona. A les últimes tres línies el més destacat és que li diem de quin rang han de ser les IPs de la interficie de túnel, això ho fem amb la comanda server i després amb la comanda push llencem una ruta estàtica que li dirà al client com arribar a la LAN que tenim connectada a l’interior de firewall.

Si ara llenço el dimoni de l’OpenVPN (/etc/init.d/openvpn start) puc veure com el port 443 de la interficie pública esta escoltant les connexions que li arriben això ho podeu mirar amb un netstat -lpn.

Configuració del client

Primer comentar que el fitxer de configuració estarà guardat a /etc/openvpn/casa/ amb el nom local.conf i els certificats de client els copiem a /etc/openvpn/casa/certs/, anem a donar un cop d’ull al fitxer de configuració:

client
verb 5
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca /etc/openvpn/casa/certs/cacert.pem
cert /etc/openvpn/casa/certs/vpn-client-cert.pem
key  /etc/openvpn/casa/certs/vpn-client-key.pem

Com podeu comprovar la configuració del client és mínima, la part més important és la que amb la comanda remote indiquem quina és la IP pública i el port on hi ha el servei que ens ofereix la VPN. Fixeu-vos amb la comanda nobind on li diem que el client no ha d’estar escoltant a cap port, només obrir una connexió contra el servidor. Indiquem quins són els fitxers a usar pel certificat de client i el certificat de la ‘root CA’ i llestos, ja tenim el client a punt.

Per llençar el client, podeu igual que al servidor llençar la comanda /etc/init.d/openvpn start.

TCP vs UDP

Com podeu veure he montat la VPN sobre TCP però també es pot montar sobre UDP, és tan senzill com canviar la comanda proto tcp-server del servidor i proto tcp-client del client, per la comanda proto udp. Per traspassar alguns firewalls i per montar VPNs darrera de NATs sense redirigir ports és molt útil poder-la montar en NAT, ja us explicaré com es pot fer tot això amb un altre article.

Com ja he comentat abans si no us agrada el port 443, també es pot canviar pel que volgueu, no sé si a nivell de IANA es recomana usar algún port en concret per aquest tipus d’VPNs.

Depurar

Per veure quins són els missatges que treu el servidor ho podeu fer al fitxer que indica el propi fitxer de configuració, o sigui, /var/log/openvpn-status.log. Per veure els missatges del client podeu mirar el vostre fitxer de log’s general del sistema sovint: /etc/log/messages.

Si alguna cosa no us funciona us recomano que repasseu tots els passos comentats i que mireu els enllaços de les pàgines en que jo m’he basat per fer la meva configuració.

La prova

Com és lògic la prova de foc està en des del client fer un ping a una IP privada de la intranet de darrera el firewall, per exemple, si 10.0.0.1 és un server de la xarxa 10.0.0.0/24 doncs des del portatil fent ping 10.0.0.1 aquest ens hauria de tornar i si fem un traceroute -n 10.0.0.1 només hauria d’haver-hi dos salts, el firewall i el server destí. Perquè tota la comunicació va per dins el túnel i els salts que es fan per internet són transparents des de dintre el túnel.

Enllaços

Webs d’on he tret la informació per montar tot això:

Automontem el pendrive o les flash cards

Reading time: 4 – 6 minutes

pendrive.jpg

Si treballeu amb udev i us instal�leu el paquet autofs, amb quatre retocs al kernel i quatre l�nies de configuraci� podeu fer que quan us enxufeu un pendrive amb linux aquest es monti i desmonti autom�ticament. De fet, aquesta soluci� esta explicada de mil formes diferents en un munt de howtos i d’altres similars. Hi ha gent que arriba nivells de sofisticaci� brutals. Per� despr�s d’estar mirant ‘largo y tendido’ tota aquesta informaci� he decidit no complicar la cosa i montar algo ben senzill que em permeti anar per feina amb els pendrives i les flash cards; que �s el que m�s uso al port�til.

Doncs b� per comen�ar el que farem �s que quan es detecti que s’ha connectat un dispositiu de tipus /dev/sdX1 (sent la X=a,b,c,d,etc) que es monti autom�ticament. Com sabeu el sistema de fitxers virtual udev genera autom�ticament els fitxers que representen els dispositius i a m�s tamb� genera uns events que es poden capturar. Si voleu monitoritzar aquests events podeu executar la comanda udevmonitor i podeu provar d’enxufar i desenxufar, per exemple, un pendrive i veureu com es generen els events que comento.

Doncs b� el primer que he fet �s que es generi un symlink autom�tic al detectar-se una partici� en un d’aquests dispositius que comentava, per tal de que aix� passi nom�s hem de modificar el fitxer: /etc/udev/rules.d/00.rules per aconseguir la funcionalitat que comentava nom�s cal afegir-hi aix�:

BUS="usb", KERNEL="sd?1", NAME="%k", SYMLINK="pendrive"

Tal com comentava si busqueu una mica podeu millorar molt�ssim fent per exemple, que nom�s es generi el enlla� din�mic (symlink) si el dispositiu �s de la marca tal o qual, model no s� quin, o que sigui de tipus usb mass-storage, etc. B� doncs, un cop ja tenim l’enlla� din�mic ara el que farem �s que quan intentem accedir a aquest dispositiu es monti autom�ticament el dispositiu i que si passats X’s segons no s’ha usat el dispositiu que es desmonti solet.

Aix� que comento ho farem amb el autofs, per configurar el dimoni ho podem fer al fitxer /etc/conf.d/autofs jo l’�nic que he tocat del fitxer de configuraci� del dimoni �s el timeout per tal de que es desmonti als 2s de no usar-lo:

...
# additional options for automount, ie. timeout
daemonoptions = '--timeout 2'
...

Abans de llen�ar el dimoni, he modificat el seg�ent dels fitxers de configuraci� que es troben a /etc/autofs al fitxer auto.master he afegit aix�:

/var/autofs/removable   /etc/autofs/auto.removable

Despr�s he creat el fitxer auto.removable:

pendrive        -sync,dirsync,fstype=vfat,uid=1000,gid=100,umask=002            :/dev/pendrive

Amb aix� aconseguim que quan s’intenti accedir al recurs /dev/pendrive es monti a /var/autofs/removable/pendrive i despr�s per tal de mantenir l’estructura de directoris de tota la vida el que faig es crear un link a /mnt/pendrive que apunta a /var/autofs/removable/pendrive:

ln -s /var/autofs/removable/pendrive /mnt/pendrive

Ara si anem a /mnt/pendrive (cd /mnt/pendrive) i fem un ls veurem el contigut del dispositiu, potser el primer ls que feu no funciona doneu-li uns segons perqu� pugui reaccionar tot plegat, a mi em triga uns 3 o 4s entre punxar el dispositiu i poder-hi accedir. Si quan acabeu d’usar el pendrive sortiu del directori veureu que al fer un df -a ja no esta montat.

Com comentava hi ha milers de howtos molt millors que el que acabo de fer, per� jo amb aix� ja he sortit del pas. Alguns howto’s que podeu mirar:

NTP public servers

Reading time: 2 – 2 minutes

sunclock.gif

Doncs gràcies a les aportacions del brainstorm al blog, he descobert el pool.ntp.org, de fet ja el coneixia com a client, el que no m’havia plantejat era el senzill que resulta ser un servidor d’NTP (Network Time Protocol) del ‘public pool NTP servers’. Amb això m’asseguro que les meves xarxes més importants estaràn sempre amb els servidors horaris ben sincronitzats i a part passo a formar part de la xarxa pública de servidors NTP perquè tothom se’n pugui beneficiar.

Els serveis de sincronització horaria pels usuaris domèstics no s’acostumen a valorar però en aplicacions distribuides i sobretot si aquestes donen serveis empresarials (on hi ha calers en joc) el tema de tenir tots els dispositius de xarxa ben sincronitzats és vital. Imagineu-vos el caos que suposaria que un caixer automàtic anès amb el rellotge atrassat…. no vull ni pensar-ho. Doncs bé jo no tinc caixers automàtics però si quioscos i d’altres coses semblants distribuides que necessito que les transaccions que realitzen estiguin ben sincronitzades perquè després em quadri la caixa 🙂

Bé doncs, si algú vol afegir-se a la xarxa de la que us parlo passeu-vos per ntp.pool.org val la pena amb 5min esteu al dia i amb 5min més heu montat el vostre propi servidor NTP públic i esteu dins la xarxa. Com a curiositat les dues IPs on he montat els meus servidors horaris són: 80.35.31.228 i 83.175.213.76. Obviament pel port 123/UDP.

Subversion: recuperant el repositori

Reading time: 2 – 2 minutes

subversion.png

Ahir dissabte vaig estar fent updates d’un munt de servidors i com sempre diu la Daphne, si una versió d’algo va perquè carai l’has d’actualitzar. Doncs bé jo diria que quasi tot va quedar al seu lloc excepte el Subversion que després de montar de nou el mòdul WebDAV d’apache i el mòdul DAV_SVN per accedir al SVN des d’HTTP no hi va haver manera de que el repositori funcionés no parava de donar errors extranyíssims que l’oracle de la sabiduria google no em sabia resoldre.

Finalment us explico com ho vaig fer ja que a mi em va salvar la vida i quasi 1000 revisions de versions de software de la feina… bufff! quin descans. El truc és tan senzill com oblidar-se del Berkeley DB que és per on ho intentava arreglar jo. El Berkeley DB (bdb) és el format que usa SVN per guardar la informació al repositori del disc. Cal simplement usar un svnadmin dump i dirigir-lo a un fitxer. Després restaurem aquest fitxer de ‘dump’ al nou repositori amb el svnadmin load. Fàcil,eh!? doncs em vaig tirar més de 3h per descobrir això tan tonto per culpa d’intentar solucionar el tema amb el bdb i no directament amb el propi SVN.

HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A.

Reading time: 12 – 20 minutes

Com podeu veure aquest post té un parell de títols i suposo que seria molt senzill tenir-ne molts més. Així doncs intentaré descriure la idea del que després explicaré. El que pretenc fer parlant sense tecnisismes és disposar d’un servidor web que només sigui accesible de forma irrefutable i segura pels clients (navegadors) que nosaltres permetem. Això és útil per exemple per bancs, institucions, etc. tot i que en el meu cas és simplement per donar serveis via web als que només tingui accés gent controlada.

key.jpg

Per tal de montar això el que hem de fer és primer de tot montar una entitat de certificació, a la que anomenarem CA (Certifcate Authority). Això ens permetrà emetre tans certificats com volguem tan per servidors com per clients. De fet, perquè això es reconegui publicament només ens caldria que els certificats es signessin per una SA (Signing Authority) o autoritat de confiança. Perquè sapigueu de què parlo alguns exemples d’autoritats d’aquest tipus són: Baltimore, RSA, VeriSign i Thawte. De fet, si volem nosaltres mateixos podem fer d’SA el que no tindrem és la confiança de tercers, ja que no ens reconeixeran com a TA (Trust Authority). Però pel nostre exemple no ens cal així doncs nosaltres mateixos ens ho farem tot.

De fet, tota aquesta història de les entitats de certificació és molt més complexe, però nosaltres només arribarem fins on ens interessa. Intentant simplificar al màxim. Tampoc cal que ens montem una PKI (Public key infrastructure) professional per treballar amb algo tan senzillet. Així doncs, ja tenim clar que hem de montar una CA (root CA) que emetrà emetrà certificats signats per ella mateixa (self-signed certificate). Aquests certificats podràn ser usats per servidors i clients. Així doncs, si montem un servidor que usi aquest certificat podem fer que aquest requereixi que els clients disposin d’un certificat en mode client sinó no podran accedir al servei oferit.

Pel cas que ens interessa el que farem és montar un servidor web, Apache concretament, que només podrà ser accedit pels clients (firefox, netscape, MSIE, etc) que disposin del certificat corresponent.

Què necessitem per montar la CA?

Només cal que tingueu instal·lat el OpenSSL, jo com sempre uso Gentoo i el paquet que he usat és dev-libs/openssl-0.9.7e-r1. El fitxer de configuració més important d’aquest paquet està a /etc/ssl/openssl.cnf. Jo l’he modificat conretament on diu default_days = 365 he canviat el 365 per 3650 així els meus certificats encomptes de ser vigents durant un any seràn vigents durant 10 anys. Si voleu això també es pot alterar a través de la línia de comandes al llençar l’script CA.pl amb el paràmetre -days.

Com ja vaig comentar a l’article: Xarxa Wifi Segura: freeRadius + WRT54G = 802.1x (WPA-radius EAP/TLS), on també s’havia de montar una entitat de certificació la distribució gentoo no instal·la el fitxer CA.pl per defecte i pot ser que no el troveu pel vostre sistema després d’instal·lar el openSSL. Així doncs, jo el que he fet és descomprimir el paquet d’openssl i truere el fitxer directament d’allà i després me l’he copiat a un directori on treballaré a partir d’ara: ~/CA.

Creem la C.A. arrel (root CA)

Un cop dins de ~/CA per generar el certificat de l’entitat arrel (root CA) només cal que feu: perl CA.pl -newca.

$ perl CA.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 1024 bit RSA private key
......................++++++
.............++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:BCN
Locality Name (eg, city) []:BCN
Organization Name (eg, company) [Internet Widgits Pty Ltd]:example CA authority
Organizational Unit Name (eg, section) []:example
Common Name (eg, YOUR name) []:example CA
Email Address []:example@example.com

Veureu que es crea un directori que es diu demoCA i dintre hi ha el fitxer cacert.pem que és el certificat de la nostre root CA.

Emetem un certificat amb la nostre root CA

Primer el que fem és una petició de certificat (request): perl CA.pl -newreq.

$ perl CA.pl -newreq
Generating a 1024 bit RSA private key
...................++++++
.................................................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:BCN
Locality Name (eg, city) []:BCN
Organization Name (eg, company) [Internet Widgits Pty Ltd]:example company
Organizational Unit Name (eg, section) []:example e-comerce department
Common Name (eg, YOUR name) []:www.example.com
Email Address []:example@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem

Obtenim el fitxer: newreq.pem. Fixeu-vos que aquest certificat és pel servidor www.exemple.com. Si voleu emetre un certificat per qualsevol subdomini del domini exmemple.com, podeu posar a ‘Common Name’ el següent *.exemple.com. El que no he provat és posar * a veure si així funciona per qualsevol domini. Tot i que jo diria que no ha de funcionar, sinó el certificat no garintiria que el servidor és qui diu ser.

Signem el certificat emès

Aquest pas és el que hauriem de demanar a la entitat de confiança (TA) la qual després d’enviar-li el nostre certificat ens el tornaria signat (SA). Però que nosaltres som com el ‘joan palom’ (jo me lo guis jo me lo com) doncs ens ho farem nosaltres mateixo amb l’ordre perl CA.pl -sign:

$ perl CA.pl -sign
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            82:9d:18:98:a7:25:24:7e
        Validity
            Not Before: Oct  1 10:50:03 2005 GMT
            Not After : Oct  1 10:50:03 2006 GMT
        Subject:
            countryName               = ES
            stateOrProvinceName       = BCN
            localityName              = BCN
            organizationName          = example company
            organizationalUnitName    = example e-comerce department
            commonName                = www.example.com
            emailAddress              = example@example.com
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                EE:8C:BC:6F:3D:3B:4D:82:56:24:BB:76:E8:39:F3:23:F3:BD:C9:BF
            X509v3 Authority Key Identifier:
                keyid:EE:71:7F:C0:71:39:F1:8A:70:B4:BC:BB:F0:48:B2:77:58:E4:F6:AE
                DirName:/C=ES/ST=BCN/L=BCN/O=example/OU=example/CN=example/emailAddress=example@example.com
                serial:82:9D:18:98:A7:25:24:7D
Certificate is to be certified until Oct  1 10:50:03 2006 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

Ara ja tenim signat el newreq.pem dins del fitxer newkey.pem. A continuació el que farem és extreure la clau privada que hi ha dins del fitxer newkey.pem:

$ openssl rsa < newreq.pem > newkey.pem
Enter pass phrase:
writing RSA key

A newkey.pem hi ha la clau privada del ‘request’.

Renombrem els fitxer per aclarir les coses

Per tal de simplificar una mica tots els conceptes és una bona idea renombrar els fitxers que hem generat:

newcert.pem -> server_cert.pem: certificat signat pel nostre servidor. Això ens permetrà després crear la clau del client.
newkey.pem -> server_key.pem: clau privada (xifrada) en format de texte pla necessaria pel certificat del servidor. La clau privada és la part secreta del certificat, hem d'evitar que tercers la puguin aconseguir.
newreq.pem -> server_req.pem: clau privada xifrada i la petició de certificat original.

Creem el certificat pel client en format pkcs12

Resulta que els nostres navegadors volen els certificats de client en un format que es diu pkcs12 (Personal Information Exchange Syntax Standard) així doncs som-hi:

# openssl pkcs12 -export -in server_cert.pem -inkey server_key.pem -out iestuff.p12
Enter Export Password:
Verifying - Enter Export Password:

Aquí també podria haver canviat el nom del fitxer on es guarda la clau i no posar-li iestuff.p12 com els exemples en que m’he basat, però la mandra és el que té. Bé doncs, ja tenim el nostre fitxer pkcs12: iestuff.p12.

Instal·lem el certificat a l’apache

No us ho creureu però he trigat més estona en fer això que en tota la resta i mira que és senzill, però he aprofitat per actualitzar el servidor i resulta que el nou paquet d’apache per gentoo funciona diferent que l’anterior i no trobava res de res. A partir d’ara parlaré doncs de com fer això en net-www/apache-2.0.54-r31. Però donaré un apunt per estalviar temps als que no useu gentoo.

L’apunt l’únic que s’ha de fer és posar els detalls necessaris perquè funcioni el vostre servidor apache amb SSL i dels fitxers de configuració d’apache només heu de modificar el ‘VirtualHost’ que necessitarà el certificat. Així doncs a partir d’ara el que toca és veure la destresa de cada un amb les infitintes ordres que té l’apache pels seu fitxer de configuració.

NOTA IMPORTANT PER TOTHOM: no oblideu que quan treballem amb un VirtualHost dins de l’espai de configuració del mateix cal user el paràmetre ServerName; doncs bé el que poseu aquí ha de coincidir al 100% amb el que posa al ‘Common Name’ del certificat que heu emès. A més, el vostre DNS ha de resoltre el mnemònic que hagiu usat amb la IP del servidor sinó no funcionarà, a més el nom ha de ser un registre de tipus A i no un CNAME dins la configuració del DNS.

Bé doncs en el paquet de gentoo que comentat el que he fet és modificar el fitxer de configuració del host SSL per defecte, això es fa al fitxer: /etc/apache2/modules.d/41_mod_ssl.default-vhost.conf. Per llençar l’apache amb el host SSL per defecte s’ha de tocar el /etc/conf.d/apache2 perquè es llenci amb les opcions: -D SSL i -D SSL_DEFAULT_VHOST. Amb això el fitxer de configuració 41_mod_ssl.default-vhost.conf passa a tenir validesa. Aqust fitxer l’he modificat ben poc només perquè apunti on he copiat els certificats.

Fixer 41_mod_ssl.default-vhost.conf:

<IfDefine SSL>
  <IfDefine SSL_DEFAULT_VHOST>
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot "/var/www/localhost/htdocs"
ServerName www.exemple.com
ServerAdmin root@localhost
ErrorLog logs/ssl_error_log
<IfModule mod_log_config.c>
        TransferLog logs/ssl_access_log
</IfModule>41_mod_ssl.default-vhost.conf
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/server_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/server_key.pem
SSLCACertificatePath /etc/apache2/ssl/
SSLCACertificateFile /etc/apache2/ssl/cacert.pem
SSLVerifyClient require
SSLVerifyDepth  2
	<Files ~ "\.(cgi|shtml|phtml|php?)$">
    SSLOptions +StdEnvVars
</Files>
	<Directory "/var/www/localhost/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
	<IfModule mod_setenvif.c>
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
</IfModule>
	<IfModule mod_log_config.c>
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</IfModule>
	<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
</IfModule>
	</VirtualHost>
	</IfModule>
	</IfDefine>
</IfDefine>

He tret els comentaris que porta el fitxer perquè no es fassi tan llarg. Però la part més important us la comento a continuació:

ServerName www.exemple.com
SSLCertificateFile /etc/apache2/ssl/server_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/server_key.pem
SSLCACertificatePath /etc/apache2/ssl/
SSLCACertificateFile /etc/apache2/ssl/cacert.pem
SSLVerifyClient require
SSLVerifyDepth  2

La primera línia és la nota que us he posat abans sobre el ServerName, o sigui, posar-lo igual que el ‘Common Name’ del certificat. El certificat signat del servidor SSLCertificateFile, la clau privada del certificat SSLCertificateKeyFile el directori on guardem les entitats de certificació arrel (root CA) SSLCACertificatePath /etc/apache2/ssl/ i el fitxer que conté el certificat de la nostre entitat de certificació arrel SSLCACertificateFile.

Les últimes dues línies són les més interessants: SSLVerifyClient indiquem si cal que el client tingui o no tingui certificat. En aquest cas requerim que el client tingui certificat per funcionar. Finalment a la última línia indiquem quina és la tolerància que donem als certificats que acceptem. És a dir, fins a quina profunditat confiem amb les entitats que poden haver emès aquest certificat. Diguem que és un tecnisisme d’herència entre entitats de confiança jo hi he posat un 2 però podeu posar-hi qualsevol número >1 i funcionarà sense problemes.

Configuració del client

Aquí només us comento com es fa amb el firefox, però amb el MSIE i el Netscape es fa quasi igual, segur que us en sortiu. Jo no només he afegit el certificat client que seria el normal sinó també el certificat de la entitat arrel (root CA) així el navegador no em pregunta cada vegada si ha de confiar amb el certificat que rep d’una root CA que no coneix.

Anem al menú Edit -> Preferences -> Advanced -> Manage Cerficates:

firefox1.png

Ara instal·lem el certificat client, anem a ‘Your Cerficates’ i premem ‘Import’ seleccionem el fitxer i importem el nostre certificat iestuff.p12:

firefox2.png

Per instal·lar el certificat del ‘root CA’ anem a la pestanya ‘Authorithies’ premem ‘Import’ i importem el fitxer cacert.pem:

firefox3.png

Conclusions

Sembla molt llarg tot el procés, però realment no ho és tan simplement que explicant sempre t’allargues més del que realment després has de fer a més he intentat ser força fidel en tot el que he fet en cada pas. Es podria haver simplificat molt més. No patiu per la part del servidor penseu que si us enganxeu el vostre problema és que coneixeu poc l’apache i d’això a tot arreu n’hi ha gent que en sap i de manuals en teniu per aburrir. Pel que fa el tema del client com podeu veure és molt senzill i si la resta esta bé funcionarà a la primera.

Enllaços

Per montar tot això he usat bàsicament dos sites que m’han ajudat moltíssim:

Scroll to Top