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.

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.

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. :)

(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.

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í.

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.

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. .

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

¿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?

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.

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.