Esto puede constituir un pequeño desastre para todos los servicios que tengo montados, ya que hay que copiar todos los datos al nuevo servidor, tirar el servicio antes para que los datos no cambien, y levantar los servicios en el nuevo, asegurándose de que todo funcione… vale, por ahí, ya sé que van a ser un par de horas… pero el DNS… con su propia caché y demás, eso sí puede ser un gran problema.

Por ese motivo me puse a buscar y, a modo de post-it, me lo dejo aquí escrito para futuro, y por si alguien lo necesita también. Básicamente es: cómo redirigir el tráfico de un servidor a otro, empleando iptables.

Redirigiendo…

Vale, estoy en el antiguo servidor, tengo email y web. Los puertos por los que llega la comunicación, todos TCP, y posibilidad de SSL, pero en eso no hay mayor problema. En esencia tengo que cuidarme de las peticiones a los puertos: 80 (http), 443 (https), 25 (smtp), 465 (ssmtp), 110 (pop3), 995 (pop3s), 143 (imap) y 993 (imaps).

Buscando, vi esta web sobre como redireccionar tráfico, por lo que, escribí:

echo 1 >/proc/sys/net/ipv4/ip_forward
export IP=XXX.XXX.XXX.XXX
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination $IP
iptables -t nat -A POSTROUTING -p tcp -d $IP --dport 80 -j MASQUERADE

NOTA: como es lógico, hay que cambiar XXX.XXX.XXX.XXX por la IP del servidor al que se quieren redireccionar las peticiones al puerto 80.

Lo que hacen estos comandos es:

1. Indica al kernel que puede hacer forward de los paquetes que pasen por su interfaz de red.
2. Indica al sistema que los paquetes entrantes al puerto 80 sean dirigidos a la $IP indicada.
3. Indica al sistema que los paquetes que deban de salir, se emascaren modificando su IP de origen por la propia.

Con esto conseguimos que la comunicación hacia el puerto 80 pase sin problemas al otro servidor. Lo único, es que se desvirtúan las estadísticas, ya que para el servidor web, todas las peticiones son del servidor que redirecciona las peticiones, pero si es un recurso temporal (como es mi caso), no tiene mucha o mayor importancia

¿Cómo funciona el enrutado?

Encontré también otra página donde se explica bastante bien (aunque algo esquemática) la forma en que funciona el enrutado de paquetes empleando iptables, el gráfico:

Como puede verse, el paquete pasa por la cadena de reglas PREROUTING al entrar, es procesado y, cuando se detecta que es para otra máquina, se pasa a FORWARD y después a POSTROUTING, donde se pueden agregar reglas de modificación antes de que el paquete sea entregado a su destino.

Recomiendo echar un vistazo al enlace dado para ampliar más sobre el tema.

Conclusiones

Nada es perfecto al 100%, por ejemplo, esto mismo lo probé con XMPP, y no funciona correctamente, ya que la comunicación de s2s del protocolo espera que los mensajes lleguen del dominio (e IP) al que se solicita información, mientras que, estos mensajes, en su mayoría, al estar direccionados al dominio, no es la misma IP. No obstante, como medida temporal y sobretodo para HTTP, el apaño lo da.

No obstante, la historia quiso que MySQL AB, la empresa que se creó para comercializar la idea de la base de datos rápida para webs, fuese finalmente adquirida por Sun Microsystems, para dar un supuesto impulso a su integración con el mundo de Java. A lo que respondió otro de los grandes del sector, finalmente, comprando a la propia Sun Microsystems.

En el momento en el que MySQL pasó a ser de Sun, comenzaron las tiranteces, de forma que, Monty, uno de los fundadores y responsable del desarrollo inicial de MySQL, que comentó que el nombre, precisamente, provenía de una de sus hijas (llamada My), hizo un fork, dándole el nombre de MariaDB (otra de sus hijas).

El caso es que, por ética profesional y propia, al final, he decidido abandonar definitivamente MySQL para usar única y exclusivamente MariaDB en lo que concierne a base de datos tipo MySQL… ya que, también hay otras como PostgreSQL que siguen siendo una muy buena opción a considerar, según el caso que se dé.

Migrando

Lo primero, veo que en la propia página de Monty dedicada a MariaDB, hay un configurador bastante bueno de elegir la distribución, la versión de MariaDB a instalar y el mirror más cercano. Con esto tenemos que la instalación en mi Debian Squeeze, por ejemplo, se basa en poner los repositorios correspondientes y hacer el apt-get install para mariadb-server-5.3 (por ejemplo).

Tanto si se instala de forma automática, como de forma manual, si tenemos corriendo un MySQL 5.1 (por ejemplo), el sistema se encarga de desinstalarlo, poner en su lugar MariaDB y ejecutar un script llamado mysql_upgrade (que en caso de la instalación desde apt-get install se realizará de forma automática).

