oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: security

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.

tcpflow: mirant streams tcp en un moment

2008/06/13 1 comentari

Reading time: 1 – 2 minutes

Fins ara per poder seguir un protocol dins del enllaç TCP, o sigui els missatges de la capa 5, sempre acabava capturant-lo amb el wireshark o en el seu defecte amb el tcpdump generava un fitxer .cap que després obria al wireshark i a través d’una funció tan simple com el Follow TCP stream em montava la sessió de capa d’aplciació que podia seguir de forma ben còmode. El gran descobriment que vaig fer l’altre dia és el tcpflow una eina la mar de simple i lleugera que com no podia ser d’altre forma usa les llibreries libpcap, le mateixes que el tcpdump i el wireshark per mostrar-nos de forma completament visual i simple a través de la consola o contra un fitxer el contingut de la sessió TCP. Espero que li tregueu tan profit com jo a l’eina.

podcast 1×08: CAS, Central Authentication Server

2008/06/12 5 comentaris

Reading time: 3 – 4 minutes

L’objectiu d’aquest podcast és donar una visió conceptual del funcionament de CAS 2.0, un servidor d’autenticacions SSO (Single Sign On). Bàsicament esta orientat a usuaris d’aplicacions amb interficie Web. A movilpoint l’estem usant tal com vaig comentar al podcast 1×07.

La diferència entre 1.0 i 2.0 és que la versió 1.0 només podia autenticar usuaris contra aplicacions web i aquests serveis no podien autenticar-se a la seva vegada contra altres serveis (serveis backend).

Amb l’esquema que hi ha a continuació i la previa lectura de les entitats d’un sistema CAS podreu seguir el podcast:


CAS - Central Authentication Server (schema)

A continuació descric les entitats que intervenen en un sistema CAS.

  • Service Ticket (ST): és una cadena de text que usa el client com a credencial per obtenir accés a un servei. Aquest tiquet s’obté del servidor CAS. La forma d’obtenir-lo és a través d’una cookie que es guarda al navegador.
  • Ticket Granting Cookie (TGC): cookie que s’envia al CAS quan un browser ja ha estat autenticat previament per aquest CAS, llavors aquest reconeix la cookie i li dona al browser un Service Ticket (ST) sense haver de passar el procés d’autenticació manual. Caduca en unes 8h aproximadament.
  • NetID: identifica a un ususari, el que coneixem habitualment com username.
  • ServiceID: identificador d’un servei, normalment en format URL.
  • Proxy Ticket (PT): és una altre cadena de text que usa un servei com a credencial per obtenir accés a un servei de backend. O sigui, que el primer servei per tal de desenvolupar la seva activitat li fa falta accedir a un altre servei (servei de backend), per tal d’obtenir accés a aquest darrer servei el primer usarà un proxy ticket. Aquest tiquets s’obtenen al CAS quan el servei que vol l’accés presenta un PGT (Proxy-Granting Ticket) i un identificador de servei que es refereix al servei de backend.
  • Proxy-Granting Ticket (PGT o PGTID): es tracta d’una altre cadena de text que com hem vist al punt anterior l’usa el servei per aconseguir un Proxy Ticket (PT) que li doni accés a un backend service l’accés a aquest servei serà amb les mateixes credencials que l’usuari original, o sigui, el que s’ha autenticat al primer servei.
  • Proxy-Granting Ticket IOU (PGTIOU): com no podia ser d’altre manera és una cadena de text que es passa com a resposta del serviceValidate i del proxyValidate usada per correlacionar un Service Ticket o una validació de Proxy Ticket amb un Proxy-Granting Ticket (PGT) particular.

Ara només queda escoltar el podcast:

[display_podcast]

Els enllaços relacionats amb el podcast:

NOTA: donar les gràcies al Marc Torres per la seva feina, gràcies nano.

Generador registre SPF pel DNS

2008/05/12 1 comentari

Reading time: < 1 minute Per casualitat he trobat una eina que pot ser molt útil si heu de crear el registre TXT del DNS, amb les dades SPF necessaries pel vostre domini. Curiosament és una web de Microsoft, com que aquesta colla tot ho fan igual s'ha de dir que ho han fet en forma d'assistent.

A més de la mateixa web he extret aquest gràfic que és força explicatiu del que és i com funciona el SPF:

SPF schema

mikrotik: failover gateway

2008/02/26 3 comentaris

Reading time: 4 – 6 minutes

Avui he refrescat una mica la meva memòria, feia algún que altre mes que no jugava amb els mikrotik. Doncs bé, per un client havia de montar un failover gateway i com que ja sabeu que sóc un fan declarat dels mikrotik per fer això he usat un RB150. Per si això ús sona a xinès segur que amb una petita explicació ho trobareu molt útil. Doncs bé, cada cop més empreses tenen dos sortides a internet i el que volen és que quan alguna de les dues sortides caigui l’altre sortida assumeixi tot el tràfic sense haver de tocar res.

