¿Cuáles son las mejores prácticas para proteger la sección de administración de un sitio web? [cerrado]

Me gustaría saber cuáles son las mejores prácticas que la gente considera para proteger las secciones de administración de los sitios web, específicamente desde un punto de vista de autenticación / acceso.

Por supuesto, hay cosas obvias, como usar SSL y registrar todos los accesos, pero me pregunto dónde, por encima de estos pasos básicos, la gente considera que se debe establecer la barra.

Por ejemplo:

• ¿Solo confía en el mismo mecanismo de autenticación que usa para los usuarios normales? Si no, que?
• ¿Está ejecutando la sección de administración en el mismo 'dominio de aplicación'?
• ¿Qué pasos debe seguir para que no se descubra la sección de administración? (o rechazas todo el asunto de la 'oscuridad')

Hasta ahora, las sugerencias de quienes respondieron incluyen:

• Introduzca una pausa artificial del lado del servidor en cada verificación de contraseña de administrador para evitar ataques de fuerza bruta [Diseño del desarrollador]
• Utilice páginas de inicio de sesión separadas para usuarios y administradores que utilicen la misma tabla de base de datos (para detener el robo de sesiones y XSRF que otorgan acceso a las áreas de administración) [Thief Master]
• Considere también agregar autenticación nativa del servidor web al área de administración (por ejemplo, a través de .htaccess) [Thief Master]
• Considere bloquear la IP de los usuarios después de varios intentos fallidos de inicio de sesión de administrador [Thief Master]
• Agregar captcha después de intentos fallidos de inicio de sesión de administrador [Thief Master]
• Proporcione mecanismos igualmente sólidos (utilizando las técnicas anteriores) tanto para los usuarios como para los administradores (por ejemplo, no trate a los administradores de manera especial) [Lo'oris]
• Considere la autenticación de segundo nivel (por ejemplo, certificados de cliente, tarjetas inteligentes, espacio de tarjetas, etc.) [JoeGeeky]
• Solo permita el acceso desde direcciones IP / dominios confiables, agregue una verificación a la canalización HTTP básica (a través de, por ejemplo, HttpModules) si es posible. [JoeGeeky]
• [ASP.NET] Bloquear IPrincipal y Principal (hacerlos inmutables y no enumerables) [JoeGeeky]
• Elevación de derechos federados: por ejemplo, envíe un correo electrónico a otros administradores cuando se actualicen los derechos de cualquier administrador. [JoeGeeky]
• Considere los derechos específicos para los administradores, por ejemplo, en lugar de los derechos basados ​​en roles, defina derechos para acciones individuales por administrador [JoeGeeky]
• Restrinja la creación de administradores, por ejemplo, los administradores no pueden cambiar ni crear otras cuentas de administrador. Utilice un cliente "superadmin" bloqueado para esto. [JoeGeeky]
• Considere los certificados SSL del lado del cliente o llaveros de tipo RSA (tokens electrónicos) [Daniel Papasian]
• Si usa cookies para la autenticación, use cookies separadas para las páginas normales y de administración, por ejemplo, colocando la sección de administración en un dominio diferente. [Daniel Papasian]
• Si es práctico, considere mantener el sitio de administración en una subred privada, fuera de la Internet pública. [John Hartsock]
• Vuelva a emitir tickets de sesión / autenticación al moverse entre contextos de uso normal o de administración del sitio web [Richard JP Le Guen]

Todas estas son buenas respuestas ... En general, me gusta agregar un par de capas adicionales para mis secciones administrativas. Aunque he usado algunas variaciones sobre un tema, generalmente incluyen una de las siguientes:

• Autenticación de segundo nivel : esto podría incluir certificados de cliente (Ex. Certificados x509), tarjetas inteligentes, espacio de tarjetas, etc.
• Restricciones de dominio / IP : en este caso, solo los clientes que provengan de dominios confiables / verificables; como subredes internas; están permitidos en el área de administración. Los administradores remotos a menudo pasan por puntos de entrada VPN confiables para que su sesión sea verificable y, a menudo, también esté protegida con claves RSA. Si está utilizando ASP.NET, puede realizar fácilmente estas comprobaciones en la canalización HTTP a través de módulos HTTP, lo que evitará que su aplicación reciba solicitudes si no se cumplen las comprobaciones de seguridad.
• Autorización principal y basada en el principal bloqueado : La creación de principios personalizados es una práctica común, aunque un error común es hacerlos modificables y / o enumerables los derechos. Aunque no es solo un problema de administración, es más importante ya que aquí es donde es probable que los usuarios tengan derechos elevados. Asegúrese de que sean inmutables y no enumerables. Además, asegúrese de que todas las evaluaciones para la autorización se realicen según el director.
• Elevación de derechos federados : cuando cualquier cuenta recibe un número selecto de derechos, todos los administradores y el oficial de seguridad son notificados inmediatamente por correo electrónico. Esto asegura que si un atacante eleva los derechos, lo sepamos de inmediato. Estos derechos generalmente giran en torno a derechos privilegiados, derechos a ver información protegida de privacidad y / o información financiera (por ejemplo, tarjetas de crédito).
• Emitir derechos con moderación, incluso para administradores : finalmente, y esto puede ser un poco más avanzado para algunas tiendas. Los derechos de autorización deben ser lo más discretos posible y deben rodear comportamientos funcionales reales. Los enfoques típicos de seguridad basada en roles (RBS) tienden a tener una mentalidad de grupo . Desde una perspectiva de seguridad, este no es el mejor patrón. En lugar de ' Grupos ' como ' Administrador de usuarios ', intente desglosarlo aún más (por ejemplo , crear usuario, autorizar usuario, elevar / revocar derechos de acceso, etc.)). Esto puede tener un poco más de sobrecarga en términos de administración, pero esto le brinda la flexibilidad de asignar solo los derechos que realmente necesita el grupo de administración más grande. Si el acceso se ve comprometido, al menos es posible que no obtengan todos los derechos. Me gusta incluir esto en los permisos Code Access Security (CAS) compatibles con .NET y Java, pero eso está más allá del alcance de esta respuesta. Una cosa más ... en una aplicación, los administradores no pueden administrar el cambio de otras cuentas de administrador o convertir a un usuario en administrador. Eso solo se puede hacer a través de un cliente bloqueado al que solo un par de personas pueden acceder.

