Medidas para asegurar foro phpbb 2.0.19

Posted by Dabo on febrero 21, 2006
Seguridad Informática
daboweb1.gifHola amigos, ante la confusión actual sobre diferentes Bugs que afectan a foros phpbb centrándonos sobre todo en su versión 2.0.19 y a la espera de una actualización "oficial" siempre teniendo en cuenta la actitud un tanto "pasiva" de la web de sus creadores, www.phpbb.com, voy a comentaros unas medidas paliativas que no definitivas hasta la llegada de una nueva versión que los corrija. Otros consejos creo que os serán también útiles para futuras versiones.
 
El artículo en menéame, gracias Kids -:). 

Hace unos días daba una información sobre el HTML activado y por qué desactivarlo, no quiero que nadie se pueda equivocar o que mi información pueda ser interpretada erróneamente, ese detalle, el desactivarlo es para una vulnerabilidad, la del HTML, pero no para otras (XSS etc).

No voy a referenciar mucho el porqué de estos consejos ya que en cierto modo podría ayudar a fomentar la inseguridad de los mismos porque no hay parches a día 21-2-06, de todos modos, debajo pongo los boletines de seguridad en los que me inspiro, me refiero a que no pongo los exploits, etc. Si alguien tiene dudas o sugerencias puede enviarme un mail a dabo arroba daboweb.com pero al final del artículo va un link a un tema que hemos abierto en nuestro foro de seguridad.
 
Consejos- (Estos a nivel particular sobre versión 2.0.19)

-Activar la función de confirmar cuenta o registro mediante el código visual que tenéis en el panel de control. -Desactivar HTML en el panel de control del administrador (HTML off) -Ocultar la cuenta de correo del Admin y cambiarlas si es preciso por si alguien las pudiera tener -Prohibir los avatares o imágenes externas -Otras medidas que implican tocar el codigo,Haz antes una copia de seguridad de tus archivos y un backup de la base de datos, en www.tomatoma.ws o www.phpbb-es.com hay información al respecto.

Desactivar la función de búsqueda a users no registrados/loggeados

Buscamos en el archivo search.php (está al principio):

Código:

$userdata = session_pagestart($user_ip, PAGE_SEARCH);
init_userprefs($userdata);

y añadimos justo después;Código:

if ($userdata[’user_id’] == ANONYMOUS)
{
redirect(append_sid(”login.$phpEx?redirect=search.$phpEx”, true));
}

Este código está inspirado en este que os pongo debajo, os recomiendo darle un vistazo

http://www.phpbb.com/files/mods/redirect_annonymous_users

Otra protección extra para evitar ataques DOS en el sistema de búsquedas (Gracias The KuKa -:)

Con cTracker evitamos ataques tipo DOS, solo permite usar la busqueda por x usuarios a la vez, con una frecuencia, etc. Con la contraseña otro tanto, ademas el login se hace con el Visual Confirmation, a la vez de tener un LOG completo de todo ello, una lista de IPs tipo SPAM ,se pueden añadir mas IPs desde el ACP (panel de control del administrador)

http://www.phpbb-es.com/foro/cr..kertracker-professional
http://www.community.cback.de/viewtopic.php?t=3421

Desactivar la función “olvidé mi contraseña”

Vaciar todo el código del siguiente archivo

Código:

includes/usercp_sendpasswd.php

y poner dentro el típico “función no disponible contacta con el administrador en este correo ….”

Si no tenéis conocimientos de php a nivel de sintaxis o código podéis hacer un documento HMTL y meterlo dentro del includes/usercp_sendpasswd.php , no os preocupéis que las etiquetas HTML las leerá igual.

——————–Otras medidas aconsejables para todo tipo de versiones

Algunos ataques van “directos” contra el user admin y otros contra el “ID” o identificador, contra los segundos poco se puede hacer pero para protegerse de los ataques al primero os recomiendo seguir la lógica de Unix en cuanto a la administración o uso normal del foro.

Mi propuesta es esta, cogéis un usuario que hayáis podido tener inactivo de pruebas u otro que registréis e ese momento y le hacéis administrador, lo ocultáis.

Al admin normal le dejáis con el rango (que no permisos) de admin y oculto y le quitáis los privilgios de administrador, lo ocultarlo es también para que no se vea que no sale en color naranja (aunque podéis cambiarle el color desde el ACP os recomiendo ocultarlo)