Obviament per fer això el que hem de tenir és un element que s’encarregui de redirigir tot el tràfic cap a un router o cap a l’altre segons si la sortida a internet esta fallant o no. La solució que plantejo és molt simple i pot perfeccionar-se moltíssim. Per exemple, l’únic que explicaré és a usar un dels dos routers i quan aquest falla enviar el tràfic cap a l’altre però no és gaire difícil crear unes policy routes per balancejar tràfic entre els dos routers mentre aquests estiguin operatius. Però per no liar la cosa em quedaré amb l’exemple bàsic. A partir d’aquí, la base estarà més que feta perquè feu coses més xules.

routerboard-inabox-02.png

escenari

El RB150 tindrà a l’ethernet 1 la xarxa LAN. A la ethernet 4 la WAN1 i a la ethernet 5 la WAN2. Amdues interficies tenen el router ADSL en monopuesto. O sigui, que tinc la IP pública a l’interficie del router.

funcionament

Per defecte, sortirem per la WAN1 i quan aquesta falli sortirem per la WAN2.

configuració

Assumeixo que les configuracions bàsiques ja estan fetes, o sigui, assignació d’IPs a interficies i l’enmascarament d’IP internes cap a internet. Això suposo que no té cap dificultat si algú necessita ajuda que avisi.

Creem dos scripts a llençar quan s’hagi de llençar la connexió via WAN1 i l’altre via WAN2:

Script per la WAN1:

:log info wan_1
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN1

Script per la WAN2:

:log info wan_2
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN2

Si ens interessa en cada un dels scripts hi podem afegir el que calgui. Per si no esteu habituats a treballar amb scripts al mikrotik els heu de colocar a /system scripts. Allà afegiu dues entrades i llestos. Com sempre això serà molt més còmode fer-ho des del winbox que no pas des de la cli.

Ara només cal que creem una entrada a l’eina netwatch, això es fa a /tool netwatch. A l’entrada li direm que faci pings cada un interval de temps que decidirem i que tingui un timeout fixe i si els pings no tornen llavors s’executarà l’script indicat. Bàsicament le entrades de netwatch tenen dos estats el up i el down i podem associar un script a llençar en cas de que hi hagi una oscil·lació cap a un dels dos estats. Això es fa així:

add host=208.67.222.222 timeout=10s interval=1m up-script=wan1 down-script=wan2 \
comment="Failover Gateway Script" disabled=no

El que fem és mirar si arribem a un dels servidors d’OpenDNS cada 1minut i ens esperem com a molt 10s perquè el ping torni. Després fixeu-vos com associem cada un dels scripts que em programat abans als estats d’aquesta prova.

Com podeu veure això és ben senzill, la gràcia esta en que jugueu amb els ECMP i els policy routing i feu del RB150 tot un balencejador de càrrega amb suport de fallides de línia. També és molt senzill que balancegeu el tràfic d’entrada d’internet cap a una ADSL o cap a l’altre, per fer això ús recomano que jugueu amb el DDNS que podeu actualitzar a través dels scripts comentats, només cal que li llenceu la petició d’actualitzar la IP associada al DDNS i els usuaris remots entraran per una o altre línia.

pfSense deixava de re-enviar paquets misteriosament…

2007/09/23 No hi ha comentaris

Reading time: 3 – 4 minutes

Intentaré explicar-vos un ‘expedient X’ d’aquells que ja tinc resolts, però que no tinc una explicació al 100% del comportament que tenia el pfSense davant del problema. La conclusió és que el pfSense descartava paquets per tenir massa connexions concurrents, però al ser connexions UDP costava identificar-les. El problema és que de forma completament misteriosa el pfSense descartava els primers X’s paquets cap a qualsevol IP. Aquesta número indeterminat, podia ser des de 2, 3 o 4 paquets fins a 100 o 200. O sigui, que hi havia moments on donava la sensació que s’havia perdut l’enllaç. Com a pecualiaritat de la configuració del firewall (pfSense) comentar que la targeta WAN estava en mode bridge amb la targeta de servidors d’internet. O sigui, que la DMZ rep el tràfic de les IPs públiques que allà hi han filtrat a través d’un bridge d’aquestes dues targetes de xarxa que he comentat.

Exemple, de la pèrdua de paquets que comentava. Ping realitzat a una IP d’internet (la de oriol.joor.net) des del propi firewall. Realment això d’operation not permitted em va tenir molt i molt desoncertat.

# ping 80.35.31.228
PING 80.35.31.228 (80.35.31.228): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
64 bytes from 80.35.31.228: icmp_seq=9 ttl=57 time=117.668 ms
64 bytes from 80.35.31.228: icmp_seq=10 ttl=57 time=86.728 ms

