Category: System administration, Databases, Messaging and Security

El meu primer package de pfSense ‘dd_adv’

Reading time: 4 – 6 minutes

Enllaç directe a la documentació:

En aquest article intentaré descriure quins són els passos que he hagut de seguir per fer un package pel pfSense. En aquest cas el package que he fet és la extenció d’una funció que ja té el pfSense però que no es comportava com jo necessito. Concretament estic parlant del servei de ‘dynamic DNS’. S’ha de reconeixer que el suport és per molts serveis públics, i de pagament, per publicar un nemónic per una IP dinàmica. Cosa que el fa molt bo. Però hi ha diversos comportaments del suport que té pfSense per aquestes funcions que no s’ajustaben a les meves necessitats. Tal com esta programat aquest suport el pfSense el que fa és agafar la IP pública de la interficie WAN i cada cop que aquesta canvia es fa l’actualització de la IP pública al servei de DNS remot.

El meu problema bé de dos llocs, per un costat la IP no la tinc assignada a la interficie amb internet, sinó a una altre interficie. Per altre banda, la interficie que té internet no té la IP pública assignada directament a ella sinó que la té un router que a través d’un procés de NAT li dona connectivitat a internet. Així doncs, el problema esta per un costat en saber sobre quina interficie accedirem a internet i per altre banda, quina és la IP pública a través de la qual s’accedeix a la xarxa. De retruc tenim encara un altre problema degut a que la IP pública no esta assignada a l’interficie del pfSense, suposo que és obvi que el problema és que no sabem quan aquesta canvia. Per tant, no sabem quan ho hem d’actualitzar al servei de DNS dinàmica.

La solució que he adoptat és crear un nou servei que a través d’un servei de pooling el que fa és anar preguntant de forma periódica a internet quina és la IP pública que té la nostre interficie. A més s’ha de poder seleccionar quina és aquesta interficie sobre la qual volem verificar quina és la IP pública. Ja que hem de forçar que el tràfic que es genera per descobrir la IP pública surti per la interficie que realment té connexió a internet. Aquesta casuística per extranya que sembli és molt habitual, perquè a una oficina o similar ens podem trobar amb la necessitat de tenir dues línies que van a internet, una que estarà a l’interficie WAN del pfSense i una altre que va per una altre interficie. Sovint a la interficie WAN hi tenim la sortida principal a internet i a una altre interficie la sortida de backup. Un exemple habitual en aquests dies que corren és usar una ADSL a la WAN i una altre sortida a través d’un router 3G de Vodafone o similar per una altre interficie.

Un cop ha quedat clar quin és l’objectiu del package de pfSense, aquest és l’aspecte del que volem aconseguir:

pfsense dynamic DNS advanced settings

La descripció dels passos per fer la configuració el teniu al wiki així si he de fer millores retocs, traduccions i similars crec que és un lloc més apropiat per posar-ho que no pas directament a un article al blog, perquè aquest acabarà sent massa llarg i difícil de referenciar, modificar i mantenir.

Vull destacar la poca documentació i exemples que té el pfSense sobretot pels nous desenvolupadors, ja que moltes vegades m’he hagut de posar a rascar codi o a posar-me a buscar en com ho havien fet altres programadors de ‘packages’ per saber com resoldre els meus problemes. Potser però el més difícil és la part de debugging del paquet ja que moltes vegades et troves amb problemes col·laterals de la programació del paquet que no saps com arreglar i que et fan perdre molt de temps. Per exemple, no sé per quin extrany problema en el procés de depuració deixava a tot el pfSense sense configuració i havia de reinciar i restaruar divereses vegades la configuració de tot el firewall per poder acabar trobant d’on venia el problema. El procés es fa tan llarg i pesat que acabes desesperante.

tcpflow: mirant streams tcp en un moment

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

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.

Wikid – Servidor d’autenticació

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.

TrueCrypt i Onekript – guardant la informació ben guardadeta

Reading time: 2 – 3 minutes

openkript.pngGràcies a l’Oriol fa una colla de mesos vaig descobrir el TrueCrypt que ell usava des de windows. De fet, l’eina em va agradar moltíssim sobretot per la seva simplicitat. Sovint m’he trobat usuaris preocupats per guardar informació confidencial al seu portàtil, pendrive, etc. i no sabia mai quina eina els podia recomanar per fer aquestes tàsques de forma senzilla i la vegada eficient. Doncs bé aquest aplicatiu s’integra molt i molt bé amb windows i és una bona solució a aquest problema.