Administráis el foro con el user oculto que nadie conoce y vuestro admin “oficial” seguirá siendo el mismo pero si se hacen con esa cuenta o la fuerzan no podrán borrar nada ni bajarse un backup de la base de datos etc etc.

—————-

También os recomiendo proteger el directorio del admin mediante está información de Tomatoma

http://www.tomatoma.ws/foros/viewtopic.php?t=5898

—————

Más consejos;

Tener un especial cuidado con mensajes privados que contengan imágenes, puede que a través de esa imagén consigan vuestra IP con un sencillo código.

Protección u ocultación de todos los correos de moderadores y usuarios que accedan a foros privados o tengan permisos para editar.

Vaciar las bandejas de mensajes privados para que en caso de violentar una cuenta de admin no se vean comprometidas las de otros usuarios, a veces llegan mensajes con información más sensible si cabe a los buzones de los administradores.

Cambiar las contraseñas con más frecuencia, evitar combinaciones que puedan estar en diccionarios sensibles a ataques por fuerza bruta, combinar mayúsculas – minúsculas simbolos y números quería decir y a ser posible mayores de 8 caracteres.

Pensar en los foros privados como si fueran “públicos”, no dejando información confidencial que en caso de un ataque e intrusión pueda ser utilizada de diferentes modos.

También sería recomendable y sobre todo viendo la gran cantidad de cambios para Subsilver en la versión 2.0.19 , dejar el template por defecto o en su caso uno que se actualice con la frecuencia del original (Subsilver).

Tener instalados los mínimos mods posibles que os permitan restaurar / parchear el foro en casos de urgencia a la mayor brevedad posible.

Y por último os repito que lo más importante es tener copias de seguridad de vuestras bases de datos y archivos en el servidor además de una gran prudencia y sentido común en la administración del foro y /o movimientos que realicéis en el mismo así como los moderadores y co-admins

Vulnerabilidades publicadas en las que me he basado para escribir lo concerniente a la versión 2.0.19 que espero tenga una pronta actualización que corrija estos Bugs;

FrSIRT

http://www.frsirt.com/english/advisories/2006/0461

http://www.frsirt.com/english/advisories/2006/0445

http://www.frsirt.com/english/advisories/2006/0051

CVE MITRE

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0450

Hay otras informaciones en las que me inspirado que por la propia seguridad de los foros no comentaré.

Para acabar, dar las gracias a tanta gente que anónimamente trabaja desarrollando software libre que después muchos utilizamos en nuestro día a día y entender todos que parte de la grandeza del software no propietario (sin referirme en este caso a la licencia de phpbb en concreto) reside en que es algo “vivo” y aún con los lógicos fallos de desarrollo, el software propietario tiene los mismos bugs o más aún, solo que quizás el día que te enteras de ellos quizás ya es demasiado tarde…

En especial aprovecho para agradecer también por su labor desinteresada y continuada, a sitios como Tomatoma o phpbb-es.com , demostrando día a día que el mejor soporte no se expresa únicamente en Inglés -:)

Hay otra persona que ha colaborado en este documento y que no estoy autorizado a citar, desde aquí te mando un abrazo amigo, el que no salga tu nombre no quiere decir que no lleve también tu firma 😀

Este documento se distribuye bajo una licencia Creative Commons, puedes reproducirlo en parte o en su totalidad o incluso mejorarlo (lo cual no será difícil XD) con el único requisito de que cites la fuente original.

Debido a la complejidad y combinaciones o parámetros que se pueden dar en un ataque a un foro de este tipo no me responsabilizo de que con estas medidas que son paliativas no definitivas, dichos ataques no se puedan llevar a cabo.

También y aunque esto pueda parecer un contrasentido, si “al otro lado” no hubiera gente que descubriese vulnerabilidades como estas, los avances o mejoras del propio software serían más lentos y posiblemente más inseguros… Los sistemas cerrados son muchas veces un claro ejemplo de ello.

En caso que tengais alguna duda sobre este articulo podeis realizar vuestras consultas en este post del foro de Tomatoma donde han publicado el artículo y donde yo prefiero que se trate al ser un lugar más adecuado donde darán mejor soporte.

Tags:

Comments are closed.

Sentimos molestarte con lo de las Cookies, pero es por imperativo legal. Puedes ver aquí la Política de Cookies, si continúas navegando te informo que la estás aceptando ;)    Ver
Privacidad