Nuestro servidor virtual CentOS es completamente funcional, faltan unos últimos ajustes y podremos decir que hemos ¿terminado?… Bueno, al menos completado la parte «básica»…
Ahora queda hacer el ajuste fino, los detalles: phpMyAdmin con sus funciones completas, analizaremos si lo actualizamos, crear una carpeta compartida, asegurar un poco más nuestro CentOS: con un usuario sudoer y deshabilitar la cuenta de root…
phpMyAdmin: liberando su poder
Así como está, phpMyAdmin, ya es bastante útil. Pero si queremos utilizar las capacidades que tiene para «recordar» información extra de nuestras bases de datos (relaciones, gráficos de su estructura y demases) debemos habilitar esas funciones…
Primero, vamos a crear la base y las tablas que necesita phpMyAdmin… Por suerte, nos proveen de un script SQL que se encarga de la tarea, lo copiaremos a la carpeta donde phpMyAdmin espera poder «subirlo» (si no quieren copiar y pegar, o tipear, pueden utilizar el Midnight Commander):
# cp /usr/share/phpMyAdmin/sql/create_tables.sql \ /var/lib/phpMyAdmin/upload/.
Accedemos al phpMyAdmin desde el navegador del anfitrión:
Si la opción «Importar» no está a la vista, cliqueamos sobre «Más»…
Y allí encontraremos la opción para «Importar» la base de datos de phpMyAdmin…
Indicamos que utilizaremos el archivo que copiamos previamente y lo seleccionamos….
Nos desplazamos al final de la página y «Continuamos»…
Luego de un instante, se nos dará el aviso que ha finalizado y volvemos a la «pantalla» principal de phpMyAdmin…
Al desplazarnos hacia abajo, observaremos que ha desaparecido la advertencia que nos indicaba que las funciones extendidas no están disponibles…
Si elegimos ahora una base de datos, por ejemplo phpMyAdmin, podremos acceder a las herramientas «extendidas» bajo el botón «Más»… Elegiremos el «Diseñador», para ver de qué se trata:
Y tenemos a nuestra disposición un «editor gráfico» de la base de datos…
Explorar la potencia de ésta y otras herramientas la dejaremos para otro artículo o la curiosidad del lector…
Actualizando phpMyAdmin (porqué no)
A algunos nos molesta un poco que alguna aplicación nos indique que hay una versión nueva… Algunos nos vemos tentados de actualizarla y luego nos damos cuenta que el proceso es más complejo (en CentOS, al menos) que «soportar» esa leyenda que nos recuerda que hay una nueva versión disponible…
«Si funciona, no lo toques» reza uno de los tantos «mandamientos» de «Sistemas», sin embargo, nuestra «ambición» a veces nos gana… Y ya que tenemos una máquina de pruebas, pues… ¿Por qué no experimentar?…
CentOS, según mi humilde experiencia y mirada, ya nos ha dado indicios que es una distribución «prolijamente» cuidada, que busca la estabilidad sobre la vanguardia.
Actualizar phpMyAdmin se puede, pero implicaría descargar el desarrollo desde su sitio y reemplazar al que provee EPEL… Y eso implicaría un trabajo extra que, para el objetivo de esta serie, lo excede…
Con esta simple «excusa» hago uso del derecho de dejarlo para un futuro, junto con una «exploración» de phpMyAdmin y sus bondades. Mis disculpas.
Compartir carpetas entre Anfitrión e Invitado
Unas de las cosas «bellas» que tiene VirtualBox es que compartir carpetas entre Anfitrión e Invitado es tan sencillo como seguir estos pasos… Por «comodidad» (y un poco de orden) he creado en el Anfitrión una carpeta intitulada «IntercambioVB» (original, ¿no?)…
Apretamos el botón «Configuración» o por el menú…
Vamos donde indica «Carpetas compartidas»
Buscamos la carpeta a compartir…
La seleccionamos…
Y marcamos:
- «Automontar«: provocará que la carpeta esté accesible cuando la Virtual Box se encienda sin que tengamos que hacer nada, y…
- «Hacer permanente«: si la máquina está corriendo, esta opción será visible y provocará que tras el reinicio, siga accesible. Sino será de acceso temporal hasta el cierre de la Virtual Box.
Y… ¿Dónde está?… Luego de un «reboot» la accederemos en:
# ll /media total 4 drwxrwx---. 1 root vboxsf 4096 may 19 19:53 sf_IntercambioVB # ll /media/sf_IntercambioVB/ total 1684368 -rwxrwx---. 1 root vboxsf 0 may 19 19:53 archivo.txt drwxrwx---. 1 root vboxsf 4096 may 19 19:53 carpeta
Dentro de la carpeta /media, habrá una nueva con el prefijo «sf_» y el nombre de la carpeta en el Anfitrión… Dentro de ella, el contenido listo para «intercambiar»…
Así de «simple»…
Crear un usuario y convertirlo en «sudoer»
Vamos a darle un poco de «seguridad» a nuestro servidor. Quizás lo comenté antes, una de las cosas que aprendí de Ubuntu es que no ser root obliga a pensarse dos veces las cosas.
Y si, escribir antes de cada instrucción «peligrosa» sudo a algunos le puede parecer una incomodidad… Pero vale la pena.
Para crear un usuario, escribimos:
# useradd -m administrador
El parámetro -m sirve para crear la carpeta «home» del usuario, ahora le asignaremos una clave:
# passwd administrador Cambiando la contraseña del usuario administrador. Nueva contraseña: Vuelva a escribir la nueva contraseña: passwd: todos los tokens de autenticación se actualizaron exitosamente.
Listo, nuestro usuario «administrador» (o el nombre que hayan elegido) está «casi» listo para utilizarlo.
«Casi» porque le debemos permitir ejecutar «sudo» y, como adicional, agregarlo a los que pueden conectarse por SSH.
NOTA: aquí puede haber algún tipo de objeciones dado que «formalmente» para editar el archivo «sudoers» debe utilizarse «visudo»… La explicación es sencilla: visudo hace algunos chequeos antes de guardar el archivo y, de haber algún error, lo informa. Honestamente, nunca tuve inconveniente alguno utilizando nano y prestando atención a lo que escribo allí, pero la aclaración es válida para evitar conflictos…
Editaremos el archivo /etc/sudoers y localizaremos la línea que reza…
# nano /etc/sudoers ... root ALL=(ALL) ALL ...
Y debajo de ella agregamos al usuario que acabamos de crear, en mi caso «administrador»:
... root ALL=(ALL) ALL administrador ALL=(ALL) ALL ...
Guardamos y salimos.
Ahora nos «deslogueamos» (o salimos si estamos por SSH, con un «exit») e ingresamos con el usuario creado. Probemos si podemos hacer algo con «sudo«…
$ tail /var/log/messages tail: no se puede abrir «/var/log/messages» para lectura: Permiso denegado
Al haber ingresado como «administrador» (el usuario que cree) no me permitirá hacer ciertas cosas, en el ejemplo, ver el final de /var/log/messages (cosa que no comprendo porqué los logs están vedados… ¿por si hay contraseñas «sin cifrar»? Supongo…)
Intentaremos con «sudo»…
$ sudo tail /var/log/messages We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for administrador: May 19 12:07:09 mercurio kernel: 00:00:00.009386 ... May 19 12:07:09 mercurio kernel: 00:00:00.009387 ... May 19 12:07:09 mercurio kernel: 00:00:00.014921 ... ...
Una leyenda nos «recuerda» que el Administrador de Sistemas nos remarcó que debemos respetar la privacidad de otros, pensemos antes de tipear (¡Ja! algo había adelantado) y que con un gran poder se tiene una gran responsabilidad (¿Eso es del Hombre Araña?) y ellos (¿quienes?) confían que hemos recibido ese «sermón»…
Ingresamos la clave del usuario y nos permite, ahora si, ver que dice al final del archivo en cuestión.
Hace un tiempo escribí una somera guía en la que explicaba cómo limitar el acceso vía SSH a Ubuntu. Aquí es un buen momento para aplicar esa medida de seguridad en CentOS. Sólo la parte respecto a SSH. Pueden implementar esos pasos para inhabilitar el acceso como root por «Secure SHell» (si, ssh, pero quería evitar escribir «ssh» a cada instante).
Si se equivocaran en el paso reciente, que menciono aquí arriba, pueden aún ingresar como root desde la consola de Virtual Box.
Antes de continuar, tenemos un paso más para nuestro nuevo usuario: agregarlo al grupo «vboxsf«. Éste es el grupo que controla las carpetas compartidas y si no lo agregamos, en un futuro, tendremos que volver aquí para agregarlo y poder continuar.
$ sudo usermod -aG vboxsf administrador
Listo… ahora si, en el próximo «lgoueo», nuestro nuevo usuario podrá acceder sin problemas a las carpetas compartidas…
Deshabilitando root
Ahora vamos por lo «pesado»…
¿Por qué querríamos evitar que root se loguée? Pues la respuesta es bien sencilla: ataque de fuerza bruta. Para cualquier «pichón» de hacker es sabido que el usuario root existe, entonces podría iniciar un ataque probando y probando secuencias de caracteres hasta que dé con la que coincide con la clave que utilizamos…
PERO, así de grande… ¿Qué pasaría si no «existe» loguin posible para el usuario root? Debería reforzar el ataque: intentando secuencias que coincidan con un potencial nombre de usuario Y, aparte, otra para la clave… Los cálculos estadísitcos los dejo a su cargo, pero es casi «imposible» (no sin la asistencia de ingeniería social)…
El paso es sencillo, editaremos /etc/passwd, y donde dice:
root:x:0:0:root:/root:/bin/bash
Por precaución, copiamos y pegamos la línea, comentando la original y editando la copia (por si acaso… descarto a estas alturas que utilizando vi o nano, han averiguado cómo copiar y pegar una línea)…
#root:x:0:0:root:/root:/bin/bash root:x:0:0:root:/root:/sbin/nologin
Guardamos, salimos, nos deslogueamos e intentamos entrar de nuevo:
$ ssh -p 28022 root@localhost root@localhost's password: Last login: Thu May 19 17:59:02 2016 This account is currently not available. Connection to localhost closed.
¡Zas! De lleno… ¡Fuera!…
¿Y por consola? Hagan el experimento…
NOTA: A partir de este momento todas las instrucciones «sensibles» deberemos anteponerle «sudo«…
Guardar el estado de la máquina
Si no se acuerdan cómo, aquí lo explico… Recuerden ponerle un nombre descriptivo, por ejemplo CentOS sin root…
En los capítulos siguientes veremos:
- Mejorando la interconexión y transporte de la Virtual Box: Conexiones de red en Virtual Box , Habilitar una segunda red, Configurando la seguna interfaz en Centos (Y a mano), Accediendo por el nombre de «host», Guardar estado, Transportar la Virtual Box
- Ejemplos de uso del servidor de pruebas: conectar otra máquina virtual al CentOS, armando una red, restaurar una DB de desarrollo, Activar un sitio de prueba, utilizando las carpetas compartidas, Otras actividades propuestas (Conclusión)
8 comentarios