Nov 16

Postfix autenticació amb sasldb

Reading time: 2 – 2 minutes

Quatre notes que tinc pendents de classificar, com donar suport d’autenticació a postfix de forma ràpida i senzilla.

Paquets que cal tenir a més del postfix: cyrus-sasl, cyrus-sasl-md5.

Línies que cal tenir al /etc/postfix/main.cf:

smtpd_sasl_application_name = smtpd
smtpd_sasl_type = cyrus
smtpd_sasl_path = sasl2/smtpd.conf
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Fitxer de configuració del servei d’autenticació /etc/sasl2/smtpd.conf:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

Assegurar-se que el propietari del fitxer /etc/sasldb2 és postfix.

El fitxer /etc/sasldb2 és una base de dades Berkeley DB que guarda els usuaris i les seves paraules de pas en text pla. Així doncs, no és molt segur però una solució més que suficient per molts entorns SOHO.

Gestió d’usuaris:

# afegir usuari
saslpasswd2 -a smtpd -u domini_exemple.com nom_usuari

# borrar usuari
saslpasswd2 -d -u domini_exemple.com nom_usuari

# llistar usuaris
sasldblistusers2

La configuració que heu de posar al MUA pel que fa al servidor de correu ha de ser del tipus:

usuari: nom_usuari@domini_exemple.com
pass: el que hagiu definit
mecanisme d'autenticació suportats:  PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

UPDATE 27/2/2012:

Perquè es pugui tenir accés al fitxer /etc/sasldb2 cal que el mòdul smtpd de postfix no es llenci com a chroot. Per evitar això cal modificar el fitxer /etc/postfix/master.cf concretament la línia del dimoni smtpd ha de quedar així:

smtp      inet  n       -       n       -       -       smtpd

Per tenir suport de SASL a Ubuntu Lucid cal instal·lar els paquets: sasl2-binlibsasl2-modules.

Nov 20

APT protocol o AptURL – instal·lant soft des del browser

Reading time: < 1 minute

AptURL o APT protocol plateja una idea molt interessant. Per exemple, quan estem mirant una pàgina web i aquesta ens parla d’un aplicatiu per Debian/Ubuntu la idea seria clicar a un enllaç del tipus: apt:exampleapp i això llençaria el gestor d’aplicacions (package manager) del sistema APT que instal·laria aquesta applicació en el nostre sistema.
Per tal de fer això possible hi ha una serie d’extencions per diversos navegadors: firefox, crhome, konqueror, opera, etc. si voleu més informació podeu consultar el wiki d’ubuntu on parla de AptURL.
Aug 21

Què és un WebHook?

Reading time: < 1 minute WebHook logo
Un WebHook és una HTTP callback, o sigui, un HTTP POST que es dona quan algo passa (un event); o sigui, que podem definir WebHook com a sistema de notificació d’events per HTTP POST.

El valor més important dels WebHooks és la possibilitat de poder rebre events quan aquest passen no a través dels ineficaços mecanismes de polling.

Si voleu més informació sobre aquest tema: WebHooks site.

Jun 20

httptunnel: TCP sobre HTTP

Reading time: 2 – 2 minutes

HTTPtunnel logo

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

  • hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
  • htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

  • suportar autenticació Digest i NTLM.
  • permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
  • poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
  • suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.
Apr 16

long polling amb jquery+jsonp+couchdb (cross domain suportat)

Reading time: 6 – 9 minutes

Porto mesos somiant amb fer la prova de concepte que explico en aquest article, intentaré descriure en que consisteix però ja aviso que la cosa és un pèl complicadilla.