Des de qualsevol de les altres potes del firewall es patia el mateix efecte, fins hi tot si es feien els pings cap a la LAN. La solució vaig trigar quasi 48h en trobar-la, era una bogeria. Ja que al final per localitzar el problema varem aïllar el firewall d’internet i el fenòmen va deixar de passar.O sigui, ja mai passava això d’operation not permitted per molt tràfic que injectessim al firewall, no passava. Així doncs, gràcies a una molt bona idea del Manu varem tancar tot el tràfic des d’internet i varem anar obrint serveis cap a la DMZ, un per un. Fins que vaig descobrir que el servei d’NTP (123/upd) era el que probocava aquest extrany efecte al pfSense.

Després de diverses proves la conclusió, és que hi havia masses connexions concurrents contra el servei que comento. Així doncs, actualment el que he fet és filtrar el número de connexions que permeto contra aquest port:

pfsense.png

Aquestes opcions les podeu trobar editant la Rule, concretament a la sección on posa Advaced Options. Com podeu veure podeu deixar ben limitat quines connexions i quines no deixeu passar cap a un servei.

Potser el més important que he aprés d’aquesta història és no montar mai un firewall que no acompleixi la regla d’or: by default block all. O sigui, tanqueu sempre tot i ja anireu obrint a mesura que faci falta. Però a vegades per voler ser una mica més transigent ho fem alrevés i al final això s’acaba pagant, com en aquest cas. A mi ja no em tornarà a passar, espero que a vosaltres tampoc.

Wikid – Servidor d’autenticació

2007/06/30 No hi ha comentaris

Reading time: 3 – 5 minutes

Abans de començar deixar clar que es tracta d’un producte amb llicència dual amb algunes diferències entre la llicència de pagament i la gratuïta. Això si ambdues modalitats de producte són de codi obert, tot i que la de pagament porta algún component que jo diria que no té el codi font lliberat, com per exemple el servidor Radius programat en Java.

Wikid és un servidor de two-factor authentication (factor doble d’autenticació). Això vol dir que combina dos sistemes d’autenticació. En aquest cas l’autenticació asimètrica basada en clau pública i a més d’una paraula de pas d’un sol ús (OTP). D’aquesta forma s’aconsegueix un nivell de seguretat equivalent al dels tokens basats en hardware, però amb tota la flexibilitat i els beneficis del software. Gràcies a aquest component de software el sistema OTP pot funcionar en tot tipus de clients: Blackberries, telèfons, Palms, PocketPCs, Windows, Linux i Mac.

Si esteu poc familiaritzats amb aquests sistemes d’autenticació podeu donar un cop d’ull al següent gràfic que jo trobo molt explicatiu.

user-validaton.png

Un gràfic encara més detallat però també més genèric seria aquest. Com es pot veure amb ambdós gràfics l’autenticació es pot considerar que el nivell de seguretat aconseguit és de molt alt nivell i a més molt simple d’usar per l’usuari final. Si fem un resum des del punt de vista de l’usuari del sistema. Quan aquest, per exemple, vol connectar-se a una web segura, VPN, FTP, WebDAV, correu, etc. el primer que ha de fer és obrir el client software del Wikid i demanar la clau OTP. Després connecta de forma completament convencional al servei que volia accedir i aquest com sempre li demana l’autenticació i llavors el client introdueix la seva clau temporal (OTP). Això esta molt bé perquè quan algú ens demana la clau per accedir a algún lloc li podem dir amb tota certesa: no sé la meva clau. Si encara li volem donar la clau la podem generar i li podem facilitar amb la certesa que no la podrà tornar a usar. Sovint el client software que ens donarà la clau OTP ens demana un codi PIN per accedir-hi. Aquesta és la única clau que haurem de recordar.

El sistema bàsicament es composa de tres parts el servidor Wikid, el client Wikid i el servei de xarxa (network service o wikid network client). Aquest últim és el servei que volem que usi com sistema d’autenticació Wikid. Per exemple, PAM, SSH, FTP, OpenVPN, servidor IMAP, una web programada en PHP, Ruby, etc. Així doncs, configurem adequadament el servei perquè quan toqui autenticar-se vagi a buscar l’autenticació al servidor Wikid i el nostre servei de xarxa automàticament ja suporta autenticació via certificats i claus temporals. O sigui, que el sistema d’autenticació ja es considera d’alta seguretat.

Si encomptes d’usar una clau temporal volem usar un sistema biomètric, una SmartCard, un token hardware, etc. també ho podem fer. D’aquesta forma podem fer que el client s’autentiqui de forma completament automàtica sense demanar-nos cap clau. Malgrat això s’acostuma a protegir l’accés al sistema biomètric, SmartCard, etc. amb un codi PIN per tal d’assegurar que l’accés físic al dispositiu és legítim.

