Proteger un área de administración del público

Me enfrenté a la misma situación, o solo permites el acceso a la consola desde ciertas IP y luego codificas todas las IP o rangos públicos que deberían tener acceso a ella. O restringir el acceso a un determinado rango de LAN y solo permitir el acceso desde allí. Luego, puede configurar una solución VPN y dar acceso a la VPN a todas las personas que necesitan acceso al panel de administración. Las personas primero deberán autenticarse en la VPN y solo así podrán acceder al panel administrativo (que tiene otro inicio de sesión). De esta manera, las personas aún pueden acceder al panel de administración desde cualquier lugar (en caso de que estén trabajando desde casa), pero no es accesible para todos.

Creo que también podría ser una buena idea implementar la autenticación de dos factores (pero tú decides).

También sugiero leer esta pregunta que publiqué hace un tiempo sobre cómo proteger los paneles de administración: Bruteforce vs Denegación de servicio

Para los sitios serios, el mayor problema no es la existencia de una ruta de acceso a una consola de administración, sino la posibilidad de un compromiso debido al administrador del sistema de escritorio para ser cargado de malware. Ambos problemas se pueden resolver de una vez mediante el inicio de sesión del administrador solo desde sistemas específicos y dedicados que se encuentran en las instalaciones. Esto evita todos los problemas que pueden surgir de la idea de permitir que los administradores actúen desde cualquier lugar, por ejemplo. desde casa o desde una computadora portátil mientras está de vacaciones. Por supuesto, esto significa que los administradores de sistemas deben estar listos para ir a trabajar en cualquier momento (o, mejor aún, estar allí; estoy listo para creer que en Ebay siempre tienen un administrador de sistemas en el sitio).

Para las redes más pobres, aún puede aplicar métodos de inicio de sesión sin contraseña (SSH con autenticación de clave pública, RDP con un certificado de cliente ...) que al menos evitan el espantoso negocio de las políticas de contraseña.

Oculte la interfaz de administración detrás de la autenticación criptográfica. Puedes lograr esto de diferentes maneras:

• En el nivel del servidor web, requiere SSL con un certificado de cliente verificado
• Expone el servicio de administración solo en una dirección IP privada a la que se puede acceder solo a través de una VPN
• Exponga el servicio solo en "localhost" y acceda a él mediante el reenvío de puertos SSH.
• Requiere autenticación de 2 factores dentro de la aplicación de administración.
• Alguna combinación de lo anterior.

Depende de cuánto esfuerzo esté dispuesto a gastar para proteger el área de administración.

• Un enfoque simple pero efectivo es usar una URL criptográfica para acceder al área de administración. Algo como un hash (por ejemplo, "u59sOgpDJa ~ M" en lugar de simplemente "admin") o similar que cambia regularmente. De esta manera, un atacante no puede hacerlo directamente porque no sabe la dirección y debe buscarla primero.

• Además, debe limitar el número de intentos de inicio de sesión fallidos. Es muy importante para que un ataque de fuerza bruta no se pueda realizar fácilmente. Por ejemplo, bloquee la dirección IP durante unas horas después de un par de inicios de sesión fallidos. Puede usar Fail2ban , DenyHosts , OSSEC , etc. o puede implementar el suyo propio. Además, puede agregar un retraso entre cada respuesta de intento de inicio de sesión, como unos pocos segundos que los usuarios no notan pero que ralentizan significativamente los robots.

No recomendaré el uso de una autenticación vpn o SSH, eso sería seguro, por supuesto, pero intentaré concentrarme solo en proteger un portal web:

1. permite que cada nombre de usuario inicie sesión solo desde un rango de IP predefinido, o una única IP estática. Si el usuario tiene una IP dinámica, no mantenga su inicio de sesión abierto a todos los rangos de IP, sabe que solo usará el rango de IP de su ISP todo el tiempo.

2. no uses un nombre obvio, como domain.com/admin , intenta hacer que suene como otra cosa, como domain.com/betazone400 o superior domain.com/SquirrelMail

3. agregue un certificado SSL y asegúrese de que los usuarios verifiquen que solo están ingresando la contraseña después de verificar que el certificado SSL sea válido, y que estén usando la misma ortografía domain.com . un usuario que ingrese su contraseña por error en otro lugar podría ser un gran problema de seguridad.

4. use nombres de usuario oscuros, tanto los nombres de usuario como la contraseña deben tener caracteres aleatorios. la mayoría de las personas intentarán utilizar Bruteforce con nombres de usuario como admin .

5. el número límite de intentos de inicio de sesión cuenta para evitar el uso brusco y cambiar los nombres de usuario y las contraseñas de los nombres de usuario que se intentan (si el atacante está usando los nombres de usuario correctos).

6. debe registrar todos los intentos fallidos de inicio de sesión, el registro de contraseñas incorrectas, ya que el texto sin cifrar en la base de datos podría ser malo, así que registre todo lo demás. (Registre las direcciones IP y los nombres de usuario de los intentos de inicio de sesión incorrectos)

Creo que la solución que implica el acceso VPN es la mejor. Puede limitar el acceso a esta interfaz a 2-3 ip y pedir a los administradores que vpn a través de uno de esos servidores. Yo evitaría usar solo un vpn ya que podría caerse por alguna razón. También puede incorporar una solución de tarjeta inteligente a la VPN y, en este caso, tiene autenticación de 2 factores. no olvides desactivar cualquier acceso que no sea https.