Category: System administration, Databases, Messaging and Security

Getting help to configure spamassassin.conf

Reading time: 2 – 3 minutes

Configure spamassassin is never easy to do. But when you look for information in Google usually you will be mad . The most common help method in linux is use ‘man command’ but it doesn’t work or information is not enough usually.

After a lucky search I found this command to get an extended information about how to configure spamassassin.conf file.

perldoc Mail::SpamAssassin::Conf

Prey – rastrejar el portàtil i el lladre

Reading time: 2 – 4 minutes

prey logoQuan ens roben el portàtil l’únic que ens queda fer és resar perquè siguem realistes, és molt poc provable que la policia el trobi. Així doncs, el que preten fer prey és enviar-nos tota la informació possible del portàtil després de que ens l’hagin robat.

El seu funcionament és força simple, però al mateix temps s’ha de dir que la idea sembla força eficient. En la versió per linux es tracta d’un script fet amb perl que es col·loca al crontab, de forma que cada x’s minuts es connecta a una URL del servidor de prey o del nostre propi servidor. Aquest URL sovint respon dient que tot va bé, és a dir, que el portàtil no ha estat marcat com a robat. En cas contrari, el servidor respon via HTTP dient que el dispositiu ha estat robat. En aquest moment és quan l’script es posa a treballar i es posa a recollir tot tipus d’informació per reportar-la a la pàgina web:

  • geolocalització per GPS o Wifi, si no disposem de GPS. He provat la localització per wifi i va força bé.
  • fa fotos amb la webcam del portàtil i captures de pantalla
  • reporta tota la informació que pot sobre processos que hi ha corrent al sistema, rutes, informació de les wifis veïnes, etc.
  • també podem fer sonar alarmes, borrar informació remotament, que ens enviï alguns arxius abans de ser borrats,etc.
  • a més els reports que es van reben queden arxivats en una interficie força amigable i molt senzilla d’usar
  • a més el software d’auto-actualitza

La compte gratuïta que ofereix la pàgina web permet tracejar fins a 3 dispositius, obviament si usem el nostre propi servidor HTTP podrem tracejar tots els dispositius que volem. Si volem usar més dispositius haurem d’adquirir una compte professional que tampoc sembla massa cara: per exemple, la més econòmica és la de 12€/mes que permet controlar fins a 10 dispositius amb un màxim de 25 informes per cada dispositiu.

Jo he provat la versió de Windows i la de Linux i ambdues m’han funcionat força bé a la primera, però pel que posa a la web també tenen la versió de Mac i la d’Android. Aquest última diria que és molt nova. Malgrat això en els meus dos Androids no uso prey sinó que uso WaveSecure. Pensat especialment per a dispostius mòbils, ja que tenen versions per: Blackberry, Symbian, Windows phone, Java i Android, és clar.

PAM (Pluggable Authentication Modules)

Reading time: 2 – 2 minutes

Amb les quatre notes que adjunto en aquest article es preten tenir una guia per tal de poder seguir i entendre els fitxers de configuració associats a PAM.

Quan PAM va associat a un servei aquest té un fitxer de configuració dins de /etc/pam.d sovint amb el mateix nom del servei o quelcom que ens el recorda. Dins de cada fitxer d’aquests es defineixen quatre categories pel procés d’autenticació:

  • auth – autenticació
  • account – gestió d’accés
  • password – quan i com es pot canviar la paraula de pas
  • session – entorn de configuració de l’usuari, accés al seu perfil

No és obligatori definir les quatre categories per tots els serveis, hi ha serveis que amb la categoria auth, en tenen prou. O d’altres que les requereixen totes.
PAM té una selecció de diferents models per cada categoria que s’organitzen en una pila. Cada mòdul esta etiquetat amb el que s’anomena una bandera de control. A través d’aquestes eines és com l’administrador controla el procés d’autenticació dels usuaris sobre els serveis.

Les banderes de control suportades per PAM són:

  • required
  • requisite
  • sufficient
  • optional

Si un mòdul marcat amb required, requisite o sufficient respon de forma negativa es deté l’execusió de la pila de forma inmediata.
Si la resposta és positiva en un mòdul: required, requisite o optional llavors PAM seguirà examinant la resta de mòduls.
Si un mòdul sufficient respon positivament es considera positiva la resposta a tota la categoria que s’esta examinant.

