¿Por qué debería firewall servidores?


104

TENGA EN CUENTA: ¡ No estoy interesado en convertir esto en una guerra de llamas! Entiendo que muchas personas tienen fuertes creencias sobre este tema, en gran parte porque han puesto mucho esfuerzo en sus soluciones de firewall y también porque han sido adoctrinados para creer en su necesidad.

Sin embargo, estoy buscando respuestas de personas expertas en seguridad. Creo que esta es una pregunta importante, y la respuesta se beneficiará más que solo a mí y a la empresa para la que trabajo. He estado ejecutando nuestra red de servidores durante varios años sin compromiso, sin ningún tipo de firewall. Ninguno de los compromisos de seguridad que hemos tenido se podría haber evitado con un firewall.

Creo que he estado trabajando aquí demasiado tiempo, porque cuando digo "servidores", siempre me refiero a "servicios ofrecidos al público", no a "bases de datos de facturación internas secretas". Como tal, cualquier regla que podríamos tener en los servidores de seguridad tendrían que permitir el acceso a toda la Internet. Además, todos nuestros servidores de acceso público están en un centro de datos dedicado separado de nuestra oficina.

Alguien más hizo una pregunta similar, y mi respuesta fue votada en números negativos. Esto me lleva a creer que las personas que votaron en contra no entendieron realmente mi respuesta, o no entiendo la seguridad lo suficiente como para estar haciendo lo que estoy haciendo actualmente.

Este es mi enfoque para la seguridad del servidor:

  1. Siga las pautas de seguridad de mi sistema operativo antes de conectar mi servidor a Internet.

  2. Use contenedores TCP para restringir el acceso a SSH (y otros servicios de administración) a un pequeño número de direcciones IP.

  3. Monitoree el estado de este servidor con Munin . Y arregle los atroces problemas de seguridad inherentes a Munin-node en su configuración predeterminada.

  4. Nmap mi nuevo servidor (también antes de conectar mi servidor a Internet). Si tuviera que firewall este servidor, este debería ser el conjunto exacto de puertos a los que deberían restringirse las conexiones entrantes.

  5. Instale el servidor en la sala de servidores y asígnele una dirección IP pública.

  6. Mantenga el sistema seguro utilizando la función de actualizaciones de seguridad de mi sistema operativo.

Mi filosofía (y la base de la pregunta) es que una fuerte seguridad basada en el host elimina la necesidad de un firewall. La filosofía de seguridad general dice que aún se requiere una fuerte seguridad basada en el host, incluso si tiene un firewall (consulte las pautas de seguridad ). La razón de esto es que un firewall que reenvía servicios públicos a un servidor permite a un atacante tanto como ningún firewall. Es el servicio en sí el que es vulnerable, y dado que ofrecer ese servicio a Internet es un requisito de su funcionamiento, restringir el acceso a él no es el punto.

Si no hay puertos disponibles en el servidor que no necesitan ser visitada por toda la Internet, a continuación, que el software necesita ser cerrado en el paso 1, y fue verificado por el paso 4. En caso de que un atacante romper con éxito en el servidor a través de software vulnerable y abren un puerto ellos mismos, el atacante puede (y lo hace) derrotar fácilmente cualquier cortafuegos haciendo una conexión saliente en un puerto aleatorio. El objetivo de la seguridad no es defenderse después de un ataque exitoso, lo que ya se ha demostrado que es imposible, sino mantener a los atacantes en primer lugar.

Se ha sugerido que hay otras consideraciones de seguridad además de los puertos abiertos, pero para mí eso suena como defender la fe de uno. Cualquier vulnerabilidad del sistema operativo / pila TCP debería ser igualmente vulnerable, ya sea que exista o no un firewall, en función del hecho de que los puertos se reenvían directamente a ese sistema operativo / pila TCP. Del mismo modo, ejecutar su firewall en el servidor en lugar de tenerlo en el enrutador (o peor, en ambos lugares) parece estar agregando capas innecesarias de complejidad. Entiendo la filosofía "la seguridad viene en capas", pero llega un punto en el que es como construir un techo apilando X número de capas de madera contrachapada una encima de la otra y luego perforando un agujero a través de todas ellas. Otra capa de madera contrachapada no va a detener las fugas a través de ese agujero.

Para ser honesto, la única forma en que veo que un firewall es útil para los servidores es si tiene reglas dinámicas que impiden todas las conexiones a todos los servidores de atacantes conocidos, como los RBL para el correo no deseado (que casualmente es más o menos lo que hace nuestro servidor de correo) . Desafortunadamente, no puedo encontrar ningún firewall que haga eso. La siguiente mejor opción es un servidor IDS, pero eso supone que el atacante no ataca primero a sus servidores reales y que los atacantes se molestan en probar toda su red antes de atacar. Además, se sabe que producen grandes cantidades de falsos positivos.


2
¿Y todo el tráfico que pasa entre sus servidores está encriptado?
GregD

55
Quiéralo. Las reglas de firewall locales son casi siempre solo vudú.
unixtippse

2
¿También tiene computadoras de escritorio / empleados en su red? ¿Qué haces con ellos?
Brandon el

8
Esta pregunta habría sido adecuada para security.stackexchange.com
Olivier Lalonde

2
@routeNpingme: Parece que no incluí ese dato en mi publicación original. Todos nuestros servidores deben estar abiertos al público y vivir en un centro de datos dedicado. Si su oficina es su centro de datos, supongo que sería necesario tener un firewall entre la red de su servidor y la red de su oficina. En cuyo caso, estoy hablando de la red del servidor: ¿por qué firewall algo que tiene acceso público completo?
Ernie

Respuestas:


54

Ventajas del firewall:

  1. Puede filtrar el tráfico saliente.
  2. Los firewalls de capa 7 (IPS) pueden proteger contra vulnerabilidades de aplicaciones conocidas.
  3. Puede bloquear un determinado rango de direcciones IP y / o puerto centralmente en lugar de tratar de asegurarse de que no haya servicio escuchando en ese puerto en cada máquina individual o denegando el acceso mediante TCP Wrappers .
  4. Los firewalls pueden ayudar si tiene que lidiar con usuarios / administradores menos conscientes de la seguridad, ya que proporcionarían una segunda línea de defensa. Sin ellos, uno debe estar absolutamente seguro de que los hosts son seguros, lo que requiere una buena comprensión de seguridad por parte de todos los administradores.
  5. Los registros de firewall proporcionarían registros centrales y ayudarían a detectar escaneos verticales. Los registros de firewall pueden ayudar a determinar si algún usuario / cliente intenta conectarse periódicamente al mismo puerto de todos sus servidores. Para hacer esto sin un servidor de seguridad, habría que combinar registros de varios servidores / hosts para obtener una vista centralizada.
  6. Los firewalls también vienen con módulos anti-spam / antivirus que también se suman a la protección.
  7. Sistema operativo de seguridad independiente. Basado en el sistema operativo host, se requieren diferentes técnicas / métodos para asegurar el host. Por ejemplo, TCP Wrappers puede no estar disponible en máquinas con Windows.

