oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: firewall

pfSense: per fi funcionen els aliases

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

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.

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.

pfSense deixava de re-enviar paquets misteriosament…

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.

Servidor FTP darrera un NAT (pure-ftpd)

Reading time: 2 – 2 minutes

Sovint quan montem un servidor FTP darrera d’un Firewall que fa DNAT per publicar els ports FTP (20, 21, tcp i udp) a internet ens deixa de funcionar l’FTP en mode Passive On. Llavors hem de fer allò tan molest i depenent del client tan difícil; o sigui, fer un Passive Off perquè la transmissió d’arxius, llistats de fitxers, etc. funcioni bé. Doncs avui cansat d’això en un servidor pure-ftpd que tinc montat a la feina i he posat solució ja que sinó tenia als tècnics molt limitats quan es trobaven a casa dels clients.

La cosa ha estat ben senzilla, només he hagut de llençar el pure-ftpd amb el paràmetre -p i especificar un rang de ports per on es faran les connexions passives. Jo he decidit que anessin entre el port 40000 i el 50000. Així doncs, el paràmetre ha quedat així: -p 40000:50000. Després al firewall he redirigit tot aquest rang de ports contra la IP interna del servidor i llestos (fent un DNAT). Ara ja funcionen perfectament els FTP passius.

Si tot això d’FTP passiu i no passiu, ús sona a xinès he trobat una petita web molt bona que explica la diferència entre un sistema i l’altre: Active FTP vs. Passive FTP, a Definitive Explanation (local).

pfSense: amb una Intel Quad PRO/1000 cal una versió >1.0.1

Reading time: 2 – 4 minutes

Avui he patit una d’aquelles feines d’administrador tan tontes i que et fan perdre tan de temps. Havia d’instal·lar una Intel PRO/1000 GT QUAD PORT en un servidor Compaq Proliant DL320 per fer de firewall amb un pfSense i el coi de servidor no tenia CDROM. El problema de connectar-li un CD extern és que detectava la tapa oberta i no s’engegava un cop superat aquest tema, com que la BIOS és vella i propietaria, no permetia arrencar amb un CD IDE sinó que volia que uses la controladora que porta instal·lada especialmet per aixo sinó no podia arrencara des de CD per instal·lar el pfSense. Al final he tret un dels disc durs del servidor, encara sort que són IDE, l’he posat a un ordinador nomal i l’hi he instal·lat el pfSense al fer el canvi de PC tot perfecte. Només un però, resulta que la versió 1.0.1 del pfSense no reconeix de forma automàtica la versió GT de la targeta de 4 ports d’intel. Així doncs, he hagut de baixar-me la versió beta de la 1.2 del pfSense que ha carregat el driver em del FreeBSD que reconeix a la perfecció la targeta de 4 ports.

intelquad.jpg

Realment una odissea de dia per fer una cosa ben senzilla. Ho comento perquè no perdeu el temps com jo intentant fer meravelles amb la versió 1.0.1 aneu directament a la 1.2 que malgrat estar en beta funciona molt bé. De moment diria que prou bé com per tenir-la en producció. El firewall finalment m’ha quedat amb 6 targetes de xarxa 2 a 100Mbps i 4 a 1000Mpbs. Dels 4 ports a 1000 n’hi ha 3 que hauran de treballar a plè rendiment quan hagi fet les proves d’estrés ja comentaré què tal. De totes formes, imagino que els resultats seràn excel·lents perquè FreeBSD realment és molt bo fent gestió de tràfic i més amb drivers tan madurs com el em per controlar el hardware d’intel.

Per cert, una altre odissea va ser trobar la targeta d’intel. Ja que malgrat fa molt de temps n’havia comprat una. De fet, el model que havia tocat era el MT i la que he montat avui és la GT, de fet ni el fabricant s’aclareix en decidir quina és la diferència real entre elles. Només anotar per si algún dia se’m torna a oblidar que les targetes les he trobat ben aprop de casa a un proveïdor de Vilafranca del Penedès que es diu ELPO. Bàsicament es dediquen al món dels SAIs però també fan de majoristes d’informàtica en general. El curiós és que en cap més distribuidor oficial de networking d’intel a l’estat la tenien ni me la volien portar.

pfSense: patch pel DynDNS quan la interficie WAN no té la IP pública

Reading time: 2 – 2 minutes

Si pel motiu que sigui, teniu un pfSense que amb el servei de Dynamic DNS i la vostre interficie WAN no té la IP pública amb la que voleu actualitzar el servei d’IP dinàmica que useu aquí trobareu la solució. Això pot passar per diversos motius:

  • Hi ha més d’una WAN
  • La WAN té una IP privada que enllaça amb el router
  • Accés a internet a través d’una VPN
  • etc

