Pregunta ¿Por qué debo los servidores de firewall?


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 cortafuegos, y también porque han sido adoctrinadas para creer en su necesidad.

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

Supongo que he estado trabajando aquí demasiado tiempo, porque cuando digo "servidores", siempre quiero decir "servicios ofrecidos al público", no "bases de datos de facturación internas secretas". Como tal, cualquier regla nos haría Tener en cualquier cortafuegos tendría que permitir el acceso a toda Internet. Además, nuestros servidores de acceso público están todos en un centro de datos dedicado separado de nuestra oficina.

Alguien más hice una pregunta similar, y mi respuesta fue votada en números negativos. Esto me lleva a creer que o las personas que lo rechazaron realmente no entendieron mi respuesta, o que no entiendo lo suficientemente segura como para estar haciendo lo que estoy haciendo actualmente.

Este es mi enfoque de la seguridad del servidor:

  1. Sigue mi sistema operativo pautas de seguridad  antes de Conectando mi servidor a internet.

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

  3. Monitorea el estado de este servidor con Munin. Y solucione los graves 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 instalar un servidor de seguridad en este servidor, este debería ser el conjunto exacto de puertos a los que deben restringirse las conexiones entrantes.

  5. Instala el servidor en la sala de servidores y dale una dirección IP pública.

  6. Mantener 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 la 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 host, incluso si tiene un firewall (consulte pautas de seguridad). La razón de esto es que un firewall que reenvía servicios públicos a un servidor habilita a un atacante tanto como ningún firewall. Es el servicio en sí el que es vulnerable, y dado que ofrecer ese servicio a toda Internet es un requisito de su operación, restringir el acceso a él no es el punto.

Sí hay son Los puertos disponibles en el servidor que no necesitan ser accedidos por toda Internet, entonces ese software tuvo que cerrarse en el paso 1 y se verificó en el paso 4. En caso de que un atacante entre con éxito en el servidor a través de un software vulnerable y abra un ellos mismos, el atacante puede (y lo hace) fácilmente derrotar a cualquier firewall al hacer una conexión de salida en un puerto aleatorio. El punto de seguridad no es defenderse después de un ataque exitoso, ya que se ha demostrado que es imposible, es mantener a los atacantes fuera en primer lugar.

Se ha sugerido que existen otras consideraciones de seguridad además de los puertos abiertos, pero para mí eso simplemente suena como defender la propia fe. Cualquier vulnerabilidad del sistema operativo / pila TCP debe ser igualmente vulnerable, ya sea que exista o no un firewall, debido al hecho de que los puertos se reenvían directamente a esa pila de sistema operativo / TCP. Del mismo modo, ejecutar su firewall en el servidor en lugar de tenerlo en el enrutador (o, lo que es peor, en ambos lugares) parece agregar capas de complejidad innecesarias. Entiendo que la filosofía "la seguridad viene en capas", pero llega un punto en el que es como construir un techo al apilar X capas de madera contrachapada una sobre otra y luego perforar un agujero en todas ellas. Otra capa de madera contrachapada no detendrá las fugas a través del agujero que estás haciendo a propósito.

Para ser honesto, la única forma en que veo que un servidor de seguridad es útil para los servidores es si tiene reglas dinámicas que impiden que todas las conexiones de los servidores se realicen con atacantes conocidos, como los RBL para el correo no deseado (que, por casualidad, es lo que hace nuestro servidor de correo) . Desafortunadamente, no puedo encontrar ningún cortafuegos que haga eso. Lo siguiente mejor es un servidor IDS, pero eso supone que el atacante no ataca primero a sus servidores reales, y que los atacantes se molestan en explorar toda la red. antes de agresor. Además, se sabe que estos producen grandes números de falsos positivos.


101
2017-11-12 21:11


origen


