oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: internet

authsmtp – serveis de relay autenticat

Reading time: 2 – 2 minutes

Tot llegint documentació sobre temes de postfix que com sempre ja sabeu que hi estic molt posat he trobat una empresa que es dedica a vendre serveis de relay dels nostres dominis via processos autenticats. És a dir, podem usar el nostre servidor domèstic amb una simple ADSL amb IP dinàmica i a través d’ASMTP podem enviar correus a través d’una IP lliure d’RBLs, registre PTR i altres problemes similars. Per tant, els nostres correus sortiran a la xarxa de forma totalment legítima i ben protegits a través d’aquest enllaç. El millor són els preus del servei que són més que raonables. Per exemple, per moltes PIMES i sistemes domèstics el cost mensual no superaria els 2€-3€.

No us confongueu, els serveis de l’empresa són de relay és a dir, no fan de mail-backup per tant els correus entrants no els guardaran ells i els re-enviaran cap al vostre SMTP sinó alrevés; el que vosaltres envieu usarà com a smart-host el servidor d’aquesta empresa. A més d’aquest servei també fan còpies de seguretat de tot el que s’envia perquè es pugui consultar a posteriori i es comprova que no s’enviin correus duplicats. A més quan vosaltres no estigueu dintre de l’oficina o de casa podreu enviar correus directament contra l’ASMTP com si del vostre servidor de correu es tractés. Tot el correu que s’envia passarà també per un anti-virus per assegurar que no envieu virus sense voler als vostres destinataris, això és realment una descàrrega de feina molt gran pels servidors de la vostre empresa ja que sovint és el que més carrega els servidors de correu.

Si voleu donar un cop d’ull a l’empresa: AuthSMTP

Migració de dreamhost a ovh

Reading time: 1 – 2 minutes

Només informar que si en les properes hores teniu problemes d’accés a la pàgina és perquè estic migrant de dreamhost a ovh. Com ja vaig comentar temps enrera estic molt desconentent del rendiment de CPU i disk que m’està donant el servei de dreamhost i aprofitantq ue acabo el contracte a final d’any he canviat de proveidor encara no tinc migrats gran part dels serveis però el més important que és el blog en principi ja esta migrat ara espero no patir problemes col·laterals de la migració i si tot va bé en les properes 72 hores continuaré migrant serveis.

Només com a detall comentar que per 19.99€+IVA tinc una màquina pròpia que administro jo amb el S.O. que vull i malgrat això hem suposi més feina a priori que no pas els serveis de dreamhost estic convensut que hi acabaré guanyant ja que almenys tot el que passi dependrà de mi, cosa que ja és dir molt a venir de dreamhost.

podcast 1×13: desafio networking [la solución]

Reading time: < 1 minute A pesar de que la solución se alcanzó y aplico durante los meses de agosto y septiembre, hasta hoy no he podido grabar la solución en este podcast. Espero que haya sabido explicarla bien y que quede claro como se ha hecho para solucionar el problema, sinó preguntad.

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.

podcast 1×11: desafio networking [el problema]

Reading time: < 1 minute Hablando sobre el problema del articulo sobre el desafio de networking. También aprovecho para enlazar una buena referencia sobre como comprender los problemas de secuencias TCP:

Espero haberme explicado bien y haber podido describir el problema algo mejor que en el articulo anterior, ya que no es sencillo describir un problema tan inusual.

[display_podcast]

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.

Postfix tips

Reading time: 6 – 9 minutes