Funcionalitats requerides:

  • long polling: l’objectiu és rebre els canvis d’una base de dades de couchdb en temps real sense haver d’anar preguntant si hi ha canvis, sinó que aquest s’envien cada vegada que es donen de forma automàtica.
  • A través de jQuery el que vull és actualitzar una pàgina web de forma asíncrona, de forma que els nous resultats que vagin entrant a la BBDD es vagin mostrant en temps real a la pantalla.
  • JSONP, és una tècnica que ens permet rebre la sortida JSON de CouchDB i després cridar una funció de callback de JavaScript. El problema és que la funció jQuery.getJSON() original de jQuery té algunes mancances que gràcies a el plugin jQuery-JSONP podem solucionar, aquestes són: (copy/paste de la web del plugin)
    • error recovery in case of network failure or ill-formed JSON responses,
    • precise control over callback naming and how it is transmitted in the URL,
    • multiple requests with the same callback name running concurrently,
    • two caching mechanisms (browser-based and page based),
    • the possibility to manually abort the request just like any other AJAX request,
    • a timeout mechanism.
  • CouchDB és una base de dades NoSQL basada en documents que és capaç d’emetre una senyal (trigger) cada vegada que el contingut d’una base de dades canvia. Per més informació sobre el tema es pot consultar a: CouchDB: The Definitive Guide al capítol Change Notifications.
  • Cross-domain: quan es llença una petició XmlHttpRequest (la base del AJAX) amb JavaScript tenim la limitació de només poder-ho fer sobre el domini que serveix la pàgina web, cap altre port ni subdomini. Obviament tampoc un altre host. Per saltar-se aquesta restricción és quan cal recorrer a JSONP.

La prova de concepte ha estat crear una base de dades anomenada: notifcations on es guarden documents que són notificacions a mostrar a la pàgina web.

Després he programat la següent web:

<html>
<head>
<script type="text/javascript" src="jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="jquery.jsonp-1.1.4.js"></script>
<script type="text/javascript">
function longpoll(since) {
    var url = "http://IP_COUCHDB_SERVER:5984/notifications/_changes?include_docs=true&feed=longpoll&since="+since+"&callback=?";
    console.log("since="+since);
    $.jsonp({
        "url":url,
        "success":function(data) {
            //console.log(data);
            since=data.last_seq;
            try {
                console.log(data.results[0].doc.msg);
            } catch(err) {
                console.log("error:"+err);
            };
            longpoll(since);
        },
        "error":function(msg) {
            //console.log(msg);
            console.log('capturat error');
        }
    });
};

var url = "http://IP_COUCHDB_SERVER:5984/notifications?callback=?";
$.jsonp({
    "url":url,
    "success":function(data) {
        //console.log(data);
        longpoll(data.update_seq);
    },
    "error":function(msg) {
        console.log(msg);
    }
});
</script>
</head>
<body>
cos
</body>
</html>

El codi és força simple de seguir, primer de tot es carreguen les llibreries: jQuery 1.4.2 i jquery-jsonp 1.1.4, ambdues necessaries per cridar el métode $.jsonp que és el que realment farà la feina.

A continuació es declara la funció longpoll que té com a paràmetre el númeral que indica quin ha estat el últim canvi a la base de dades. Aquest s’utiliza per construir la petició que es fa a CouchDB:

var url = "http://IP_COUCHDB_SERVER:5984/notifications/_changes?include_docs=true&feed=longpoll&since="+since+"&callback=?";

La URL el que fa és demanar el següent:

  • els canvis (_changes)
  • incloent els documents que han canviat (include_docs=true)
  • tracta la petició com a long polling (feed=longpoll)
  • mostra els canvis des de la versió X (since=X)
  • quan enviis els canvis fes una crida a la funció de callback definida aquí (callback=?)
    • ‘?’ és substituit per jquery-jsonp per la funció anomenada ‘C’, aquest nom es pot canviar usant paràmetres en la declaració de $.jsonp() que ve a continuació

Els missatges de l’estil ‘console.log()‘ són per tenir un seguiment del que va passant a la consola de javascript del navegador.

$.jsonp() té força paràmetres possibles definits a la API, però en aquesta prova de concepte només uso ‘url’, ‘success’ i ‘error’. El primer esta clar que és, els altres dos són les funcions a cridar quan l’acció va bé o malament respectivament. Dins de la funció posem el codi referent a les accions que volem fer, per exemple, actualitzar la pàgina actual. Com que això només és una prova de concepte el que faig és mostrar missatges per consola i llestos. La part més important és fixar-se que quan la cosa ha anat bé es fa una crida a ella mateix de forma que la cosa no acabi mai. De fet quan hi ha un error es podria també fer una crida a si mateix perquè no pares de provar de llençar la petició un i altre cop, però el que he fet per provar eś que es notifiqui a la consola de javascript i prou.

