viernes, 30 de noviembre de 2018

Los 10 mandamientos de un servidor | 7. No te olvidarás de migrar los datos

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
3. Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa
4. Los 10 mandamientos de un servidor | 4. Honrarás la configuración de tus servicios
5. Los 10 mandamientos de un servidor |5. Instalarás todos los programas necesarios
6. Los 10 mandamientos de un servidor | 6. No cometerás actos impuros con tus llaves SSH
7. Los 10 mandamientos de un servidor | 7. No te olvidarás de migrar los datos
****************************************************************************

Para este post tenía pensado comentarcómo se debería realizar la migración, que tras el mandamiento 6 se reduce todo en un tar y enviar el tar a los nuevos servidores para después descomprimir y ya. El post iba a tener esa dinámica, pero voy a aprovechar para ser muy faltón para que queden algunas ideas claras.


Esta tarea no es que sea muy complicada. Simplemente tienes que saber qué datos quieres/tienes que migrar, "comprimirlos" y pasarlos. No hay mucha complicación en esto.


Para mi caso voy a coger las carpetas save/ y data/ dentro de /applications/ProjectGID. Sencillo. No se puede complicar nada ¿verdad?


Antes he dicho hacer un "compress" porque si utilizamos el comando tar, tar es un contenedor, tar no comprime. Esto quiere decir que si yo hago un tar de un archivo de 2GB, nos quedará una archivo tar de 2GB. Eso sí, como todo buen contenedor/cesta, si yo meto una camiseta roja y miro dentro, tengo qu ever una camiseta roja, no amarilla.

He querido remarcar los permisos del archivo tar porque aquí hay mucha confusión. Tiene permisos de root y como vimos antes, las carpetas save y data tenían otros permisos y ownerships ¿Qué pasará?


Pues nada, conserva todos los permisos y ownerships. Pues bueno, aquí vienen los palos. Esto acaba de pasar porque yo estoy con un Debian. Parece lógico que un contenedor que por no hacer, ni te comprime, te cambie permisos, pero no siempre es así. Si, por ejemplo, utilizas un Red Hat, la situación es bien distinta porque aquí te cambia permisos y ownerships, y esto doesn't make sense.

Esto que pasa con Red Hat es una gilipollez, y cualquier empresa que utilice Red Hat como distro para sus servers demuestran ser monos masturbadores. Es algo que da mucho más trabajo.

Aunque los más avispados podréis decir: "Pero Manu, hay una trampa, al hacer el tar no has utilizado la opción -p para que conserve permisos y ownerships. Eres un fullero". Cierto, pero no olvidemos que con Debian sin esa opción -p los conservamos.

También podréis pensar que esto no es mucho problema (lo que ocurre con Red Hat) ya que simplemente en el servidor viejo hacemos un tar -cvzpf, los pasamos y sobreescribimos los datos, que al fin y al cabo son los mismos y se nos cambiarán ya de paso los permisos y ownerships. Vamos a testearlo en mi Debian.


Primero voy a recrear la situación en mi Debian. Cambio los permisos para que al pasar el tar con la opción -p (en mi caso da igual utilizar esa opción o no, ya que en Debian te los conserva) para así apreciar si se sobreescrimen los permisos y los ownerships.


Me paso el tar con rsync especificando que el protocolo sea ssh. Me gusta utilizar rsync cuando los archivos son muy pesados, y en grandes empresas, migrar datos como estos son bastante pesados, por lo que es una opción muy buena por su velocidad.


Pues sí, sobreescrime los permisos y ownerships...pero esto en Debian. Adivinad qué ocurre en Red Hat. Exacto ¡NO SOBREESCRIBE!

Este post más que para expxlicar cómo migrar datos es un post para dar puntos a favor de Debian. Por favor, no utilicéis Red Hat, no tiene sentido su forma de operar. Al final te da más trabajo porque toca eliminar esas carpetas y volver a pasarlas con la opción -p.

Foolish. Esa es la palabra que me sale para describir a las empresas que utilizan Red Hat. Debian es la madre de muchas distros. Es una distro consolidada, ante cualquier problema la capacidad de respuesta es bastante rápida. No tanto como la de CentOS, eso es verdad, pero en el sumatorio final Debian gana de calle, y más por cuestiones como las comentadas aquí. 

Como dijo Iniesta ¡Debian para todos!

¿Hackeamos el Mundo?

jueves, 29 de noviembre de 2018

Fucked en segundos

Mucha gente se cree que explotar vulnerabilidades hoy en día es muy complicado y que puede costar mucho o que se requiere de muchos conocimientos para hacerlo. Para romper este pensamiento les digo "¿Hackeamos a X en segundos?". La respuesta suele ser algo como "¿En serio?".



Yo tengo mis técnicas y mis trucos, como todo mago. Muchas veces tiro de Shodan porque es lo más rápido, y es que siempre te encuentras cosas interesantes si la query es interesante.



Et voilá. Con tan sólo buscar Windows, ya me salían Window Servers con vulnerabilidades en IIS como en el caso anterior. Además en Shodan me enumeraban los CVEs, por lo que yo ahora tan sólo tenía que irme a cve details o google hacking database para buscar exploits públicos y explotar esas vulnerabilidades.