¿Y entonces TODO el tráfico que pasa entre sus servidores está encriptado? - GregD
Quiéralo. Las reglas del cortafuegos local son casi siempre solo vudú. - unixtippse
¿Tiene escritorios / empleados en su red también? ¿Qué haces con ellos? - Brandon
Esta pregunta hubiera sido adecuada para seguridad.stackexchange.com - Olivier Lalonde
@ 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é un firewall es algo que tiene acceso público completo? - Ernie


Respuestas:


Ventajas del cortafuegos:

  1. Puede filtrar el tráfico saliente.
  2. Los firewalls de capa 7 (IPS) pueden proteger contra vulnerabilidades conocidas de aplicaciones.
  3. Puede bloquear un cierto rango de direcciones IP y / o puertos de manera centralizada en lugar de intentar asegurarse de que no haya ningún servicio escuchando en ese puerto en cada máquina individual o negando el acceso usando Envoltorios TCP.
  4. Los cortafuegos pueden ser útiles si tiene que lidiar con usuarios / administradores menos conscientes de la seguridad, ya que podrían proporcionar una segunda línea de defensa. Sin ellos, uno tiene que estar absolutamente seguro de que los hosts son seguros, lo que requiere una buena comprensión de la seguridad por parte de todos los administradores.
  5. Los registros del cortafuegos proporcionarían registros centrales y ayudarían a detectar escaneos verticales. Los registros de firewall pueden ayudar a determinar si algún usuario / cliente está intentando conectarse al mismo puerto de todos sus servidores periódicamente. Para hacer esto sin un firewall, habría que combinar registros de varios servidores / hosts para obtener una vista centralizada.
  6. Los cortafuegos también vienen con módulos antispam / antivirus que también se añaden a la protección.
  7. Seguridad independiente del SO. Según el sistema operativo del host, se requieren diferentes técnicas / métodos para hacer que el host sea seguro. Por ejemplo, los TCP Wrappers pueden no estar disponibles en las máquinas con Windows.

Por encima de todo esto, si no tiene firewall y el sistema está comprometido, ¿cómo lo detectaría? No se puede confiar en el intento de ejecutar algún comando 'ps', 'netstat', etc. en el sistema local, ya que esos binarios se pueden reemplazar. No se garantiza la protección de 'nmap' desde un sistema remoto, ya que un atacante puede asegurarse de que el kit raíz acepte conexiones solo desde la (s) dirección (es) IP de origen seleccionada en los momentos seleccionados.

Los firewalls de hardware ayudan en estos escenarios, ya que es extremadamente difícil cambiar el sistema operativo / los archivos del firewall en comparación con el sistema operativo / los archivos host.

Desventajas del firewall:

  1. La gente siente que el firewall se hará cargo de la seguridad y no actualiza los sistemas regularmente y detiene los servicios no deseados.
  2. Cuestan. A veces la cuota anual de la licencia debe pagarse. Especialmente si el firewall tiene módulos antivirus y antispam.
  3. Un solo punto de falla adicional. Si todo el tráfico pasa a través de un firewall y el firewall falla, la red se detendrá. Podemos tener cortafuegos redundantes, pero luego el punto anterior en el costo se amplifica aún más.
  4. El seguimiento de estado no proporciona ningún valor en los sistemas públicos que aceptan todas las conexiones entrantes.
  5. Los cortafuegos con estado son un cuello de botella masivo durante un ataque DDoS y suelen ser los primeros en fallar, porque intentan mantener el estado e inspeccionar todas las conexiones entrantes.
  6. Los cortafuegos no pueden ver dentro del tráfico cifrado. Ya que todo el tráfico debería Estar cifrado de extremo a extremo, la mayoría de los firewalls agregan poco valor frente a los servidores públicos. A algunos firewalls de próxima generación se les pueden otorgar claves privadas para terminar TLS y ver dentro del tráfico, sin embargo, esto aumenta 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 están parcheados contra las vulnerabilidades mucho más rápidamente que los firewalls. Los proveedores de firewall a menudo se sientan en problemas conocidos para años sin la aplicación de parches, y la aplicación de parches a 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 buggy. Los firewalls son simplemente 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 firewalls tienen errores, pero parecen proporcionar pocas herramientas para solucionarlos. Por lo tanto, los firewalls agregan complejidad y una fuente adicional de errores difíciles de diagnosticar a una pila de aplicaciones.