Doncs bé, concretament en el meu cas tinc dues sortides WAN i per si fos poc la que té IP dinàmica no té la IP asignada pel proveidor sinó una IP privada. Així doncs, buscant pels foros de pfSense he trobat aquesta solució al problema.

Es tracta de modificar el fitxer /etc/inc/dyndns.class. Primer de tot afegim aquest nou mètode (funció) a la classe:

/* Private function for getting real IP */
/* Author: Tri Tu */
function _checkip() {
   log_error("DynDns: Running _checkip() for real WAN IP");
   $ch = curl_init();
   curl_setopt($ch, CURLOPT_URL, 'http://checkip.dyndns.com');
   curl_setopt($ch, CURLOPT_HEADER, 0);
   curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
   $data = curl_exec($ch);
   curl_close($ch);
   list($part1, $part2) = split(': ', $data, 2);
   list($ip, $junk) = split('<', $part2);
   return $ip;
}

Després dins del mateix fitxer busquem tots els llocs on apareix:

$wan_ip = get_current_wan_address();

i ho canviem per:

$wan_ip = $this->_checkip();

Si ús fixeu, el tema és tan senzill com dir-li a la classe que per saber quina és la seva IP de WAN ha de cridar la funció anterior, aquesta funció connecta a la típica web que retorna la IP que tenim i a partir d’aquí capturem aquesta IP i l’assignem a la variable que s’usar per saber si ha canviat la nostre IP.

e-duna gestió d’amplada de banda en appliance

Reading time: 2 – 4 minutes

Totes les solucions de gestió d’ampada de banda a través d’appliance que coneixia fins ara venien de països on les connexions de les empreses són simètriques i les necessitats de gestió estan molt allunyades de la realitat de les telecomunicacions al nostre país. Doncs bé avui m’he trobat amb e-Duna. No sé si és una solució made in spain però té tota la pinta. El que si que esta clar és que el paquet de solucions que incorpora van des dels 2Mbps fins als 45Mbps. A més constantment fa referencia amb la possibilitat de fer gestió del balanceix de càrrega en diverses ADSL, la qual cosa és una realitat en les PYMES del nostre país.

esquema.jpg

Per tant, diria que és un dels appliance més ben enfocats per les necessitats diaries dels clients que estic acostumat a tocar. Els preus van dels 1.000€ aproximadament en endavant, segons l’ampada de banda a gestionar. La usabilitat segons els screenshots de la pàgina web sembla ben senzilla i inmediata. Potser dona la sensació de ser poc dinàmic en la seva configuració, però es clar, venint de sistemes on t’ho has de treballar tot tu, com pot ser linux i BSD, doncs qualsevol cosa és poc dinàmica.

Malgrat no l’he pogut provar, em moro de ganes de veuren revisions i crítiques perquè hi ha més d’un lloc en que m’agradaria col·locar-n’hi un d’aquests. De fet, diria que sovint aquest dispositius, sempre que funcionin bé, són la solució perfecte per gestionar de forma trivial problemes cada dia més patents a les empreses i que ens impliquen perdre més temps de configuració en els firewalls amb linux i d’altres productes que ens montem a mida. Per tant, a vegades cal cedir terreny als appliance si és per anar a dormir més tranquils i trencar-nos menys el cap quan ens demanen modificacions a les polítiques de gestió d’amplada de banda.

De fet, el producte segons la seva pàgina web fa moltes més coses aquí en podeu veure un resum. Però jo pel que em diu l’experiència només em quedaria amb la idea de gestionar i balancejar l’ampada de banda.

funcions.jpg

A més, pels que estigueu familiaritzats amb els típics distribuidors d’informàtica de tota la vida el podeu trobar a Diode.

pfSense: tutorial en català

Reading time: 1 – 2 minutes

firewall.jpg

A través del blog d’en Xavier Caballé he trobat un tutorial molt interessant del pfSense. Es tracta d’un liveCD que funciona en una base de BSD Installer (versió reduida del FreeBSD). A través d’una interficie web s’administra un firewall derivat del m0n0wall.

Les funcions del firewalls són realment interessants:

  • Totes les interficies de xarxa que volguem
  • DHCP Server
  • Snort
  • Squid
  • Radius
  • Portal captiu
  • Gestió d’ampada de banda
  • Balanceix de càrrega
  • Filtrat de paquets
  • NAT
  • DNS

I alguna altre que de ben segur m’he deixat d’esmentar. Espero que quan hem tornin a demanar per un bon firewall amb linux, ja no pensi només amb l’Astaro. Pel que fa a l’IPCop mai se m’ha ajustat al que volia.

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