Autenticació PAM/OTP via PHP

Reading time: 21 – 34 minutes

Una bona forma de continuar aprofindint amb el tema OTP i també amb PAM, després de l’article: Shellinabox i OTP, és explicar-vos com m’ho he fet per afegir suport OTP al PHP, de forma que quan programem amb PHP es pugui delegar l’autenticació al sistema PAM del linux. Obviament això té certes restriccions perquè PHP corre amb els permisos de l’usuari de l’Apache, o bé, de l’usuari del FSGI, etc. L’important de fer notar és que no és habitual llençar codi PHP amb permisos de ‘root’. Així doncs, depèn de quina acció li fem fer al PAM aquest no la podrà dur a terme, per exemple, no podrà accedir al fitxer /etc/shadow per validar el password de sistema. De fet, com que el que jo vull és treballar amb OTP això no és rellevant.

El primer que s’ha de fer és instal·lar el paquet php5-auth-apm i reiniciar l’Apache:

apt-get install php5-auth-pam
/etc/init.d/apache2 restart

Ara anem al directori /etc/pam-script.d i fem:

cd /etc/pam-script.d
rm pam_script_acct
# creem fitxer pam_script_acct
echo '#!/bin/sh' > pam_script_acct
echo 'exit 0' >> pam_script_acct
chmod 755 pam_script_acct

Ara toca crear el fitxer /etc/pam.d/php, amb el següent contingut:

auth    sufficient      pam_script.so onerr=fail dir=/etc/pam-script.d/
account  required       pam_script.so onerr=fail dir=/etc/pam-script.d/

Amb això ja en tenim prou per anar a jugar amb el php, el primer és amb un phpinfo(); validar que apareix algo així:

i després podem fer un codi tan senzill com aquest:

<?php
    $result=pam_auth('user','password-otp',&$error);
    var_dump($result);
    var_dump($error);
?>

La comanda clau com podeu veure és pam_auth, passeu com a paràmetre el nom de l’usuari, el password que ús ha donat la vostre aplicació generadora de passwords OTP i la variable que voleu que reculli els errors la passeu per referencia. En cas d’error de l’autenticació aquesta comanda contindrà la descripció de l’error. Aquesta mateixa funció retorna un codi boleà amb el resultat de l’autenticació.

Shellinabox i OTP (One Time Password)

Reading time: 40 – 67 minutes

A vegades cal poder accedir a la shell d’un servidor però no es disposa de cap client SSH ni res semblant, o fins hi tot hi ha casos en que només si pot accedir a través de proxy usant HTTP, ni tan sols es disposa d’HTTPs. Per aquests casos el que he fet és montar el següent:

Un shellinabox que és un dimoni que publica una shell a través d’HTTP, de forma que es pot usar el navegador com a client. A diferència d’altres solucions aquesta esta implementada aprofitant AJAX i no li cal suport de flash, java o d’altres tecnologies similars. Si no l’heu provat, feu-ho perquè és impressionant el bé que arriba a funcionar.

Bé doncs, gràcies al dimoni de shellinabox ja podriem publicar al port 80 la pantalla de login del nostre servidor, però en el meu cas al port 80 hi tinc l’Apache funcionant, així doncs, el que he fet és montar un proxy invers aprofitant les funcionalitats d’Apache, de forma que quan em connecto a un subdomini concret l’Apache redirecciona la meva connexió HTTP al servidor de shellinabox.

Al usar aquest client que funciona sobre un protocol sense xifrar tothom podria aconseguir de forma senzilla l’usuari i password que uso per accedir a la shell. Per tal de solucionar aquest problema el que he fet és instal·lar com a mètode d’autenticació al PAM del servidor suport OTP.

O sigui, que quan l’usuari fa login per qualsevol servei que usi el sistema d’autenticació ‘common-auth’ del PAM aquest podrà fer-ho amb el password del sistema o bé amb un password d’un sol ús. Això em garanteix que després de que jo m’hagi autenticat a la shell amb un password ningú més ho podrà fer amb aquell password.

Esquema de la idea

Configuració d’apache, proxy invers

Primer de tot cal activar el modul ‘proxy’ de l’Apache:

a2enmod proxy