52
2017-11-13 02:36



Above all this if you do not have firewall and system is compromised then how would you detect it? La detección de intrusos no es el trabajo del firewall. Ese trabajo es manejado más adecuadamente por el HIDS (sistema de detección de intrusiones basado en host), que es independiente del firewall. - Steven Monday
Los servidores de Syslog eliminan la necesidad del elemento 5. En todo caso, es mejor enviar sus registros de firewall a un servidor de syslog, en caso de que un atacante logre poner en peligro el firewall y elimine sus registros. Luego, el atacante tiene que comprometer dos sistemas solo para eliminar los registros, y es posible que no estén preparados para eso (especialmente con ataques automatizados). Del mismo modo, si todos sus sistemas tienen un registro centralizado, obtendrá mejores detalles sobre el ataque que los registros de firewall. - Ernie
Mi punto fue porque 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 archivos binarios de tripwire (twadmin, tripwire, twprint, etc.) con versiones comprometidas que nunca informarán de intrusiones. Incluso si intentamos copiar bibliotecas / archivos binarios de otro sistema, puede haber un proceso en ejecución que supervise estos archivos binarios comprometidos y nuevamente los reemplace con una versión dañada en caso de que sean reemplazados o actualizados. El firewall es independiente del host, se puede confiar en tales escenarios. - Saurabh Barjatiya
Esta respuesta fue aceptada en lugar de la más popular porque proporciona mejores y más completas razones 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 suelen ser los primeros en fallar bajo ataque. - rmalayter


Podría decirse que los Wrappers de TCP se pueden denominar implementación de firewall basado en host; Estás filtrando el tráfico de la red.

Para el punto en que un atacante hace conexiones salientes en un puerto arbitrario, un firewall también proporcionaría un medio para controlar el tráfico saliente; un firewall configurado correctamente administra el ingreso y egreso de una manera que sea apropiada para el riesgo relacionado con el sistema.

En el punto sobre cómo cualquier vulnerabilidad de TCP no es mitigada por un firewall, no está familiarizado con cómo funcionan los firewalls. Cisco tiene un montón de reglas disponibles para descargar que identifican paquetes construidos de una manera que podría causar problemas particulares en los sistemas operativos. Si tomas Snort y empiezas a ejecutarlo con el conjunto de reglas correcto, también recibirás alertas 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 alejas 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 evitarlo. Concentrar su protección en la frontera, al igual que con un firewall dedicado, hace que las cosas sean más fáciles de administrar porque tiene un punto central de ahogo 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 la frontera, envoltorios de TCP en el dispositivo y probablemente también algunas reglas sobre enrutadores internos. Por lo general, debe proteger la red de Internet y proteger los nodos entre sí. Este enfoque de capas múltiples no es como perforar un agujero a través de varias hojas de madera contrachapada, es más como poner un par de puertas para que un intruso tenga dos cerraduras que romper en lugar de una sola; Esto se llama una trampa para el hombre en la seguridad física, y la mayoría de los edificios tienen una por una razón. :)


33
2017-11-12 22:04



Además, si se escabullen dentro del edificio y abren la puerta interior para que su amigo salga, también tienen que abrir 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 en 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
@Ernie: no, solo debe existir para que se busque automáticamente espacio libre para Warez, bases de datos de clientes, información financiera, contraseñas y se agregue a una red de bots, pero incluso eso puede ser lo suficientemente malo. Algunos administradores no tendrán ningún problema en su IP. Si parece que te hospedan zombies. - Rory Alsop
TCP Wrappers could be arguably called a host-based firewall implementation+1 por una gran respuesta. - sjas


(Puede que quieras leer "La vida sin firewalls")

