2010/09/14
3 comentaris
Reading time: 7 – 11 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
Havia tingut l’oportunintat de veure funcionar aquest tipus de concentradors d’VPN en diverses ocasions però mai n’havia configurat cap. De fet, el model en concret del que us parlo el vaig descobrir a través de 
