Aviso de seguridad del equipo debian DSA-1609-1.

Multiples vulnerablidades locales y remotas ha sido descubiertas en lighttpd, un servidor web rápido con mínimo consumo de m
emoria.

lighttpd 1.4.18 y posiblemente otras versiones anteriores a la 1.5.0 no calcula apropiadamente el tamaño de un array, lo cual podría permitir a atacantes remotos causar un DoS, a través de múltiples conexiones.
connections.c en lighttpd anterior a 1.4.16, acepta mas conexiones de las configuradas como máximo, lo cual permitiría a atacantes remotos causar un DoS, a través de multiples intentos de conexión.

En el anterior articulo de iptables. Especificamos unas ips de origen, a las cuales permitíamos el acceso por ssh y ftp. Ya vimos que esto no es siempre posible, debido a que la mayoría de las personas no tienen ip fija.

Mirar que bonito error me he encontrado en los logs:

ip_conntrack: table full, dropping packet.

He tenido problemas con un server estático y otro ha tenido que asumir su carga.
Al principio pensé que no podía con toda la carga este servidor, pero investigando mas a fondo, me he encontrado con esos errores en el log.

Éste será el primero de una serie de articulos relacionados con la seguridad en un servidor web. Pese a que está enfocado en un servidor web, se puede aplicar a otros servicios cambiando los puertos correspondientes.

El primer paso para securizar el servidor web, será implementar un firewall, para lo que utilizaremos el iptables.
A la hora de implementar un firewall, lo mas seguro es cortarlo todo y después permitir solo aquello que sea absolutamente necesario.
Con el fin de hacer nuestro script lo mas genérico posible, utilizaremos algunas variables al principio para especificar las ips que aparecerán:

Después de hacer un backup completo de todas las bases de datos de MySQL, un cliente me pidió la restauración de una sola tabla.
Vaya… y como saco yo una sola tabla dentro de un dump de varios gigas ?
Me puse a investigar y lo he logrado con el comando sed.
Con sed genero un dump nuevo solo con la tabla que quiero restaurar. La tabla la quiero restaurar no la quiero sobreescribir, por lo que copiare los datos en una tabla temporal.
Suponiendo que el backup está en mysqldump.sql y queremos generar el nuevo dump en /tmp/tabla.sql, podríamos hacerlo de la siguiente manera:
echo "USE \`NOMBRE_BD\`;" > /tmp/tabla.sql;sed -n '/^USE `'NOMBRE_BD'`/,/^USE/p' mysqldump.sql |sed -n '/-- Table structure for table `'NOMBRE_TABLA'`/,/UNLOCK TABLES/p'|sed s/NOMBRE_TABLA/NOMBRE_TABLABCCK/g >> $FILE
Al primer sed le indicamos que nos muestre lo que hay entre las lineas que empiecen por “USE `NOMBRE_BD`” y “USE“, que será la siguiente base de datos. Esto lo hacemos así ya que distintas bases podrían tener el mismo nombre para una tabla. Con la primera selección ya tenemos todo el dump de la base de datos donde se encuentra nuestra tabla. Con el siguiente sed seleccionamos las sentencias relacionadas con esa tabla, y con el último sed, le decimos que nos cambie ese nombre de tabla por otro, para no sobreescribir la original. El echo del principio, es para indicar la base de datos que tiene que usar en la restauración.

Pequeña receta para hacer un backup total de las bases de datos de MySQL:

mysqldump -uroot -p --all-databases > /var/tmp/mysqldump.`date +%Y%m%d`.sql

Si solo se quiere salvar los datos de una:

mysqldump -uroot -pPASSWORD NOMBRE_BD > /var/tmp/NOMBRE_BD.`date +%Y%m%d`.sql


Restauramos las bases del MySQL:

mysql -u root -p < /var/tmp/mysqldump.FECHA.sql

Restauramos una base del MySQL:

mysql -u root -p NOMBRE_BD < /var/tmp/NOMBRE_BD.FECHA.sql

Existe una herramienta llamada httping que nos puede servir de ayuda a la hora de optimizar nuestro servidor web.
Con ella podremos saber la latencia entre nuestro servidor web y el lugar desde donde la ejecutamos. También podremos medir el rendimiento de éste.

Para saber la latencia entre nuestro servidor web y el punto desde el que realizamos las pruebas, realizaremos:
httping -c 5 -g http://localhost/