Si el sitio web requiere un inicio de sesión para las actividades habituales y los administradores, por ejemplo, un foro, usaría inicios de sesión separados que usan la misma base de datos de usuarios. Esto asegura que XSRF y el robo de sesiones no permitirán al atacante acceder a áreas administrativas.

Además, si la sección de administración está en un subdirectorio separado, asegurar esa con la autenticación del servidor web (.htaccess en Apache, por ejemplo) podría ser una buena idea; entonces alguien necesita tanto esa contraseña como la contraseña de usuario.

La ocultación de la ruta de administración no genera casi ninguna ganancia de seguridad: si alguien conoce datos de inicio de sesión válidos, lo más probable es que también pueda averiguar la ruta de la herramienta de administración, ya que la envió a través de phishing o keylogger o la obtuvo a través de ingeniería social (lo que probablemente revelaría el camino, también).

Una protección de fuerza bruta como bloquear la IP del usuario después de 3 inicios de sesión fallidos o requerir un CAPTCHA después de un inicio de sesión fallido (no para el primer inicio de sesión, ya que eso es extremadamente molesto para los usuarios legítimos) también podría ser útil.

• Rechazo la oscuridad
• Usar dos sistemas de autenticación en lugar de uno es excesivo
• La pausa artificial entre intentos también debe hacerse para los usuarios.
• El bloqueo de IP de intentos fallidos también debe realizarse para los usuarios
• Los usuarios también deben utilizar contraseñas seguras
• Si consideras que los captchas están bien, adivina qué, también podrías usarlos para los usuarios

Sí, después de escribirlo, me doy cuenta de que esta respuesta podría resumirse como "nada especial para el inicio de sesión de administrador, todas son características de seguridad que deben utilizarse para cualquier inicio de sesión".

Si usa solo un inicio de sesión para usuarios que tienen privilegios de usuario normal y privilegios de administrador, regenere su identificador de sesión (ya sea en una cookie o un parámetro GET o lo que sea ...) cuando haya un cambio en el nivel de privilegio ... al menos.