Ahora: ¿Qué pasa con tener un sistema heredado para el cual 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 necesidad del firewall. Lo que realmente importa es que tienes que implementar una política de seguridad. Para ello, utilizará las herramientas que lo implementarán y lo ayudarán a administrarlo, expandirlo y evolucionarlo. Si se necesitan cortafuegos para hacerlo, está bien. Si no son necesarios eso también está bien. Lo que realmente importa es tener una implementación funcional y verificable de su política de seguridad.


15
2017-11-12 21:31



Heh He estado ejecutando nuestra red de servidores durante los últimos 8 años sin un firewall. podría tener escrito "Vida sin cortafuegos", pero hizo un trabajo mucho mejor y tiene una red mucho más grande que yo, de todos modos. - Ernie
@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, que a veces se remonta a 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
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 extraer datos realmente confidenciales, incluso con acceso de raíz en cada servidor), he podido descubrir cada compromiso individual he tenido desde que empecé aquí. Podría continuar con el espectáculo de terror que existía cuando empecé, pero no tengo suficiente espacio. :) Basta con decir que la mayoría de los ataques no son sutiles, y los sutiles también son visibles. Ah, sí, y la separación de privilegios del usuario es tu amigo. - Ernie


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

Pocas cosas son una "necesidad" en un sentido estricto de la palabra. La seguridad es más sobre la configuración de todos los bloqueos que puedas. Cuanto más trabajo necesites para entrar en tu servidor, tendrás menos posibilidades de un ataque exitoso. Quiere que sea más fá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 la seguridad. Otra ventaja de los cortafuegos es que puede simplemente eliminar los intentos de conectarse a cualquier puerto en lugar de responder a las solicitudes rechazadas, lo que hará que el mapeo sea un poco más inconveniente 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 el límite de velocidad de las conexiones entrantes para ayudar a aliviar los ataques de DOS.

"El punto de seguridad no es defenderse después de un ataque exitoso, ya que se ha demostrado que es imposible, es mantener a los atacantes fuera".

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 antiguo dicho "No pegue todos sus huevos en una cesta" es aplicable aquí.


9
2017-11-12 21:30



Bueno, tienes razón, no puse ningún inconveniente allí. Contras: mayor complejidad de la red, punto único de falla, interfaz de red única a través de la cual el ancho de banda se encuentra en un cuello de botella. Del mismo modo, los errores administrativos cometidos en un firewall pueden matar toda su red. Y los dioses prohíben que te quedes fuera de esto mientras tanto se trata de un viaje de 20 minutos a la sala de servidores. - Ernie
Esto puede ser puramente retórico, pero cuando dice "La seguridad es más sobre la configuración de todos los bloqueos que puede", preferiría escuchar "La seguridad es más sobre bloquear todo de forma 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


Should I firewall my server? Buena pregunta. Parecería que no tiene mucho sentido golpear un firewall en la parte superior de una pila de red que ya rechaza los intentos de conexión a todos, excepto a los pocos puertos que están legítimamente abiertos. Si hay una vulnerabilidad en el sistema operativo que permite que los paquetes creados con fines malintencionados interrumpan / exploten un host, un firewall corriendo en ese mismo host ¿Evitar el exploit? Bien, tal vez ...

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

Otra razón para ejecutar un servidor de seguridad en un servidor es desacoplar estas dos preocupaciones que de otra manera están fuertemente relacionadas:

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

Sin un firewall, el conjunto de servicios que se ejecutan (junto con las configuraciones para tcpwrappers y similares) determina completamente el conjunto de puertos que el servidor tendrá abiertos, y desde dónde se aceptarán las conexiones. Un servidor de seguridad basado en host proporciona al administrador flexibilidad adicional para instalar y probar nuevos servicios de forma controlada antes de que estén más disponibles. Si no se requiere dicha flexibilidad, entonces hay menos razones para instalar un servidor de seguridad en un servidor.

En una nota final, hay un elemento que no se menciona 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 AYUDANTE 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.


8
2017-11-12 23:10



