oriolrius.cat

Des del 2000 compartiendo sobre…

Category: System administration, Databases, Messaging and Security

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

2009/02/27 No hi ha comentaris

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

vmware-vswitch-sc002

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: per fi funcionen els aliases

2009/02/13 No hi ha comentaris

Reading time: 2 – 2 minutes

pfsense logo

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.


GreenSQL: protecció contra SQL injection

2009/01/20 No hi ha comentaris

Reading time: 1 – 2 minutes

GreenSQL logoGràcies a l’Aitor descubreixo el GreenSQL, una aplicació en forma de dimoni que fa funcions de reverse proxy entre les aplicacions que usen MySQL i el servidor de MySQL. Després de revisar la pàgina web, una presentació i veure una demostració del seu panell de control he de dir que l’eina té molt bona pinta. El seu mètode de funcionament ens pot portar a alguns mals de caps ja que fins que les whitelist no tenen suficient informació de com funcionen les nostres aplicacions alguns falsos positius en els seus anàlisis ens poden fer tornar una mica bojos. Malgrat això en alguns entorns crec que l’eina pot ser molt útil. El que no he sabut trobar per enlloc és un benchmark de quin és el rendiment d’aquest proxy ja que per entorns de molta càrrega crec que podria convertir-se en un coll d’ampolla. Finalment una altre informació que no he sabut trobar és on guarda la seva base de dades d’informació??? ja que el volum d’aquesta pot ser molt gran i seria curiós saber si ho fa també sobre MySQL o sobre fitxers de text, tipus sqlite o BerkeleyDB, per exemple.

ACL Policy Daemon for Postfix

2008/12/12 1 comentari

Reading time: 3 – 4 minutes

Fins ara l’únic policy daemon que usava per postfix és el policyd v1 que esta fet amb C i per temes de rendiment em donava grans funcionalitats, rapidesa i escalavilitat sobretot pel seu backend en MySQL. Però avui m’he vist obligat a instalar el ACL Policy Daemon que esta programat amb Twisted+Python i que a través de la seva capacitat de configurar les regles d’accés al Postfix vai ACLs m’he pogut montar una funcionlitat un pel rebuscada que em calia per un client.

El problema és que aquest client necessita:

  • Rebre correu pels seus dominis
  • Permetre relay previa autenticació dels seus roadwarriors

Doncs bé això planteja un problema degut a una funcionalitat contradictoria. Si configurem el Postfix perquè rebi correu local, podem protegir aquest correu contre UBE tan com volguem i més però si l’origen especificat en la transacció SMTP indica que el remitent és una compte de correu del mateix domini que el destí (sovint la mateixa compte de correu), aquest correu s’acceptarà com a legítim i no es demanarà autenticació perquè l’MTA on s’està enviant el correu és el destí del mateix. Gràcies a això el correu serà acceptat al MTA i només quedarà a expenses del anti-spam i regles UBE anturar-lo, el qual malgrat via SPF i d’altres similars intentarà aturar aquest correu això no sempre serà possible i menys si els intents d’injecció són de l’ordre de desenes de milers al dia. Ens trobavem que alunes desenes passaben els filtres igualment.

Així doncs, gràcies a aquest policy daemon he pogut programar un regla que diu algo així:

  • si IP d’enviant no és local
  • si origen del correu és un domini local
  • si destí del correu és un destí local
  • si l’usuari no s’ha autenticat
  • NO es pot enviar aquest correu!

Els clients que estan fora de l’empresa (roadwarriors) sempre que envien un correu ho fan via ASMTP així doncs, si volen enviar un correu a alguna compte del mateix domini que la seva ho faran de forma autenticada. Per altre banda, si un client de correu intern a l’emrpesa intenta enviar un correu ho farà amb una IP local de l’empresa i aquest filtre no el bloquejarà.

Com podeu veure el problema és una mica enrabassat. Per altre banda, si voleu fer un cop d’ull al fitxer de configuració policy.conf (un dels fitxers de configuració del aplicyd) que he creat és de l’estil d’aquest:

acl wl client_address NET_IP/MASK
action nice_users DUNNO
access wl nice_users

