oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: ssl

sslsnoop – hacking OpenSSH

2014/07/08 No hi ha comentaris

Reading time: < 1 minute Using sslsnoop you can dump SSH keys used in a session and decode ciphered traffic. Supported algorithms are: aes128-ctr, aes192-ctr, aes256-ctr, blowfish-cbc, cast128-cbc. Basic sslsnoop information: 

 $ sudo sslsnoop # try ssh, sshd and ssh-agent… for various things
 $ sudo sslsnoop-openssh live `pgrep ssh` # dumps SSH decrypted traffic in outputs/
 $ sudo sslsnoop-openssh offline –help # dumps SSH decrypted traffic in outputs/ from a pcap file
 $ sudo sslsnoop-openssl `pgrep ssh-agent` # dumps RSA and DSA keys

Take a look into the project in sslsnoop github page.

Terminals via Web (CLI via Web)

2010/03/05 2 comentaris

Reading time: 2 – 2 minutes

UPDATE 2017/1/18: I just discovered Wetty which is by far the best option that I found to have a Web Terminal completely easy to use and compatible with Linux terminals. I highly recommend it.

En l’article sobre Turnkey Linux vaig parlar sobre shellinabox, doncs bé per coses de l’atzar he descobert que no és l’únic sistema que preten donar accés a una sessió de shell a través d’una pàgina web.

De fet, les tres eines que he trobat són realment bones, així doncs si algú en sap alguna cosa més sobre elles que m’ho digui perquè no sé amb quina quedar-me:

  • shellinabox: emula un terminal VT100 i es llença com un dimoni que dona accés al host local a través del port que escollim, pot treballar amb o sense SSL.
  • ANYTerm: també suporta SSL però treballa a través d’Apache recolzant-se amb mod_proxy.
  • AJAXTerm: inspirat en ANYTerm però molt més simple d’instal·lar, ja que només depèn de python, o sigui, que treballa com a dimoni en el sistema on volem tenir la shell.

openssl: certificats autosignats de forma molt simple

2009/06/17 3 comentaris

Reading time: 2 – 4 minutes

Fins aquest matí cada vegada que necessitava crear-me certificats auto-signats (self-signed certificates) usava llarguíssimes llistes d’opcions amb l’openssl, però avui he descobert (digueu-me lent) que si descarregues el paquet d’OpenSSL i el desempaquetes dins del codi font hi ha un directori que es diu: easy-rsa.

Com es pot observar el nom ja dona moltes pistes, doncs bé, dintre d’aquest hi trobem encara un altre directori anomenat 2.0. Aquí dintre, hi ha un munt d’scripts que ens simplificaran moltíssim la vida a l’hora de crear certificats, com sempre en faig un resum en forma de cookbook.

  • Editar el fitxer vars. Cal modificar el valor de les variables:
    • export KEY_COUNTRY="yourContry"
export KEY_PROVINCE="yourProvince"
export KEY_CITY="yourCity"
export KEY_ORG="myOwnOrg"
export KEY_EMAIL="user@domain.tld"
  • Després netegem el directori de claus perquè no hi hagi restes d’exemples:
    • ./clean-all
  • Carreguem variables d’entorn del fitxer vars:
    • source ./vars
  • Creem una CA (Certificate Authority):
    • ./pkitool --initca
  • Crear el certificat per un servidor:
    • # ./pkitool --server
# penseu que a vegades el common_name ha de ser el url_host del servidor, per exemple, en servidors https
./pkitool --server nom_servidor
  • Certificats per un client:
    • # ./pkitool
./pkitool nom_client
  • Certificat per un client enpaquetat amb PKCS12:
    • # ./pkitool --pkcs12
./pkitool --pkcs12 nom_client
  • Generar un fitxer DH (Diffie-Hellman)
    • ./pkitool --build-dh

NOTA: en cas de volgueu protegir les claus privades amb una clau simètrica per evitar que siguin usades per tercers persones podeu fer-ho afegint el paràmetre ‘–pass‘ a les comandes anteriors.

Les claus generades les podeu trobar al directori ‘easy-rsa/2.0/keys‘.

Pels que no tingueu massa per la mà el tema dels certificats posaré quatre notes sobre els fitxers creats:

  • *.csr: Certificate Signing Request, petició de certificat que s’envia a una CA perquè ens el torni signat.
  • *.crt: Certificat signat per una CA
  • *.key: Clau privada del certificat, sovint s’acostuma a protegir amb una clau simètrica
  • ca.crt: Certificat de la CA
  • ca.key: clau privada del certificat de la CA.