El servidor se levanta de forma rápida y tenemos un MySQL completamente funcional con la base de datos instalada y funcionando. El corte casi que ni se nota.

No obstante, siempre es deseable tener una copia de seguridad por lo que pudiera pasar. Está el caso de éxito de SpamExperts que migraron cerca de 300 servidores en más o menos tres horas y sin complicaciones.

Las ramas de MariaDB

Actualmente hay disponibles tres ramas de MariaDB, la versión 5.1, la versión 5.2 y la versión 5.3.

• La versión 5.1 es una versión prácticamente igual que la versión 5.1 de MySQL, solo que con muchas correcciones de errores realizadas.
• La versión 5.2 es la siguiente evolución, que consta con muchas de las características que querrían haber introducido sus creadores en la versión anterior, pero no pudieron por falta de tiempo.
• La versión 5.3 es la actual, que integra muchas mejoras y cosas que en MySQL solo están en la versión comercial.

La versión 5.3, que es la última y la más avanzada, tiene cosas como:

• Optimizaciones en subconsultas, de siempre en SQL, el hecho de realizar subconsultas es algo que da un poco de miedo, porque, además de que puede ser lioso el hecho de construir una gran consulta con subconsultas dentro, tiene penalización en rendimiento. Pues bien, esta versión está optimizada para el uso de subconsultas de modo que, con respecto a MySQL (la versión normal) mejora el rendimiento sustancialmente.
• Interfaz NoSQL… bueno, realmente, sigue siendo SQL, pero permite redefinir y aumentar la base de datos de forma fácil en cada UPDATE e INSERT. Un ejemplo puede verse en esta página.
• Nuevos engines (realmente esto es de la 5.2), permite usar OQGRAPH, que es un engine preparado para el almacenamiento de elementos jerárquicos y grafos; y SphinxSE que integra un sistema de búsqueda de texto muy parecida al FTS de PostgreSQL enlazando con el servidor de Sphinx.
• Autenticación por plugins: permite tener autenticación vía PAM, LDAP, etc.

Conclusiones

MariaDB se mueve en un entorno ágil con mucha gente que lo mantiene desde su comunidad, y sobretodo, con el apoyo y liderazgo de quien comenzó en su día MySQL, por lo que, es más que posible que dentro de unos cuantos meses o años, se comience a escuchar hablar más de MariaDB que de MySQL. Además, migrar ahora es fácil, ya que las versiones 5.1 en ambos elementos son muy parecidos (son casi iguales), pero ya con la versión 5.5 de MySQL (han saltado de la 5.1 a la 5.5 directamente) y la 5.3 de MariaDB, cada vez se irán distanciando más.

Mi consejo: ¡actualiza ya!

Estimados, he decidido liberar la obra para que los interesados puedan disfrutarla de modo libre y distribuirla.

http://www.hackingetico.com

Espero que la disfruten, saludos.

Por lo que, tenemos ya a disposición de todo el mundo este increíble libro sobre seguridad y redes, de la mano de un autor que trabaja día a día en empresas de seguridad y sobre problemas de seguridad reales.

Lo que se trata en el libro, visto por capítulos es Cultura Hacker, Técnicas de búsqueda de información, Ingeniería social, Fuerza Bruta, Aplicaciones Web (XSS, Exploits, …), Inyección de SQL, Servidores Linux y Servidores Windows.

En esencia, son unas muy buenas lecciones sobre administración de sistemas, de cara a la seguridad y mantenerse alerta de por donde pueden venir los ataques más comunes. También tiene capítulos muy aconsejables para programadores, a nivel de codificación para evitar la creación de códigos maliciosos como exploits, o inyecciones de scripting o código SQL.

Debería de ser el libro de cabecera de todo administrador de redes y técnico en seguridad de todas las empresas TIC.

El sistema GNU/Linux, al igual que su inspiración Minix, y la raíz de estos sistemas, Unix, se basan en ficheros. Todo es un fichero. Por ello, la seguridad de acceso a este tipo de información es muy importante.

Usuarios y Grupos

Los sistemas *nix, se basan en una estructura basada en grupos y usuarios. Un usuario puede ser una persona que tiene acceso al sistema mediante una contraseña y usa una consola, o puede ser un programa, un sistema servidor o un concepto abstracto (por ejemplo cdrom) en el que se agrupan una serie de ficheros, ejecución de servicios o servidores, etc.

Los grupos son como los usuarios, es decir, pueden tener propiedad sobre un fichero. Esto se hace para limitar o facilitar el acceso a los ficheros a un grupo de usuarios. Cada usuario puede estar en uno o varios grupos, así como cada grupo puede tener uno o varios usuarios.