acl remitent sender @example.com
acl desti recipient @example.com
acl aut sasl_method (PLAIN|LOGIN)
action rej REJECT Auth required
access remitent desti !aut rej

Malgrat jo he usat el apolicyd per temes molt concrets s’ha de dir que el seu codi font és molt entenedor i simple de modificar, a més de suportar moltíssimes funcionalitats de serie que permeten ajustar les nostres regles de filtrat moltíssim. Realment m’ha sorprès de forma molt positiva no m’esperava que estigués tan ben pensat.

duplicity: còpies de seguretat senzilles i potents des de la CLI

2008/11/22 3 comentaris

Reading time: 3 – 4 minutes

Duplicity és un aplicatiu basat en python que de moment no disposa de frontend gràfic, sinó com les coses bones de la vida s’usa des de CLI. Esta orientat a les còpies de seguretat i la seva principal potència resideix en recolzar-se amb rdiffdir/rdiff/rsync per fer còpies de seguretat diferencies/incrementals. Això sembla que no sigui cap tret diferencial si no fos perquè suporta una bona colla de sistemes on enmagatzemar les còpies:

  • ssh/scp
  • local file access
  • rsync
  • ftp
  • HSI
  • WebDAV
  • Amazon S3

De moment ja he pogut comprovar que tan via Amazon S3 com via FTP, funciona la mar de bé. Això com podeu verure ja té més història, ja que fer un sistema de còpies diferencies i/o incrementals contra un FTP o contra S3, no és trivial. A més esta fet seguint tots els estàndards, és eficient en la gestió d’ampada de banda i suporta xifrat per clau pública i clau privada.

A continuació adjunto un petit cookbook dels paràmetres que jo més uso:

    • Fer un backup contra un FTP de tot el sistema, el backup es farà incremental sempre que la còpia incremental més vella no tingui més de 7 dies llavors es farà una còpia ‘full’. S’indica que els fitxers que es pujaran a l’FTP tenen una mida de 10Mb. No es copiaran els directoris /dev, /proc, /tmp, /mnt, /media
PASSPHRASE=clausimetrica duplicity incremental --full-if-older-than 7D -v4 --volsize 10 --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/mnt --exclude=/media / ftp://user:pass@hostname
    • Veure un llistat dels fitxers sobre els que hem fet còpia:
PASSPHRASE=clausimetrica duplicity list-current-files ftp://user:pass@hostname
    • Consultar quines còpies hi ha disponibles al repositori:
PASSPHRASE=clausimetrica duplicity collection-status  ftp://user:pass@hostname

Per restaurar les còpies de seguretat, cal pensar que sovint el que es vol és recuperar algún fitxer o directori i no pas tota la còpia. Així doncs aquí es tindran en compte aquests detalls.

    • Recuperem tota la còpia de seguretat sencera:
PASSPHRASE=clausimetrica duplicity ftp://user:pass@hostname /tmp/restore
    • Recuperem un fitxer o directori:
PASSPHRASE=clausimetrica duplicity --file-to-restore nom_fitxer_o_directori_a_recuperar ftp://user:pass@hostname /tmp/restore
    • Recuperem un fitxer o directori concrets de fa 3 dies enrera:
PASSPHRASE=clausimetrica duplicity -t 3D --file-to-restore nom_fitxer_o_directori_a_recuperar ftp://user:pass@hostname /tmp/restore

Com podeu comprovar l’ús de l’eina és ben senzill i fàcil de col·locar dins d’un crontab, però realment si ús calen combinacions més complexes cal que doneu un bon cop d’ull al man duplicity.

UPDATE (2015/08/17) How to install duplicity on Ubuntu 12.04

apt-get install -y python-paramiko python-gobject-2 python-dev build-essential python-pip python-software-properties
add-apt-repository ppa:duplicity-team
apt-get update
apt-get install -y duplicity

UPDATE (2016/08/02) Backup full Ubuntu Linux

PASSPHRASE=your_password duplicity incremental --full-if-older-than 7D -v4 --volsize 10 --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / rsync://the_user:the_password@host_server::/path/

El meu primer package de pfSense ‘dd_adv’

2008/10/21 1 comentari

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

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.

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.