Tag: security

Podcast 2×01: introudcció i descripció detallada del protcol SOCKS5

2010/03/04 No Comments

Reading time: 3 – 4 minutes

Després de moltes hores de feina estudiant el protocol SOCKS he decidit publicar un podcast que expliqui el seu RFC, el podcast pretent fer una introducció des de la part meś conceptual fins endinsar-se en el fluxe de paquets, els camps de les peticions llençades arribant a explicacions de nivell de bit. Amb l’ajuda dels diagrames adjunts a aquest article, l’RFC1928 i l’explicació del podcast després hauriem d’estar capacitats per implementar un client/servidor SOCKS5.

El podcast:

[display_podcast]

Esquemes que ajuden a seguir el podcast

esquema 1: petició d’un client SOCKS5 al servidor

                   +----+----------+----------+
                   |VER | NMETHODS | METHODS  |
                   +----+----------+----------+
                   | 1  |    1     | 1 to 255 |
                   +----+----------+----------+

esquema 2: resposta del servidor SOCKS5 al client

                         +----+--------+
                         |VER | METHOD |
                         +----+--------+
                         | 1  |   1    |
                         +----+--------+

mètodes d’autenticació

X’00’ NO AUTHENTICATION REQUIRED
X’01’ GSSAPI
X’02’ USERNAME/PASSWORD
X’03’ to X’7F’ IANA ASSIGNED
X’80’ to X’FE’ RESERVED FOR PRIVATE METHODS
X’FF’ NO ACCEPTABLE METHODS

esquema 3: el client SOCKS5 envia una comanda al servidor

        +----+-----+-------+------+----------+----------+
        |VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
        +----+-----+-------+------+----------+----------+
        | 1  |  1  | X'00' |  1   | Variable |    2     |
        +----+-----+-------+------+----------+----------+

camp: ATYP -> address type

IP V4 address: X’01’
DOMAINNAME: X’03’
IP V6 address: X’04’

esquema 4: resposta del servidor SOCKS5 a la comanda del client

        +----+-----+-------+------+----------+----------+
        |VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
        +----+-----+-------+------+----------+----------+
        | 1  |  1  | X'00' |  1   | Variable |    2     |
        +----+-----+-------+------+----------+----------+

camp: REP -> reply

X’00’ succeeded
X’01’ general SOCKS server failure
X’02’ connection not allowed by ruleset
X’03’ Network unreachable
X’04’ Host unreachable
X’05’ Connection refused
X’06’ TTL expired
X’07’ Command not supported
X’08’ Address type not supported
X’09’ to X’FF’ unassigned

esquema 5: encapsulaments per enviaments de paquets UDP

      +-----+----+-----+------------------------+------+
      | ... | IP | UDP | SOCKS5 UDP ASSOCIATION | DATA |
      +-----+----+-----+------------------------+------+

esquema 6: camps de l’encapsulament: UDP ASSOCIATION

      +----+------+------+----------+----------+----------+
      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
      +----+------+------+----------+----------+----------+
      | 2  |  1   |  1   | Variable |    2     | Variable |
      +----+------+------+----------+----------+----------+

Referències d’utilitat

Apunts per fer el podcast: fitxer .txt amb la llista de coses que havia de comentar al podcast és una barreja de català, castellà i anglès… però pot servir-vos per entendre el que intento explicar
Wikipedia: SOCKS
RFC’s:
- RFC1928: SOCKS Protocol v5
- RFC1929: Username/Password Authentication for SOCKS V5
- RFC1961: GSS-API Authentication Method for SOCKS V5

gnoMint: X.509 CA management tool

2010/02/26 1 Comment

Reading time: 2 – 3 minutes

Quan administres alguns sistemes i comences a montar serveis SSL arriba un moment que acabes familiaritzan-te amb la sintaxis d’openSSL per la generació de certificats i fins hi tot entitats certificadores autosignades. El problema és quan has de mantenir diverses entitats i diversos certificats arriba un moment que ja no recordes a quina màquina tens els fitxers guardas i l’administració de tot plegat es fa força pesat.