La pròpia web del producte té diversos videos d’ajuda i força howtos. Però si volem informació més detallada la meva recomanació és que passeu per HowtoForge i poseu “wikid” al seu buscador i sortiran una bona colla de manuals de com configurar Wikid com a servidor d’autenticació. Per exemple, OpenVPN, SSH, FreeNX, WebDAV, etc.

Yoggie Security Systems

2006/09/30 No hi ha comentaris

Reading time: 3 – 4 minutes

Aquesta empresa de capital risc acaba de presentar un mini-caixa de la mida d’una targeta de crèdit, amb dues connexions ethernet una cap a l’ordinador i l’altre cap a internet. La idea és fer de firewall personal per ordinadors aïllats o com a molt protegir petites xarxes de fins a 5 o 6 ordinadors connectant-hi un petit switch (o HUB). Com no podia ser d’una altre manera aquesta caixeta porta un Linux que s’encarrega de fer el que a Yoggie en diuen Personal Security Gatekeeper, o sigui donar funcions de:

  • Stateful inspection firewall
  • VPN client
  • Intrusion detection and prevention
  • Four transparent proxies: HTTP, FTP, POP3 (Pro model only), and SMTP (Pro model only)
  • Antivirus, antispyware, antispam (Pro model only), antiphishing (Pro model only)
  • Yoggie “Layer 8” security engine (patent pending)
  • Yoggie multilayer security agent
  • Content filtering
  • White and black lists
  • Yoggie health monitoring
  • Web management and monitoring said to provide “real time, constant, consistent and un-paralleled visibility into distributed laptop platforms, regardless of location”
yoggie_gateway.jpg

Tot això en ordinador ben petit però ben potent al mateix temps, de fet, esta disponible en dues versions la versió basic i la pro; les característiques del hardware són les següents:

  • Intel PXA270 (Bulverde) a 416MHz (basic) o 642MHz (pro)
  • 64 o 128Mb SDRAM
  • 64 o 128Mb Flash
  • SD slot (suport SDIO)
  • 4Mb de secured flash
  • 2 port 10/100 Ethernet
  • USB OTG (on-the-go)
yoggie_gateway_boards.jpg

El producte es comercialitzarà al novembre a través de distribuidors a EUA, UK i Alemanya. El model basic costarà uns 180$ i el Pro uns 220$. Realment crec que relació qualitat preu és un molt bon producte per molts tipus d’usuaris. Sobretot en el camp del SOHO o els RoadWarriors que van per tot arreu amb el portàtil. Esta clar que pels professionals de les TIC no és res de l’altre món però pels usuaris en general crec que per fi hi ha una bona alternativa a les appliances que treuen les companyies d’antivirus que sota la meva opinió en general són lamentables i una presa de pel.

El producte l’he tret de linuxdevices per variar, concretament de l’article Tiny Linux gadget protects Windows XP laptops. Si com a mi el que més us ha agradat del producte és la placa base podeu ampliar informació sobre el tema a l’article Freescale ships “SideShow” devkit — but where’s the Linux?. També podeu buscar més informació a google amb la keyword “Bulverde“.

cookbook: securitzant una xarxa wifi amb EAP/TTLS (i PAP intern)

2006/09/02 No hi ha comentaris

Reading time: 2 – 2 minutes

Els artícles on explico com configurar EAP/TLS en català i en anglès tenen més de 8.000 visites el primer i més de 17.000 el segon. Doncs bé, degut a les preguntes d’algún d’aquests lectors de l’article acabo de fer un petit i ràpid cookbook de com afegir TTLS a la configuració TLS de l’article. De fet, si teniu clars els conceptes podeu montar-vos una autenticació EAP/TTLS amb PAP intern amb menys de 15min.

Bàsicament l’únic que afegim a la configuració del EAP/TLS és la capacitat d’afegir un nou sistema d’autenticació després d’establir el túnel segur entre el servidor radius i el client que es vol autenticar a la xarxa wifi. En aquest exemple per tal de simplificar les configuracions el protocol utilitzat per aquesta autenticació és el PAP. Amb aquest simple sistema he enmagatzemat el nom d’un usuari i una paraula de pas necessaris per autenticar el client després d’establir el túnel gràcies al seu certificat de client.

Obviament si no voleu usar PAP podeu modificar la configuració per usar CHAP, MsCHAP, o qualsevol altre sistema que volgueu. Si aquest article desperta tan interés com els altres ja l’aniré polint, però la veritat ara mateix no tinc ganes de posar-me a explicar tots els detalls de les configuracions que ja vaig explicar en el seu dia. Així doncs si ús cal ajuda la demaneu.

El cookbook el podeu trobar al wiki.