Sobre todo esto, si no tiene firewall y el sistema está comprometido, ¿cómo lo detectaría? Intentar ejecutar algún comando 'ps', 'netstat', etc. en el sistema local no es confiable ya que esos binarios pueden ser reemplazados. 'nmap' de un sistema remoto no garantiza la protección, ya que un atacante puede garantizar que el kit raíz acepte conexiones solo desde las direcciones IP de origen seleccionadas en los momentos seleccionados.

Los cortafuegos de hardware ayudan en tales escenarios, ya que es extremadamente difícil cambiar el sistema operativo / archivos del servidor de seguridad en comparación con los sistemas operativos / archivos host.

Desventajas del firewall:

  1. La gente siente que el firewall se encargará de la seguridad y no actualizará los sistemas regularmente y detendrá los servicios no deseados.
  2. Cuestan. A veces, se debe pagar una tarifa de licencia anual. Especialmente si el cortafuegos tiene módulos antivirus y antispam.
  3. Punto único adicional de falla. Si todo el tráfico pasa a través de un firewall y el firewall falla, la red se detendrá. Podemos tener firewalls redundantes, pero luego el punto anterior sobre el costo se amplifica aún más.
  4. El seguimiento con estado no proporciona valor en los sistemas públicos que aceptan todas las conexiones entrantes.
  5. Los firewalls con estado son un cuello de botella masivo durante un ataque DDoS y a menudo son lo primero que falla, porque intentan mantener el estado e inspeccionar todas las conexiones entrantes.
  6. Los cortafuegos no pueden ver el tráfico cifrado en su interior. Dado que todo el tráfico debe estar encriptado de extremo a extremo, la mayoría de los firewalls agregan poco valor frente a los servidores públicos. Algunos firewalls de próxima generación pueden recibir claves privadas para terminar TLS y ver dentro del tráfico, sin embargo, esto aumenta aún más la susceptibilidad del firewall a DDoS y rompe el modelo de seguridad de extremo a extremo de TLS.
  7. Los sistemas operativos y las aplicaciones se corrigen contra vulnerabilidades mucho más rápidamente que los firewalls. Los proveedores de firewall a menudo se sientan en problemas conocidos durante años sin parches, y parchear un clúster de firewall generalmente requiere tiempo de inactividad para muchos servicios y conexiones salientes.
  8. Los cortafuegos están lejos de ser perfectos, y muchos son notoriamente defectuosos. Los cortafuegos son solo software que se ejecuta en algún tipo de sistema operativo, tal vez con un ASIC o FPGA adicional además de una CPU (generalmente lenta). Los cortafuegos tienen errores, pero parecen proporcionar pocas herramientas para abordarlos. Por lo tanto, los firewalls agregan complejidad y una fuente adicional de errores difíciles de diagnosticar a una pila de aplicaciones.

66
Above all this if you do not have firewall and system is compromised then how would you detect it?La detección de intrusiones no es el trabajo del firewall. Ese trabajo lo maneja más adecuadamente el HIDS (sistema de detección de intrusos basado en el host), que es independiente del firewall.
Steven lunes

66
Los servidores de Syslog eliminan la necesidad del elemento 5. En todo caso, es mejor enviar los registros de su firewall a un servidor de Syslog, en caso de que un atacante logre comprometer el firewall y eliminar sus registros. Luego, el atacante debe comprometer dos sistemas solo para eliminar los registros, y es posible que no estén preparados para eso (especialmente con ataques automáticos). Del mismo modo, si todos sus sistemas tienen un registro centralizado, obtendrá mejores detalles sobre el ataque que los registros de firewall pueden proporcionar.
Ernie

2
Mi punto era que como HIDS reside en el host, no podemos confiar en su salida. Por ejemplo, incluso si usamos 'tripwire' criptográficamente seguro como IDS basado en host, el atacante siempre puede reemplazar todos los binarios de tripwire (twadmin, tripwire, twprint, etc.) con versiones comprometidas que nunca reportarán intrusiones. Incluso si tratamos de copiar bibliotecas / archivos binarios de otro sistema, puede haber un proceso en ejecución que supervise estos archivos binarios comprometidos y los reemplace nuevamente con una versión dañada en caso de que sean reemplazados o actualizados. El firewall es independiente del host y se puede confiar en tales escenarios.
Saurabh Barjatiya

2
Esta respuesta fue aceptada sobre la más popular porque proporciona un conjunto de razones mejor y más completo para usar un firewall. Y no, para el caso.
Ernie

Los firewalls de inspección de paquetes con estado NO pertenecen a los servidores. Son una gran responsabilidad en los ataques DDoS y, por lo general, son lo primero en fallar bajo ataque.
rmalayter

33

TCP Wrappers podría llamarse una implementación de firewall basada en host; Estás filtrando el tráfico de red.

Para el punto en el que un atacante realiza conexiones salientes en un puerto arbitrario, un firewall también proporcionaría un medio para controlar el tráfico saliente; Un cortafuegos configurado correctamente gestiona la entrada y la salida de forma adecuada al riesgo relacionado con el sistema.

En cuanto a cómo un firewall no mitiga ninguna vulnerabilidad de TCP, no está familiarizado con el funcionamiento de los firewalls. Cisco tiene un montón de reglas disponibles para descargar que identifican los paquetes construidos de una manera que causaría problemas particulares en los sistemas operativos. Si agarras Snort y comienzas a ejecutarlo con el conjunto de reglas correcto, también recibirás una alerta sobre este tipo de cosas. Y, por supuesto, las iptables de Linux pueden filtrar paquetes maliciosos.

Básicamente, un firewall es una protección proactiva. Cuanto más te alejes de ser proactivo, más probable es que te encuentres en una situación en la que estás reaccionando a un problema en lugar de prevenirlo. Concentrar su protección en la frontera, como con un firewall dedicado, hace que las cosas sean más fáciles de administrar porque tiene un punto de estrangulamiento central en lugar de duplicar las reglas en todas partes.

Pero ninguna cosa es necesariamente una solución final. Una buena solución de seguridad generalmente es de múltiples capas, donde tiene un firewall en el borde, envoltorios TCP en el dispositivo y probablemente también algunas reglas en enrutadores internos. Por lo general, debe proteger la red de Internet y proteger los nodos entre sí. Este enfoque de múltiples capas no es como perforar un agujero a través de múltiples láminas de madera contrachapada, es más como colocar un par de puertas para que un intruso tenga dos cerraduras que romper en lugar de una sola; Esto se llama trampa de hombre en seguridad física, y la mayoría de los edificios tienen una por una razón. :)


66
Además, si se escabullen dentro del edificio y abren la puerta interior de su amigo afuera, también tienen que desbloquear y abrir la puerta exterior. (es decir, sin un firewall externo, alguien que ingrese a su servidor puede abrirlo de inmediato, mientras que un firewall externo aún bloquearía los puertos abiertos desde el exterior)
Ricket