Així doncs, m’he decidit a provar gnoMint que eś una eina programada amb GTK i que fa de GUI a les típiques funcioalitats que demanem sovint al openSSL. Així doncs, és molt senzill de crear diverses entitats certificadores amb diversos certificats associats a cada una d’elles. Però el més important és senzillissim de mantenir, ja que en un cop d’ull saps quins certificats tens creats i quins et caldran per un nou projecte. A més de poder exportar les claus publiques i privades de forma ben senzilla.

Un petit resum de funcionalitats de l’eina seria el que trobem a la seva web:

Creating all the infrastructure to keep and run a Certification Authority, saved in only one file.
Create Certification Signing Requests, allowing to export them to PKCS#8 files, so they can be send to other CAs.
Create X.509 certificates, with a usual set of subject-parameters.
Export certificates and private keys to PEM files, so they can be used by external applications.
For each CA, establish a set of policies for certificate generation.
Import CSRs made by other applications
Export PKCS#12 structures, so the certificates can be imported easily by web and mail clients.
Revoke certificates, and generate the corresponding CRLs
Allow the possibility of keeping the CA private key, or other private keys, in external files or devices (as USB drives)
Allow the management of a whole hierarchy of CAs, with their respectives certificates.
Import pre-existing Certification Authorities, with all their data.
Allow an easy CA operation from command-line tools, for batch certificate creation, or integration with other utilities.

openssl: certificats autosignats de forma molt simple

2009/06/17 3 Comments

Reading time: 27 – 45 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 Comments

Reading time: 30 – 50 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

Eines de recuperació de dades

2009/05/11 1 Comment

Reading time: 1 – 2 minutes

A través del blog d’en Xavier Caballé trobo un article amb un recull d’eines de recuperació de dades. Després de contrastar-ho amb el Manel i amb la seva experiència a Inforescate la llista s’ha ampliat i queda així:

TestDisk, per a Windows, Mac i Linux
Recuva, per a Windows
PhotoRec, per a Windows, Mac i Linux
Restoration, per a Windows
Undelete Plus, per a Windows
Captain Nemo
Get Data Back for FAT
Get Data Back for NTFS
UFS Explorer
Active Partition Recovery
R-Studio
Stellar Phoenix
Raid Reconstructor
Data Doctor Recovery for Removable Media
Directory OPUS (explorador de fitxers SUPREM!)

Netgear ProSafe SSL VPN Concentrator SSL312

2009/03/03 3 Comments

Reading time: 9 – 15 minutes

Havia 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:

o usant dues interficies de xarxa:

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

Atac DOS al DNS: DNS Root Query Amplification

2009/02/28 No Comments

Reading time: 2 – 4 minutes

El dia 26 un dels servidors que administro va ser víctima d’un atac DNS, de fet, a hores d’ara encara continuem sent víctimes de l’atac malgrat ara mateix ja hem pres mesures de contenció per tal de que el mateix no ens afecti. La qüestió és que aquest atac va sobrecarregar l’activitat del nostre servidor de DNS fins a tal punt que les peticions DNS trigaven molta estona a resoldres ja que s’acumulava la feina i aquestes cada cop trigaven més a resoldres. Això de forma col·lateral va provocar problemes en altres serveis, arribant fins hi tot a col·lapsar-los i a fer caure un dels servidors.

L’atac en qüestió esta perfectament descrit pel SANS:

DNS queries for ”

Una possible solució i també descripció del problema la va trobar en Lluís en aquest blog:

DNS Root Query Amplification

Per resumir una mica el que es nota és que rebem moltíssimes peticions de resolució del domini ‘.’, cosa que dona molta feina al nostre servidor DNS i que acaba generant un gran tràfic de resposta per una petita petició que pot llençar perfectament un zombie sense patir cap sobrecarrega al seu ampla de banda, encanvi el destinatari del atac DOS pot veures afectat per moltíssims paquets no solicitats de diversos origens, convertint el simple atac DOS en un complicat atac DDOS difícil de parar pel destí final de l’atac.