Fora de la funció longpoll el que es fa és una petició JSONP per saber quina és l’últim número de seqüència de la base de dades, paràmetre necessari per entrar per primera vegada a la funció recursiva de longpoll.

Conclusions

Pot semblar tot una mica enravassat però diria que he simplificat el problema moltíssim, ja que fins ara havia estat teoritzant moltíssim sobre el tema. Fins que ahir i abans d’ahir vaig haver de posar-me a provar-ho a la pràctica per saber exactament com es podia implementar. Sota el meu punt de vista ha quedat tot força net i entenedor.

Pels que sou programadors de webs habitualment haureu tingut necessitats semblants així doncs espero que ús pugui ser tan útil com a mi, de fet, fa unes setmanes que estic treballant amb Tiny Core Linux montant un Quiet PC sobre una DOM de 512MB per usar-la de sistema de monitorització de les meves xarxes i les d’alguns clients, espero que d’aquí uns mesos pugui donar-vos més informació del projecte.

Mar 12

Podcast 2×04: SSH avançat

Reading time: 3 – 5 minutes

El podcast



Notes sobre el podcast

  • -L: connecta per SSH a un HOST Un cop allà obre una connexió TCP a un altre HOST:PORT i obre un port TCP local que al connectar-hi ens envia al HOST:PORT anteriors, o sigui, portforwarding.
    • -L [bind_address:]port:host:hostport]
  • -W: connecta per SSH a un HOST un cop allà obre una connexió TCP a un altre HOST:PORT i ens retorna a la stdin/stdout el contingut d’aquest darrer enllaç TCP
    • -W host:hostport
  • -R publicar un port: connecta per SSH a un host i un cop allà publica un port TCP, quan un client es connecta a aquest port TCP accedeix per SSH a la màquina que ha llença l’enllaç SSH i obre un altre enllaç TCP a una altre IP:PORT.
    • -R[bind_address:]port:host:hostport
  • -D socks5: connecta per SSH a un HOST i després publica un port SOCKS5/TCP, és a dir, que podem connectar a aquest port local i sortir a internet a través de la IP del HOST on hem connectat per SSH
    • -D [bind_address:]port
  • -w tunel: connecta per SSH a un HOST i el socket que s’ha usat per fer l’enllaç SSH es connecta a dues interficies de tipus TUN, una a cada extrem del socket. Així doncs, si configurem les corresponents IPs a les interficies TUN tenim un tunel/VPN montada entre els extrems.
    • -w local_tun[:remote_tun]

HPN-SSH

La web de: HPN-SSH -> especialment interessant: Dynamic Windows and None Cipher

  • treballa amb mida de finestra dinàmica
  • treballa sense xifrat quan un enllaç no té terminal associat, sovint usat per pas de fitxers

Les proves:

  • Openssh 5.3p1 + hpn-13 (només el patch: Dynamic Windows and None Cipher)
  • després d’aplicar el patch: openssh5.3-dynwindow_noneswitch.diff.gz
  • modifiquem el fitxer: sshconnect2.c
    linia: 366
    - 		if (!tty_flag) /* no null on tty sessions */
    + 		if (1) /* no null on tty sessions */
  • així podem fer SSH sense xifrar només després d’haver fet el login.

exemple ampla de banada d’un SSH amb xifrat aes128-ctr, usant finestra dinàmica:

scp -v -oNoneEnabled=no -oNoneSwitch=yes fitxer root@127.0.0.1:/tmp/ssh
o
ssh -v -oNoneEnabled=no -oNoneSwitch=yes root@127.0.0.1 "dd if=/dev/zero"|pv > /dev/null

velocitat de transferència:  13.7MB/s
  • debug ciphers, una única negociació de ciphers:
    debug1: AUTH STATE IS 0
    debug1: REQUESTED ENC.NAME is 'aes128-ctr'
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: REQUESTED ENC.NAME is 'aes128-ctr'
    debug1: kex: client->server aes128-ctr hmac-md5 none
    