@Ricket: Tal vez podrían, pero los atacantes modernos no se molestan con cosas como esta. Su sitio tendría que ser de particular interés para que un atacante haga algo más que agregar su servidor a una granja de zombis.
Ernie

1
@Ernie: no, solo tiene que existir para que se pruebe automáticamente el espacio libre para Warez, las bases de datos de clientes, la información financiera, las contraseñas y se agregue a una botnet, pero incluso eso puede ser lo suficientemente malo, algunos administradores felizmente bloquearán su IP si parece que albergas zombies.
Rory Alsop

TCP Wrappers could be arguably called a host-based firewall implementation+1 para una gran respuesta.
sjas

15

(Es posible que desee leer "La vida sin cortafuegos ")

Ahora: ¿Qué pasa con tener un sistema heredado para el que ya no se publican parches? ¿Qué pasa con no poder aplicar los parches a las máquinas N en el momento en que necesita hacerlo, mientras que al mismo tiempo puede aplicarlos en menos nodos en la red (firewalls)?

No tiene sentido debatir la existencia o la necesidad del firewall. Lo que realmente importa es que debe implementar una política de seguridad. Para hacerlo, utilizará cualquier herramienta que lo implemente y lo ayude a administrarlo, expandirlo y evolucionarlo. Si se necesitan firewalls para hacerlo, está bien. Si no son necesarios, también está bien. Lo que realmente importa es tener una implementación funcional y verificable de su política de seguridad.


1
Je He estado ejecutando nuestra red de servidores durante los últimos 8 años sin un firewall. Podría haber escrito "La vida sin cortafuegos", pero hizo un trabajo mucho mejor y, de todos modos, dirige una red mucho más grande que yo.
Ernie

2
@ Ernie - Supongo que podrías haber tenido suerte. ¿Cómo sabes que no has sido comprometido? Los resultados de las investigaciones forenses en muchos de mis clientes han descubierto un compromiso, a veces desde hace meses, mientras que los atacantes encontraron información personal y financiera, detalles del cliente, propiedad intelectual, planes de negocios, etc. Como dijo Sean, realice una auditoría de seguridad adecuada.
Rory Alsop

1
En realidad, aparte del hecho de que nuestra red de servidores está físicamente separada de la red de nuestra oficina (y, por lo tanto, no se pueden obtener datos realmente confidenciales, incluso con acceso de root en cada servidor), he podido descubrir cada compromiso que Lo he tenido desde que empecé aquí. Podría continuar sobre el espectáculo de terror que existía cuando comencé, pero no tengo suficiente espacio. :) Baste decir que la mayoría de los ataques no son sutiles, y los sutiles también son reconocibles. Ah sí, y la separación de privilegios de usuario es tu amigo.
Ernie

9

La mayoría de sus explicaciones parecen refutar la necesidad de un firewall, pero no veo una desventaja de tener uno, aparte del poco tiempo para configurarlo.

Pocas cosas son una "necesidad" en un sentido estricto de la palabra. La seguridad se trata más de configurar todos los bloqueos que puedas. Cuanto más trabajo se necesita para entrar en su servidor, menos posibilidades hay de un ataque exitoso. Desea que sea más difícil entrar en sus máquinas que en otro lugar. Agregar un firewall hace más trabajo.

Creo que un uso clave es la redundancia en seguridad. Otra ventaja de los firewalls es que simplemente puede abandonar los intentos de conectarse a cualquier puerto en lugar de responder a las solicitudes rechazadas; esto hará que nmapping sea un poco más incómodo para un atacante.

Lo más importante para mí en la nota práctica de su pregunta es que puede bloquear SSH, ICMP y otros servicios internos en subredes locales, así como limitar las conexiones entrantes de límite de velocidad para ayudar a aliviar los ataques de DOS.

"El objetivo de la seguridad no es defenderse después de un ataque exitoso, lo que ya se ha demostrado que es imposible, es mantener a los atacantes fuera en primer lugar".

Estoy en desacuerdo. Limitar los daños puede ser igual de importante. (¿bajo este ideal por qué las contraseñas hash? ¿o pegar el software de su base de datos en un servidor diferente al de sus aplicaciones web?) Creo que el viejo dicho "No pegue todos sus huevos en una canasta" es aplicable aquí.


1
Bueno, tienes razón, no puse ninguna desventaja allí. Contras: aumento de la complejidad de la red, punto único de falla, interfaz de red única a través de la cual se bloquea el ancho de banda. Del mismo modo, los errores administrativos cometidos en un firewall pueden matar toda su red. Y los dioses prohíben que te bloquees mientras estás en un viaje de 20 minutos a la sala de servidores.
Ernie

1
Esto puede ser puramente retórico, pero cuando dice "La seguridad se trata más de configurar todos los bloqueos que pueda", preferiría escuchar "La seguridad se trata más de bloquear todo de manera predeterminada y abrir cuidadosamente el mínimo estricto para operar".
MatthieuP

+1 Un plan de seguridad integral cubre la prevención, detección y respuesta.
Jim OHalloran el

8

Should I firewall my server?Buena pregunta. Parece que no tiene mucho sentido colocar un cortafuegos en la parte superior de una pila de red que ya rechaza los intentos de conexión a todos menos a un puñado de puertos que están legítimamente abiertos. Si existe una vulnerabilidad en el sistema operativo que permite que los paquetes creados con fines malintencionados interrumpan / exploten un host, ¿un firewall que se ejecute en ese mismo host evitará la explotación? Bueno, tal vez ...

Y esa es probablemente la razón más sólida para ejecutar un firewall en cada host: un firewall podría evitar que se aproveche una vulnerabilidad de la pila de red. ¿Es esa una razón suficientemente fuerte? No lo sé, pero supongo que se podría decir: "Nadie fue despedido por instalar un firewall".

Otra razón para ejecutar un firewall en un servidor es desacoplar estas dos preocupaciones, por lo demás, fuertemente correlacionadas:

  1. ¿Desde dónde y a qué puertos, acepto conexiones?
  2. ¿Qué servicios están ejecutando y escuchando conexiones?

Sin un cortafuegos, el conjunto de servicios que se ejecutan (junto con las configuraciones para tcpwrappers y demás) determina completamente el conjunto de puertos que el servidor tendrá abiertos y de quién se aceptarán las conexiones. Un servidor de seguridad basado en host le brinda al administrador flexibilidad adicional para instalar y probar nuevos servicios de manera controlada antes de hacerlos más ampliamente disponibles. Si no se requiere dicha flexibilidad, entonces hay menos razones para instalar un firewall en un servidor.

En una nota final, hay un elemento que no menciono en su lista de verificación de seguridad que siempre agrego, y es un sistema de detección de intrusos basado en host (HIDS), como AIDE o samhain . Un buen HIDS hace que sea extremadamente difícil para un intruso realizar cambios no deseados en el sistema y permanecer sin ser detectado. Creo que todos los servidores deberían estar ejecutando algún tipo de HIDS.


1
+1 para mencionar los sistemas HIDS.
Sam Halicke el

