De todos es sabido que una configuración correcta de PHP hablando de servidores web es vital para evitar “sustos” o ataques hacia nuestras máquinas. Si eres un administrador de sistemas o estás interesado en estas cuestiones, os recomendamos leer (en Inglés) estos 25 ejemplos para mejorar la seguridad de instalaciones en las que se ejecute PHP.

Acceso a; “25 PHP Security Best Practices For SysAdmins“

Durante el día de ayer y hoy, hemos podido leer tal y como informan en Ontinet y en muchos otros sites, que dos de los servidores destinados a distribuir el Kernel que impulsa nuestras distros de GNU/Linux alojados en kernel.org, fueron víctimas de un ataque que podíamos catalogar como “devastador”, dado el grado de acceso que se consiguió.

Hablamos nada más y nada menos que con privilegios de “root” (súper usuario en un sistema *Nix). Este hecho derivó en la inclusión de un troyano en parte de su código fuente con las consecuencias que ello conlleva. A pesar de que la intrusión se llevó a cabo el día 12 de Agosto y fue descubierta el pasado 28, algunos pueden pensar si el Kernel que han descargado desde el día 12 hasta la fecha contiene alguna vulnerabilidad.

Una fuente tan reputada como Jonathan Corbet ya ha dicho que no debemos preocuparnos por la integridad del Kernel reconociendo (cómo no) que es un tema preocupante y que se volcarán backups “limpios” en los sistemas afectados además de revisar el resto.

Hablando de Git…

Los aproximadamente 40.000 ficheros que componen el Kernel, cuentan con una protección como la que ofrece “Git” (creado por el propio Linus Torvalds) el cual se basó para su desarrollo en BitKeeper y en Monotone para llevar un control de versiones eficaz y seguro. Actualmente, Git esta principalmente mantenido por Junio Hamano junto a casi 300 programadores.

Git es usado actualmente además de para desarrollar el código del Kernel, de proyectos de tanto peso como Perl, KDE, Android, Debian o GNOME por citar algún ejemplo.

Os podéis imaginar lo que puede ser llevar ese control de cambios en un mismo fichero por una cantidad tan grande de programadores que trabajan en el código fuente del Kernel. Gracias a Git, ese proceso se realiza de una forma rápida y eficiente. Cuando se realiza un cambio en el código sobre alguna versión previa, los cambios que se hacen posteriormente son notificados en todas ellas.

La gestión distrubuida que ofrece Git proporciona a cada mantenedor del código una copia local con todos los cambios realizados en el desarrollo de un proyecto. Esos cambios se propagan entre repositorios locales y son importados como ramas adicionales pudiendo ser fusionadas del mismo modo que en la ramificación local. Todo ello apoyado por la solidez del “hash” SHA1 para evitar “colisiones” y llevar un mejor control de los cambios realizados.

Trabaja con desarrollos no-lineales que dotan de una mejor gestión de las ramificaciones y la fusión con versiones diferentes del código, se realiza de una forma rápida y eficaz. A pesar de que se hay otras formas de publicar los cambios, se suele optar por el cifrado que ofrece SSH para hacerlo de un modo más seguro. Se pueden usar a modo de emulación, varios módulos y clientes CVS y con “git-svn” trabajaremos con Subversion o svk.

Como podéis ver, la forma de trabajar a través de Git junto a las palabras de Corbet ya deberían ser suficientes como para tranquilizarnos, alguien como él no diría gratuitamente “no hay problemas con el Kernel” caso de haberlos, pero también, muchos de los desarrolladores que se encargan de su mantenimiento, si no fuese así, podéis dar por seguro que darían la voz de alarma.

Lo mejor para ver todas las funcionalidades de Git, es pasaros por sus “FAQs”.

Nuestro compañero Dabo está de “cumpleblog” con su DaboBlog. Sí, parece que fue ayer cuando nos anunció que se independizaba de nosotros (al final no fue para tanto porque como podéis leer, todavía le dejamos escribir por aquí -;P).

Coincidiendo con esa fecha tan señalada (Dabo, eso seguro que estaba preparado, ¡Qué casualidad!), un blog amigo y referencia donde las haya hablando de seguridad informática como es Security By Default, le ha realizado una entrevista titulada “Entrevista a David Hernández (aka Dabo)” donde podéis saber un poco más tanto de él, como de los comienzos de Daboweb y el resto de proyectos que mantiene en Internet. Gracias a SbD por el detallazo .

Además, tal y como nos cuenta en esta entrada, da el salto junto a dos conocidos por todos vosotros a un plano más profesional en su actividad con los servidores web dentro de APACHEctl.com.