Entonces, si inicio sesión, hago un montón de cosas de usuario normales y luego visito una página de administración, regenero mi ID de sesión. Si luego navego fuera de una página de administración a una página de usuario normal, regenerar mi ID nuevamente.

Tenga una buena contraseña de administrador.

No, "123456"sino una secuencia de letras, dígitos y caracteres especiales lo suficientemente largos, digamos, 15-20 caracteres. Al igual "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Agregue una pausa para cada verificación de contraseña para evitar ataques de fuerza bruta.

Aquí hay algunas otras cosas a considerar:

1. Una opción a considerar, especialmente si administra las computadoras del administrador o si son técnicamente competentes, es usar algo basado en certificados SSL para la autenticación del cliente. Los llaveros RSA y todo eso también se pueden usar para mayor seguridad.
2. Si está utilizando cookies, tal vez para un token de autenticación / sesión, probablemente desee asegurarse de que las cookies solo se envíen a las páginas de administración. Esto ayuda a mitigar los riesgos planteados a su sitio al robar cookies, ya sea por compromiso de capa 1/2 o XSS. Esto se puede hacer fácilmente si la parte de administración se encuentra en un nombre de host o dominio diferente, además de configurar la bandera de seguridad con la cookie.
3. Restringir por IP también puede ser inteligente, y si tiene usuarios en Internet, aún puede hacerlo, si hay una VPN confiable a la que puedan unirse.

Usamos Windows Authenticationpara acceso de administrador. Esta es la forma más práctica de proteger las áreas de administración mientras se mantiene la autenticación separada de lo que se aplica a los usuarios finales en general. El administrador del sistema gestiona las credenciales de acceso del usuario administrador y hace cumplir las políticas de contraseña en la cuenta del usuario del dominio.

La forma estricta es tener dos "granjas" diferentes, incluidas bases de datos, servidores y todo, y mover los datos de una granja a otra. La mayoría de los sistemas modernos a gran escala utilizan este enfoque (Vignette, SharePoint, etc.). Normalmente se dice que tiene diferentes etapas "etapa de edición" -> "etapa de vista previa" -> "etapa de entrega". Este método le permite tratar el contenido / configuración de la misma manera que trata el código (dev-> qa-> prod).

Si es menos paranoico, puede tener una única base de datos, pero solo su sección de administración está disponible en los servidores de "edición". Quiero decir, solo coloque los scripts / archivos de edición en el servidor de edición.

Naturalmente, la etapa de edición solo debería estar disponible en una intranet local y / o usando una VPN.

Esto puede parecer un poco exagerado y puede que no sea la solución más fácil para todos los casos de uso, pero definitivamente es la forma más sólida de hacer las cosas.

Tenga en cuenta que cosas como "tener contraseñas de administrador seguras" son buenas, pero aún dejan a su administrador abierto a ataques inteligentes de todo tipo.

Depende en gran medida del tipo de datos que desee proteger (requisitos legales y demás).

• Muchas sugerencias tienen que ver con la autenticación ... Creo que debería considerar el uso de la autenticación OpenId / Facebook como inicio de sesión. (Lo más probable es que gasten más recursos en seguridad de autenticación que usted)

• Guarde los cambios y actualice los valores en la base de datos. De esa forma, puede revertir los cambios del usuario X o entre la fecha X e Y.

No noté que nadie mencionara el almacenamiento / validación de la contraseña de administrador. Por favor, no almacene el PW en texto sin formato, y preferiblemente ni siquiera en algo que pueda revertirse; use algo como un hash MD5 salado para que, al menos, si alguien recupera la "contraseña" almacenada, no la tenga cualquier cosa terriblemente útil, a menos que también tengan tu esquema de sal.

Agregue un campo de contraseña y una pregunta de seguridad que el Administrador sepa, por ejemplo, cuál fue el nombre de su primera novia, o aleatorice las preguntas cada vez que vea el panel de administración.

Quizás siempre podría poner la sección de administración en un directorio grande, por ejemplo

http://domain.com/sub/sub/sub/sub/sub/index.php

Pero eso no es realmente bueno, ja.

Quizás podría incluir una cadena de consulta en la página de inicio, como:

http://domain.com/index.php?display=true

Cuando lo haga, aparecerá el campo de nombre de usuario y contraseña.