3
HIDS son geniales: si tiene la intención de configurarlo y olvidarlo. Y nunca agregue o elimine cuentas. De lo contrario, la gran mayoría de los registros de HIDS serán largas listas de lo que hiciste hoy, y rápidamente terminarán siendo ignorados todo el tiempo.
Ernie

Sin dolor, sin ganancia, como dicen. En servidores con muchos cambios, es posible filtrar el ruido esperado, dejándolo concentrado en lo inesperado.
Steven lunes

6

Un firewall es una herramienta. No hace que las cosas sean seguras en sí mismas, pero puede hacer una contribución como capa en una red segura. Eso no significa que necesite uno, y ciertamente me preocupo por las personas que ciegamente dicen "Tengo que obtener un firewall" sin entender por qué piensan de esa manera y que no entienden las fortalezas y debilidades de los firewalls.

Hay muchas herramientas que podemos decir que no necesitamos ... ¿Es posible ejecutar una computadora con Windows sin antivirus? Sí, lo es ... pero es una buena capa de seguro tener uno.

Yo diría lo mismo sobre los firewalls; lo que sea que pueda decir sobre ellos, son un buen nivel de seguro. No son un sustituto de los parches, el bloqueo de máquinas, la desactivación de servicios que no utiliza, el registro, etc., pero pueden ser un complemento útil.

También sugiero que la ecuación cambie un poco dependiendo de si estás hablando de colocar un firewall frente a un grupo de servidores cuidadosamente atendidos, como parece ser, o una LAN típica con una combinación de estaciones de trabajo y servidores , algunos de los cuales podrían estar ejecutando algunas cosas bastante peludas a pesar de los mejores esfuerzos y deseos del equipo de TI.

Una cosa más a considerar es el beneficio de crear un objetivo obviamente endurecido. Seguridad visible, ya sean luces brillantes, cerraduras pesadas y una caja de alarma obvia en un edificio; o un obvio cortafuegos en el rango de direcciones IP de una empresa puede disuadir al intruso casual: buscarán presas más fáciles. Esto no disuadirá al intruso determinado que sabe que tiene información que quiere y está decidida a obtenerla, pero vale la pena disuadir a los intrusos ocasionales, especialmente si sabe que cualquier intruso cuyas sondas persisten más allá del elemento disuasorio debe tomarse especialmente en serio. .


1
Entonces, ¿la razón por la que dije "servidores" en lugar de "red de oficina"? :) En nuestro caso especialmente, el centro de datos y la oficina son dos entidades físicamente separadas.
Ernie

Entiendo que Ernie, pero es un punto que vale la pena subrayar ... así que lo hice.
Rob Moir

5

Todas buenas preguntas. PERO - Estoy muy sorprendido de que el RENDIMIENTO no haya sido llevado a la mesa.

Para los front-end web altamente utilizados (en términos de CPU), el firewall local realmente degrada el rendimiento, punto. Pruebe una prueba de carga y vea. Lo vi toneladas de veces. Desactivar el firewall aumentó el rendimiento (solicitud por segundo) en un 70% o más.

Esta compensación debe ser considerada.


2
Depende mucho de las reglas de firewall establecidas. Las reglas de firewall se ejecutan secuencialmente en cada paquete, por lo que no desea tener cientos de reglas que deben observarse. El invierno pasado, cuando administramos un sitio que tenía un anuncio en el superbowl, las reglas de firewall no eran un problema, por ejemplo. Pero sí estoy de acuerdo en que debe comprender el impacto en el rendimiento de las reglas de firewall.
Sean Reifschneider

4

Un firewall es protección adicional. Tres escenarios particulares contra los que protege son los ataques de pila de red (es decir, el sistema operativo de su servidor tiene una vulnerabilidad en los paquetes especialmente diseñados que nunca alcanzan el nivel de puertos), una intrusión exitosa que hace una conexión al "teléfono a casa" (o envía spam, o lo que sea ), o una intrusión exitosa abriendo un puerto del servidor o, menos detectable, observe una secuencia de interrupción del puerto antes de abrir un puerto. Por supuesto, los dos últimos tienen que ver con mitigar el daño de una intrusión en lugar de prevenirla, pero eso no significa que sea inútil. Recuerde que la seguridad no es una propuesta de todo o nada; uno adopta un enfoque en capas, cinturón y tirantes, para lograr un nivel de seguridad que sea suficiente para sus necesidades.


+1 Absolutamente, la defensa en profundidad es clave.
Jim OHalloran el

2
No veo cómo puedo tener alguna expectativa de bloquear el tráfico saliente para algún efecto, especialmente cuando nuestros clientes esperan que muchos de nuestros servidores envíen correo a hosts aleatorios en Internet (como es el caso del correo no deseado). "Llamar a casa" es solo una cuestión de conectarse a algún otro host aleatorio en la red, y dudo que bloquear todas las conexiones salientes, salvo por unos pocos, ayude en algo, es decir, si desea hacer algo en Internet. Y bloquear solo unos pocos puertos es como montar una caseta de peaje en medio del desierto.
Ernie

3

No soy un experto en seguridad de ninguna manera, pero parece que estás protegido por firewall. Parece que ha tomado parte de la funcionalidad central de un firewall y lo ha incluido en sus políticas y procedimientos. No, no necesita un firewall si va a hacer el mismo trabajo que un firewall usted mismo. En cuanto a mí, prefiero hacer lo mejor que pueda para mantener la seguridad, pero tener un firewall mirando por encima de mi hombro, pero en algún momento cuando puedes hacer todo lo que el firewall está haciendo, comienza a ser irrelevante.


3

Ciertamente, no se necesita un firewall para configuraciones más pequeñas. Si tiene uno o dos servidores, los firewalls de software son mantenibles. Dicho esto, no ejecutamos sin firewalls dedicados, y hay algunas razones por las que mantengo esta filosofía:

Separación de roles

Los servidores son para aplicaciones. Los cortafuegos son para inspección, filtrado y políticas de paquetes. Un servidor web debería preocuparse por servir páginas web, y eso es todo. Poner ambos roles en un solo dispositivo es como pedirle a su contador que también sea su guardia de seguridad.

El software es un objetivo en movimiento

El software en el host siempre está cambiando. Las aplicaciones pueden crear sus propias excepciones de firewall. El sistema operativo se actualiza y parchea. Los servidores son un área de "administración" de alto tráfico, y sus políticas de firewall / políticas de seguridad a menudo son mucho más importantes para la seguridad que las configuraciones de sus aplicaciones. En un entorno de Windows, suponga que alguien comete un error en algún nivel de Política de grupo y apaga el Firewall de Windows en las PC de escritorio, y no se da cuenta de que se aplicará a los servidores. Estás completamente abierto en cuestión de clics.

Simplemente hablando de actualizaciones, las actualizaciones de firmware del firewall generalmente salen una o dos veces al año, mientras que las actualizaciones del sistema operativo y del servicio son un flujo constante.

Servicios / políticas / reglas reutilizables, manejabilidad