Ah, obviemos que es un VPS que si lo atacamos con un Buffer Overflow pueda afectar a miles de clientes. Obviemos que si lo hackeamos podamos cambiar DNSs o las bases de datos. Obviemos todo eso que suena tan de película. Y por eso estamos expuestos.

¿Hackeamos el Mundo?

miércoles, 28 de noviembre de 2018

Los 10 mandamientos de un servidor | 6. No cometerás actos impuros con tus llaves SSH

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
3. Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa
4. Los 10 mandamientos de un servidor | 4. Honrarás la configuración de tus servicios
5. Los 10 mandamientos de un servidor |5. Instalarás todos los programas necesarios
6. Los 10 mandamientos de un servidor | 6. No cometerás actos impuros con tus llaves SSH
****************************************************************************

Ya llevamos más de la mitad de posts, ya casi terminamos. Hoy vamos a ser un poco traviesos. Hoy vamos a ver cómo cometer actos impuros con menores de edad, que eso no es pecado. Masturbarse sí, pero violar a menores de edad no. Todo el mundo lo sabe.




A ver, esto es muy importante hacerlo bien porque de lo contrario no podremos acceder a nuestro servidor. En grandes empresas, lo normal es que los sysadmin accedan a los servidores via ssh, por lo que, como he dicho, una correcta configuración es fundamental. Imaginad el problema si no introducimos correctamente la clave ssh de root. La que montamos es gorda.


Mucha atención al archivo de configuración de ssh (/etc/ssh/sshd_config). Aquí podemos definir cuántos intentos vamos a permitir. Es decir, en caso de introducir la password y fallar ¿Cuántas veces más lo vamos a dejar hasta cerrar la conexión? Así evitamos ataques como los de fuerza bruta.

También sería importante especificar dónde se encontrarán los archivos con las llaves ssh de cada usuario. Esto puede ser interesante en caso de tirar de seguridad por oscuridad. Configurando la política AuthorizedKeysFile configuramos esto mismo.

Otra cosa que podríamos tener en cuenta es utilizar un directorio específico para las llaves ssh para que así si migramos de servidores con frecuencia, migrar únicamente un directorio y no uno por cada usuario.

Por ejemplo, podríamos pasar todas las llaves SSH a un directorio como /SSH_keys_file/<user>/.ssh/authorized_keys y así en futuras migraciones haríamos un tar -cvzpf de /SSH_keys_file, por lo que reduciríamos mucho trabajo.


En cuanto a la migración es fácil. Un tar -cvzpf de los directorio que queramos y enviarlo por scp o por rsync. Yo, cuando son archivos grandes y pesados utilizo rsync. Algo como rsync -avzhe ssh --progress --remove-source-files <tar files>.tar.gz <user>@<remoteserver>:<path>. Especificaré un poco cada pción.

-e. Especifica el protocolo a utilizar. En mi caso ssh.
--progress. Para tener un verbose.
--remove-soruce-files. La misma opción lo indica. Esto eliminará el tar en el origen una vez que se haya enviado. Muy útil para no saturar la máquina con archivos que no sean necesarios una vez pasados.



Una vez pasado y descomprimido, si tratamos de realizar la conexión, veremos que ya no pide password porque autentica con la clave pública y privada.

Haciendo esto ya tenemos gran parte de la migración hecha, ya lo que nos queda son cosas más "sencillas", pues si esta conexión funciona correctamente tenemos mucho hecho. Lo peor es que hubiese algún problema en la conexión ssh, por lo que si salvamos este error, tenemos gran parte hecha.

¿Hackeamos el Mundo?

martes, 27 de noviembre de 2018

Mi mala relación con Linkedin

No es que me lleve mal con Linkedin, es que si se me compara con otros de mis conocidos, mi dominio al utilizar Linkedin es penoso. Siempre llego tarde a todo lo que hay interesante en Linkedin, nunca veo las notificaciones, a lo mejor felicito a alguien por su nuevo puesto 1 año después. Un desastre.


Soy muy malo utilizando Linkedin. Siempre estoy diciendo "Ah ¿pero esto se puede hacer?". No lo utilizo mucho y me he propuesto utilizarlo cada vez más, pero es que es demasiado para mi cabeza acostumbrada a la línea de comandos XD.

Esto lo digo para que se le quite esa falsa idea a mucha gente de que por el simple hecho de ser informático ya tengamos que saber cómo funciona cada web o cada dispositivo Informático existente en la faz de la Tierra.

Yo no sé utilizar Linkedin y otras muchas plataformas, y eso no quiere decir nada. Eso sí, si alguien me quiere hacer una Knowledge Transfer, yo no me quejo.

¿Hackeamos el Mundo?

lunes, 26 de noviembre de 2018

Los 10 mandamientos de un servidor |5. Instalarás todos los programas necesarios

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
3. Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa
4. Los 10 mandamientos de un servidor | 4. Honrarás la configuración de tus servicios
5. Los 10 mandamientos de un servidor |5. Instalarás todos los programas necesarios
****************************************************************************