Senzill, oi? diria que ja no teniu excusa per gestionar-vos vosaltres mateixos les claus SSL. Si ús calen d’altres funcions al directori esmentat hi ha molts altres scripts i el propi ‘pkitool‘, té força altres opcions molt interessants i igual de simples d’usar.

openssl: canvi de clau privada d’un PKCS12

2009/06/16 No hi ha comentaris

Reading time: 1 – 2 minutes

Pels que ús soni de res el PKCS12 la wikipedia és un bon lloc per coneixer de que va, una definició xapussera de què conté un PKCS12 seria:

  • Cert de la CA (Certificate Authority)
  • Cert del client
  • Clau privada del client

Això permet poder configurar ràpidament clients que han d’usar certificats ja que només tenim un fitxer que posar a la configuració.

A continuació enganxo un petit cookbook que explica com canviar o treure la clau simètrica que protegeix la clau privada del certificat client:

#extreiem private key d'un p12
openssl pkcs12 -in client.p12 -nocerts -out client_private_key.pem
#extreiem client certificate d'una p12
openssl pkcs12 -in client.p12 -clcerts -nokeys -out client_cert.pem
#extreiem CA d'una p12
openssl pkcs12 -in client.p12 -cacerts -nokeys -out ca_cert.pem
#treiem password d'una clau
openssl rsa -in client_private_key.pem -out client_private_key.nopass.pem
#canvi pass d'una clau
openssl rsa -in client_private_key.pem -des3 -out client_private_key.novaclau.pem
#creem una p12 a partir dels seus fitxers arrel
openssl pkcs12 -export -out client.nou.p12 -in client_cert.pem -inkey client_private_key.novaclau.pem -certfile ca_cert.pem -name "nova clau" -out client.nou.p12

Netgear ProSafe SSL VPN Concentrator SSL312

2009/03/03 5 comentaris

Reading time: 4 – 6 minutes

NetGear SSL312Havia tingut l’oportunintat de veure funcionar aquest tipus de concentradors d’VPN en diverses ocasions però mai n’havia configurat cap. De fet, el model en concret del que us parlo el vaig descobrir a través de Tecnología Pymes. El que més em va sorprendre és la quantitat d’VPNs que gestionava i el seu preu, són 25 VPNs concurrents per uns 350€ de PVD. Després vaig estar mirant-me a fons el manual i les seves especificacions tècniques i crec que és una de les solucions més competitives per montar VPNs a usuaris remots (roadwarriors) de forma senzilla. En aquest cas, senzilla vol dir que no s’hagi d’anar usuari per usuari a configurar-los l’VPN. Sinó que ells mateixos simplement accedint a una pàgina web i amb un simple usuari/password més el suport d’un plug-in Java/ActiveX passin a ser un client de l’VPN.

Al accedir via web després de l’autenticació el dispositiu facilita un portal d’enllaços als usuaris on poden amb un simple clic accedir a aplicacions a través del navegador, per exemple, usant VNC, RDP, Telnet, SSH, IE i d’altres protocols l’usuari pot iniciar per exemple una sessió amb una aplicació que estigui en un servidor local: Word, Excel, ERP, CRM, Web,  etc. O sigui, que és ideal per quan tenim usuaris amb coneixements molt bàsics perquè els podem donar accés directe a les típiques coses que usaran i per l’usuari és molt senzill d’entendre. Obviament si no volem accedir via web a la xarxa remota ho podem fer des del sistema, o sigui, que per exmemple si obrim una consola podem llençar un ping sense problemes als servidors remots. No deixa de ser una VPN de les de sempre, però usant com a client el navegador.

Pel que fa al firmware que usa després de connectar-hi via RS232 he pogut veure que és un Linux, al qual pel mateix CLI serie podem tenir-hi accés i tocar el que ens convingui. Per cert, enlloc he trobat la configuració del port serie per connectar-hi però fent proves la que m’ha funcionat ha estat: 9600 8N1 no control de fluxe per hardware ni tampoc per software.

Al iniciar el router aquest portava un firmware força antic que no suportava Windows Vista i que només podia treballar amb clients IE via ActiveX. Però després d’actualitzar el firmware a la versió 2.3.03 no només ja es suporta el Windows Vista sinó que també funciona amb clients Linux amb Firefox usant un applet de Java. Això si hem de tenir permisos d’administrador perquè sinó no pot crear les rutes i d’altres similars al sistema.

# uname -a
Linux vpn0 2.4.20-br264 #25 Fri Nov 14 12:23:42 IST 2008 POLO unknown