Si configuro un servicio / política llamado "Servidor web" una vez (digamos TCP 80 y TCP 443), y lo aplico al "grupo de servidores web" en el nivel de firewall, eso es mucho más eficiente (un par de cambios de configuración) y exponencialmente menos propenso a errores humanos que configurar servicios de firewall en 10 cajas y abrir 2 puertos x 10 veces. Cuando esa política necesita cambiar, es 1 cambio vs. 10.

Todavía puedo administrar un firewall durante un ataque o después de un compromiso

Digamos que mi servidor de aplicaciones de firewall + host está siendo atacado y la CPU está fuera del gráfico. Incluso para comenzar a descubrir qué está sucediendo, estoy a merced de que mi carga sea menor que la del atacante para siquiera entrar y mirarlo.

Una experiencia real: una vez estropeé una regla de firewall (dejé puertos a CUALQUIER lugar en lugar de uno específico, y el servidor tenía un servicio vulnerable), y el atacante realmente tenía una sesión de Escritorio remoto en vivo. Cada vez que comenzaba a tener una sesión, el atacante mataba / desconectaba mi sesión. Si no fuera por poder apagar ese ataque desde un dispositivo de firewall independiente, eso podría haber sido mucho peor.

Monitoreo independiente

El registro en unidades de firewall dedicadas suele ser muy superior a los firewalls de software basados ​​en host. Algunos son lo suficientemente buenos como para que ni siquiera necesite un software de monitoreo externo SNMP / NetFlow para obtener una imagen precisa.

Conservación de IPv4

No hay razón para tener dos direcciones IP si una es para web y otra para correo. Mantenga los servicios en cajas separadas y enrute los puertos adecuadamente a través del dispositivo diseñado para hacerlo.


2

Blockquote Bueno, tienes razón, no puse ninguna desventaja allí. Contras: aumento de la complejidad de la red, punto único de falla, interfaz de red única a través de la cual se bloquea el ancho de banda Del mismo modo, los errores administrativos cometidos en un firewall pueden matar toda su red. Y los dioses prohíben que te bloquees mientras estás en un viaje de 20 minutos a la sala de servidores.

Primero, agregar como máximo un salto enrutado adicional a través de su red no es complejo. En segundo lugar, ninguna solución de firewall implementada con ningún punto único de falla es completamente inútil. Al igual que agrupa su servidor o servicios importantes y utiliza NIC enlazadas, implementa firewalls de alta disponibilidad. No hacerlo, o no reconocer y saber que lo harías es muy miope. Simplemente declarar que hay una única interfaz no convierte automáticamente algo en un cuello de botella. Esa afirmación muestra que no tiene idea de cómo planificar e implementar adecuadamente un firewall dimensionado para manejar el tráfico que fluiría a través de su red. Tiene razón al decir que un error en la política puede causar daños a toda su red, pero yo diría que mantener políticas individuales en todos sus servidores es mucho más propenso a errores que un solo lugar.

En cuanto al argumento de que se mantiene al día con los parches de seguridad y sigue las guías de seguridad; ese es un argumento inestable en el mejor de los casos. Por lo general, los parches de seguridad no están disponibles hasta que se descubre una vulnerabilidad. Eso significa que todo el tiempo que esté ejecutando servidores dirigibles públicamente son vulnerables hasta que se reparen. Como otros han señalado, los sistemas IPS pueden ayudar a prevenir compromisos de tales vulnerabilidades.

Si cree que sus sistemas son lo más seguros posible, es una buena confianza. Sin embargo, le recomiendo que realice una auditoría de seguridad profesional en su red. Puede que solo te abra los ojos.


It may just open your eyes.+1 ya que será el último clavo en el ataúd.
sjas

2

En general, la seguridad es una cuestión de cebolla, como ya se mencionó. Hay razones por las que existen cortafuegos, y no solo todos los otros lemmings son estúpidos imbéciles.

Esta respuesta viene, ya que la búsqueda de 'fail2ban' en esta página no me dio ningún resultado. Entonces, si doblo otro contenido, tengan paciencia conmigo. Y discúlpeme, si despotrico un poco, proporciono una experiencia sencilla, ya que esto podría ser útil para otros. :)

Consideraciones de redes, locales versus externas

Esto es más bien específico de Linux y se concentra en el firewall basado en host, que suele ser el caso de uso. El cortafuegos externo va de la mano con una estructura de red adecuada y otras consideraciones de seguridad generalmente entran en eso. O sabes lo que está implícito aquí, entonces es probable que no necesites esta publicación. O no, entonces sigue leyendo.

Ejecutar cortafuegos externa y localmente puede parecer contrario a la intuición y doble trabajo. Pero esto también da la posibilidad de cambiar las reglas en el externo, sin comprometer la seguridad de todos los demás hosts que están detrás. La necesidad podría surgir por razones de depuración o porque alguien acaba de joder. Otro caso de uso vendrá allí en la sección 'firewall global adaptativo', para el cual también necesitará firewalls locales y globales.

Costo y disponibilidad y la misma historia todo el tiempo:

El firewall es solo un aspecto de un sistema seguro adecuado. No instalar un firewall ya que 'cuesta' dinero, introduce un SPOF o lo que sea solo una mierda, perdón por mi francés aquí. Simplemente configure un clúster. Oh, pero ¿y si la celda de incendio tiene un corte de energía? Luego, configure su clúster en dos o más compartimentos contra incendios.

Pero, ¿qué sucede si no se puede acceder a todo el centro de datos, ya que ambos operadores externos están fuera del negocio (el excavador mató su fibra)? Simplemente haga que su clúster abarque varios centros de datos, entonces.

¿Eso es caro? Los grupos son demasiado complejos? Bueno, la paranoia tiene que pagarse.

Simplemente quejarse de SPOF, pero no querer pagar más dinero o crear configuraciones un poco más complejas es un caso claro de doble rasero o simplemente una pequeña billetera por parte de la empresa o el cliente.

Este patrón se aplica a TODAS estas discusiones, sin importar qué servicio sea el tema actual del día. No importa si se trata de una puerta de enlace VPN, un Cisco ASA se usa solo para firewall, una base de datos MySQL o PostgreSQL, un sistema virtual o hardware de servidor, un back-end de almacenamiento, conmutadores / enrutadores, ...

A estas alturas ya deberías tener la idea.

¿Por qué molestarse con cortafuegos?

En teoría su razonamiento es sólido. (Solo los servicios en ejecución pueden ser explotados).

Pero esto es solo la mitad de la verdad. El firewall, especialmente el firewall con estado, puede hacer mucho más por usted. Los firewalls sin estado solo son importantes si experimenta problemas de rendimiento como otros que ya se mencionaron.

Fácil, central, control de acceso discreto

Usted mencionó los contenedores TCP que implementan básicamente la misma funcionalidad para asegurar su. Por el bien del argumento, supongamos que alguien no sabe tcpdy le gusta usar un mouse. fwbuilderpodría venir a la mente.

