Falla PFsense con ISP
-
Buen día Compañeros
Hace unos días puse un tema sobre un ataque DDoS, pues bien este es mi escenario:
Tengo pfsense 2.2.4 en un máquina virtual KVM, en un servidor Centos, tengo 3 WAN, 1 LAN y 1 DMZ, las 3 interfaces WAN tienen canales con reuso de 40, 17 y 3 Mbps, en el Pfsense la 3 interfaces WAN que son virtuales, salen por la misma interfaz física, es decir están en un mismo bridge, el canal de 17 Mbps el router está en modo bridge, los otros 2 con NAT en el modem y que por políticas del ISP no me dejan tener el control.
Cuando les comenté acerca de dicho ataque y que había hecho, puesto que me estaba tumbando el pfsense y tocaba reiniciar, funcionó, y pues ya no podían tumbarlo, sin embargo cada cierto tiempo, no sé a veces los miércoles, por ejemplo hoy ocurrió a las 8 am, la interfaz del canal de 17 Mbps, muestra una tasa de transferencia muy alta en IN, y por ende los servicios que allí van se caen, el canal de 3 Mbps también muestra una tasa de transferencia igual a la del canal de 17 Mbps en IN, y el canal de 40 Mbps en OUT muestra la suma de esa transferencia alta de los otros 2 canales, entonces me toca reiniciar las interfaces del canal de 17Mbps y del de 3 Mbps, para que vuelva a la normalidad. Los Logs del firewall no muestran paquetes raros denegados, solo los de siempre que son IGMP que ocurre en todas la interfaces pero que tiene la misma ip de origen que es la del modem del canal de 3 Mbps, y paquetes ICMP de la IP del switch en la VLAN.
Ese switch tiene habilitado Jumbo frames, y también está la red LAN ahí.
Ya no se que hacer, necesito la ayuda de ustedes.
-
BUen día
Nuevamente verificando mejor los Logs del firewall, en la interfaz de 17 Mbps, se ven paquetes con origen de una IP y puerto privada 192.168.5.76:137 en UDP, pero todos esos paquetes se bloquearon exactamente al mismo tiempo con segundos y todo, y destino la de broadcast 192.168.5.76:137, cuando desactivé esa interfaz, el tráfico se empezó a bloquear en la interfaz del canal de 3 Mbps.
 -
Hola. El puerto que mencionas (UDP 137) está relacionado con el servicio NetBIOS de Windows (además del 138 y 139). En los sistemas "antiguos" de Win 95-98-NT, muchos malwares y virus utilizaban ese puerto para poder propagarse en las redes internas o realizar denegación de servicio.
Fijate en éste link: (un poco antiguo pero útil)
https://www.kb.cert.org/vuls/id/32650
¿Por que no intentas cerrar el acceso desde la LAN a esos puertos con alguna regla específica?
Saludos
-
Buen día Shadow
Ese segmento de red de donde proviene el ataque, no es de mi red interna, y pues en mis interfaces WAN yo tengo reglas muy precisas en donde expreso los protocolos permitidos, cuando aplique, con ip de origen y de últimas una regla que bloquee todo tipo de tráfico IPV4 + IPV6, en la LAN, tengo permitido todo hacia afuera, y en el log que adjunté, se muestra que ese tráfico bloqueado, están en las interfaces WAN(Me toca dejar todo abierto hacia afuera ya que esa empresa tiene muchas conexiones hacia clientes de ellos, ya que es una casa de software). i
-
Las redes WAN estan dentro de los bloques de redes privadas ?
Puedes probar bloqueando las redes bogon y las redes privadas.
-
Buen día
De los 3 enlaces WAN, 1, la ip publica se la coloco al pfsense, los otros 2, el modem hace nat, pero los segmentos de red privados de esos modem yo les configuré mascara 30 y en segmentos distintos, pero son diferentes a la ip del ataque.
Las interfaces WAN tienen activo lo del Bogon Network, porque en los logs que les adjunte se ve eso, que los está bloqueando, pero aún así congestiona el canal.