Aquest inici de setmana l’he passat moltes i moltes hores llegint documentació del Postfix per tal de solucionar un problema a un client que tenia una cua de correu inmensa i que no hi havia manera de servir perquè el servidor no donava coll. Doncs bé, degut a això m’he hagut de llegir molts documents i volia referenciar-los per no perdre’ls de vista ja que molts d’ells són interessentíssims. Realment cada dia que passa estic més convensut que Postfix és la millor opció com a MTA, diria que he passat moltes hores i molts anys provant sendmail, exim i qmail. Però l’experiència sempre m’ha dit que Postfix era el que em solucionava les problemàtiques més inversemblants i així ha estat aquest cop també.

  • Postfix Bottleneck Analysis: aquest document és una introducció a l’eina qshape la qual ens permet veure quin és l’estat de les diferents cues que té postfix, no només om a totals sinó també destriat en dominis i amb una distribució temporal del temps que fa que el correu és a la cua. Realment molt i molt útil per saber on tenim realment acumulat el correu i quines mesures hem de prendre.
  • postsuper – Postfix superintendent: aquesta comanda ens permet fer tasques de manteniment a les cues de postfix. Malgrat la comanda postqueue també permet fer tasques d’aquest tipus aquestes tasques són molt més limitades i orientades a usuaris que no pas a administradors del sistema. Perquè entengueu la potència del postsuper algunes de les seves funcions són: borrar missatges d’una cua concreta a través del seu ID, posar missatges en estat hold així aquests missatges no s’intenten enviar i els tenim retinguts fins que ens interessi, es poden re-encuar missatges que ja han estat encuats així podem tornar a aplicar-los filtres que s’havien aplicat malament, etc.
  • Postfix built-in content inspection: bàsicament es tracta d’un conjunt d’ordres del fitxer main.cf que permeten filtrar els correus en funció d’expressions regulars aplicades a la capçalera del correu (header_checks), cos del correu (body_checks), adjunts mime (mime_header_checks) o caçalers dels correus adjunts als correus (nested_header_checks).
  • Postfix After-Queue Content Filter: aquest document explica com filtrar els correus de formés molt més avançades, per exemple, s’explica la base que tenen de funcionar aplicacions com l’amavisd-new quan s’integren amb postfix. Al que refereixo és a tenir un postfix escoltant el port 25, quan entra un correu aquest s’envia a un port de localhost, allà es processa el correu i es generen d’altres correus amb informes d’spam si fa falta i després es re-injecta a un altre port localhost en aquest cas publicat pel postfix i finalment aquest correu es serveix. Doncs això que sembla senzill de montar té les seves pecualiritats que cal tenir en compte i en aquest document s’expliquen molt i molt bé, a més ens referencia a eines que comento a continuació per crear els nostres propis SMTP proxies on podem aplicar els filtres que ens interessin. Un exemple d’aplicació, a part dels típics filtres anti-spam, seria montar serveis de comandes via SMTP o sigui, que enviant un correu amb un format concret aquest fes una serie d’accions i el resultat tornés al seu origen via email. En la meva època del packet radio usabem això per fer smtp2ftp, per exemple.
  • smtpprox – simple efficient SMTP proxy in perl: amb aquesta eina és trivial montar les nostres aplicacions a mida per fer filtres de correu tal com comentava en el punt anterior, a més des de la pròpia pàgina es referència a moltíssims patches per tal de fer funcions espcífiques amb aquesta eina. Alguns exemples: podem fer el mateix que fa amavisd-new però amb un codi molt més simple, podem fer de proxy d’autenticació per un SMTP que no té autenticació montada, tenir una llista de blacklist en MySQL, etc.Bàsicament l’SMTP proxy només fa de servidor SMTP per un costat i client SMTP per l’altre, al mig nosaltres podem processar el correu segons la seva informacó: capaçalera, adjuns, contingut del correu, etc.

Volia comentar de forma explícita una de les solucions ineressants que es presenta al primer document, el que parla sobre qshape. La idea és que a través d’aquesta utilitat podem trobar un domini sobrel el que s’hi encuen molts correus i per tant la cua de sortida de correus es veu perjudicada perquè aquest destí monopolitza gran part de la cua. Doncs bé, es tracta de construir una cua de sortida de correu només per aquest destí i fer que els correus que vagin cap allà es processin a part.