+1 por la mención de los sistemas HIDS. - Sam Halicke
Los HIDS son geniales, si pretendes configurarlo y olvidarlo. Y nunca añada o elimine cuentas. De lo contrario, la gran mayoría de los registros de HIDS serán listas largas de lo que hiciste hoy, y terminarán siendo ignoradas rápidamente todo el tiempo. - Ernie
No hay dolor, no hay ganancia, como dicen. En los servidores con muchos cambios, es posible filtrar el ruido esperado, lo que le permite concentrarse en lo inesperado. - Steven Monday


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 preocupa que las personas que dicen ciegamente "Tengo que obtener un cortafuegos" sin entender por qué piensan de esa manera y que no entienden las fortalezas y debilidades de los cortafuegos.

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 cortafuegos: cualquier otra cosa que pueda decir sobre ellos, son un buen nivel de seguro. No sustituyen los parches, el bloqueo de máquinas, la inhabilitación de servicios que no utiliza, el registro, etc. Pero pueden ser un complemento útil.

También sugeriría que la ecuación cambie un poco dependiendo de si se está 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 pueden 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 evidente en un edificio; o un cortafuegos obvio 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 usted tiene la información que desea y está decidido a obtenerla, pero vale la pena disuadir a los intrusos ocasionales, especialmente si sabe que cualquier intruso cuyas investigaciones persistan más allá del disuasivo debe tomarse especialmente en serio. .


6
2017-11-12 22:25



Por lo tanto, ¿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í lo hice. - Rob Moir


Todas las grandes preguntas. PERO, estoy muy sorprendido de que el RENDIMIENTO no se haya puesto sobre la mesa.

Para los front-end web utilizados con mucha CPU (en cuanto a la CPU), el firewall local realmente degrada el rendimiento y el período. Prueba una prueba de carga y verás. Vi esto muchas veces. La desactivación del firewall aumentó el rendimiento (solicitud por segundo) en un 70% o más.

Esta compensación debe ser considerada.


5
2017-11-13 22:28



Depende mucho de las reglas de firewall en su lugar. Las reglas del cortafuegos se ejecutan secuencialmente en cada paquete, por lo que no desea tener cientos de reglas que deben ser revisadas. El invierno pasado, cuando gestionamos un sitio que tenía un anuncio en la superbowl, las reglas del firewall no fueron un problema, por ejemplo. Pero estoy de acuerdo en que necesita comprender el impacto en el rendimiento de las reglas de firewall. - Sean Reifschneider


Un firewall es una protección adicional. Tres escenarios particulares contra los que protege son los ataques de la pila de red (es decir, el sistema operativo de su servidor tiene una vulnerabilidad a los paquetes especialmente diseñados que nunca llegan al nivel de los puertos), una intrusión exitosa que hace la conexión a "teléfono de casa" (o envía spam, o lo que sea) ), o una intrusión exitosa al abrir un puerto de servidor o, menos detectable, ver una secuencia de detonación de puertos 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 evitarlo, pero eso no significa que sea inútil. Recuerde que la seguridad no es una proposición de todo o nada; uno tiene un enfoque en capas, cinturón y tirantes, para lograr un nivel de seguridad que sea suficiente para sus necesidades.


4
2017-11-13 12:37



+1 Absolutamente, la defensa en profundidad es clave. - Jim OHalloran
No veo cómo puedo tener ninguna expectativa de bloquear el tráfico saliente, 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 el bloqueo de todas las conexiones salientes, salvo algunas, ayudará en todo, es decir, si quiere hacerlo cualquier cosa En Internet. Y bloquear solo algunos puertos es como establecer una cabina de peaje en medio del desierto. - Ernie


No soy un experto en seguridad de ninguna manera, pero suena como si tuvieras un firewall. Parece que ha tomado parte de la funcionalidad principal de un firewall y lo ha incorporado a sus políticas y procedimientos. No, no necesita un servidor de seguridad si va a hacer el mismo trabajo que un servidor de seguridad. En lo que a mí respecta, prefiero hacer lo mejor que pueda para mantener la seguridad, pero tener un servidor de seguridad mirando por encima de mi hombro, pero en algún momento cuando puedes hacer todo lo que hace el servidor de seguridad, comienza a ser irrelevante.


