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).
Buscamos en el archivo search.php (está al principio):
Código:
$userdata = session_pagestart($user_ip, PAGE_SEARCH);
init_userprefs($userdata);
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.