Tot i esta totalment suportat en linux, el suport genèric només és via CLI, així doncs, es fa una mica engorrós usar-lo des de linux sense tenir al cap tots els paràmetres necessaris per treballar amb l’eina. Doncs bé, avui he descobert OneKript a través de Kriptopolis. Es tracta d’una eina que s’integra amb Konqueror i simplifica moltíssim l’ús de TrueCrypt en linux.

De fet, jo no uso KDE i per tant, fins que això no es suporti en nautilus no tinc cap gran avantatge a l’hora d’usar aquesta eina des de linux, però no volia deixar passar la oportunitat per recomanar un bon software per guardar les nostres dades privades en els dispositius d’enmagatzematge.

Les principals característiques d’aquest software són:

  • Creates a virtual encrypted disk within a file and mounts it as a real disk.
  • Encrypts an entire hard disk partition or a storage device such as USB flash drive.
  • Encryption is automatic, real-time (on-the-fly) and transparent.
  • Provides two levels of plausible deniability, in case an adversary forces you to reveal the password:
    • Hidden volume (steganography – more information may be found here).
    • No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).
  • Encryption algorithms: AES-256, Blowfish (448-bit key), CAST5, Serpent, Triple DES, and Twofish.
  • Mode of operation: LRW (CBC supported as legacy).

UPDATE: updated information about Truecrypt alternatives can be found here.

Yoggie Security Systems

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 keywordBulverde“.

Encara tenim censura en aquest país

Reading time: 2 – 2 minutes

censured.jpg

Avui he rebut un buroFAX d’un bufet d’advocats de Granollers demanant-me que retiri una notícia perquè perjudica al seu client. Així que per no fer-li més propaganda a aquest mussol ni el nombraré. La qüestió és que em demanen que retiri un article i els seus comentaris perquè segons ells aporto informació erronea que perjudica a tal empresa. Doncs bé, espero que ara ja no es queixin ja que com a bon peó de la justícia acato les seves peticions retirant totes les relacions de la meva notícia amb tal empresa.

Se m’acuden moltes reflexions d’aquest fet, però com que ja vaig prou putejat amb la feinada que tinc. Només em quedaré amb dues reflexions. La primera, que trist és comprovar que ja no pots ni opinar sobre les coses, m’inventi coses o no! aquí ja no hi entro. L’important, no és això sinó la llibertat de dir el que et dona la gana i ja esta, ni que fos tan greu. La segona conclusió, diguem que em quedo amb la pujada d’autoestima que donen coses així: realment importa a la gent el que dic, no? hi hi hi!

Abans d’acabar el post i anar a disfrutar de la meva desconnexió mental per avui, només dedicaré un comentari al jefe de la tal empresa. Al gener ens n’anem de vacances 20 dies a Panamà!!! A la resta ja us penjaré més detallets del viatge quan els tingui, de moment només us confirmo la notícia.

l’fbi busca hackers

Reading time: < 1 minute

Búsques feina? doncs ara resulta que l’FBI fa un anunci als USA oferint feina als ‘hackers’ que els vulguin donar un cop de mà. L’anunci (6Mb/mpeg).

Gentoo trick: instal·lant iptables amb suport de patch-o-matic (POM)

Reading time: 1 – 2 minutes

Doncs porto quasi 2h perdudes per culpa de saber com instal·lar les extensions de POM de les iptables en una Gentoo i acte seguit després d’aconseguir-ho ho m’he posat a escriure això, perquè no se m’oblidi… quina desesperació. Finalment per aconseguir-ho el que he hagut de fer és mirar l’ebuild del paquet d’iptables i fer enginyeria inversa. Amb la qual he deduit que hi ha una USE flag no documentada, almenys jo no he trobat documentació, que fa que quan l’emerge instal·la el paquet compili també totes les extensions de POM.

Concretament la extensió que em feia falta és la del time-based rules, si voleu més informació sobre les POM, fa temps en vaig parlar: Funcions poc conegudes de les iptables.

Bé doncs perquè a ningú li passi com jo, per compilar les POM a les iptables de la Gentoo heu de tenir el flag: extensions definit a la variable USE, que com segur que ja sabeu esta dins el fitxer /etc/make.conf.

Scroll to Top