Tener acceso completo desde su red de administración es algo que debería haber habilitado, que es algo de los primeros casos de uso de su firewall basado en host.

¿Qué tal una configuración multiservidor, donde la base de datos se ejecuta en otro lugar y no puede colocar ambas / todas las máquinas dentro de una subred compartida (privada) por cualquier razón? Use el firewall para permitir el acceso a MySQL en el puerto 3306 solo para la única dirección IP dada del otro servidor, hecho, simple.

Y eso también funciona perfectamente para UDP. O cualquier protocolo. Los cortafuegos pueden ser muy flexibles. ;)

Mitigación de Portscan

Además, con el firewall, se pueden detectar y mitigar los escaneos de puertos generales, ya que la cantidad de conexiones por intervalo de tiempo se puede monitorear a través del kernel y su pila de redes, y el firewall puede actuar sobre eso.

También se pueden manejar paquetes no válidos u oscuros antes de que lleguen a su aplicación.

Limitación de tráfico saliente

Filtrar el tráfico saliente suele ser un fastidio. Pero puede ser obligatorio, según el contrato.

Estadística

Otra cosa que un cortafuegos puede darle son las estadísticas. (Piense watch -n1 -d iptables -vnxL INPUTen haber agregado algunas reglas para direcciones IP especiales en la parte superior para ver si los paquetes están llegando).

Puede ver a plena luz del día si las cosas funcionan o no. Lo cual es MUY útil al solucionar problemas de conexiones y poder decirle a la otra persona por teléfono que no recibe paquetes, sin tener que recurrir a conversadores tcpdump. La creación de redes es divertida, la mayoría de las personas ahora saben lo que están haciendo y, a menudo, son simples errores de enrutamiento. Demonios, incluso yo no siempre sé lo que estoy haciendo. Aunque he trabajado literalmente con docenas de sistemas y dispositivos complejos, a menudo también con túneles.

IDS / IPS

El firewall de Layer7 generalmente es aceite de serpiente (IPS / IDS), si no se atiende correctamente y se actualiza regularmente. Además, las licencias son muy caras, por lo que ahorraría obtener una si no tiene la necesidad real de obtener todo lo que el dinero puede comprarle.

Masqerading

Fácil, solo intenta esto con tus envoltorios. :RE

Reenvío de puerto local

Ver disfraces.

Asegurar canales de acceso de contraseña con direcciones IP dinámicas

¿Qué pasa si los clientes tienen direcciones IP dinámicas y no hay una configuración de VPN implementada? ¿U otros enfoques dinámicos para el firewall? Esto ya se insinuó en la pregunta, y aquí vendrá un caso de uso para Desafortunadamente, no puedo encontrar ningún firewall que haga eso. parte.

Haber deshabilitado el acceso a la cuenta raíz a través de una contraseña es imprescindible. Incluso si el acceso está limitado a ciertas direcciones IP.

Además, tener otra cuenta blanko lista con un inicio de sesión con contraseña si se pierden las claves ssh o falla la implementación es muy útil si algo sale realmente mal (¿un usuario tiene acceso administrativo a la máquina y 'cosas sucedieron'?). Es la misma idea para el acceso a la red, ya que tener un modo de usuario único en Linux o usar init=/bin/bashvía grubpara acceso local es realmente malo y no puede usar un disco en vivo por cualquier razón. No se ría, hay productos de virtualización que lo prohíben. Incluso si existe la funcionalidad, ¿qué sucede si se ejecuta una versión de software desactualizada que carece de la funcionalidad?

De todos modos, incluso si ejecuta su ssh daemon en algún puerto esotérico y no en el 22, si no ha implementado cosas como el bloqueo de puertos (para abrir incluso otro puerto y mitigar escaneos de puertos, bordeando poco a poco ser demasiado poco práctico), los escaneos de puertos detectarán su servicio eventualmente.

Por lo general, también configura todos los servidores con la misma configuración, con los mismos puertos y servicios por razones de eficiencia. No puede configurar ssh en un puerto diferente en cada máquina. Además, no puede cambiarlo en todas las máquinas cada vez que considere que es información "pública", porque ya está después de un escaneo. La cuestión de nmapser legal o no no es un problema al tener una conexión Wi-Fi pirateada a su disposición.

Si esta cuenta no se llama 'root', es posible que las personas no puedan adivinar el nombre de cuenta de usuario de su 'puerta trasera'. Pero lo sabrán, si obtienen otro servidor de su empresa, o simplemente compran un espacio web, y tienen una mirada sin raíz / sin encerrar / sin contención /etc/passwd.

Para una ilustración puramente teórica ahora, podrían usar un sitio web pirateable allí para obtener acceso a su servidor y buscar cómo se ejecutan las cosas en su lugar. Es posible que sus herramientas de búsqueda de pirateo no se ejecuten las 24 horas del día, los 7 días de la semana (por lo general, ¿lo hacen por la noche por razones de rendimiento del disco para los análisis del sistema de archivos?) Y sus escáneres de virus no se actualizan en el segundo en que un nuevo día cero ve la luz del día, por lo que lo hará no detecte estos sucesos de inmediato, y sin otras medidas de protección, es posible que nunca sepa lo que sucedió. Para volver a la realidad, si alguien tiene acceso a exploits de día cero, es muy probable que no apunte a sus servidores de todos modos, ya que estos son simplemente caros. Esto es solo para ilustrar que siempre hay una forma de entrar en un sistema si surge la 'necesidad'.

Pero sobre el tema nuevamente, ¿simplemente no use una cuenta adicional con contraseña y no se moleste? Por favor sigue leyendo.

Incluso si los atacantes obtienen el nombre y el puerto de esta cuenta adicional, una combinación fail2ban+ iptableslos detendrá, incluso si usó solo una contraseña de ocho letras. Además, fail2ban también se puede implementar para otros servicios, ampliando el horizonte de monitoreo.

Para sus propios servicios, si alguna vez surgió la necesidad: Básicamente, todas las fallas de registro de servicios en un archivo pueden obtener soporte de fail2ban mediante la provisión de un archivo, qué expresiones regulares deben coincidir y cuántas fallas están permitidas, y el firewall bloqueará felizmente cada dirección IP. se le dice que lo haga.

¡No estoy diciendo que use contraseñas de 8 dígitos! Pero si se les prohíbe durante 24 horas por cinco intentos de contraseña incorrecta, puede adivinar cuánto tiempo tendrán que intentarlo si no tienen una botnet a su disposición, incluso con una seguridad tan pésima. Y se sorprendería de las contraseñas que los clientes tienden a usar, no solo para ssh. Echar un vistazo a las contraseñas de correo de las personas a través de Plesk le dice todo lo que preferiría no querer saber, si alguna vez lo hace, pero lo que no estoy tratando de implicar aquí, por supuesto. :)

Cortafuegos global adaptativo

fail2banes solo una aplicación que usa algo similar iptables -I <chain_name> 1 -s <IP> -j DROP, pero puedes construir fácilmente esas cosas tú mismo con algo de magia Bash bastante rápido.