Un bon gràfic per entendre l’atac és aquest:

dns-amplification-attack-small

Aquest gràfic l’he extret de l’article DNS Amplification Attack
del blog Security News & Tips. Que també té un bon article on s’explica l’atac en detall.

Si simplement sóm usats per llençar aquest atac, com era el cas que explico gràcies a eines com el fail2ban no és complicat d’aturar, ja que podem dir-li que vigili el nostre fitxer de logs i llençar regles de filtrat que aturin les peticions al DNS que es repeteixen massa pel mateix origen. Per un detall més complert de com implementar això ús remeto a l’article: DNS Root Query Amplification.

NOTA sobre PowerDNS: El software que usem per gestionar els DNS és el PowerDNS el qual disposa d’una interficie web per controlar les estadístiques del servei, en cas de patir un atac d’aquest tipus a través d’aquesta pàgina web serà molt senzill que identifiqueu quines IPs estan llençant l’atac i a més a més comprovar que l’atac és el del tipus que he descrit.

pfSense i VMWare: problemes amb les interficies en bridging [solucionat]

2009/02/27 No Comments

Reading time: 4 – 6 minutes

Ahir en Joan i jo ens varem passar 11h per descobrir que el nostre gran problema d’incompatibilitat entre el pfSense i el VMWare ESX 3.5 no era res més que un petit error de configuració a un virtual siwtch (vSwitch) que unia les interficies virtuals del firewall.

Bé anem a descriure l’escenari. Imagineu un pfSense com a màquina virtual d’VMWare amb dues potes físiques, o una física i una virtual, com volgueu el problema és el mateix. Si les dues són virtuals no ho he provat, però imagino que passa el mateix. La qüestió és que si fem que les dues potes del pfSense estiguin en mode bridge, és a dir com si el pfSense no hi fos i ambdues subxarxes estiguessin unides en una de sola, llavors el tràfic entre una xarxa i l’altre no flueix. O sigui, no podem passar ni paquets ICMP, ni TCP ni UDP. Però si que podem passar paquets ARP. Curiós, eh!?

vmware-pfsense-bridge

En el dibuix anterior es veu l’escenari d’exemple que varem estar provant. O sigiui, un portàtil en una xarxa física, després en una altre xarxa hi teniem un servidor físic i un de virtual. El pfSense sempre virtual, o sigui dins del VMWare ESX. Per altre banda teniem una altre pota real que ens connectava a internet. Però això no és rellevant, només ho indico perquè quedi clar que el pfSense tenia tres potes i que les que feien el bridge no eren la LAN i la WAN. Sinó la LAN i una OPT1. L’escenari real i le proves següents complicaven aquest escenari bàsic afegint una pota més del pfSense també en mode bridge amb la primera, les proves també van funcionar.

Pels que no estigueu familiaritzats amb el VMWare per fer això cal definir dos vSwitch un que uneixi la LAN del pfSense amb la targeta de xarxa real del VMWare i la Xarxa 1. Un altre vSwitch ha d’unir el pfSense amb la Xarxa 2, que té una màquina virtual connectada a ell i un targeta de xarxa del VMWare connectada a un switch real amb un ordinador físic. Doncs bé, aquestes dues interficies del pfSense es posen en mode bridge i els ordinadors de la xarxa 1 i 2 poden compartir domini de col·lisió i el pfSense pot fer filtrat de packets en mode stealth ja que els usuaris ni s’adonen que els seus paquets passen per un firewall.

Diria que ja ha quedat clar el que passava, doncs bé en Joan i jo ens varem passar 11h lluitant i investigant d’on podia venir el problema que feia que els paquets no passessin d’un costat a l’altre del pfSense. De fet, el que varem observar per començar és que a l’itnerficie de xarxa del pfSense no arribaben els paquets de la xarxa 1 a menys que aquests anessin dirigits a la IP de la pota de forma explícita, o els paquets que volien usar el firewall com a porta d’enllaç per navegar.

