De manera similar a esta pregunta sobre Stack Overflow, ¿qué debe saber un administrador de sistemas que está acostumbrado a situaciones privadas de tipo intranet antes de ser administrador de un sitio público?
Estas podrían ser cosas relacionadas con la seguridad, como "no dejarlo telnetabierto", o cosas prácticas como cómo hacer un equilibrio de carga para un sitio de alto tráfico.
Respuestas:
Cada aplicación, cada binario, cada paquete que existe en el servidor es una responsabilidad. Suscríbete al principio del "mínimo bit"; Si no está instalado, no puede verse comprometido.
Implemente la detección de intrusos, como Tripwire o similar, y escanee con frecuencia.
Invierta en un firewall de hardware y solo abra los puertos que necesita para su aplicación. No permita que sus puertos de administración (ssh, rdp, etc.) sean visibles públicamente; restringirlos a direcciones IP de administración aprobadas.
Tenga copias de seguridad de las configuraciones de su firewall / interruptor / enrutador al momento de entrar en producción. Si uno de esos dispositivos se ve comprometido, es significativamente más rápido recuperarse limpiando el cerebro del dispositivo y recargando la configuración que realizar una auditoría línea por línea de la configuración cuando el reloj pasa.
mapee su entorno desde el exterior con frecuencia para asegurarse de que no se hayan abierto nuevos puertos.
Nunca confíes en internet; asegúrese de que sea lo que sea que esté sirviendo en la red sea lo más seguro posible (realice una validación y desinfección de entrada del lado del servidor para detener los ataques de inyección SQL, por ejemplo).
Mantente al tanto de tus parches.
Si está comprometido, reconstruya desde cero con medios recién descargados. Ya no puede confiar en que sus copias de seguridad estén seguras y no se hayan visto comprometidas (aunque tripwire puede ayudar con esto) por otra cosa que no sean datos inertes y no ejecutables.
Una herramienta que he encontrado útil para fortalecer la red es nessus
Básicamente, lo configura en un servidor externo, e intenta atacar su red con una gran cantidad de exploits conocidos. Puede configurarlo para el modo seguro (donde ninguno de los ataques debería bloquear su servidor), o si está bastante seguro de que tiene todo parcheado, o puede permitirse reiniciar sus servidores si es necesario, para el modo inseguro .
Luego, proporcionará un informe calificado muy completo para cada máquina que pueda ver de las vulnerabilidades / debilidades que encuentre, y las calificará en cuanto a su gravedad, e incluso recomendará acciones a tomar para abordar los problemas.
Deben saber cómo funciona su sistema de respaldo y recuperación ante desastres y cómo recuperarán el sistema cuando se vea comprometido.
Esto es un poco contrario, pero en términos de seguridad no distingo entre un servidor interno y un servidor externo. Tarde o temprano, alguien cometerá un error en un firewall, la administración insistirá en que un servidor esté expuesto debido a un cliente importante, Betty en contabilidad de alguna manera obtendrá un cliente VPN en su máquina doméstica infectada, etc.
Dicho esto, las capas son tus amigas y deberías incluirlas en la lista negra de forma predeterminada.
Capas: debe tener varias capas de seguridad. Por ejemplo, un firewall de hardware y un firewall de software. En teoría, tienen el mismo propósito, pero tener varias capas protege contra errores y mitiga las consecuencias de una sola capa que se explota.
Otro aspecto de la estratificación es el "hogareño", que es esencialmente DMZ múltiples. En algún momento, debe tener cierto nivel de confianza entre sus máquinas y las personas que acceden a sus cuentas. Si puede reducir esos puntos de interacción, puede controlar estrictamente el tipo de tráfico en el que confía en cualquier momento. Por ejemplo, si separa sus servidores de interfaz / aplicación de sus servidores de base de datos, reduce el nivel de confianza. Si sus servidores de aplicaciones se ven comprometidos, esos atacantes obtienen un punto de apoyo mínimo en su infraestructura (es decir, para continuar su ataque e intentar explotar sus otros servidores, solo tienen esos puntos de confianza establecidos para usar).
Con respecto a las listas negras por defecto, básicamente debería cerrar todo y exigir (incluso si es solo de usted) justificación para cada puerto que abra, nombre de usuario al que permita el acceso, aplicación que instale, etc.
En los sistemas con CUALQUIER interfaz pública, asegúrese de que sus usuarios tengan contraseñas seguras implementando una política de contraseña segura y probando el archivo de contraseña con una utilidad para descifrar contraseñas como John the Ripper
Puede protegerse aún más contra los ataques de adivinación de contraseña de fuerza bruta bloqueando las direcciones IP después de varios intentos fallidos. Una buena herramienta para esto (en Linux) es fail2ban
Su interruptor puede ser pirateado y alguien puede alterar los datos. Si no es el propietario del conmutador, configure un vpn, ya que la restricción de acceso al firewall por ip podría no ser suficiente.
No deje ningún puerto abierto excepto aquellos a los que desea que accedan los usuarios y los hackers. Escanee sus propios servidores desde otro sitio todos los meses.
No deje el puerto predeterminado de ssh abierto para hackers.