Els usuaris de l’VPN poden estar guardats en diversos llocs:

  • Local user database
  • Microsoft Active Directory
  • LDAP directory
  • NT domains
  • RADIUS (PAP, CHAP, MSCHAP, MSCHAPv2)

A més disposa d’un sistema de grups i de polítiques de permisos que malgrat no ser res de l’altre món ens permet crear certs tipus de perfils restringint els accessos de forma simple i fàcil de gestionar als grups o usuaris.

Quan montem aquesta solució podem treballar de diverses formes. Diposa de dues sortides ethernet i podem treballar amb només una sortida:

topologia 1

o usant dues interficies de xarxa:

topologia 2

a partir d’aquí podem adaptar el sistema d’VPN al que més ens interessi dins de l’empresa.

Abans d’acabar només un apunt sobre el tema de la configuració. Cal dir que no és complicat de configurar, però en primera instància és una mica engorrós tenir tantes opcions i tan poc intuitives. Una bona recomanació és que no deixeu de llegir-vos atentament l’ajuda en línia (apareix a la part dreta) que es mostra en la WebUI de configuració.

Un altre cop doncs NetGear ens ha presentat un producte molt decent i recomanable, he de dir que és una marca que al igual que Linksys m’acostuma a deixar un bon gust de boca.

Pàgina del producte:  ProSafe SSL VPN Concentrator SSL312

ssldump depuració de tràfic xifrat

2008/10/02 No hi ha comentaris

Reading time: 2 – 2 minutes

Tothom coneix el TCPdump i fins hi tot hi ha gent com jo que l’usem a diari, de fet, no fa massa temps  vaig re-descobrir el TCPflow (ja l’havia descobert abans, però vaig cometre el gran error d’oblidar-lo). Doncs bé, el problema d’aquestes eines és que són molt útils per tràfic sense xifrar però quan es tracta de tràfic xifrat amb SSL/TLS com ara HTTPs o d’altres protocols que viatgen xifrats i volem saber perquè no funcionen hem de recorrer a eines com el ssldump.

SSLdump permet seguir el fluxe de les conexions TCP xifrades amb SSLv3/TLS. Obviament per aconseguir desxifrar el contingut de l’enllaç hem de facilitar-li els certificats corresponents a l’eina. Però no només ens permet depurar a nivell de dades que corren per TCP sinó que també ens dona informació del propi protocol de xifrat descrita de forma humana. O sigui, que podem saber si el problema de l’enllaç és produeix durant el procés de handshake, ChangeCipherSpec o dins del protocol.

El que jo feia fins ara per poder analitzar el contingut d’un protocol que viatge xifrat és ajudar-me de l’eina sslproxy. La qual feia de bouncer al servidor de protocol o al client, així doncs obtenia un tram de la conexió que no anava xifrat i a través del tcpflow o el tcpdump podia obtenir el tràfic en clar. La tècnica és enginyosa i útil però ferragosa en comparació al ssldump.

Pound: reverse proxy i load balancing

2008/06/02 3 comentaris

Reading time: 3 – 4 minutes

A través d’un howto de howtoforge he descobert aquesta eina anomenada Pound. Realment m’ha deixat impressionat per la seva simplicitat i potència al mateix temps. A més m’ha donat molt confiança saber que hi ha almenys un site processant 30M de peticions al dia, unes 600 per segon amb aquest aplicatiu. Aquest tipus de números sempre ajuden a donar confiança en les eines.

Doncs bé, l’eina bàsicament es dedica a capturar totes les peticions HTTP i HTTPs repartint-les després contra els servidors que té en el backend. En cap moment fa de caché ni res similar. Tot i que cal destacar la capacitat de poder fer de SSL wrapper. Així doncs, no cal que els backend facin de servidors SSL, només de servidor HTTP. Obviament pel client s’establirà una connexió HTTPs completament transparent. Si la validació SSL no és correcte Pound ja no envia peticions als servidors que té darrera.

Les funcions de balancejador de càrrega (load balancer) permeten no perdre les sessions establertes pels navegadors dels clients contra els servidor de backend, de fet, Pound implementa sis formes diferents de capturar una sessió per tal de no enviar peticions a un dels backends que no conegui la sessió del navegador.

Suporta funcions de fail-over, així doncs totes les peticions es direccionen només als servidors de backend que se sap que funcionen, la validació que es fa per saber si un servidor esta actiu o no és força simple i a grans trets es basa en paquets ICMP.

