¿Es seguro reiniciar un servidor abierto a Internet?

Específicamente

Tengo un conjunto de reglas de iptables definido en un servidor que ejecuta CentOS. ¿Estoy garantizado / puedo garantizar / cómo puedo garantizar que cuando la red se conecte (ya sea en el arranque de la máquina o después de reiniciar el servicio de red) el conjunto de reglas de iptables ya está aplicado (y si iptables no se inició o no pudo aplicar el conjunto de reglas la interfaz de red no podrá aparecer)?

(Sé que esta es una pregunta novata, pero nunca he ejecutado un servidor en otra cosa que no sea redes confiables detrás de un DHCP NAT enmascarado y un firewall, así que ... espere preguntas novatas de los novatos).

networking centos security boot internet Tiro de Partia
fuente

Realmente no es una pregunta novata en absoluto. Esto es esencialmente cómo los piratas informáticos ingresaron a la red de PlayStation en 2011, causando 24 días de interrupción y $ 15MM en acuerdos. Cuando sus cortafuegos se reiniciaron (como lo hacían mensualmente), el cortafuegos se abrió por unos instantes, aparentemente el tiempo suficiente.

Chris S

@ChrisS Lo más extraño de eso, para mí, sería que estoy seguro de que los administradores de sistemas responsables de esa red seguramente serían lo suficientemente inteligentes como para negarse si alguien sugiriera apagar el firewall, pero no pestañear, mensualmente , apagándolo ... y luego volviéndolo a encender. Sin embargo, no estoy seguro de qué combinación de estos lo explicaría.

Parthian Shot

Otra opción es deshabilitar el puerto en el conmutador de red hasta que el servidor se haya iniciado por completo, si está en el sitio y tiene acceso al conmutador. Esto no es ideal, pero definitivamente funcionaría, a menos que el servidor tuviera una dependencia de red como NFS.

jftuga

@jftuga Bueno, claro. Pero entonces el servidor no estaría conectado a Internet, por lo que esa solución técnicamente no cae dentro del alcance de esta pregunta. Si estoy en el sitio, podría desconectar el cable de Ethernet durante el reinicio. Y el problema subyacente permanecería con la solución de bloqueo de puertos, de todos modos; que otra computadora que ataca a través de la red no sería detenida por el firewall local. Si el enrutador está pirateado, o funciona mal, o si alguien más en la red local se ve comprometido, el juego aún termina.

Parthian Shot

@jftuga De hecho, el problema es aún peor que eso. Suponiendo que alguien ya ha conseguido ejecutar una pieza de software en la máquina local, pero mi cortafuegos hace el filtrado de salida, la regla es que los paquetes salientes solo se permiten si están establecidos o relacionados, y las nuevas conexiones entrantes solo se permiten al puerto 80 Normalmente, eso evitaría un shell inverso de una cuenta no privilegiada. Pero si la conexión se inicia en el arranque, se mantendrá mediante la inicialización del firewall. Supongo que eso también significa que las reglas del firewall deberían cambiar, pero es un error fácil de cometer.

Disparo de Partia el

Respuestas:

Fuera de la caja, tiene la garantía de que iptables se iniciará antes de que aparezca la interfaz por orden de los scripts de inicio. Mire la línea "chkconfig" en cada script de inicio y verá los niveles de ejecución en los que está "activado" cuando está activo, el orden de inicio y el orden de detención.

No se garantiza que la interfaz no se abrirá si el conjunto de reglas de iptables no se aplicó correctamente (o no se aplicó).

Ejemplo:
chkconfig: 2345 08 92
esta línea indica que el servicio en cuestión estará activo en los niveles de ejecución 2, 3, 4 y 5, y comenzará en 8 y se detendrá en 92. Cualquier cosa con un mayor valor de "inicio" comenzará solo después de que este script se complete, pero este error de secuencia de comandos se considera una finalización y no impedirá que se ejecuten secuencias de comandos posteriores.

Tenga en cuenta que esta respuesta se aplica a CentOS 6 y versiones anteriores, no necesariamente a CentOS 7. No he investigado personalmente 7 lo suficiente como para responder a esta pregunta para 7.

John
fuente

+1 Y ... no mirar un caballo de regalo en la boca, porque tu respuesta es bastante útil, pero ... ¿Sabrías alguna forma estándar de dar a los servicios una orden de dependencia, de modo que si uno falla? temprano en la cadena no comienzan las posteriores? Ooh, y también, si alguien logra bloquear el firewall (de alguna manera), ¿la interfaz de red "fallará con el barco"? Idealmente, me gustaría que todo fallara a salvo, incluso en el caso de que alguien tenga 0 días para hacer el firewall ...

Parthian Shot

Con los scripts de inicio de SysV (es decir, CentOS 6 y versiones anteriores), no hay una buena manera de hacerlo. CentOS 7 hace las dependencias que desee: si B depende de A y A falla, B no se inicia. Para 7, para ver el uso de dependencias systemctl list-dependencies --all(acabo de mirar la página del manual de hace 30 segundos)

John

Si bien esa noticia es un poco decepcionante (estoy en 6 en este momento), al menos ahora sé que modificar los scripts de inicio es un truco aceptablemente horrible.

Parthian Shot

Tenga mucho cuidado al modificar los scripts de inicio, ya que esto puede provocar falsas alarmas en cualquier software de detección de intrusos que pueda tener instalado, y las modificaciones se sobrescribirán si el initscriptspaquete se actualiza alguna vez (por ejemplo, una versión de erratas). Realmente no recomiendo hacer eso.

John

Todavía no he configurado un IDS, por lo que las falsas alarmas no son un problema en este momento (el servidor aún no está en funcionamiento y sé que no estoy listo para implementarlo; esta pregunta es parte de mi preparación). Pero voy a poner un HIDS). Seré lo más cuidadoso posible, y si hay una forma que no implique modificar manualmente las partes centrales de la configuración de init, definitivamente lo haré.

Parthian Shot

También puede usar la opción ifup-post en centos:

/ etc / sysconfig / network-scripts / ifup-post

Se llama cuando aparece cualquier dispositivo de red EXCEPTO un dispositivo SLIP. Llama a / etc / sysconfig / network-scripts / ifup-routes para mostrar rutas estáticas que dependen de ese dispositivo. Llama a / etc / sysconfig / network-scripts / ifup-aliases para mostrar los alias de ese dispositivo. Establece el nombre de host si aún no está configurado y se puede encontrar un nombre de host para la IP de ese dispositivo. Envía SIGIO a cualquier programa que haya solicitado notificación de eventos de red.

Podría extenderse para arreglar la configuración del servicio de nombres, llamar a scripts arbitrarios, etc., según sea necesario.

Este script se ejecuta y después de lo anterior (ifup-route y ifup-aliases) busca ifup-local

if [ -x /sbin/ifup-local ]; then
   /sbin/ifup-local ${DEVICE}
fi

Entonces puede crear este archivo y asegurarse de que vuelva a llamar a iptables, por ejemplo, usando iptables-restore:

iptables-restore < /etc/sysconfig/iptables

Moti
fuente

Un pequeño apéndice: para asegurarse de que las reglas necesarias estarán allí la próxima vez que inicie el servidor, guárdelo con

sudo sh -c "iptables-save > /etc/iptables.rules"

manu
fuente