Després creem un subdomini i re-enviem el tràfic cap al servidor de shellinabox:

    
<VirtualHost *:80>
    ServerName elteusubdomini.exmaple.tld

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:4200/
    ProxyPassReverse / http://127.0.0.1:4200/

    LogFormat "%h %l %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-Agent}i\" %D" common
    CustomLog /var/log/apache2/elteusubdomini.exmaple.tld.access.log common
    ErrorLog  /var/log/apache2/elteusubdomini.exmaple.tld.error.log
    LogLevel  warn
</VirtualHost>

Després d’això ja podeu reiniciar l’apache, recordeu a crear la corresponent entrada al DNS.

Paràmetres que uso pel shellinabox

Malgrat el manual del shellinabox esta plè d’opcions molt interessants en el meu cas amb els següents paràmetres n’he tingut prou:

/opt/shellinabox/bin/shellinaboxd --no-beep -t -b
  • –no-beep no vull que emeti ‘beeps’, proveu-ho sense això a mi em van fotre un ensurt que encara tremolo
  • -t per deshabilitar l’SSL que s’activa per defecte
  • -b es llença en background

Configuració d’OTP al PAM del linux

El suport OTP que he afegit al PAM és molt limitat i bàsic, ja que no volia afegir més complexitat al sistema, o sigui, que per controlar els usuaris que poden accedir via OTP he usat un simple fitxer de text pla i per validar l’autenticació em recolzo amb el pam_script que és un mòdul de PAM que permet llençar un script arbitrari per validar l’autenticació.

Potser una de les formes més recomanables si voleu usar OTP en un servidor més professional que el que jo he usat seria fer-ho a través de RADIUS, o bé, usant MOAS el qual ofereix una interficie web feta amb PHP i backend MySQL per mantenir una taula d’usuaris i d’altres detalls de configuració.

Tornant al cas que ens ocupa, la configuració de PAM que he usat és tan senzilla com:

# fitxer: /etc/pam.d/common-auth
...
auth    sufficient      pam_script.so onerr=fail dir=/etc/pam-script.d/

auth    sufficient      pam_unix.so nullok_secure try_first_pass
...

La primera línia afegeix suport de pam_script per l’autenticació, a més de posar-hi dos paràmetres que indiquen que si aquesta falla fallarà l’autenticació i també indica a quin directori s’ha d’anar a buscar l’script d’autenticació. Aquí és on es provarà si s’ha introduït un password OTP.

La segona línia és estàndard en l’ubuntu on he fet la configuració, excepte l’últim paràmetre try_first_pass que diu que torni a provar el password que s’ha introduït en el pas anterior, així no l’hem de re-introduïr per validar si el password intruït és un password de sistema.

Ambdues línies usen la ‘flag’ sufficient, o sigui que si algún dambdós es compleix serà suficient per validar positivament l’autenticació.

El pam_script és un mòdul de PAM que al instal·lar-lo ens ha creat la carpeta /etc/pam-script.d amb uns quants fitxers al seu interior. Aquí l’únic que haurem de fer és borrar l’enllaç simbòlic anomenat: /etc/pam-script.d/pam_script_auth. Ja que per defecte aquest apunta a /etc/pam-script.d/pam_script i nosaltres no volem usar l’script per defecte sinó el nostre propi script, o sigui, el que fa la validació OTP.

L’script que fa la validació l’he modificat una miqueta respecte l’script per defecte i l’he col·locat a: /opt/otp/otp-auth. Ara ja podem refer l’enllaç simbòlic que haviem borrat abans:

ln -s /etc/pam-script.d/pam_script_auth /opt/otp/otp-auth

En el directori /opt/otp/ cal que tinguem també:

  • otp-auth – script que fa la validació, fet amb Perl i amb alguna dependència
  • otp-secrets – fitxer de configuració dels usuaris que poden usar OTP
  • cache/ – directori necessari per guardar-hi claus de forma temporal

El fitxer de configuració del /opt/otp/otp-auth el /opt/otp/otp-secrets té aquest pinta:

%users =
(
        username =>
        {
                secret => 'codi_secret_compartit_amb_eina_client',
                pin => ping_acces_eina_client,
                offset => 0,
        },
        anotheruser =>
        {
                secret => 'ZZZZZZZZZZZZZZZZ',
                pin =>  IIII,
                offset => 0,
        },
);
1;

