Ajaxterm + Apache + SSL


Después de buscar y buscar llegue a un tutorial de como configurar Ajaxterm de forma segura utilizando el servidor Apache y el protocolo SSL. Ajaxterm es una aplicación escrita en Python que nos permite tener acceso remoto a una máquina a través de una terminal común a todos los sistemas GNU/Linux pero con la diferencia que es vía web, por eso mismo es necesario la utilización del protocolo SSL el que hace que la información viaje encripatada.

Ahora les voy a dejar los pasos que segui pero con algunos cambios para llegar a tener todo configurado siguiendo el tutorial que les mencione, espero les sirva como a mi.

Instalamos el servidor web Apache:

# apt-get install apache2

Habilitamos los modulos proxy para apache:

# a2enmod proxy_http
# a2enmod proxy

Instalamos SSL y creamos el certificado:

# apt-get install openssl # apt-get install ssl-cert
# mkdir /etc/apache2/ssl
# /usr/sbin/make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

Al configurarlo nos pedira el nombre de dominio entonces en vez de “localhost” como aparece colocaremos NuestroDominio con el que accederemos a nuestra máquina.

Habilitamos el ssl:

# a2enmod ssl

Instalamos ajaxterm y lo iniciamos:

# apt-get install ajaxterm
# /etc/init.d/ajaxterm start

Si nuestro puerto SSH no es el default (22) debemos cambiarlo para el servicio de ajaxterm haciendo:

# nano /etc/init.d/ajaxterm

SERVERPORT = 22

Creamos un nuevo archivo de host virtual, tener en cuenta que para mi ajaxterm utilice el puerto 8443 asi que dependiendo del que ustedes eligan tendran que cambiarlo en el archivo:

# nano /etc/apache2/sites-available/ajaxterm

************************************************************

Listen 8443

<VirtualHost *:80>
ServerAdmin webmaster@localhost

DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory “/usr/lib/cgi-bin”>
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access.log combined

Alias /doc/ “/usr/share/doc/”
<Directory “/usr/share/doc/”>
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>

</VirtualHost>

NameVirtualHost *:8443

<VirtualHost *:8443>
ServerName NuestroDominio
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem

# Suppresses the Via header
ProxyVia Off
# Do not flood the log
#CustomLog /var/log/apache2/access.log combined env=!dontlog
#SetEnvIf Request_URI “^/ajaxterm/u” dontlog

ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8022/
ProxyPassReverse / http://localhost:8022/
</VirtualHost>

************************************************************

Habilitamos el ajaxterm creado y reiniciamos los servicios:

# a2ensite ajaxterm
# /etc/init.d/apache2 restart
# /etc/init.d/ajaxterm restart

Ahora si hemos terminado y ya tenemos configurado ajaxterm con el protocolo https para poder acceder en forma remota y segura a nuestra máquina, podemos probarlo haciendo:

https://NuestroDominio:8443

o en forma local:

https://localhost:8443

Acá les dejo una captura de como deberían verlo:

Nota: Si en el momento en que reiniciamos el servidor apache nos sale el siguiente error:

“apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName”

la solución es editar el archivo httpd.conf:

#nano /etc/apache2/httpd.conf

agregandole la línea:

ServerName localhost

Anuncios

(In)Seguridad en el sistema de gestión de la facultad


Hace un tiempo había instalado en mi máquina el analizador de protocolos Wireshark para probarlo y ver como funcionaba ya que me gusta probar todo ese tipo de herramientas, después de un tiempo lo deje nomas, y quedo ahi instalado nomas. Pero ahora en este nuevo cuatrimestre en la facultad cursando la materia Redes de Información tenemos que utilizarlo para realizar distintas actividades. Y viendo algunas cosas me volvio a la mente algo que había leído hace rato sobre que era posible obtener el usuario y contraseña de un login en un sitio web donde no use cifrado SSL.

Y me acorde que el sistema de gestión de alumnos en internet guarani3w de la facultad no usa cifrado SSL asi que se me ocurrio probar el programa con éste sitio y como era de esperar luego de capturar algunos paquetes de mi interfaz de red mientras me logueba en el sitio aparecio lo que buscaba.

Acá les muestro la imagen, que como veran el paquete corresponde al protocolo HTTP y mas abajo podemos ver que dice Usuario y Clave:

escaneo_login

Así que por lo que tengo entendido cualquiera que se ponga a capturar paquetes en máquinas que comprender la red de la facultad puede obtener el usuario y clave de los que se loguean en el sitio para hacer diferentes consultas, inscripciones, etc.

No creen que debería implementarse el protocolo SSL para éste sitio, quizá es una boludes pero siendo una facultad donde se dicta Ingeniería en Sistemas a mi parecer esto no le da buena imagen que digamos. ¿Ustedes que piensan?

La crisis del SSL


Hace un tiempo lei una pequeña noticia en la que se hacia mención a que el protocolo SSL (Secure Socket Layer) utilizado en ciertos sitios web y sistemas para cifrar la información que estamos enviando a un cierto servidor estaba pasando por una especie de crisis donde se lo consideraba bastante vulnerable hasta tal punto que hace unos cuantos días se empezo a hablar del famoso ya SSLStrip presentado por Moxie Marlinspike en el Black Hat 2009.

Con esta herramienta como bien demostro su creador se puede hacer pasar un sitio seguro (nos damos cuenta cuando en la dirección del mismo dice HTTPS) como uno que no lo es, en rasgos generales lo que hace es interceptar peticiones https y devolver el mismo sitio pero en su versión http, haciendole pensar al usuario que está frente a un sitio seguro, y en realidad los datos ingresados estan siendo enviados sin cifrado, haciendo una analogía vendria a ser como un policia corrupto, precisamente no te esta protegiendo de los malos sino que te está entregando.

Ahora realmente sabemos que el protocolo SSL está en crisis de verdad y una de las soluciones que se proponen varios seria el cifrado de todas las conexiones http, pero por mas que todo sea cifrado utilizando SSLStrip se obtendrían los mismos resultados, así que de momento está todo muy nebuloso.

Asi que bueno, el post era simplemente para comentarles esto para los que no lo sabían y mientras tanto sigamos confiando un poco en el protocolo.

Para mas info les dejo estos links:

Mini-Post: SSL


Unos hackers a modo de demostración rompieron la seguridad del SSL (Secure Sockets Layer, Protocolo de Capa de Conexión Segura, usado en el protocolo https) a través de diversas técnicas ingeniosas y la potencia de 200 PlayStation 3, equivalentes a unos 8.000 ordenadores convencionales o unos 20.000 dólares en tiempo de procesamiento.

Leer más en Microsiervos