Para ampliar aún más algo como esto, agregue todas las direcciones IP fail2ban de los servidores dentro de su red en un servidor adicional, que conserva todas las listas y las pasa a su vez a los firewalls centrales que bloquean todo el tráfico que ya está en el borde de su red.

Dicha funcionalidad no puede venderse (por supuesto que sí, pero será un sistema frágil y apestará), pero debe entrelazarse con su infraestructura.

Mientras lo hace, también puede usar direcciones IP de listas negras o listas de otras fuentes, ya sea agregadas por usted mismo o externas.


1

En el mundo físico, las personas aseguran sus objetos de valor poniéndolos en cajas fuertes. Pero no hay una caja fuerte que no pueda ser forzada. Las cajas fuertes, o contenedores de seguridad, se clasifican en términos de cuánto tiempo lleva forzar la entrada. El propósito de la caja fuerte es retrasar al atacante el tiempo suficiente para que sean detectados y las medidas activas luego detengan el ataque.

Del mismo modo, la suposición de seguridad adecuada es que sus máquinas expuestas eventualmente se verán comprometidas. Los firewalls y los hosts de bastión no están configurados para evitar que su servidor (con sus datos valiosos) se vea comprometido, sino para obligar a un atacante a comprometerlos primero y permitirle detectar (y disuadir) el ataque antes de que se pierdan los objetos de valor.

Tenga en cuenta que ni los firewalls ni las bóvedas bancarias protegen contra las amenazas internas. Esa es una razón para que los contadores bancarios tomen dos semanas de licencia consecutivas, y para que los servidores tengan todas las precauciones de seguridad internas a pesar de estar protegidos por los servidores del bastión.

Parece implicar en la publicación original que está reenviando paquetes del "mundo exterior" a través de su firewall directamente a su servidor. En ese caso, sí, su firewall no está haciendo mucho. Se realiza una mejor defensa del perímetro con dos cortafuegos y un host de bastión, donde no hay una conexión lógica directa desde afuera hacia adentro: cada conexión termina en el host de bastidor DMZ; cada paquete se examina adecuadamente (y posiblemente se analiza) antes de reenviarlo.


"Esa es una razón para que los contadores bancarios se tomen dos semanas de vacaciones consecutivas", ¿pueden aclararlo? Puede que no sea importante aquí, pero me interesé.
Según Wiklander el

-1 porque ya cubrí el hecho de que no tienes que entrar en un firewall antes de entrar en un servidor: el firewall debe permitir que el público tenga acceso a un servicio que estás ofreciendo al público, por lo tanto, el servidor mismo Está abierto al ataque del público. No hay servicios en ninguno de nuestros servidores a los que no queremos que el público tenga acceso.
Ernie

@Ernie - Te pierdes el punto. Un diseño de host de bastión DMZ aísla un host mediante firewalls en ambos lados. Ese host está expuesto a ataques y eventualmente será subvertido. Pero ese host no es su servidor y correctamente tendrá cantidades mínimas de su información crítica en él. El DMZ (host + cortafuegos) ralentiza un ataque en su servidor el tiempo suficiente para que pueda responder y evitar su éxito.
mpez0

1
@Per Wiklander - GAAP incluye auditorías de cheques regulares. Un contador de malversación de fondos puede cocinar los números y evitar el descubrimiento durante esas auditorías de verificación cuando esté presente, pero si es necesario estar fuera del trabajo durante dos semanas consecutivas, alguien más informará y se descubrirá su malversación. Es una forma de control de dos personas.
mpez0

¿Cómo protege el host del bastión algo en los servidores? Un ejemplo: los puertos 80, 25 y 110 son los únicos puertos abiertos en un servidor. El firewall permite el tráfico a estos puertos desde todo Internet. Por lo tanto, el firewall no protege nada. Si sus servidores están en una ubicación separada de su oficina, entonces no necesita más protección, excepto un firewall en su oficina.
Ernie

1

Las vulnerabilidades son difíciles de predecir. Es prácticamente imposible predecir de qué manera su infraestructura será explotada. Tener un firewall "eleva el listón" para un atacante que quiera explotar una vulnerabilidad, y esta es la parte importante, ANTES de saber cuál es esa vulnerabilidad. Además, las ramificaciones del cortafuegos se pueden entender fácilmente de antemano, por lo que es poco probable que CAUSE problemas con un cortafuegos que son más graves que los problemas que es probable que evite.

Es por eso que "nadie fue despedido por instalar un firewall". Su implementación es de muy bajo riesgo y tiene una ALTA probabilidad de prevenir o mitigar un exploit. Además, la mayoría de las vulnerabilidades realmente desagradables terminan siendo explotadas por la automatización, por lo que cualquier cosa "inusual" terminará rompiendo un bot, o al menos logrará que se salte a favor de un objetivo más fácil.

Nota al margen; los cortafuegos no son solo para internet. Su departamento de contabilidad. no necesita ssh / lo que sea para su servidor ldap, así que no se los dé. La compartimentación de los servicios internos puede marcar una gran diferencia en el trabajo de limpieza en caso de que algo SÍ rompa los muros del castillo.


2
Tener un firewall no sube el listón cuando necesita tener reglas de firewall que abran los puertos 80, 53, 25, 110, 143, 443, 993, 995 y más a todo Internet. Esos servidores son tan vulnerables con un firewall como sin ellos, si necesita tener reglas como esa.
Ernie

2
Es cierto, pero ese mismo servidor probablemente tenga el puerto 3306 (mysql) y una variedad de otros protocolos que potencialmente se beneficiarían de un firewall. Eso no quiere decir que no debas tener otra protección; solo que el firewall no va a doler. Además, creo que se perdió mi punto de que todo el tráfico no necesita estar abierto para todos los usuarios. Es posible que el puerto 22 deba estar abierto, pero no en TODOS sus hosts, y ciertamente no en todo Internet (ni en contabilidad ni en recursos humanos). Cerrar 25 por contabilidad si se supone que deben operar por encima de 465 puede mitigar algunos malware de spam, por ejemplo.
Enki

1

Tengo que decirle a Ernie que, si bien parece hacer mucho para fortalecer sus servidores y mitigar los ataques y las vulnerabilidades, no estoy de acuerdo con su postura sobre los firewalls.

Trato la seguridad un poco como una cebolla, ya que idealmente tienes capas que tienes que atravesar antes de llegar al núcleo, y personalmente creo que es muy equivocado no tener alguna forma de firewall de hardware en el perímetro de tu red.

Admito que estoy llegando a esto desde el ángulo "a lo que estoy acostumbrado", pero sé que cada mes recibo una pequeña lista de parches de Microsoft, muchos de ellos siendo explotados en la naturaleza . Me imagino que sucede lo mismo para casi cualquier sistema operativo y conjunto de aplicaciones en las que quieras pensar.

Ahora no estoy sugiriendo que los firewalls eliminen esto, ni los firewalls son inmunes a tener errores / vulnerabilidades, obviamente un firewall "hardware" es solo software que se ejecuta en una pila de hardware.