En el meu cas, el secret l’he generat amb l’eina client que m’he instal·lat al mòbil (Android). El pin simplement ús el podeu inventar i és necessari introduir-lo al client que genera les claus.

Client OTP per Android

El client que he usat per Android és el Mobile-OTP, quan l’executeu per primera vegada ús guiarà perquè genereu un secret i un pin quan els tingueu els heu de posar al fitxer de configuració /opt/otp/otp-secrets.

Procés d’ús

Anem a un navegador qualsevol connectat a internet, accedim al subdomini que hem definit i ens surt una pantalla de login, introduïm l’usuari i ens demana el password.

Ara agafem el mòbil i obrim l’aplicació Mobile-OTP, posem el codi PIN i premem el botó ‘Calculate OTP’ inmediatament després ens surt un codi amb números i lletres i una longitud de 6 caràcters, introduïm aquest codi com a password de la nostre compte i ja som dins.

Recordeu que aquest codi és vàlid durant uns 2 minuts aproximadament, després l’haureu de tornar a generar. Aquest codi també deixa de ser vàlid en el moment en que ja l’heu usat un cop, o sigui, que si voleu fer dos logins seguits haureu de generar dos codis.

També es pot usar OTP amb altres serveis

Recordeu que al configurar el sistema d’autenticació OTP al PAM ho he fet a l’arxiu ‘common-auth’, això vol dir que qualsevol servei de la màquina que usi aquest fitxer d’autenticació (la majoria ho fan: SSH, POP3, IMAP, etc) suportarà el sistema d’autenticació OTP.

Així doncs, si feu un SSH dels de tota la vida cap a la vostre màquina però no voleu que ningú sàpigue el vostre password només mirant com escriuen els vostres dits podeu aprofitar aquest sistema.

Referències

wiki: Glossari de seguretat

Reading time: < 1 minute Al meu wiki he començat a construir un glossari sobre seguretat, com sempre relacionat amb linux. Bàsicament són petits resums, sovint en anglès, sobre com funcionen certs protocols, mecanismes, estàndards, llibreries, software, etc. L'enllaç original del contingut és: Gloassari de seguretat

A continuació incrusto de forma dinàmica la pàgina del wiki, perquè s’actualitzi l’article en temps real. Potser això no serà visible des de l’RSS, ho desconec. Per tant, aquesta pàgina estarà en construcció indefinidament, ja que l’usaré com a quadern de notes per aquests temes. De la definició de certs termes se’n poden derivar, podcasts, screencasts, articles, etc.

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

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!

gnoMint: X.509 CA management tool

Reading time: 2 – 3 minutes

Quan administres alguns sistemes i comences a montar serveis SSL arriba un moment que acabes familiaritzan-te amb la sintaxis d’openSSL per la generació de certificats i fins hi tot entitats certificadores autosignades. El problema és quan has de mantenir diverses entitats i diversos certificats arriba un moment que ja no recordes a quina màquina tens els fitxers guardas i l’administració de tot plegat es fa força pesat.

Així doncs, m’he decidit a provar gnoMint que eś una eina programada amb GTK i que fa de GUI a les típiques funcioalitats que demanem sovint al openSSL. Així doncs, és molt senzill de crear diverses entitats certificadores amb diversos certificats associats a cada una d’elles. Però el més important és senzillissim de mantenir, ja que en un cop d’ull saps quins certificats tens creats i quins et caldran per un nou projecte. A més de poder exportar les claus publiques i privades de forma ben senzilla.

Un petit resum de funcionalitats de l’eina seria el que trobem a la seva web:

  • Creating all the infrastructure to keep and run a Certification Authority, saved in only one file.
  • Create Certification Signing Requests, allowing to export them to PKCS#8 files, so they can be send to other CAs.
  • Create X.509 certificates, with a usual set of subject-parameters.
  • Export certificates and private keys to PEM files, so they can be used by external applications.
  • For each CA, establish a set of policies for certificate generation.
  • Import CSRs made by other applications
  • Export PKCS#12 structures, so the certificates can be imported easily by web and mail clients.
  • Revoke certificates, and generate the corresponding CRLs
  • Allow the possibility of keeping the CA private key, or other private keys, in external files or devices (as USB drives)
  • Allow the management of a whole hierarchy of CAs, with their respectives certificates.
  • Import pre-existing Certification Authorities, with all their data.
  • Allow an easy CA operation from command-line tools, for batch certificate creation, or integration with other utilities.