Doncs bé, el tema esta en que els vSwitch del VMWare han de tenir el paràmetre “Promiscous Mode“, que per defecte esta a “Reject“, a “”Accept“. Fent això a ambdós vSwitch els paquets flueixen d’un costat a l’altre del firewall sense problemes. Increible, oi? doncs si. Una de les múltiples alegries que et dona l’informàtica quan després d’aixecar-te a les 4 del matí per posar en producció el sistema, a les 6 de la tarda descobreixes en un entorn simulat que el problema venia d’això.

A continuació adjunto un parell de captures de pantalla on podeu veure com per defecte el paràmetre esta a “Reject” :

Caputra de les propietats d'un vSwitch

i simplement editant les propietats del vSwitch el podem posar a “Accept”:

Això farà, que demà a les 8 hem toqui treballar altre vegada i que per fi pugui posar en producció el sistema. Esperem que les proves de concepte fetes en el entorn simulat que varem montar ahir a la tarda segueixin funcionant tan bé en l’entorn real demà al matí. Apa doncs, només agraïr al Joan la seva paciència i seguir provant i provant colze amb colze amb mi per arribar a aquesta solució.

pfSense: comanda clog

2009/02/14 1 Comment

Reading time: 2 – 2 minutes

Com no podia ser d’altre forma el pfSense usa logrotate per guardar els logs. O sigui, que si fem un cat als seus fitxers de logs no estem buscant en tot el registre d’informació sinó només en la última part que encara no s’ha empaquetat sovint la part corresponent al dia actual. Doncs bé la gent de pfSense ha creat una eina en forma de comanda: clog que permet mirar un fitxer de logs i en tots els seus paquets comprimits amb informació de dies anteriors.

A més, una funcionalitat molt habitual en els fitxers de logs sobretot quan estem depurant és usar la comanda “tail -f“. Que ens permet veure en temps real els continguts que es van afegint a un fitxer de log, doncs bé, si decidim tenir aquest fitxer en una consola diversos dies monitoritzant el fitxer que ens interessa com que aquest serà empaquetat pel logrotate el “tail -f” es truncarà. Això es soluciona també amb la nova comanda “clog“, només cal que usem el paràmetre “-f” per monitoritzar el que es va afegint en un fitxer de log. O sigui, “clog -f nom_fitxer.log“.
Si voleu donar un cop d’ull a la plana wiki on ho he trobat: clog.

pfSense: per fi funcionen els aliases

2009/02/13 No Comments

Reading time: 2 – 2 minutes

Acabo de llegir al wiki de pfSense que per fi la funcionalitat d’aliases als ports funciona, de fet, encara no sé si això passarà a funcionar a la versió 1.2.3 o ja funciona a les versions 1.2.2 que estic montant útlimament quan ho hagi contrastat ja avisaré en aquest mateix post. Pels que no tingueu ni idea de què estic parlant vaig a explicar-me.

Resulta que el pfSense té entre les seves funcions la de poder declarar aliases de hosts, xarxes i ports. Això és genial a nivell conceptual perquè podem definir, per exemple, un grup de hosts que anomenem “ServidorsWeb” i un grup de ports que anomenem “PortsWeb” i després al la secció de regles (rules) només cal que creem una sola regle que permeti el tràfic a tots els “ServidorsWeb” pels “PortsWeb” i això automàticament en background generarà tantes regles com calguin perquè aquest tràfic passi sense problemes. Fins ara es podien definir els aliases dels ports però després a la secció de NAT o Rules no es podien associar, per tant, era com inútil asignar aliases a ports.

Quan tenim xarxes dividides en diverses subxarxes i amb uns quants servidors, grups d’usuaris, etc. aquest típus d’eines van genials. De fet, altres firewalls més coneguts com el Checkpoint fa segles que disposen de funcions com aquestes.

Si voleu donar un cop d’ull a la plana wiki on ho he trobat: Aliases.