La primera generación de cortafuegos era solo un dispositivo simple de capa 3 con múltiples interfaces y una lista de acceso aplicada en la dirección de la interfaz, durante la misma era en la que los enrutadores soportaban también las listas de acceso sin estado, así que en esos días qué es lo punto de usar el firewall en lugar del enrutador, mientras que casi brindan los mismos beneficios de seguridad
La primera generación de firewalls era solo un dispositivo de capa 3
No creo que esto sea cierto. Al contrario de lo que ocurre con los enrutadores, la primera generación de cortafuegos de filtro de paquetes ya funcionaba en la capa 4, es decir, ya podían filtrar el tráfico TCP y UDP por número de puerto y, por lo tanto, permitir el acceso selectivo a servicios específicos como SMTP (puerto 25) o HTTP (puerto 80).
La diferencia más importante entre estos cortafuegos de filtro de paquetes sin estado y las versiones actuales de estado es que el estado tiene el concepto de conexiones, mientras que el sin estado no tenía. Esto significa especialmente que con un firewall con estado es posible aceptar paquetes entrantes que coincidan con las conexiones salientes, mientras que con firewalls sin estado esto no es posible.
Debido a esto, un firewall sin estado no ofrece mucha protección para los hosts que funcionan como clientes, es decir, que son la fuente de las conexiones salientes. Pero es útil para los hosts que solo funcionan como un servidor, es decir, donde solo se aceptan conexiones desde el exterior en puertos seleccionados. E incluso hoy en día puede tener sentido no siempre realizar un seguimiento del estado de dichas conexiones entrantes, ya que el seguimiento de estado necesita más recursos tanto en la memoria como en el tiempo de procesamiento.
Es posible que esté subestimando las limitaciones de hardware de esos días. Desde principios hasta mediados de los 90, Ethernet usaba concentradores y coaxiales. Los conmutadores y las VLAN no estaban en uso, por lo que las redes se dividieron en subredes y se segmentaron en concentradores físicos para reducir el tráfico de difusión. A veces incluso se utilizaron puentes. (¿Recuerda los puentes?) Si deseaba mover datos de un segmento a otro, a menudo de un piso a otro, tenía que pasar por un enrutador. Los enrutadores debían ser muy rápidos.
Por comparación, los enlaces WAN eran lentos. 64 kbps, 128 kbps RDSI, a veces T1. Los cortafuegos estaban implementando NAT, el reenvío de puertos y las 'reparaciones' de protocolos fueron implementaciones tempranas de inspección con estado Fue muy difícil implementar de forma segura FTP o incluso DNS sin tales correcciones. Otras funciones de firewall, como las VPN entre sitios, eran exclusivas del equipo de Firewall.
Vea un poco del historial de PIX enlace
Estoy seguro de que las ACL extendidas se utilizaron como cortafuegos cuando las personas tenían un presupuesto limitado, pero puede haber sido un período breve cuando fue necesario, ya que los equipos mejoraron muy rápidamente en esos días. La falta de inspección del protocolo de la aplicación hubiera significado poner algunos de sus sistemas fuera de la ACL extendida o del firewall provisional. Por ejemplo, NTP, DNS, FTP ...
Recuerdo haber configurado un pequeño ISP en 1997 y no tenían un firewall. Teníamos una caja de Linux conectada a nuestra RDSI. Era nuestra pasarela de acceso telefónico, nuestro servidor web, nuestro servidor de correo electrónico, etc. No creo que ni siquiera ipchains estaba maduro en ese momento, y mucho menos reemplazado por iptables. Si quería un puerto inactivo, la solución era no tener un servicio escuchando en él.
Dicho esto, nunca configuré redes grandes en los años 90. Sobre todo jugué con los viejos enrutadores y cortafuegos a principios de la década de 2000 por curiosidad.