openssl: certificats autosignats de forma molt simple

Reading time: 27 – 45 minutes

Fins aquest matí cada vegada que necessitava crear-me certificats auto-signats (self-signed certificates) usava llarguíssimes llistes d’opcions amb l’openssl, però avui he descobert (digueu-me lent) que si descarregues el paquet d’OpenSSL i el desempaquetes dins del codi font hi ha un directori que es diu: easy-rsa.

Com es pot observar el nom ja dona moltes pistes, doncs bé, dintre d’aquest hi trobem encara un altre directori anomenat 2.0. Aquí dintre, hi ha un munt d’scripts que ens simplificaran moltíssim la vida a l’hora de crear certificats, com sempre en faig un resum en forma de cookbook.

    • Editar el fitxer vars. Cal modificar el valor de les variables:
export KEY_COUNTRY="yourContry"
export KEY_PROVINCE="yourProvince"
export KEY_CITY="yourCity"
export KEY_ORG="myOwnOrg"
export KEY_EMAIL="user@domain.tld"
    • Després netegem el directori de claus perquè no hi hagi restes d’exemples:
./clean-all
    • Carreguem variables d’entorn del fitxer vars:
source ./vars
    • Creem una CA (Certificate Authority):
./pkitool --initca
    • Crear el certificat per un servidor:
# ./pkitool --server
# penseu que a vegades el common_name ha de ser el url_host del servidor, per exemple, en servidors https
./pkitool --server nom_servidor
    • Certificats per un client:
# ./pkitool
./pkitool nom_client
    • Certificat per un client enpaquetat amb PKCS12:
# ./pkitool --pkcs12
./pkitool --pkcs12 nom_client
./pkitool --build-dh

NOTA: en cas de volgueu protegir les claus privades amb una clau simètrica per evitar que siguin usades per tercers persones podeu fer-ho afegint el paràmetre ‘–pass‘ a les comandes anteriors.

Les claus generades les podeu trobar al directori ‘easy-rsa/2.0/keys‘.

Pels que no tingueu massa per la mà el tema dels certificats posaré quatre notes sobre els fitxers creats:

  • *.csr: Certificate Signing Request, petició de certificat que s’envia a una CA perquè ens el torni signat.
  • *.crt: Certificat signat per una CA
  • *.key: Clau privada del certificat, sovint s’acostuma a protegir amb una clau simètrica
  • ca.crt: Certificat de la CA
  • ca.key: clau privada del certificat de la CA.

Senzill, oi? diria que ja no teniu excusa per gestionar-vos vosaltres mateixos les claus SSL. Si ús calen d’altres funcions al directori esmentat hi ha molts altres scripts i el propi ‘pkitool‘, té força altres opcions molt interessants i igual de simples d’usar.

openssl: canvi de clau privada d’un PKCS12

Reading time: 30 – 50 minutes

Pels que ús soni de res el PKCS12 la wikipedia és un bon lloc per coneixer de que va, una definició xapussera de què conté un PKCS12 seria:

  • Cert de la CA (Certificate Authority)
  • Cert del client
  • Clau privada del client

Això permet poder configurar ràpidament clients que han d’usar certificats ja que només tenim un fitxer que posar a la configuració.

A continuació enganxo un petit cookbook que explica com canviar o treure la clau simètrica que protegeix la clau privada del certificat client:

#extreiem private key d'un p12
openssl pkcs12 -in client.p12 -nocerts -out client_private_key.pem
#extreiem client certificate d'una p12
openssl pkcs12 -in client.p12 -clcerts -nokeys -out client_cert.pem
#extreiem CA d'una p12
openssl pkcs12 -in client.p12 -cacerts -nokeys -out ca_cert.pem
#treiem password d'una clau
openssl rsa -in client_private_key.pem -out client_private_key.nopass.pem
#canvi pass d'una clau
openssl rsa -in client_private_key.pem -des3 -out client_private_key.novaclau.pem
#creem una p12 a partir dels seus fitxers arrel
openssl pkcs12 -export -out client.nou.p12 -in client_cert.pem -inkey client_private_key.novaclau.pem -certfile ca_cert.pem -name "nova clau" -out client.nou.p12

Scroll to Top