3
2017-11-13 10:47





Ciertamente, no se necesita un firewall para configuraciones más pequeñas. Si tiene uno o dos servidores, los cortafuegos de software se pueden mantener. Dicho esto, no corremos 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 de paquetes, filtrado y políticas. Un servidor web debería preocuparse por servir páginas web, y eso es todo. Poner ambos roles en un dispositivo es como pedirle a su contador que también sea su guardia de seguridad.

El software es un blanco móvil.

El software en el host siempre está cambiando. Las aplicaciones pueden crear sus propias excepciones de cortafuegos. El sistema operativo se actualiza y parcheado. Los servidores son un área de "administración" de alto tráfico, y sus políticas de seguridad / políticas de firewall son a menudo mucho más importantes para la seguridad que las configuraciones de su aplicación. En un entorno de Windows, suponga que alguien comete un error en algún nivel de directiva 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 abierto en cuestión de clics.

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

Servicios / políticas / reglas reutilizables, manejabilidad

Si configuro un servicio / política llamado "Servidor web" una vez (por ejemplo, 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 la configuración de servicios de firewall en 10 cajas y abrir 2 puertos x 10 veces. Cuando esa política necesita cambiar, es 1 cambio contra 10.

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

Digamos que mi servidor de aplicaciones + firewall basado en 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 es menos que la del atacante para siquiera entrar y mirarla.

Una experiencia real: una vez arruiné una regla de firewall (dejé los puertos a CUALQUIERA en lugar de uno específico, y el servidor tenía un servicio vulnerable), y el atacante en realidad tenía una sesión de Escritorio remoto en vivo en la caja. Cada vez que comenzaba a obtener una sesión, el atacante anulaba / 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 SNMP / NetFlow externo para obtener una imagen precisa.

Conservación de IPv4

No hay razón para tener dos direcciones IP si una es para la web y la otra para el correo. Mantenga los servicios en cajas separadas y dirija los puertos de manera adecuada a través del dispositivo diseñado para ello.


3
2017-11-13 16:06





Blockquote   Bueno, tienes razón, no puse ningún inconveniente allí. Contras: mayor complejidad de la red, punto único de falla, interfaz de red única a través de la cual el ancho de banda se encuentra en un cuello de botella. Del mismo modo, los errores administrativos cometidos en un firewall pueden matar toda su red. Y los dioses prohíben que te quedes fuera de esto mientras tanto se trata de un viaje de 20 minutos a la sala de servidores.

En primer lugar, agregar a lo sumo un salto enrutado adicional a través de su red no es complejo. En segundo lugar, ninguna solución de firewall implementada con un solo punto de falla es completamente inútil. Al igual que usted agrupa su servidor o servicios importantes y usa NIC vinculadas, implementa firewalls de alta disponibilidad. No hacerlo, o no reconocer y saber que lo harías es muy miope. El simple hecho de indicar que hay una sola interfaz no convierte automáticamente algo en un cuello de botella. Esa afirmación muestra que no tiene idea de cómo planear e implementar adecuadamente un firewall con el tamaño adecuado 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ño a toda su red, pero diría que mantener políticas individuales en todos sus servidores es mucho más propenso a los errores que en un solo lugar.

En cuanto al argumento de que te mantienes al día con los parches de seguridad y sigues las guías de seguridad; eso es un argumento inestable en el mejor de los casos. Normalmente, los parches de seguridad no están disponibles hasta después de que se descubre una vulnerabilidad. Eso significa que todo el tiempo que esté ejecutando servidores direccionables públicamente serán vulnerables hasta que estén parcheados. Como han señalado otros, los sistemas IPS pueden ayudar a prevenir los compromisos de tales vulnerabilidades.

Si cree que sus sistemas son tan seguros como pueden ser, es una buena confianza tenerlos. Sin embargo, le recomiendo que realice una auditoría de seguridad profesional en su red. Sólo puede abrir los ojos.


2
2017-11-14 03:57



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