Ya estamos a la mitad de esta serie de posts sobre los 10 mandamientos de un servidor.  Una de las cosas que nos quedan es instalar todos los programas que tengamos instalados en los servidores antiguos, por lo que sería conveniente pasar los programas de los servidores viejos a un txt y después comparar.


Obviamente lo primero que tendremos que hacer es loguearnos en los servidores antiguos y pasarlo a un txt el cual pasaremos a los nuevos servidores.


Y con el comando dpkg comprobamos cada paquete. Para no hacerlo uno por uno, podemos utilizar un script con un bucle for que compruebe el línea por línea el archivo de texto que hemos tenido que crear previamente.Una vez que veamos que están todos los programas, podremos pasar a la siguiente fase, pero eso ya será para otro post.

¿Hackeamos el Mundo?

domingo, 25 de noviembre de 2018

La vida en un dibujo

Esta es una teoría que le comento sobre todo a la gente que tengo más cerca. Es para la vida en general, pero yo la comento sobre todo cuando hablo de la vida laboral y hoy lo quiero compartir en el blog.



Me encanta dibujar. Eso es algo que los que están cerca mía saben muy bien. Mi pareja sobre todo, ya que últimamente estoy dibujando mucho más. Dibujar es de lo poco junto a la física que compite con la Informática por mi corazón.

Por esta razón hace unos años llegué a la conclusión de que la vida debía ser como un dibujo, y es lo que os quería comentar. Decir que es como cada uno debería tomarse su propia vida para ir mejorando poco a poco.


Primero tendríamos un boceto. Esto cuando hablo de la vida laboral me suelo referir a cuando estás empezando a trabajar. Esto es un trazo que no es el final pero que ya nos da una ligera idea de cómo va a ir el dibujo.

Por supuesto este boceto se puede ir borrando y mejorando. Y eso es precisamente la vida. Nuestro boceto que tenemos que ir retocando y mejorando poco a poco, paso a paso. Tenemos un ligero "trazo" con nuestras ideas, opiniones o personalidad que no tiene por qué ser con la que sigamos siempre, la podemos ir cambiando o modelando.

Cada retoque no tiene que ser malo, es más, esto mejora el dibujo, por lo que no os preocupéis por "retocar vuestro dibujo" (vida). No tengáis ningún inconveniente porque alguien os corrija, es simplemente un trazo que hay que mejorar.


Poco a poco, con cada retoque, con cada borrado, con cada trazado nuevo; llegaremos a un punto en el que ya somos un poco mejores, por lo que podemos pasar al entintado (yo aquí lo he hecho con un boli bic porque lo tenía que hacer rápido para este post, pero no entintéis con bic por favor, utilizad pluma, rotuladores calibrados o acuarelas).

No hace falta añadir detalles antes, eso los vamos a añadir ahora al entintar. Pero esto sólo es porque ya sabemos bien por dónde queremos que vaya nuestro dibujo y estamos seguros de que hemos cogido una buena base. Estamos mejorando.Estamos evolucionando tras cada fallo que hemos dejado atrás.


Y vamos añadiendo más detalles. Pero ¡ojo! no añadimos detalles así sin más, no. Los detalles los vamos añadiendo porque entendemos lo que estamos dibujando. Como en la vida, sólo matizamos cuando entendemos el problema que tenemos delante. Es imposible que dibujemos detalles (maticemos) si no entendemos cómo funciona lo que tenemos delante. 

Si queremos dibujar un zapato, tenemos que entender cómo funciona un zapato y fijarnos muy muy bien en cada detalle y estar concentrados en el zapato. Como en el trabajo y en la vida en general.

Para este dibujo, me he ido a unos locales abandonados a tirar piedras a los cristales con una cámara al otro lado para entender bien cómo se rompe un cristal. Parece una tontería, pero esos detalles de entendimiento son los que marcan la diferencia. Siempre estás aprendiendo cuando dibujas. Siempre aprendes en la vida.

Y cuando parece que ya lo tienes todo ¡aquí podría darle un toque de esto...o de esto otro! Siempre hay más. Después colorear, sombrear.etc.

Y así debería ser nuestra vida diaria, un proceso de continua mejora donde entendemos nuestros errores y una vez que hemos entendido por qué hemos fallado, lo borramos para mejorar. Un proceso por el que entendemos el problema que tenemos, y una vez entendido, actuamos.

¿Hackeamos el Mundo?

sábado, 24 de noviembre de 2018

Los 10 mandamientos de un servidor | 4. Honrarás la configuración de tus servicios

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
3. Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa
4. Los 10 mandamientos de un servidor | 4. Honrarás la configuración de tus servicios
****************************************************************************

Ya hemos instalado nuestros principales servicios (ssh en mi caso para esta prueba en esta serie de posts), por lo que ahora nos tocará configurar nuestros servicios. Y sobre esto va a ir este post. Sobre configurar nuestros servicios en los nuevos servidores. En este caso ssh, pero podrían ser más (es más, de hecho siempre son más).


Por supuesto todo dependerá de cómo de seguros queramos estar. Tendremos que tocar mucho los archivos de configuración. Hay mucho testing, pero merece la pena.