Finalment també cal destacar una funcionalitat que m’ha cridat molt l’atenció, ja que permet fer de wrapper d’URL i enviar les peticions que acompleixin certes expressions regulars cap a un o altre servdidor. Això permet, per exemple, enviar els dominis virtuals cap a un o altre servidor. A més, també podem per exemple, enviar les peticions d’imatges cap certs servidors de backend específics.

Al llegir-me la documentació d’aquesta eina el que més m’ha intrigat és saber com resolien el típic problema que presenten les eines d’aquest tipus, els fitxers de logs. M’explico, una cosa molt important a poder controlar des del punt de vista d’un servidor web és saber d’on arriben les peticions si el servidor web no rep les peticions directes d’internet sinó a través d’un balancejador com Pound la IP origen de la petició es perd i per tant, els fitxers de logs dels servidors web no són reals sinó que tenen com a origen sempre el balencejador. A més de totes els problemes associats a no saber d’on venen les peticions, com el control d’accés i d’altres similars.

Doncs bé, bàsicament això es soluciona a través d’una capçalera HTTP afegida des de Pound a la petició web. Així doncs és en aquesta capçalera que s’han d’anar a buscar les dades necessaries per recomposar el fitxer de logs del servidor web. També hi ha mod’s d’apache que ja solucionen aquest tema directament capturant aquesta nova entrada en la capçalera HTTP, concretametn val la pena que no perdeu de vista mod_extract_forwarded2.

Sota el meu punt de vista un gran descobrint i una eina molt interessant per tal de poder montar servidors web’s amb més cara i ulls. No sé si algú l’haura provat 😉

sslproxy

2005/10/18 No hi ha comentaris

Reading time: 2 – 4 minutes

L’sslproxy és una petita eina d’aquelles que van de PM… què fa doncs el nom ho diu tot:

SSL Proxy server listens on a TCP port, accepts SSL connections, and forwards them to another local or remote TCP port. For example, it is possible to create an HTTPS server if you have an HTTP server and you run an SSL Proxy server on port 443 which forwards the connections to port 80. SSL Proxy’s design makes it as secure as possible and still perform well.

Un petit exemple on es pot veure com funciona. Llencem una petició HTTPs des del nostre navegador contra l’sslproxy i aquest re-enviarà la petició a un servidor TCP (netcat) i podrem veure la browser fingerprint del nostre navegador. O dit més senzill, la petició HTTP del nostre navegador, sense la S. O sigui, sense l’SSL.

Posem el servidor TCP (netcat) a escoltar el port 8000:

nc -l p 8000

Llencem el sslproxy amb el seu certificat SSL corresponent:

ssl_proxy -s 443 -d -c 8000 -C server-cert.pem -K server-key.pem

Anem al navegador i la barra de direcció posem:

https://localhost

Si mirem el nc podrem veure que hi ha la petició HTTP que llençavem:

GET / HTTP/1.0
Host: localhost
Accept: text/html, text/plain, application/vnd.sun.xml.writer, application/vnd.sun.xml.writer.global, application/vnd.stardivision.writer, application/vnd.stardivision.writer-global, application/x-starwriter, application/vnd.sun.xml.writer.template
Accept: application/msword, application/vnd.sun.xml.calc, application/vnd.stardivision.calc, application/x-starcalc, application/vnd.sun.xml.calc.template, application/excel, application/msexcel, application/vnd.ms-excel, application/x-msexcel
Accept: application/vnd.sun.xml.impress, application/vnd.stardivision.impress, application/vnd.stardivision.impress-packed, application/x-starimpress, application/vnd.sun.xml.impress.template, application/powerpoint, application/mspowerpoint
Accept: application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.sun.xml.draw, application/vnd.stardivision.draw, application/x-stardraw, application/vnd.sun.xml.draw.template, application/vnd.sun.xml.math
Accept: application/vnd.stardivision.math, application/x-starmath, text/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png, image/x-xbitmap, image/x-xbm, image/gif, application/postscript, */*;q=0.01
Accept-Encoding: gzip, compress
Accept-Language: en
User-Agent: Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7e

L’exemple és una mica xorra a nivell funcional, però crec que a nivell conceptual és molt explicit de quina és la funcionalitat que ens ofereix el sslproxy. Sobretot si hem programat una aplicació que no té suport SSL i li volem afegir seria tan senzill com aplicar el que explico aquí.

OpenVPN roadwarrior over PROXY

2005/10/17 No hi ha comentaris

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.

Consum d’ampla de banda de l’OpenVPN

2005/10/13 No hi ha comentaris

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.