VirtualBox logo

VirtualBox 5.0.14

VirtualBox 5.0.14 es la última actualización a la fecha de hoy 22 de enero de 2016, nosotros usamos intensamente este entorno de virtualización tanto para servidores en producción como servidores en desarrollo. Esta última versión hoy la descargamos e instalamos sobre los servidores de desarrollo y dentro de unas dos semanas que hayamos probado su estabilidad y certeza de rapidez y eficiencia, será aplicado a los de producción.

VirtualBox - Acerca de.
VirtualBox – Acerca de.

A continuación la lista de cambios que igual podeís leer en la página web oficial de VirtualBox ¿Que para qué lo repetimos aquí? pues bueno le damos valor agregado a lo que consideramos importante (o digno de recalcar) y utilizamos el color verde en la fuente de letra para ello.


VirtualBox 5.0.14 (released 2016-01-19)

This is a maintenance release. The following items were fixed and/or added:

  • GUI: properly limit the number of VCPUs to the number of physical cores on Mac OS X (bug #15018)
  • Audio: fixed a bug which prevented loading a saved state of a saved guests with HDA emulation (5.0.12 regression; bug #14981)
  • Audio: don’t crash if the backend is unable to initialize (bug #14960)
  • Audio: fixed audio capture on Mac OS X (bug #14386)
  • Storage: fixed a possible crash when attaching the same ISO image multiple times to the same VM (bug #14951)
  • BIOS: properly report if two floppy drives are attached <— JE JE JE 😎
  • USB: fixed a problem with filters which would not capture the device under certain circumstances (5.0.10 regression; bug #15042)
  • ExtPack: black-list Extension Packs older than 4.3.30 due to incompatible changes not being properly handled in the past
  • Windows hosts: fixed a regression which caused robocopy to fail (bug #14958)
  • Linux hosts: properly create the /sbin/rcvboxdrv symbolic link (5.0.12 regression; bug #14989)
  • Mac OS X hosts: several fixes for USB on El Capitan (bug #14677)
  • Linux Additions: fixes for Linux 4.5 (bug #15032)

 

Trabajo, trabajo y más trabajo, lo único constante es el cambio.

VirtualBox 5.0.14

VirtualBox 5.0.14 instalando y compilando kernel con dkms.
VirtualBox 5.0.14 instalando y compilando kernel con dkms.

En la imagen arriba podeís obervar el proceso de actualización e instalación en Ubuntu 14.04 y en lo particular agradezco la deferencia de que revise si el grupo “vboxusers” está agregado al sistema GNU/Linux correspondiente (esto permite el acceso de los puertos USB, incluso 3.0, a las máquinas virtuales) y lo otro es la compilación in situ del kernel necesario, el que se adapta perfectamente al hardware donde uno tiene corriendo el sistema operativo. Todo esto permite eficiencia al máximo, el mejor aprovechamiento de recursos físicos “compilación personalizada” si le queremos dar un nombre. Si creeís que es una tontería esto último, leed la siguiente noticia sobre el futuro que se nos avecina, ahora les dicen “unikernels”.

Actualizando los paquetes de extensiones.

El proceso no estaría completo si no actualizamos los paquetes de extensión (bueno, en realidad utilizamos sólo uno, el de Oracle, pero allí está abierta la posibilidad si queréis usar el de un tercero e incluso desarrollar el vuestro ¡LIBERTAD!) en este caso la versión numérica coincide identicamente:

Descargando paquete de extensión 5.0.14 para VirtualBox
Descargando paquete de extensión 5.0.14 para VirtualBox
Descargado paquete de extensión 5.0.14 para VirtualBox
Descargado paquete de extensión 5.0.14 para VirtualBox
Advertencia antes de instalar paquete de extensión 5.0.14 para VirtualBox
Advertencia antes de instalar paquete de extensión 5.0.14 para VirtualBox
Instalado paquete de extensión 5.0.14 para VirtualBox
Instalado paquete de extensión 5.0.14 para VirtualBox

Casi olvidamos mencionar que, curiosamente, el paquete de extensión se actualiza AL EJECUTAR VIRTUALBOX y no por el repositorio de Ubuntu, que es lo normal además por todas las distribuciones Debian pero que la interfaz gráfica es bonita, ea, que nos gusta la línea de comandos pero esto de la interfaz gráfica cuela y mola en cantidad 😉 .

Actualización de software Ubuntu 14.04
Actualización de software Ubuntu 14.04

VBoxGuestAdditions.

Por último debemos actualizar en las máquinas virtuales el VBoxGuestAdditions el cual permite, por ejemplo, los gráficos 3D y los puertos USB, si a ver vamos, somo controladores “drivers” del entorno VirtualBox (recordar que los BIOS, NIC’s, etc son emulados) para descargar el archivo ISO deben ir a esta dirección web.

Aquí una copia del contenido remoto:

Index of http://download.virtualbox.org/virtualbox/5.0.14

      Name                                                                  Last modified      Size
      MD5SUMS                                                               19-Jan-2016 20:38  3.1K
      Oracle_VM_VirtualBox_Extension_Pack-5.0.14-105127.vbox-extpack        19-Jan-2016 17:55  17M
      Oracle_VM_VirtualBox_Extension_Pack-5.0.14.vbox-extpack               19-Jan-2016 17:55  17M
      SDKRef.pdf                                                            19-Jan-2016 18:14  2.4M
      SHA256SUMS                                                            19-Jan-2016 20:38  4.3K
      UserManual.pdf                                                        19-Jan-2016 17:43  3.4M
      VBoxGuestAdditions_5.0.14.iso                                         19-Jan-2016 17:46  57M
      VirtualBox-5.0-5.0.14_105127_el5-1.i386.rpm                           19-Jan-2016 18:48  81M
      VirtualBox-5.0-5.0.14_105127_el5-1.x86_64.rpm                         19-Jan-2016 18:48  82M
      VirtualBox-5.0-5.0.14_105127_el6-1.i686.rpm                           19-Jan-2016 18:48  73M
      VirtualBox-5.0-5.0.14_105127_el6-1.x86_64.rpm                         19-Jan-2016 19:18  73M
      VirtualBox-5.0-5.0.14_105127_el7-1.x86_64.rpm                         19-Jan-2016 20:04  68M
      VirtualBox-5.0-5.0.14_105127_fedora18-1.i686.rpm                      19-Jan-2016 20:04  68M
      VirtualBox-5.0-5.0.14_105127_fedora18-1.x86_64.rpm                    19-Jan-2016 20:22  68M
      VirtualBox-5.0-5.0.14_105127_fedora22-1.i686.rpm                      19-Jan-2016 20:04  68M
      VirtualBox-5.0-5.0.14_105127_fedora22-1.x86_64.rpm                    19-Jan-2016 20:04  68M
      VirtualBox-5.0-5.0.14_105127_openSUSE131-1.i586.rpm                   19-Jan-2016 20:04  62M
      VirtualBox-5.0-5.0.14_105127_openSUSE131-1.x86_64.rpm                 19-Jan-2016 20:04  62M
      VirtualBox-5.0-5.0.14_105127_openSUSE132-1.i586.rpm                   19-Jan-2016 20:04  62M
      VirtualBox-5.0-5.0.14_105127_openSUSE132-1.x86_64.rpm                 19-Jan-2016 20:04  62M
      VirtualBox-5.0-5.0.14_105127_sles11.0-1.i586.rpm                      19-Jan-2016 19:18  72M
      VirtualBox-5.0-5.0.14_105127_sles11.0-1.x86_64.rpm                    19-Jan-2016 19:18  72M
      VirtualBox-5.0.14-105127-Linux_amd64.run                              19-Jan-2016 18:00  81M
      VirtualBox-5.0.14-105127-Linux_x86.run                                19-Jan-2016 17:56  80M
      VirtualBox-5.0.14-105127-OSX.dmg                                      19-Jan-2016 18:04  87M
      VirtualBox-5.0.14-105127-SunOS.tar.gz                                 19-Jan-2016 17:57  94M
      VirtualBox-5.0.14-105127-Win.exe                                      19-Jan-2016 18:10  112M
      VirtualBox-5.0.14.tar.bz2                                             19-Jan-2016 17:58  106M
      VirtualBoxSDK-5.0.14-105127.zip                                       19-Jan-2016 18:02  9.2M
      virtualbox-5.0_5.0.14-105127~Debian~jessie_amd64.deb                  19-Jan-2016 19:04  62M
      virtualbox-5.0_5.0.14-105127~Debian~jessie_i386.deb                   19-Jan-2016 18:57  62M
      virtualbox-5.0_5.0.14-105127~Debian~squeeze_amd64.deb                 19-Jan-2016 18:26  67M
      virtualbox-5.0_5.0.14-105127~Debian~squeeze_i386.deb                  19-Jan-2016 18:09  67M
      virtualbox-5.0_5.0.14-105127~Debian~wheezy_amd64.deb                  19-Jan-2016 20:33  61M
      virtualbox-5.0_5.0.14-105127~Debian~wheezy_i386.deb                   19-Jan-2016 20:25  62M
      virtualbox-5.0_5.0.14-105127~Ubuntu~precise_amd64.deb                 19-Jan-2016 20:16  61M
      virtualbox-5.0_5.0.14-105127~Ubuntu~precise_i386.deb                  19-Jan-2016 20:09  62M
      virtualbox-5.0_5.0.14-105127~Ubuntu~trusty_amd64.deb                  19-Jan-2016 18:48  61M
      virtualbox-5.0_5.0.14-105127~Ubuntu~trusty_i386.deb                   19-Jan-2016 18:41  61M
      virtualbox-5.0_5.0.14-105127~Ubuntu~wily_amd64.deb                    19-Jan-2016 18:33  62M
      virtualbox-5.0_5.0.14-105127~Ubuntu~wily_i386.deb                     19-Jan-2016 18:26  62M
download.virtualbox.org

Actualizado el sábado 05 de marzo de 2016.

Es muy bienvenida la versión 5.0.16 y compiló los módulos del kernel sin problemas:

VirtualBox kernel modules 5.0.16
VirtualBox kernel modules 5.0.16

<Eso es todo, por ahora>.

ssh-keygen

SSH keygen.

SSH keygen.

Con SSH podremos conectarnos de manera segura a nuestras máquinas remotas y ejecutar o automatizar tareas con la certeza de que nadie podrá indagar qué estamos haciendo, privacidad absoluta.

En un post anterior vimos y aprendimos nuestros primeros pasos para trabajar por línea de comandos (shell) en una ventana terminal. Si no lo recordaís o quereís refrescar la memoria pues visitadlo y regresa acá para continuar nuestro aprendizaje (que yo también escribo esto para que no se me olvide -y ayudo a otros también-).


ssh-keygen
ssh-keygen

Pues el tema que nos trae hoy consta de dos publicaciones de la cual ésta es la primera. Ya sabemos cómo manejar la terminal por atajos de teclado para listar, copiar archivos, renombrarlos, etc. Todo esto lo hacíamos así, directamente sentados en nuestro ordenador, en contacto físico con nuestro equipo. ¿Pero que tal si nosotros necesitamos conectarnos a alguno de los ordenadores de nuestro trabajo? ¿O si estamos de viaje conectarnos a nuestra computadora en casa?

Apartando el tema que necesitamos conocer la dirección IP que nos asigna nuestro proveedor de internet para conectarnos (eso ya será tema para una nueva publicación) en el mundo Linux hay software antiquísimo diseñado especialmente para esto. En un  principio nos ocasionará temor el dejar nuestros equipos así, abiertos al mundo y con tanto “hacker” suelto por allí, que ni siquiera el mayor imperio conocido en la historia de la humanidad ha podido capturar a Edward Snowden o a Julian Assange, ¿qué quedará para nosotros? Al final de estas líneas os mostraremos al menos una herramienta para ayudar a protegernos de accesos no autorizados.

La buena noticia -y que tal vez los tranquilize un poco- es que estos dos señores (y muchos más) utilizan lo que nosotros aprenderemos aquí. Se dice rápido y fácil pero detrás de esto mucha gente se devanó los sesos pensando fórmulas matemáticas, estadística y algoritmos para garantizar nuestro acceso a ordenadores remotos. Sin más preámbulos pasemos a describir dicha tecnología.

SSH “Secure SHell”

En informática el acrónimo de 3 letras SSH (“Secure SHell”) describe la conexión segura entre dos computadores por medio de un canal seguro basado en un protocolo de red que nos permite manejar una línea de comandos como si estuviéramos de cuerpo presente frente al ordenador. La definición en inglés es cortísima, pero bueno cosas de ese idioma, todo es corto y rápido, “como para ayer pues”. Una cosa que yo admiro, eso sí, de esa gente es LA PRACTICIDAD. Estas conexiones nos permiten administrar múltiples equipos, pero el asunto va mucho más allá. Yo me esfuerzo todos los días para llegar a ser un Administrador de sistemas perezoso y ser así algún día UN BUEN ADMINISTRADOR DE SISTEMAS. Podemos crear archivos de procesos por lotes escritos en formato .sh (bin bash) y que nuestra máquina local ejecute cada cierto tiempo prefijado con CRON pero lo aplique a una máquina remota (la idea es poder introducir variables de búsqueda o parámetros a programas desde nuestro equipo local y aplicarlo en la máquina remota).

Para ello debemos nosotros mismos introducir la contraseña de la máquina remota y hasta allí llega nuestro entusiasmo para automatizar tareas. Pero para ello inventaron el ssh-keygen, un algoritmo que nos permitirá conectar automáticamente “sin contraseña” pero con una seguridad muy robusta y comprobada millones de veces diariamente.

Vuelvo y repito, detrás de todo esto hay mucha ciencia y esfuerzo, lo que les describo es una simplificación para aprender el concepto que luego pueden ampliarlo con los variados enlaces que incluyo y que utilicé para escribir esta entrada en mi blog.

Cinco pasos para crear “login sin contraseña”.

Tanto como “sin contraseña” no es el asunto, realmente tendremos que colocar una sola vez nuestra contraseña para poder acceder a nuestra página remota. Luego son cinco los pasos necesarios para crear nuestras conexiones “sin contraseñas” o como dicen en inglés “SSH Passwordless Login Using SSH Keygen in 5 Easy Steps“. Dichos pasos, panorama general, son los siguientes:

  1. En nuestra computadora local generaremos una llave digital.
  2. Luego crearemos un directorio en la máquina remota donde reposará dicha llave digital.
  3. Acto seguido copiaremos la llave en sí (local->remota).
  4. Asignaremos en la máquina remota permisos de lectura a dicha llave.
  5. Nos conectaremos como prueba de que la llave funciona.

Fue más fácil decirlo que hacerlo, como siempre. Ahora paso a describirlo con un ejemplo, en mi caso tengo una computadora real corriendo Ubuntu 14 de 64 bits (máquina local llamada “KEVIN” cuya dirección IP local es 192.168.1.47) corriendo un software llamado VirtualBox que me permite correr máquinas con diferentes sistemas operativos, para nuestras pruebas nos vienen como anillo al dedo pues ahorramos en hardware y en tiempo. La máquina virtual que utilizaré tiene corriendo Debian 7 “wheezy” la cual será la máquina remota, su nombre es “postgresql” y su dirección ip de área local es, para este ejemplo, 192.168.1.27 (una máquina virtual con motor de base de datos que utilizo para pruebas de programación).

Instalando SSH en la máquina remota (Debian).

Debido a la sencillez de este paso no se los había mencionado pero es que tampoco podemos obviarlo porque es crucial para aplicar los 5 pasos que nos fijamos como meta. Por seguridad (pienso yo) el SSH no viene instalado de manera prefijada en las distribuciones Linux. Pensemos esto como que si no existe una puerta nunca podremos entrar. Lo que vamos a hacer ni siquiera es abrir una puerta, lo que vamos a realizar es romper la pared y empotrar nuestra puerta.

Es así que PRIMERO debemos estar sentados en la que será la máquina remota (-si se pierden retrocedan un párrafo y se ubican-) y abrir una ventana terminal y ejecutar la siguiente sentencia:

apt-get install ssh

Debemos estar conectados como superusuario, en esta oportunidad utilicé el comando su introduje mi contraseña de usuario y ordené la instalación del software necesario para hacer la conexión (recordar que la máquina remota ejecuta Debian).

Instalando SSH.
Instalando SSH.

Como ya estaba instalado me reporta que no fue instalado ni modifcado nada y nos recuerda que hay 2 actualizaciones por realizar (de nuevo esta parte da material para otra entrada aparte en mi blog). Ya con esto establecido pordemos continuar ahora sí con los cinco pasos siguientes.

Bono adicional: instalando SSH en Ubuntu.

Pues eso, tengo una máquina virtual para probar Ubuntu de 64 bits con la versión 16.04 Xenial Xerus [Ubuntu da nombres rimbombantes a sus distros (abrid este enlace si queréis saber su significado en inglés), pero ¿quienes somos nosotros para criticarlos? Hagamos nuestra propia distro para ponerle un nombre que nos guste, ja ja ja 😉 ].

En dicha máquina virtual abrimos una ventana terminal con CTRL+T (recordad de nuevo que es Ubuntu) e introducimos el correspondiente comando:

apt-get install ssh (1)
apt-get install ssh (1)
apt-get install ssh (2)
apt-get install ssh (2)

En este ejemplo si que vemos cómo se instala completo, y notad la generación de certificados digitales mínimos necesarios para funcionar. También, en la figura 2, veréis como la última liínea se generan disparadores para ufw, el firewall que utiliza Ubuntu, al final ampliaremos esto. Luego de realizado esto podemos probar la conexión y revisar si conecta correctamente:

ssh jimmy@192.168.1.130
ssh jimmy@192.168.1.130

Paso N° 1: creación de llave digital.

Tal vez esta sea la sección más llamativa del asunto. Necesitamos crear una llave digital que consiste en un montón de caracteres organizados según un algoritmo que hace esta llave única. Incluso tiene opciones para hacerl más segura aún, pero les dejo eso como tarea y se entusiasmen tanto como yo. Dicho esto usaremos la opción “simple”, sentados en la máquina local abrimos una ventana de terminal y tecleamos lo siguiente:

ssh-keygen -t rsa
Generando llave SSH.
Generando llave SSH.

Luego presionamos la tecla intro (enter) cuatro veces, osea, empleamos los valores que trae por defecto el programa generador de llaves. Aquí debemos notar dónde guarda la llave que acabamos de generar: en nuestra carpeta personal dentro de un directorio oculto llamado ssh, en nuestro ejemplo es “/home/jimmy/.ssh/”. Sabiendo esto nos vamos al siguiente paso.

Paso N° 2: directorio remoto para guardar llave.

Para copiar nuestra nueva llave digital en nuestra máquina remota necesitaremos introducir los siguientes comandos desde la máquina local:

ssh jimmy@192.168.1.27 mkdir -p .ssh

Como ven aquí ya comenzamos a correr comandos en la máquina remota (llamada “postgresql” y cuya dirección ip es “192.168.1.27”). Para ser más exactos ordenamos pro medio del comando mkdir crear un directorio oculto (observar el punto delante) y con la opción -p le decimos que obvie error si ya existe el directorio. Con esa opción la línea de comandos no devolverá respuesta alguna si todo va bien, el estoicismo de Linux es heredado del Unix. Ya habrán podido notar que la sintaxis del ssh consiste a dónde se va a conectar y si le colocamos algún otro comando seguido pues simplemente ejecuta ese comando en la máquina remota y “se desconecta”.

Si sólamente colocamos “ssh usuario@máquina” (y por supuesto introducimos nuestra contraseña  de usuario de la máquina remota) quedará la ventana terminal abierta para teclear los comandos que necesitemos, eso sí, cambiando el prompt o indicador (para nuestro ejemplo “jimmy@posgresql:~$“) para que sepamos dónde estamos ubicados.

Paso N° 3: copiando la llave a la máquina remota.

En el paso N° 1 anotamos dónde se guardó nuestra llave digital en nuestro ordenador local (opción por defecto, presionamos intro y escribir otra ruta). Ahora la copiaremos mediante:

cat .ssh/id_rsa.pub | ssh jimmy@192.168.1.27 'cat >> .ssh/authorized_keys'

De nuevo introducimos nuestra contraseña de  usuario en la máquina remota con la aclaratoria del uso del signo “tubería” | que se denota así, una barra vertical que indica pasar los resultados de un comando al otro. Vemos que usamos cat un comando que nos permite visualizar por pantalla el contenido de un archivo de texto (o cualquier otro archivo) sólo que con el uso del signo “tubería” lo que íbamos a ver por pantalla (contenido de la llave digital “id_rsa.pub”) se lo enviamos al comando ssh quien a su vez, como tiene un comando a su derecha, lo pasa al interprete de comando de la máquina remota. Aquí hagamos una pausa para asimilar el resto de la linea (3 comandos).

Así como el comando cat nos permite extraer y visualizar -por pantalla, por defecto-, también nos permite INTRODUCIR texto en un archivo con el uso de los dos signos “>>” pero cambiandole el nombre a “authorized_keys“; si el archivo existiera pues lo agregaría al final (que una máquina remota puede servir para conectarnos desde varias máquinas locales diferentes, cada una con su propia llave digital). De nuevo el estoicismo y sencillez de Linux se hace notar.

Paso 4: asignando permisos a la llave copiada.

Para que nosotros y sólo nosotros seamos los únicos que podamos usar esa llave digital en la máquina remota, debemos asignarnos permisos para nosotros, es decir, los otros usuarios registrados en esa máquina remota les cerramos la posibilidad de leer la llave que acabamos de copiar. De no hacer esto cualquier otro usuario registrado en esa máquina remota pudiera copiarla en un dispositivo e “instalarla” en otra computadora para tener acceso a dicha máquina remota con nuestras credenciales, suplantando nuestra identidad. Este esquema no lo he probado pero también se los dejo como tarea para que lo prueben y se den el gusto de escribirme diciendome que estoy equivocado en mis apreciaciones y conocimientos.

Para ello ejecutaremos el comando chmod a la derecha del comando ssh, ya conocemos bien la sintaxis:

ssh jimmy@192.168.1.27 "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"

Lo único nuevo aquí es el uso del punto y coma para separar un comando de otro dentro del conjunto delimitado por las comillas dobles. En la máquina remota se ejecutará tal cual, lee el primer comando de la izquierda hasta que encuentre el punto y coma, ejecuta y luego sigue leyendo hasta conseguir otro punto y coma (o se acabe la cadena con la comilla que sirve para delimitar).

Paso N° 5: comprobar que funciona.

ssh keygen
ssh keygen

El paso más sencillo: ejecutar la conexión y comprobar “que no nos pide contraseña”, tecleando en la terminal lo siguiente:


Actualizado el sábado 24 de octubre de 2015:

Si quisiéramos conectarnos como usuario raíz o “root” el procedimiento necesitaría unos comandos -y ediciones- adicionales. No obstante la comunidad Linux recomienda NO hacerlo por razones de seguridad, lo mejor es crear un usuario en el grupo de “sudoers”.


Fail2ban para fortalecer servidor.

En esta segunda parte de la entrada nos dedicaremos a estudiar el programa Fail2ban para proteger nuestro servidor SSH revisando periódicamente los registros de acceso a nuestro servidor en búsqueda de síntomas que indiquen un ataque. Cuando un ataque es detectado, que cumplan los parámetros establecidos, Fail2ban actualizará nuestro iptables para bloquear la dirección ip del atacante (o al menos la dirección ip que recibimos) por un período de tiempo o incluso permanentemente. Fail2ban incluso nos avisará por correo electrónico del suceso, si le instalamos algunos programas adicionales. Por último tampoco podemos perder de vista el Ubuntu Fire Wall (ufw).

Instalación de Fail2ban.

Primero debemos verificar si nuestro servidor está actualizado con los últimos parches de seguridad (línea N° 1), luego instalaremos el Fail2ban en sí (línea N° 2), el programa sendmail si queremos recibir correo con informes de sucesos (línea N° 3) y configuraremos el firewall (en este ejemplo de Ubuntu) en las líneas N° 4 y 5:

apt-get update && apt-get upgrade -y
apt-get install fail2ban
apt-get install sendmail
ufw enable
ufw allow ssh

Y las capturas de pantalla para que veaís el resultado de las líneas 2° a la 5°:

apt-get install fail2ban
apt-get install fail2ban

 

apt-get install sendmail
apt-get install sendmail

 

ufw enable & ufw allow ssh
ufw enable & ufw allow ssh

Al instalar sendmail el problema no es la descarga del programa, que es rápido, sino el tiempoq ue tarda instalándose ya que revisa todo el sistema para instalar certificados digitales para la seguridad TLS y muchos otros valores así que paciencia con esto.

Configurando fail2ban.local

Fail2ban, al inciarse en nuestro equipo remoto (que ya tenemos listo para conectarnos “sin contraseña”) primero lee todos los archivos con extensión .conf (que trae por defecto) y luego lee los archivos con extensión .local que están ubicados en la carpeta de sistema /etc/fail2ban. Nosotros podemos aprovechar este comportamiento para nuestro beneficio copiando el archivo fail2ban.conf a fail2ban.local y editar la copia, dejando intacto nuestro archivo original (por si acaso algo sale mal, borramos fail2ban.local y repetimos el proceso):

cp fail2ban.conf fail2.local
cp fail2ban.conf fail2.local

Ahora abrimos con el editor de texto favorito (nosotros usamos nano en este caso) para ajustar los valores necesarios:

nano fail2ban.local
nano fail2ban.local

Podéis hacer click en la imagen para ampliarla en otra pestaña (si su navegador lo permite). Los valores son los siguientes:

  • loglevel: nos permite habilitar el nivel de detalle que nos presentará fail2ban: eventos críticos (“CRITICAL”), de error (“ERROR”), de advertencia (“WARNING”), nota (“NOTICE”), informativo (“INFO”), depuración (“DEBUG”). Por defecto está en “INFO”, cambiad a vuestro gusto.
  • logtarget: nos permite decidir a donde vamos a guardar el informe de fail2ban, por defecto en el archivo /var/log/fail2ban.log . Las otras opciones son STDOUT, STDERR y SYSLOG, esta última puede ser útil si queremos manejar por mensajes del sistema.
  • syslogsocket: como dijimos en el apartado anterior, si seleccionamos SYSLOG para que fail2ba.log nos envie el infrome de sucesos, podemos configurar para que automáticamente utilice la vía por defecto o si queremos ubicarlo en una ruta distinta (se puede dar el caso).
  • socket: nos permite comunicarnos con el “demonio” que corre el servicio fail2ban. Dejamos intacto esta línea, de lo contrario no podremos pasarle órdenes. En el mundo del software libre todo es cristalino y transparente, esta línea es útil a la hora de depurar errores de programación del fail2ban.
  • pidfile: cada vez que se inicie, en este archivo se guardará el PID del servicio (Process Identification Number), esto es un identificador único a nivel del sistema oeprativo y sirve, por ejemplo, si necesitamos eliminar el proceso de la memoria.
  • dbfile: fail2ban utiliza SQLite, un manejador ligero de base de datos, para guardar sus procesos en disco duro de manera indexada, lo cual nos permite buscar rápidamente el historial de eventos, así se detenga fail2ban. Permite establecer el proceso en memoria para rapidez -pero se perderán los datos al apagar el equipo- o simplemente no indexaremos nada (tal vez si nos conformamos con los avisos por correo electrónico pero pensamos que siempre necesitaremos saber más, por eso recomendamos dejarlo en su valor por defecto /var/lib/fail2ban/fail2ban.sqlite3). De este archivo podemos sacar datos si usamos la línea de comandos SQLite3.
  • Si establecimos en el apartado anterior el uso del manejador ligero de base de datos, podemos establecer en esta línea el tiempo máximo (en segundos) que se deben conservar los registros. Recomendamos establecerlo a 7 días en vez de las 24 horas que trae por defecto.

Configurando fail2ban.jail

En este archivo fail2ban.jail haremos lo mismo que hicimos con fail2ban.conf.: copiaremos el contenido de fail2ban.jail a fail2.local para conservar el archivo original. Nota: los desarrolladores advierten que fail2ban.conf será cambiado en cualquier momento en que actualizemos a una nuevar versión. De antemano ya habíamos previsto utilizar los archivos .local y así nos lo especifican en una nota al comienzo del archivo.

Los valores que contiene son los siguientes (usamos de nuevo el editor nano con derechos de administrador):

  • En la sección [INCLUDES] la etiqueta before indica que se lean primero los archivos .conf (ya describimos este comportamiento).
  • En la sección [DEFAULT] la etiqueta ignoreip permite colocar las direcciones ip a las cuales no le aplicaremos regla alguna. Por defecto trae en formato CIDR a la dirección especial de equipo local 127.0.0.1/8 y si queremos o necesitamos podemos colocar direcciones ip específicas e incluso podemos bloquear servidores de nombres de dominio DNS. Debemos separar con un espacio los diferentes valores. Así podríamos, por ejemplo, especificar que no aplicase regla alguna a nuestros fallidos intentos de conexión SSH desde nuestra red de área local (generalmente 192.168.1.X) con la siguiente notación CIDR: 192.168.1.0/24 (una subnet y 255 direcciones ip).
  • maxretry y findtime: el primer parámetro indica cuántos intentos fallidos y en cuál período de tiempo han de haber sucedido para bloquear la dirección ip del atacante. Por defecto el número máximo de intentos son 5 en 600 segundos (10 minutos) o menos.
  • bantime: si cumple con el punto anterior, en este parámetro especificamos por cuánto tiempo bloquearemos la dirección ip del atacante. Por defecto serán 600 segundos sin atender llamada desde esa dirección ip involucrada.
  • usedns: esto lo explicaremos por la utilidad más notable, ver si la dirección ip es dinámica por medio del reverso del DNS. Al llegarnos un ataque podemos usar su dirección ip al DNS bajo la cual está bajo control a fin de determinar si es una dirección ip fija a un nombre de dominio o si es una dirección ip dinámica que cambia constantemente entre los clientes de un proveedor de internet (ISP). La segunda utilidad es poder marcar en un formato legible para nosotros los humanos en el archivo de registro de eventos. Por defecto viene marcada como advertencia.
  • logencoding: permite codificar el archivo de registro, viene marcado como “auto” y esto quiere decir que se utilizará lo que tenga asignado el sistema operativo, Posibles valores: ASCII, UTF-8 (este último formato es útil para nosotros los latino hablantes: castellano, francés, italiano, etcétera).
  • enable: por defecto es falso “false” y permite habilitar el archivo jail correspondiente.
  • filter: permite que el archivo “interactue” con otros mensajes del sistema, dándole el nombre propio del archivo para pasarlo como variable. No tocar esta línea para nada.

Hacemos una pausa para separar los valores destinados al envío de correos del sistema:

  • destemail: por defecto root@localhost será quien esté informado de lo que esté sucediendo.
  • sender: quien envia el correo, se repite el valor root@localhost, como vemos “yo con yo” no es útil así que en destemail colocaremos nuestra dirección de correo electrónico.

Fuentes consultadas.

Aquí les coloco los que visité y leí para poder escribir esta entrada “con sabor venezolano”:

En idioma castellano.

En idioma inglés.

En idioma francés.

Nuestro “tuiteo” acerca de este tema:



<Eso es todo, por ahora>.

Ubuntu 6 32 bits 27 junio 2007

Ubuntu 6.10 32 bits.

Ubuntu 6.10 32 bits.

Ubuntu 6.10 32 bits (año 2007 y reinstalado en 2015 por medio de una máquina VirtualBox): un CD que recuperé del baúl de los recuerdos el cual le hice una imagen ISO con Brasero (recuperado en un 99,9% a pesar de haber estado más de 48 horas leyendo y releyendo) y la utilidad de disco confirma los defectos en la imagen grabada. También tiene utilidad de comprobación de memoria RAM, la ejecuté también, todo está en el video.

Por allá en el 2004 tenía una computadora que compré ya armada y me vendieron una marca infame de tarjeta madre (yo recomiendo las marcas Foxconn, Asus y Gigabyte con los ojos cerrados) y dicha tarjeta madre dejó de reconocer disco duro alguno en el 2007, pero al menos si arrancaba desde CD (en aquella época era una novedad en Venezuela el DVD interno para computadora, el cual era el primero de mi propiedad y de paso era quemador también). Así que para no darle más vueltas a ese asunto descargué el Ubuntu y usaba el live CD y guardaba en memoria USB (pendrive). Esa computadora a la final la desarmé y vendí por partes pero como no hay mal que por bien no venga me introdujo a mi primera experiencia real con el Software Libre, submundo Linux.

<Eso es todo, por ahora>.

VirtualBox logo

VirtualBox puerto paralelo.

VirtualBox puerto paralelo.
VirtualBox puerto paralelo.

VirtualBox puerto paralelo.

Introducción.

Con VirtualBox podemos crear máquinas virtual con diferentes sistemas operativos lo cual nos permite experimentar con las nuevas versiones que publiquen los desarrolladores de software. Mejor aún, también nos permite utilizar sistemas operativos antiguos para ciertos programas “obsoletos” debido precisamente a esa evolución de los sistemas operativos; el caso que me ocupa en esta oportunidad es simplemente un software de 16 bits que ya no corre de manera alguna en 64 bits.

De manera predeterminada al crear una máquina virtual se incluyen los puertos seriales (para las impresoras fiscales del SENIAT, por ejemplo) y uno marca casillas de verificación de 1 ó 2 puertos seriales (hay visores de precios fiscal que NO conectan a la impresora fiscal, de allí el uso de dos puertos seriales).

La impresora que intento utilizar en una computadora moderna con procesador de 64 bits era utilizada para imprimir facturas con la Providencia N° 0591 SENIAT y ahora usamos para imprimir órdenes de movilización del depósito de mercancías hacia el área de despacho (la Providencia mencionada arriba quedó derogada con la Providencia Seniat N° 071 y 078 SENIAT donde obligan a utilizar impresoras fiscales con puerto serial para ventas masivas -y permite facturas sin nombre de contribuyente, sin derecho a crédito fiscal y también con RIF y razón fiscal, dos únicos datos exigidos, para tener derecho a crédito fiscal-).

VirtualBox puertos seriales

Reconocimiento a Alexander Eichner.

Importante mencionar que VirtualBox ofrece soporte a los puertos paralelos desde el año 2007 gracias al trabajo del sr. Alexander Eichner así que aquí el rendimos un justo reconocimiento a su labor.

Antecedentes históricos.

El cable que comunica a la impresora es tipo Centronics , muy popular desde 1970 hasta 2000, cuando las impresoras con conexión USB comenzaron a fabricarse de manera masiva. La lucha en cuanto a hardware se refiere para las impresoras es, si se quiere, leve comparado con la lucha que obligó a Richard Stallman a crear el software libre. Por supuesto que hoy en día existen cables adaptadores de USB a puerto paralelo pero ¿para qué gastar más dinero si estamos completos en hardware? Aquí muestro la configuración del BIOS para dicha máquina real (“anfitrón” en la jerga de VirtualBox):

PhoeniX BIOS CMOS
PhoeniX BIOS CMOS

La tarjeta madre tiene su puerto paralelo incorporado y al exterior (ojo hay otras tarjetas madres que sólo tienen el conector interno y uno debe comprar un cable conector hasta el exterior del case) ya lo que debemos es echar mano de nuestro ingenio para alcanzar el objetivo deseado.

Línea de comandos: la orden VBoxManage.

Revisando la documentación que acompaña a VirtualBox, un archivo pdf en inglés bastante largo por cierto, anuncian el uso avanzado con el comando VBoxManage que nos permite modificar nuestras máquinas virtuales que estén “apagadas”:

VboxManage modifyvm option lptmode y lpt
VBoxManage modifyvm (el resaltado es nuestro).

Así que ejecuto las siguientes órdenes (con mis valores correspondientes a la máquina real) que ejecuto sin problema alguno:

VBoxManage modifyvm WinXP --lptmode2 "/dev/parport0"
VBoxManage modifyvm WinXP --lpt1 0x378 7

Línea de comandos: la orden rmmod.

El problema ocurre al tratar de ejecutar dicha máquina virtual, esencialmente sucede que el puerto paralelo está ocupado por algún proceso y ésa es la pega del asunto.

Error puerto paralelo ocupado.
Error puerto paralelo ocupado.

Imaginaba yo que quien ocupa el puerto paralelo es algúna aplicación, nunca pensé que era el propio sistema operativo a nivel de kernel. Cuando yo comienzo a hablar de kernels -de cualquier cosa- me miran de arriba a abajo y me dicen que soy un pobre loquito pero investigando y sin dejar de rendirme consigo que el comando que desocupa el puerto paralelo es el siguiente -que debe ser ejecutado justo antes de lanzar la máquina virtual-:

sudo rmmod lp

El comando sudo nos permite ejecutar tareas de Administrador o raíz -root- ya que necesitamos a rmmod, un simple programa para remover un módulo del kernel de Linux (“Simple program to remove a module from the Linux Kernel”). Dicho comando rmmod ya el sr. Alexander Eichner bien lo especifica en su mensaje de lista de correo a los desarrolladores de VirtualBox . Cualquier avezado lector que quiera ayudarme a establecer de manera permanente, osea, en cada arranque, la remoción del módulo lp agradezco me comente por vía de mi cuenta Twitter, mientras tanto yo utilizo este simple proceso por lotes -script bash- antes de lanzar la máquina virtual:

#!/usr/bin/sh
sudo rmmod lp
VBoxManage startvm "WinXP"
exit

Actualizado el día domingo 03 de julio de 2016.

Leyendo los excelentes tutoriales que anuncian por la cuenta Twitter de Linode.com observo que se puede agregar al usuario al grupo de “sudoers” con la consabida brecha en la seguridad que significa elevarle los privilegios a un usuario. No recomiendo esto, pero bueno, el software libre nos permite hacer todo lo que necesitemos -o queramos-, vaya hasta ustedes el comando necesario (conectado como usuario raíz root y sustituyan usuario_ejemplo con el nombre real del usuario a añadir):

add user usuario_ejemplo adduser example_user sudo

La primera línea adiciona al usuario en sí, la segunda lo agrega al grupo sudo con derechos administrativos.


Fuentes consultadas:

Enlaces en idioma inglés:

<Eso es todo, por ahora>.

VirtualBox bajo GNU/Linux Canaima.

VirtualBox kernels Canaima Linux.

VirtualBox kernels Canaima 4.1 kukenan x86 (virtual).

ESTE PROBLEMA ME QUITABA EL SUEÑO, ya no más 😎 .

VirtualBox kernels Canaima: en la entrada anterior les indiqué cómo “instalar” una máquina virtual Canaima en una máquina REAL que corre Ubuntu+VirtualBox. Vayan a este enlace, refrescan la memoria y luego regresan.


“O inventamos o erramos”


 

Como pudieron observar en el video correspondiente, la máquina virtual quedó instalada y funcionando. Luego se me ocurre la pregunta ¿Puedo instalar VirtualBox en ésa máquina virtual Canaima que acabo de crear?

La respuesta es SI, si se puede,

pero es más fácil decirlo que hacerlo,

je je je. 😉

No voy a entrar en detalles profundos para instalar VirtualBox,  yo lo he instalado en diferentes sistemas operativos sin problema alguno pero en GNU/Linux Canaima hay que hacerle dos pasos adicionales a todo lo que explican MUY CLARAMENTE en la página de dicha empresa de software:

-> https://www.virtualbox.org/wiki/Linux_Downloads

En el manual en inglés (más detallado aún que la página web) explican este procedimiento como:

“It builds the VirtualBox kernel modules (vboxdrv, vboxnetflt and vboxnetadp) and installs them.

Ya bien lo aclara el manual, para que VirtualBox acceda a ciertos recursos REALES de la computadora debe estar sincronizado con la versión linux en que se ejecuta; IMAGINO con propósitos de “compilar” y tener una versión muy bien adecuada al sistema que uno posea.

Los comandos “truco” son:

apt-get install build-essential module-assistant
m-a prepare

(aunque he de confesarles que yo instalé varias paqueterías primero -que no recuerdo cuáles fueron- y hasta hice una actualización de software completa, de allí que al principio del vídeo aparezca el mensaje de poco espacio en disco)

Sin más, pues, les presento el video, ALOJAMIENTO CORTESÍA DE YOUTUBE:

Reconocimiento de autoría.

Debo reconocer que el script que me ayudó a instalar el VirtualBox en Canaima me lo suministraron dos personas con los cuales estoy sumamente agradecido:

  • Twitter: @abr4xas
  • Twitter: @cotoprixve

Espero yo retribuir conocimientos algún día (aunque CREO ya lo estoy haciendo con esta entrada a mi blog), y ya lo saben:



 

Duerman tranquilos, duerman contentos PERO PRIMERO COMPARTAN SUS CONOCIMIENTOS CON TODOS LOS QUE PUEDAN, es la razón de ser del Software Libre 😎 .



Actualizado el sábado 30 de enero de 2016:

   En Ubunlog.com, sitio web dedicado a reseñar “tutoriales, escritorios y software para Ubuntu” publica un problema parecido al que reportamos por acá, pero en este caso el contratiempo es la actualización del propio kernel del GNU/Linux que “choca” con el ya instalado VirtualBox. La propuesta es interesante y toman otra vía que merecemos reseñar en esta entrada para así compartir el conocimiento, bastión fundamental del Software Libre.

El autor es Miguel Pérez, ciudadno español y estudiante de Ingeniería Informática en la Universidad de las Islas Baleares, dicho artículo pueden visitarlo en este enlace web.


<Eso es todo, por ahora>.