Para acabar, podemos ver que Dabo ha tenido un año 2010 muy relevante y empieza fuerte el 2011. Mucha suerte con todo, que no se te suban mucho los humos que ya te los bajaremos aquí -;P. Ya sabes, estamos ahí todo el equipo para lo que sea y más si hace falta (toca revisión salarial en 2011 ya!!)

A través de Hispasec nos enteramos de un grave agujero de seguridad que afecta a ProFTPD en su versión 1.3.3c, habiendo sido descargado entre los días 28 de Noviembre y 1 de Diciembre.

Atacantes remotos lograron el acceso al servidor principal desde el que se distribuye ProFTPD, manipulando los ficheros originales e instalando una puerta trasera que permite el acceso remoto con privilegios de root a usuarios no autenticados en el sistema consiguiendo un acceso total al sistema afectado.

El fallo ha sido corregido, aunque hay dudas acerca de cómo se ganó el acceso. Os recomendamos leer toda la información sobre esta grave vulnerabilidad en Hispasec.

Nuestro compañero Dabo se pone en esta ocasión al micro junto a Ricardo Galli (Menéame, UIB) en un episodio especial de su podcast dedicado a la administración y gestión de un servidor o proyecto web.

El resultado, ha sido una didáctica charla sobre sysadmins entre dos colegas que nos van haciendo entrar en escena a medida que transcurre el podcast abarcando las siguientes cuestiones;

Escalado web, MySQL, Amazon, Apache, Ngnix, Caching, Monitorización, Seguridad.

Acceder a “Especial SysAdmins en Kernel Panic” (Dabo) | “Un podcast para SysAdmins“ (Gallir).

Junto a la entrada original en DaboBlog, se puede ver una extensa documentación de todo lo comentado en el audio.

Nuestro compañero Dabo ha publicado en su blog un tutorial sobre el uso de BFD, (Brute Force Detection) una herramienta muy a a tener en cuenta para proteger un servidor web bajo GNU/Linux frente a ataques de fuerza bruta, servicios tan importantes en  como; sshd, FTP, correo POP e IMAP, etc.

Acceso al post en DaboBlog.

Para hoy Sábado y vía Wwwhat’s New os recomendamos guardar en vuestros marcadores la siguiente url; www.htaccesstools.com. Alguna vez hemos hablado de los ficheros .htaccess y cómo usarlos para aumentar la seguridad de un servidor, web o blog, esta herramienta os ayudará para simplificar los pasos a seguir.

Desde Htaccess Tools podréis generar passwords, hacer redirecciones por lenguaje, bloqueos de IPs maliciosas o definidas por vosotros, reducir el consumo de ancho de banda cuando se usan vuestras imágenes en otras webs (hotlinking), etc.

Todo ello de un modo muy intuitivo y aún estando la información en Inglés, se entiende perfectamente. También cuentan con un foro de ayuda para los temas que tratan en la web.

Si decimos que la industria del Malware, además de molesta, perniciosa y cansina, está siempre “a la última” en cuanto a técnicas de infección-redifusión, no sería nada nuevo ya que de todos es sabido.

Pero no está de más tener en cuenta esta información que podemos leer en Slashdot (ENG) con origen en este enlace (ENG), en la que se hacen eco de un aumento de ataques a través de servidores DNS vulnerables o con configuraciones potencialmente explotables, que son un filón para los crackers que consiguen hacerse con el control de esos servidores DNS, redirigiendo varios subdominios legítimos a una IP diferente y desde donde se llevan a cabo los ataques (de todo tipo) hacia el usuario a través de su navegador.

Sirva también a modo de recordatorio para los que administramos un servidor web, ya que como bien apuntan en la entrada original, a veces, una vez que has configurado las zonas DNS así como los diferentes dominios principales y subdominios, puede que no se revisen con la frecuencia que sería deseable y más si son subdominios creados no para servir páginas, sino para alojar por ejemplo imágenes, ficheros, etc, donde rara vez se consulta vía web sino más bien por FTP-SFTP.

Aunque personalmente opino que si ya se han hecho con el control de tu DNS, estás técnicamente K.O. Si hablamos de un servidor web bajo GNU/Linux, no está de más revisar esas configuraciones DNS y usar herramientas como “nslookup” o hacer consultas DNS con el comando “dig” para ver que está todo correcto y que tanto los dominios principales como subdominios, apuntan a IPs correctas.

Y para acabar, hablando de subdominios, es importante revisar a nivel de Apache que no queden expuestos o la vista de todos los subdominios (listado de directorios), aunque con un simple “index.php” o “.html” en el directorio principal del subdominio, caso de que como dije antes no se sirva tráfico web desde él, el contenido alojado dentro no quedará expuesto.