Per montar això cal:

  • Modificar el fitxer master.cf i afegir un “smtp” transport per la destinació en concret. Això es faria així:
  • /etc/postfix/master.cf:
        # service type  private unpriv  chroot  wakeup  maxproc command
        fragile   unix     -       -       n       -      20    smtp
  • Fixeu-vos que fixem el número de processos a un màxim de 20, això vol dir que com a molt hi podran haver 20 instàncies simultanees del procés “smtp” per servir correus d’aquesta cua de sortida.
  • Al main.cf configurem els límits de la cua que s’usarà pel transport “fragile” que hem configurat.
  • /etc/postfix/main.cf:
    transport_maps = hash:/etc/postfix/transport
        fragile_destination_concurrency_failed_cohort_limit = 100
        fragile_destination_concurrency_limit = 20
    
  • Ara toca crear el fitxer de transport on indicarem que els correus per aquest domini es serveixen per una cua particular, al costat del nom de la cua si es vol es pot indicar un host i un port cap a on es farà relay:
  • /etc/postfix/transport:
        example.com  fragile:
    
  • Recordeu que després de crear el fixer transport cal fer un postmap transport.
  • Per veure quin és l’estat de la nova cua, només cal fer qshape fragile.

Espero que si no coneixieu postfix aquest petit post hagi servit per veure fins a quin punt és simple i dinàmic de configurar, no pretenia fer cap introducció només una pura referència de documentació que crec que a partir d’ara intentaré tenir aprop.

iubui surt a la llum

Reading time: 2 – 4 minutes

logo iubui by enixit

Doncs només fa unes hores que ha sortit a la llum iubui l’empresa del meu gran amic Oriol. En la que a més també hi tinc alguna coseta a veure encara que sigui molt petita. Ja que he montat el servidor web. De fet, el gran mèrit obviament és de l’Oriol i és a qui li disitjo tota la sort del món. Per això també hi vull contribuir amb aquest petit gra d’arena. És a dir, intentant portar-li alguna que altre visita des d’aquest blog.

Potser ja comença a ser hora que expliqui alguna cosa del projecte, no? doncs bé, jo ho explicaria com un sistema de donar-li la volta a eBay, és a dir, encomptes d’anar a oferir coses perquè d’altres facin una puja per comprar-les. Aquí es tracta de fer un matching entre la gent que vol oferir coses i la gent que vol demanar coses. Però no pas com uns simples classificats sinó algo més elavorat i aprofitant la semàntica de la informació perquè la pròpia web ajudi a posar en contacte els compradors i venedors.

Segurament es pot explicar millor, per això des d’aquí convido a l’Oriol Mercadé a participar en el meu següent podcast on estaria bé que ens expliques algo més sobre iubui, a veure si realment el projecte té la vida que tots esperem.

UPDATE: demano el vot al Newsroom de MobuzzTV per l’article que parla de iubui.

UPDATE 2: bona descripció del Ferran, un dels programadors de iubui:

iubui.com. No busques, Pídelo! Se trata de ver la compra-venta de productos y servicios desde un nuevo paradigma que sólo es posible gracias a Internet. Iubui es una plataforma donde, por primera vez, el protagonista no es el vendedor ni lo vendido. El protagonista es el comprador, sus necesidades y sus condiciones: con el proyecto iubui el comprador ya no necesita hacerse un experto en lo que va a comprar, no necesita conocer donde se vende lo que quiere, ni necesita gastar tiempo y energías para realizar una compra. Con la plataforma iubui son los proveedores los que aconsejan al comprador, los que ofrecen sus producto y gastan energías en lo que les aporta beneficio. Y iubui.com ya es una realidad, hoy empezamos a operar. Si queréis y tenéis tiempo os invito a que pidáis todo aquello que necesitéis y tengáis paciencia porque estoy seguro que os harán ofertas muy interesantes.