Para el archivo de ssh (/etc/ssh/sshd_config) yo voy a indicar que como mucho se intente hacer login 3 veces para evitar ataques de fuerza bruta y además algo que nos será muy importante en los siguientes posts, definir el archivo que contendrá las llaves públicas para la conexión por ssh mediante un par de claves.

Cada servicio tiene su archivo de configuración, por lo que tendremos que ir uno por uno configurándolo. Por ejemplo, si tenéis un Apache, podéis echarle un ojo al post del Server me sabe a poco donde comento algunas configuraciones para Apache que son bastante top. Por los demás servicios, decir que cada archivo tiene sus opciones específicas y que deberemos conocerlas. En caso de no saberlo, siempre podemos echar un vistazo a su manual y listo.

¿Hackeamos el Mundo?

viernes, 23 de noviembre de 2018

Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
3. Los 10 mandamientos de un servidor | 3. Santificarás la arquitectura de tu empresa
****************************************************************************

Para este tercer post, vamos a ver algo que es practicamente lo más importante a la hora de hacer el migrado. La arquitectura de la empresa. Y es que sin esto, no podremos hacer nada.


Lógicamente, cuanto más grande sea la aplicación y la empresa, será "más difícil" establecer la misma arquitectura servidor en las nuevas máquinas. Pero más difícil porque nos llevará más tiempo, no por otra cosa.

Aquí las instrucciones dependerán de la aplicación, pero obviamente tendremos que entender muy bien la arquitectura actual y qué arquitectura quieren, porque pueden querer cambiar la arquitectura de los servidores. Esto muchas veces no se aclara del todo bien y después pasa lo que pasa. Así que formación y aportad toda la información necesaria, empresas.

Es muy importante que sepamos qué procesos suelen ser normales que estén en ejecución y cuáles no. Saber cuáles suelen dar fallo y el por qué del fallo. Todo eso lo tenemos que saber bien, y sino llevamos el suficiente tiempo en la aplicación para que, con la monitorización diaria, sepamos todo esto; se nos debe especificar si queremos hacer nuestro trabajo bien.

Porque esto es como construir una casa, yo no la puedo construir si no sé cuántas habitaciones quieres, de qué tamaño, si quieres que en una habitación corra más aire que en otras. Todo eso debo saberlo y debe estar especificado. Pero pocas veces ocurre esto, y esto es un problema y de la empresa, no del SysAdmin.

¿Hackeamos el Mundo?

jueves, 22 de noviembre de 2018

Pasión

Sin duda esta es la palabra que marca mi vida en todo lo que hago. La pasión. Sin pasión no haría lo que hago, de eso estoy seguro. Muchas horas delante del ordenador, investigando, pensando y tecleando no serían posibles sin pasión ni amor por lo que hago.


Simplemente por curiosidad estoy anotando las horas extras que hago cada día. El mes pasado, en octubre, hice 30 horas de más. Cada semana trabajo (oficialmente) 40 horas, por lo que en octubre hice casi una semana más de trabajo.

A parte de eso, cuando salgo, cuando voy en el metro, andando o hablando con amigos; siempre voy pensando en algo de seguridad, servidores o informática en general. Si pago con tarjeta, pienso en el mecanismo que lo hace funcionar y cómo se podría romper esa seguridad. Todo el día pensando en servidores y seguridad.

Igual me pasa con otros proyectos que nada tienen que ver con la tecnología y que estoy desarrollando. Es más, estoy terminando el comienzo de un proyecto por el que tengo mucha ilusión y que espero que os pueda comentar en breves. Antes de que termine el año tendréis un post donde os informe de este proyecto en el que estoy metido y que no tiene que ver con tecnología. Un proyecto que hace que le esté dedicando bastantes horas también y que está rivalizando seriamente con la informática para captar mi atención.

Como veis, soy una persona que, todo lo que hace, lo hace con amor y con pasión ya que es la única forma que entiendo de vivir. La vida yo la entiendo como trabajo diario, esfuerzo, sacrificio y pasión. Y punto.

Pasión para mí es eso de hacer algo que te tiene la cabeza ocupada todas las horas que estás despierto y parte de tus horas de sueño y que haces sin que te importe. Pasión es que se te pasen las horas volando y se te olvide comer. Alimentarte de tu trabajo y tu esfuerzo, eso es pasión para mí.

¿Hackeamos el Mundo?

miércoles, 21 de noviembre de 2018

Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano

****************************************************************************
1. Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas
2. Los 10 mandamientos de un servidor | 2. No tomarás los servicios instalados en vano
****************************************************************************

Ya en el anterior post vimos profundamente qué escenario teníamos y qué escenario nuevo queríamos e instalamos. Ahora lo que nos toca es simplemente ir mirando al servidor viejo y compararlo con el nuevo para ver qué le falta. As simple as that.



Este post es más sencillo ya que simplemente es obtener la lista de programas y servicios instalados en los servidores actuales y compararlos con los nuevos. Con los programas no me voy a detener mucho ya que es parte de otro post de esta serie. Aquí vamos a centrarnos solamente en los servicios.


Como ejemplo yo voy a mostrar solamente el caso del servicio ssh y de Telnet, pero esto dependerá de la arquitectura del servidor que os toque migrar.