Dicho esto, duermo mucho más seguro sabiendo que si tengo un servidor que solo necesita que el puerto 443 sea accesible desde la web, mi perímetro Juniper asegura que solo el puerto 443 sea accesible desde la web. No solo eso, sino que mi Palo Alto asegura que el tráfico que ingresa se descifra, inspecciona, registra y escanea en busca de IPS / IDS, no es que elimine la necesidad de mantener los servidores seguros y actualizados, pero ¿por qué NO encontrarías ese beneficio dado que puede mitigar las vulnerabilidades de día cero y los viejos errores humanos?


1

En primer lugar, al hablar sobre el reenvío de puertos, creo que está combinando firewalls con NATing. Si bien en la actualidad los NAT suelen funcionar como firewalls de facto, ese no es el propósito para el que fueron diseñados. NAT es una herramienta de enrutamiento. Los cortafuegos son para regular el acceso. Es importante para la claridad de pensamiento mantener estos conceptos distintos.

Por supuesto, es cierto que poner un servidor detrás de una caja NAT y luego configurar el NAT para reenviar cualquier cosa a ese servidor, no es más seguro que poner el servidor directamente en Internet. No creo que nadie discuta con esto.

Del mismo modo, un firewall configurado para permitir todo el tráfico no es un firewall en absoluto.

Pero, ¿es "permitir todo el tráfico" realmente la política que desea? ¿Alguien tiene la necesidad de enviar ssh a cualquiera de sus servidores desde una dirección IP rusa? Mientras está jugando con la configuración de un nuevo demonio de red experimental, ¿realmente todo el mundo necesita acceso a él?

El poder de un firewall es que le permite mantener abiertos solo aquellos servicios que sabe que deben estar abiertos y mantener un único punto de control para implementar esta política.


2
Todos sus puntos han sido abordados en mi pregunta. Sí, "permitir todo el tráfico" es realmente la política que queremos para los servicios que no son de administración como SSH o el puerto de administración de algún servidor. De lo contrario, la gente no podría ver nuestras páginas web y enviarnos un correo.
Ernie

2
En cuanto a mantener abiertos aquellos servicios que deben ser, para eso están los pasos 1 y 4.
Ernie

1

Los firewalls de inspección de paquetes con estado NO pertenecen a servidores públicos. Estás aceptando todas las conexiones, por lo que el seguimiento del estado es bastante inútil. Los firewalls tradicionales son una gran responsabilidad en los ataques DDoS y, por lo general, son lo primero en fallar bajo el ataque DDoS, incluso antes de que el ancho de banda del enlace o los recursos del servidor se consuman por completo.

Los filtros de paquetes sin estado en los enrutadores tienen sentido frente a los servidores públicos, pero solo si pueden manejar la velocidad de línea de todo el tráfico de entrada y salida (como una ACL de hardware en un enrutador).

Google, Facebook e incluso Microsoft no colocan los "firewalls" tradicionales frente a los servidores públicos. Cualquiera que haya ejecutado servicios web públicos a escala de "más de un servidor" debería saber esto.

Otras funciones que se encuentran en los firewalls tradicionales, como los ASA de Cisco o lo que sea, se implementan mejor en los propios hosts, donde se pueden escalar de manera efectiva. El registro, los IDS, etc. son todas características de software en los firewalls de todos modos, por lo que se convierten en un gran cuello de botella y un objetivo DDoS si se colocan frente a servidores de acceso público.


1
Creo que el contexto importa. El OP probablemente no estaba hablando de sistemas de escala web, donde el equilibrio de carga y el firewall se implementarían de manera muy diferente a la pila de tecnología de back-office de una SMB.
ewwhite

Incluso frente a un único servidor, un firewall con estado no hace mucho para ayudarte si aceptas conexiones de todas partes. De todos modos, debe usar TLS u otro cifrado para todo, por lo que todo lo que puede hacer un firewall es decir "oye, me pasan más datos en el puerto 443". Los cortafuegos están prácticamente muertos: etherealmind.com/why-firewalls-wont-matter-in-a-few-years
rmalayter

0

¿Por qué todos sus servidores necesitan una dirección pública?

Instale el servidor en la sala de servidores y asígnele una dirección IP pública.

De los aproximadamente 14 servidores que ejecuto regularmente, solo 2 tienen interfaces de acceso público.

Editado para agregar : en otras redes que he tenido que manejar, hemos tenido la capacidad de desactivar / activar los servicios a voluntad, mientras que no teníamos acceso para administrar el firewall. Ni siquiera puedo comenzar a decirle cuántas veces, sin darse cuenta, por supuesto, un servicio innecesario (SMTP) se activó y dejó de funcionar, y lo único que nos evitó convertirnos en un volcado de correo no deseado y quedar en la lista negra en el proceso fue un firewall.

Además, ¿todo el tráfico que pasa entre los servidores está totalmente encriptado?

Ciertamente, puede conducir un automóvil a 100 mph sin cinturones de seguridad, sin bolsas de aire y neumáticos calvos, pero ¿por qué lo haría?


1
Porque todos pueden tener servicios a los que se debe acceder "desde Internet"
adamo

Mmm no. Más como conducir un automóvil a 70 mph con cinturones de seguridad y bolsas de aire mientras prestas atención a lo que estás haciendo. Pero sin cerrar las puertas. Existe una política de seguridad y los servidores se mantienen seguros, pero no hay firewall. Los firewalls no son el principio y el fin de la seguridad, ya sabes.
Ernie

2
No dije, NUNCA, que los cortafuegos fueran la seguridad total o final. No repetiré lo que ya se ha dicho aquí. Son solo una CAPA en muchas CAPAS de seguridad. Te he preguntado dos veces y no has respondido. Los servidores en una LAN son cosas habladoras. ¿Todos sus servidores solo se comunican entre sí mediante canales cifrados?
GregD

0

Los cortafuegos pueden evitar que los usuarios del sistema abran servicios accesibles a la red que los administradores desconocen o que reenvíen puertos a otras máquinas. Al hacer uso del módulo hashlimit, los cortafuegos también pueden limitar la velocidad de los abusadores en función de la IP remota.

Un firewall es otra red de seguridad que garantiza que se cumplan sus políticas. Claro, no ejecute servicios que no espera.

Definitivamente recomiendo que las actualizaciones de software se apliquen de manera oportuna, por ejemplo, pero también recomiendo firewalls en todas las máquinas. Es como cuando conduzco: claro, trato de evitar obstáculos y otros autos, pero también uso el cinturón de seguridad y tengo bolsas de aire en caso de que ocurra lo inesperado.


0

Es posible que no se dé cuenta de cuánto se está beneficiando de los firewalls simplemente porque todos los demás los están utilizando. En un día en que, literalmente, todo el mundo, hasta los usuarios domésticos de DSL tienen cortafuegos en su lugar, la detección de puertos se ha abandonado como un posible vector de ataque. Un hacker decente no va a perder el tiempo buscando tales cosas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.