exemple sense xifrat, usant finestra dinàmica:

scp -v -oNoneEnabled=yes -oNoneSwitch=yes fitxer root@127.0.0.1:/tmp/ssh
o
ssh -v -oNoneEnabled=yes -oNoneSwitch=yes root@127.0.0.1 "dd if=/dev/zero"|pv > /dev/null

velocitat de transferència:  37.4MB/s
  • abans del pass de login:
  • debug1: AUTH STATE IS 0
    debug1: REQUESTED ENC.NAME is 'aes128-ctr'
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: REQUESTED ENC.NAME is 'aes128-ctr'
    debug1: kex: client->server aes128-ctr hmac-md5 none
    
  • després d’autenticar-se:
  • debug1: AUTH STATE IS 1
    debug1: REQUESTED ENC.NAME is 'none'
    debug1: Requesting NONE. Authflag is 1
    debug1: None requested post authentication.
    debug1: kex: server->client none hmac-md5 none
    debug1: REQUESTED ENC.NAME is 'none'
    debug1: Requesting NONE. Authflag is 1
    debug1: None requested post authentication.
    debug1: kex: client->server none hmac-md5 none
    
Mar 09

Podcast 2×03: eines per jugar amb SOCKS5

Reading time: 1 – 2 minutes

Finalment l’última entrega de la trilogia de podcasts sobre SOCKS. Com indica el títol i podeu veure amb els links aquest parla d’eines per montar servidors SOCKS i wrappers per montar clients SOCKS5.

El podcast:

Referències:

Mar 09

Podcast 2×02: SOCKS5 Bytestreams (XEP-0065)

Reading time: 4 – 7 minutes

La segona part sobre la trilogia de SOCKS5.

El podcast:

Exemples extrets del XEP-0065:

Example 1. Initiator Sends Service Discovery Request to Target

<iq type='get'
    from='initiator@example.com/foo'
    to='target@example.org/bar'
    id='hello'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 2. Target Replies to Service Discovery Request

<iq type='result'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='hello'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='proxy'
        type='bytestreams'
        name='SOCKS5 Bytestreams Service'/>
    <feature var='http://jabber.org/protocol/bytestreams'/>
  </query>
</iq>

Example 3. Initiator Sends Service Discovery Request to Server

<iq type='get'
    from='initiator@example.com/foo'
    to='example.com'
    id='server_items'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

Example 4. Server Replies to Service Discovery Request

<iq type='result'
    from='example.com'
    to='initiator@example.com/foo'
    id='server_items'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='streamhostproxy.example.net' name='Bytestreams Proxy'/>
  </query>
</iq>

Example 5. Initiator Sends Service Discovery Request to Proxy

<iq type='get'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='proxy_info'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 6. Server Replies to Service Discovery Request

<iq type='result'
    from='streamhostproxy.example.net'
    to='initiator@example.com/foo'
    id='proxy_info'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='proxy'
              type='bytestreams'
              name='SOCKS5 Bytestreams Service'/>
    <feature var='http://jabber.org/protocol/bytestreams'/>
  </query>
</iq>

Example 7. Initiator Requests Network Address from Proxy

<iq type='get'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'/>
</iq>

Example 8. Proxy Informs Initiator of Network Address

<iq type='result'
    from='streamhostproxy.example.net'
    to='initiator@example.com/foo'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'>
         sid='vxf9n471bn46'>
    <streamhost
        jid='streamhostproxy.example.net'
        host='24.24.24.1'
        p
        zeroconf='_jabber.bytestreams'/>
  </query>
</iq>

Example 9. Proxy Returns Error to Initiator

<iq type='error'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'/>
  <error code='403' type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 10. Proxy Returns Error to Initiator

<iq type='error'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='discover'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'/>
  <error code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 11. Initiation of Interaction

<iq type='set'
    from='initiator@example.com/foo'
    to='target@example.org/bar'
    id='initiate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'
         mode='tcp'>
    <streamhost
        jid='initiator@example.com/foo'
        host='192.168.4.1'
        port='5086'/>
    <streamhost
        jid='streamhostproxy.example.net'
        host='24.24.24.1'
        zeroconf='_jabber.bytestreams'/>
  </query>