Como somos informáticos y nos gusta automatizar tareas, vamos a hacerlo más rápido pasando a un archivo de texto todos los servicios que queramos comprobar.


Lo que vamos a hacer va a ser pasar ese archivo de texto al nuevo servidor de PROD. Yo lo voy a hacer con rsync, aunque este tipo de ficheros pequeños da igual que lo pasemos por scp. Eso sí, yo voy a especificar que lo pase de forma segura con ssh. Y ojito al detalle de que pida password de root del nuevo servidor. Esto es porque aún no tenemos las llaves SSH en el nuevo servidor, algo que haremos en un futuro post.

NOTA: El dpkg anterior lo que va a hacer va a ser pasar al archivo txt solamente el servicio telnet, para que lo pase todo necesitaremos el paréntesis con este comando

(dpkg --get-selections |grep ssh; dpkg --get-selections| grep telnet) > services.txt

NOTA 2: Para el archivo de texto, mejor que quitemos la palabra "install" ya que puede dar a error posteriormente.


Este es el script que he creado en el servidor nuevo de PROD. Como podéis observar es un script muy sencillo. Un bucle que corta por el carácter "-" y evita repeticiones y después tira del comando dpkg junto a grep para buscar si esos servicios existen.Muy sencillo.


Et voilá. Como veis esta es una tarea muy sencilla, y más si la automatizamos de esta forma. Esta es una prueba más de que, por muy grande que sea la aplicación y el entorno con el que trabajes, no hay excusa para migrar servidores y actualizarlos. Se puede, pues son cosas sencillas pero que, lógicamente, llevan su tiempo de trabajo. Esta es una de las intenciones de esta serie de posts, demostrar que es posible y fácil de realizar. Laborioso, pero que se puede hacer dedicándole tiempo y mimo.

¿Hackeamos el Mundo?

P.D: He dado hasta el script hecho ya. Creo que no hay excusas.

martes, 20 de noviembre de 2018

Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas

Cuando vamos a migrar un servidor porque vamos a actualizar la máquina y realizar importantes cambios, nos tenemos que hacer la idea que tendremos  mucho trabajo que hacer, sobre todo si hay muchos datos que migrar y la aplicación del proyecto es muy grande. No obstante, deberemos tener en cuenta una serie de "mandamientos" que son importantes a tener en cuenta durante nuestro trabajo de migrado de servidores. Aquí va el primer mandamiento. Amarás las nuevas máquinas sobre todas las cosas.



Sí, me he llamado a mí mismo San MaGnu. Me he autodenominado santo al ser un mártir por la Iglesia protestante Gnu/Linuxterana. Junto a San IGnucio de Richard Stallman, esta Iglesia (la buena de verdad) crece. Pero como esta serie de posts van sobre "religión", qué mejor que ponernos cerdis como Rick y Morty en un capítulo de la segunda temporada que trataba el tema de le Religión.



Antes de nada, voy a comentar brevemente qué escenario he montado, para que así sepáis qué voy a migrar. Decir que es un escenario de pruebas para esta serie de posts, por lo que no esperéis algo muy grande tampoco.


Voy a contar con 2 servidores, uno de PROD y otro de BACKUP. Como imaginaréis, el servidore principal es el de PROD, y es ahí donde ocurrirá "todo lo gordo". El servidor de BACKUP realizará la función de almacenar backup de los datos de PROD y estar ahí listo con todos los datos de PROD al día por si en cualquier momento falla PROD, que tengamos listo otro servidor que podamos tratar como "Fake temporal PROD" hasta que solventemos el problema que tengamos en el servidor.

Por supuesto que esto no es ideal, lo suyo sería tener más, ya que en el de BACKUP también podríamos testear cosas que no testearíamos en PROD, por lo que el escenario ideal sería tener un server más como mínimo para testear ahí y después pasar esas pruebas al de BACKUP con datos de backup de PROD para ver cómo funciona esos testeos en un servidor con y sin datos de PROD. Así pues, cuando estemos seguros de que todo funciona correctamente, pasaremos y aplicaremos esos cambios al main server.


Ahora vamos con los servers. Como os podéis fijar, BACKUP no está correctamente configurado, ya que en PROD tiene datos en /applications/ProjectGID/data que no tiene en su /applications/ProjectGID/data(Antes de empecéis a pensar mal, decir que ProjectGID no es un proyecto real de mi empresa, simplemente son las siglas de God is Dead).

Esto es algo que durante el monitoreo necesitaremos a tener en cuenta, ya que os adelanto que nuestro entorno girará alrededor de /applications/ProjectGID/{data,save}. El archivo interesante a copiar sería copyfiles, ya que será el script que meteremos en nuestro crontab para que, a una hora determinada, copie los reports bajo /data a la carpeta /save del servidor BACKUP. Primero cifrará con gpg ese archivo y posteriormente lo enviará.

¿Pero qué es ese reports.csv? Pues un ejemplo de un archivo donde tendremos los reports de los clientes, de ahí que sea interesante cifrarlo.