… ¿y como se enlaza todo esto?

Los permisos en los sistemas *nix se basan en tres partes. Cada fichero y directorio tiene permisos específicos para: usuario, grupo y otros. Esto quiere decir que, si el fichero pertenece a un usuario y a un grupo determinado, podemos limitar los permisos para este usuario en particular, para ese grupo y para los demás.

Al realizar ls -lh en la consola es cuando se ve esta información en consola:

-rwxr-xr-x     1 bombadil  users      2K 12 nov  2009 marubio.jpg
-rw-r--r--     1 bombadil  users     50B  2 nov  2009 marubio.txt
-rwxr-xr-x     1 bombadil  users      5K 12 nov  2009 marubio2.jpg

Como se puede ver, la primera columna de la izquierda, hay un guión inicial que indica si es directorio (d) o fichero (-), después, se indican tres letras por tipo de permisos, en este caso sería:

• rwx, para el usuario, se dan los permisos de lectura (r), escritura (w) y ejecución (x).
• r-x, para los usuarios que no sean bombadil y pertenezcan al grupo users, se dan los permisos de lectura (r) y ejecución (x).
• r-x, y para los usuarios que no sean bombadil, ni pertenezcan al grupo users, se le dan los permisos de lectura (r) y ejecución (x).

¿Qué es eso de ejecución?

Básicamente, los permisos varían si se trata de un fichero o de un directorio, ya que la lectura (r) indica que se pueda leer el fichero o ver los ficheros que hay dentro de un directorio, así la escritura (w) indica que se pueda cambiar un fichero o crear ficheros en un directorio.