</iq>

Example 12. Target Refuses Bytestream

<iq type='error'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='initiate'>
  <error code='406' type='auth'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 13. Target Is Unable to Connect to Any StreamHost and Wishes to End Transaction

<iq type='error'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='initiate'>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Example 16. Target Notifies Initiator of Connection

<iq type='result'
    from='target@example.org/bar'
    to='initiator@example.com/foo'
    id='initiate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'>
    <streamhost-used jid='streamhostproxy.example.net'/>
  </query>
</iq>

Example 19. Initiator Requests Activation of Bytestream

<iq type='set'
    from='initiator@example.com/foo'
    to='streamhostproxy.example.net'
    id='activate'>
  <query xmlns='http://jabber.org/protocol/bytestreams'
         sid='vxf9n471bn46'>
    <activate>target@example.org/bar</activate>
  </query>
</iq>

Example 20. Proxy Informs Initiator of Activation

<iq type='result'
    from='streamhostproxy.example.net'
    to='initiator@example.com/foo'
    id='activate'/>

Referències:

<iq type=’get’
from=’initiator@example.com/foo’
to=’target@example.org/bar’
id=’hello’>
<query xmlns=’http://jabber.org/protocol/disco#info’/>
</iq>
Mar 08

reDuh: TCP sobre HTTP

Reading time: 1 – 2 minutes

La idea es força simple es tracta de transportar un fluxe TCP sobre d’una connexió HTTP convencional, fiexeu-vos que en aquest cas no estem parlant de proxies ni similars. Sinó de paquets TCP+HTTP que en la part de dades del HTTP tornen a implementar TCP, si fessim un petit esquema seria algo així:

+----+----+------+------+-----+------+
|... | IP | TCP | HTTP | TCP | DATA |
+----+----+------+------+-----+------+

Si realment teniu aquest interés montar reDuh és realment senzill, de fet, suporta servidors amb JSP, PHP i ASP. En escència l’únic que fa és usar aquests protocols per re-obrir una connexió TCP. Així doncs, al servidor on montem aquesta eina hem de tenir certs privilegis per poder obrir sockets des d’un script.
L’eina no és massa recomanable si pensem tenir fluxes de dades molt intensos, per exemple, senssions VNC. Però funciona prou bé si el que volem és transportar una sessió SSH o similar.

Mar 05

Proxytunnel: connecta un socket a través d’un proxy HTTP i HTTPs

Reading time: 2 – 2 minutes

Descrirure tècnicament el que fa proxytunnel és força senzill, ja que l’únic que fa és connectar l’entrada i sortides estàndard a través d’un socket que va del client al servidor a través d’un servidor proxy HTTP o HTTPs; soportant autenticació de diversos tipus en el servidor proxy.
Gràcies a aquesta funcionalitat tan simple es pot aplicar en infinitat de llocs, per exemple, com a backend d’OpenSSH per tal de poder fer connexions SSH a través d’un proxy HTTP. Això si el proxy haurà de suportar el mètode CONNECT.
Un cop ha establert la connexió amb l’extrem desitjat publica un port a través del qual ens podem connectar a través d’un client TCP convencional i enviar/rebre dades de l’altre extrem del túnel.
Quan treballem sobre proxies HTTP aquests no poden fer inspecció de continguts de capa 7 sinó s’adonaran que el tràfic qeu es passa no és legítim, encanvi si fem el túnel sobre HTTPs això no e un problema ja que no es pode inspeccionar les dades que van per sobre de la capa 4 al anar xifrades.
També cal pensar que és habitual que si el mètode CONNECT, que ha de ser suportat pel proxy esta habilitat (cosa rara que passi) segurament estarà restringit a connectar-se al port 80, 8080 i 443 remots, com a molt. Així doncs, si el que volem és fer una connexió SSH el que hem de fer és publicar el servidor SSH per algún d’aquests ports.
Si esteu interessats en aplicar la solució de la connexió SSH sobre proxy HTTP/s ús recomano seguir el manual que hi ha a la pàgina: DAG WIEERS: Tunneling SSH over HTTP(S).