Podríamos tener más datos, es más, a poco que una aplicación de este tipo tenga 3 meses, la cantidad de datos sería ingente. Imaginad un banco los datos que puede recopilar en 3 meses con todos los clientes que tiene.

Tiene sentido que pasemos a save/ los datos al servidor de BACKUP, ya que ahí vamos a guardar las copias de seguridad de los reports que es lo importante ya que al fin y al cabo son los datos de los clientes, que es lo que nos debe preocupar.



Como he mencionado antes, otro aspecto importante es el crontab, y más para nuestro caso en el que vamos a enviar a las 12:15 de todos los días los reports. Por supuesto esto tiene que funcionar correctamente para tener los datos actualizados en el servidor. Esto no puede fallar. Pero claro, tenemos que pensar que al estar en una migración de servidores, este crontab es importante tenerlo también en el nuevo servidor de PROD.

Durante un migrado (o simplemente por hacer backup) podemos encontrar los crontan que creemos en /var/spool/cron/crontabs, por lo que sabiendo esto, podremos tenerlo en cuenta para migrarlo también y así no tener que crearlo de nuevo en los nuevos servidores. Live Hack muy útil.

Ah, casi se me olvidaba. Por si os lo preguntabais porque sois inocentes y aún no me conocéis, estoy con un Debian en ambos servidores. Ambos son Debian 8 y migraré al Debian 9 para estos posts.

Visto esto, ahora lo que nos queda es de lo que se trata este post, de instalar las nuevas máquinas. Yo voy a instalar solamente una, ya que la otra es seguir los mismos pasos. Es más, si estáis con máquinas virtuales podéis clonarlas y después cambiar la MAC y su nombre en /etc/hostname.


Seleccionaremos la Instalación típica, nada de interfaz gráfica, aquí vamos a pelo. Tras esto nos pedirá que seleccionemos el idioma, uso horario,etc. En esto no me detengo ya que es fácil. Lo que sí nos pedirá es introducir un usuario y aquí tendremos que tener en cuenta los usuarios que tengamos creados en nuestro server.



Introducimos un usuario cualquiera y pasamos a otro de los pasos importantes.




Aquí tendremos que decidir cómo queremos realizar la instalación. Yo recomiendo la de utilizar todo el disco y configurar LVM cifrado. Sobre esto de LVM nos detendremos en futuros posts.


Y vamos a separar también en distintas particiones /home, /var y /tmp.


Tras unos minutos instalando y cifrando LVM, nos pedirá qué software instalar. Como vamos a utilizar un servidor, yo no voy a instalarle ningún escritorio, pero sí el web server y SSH.


Una vez instalado ya nuestro nuevo Debian 9, lo que tendremos que hacer es instalar todo el software que tengamos en nuestro servidor antiguo. En mi caso me he cerciorado de tener:


  • rsync
  • tree
  • gpg

Ahora tendríamos que añadir los usuarios, y aquí tenemos varias opciones:

  • Si son pocos usuarios como mi es mi caso, podemos crearlos con el mismo ID de usuario (opción -u) y listo
  • Utilizar netgroups con un servidor intermedio de Red Hat o cualquier otra arquitectura de LDAP.

Y ahora ojo, que en los servidores actuales accedemos de PROD a BACKUP sin introducir ninguna password y eso es por una cuestión. Estoy utilizando un par de claves privada y pública para esto. Si queréis saber cómo hacer esto, os dejo este post donde lo explico, ahora no me voy a detener mucho en explicar de nuevo cómo se configura.

Y hasta aquí la parte de la instalación. Por supuesto queda otra máquina que es la de BACKUP, pero es seguir los mismos pasos al fin y al cabo y tener en cuenta que sería bueno separar en distintas particiones /home, /var y /tmp y tener LVM cifrado.

¿Hackeamos el Mundo?

lunes, 19 de noviembre de 2018

Los 10 mandamientos de un servidor

Hace unas semanas os comenté brevemente el cómo hacer un migrado de nuestros servidores. Como ya dije, actualmente está siendo ese mi trabajo, por lo que he considerado el elaborar una serie de posts sobre este tema para explicarlo más en profundidad. Así que tras este posts, veréis un post por cada "mandamiento".


Tendréis que dejarme un tiempo, porque la idea se me acaba de ocurrir y quiero preparar algo especial y más grande. Prepararé máquinas virtuales específicas para esta serie de posts. Tened en cuenta que esto puede llevar un tiempo, ya que primero tendré que crear dos máquinas con datos que recreen los servidores en su estado inicial y posteriormente otras 2 que representen las máquinas actuales.

Esto tiene su trabajo y requiere de bastante tiempo, por lo que paciencia, que tendréis ese post tan pronto como termine de prepararlo todo. Que no os extrañe si estos días veis algún post más "sencillo" y "básico", ya que será para hacer un poco de tiempo, pero valdrá la pena.

¿Hackeamos el Mundo?

domingo, 18 de noviembre de 2018

Querido amigo servidor

Esto que os voy a contar hoy sólo lo saben las personas más cercanas a mí, por lo que hasta cierto punto es abrirme con vosotros. Puede parecer una tontería pero es tal y como veo yo la informática, así que ahí voy, voy a abrirme más que la tumba de Franco.