El permiso más extraño, el de ejecución (x), en caso de un fichero indica que se pueda ejecutar. Es decir, si se trata de un shell script, un programa compilado, o un script de consola de tipo python, etc., que se pueda ejecutar directamente (sino habría que lanzarlo desde algún intérprete.

En el caso de un directorio, indica si se puede acceder al directorio o no. Es curioso porque es casi como el atributo de lectura, solo que si tienes lectura y no escritura, se permite listar el directorio, pero no acceder con el comando chdir (o cd).

Equivalencia numérica

Hay mucha gente que esto de rwx le sonará un poco a chino y pensará… los permisos de tipo rwxr-xr-x son los 755 de toda la vida

Pues sí, los permisos se pueden dar de forma numérica también, teniendo en cuenta de que son valores octales, se puede dar un valor desde 000 a 777, siendo el primer dígito para el usuario, el segundo para el grupo y el último para los otros. Por tanto:

0 -> ---
1 -> --x
2 -> -w-
3 -> -wx
4 -> r--
5 -> r-x
6 -> rw-
7 -> rwx

Permisos especiales

Además de todo esto, hay dos permisos especiales que tienen unas propiedades bastante curiosas. El primero de ellos es el superuser grant. Este permiso se puede otorgar a programas que se deban de ejecutar como superusuario, pero solo se pueda dar a binarios, los programas de tipo scripting no tienen esta propiedad, ya que, realmente, se ejecutan desde un intérprete que no tendrá este bit de permiso activo.

Como ejemplo, podemos ver el programa passwd. Este programa ejecutado desde consola necesita acceder a ficheros como shadow y passwd para poder cambiar la clave del usuario:

-rwsr-xr-x 1 root root 39K dic  6  2009 /usr/bin/passwd

El segundo permiso especial es el sticky. Este permiso se otorga en especial a los directorios. Cuando un directorio tiene este permiso, quiere decir que cualquier usuario podrá tener acceso al directorio y crear incluso ficheros, pero no podrá modificar y ver nada más que los que sean de su propiedad.

Este atributo es el que se suele usar para el directorio tmp de los sistemas *nix, de servidores multiusuario. Cuando un programa necesita volcar información en este directorio, con este atributo, nos aseguramos que ningún otro usuario puede modificar o ver esta información temporal:

drwxrwxrwt 5 root root 12K ago  5 18:32 /tmp

Conclusiones

Los sistemas *nix tienen sistemas de permisos y usuarios muy simples, comparados con los sistemas de permisos de sistemas con Windows. Esto no quiere decir que sean peores ni mejores, son simples, y por ello flexibles y potentes. Así mismo, en los sistemas GNU/Linux se han implementado unas políticas añadidas de seguridad que no solo permiten el acceso o no a un recurso, sino a nivel de aplicación, el uso de una forma u otra de ese recurso.

No obstante, y sinceramente, el uso llano de estos permisos suele ser suficiente para la mayoría de los casos, no necesitando ninguna capa más que afine el nivel de privilegios, cuyo uso suele ser más complejo.

El lenguaje Perl me llamó la atención, sobre el resto, porque había sido un lenguaje creado por Larry Wall, un administrador de sistemas… ¡en un mes!, supongo que lo que creó fue la parte más básica del sistema, pero al mismo tiempo la más importante, ya que, como él mismo comenta, Perl fue la simplificación del uso de herramientas como awk, sed, shell script y C.

En la mayoría de trabajos que he tenido, después de eso, cuando un administrador de sistemas desarrollaba algún proyecto, alguna aplicación o decía que programaba, lo hacía en Perl. No en vano, ha sido considerado por muchas distribuciones, empresas y comunidades, como el lenguaje de facto para las actividades típicas de administración de sistemas, entre las que se encuentran tareas tan vitales como: la instalación del sistema, asistentes de configuración, pasarelas intermedias (como amavis)…

Uno de los grandes miedos de la gente que programa en este lenguaje, es la mítica frase de que Perl es un lenguaje write-only, es decir, de los que se usan solo para escribir código que no hace falta mantener (o de usar y tirar), aunque proyectos grandes y la comunidad en sí manteniendo y ampliando el lenguaje, han demostrado que Perl es un gran lenguaje de programación en el que se pueden desarrollar grandes cosas y darles mantenimiento sin problema ni riesgo.

El libro que aconsejo para adentrarse en el mundo de Perl es el que escribió su creador, Larry Wall, aunque a partir de su tercera edición, que está acompañada de mucho más contenido aportado por autores como Tom Christiansen, uno de los primeros que se sumó al mundo y comunidad de Perl; y Jon Orwant, el editor de The Perl Journal, cuya publicación cesó hace ya algunos años.

El libro es algo extenso y asusta al primer vistazo, no en vano son 1070 páginas. Pero una vez se ha abierto y visto el índice, se entiende su extensión y deja de asustar. Realmente, el libro se parte en cinco apartados bien diferenciados:

• Introducción… bueno, esta la podemos leer a modo informativo, o podemos obviarla. Son unas 50 páginas.
• Los detalles desagradables… un título un poco extraño, pero se entiende, porque son los detalles del lenguaje en sí, lo que permite, lo que se puede hacer con él, la sintaxis, los elementos… todo. Es la parte más importante del libro, en mi parecer. Unas 350 páginas, más o menos.
• Perl como Tecnología, nos adentra en lo que hace el intérprete internamente, cómo se puede optimizar su uso, el depurador, los hilos, interfaz con C… sería la parte avanzada del lenguaje. Unas 150 páginas.
• La Cultura de Perl, es el uso de CPAN, el administrador de paquetes, prácticas comunes, seguridad, haciendo Perl portable entre plataformas, documentación, etc. Un poco de Perl en la comunidad y cómo compartir código en la forma en la que lo hacen muchos. Unas 100 páginas.
• Material de Referencia… como no podía faltar, toda la referencia de los paquetes básicos de las librerías que trae consigo Perl. Esta quizás es la parte más extensa del libro, pero la que más se puede emplear en el día a día, realmente.

Una lectura muy recomendable para todos aquellos que quieren adentrarse en la programación de Perl de una forma más íntima, conociendo la comunidad, cómo compartir código, cómo aprovechar el código que ya está disponible para Perl y las mejores prácticas de programación en este lenguaje.

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

Aquí os dejo el enlace: PostgreSQL: Instalación, Configuración y Trucos.

En este caso, voy a explicar como instalar y usar SQL Server vía ODBC desde cualquier aplicación en GNU/Linux, como pueden ser programas Java, Perl, PHP, Ruby…

En principio, vamos a tirar de apt-get para instalar algunos programas:

apt-get install tdsodbc unixodbc libct3 libltdl3 odbcinst1debian1

Lo siguiente es crear el fichero /etc/odbcinst.ini, que debe de contener lo siguiente:

[FreeTDS]
Description     = TDS driver (Sybase/MS SQL)
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsS.so
CPTimeout       =
CPReuse         =

Ahora, para cada base de datos a la que queramos conectarnos, habrá que agregar un bloque de este tipo en el fichero /etc/odbc.ini:

[contactos]
Driver      = FreeTDS
Server      = 192.168.1.5
Database    = contactos
TDS_Version = 8.0
Port        = 1433

El nombre de la conexión es el que se situa entre los corchetes, y el que se usará para referenciar a esa conexión.

Para comprobar, podemos ejecutar el comando isql con los siguientes parámetros:

isql contactos usuario clave

Con esto, desde interfaces como DBI (Perl y Ruby), podemos usar DSN del tipo DBI:ODBC:contactos para acceder a esta conexión, siempre pensando que el usuario y la clave debe de insertarse en el comando de conexión.