Yo a los servidores los veo como amigos o hijos. Es totalmente cierto, pero me llego a encariñar con los servidores (sólo si son GNU/Linux).

Pero los veo como esos amigos a los que tienes que querer y cuidar sobre todas las cosas, preocuparte por ellos y buscar lo mejor para ellos. Ser atento con ellos. Es por eso que todo servidor que me toca configurar, le pillo cariño y no me lo puedo quitar de la cabeza y hace que esté siempre preocupado cual padre por sus hijos.

Cuando monitoreo un servidor, simplemente pienso que estoy revisando que no tenga ninguna herida cuando se cae en el parque. Es una obsesión por el bienestar del servidor que me toca configurar.

Es por eso también que creo que cuando veo a alguien que deja despreocupado su servidor y no lo configura debidamente (como la UCO) salte tanto. Es como si se estuviese desatendiendo y maltratando a un hijo.

Puede que sea una enfermedad, pero que me quede hasta tarde trabajando haciendo el migrado de los servidores de mi empresa, es por esto, porque tengo cariño por los servidores de mi empresa, y una vez que los estoy migrando, aunque ya haya sobrepasado mi horario por 1-2 horas, me quedo para entender mejor los procesos que hay dentro de cada servidor, cómo actúa y cómo debería comportarse y cómo poder solucionar un problema rápida para atender a "mi hijo" lo antes posible. Eso es amor.

¿Hackeamos el Mundo?

sábado, 17 de noviembre de 2018

Rompiendo el tiempo que no se debe romper

Diariamente tengo varias meetings donde tengo que dar el output de los proyectos en los que estoy metido. Y os digo la verdad, muchas veces me aburro porque hay alguna que otra meeting que se alarga y parece no terminar nunca y a lo mejor yo o no tengo que hablar o hablo poco. Hay alguna en la que sí hablo más, pero el caso que quería comentar es de ese tiempo que rompo y que está mal visto romper, que es el tiempo que no estoy hablando y que debo estar escuchando a la persona que está hablando.


Yo, lo siento mucho,  pero yo ante estas situaciones me aburro mucho. Entonces para poder escuchar tengo que hacer otra cosa que me haga prestar atención. En mi caso es dibujar. Dibujo mucho. Desde partes de cómics con personajes que yo mismo me invento, pasando por a mi pareja y terminando con algún personaje famoso y...lo digo susurrando, a algún miembro del equipo. Aquí un ejemplo.



A la izquierda Rosendo, una caricatura de Rosendo. Algunos títulos de canciones de fondo y el fucking logo de Leño. A la derecha Freddie Mercury y en medio una lista que me suelo hacer de "Tasks to do" con un dibujo de mi pareja.

Por lo general cuando termina la meeting yo dejo de dibujar, y ojo que me sirve porque hace que preste más atención aunque no quiera a la meeting. Es más, hay veces que digo "han dicho esto, atento que te toca" y me han respondido "pero si estás dibujando ¿cómo te has dado cuenta?".

Me encanta dibujar porque puedo o darle toques hiperrealistas a los personajes o deformarlos todo lo que quiera. Puedo hacerle narizón a Rosendo o dibujar tal y como es en la realidad mi pareja. Me da mucho juego, me hace fijarme en los detalles. Muchas veces no sabía cómo dibujar alguna parte del cuerpo de mi pareja y al verla, no he dejado de mirarla ahí. Algunas veces eran los ojos, otras veces las manos.

Y lo mismo con otros personajes, ya sean famosos, amigos o compañeros de oficina. Me hace fijarme más en ellos y tratar de conocerlos más, porque para dibujar, además de practicar, hay que conocer lo que dibujas y entenderlo, sino, fracaso absoluto.

¿Hackeamos el Mundo?

viernes, 16 de noviembre de 2018

Un monitorizado para controlarlos a todos

Alguna que otra vez ya he comentado por el blog lo importante que es monitorizar nuestros sistemas y servidores. Son muchas las cuestiones a tener en cuenta, yo siempre estoy aprendiendo sobre cómo monitorizar sistemas y servicios, pero si queréis tener un poco más de conocimiento o qué herramientas suelo utilizar yo, aquí os dejo una serie de posts donde comento cosillas de monitoreo de sistemas y servidores.




Como imagináis, esto es importante para tratar de predecir cuándo un fallo va a ocurrir. Por ejemplo, si sabemos que necesitamos unos archivos con las estadísticas de las ventas realizadas para que esos datos lleguen a la aplicación que utilice otro equipo de la empresa y esos archivos no llegan, ya sabemos que el equipo no va a poder ver esos datos, y ahí nos toca revisar y tratar de encontrar la root cause.

Los motivos pueden ser varios, desde que nuestra tienda online esté fallando, por lo que tendremos que revisar nuestro servidor web y configurarlo debiadamente como en "El server me sabe a poco".  Puede ser por un fallo en la Base de datos, puede que la base de datos esté llena, puede ser problema de espacio en el sistema de archivos, un fallo de conexión entre máquinas temporal que es lo que ha provocado ese fallo,etc. Pueden ser muchos fallos ¿Cómo encontrar la causa real?

Pues muchas veces es difícil, muy difícil, pero nos toca revisar los logs que tengamos (los logs son nuestros amigos fieles que nos lo cuentan todo) y tratar de ver los errores, entenderlos y llegar a una conclusión, y en función de esa conclusión tomar una decisión.

Of course que esto requiere de tiempo de análisis, esto no se hace en 2 minutos. Puede ser laborioso, pero estamos aquí para eso, además que la satisfacción de después es inmensa. Es un problema que has resuelto o que has evitado, porque esa es otra, si ves en tu Pandora FMS que el sistema que contiene la Base de datos al que debe llegar el csv está caido y el crontab de la máquina que lo envían lo va a hacer a las 23:00 y son las 22:30, pues simplemente puedes tratar de actuar en esa media hora o eliminar esa línea de forma temporal y en la máquina target, cambiar el script o programa que lo vaya a leer y decirle que lo lea una hora después.

Eso sí, esto depende del entorno, ya que ese movimiento puede provocar que si tenemos una estructura de árbol por el cuál ese archivo interactúe con 20 procesos, ojo, tenemos que tocar esos 20 procesos. Y esto es lo bello de nuestro trabajo.

¿Hackeamos el Mundo?

jueves, 15 de noviembre de 2018

Variable empty, null. Problemas

Me preocupa un poco esta situación. Llevo unos días en los que no sé sobre qué escribir. Tengo un post parado a la espera de la revisión de una persona, tengo algunas ideas para posts pero que no termino de ver cómo hacerlos.


También se junta que tengo poco tiempo libre y que no puedo pararme a elaborar un post largo a menos que tenga otros programados que me den un tiempo extra para elaborar esos posibles posts más complejos.

El caso es que me preocupa porque trato de pensar temas pero no sale nada. Es una variable con valor null. Puede que sea saturación y que en cuanto tenga un poco de tiempo libre consiga sacar algo más, pero no dejo de estar preocupado porque me encanta escribir en el blog y por mi TOC de tener que dejar todos los días un post en el blog.

No quiero pasar a elaborar un post a la semana o cuando pueda, ya que como he dicho, me encanta escribir en el blog, es mi cuaderno de notas, pero es cierto también que algo no funciona del todo bien y que no puedo sacar ideas. Espero que sea un "fallo de red" temporal.

¿Hackeamos el Mundo?

miércoles, 14 de noviembre de 2018

Una pensión con barra libre de Wifi

Los días 1,2 y 3 me hospedé en una pensión de Granada para alejarme de todo, descansar unos días y avanzar algunos proyectos que irán saliendo además de disfrutar de la ciudad y hacer yo rutas turísticas. La verdad es que desconecté bastante y disfruté. Me di cuenta de que necesitaba ese tiempo de descanso, pero siempre hay alguna pega. En este caso en la pensión en la que me hospedé. La habitación y la atención eran geniales, pero hubo algo que me hizo saltarme, el último día, mi ley de desconexión, la seguridad de la Wifi.


La última noche que pasé, me quedé en la habitación con algunos proyectos y preparando el concierto de Rosendo y de repente me pregunté ¿Cómo de segura será la wifi? Bendita pregunta la mía.


Encendí mi Kali Linux y tiré de nmap para ver rápidamente los puertos abiertos de la wifi. Al principio me sorprendió un poco que fuese una red tipo C, pero era una pensión y no tendrían muchos clientes, por lo que casi que lo entendí que no tuviese un rango de IPs mayor. Pero claro, vi ese telnet ahí tan solitario y que me decía "atácame, hazme fuerza bruta, tío bueno". Y claro, uno que no es de piedra entra en el juego.


Y es que el telnet tenía un leak por el que si introducías el usuario incorrecto, ni te dejaba escribir la contraseña para darte error de autenticación, no, te decía que ese no era el usuario. Si era el usuario, te dejaba escribir la contraseña. Esta tontería ya nos facilitaba un posible ataque de fuerza bruta, ya que el usuario ya lo teníamos. Curioso cuanto menos.


Aunque sin duda, lo peor de todo es que el panel de administración del router tuviese de credenciales 1234/1234. Ya estaba dentro. Y es que los routers de Masmovil suelen tener como default passwords algo como:

  • masmovil/masmovil
  • admin/admin
  • 1234/1234
  • user/user
  • avanzado/avanzado
Una vez dentro, ya podía hacer lo que quisiera, desde cambiar la password del router, cambiar DNS. Todo.


Podía habilitar samba y cargar ahí una shell para tener acceso mediante una sesión meterpreter.


Tener acceso al panel de administración del router cuando no deberías estar autorizado no es una buena idea. Es tan sencillo como cambiar el servidor DNS por uno malicioso y ya podremos atacar a una gran cantidad de gente. Imaginad toda la gente que, dentro de la wifi, trate de acceder a su banco, su Paypal y que compre por Internet. Imaginad esa gente accediendo a su correo y sin darse cuenta de que están siendo hackeados por culpa de un protocolo que no entienden y de una red wifi no lo suficientemente fortificada. Un gran problema.

¿Hackeamos el Mundo?
Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...