Ver logs del cortafuegos en tiempo real
-
¡Hola!
Acostumbrado a las consolas y al tail -f encontré un truco muy interesante en el recientemente publicado libro de pfSense.
Lo expliqué hace unas horas en:
http://forum.pfsense.org/index.php/topic,20999.msg108000.html#msg108000
Desde hace unos días que tengo a PuTTY con este truco (minimizado en mi PC) para ir viendo cosas …
Saludos,
Josep Pujadas
-
;D que buena bellera
seria como un snort version humana jjaaapucha que se ve interesante ese libro
tendre que comprar uno :P -
;D que buena bellera
seria como un snort version humana jjaaapucha que se ve interesante ese libro
tendre que comprar uno :P -
¡Hola!
Acostumbrado a las consolas y al tail -f encontré un truco muy interesante en el recientemente publicado libro de pfSense.
Lo expliqué hace unas horas en:
http://forum.pfsense.org/index.php/topic,20999.msg108000.html#msg108000
Desde hace unos días que tengo a PuTTY con este truco (minimizado en mi PC) para ir viendo cosas …
Saludos,
Josep Pujadas
ballera me puedes decir como interpretar el trafico en este log es muy bueno entiendo algunas pero otras no gracias . Lo otro el libro que dice usted es la guía definitiva de pfsense para poder comprarla, o hay otro libro muchas gracias le agradezco
-
¡Hola!
Ahí verás los bloqueos de la default rule de pfSense y las acciones de las reglas que decidas loguear.
Si hay excesivo ruido porque la default rule bloquea cosas evidentes hay un truco consistente en poner una regla de bloqueo para las acciones ruidosas y no loguear esta regla. De esta manera se consigue reducir el logueo, conservando el bloqueo.
Sobre el libro, es el oficial, http://www.amazon.com/gp/product/0979034280?ie=UTF8&tag=pfsense-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0979034280
No conozco otro.
Saludos,
Josep Pujadas
-
Hola!
Tengo un problemilla, al intentar evitar reglas que me inundan el log, tal y como has comentado en tu intervención.
Tengo un FabiaTech FX5622, con la versión 1.2.3-RC1 Embedded.
Tengo la WAN y la LAN en modo bridge.
Conectado en la parte de la WAN tengo dos routers cisco, de modo redundante, utilizando el protocolo de cisco HSRP. Esto me produce cada 3 segundos un mensaje de multidifusión, desde cada uno de los routers, hacia toda la red. Algo que me inunda el log del firewall y no me dificulta buscar algo cuando tengo la necesidad.
He puesto reglas más prioritarias que me bloqueen estos registros, tanto en la LAN como en la WAN, pero sigue sin funcionar, la regla por defecto es la que bloquea la acción.
En el log puedo ver que el origen del paquete filtrado es BRIDGE0, pero no puedo poner ninguna regla a BRIDGE0.
No se si el problema puede venir por aquí.¿Alguna sugerencia?
Muchas gracias -
¡Hola!
No he experimentado en modo bridge … Sin embargo, en lo que describes ¿no sería (en el lado WAN) el router Cisco el origen de los paquetes a bloquear?
Una regla correcta debería servir ...
Por otra parte, podrías migrar a la 1.2.3-RELEASE, NanoBSD. Hay que "tunear" el arranque pero funciona ... http://forum.pfsense.org/index.php/topic,21194.0.html Estarías con la última versión oficial y tendrías todos los últimos cambios/mejoras. No sea que haya algún lío con el tema ...
Saludos,
Josep Pujadas
-
Hola Josep!
Tienes razón cuando dices que tendría que ser en la WAN, pero me he encontrado que paquetes de retorno hacía la DMZ por ejemplo, o hacía otra OPT configurada, no llegaban, tenía que poner las reglas tanto en la WAN como en la LAN. Parece que al estar en modo bridge puede que se haga un lio por el retorno del paquete. Si no las ponía en las dos, a veces funcionaba a veces no.
Te aseguro que la regla no funciona y mira que he probado formas diferentes de bloquearla.
Al trabajar en modo bridge, el firewall debe ser transparente a los equipos, con lo que la puerta de enlace predeterminada es el router que esta en la WAN, esto hace que cuando un equipo que esta en la LAN quiera acceder a una IP que esta en la DMZ, por ejemplo, al ser rangos diferentes, envie el paquete al default gateway que es el router y entonces las reglas que esten puestas en el pfsense no actuan, las salta por alto. Si al equipo de la LAN se le pone como default gateway el pfsense parece que esta parte funciona. Pero por el contrario cuelga sesiones establecidas y se pierde al conmutar ciertos paquetes.
Tengo que mirar lo que dices de migrar la versión, pero al ser un equipo que esta en producción no puedo hacerlo en cualquier momento.
La idea final es segmentar tanto WAN como LAN, pero para eso tengo que hablar con el proveedor para concretar con él cambios de IPs y propagación de nuevas IP en delegaciones y demás. Mientras tanto tiene que estar funcionando.
No se como lo arreglaré.
Muchas gracias Josep. -
Al trabajar en modo bridge, el firewall debe ser transparente a los equipos, con lo que la puerta de enlace predeterminada es el router que está en la WAN,
De acuerdo.
esto hace que cuando un equipo que esta en la LAN quiera acceder a una IP que esta en la DMZ, por ejemplo, al ser rangos diferentes, envie el paquete al default gateway que es el router y
No es imprescindible emplear bridge para hacer esto. No conozco, sin embargo, tu topología para afirmar lo que digo al 100%. Resultaría imprescindible el modo bridge si lo que tienes en el lado LAN de pfSense son servidores con IP pública. En ese caso sí necesitas un firewall transparente (bridge).
entonces las reglas que esten puestas en el pfsense no actuan, las salta por alto.
En el capítulo 9 de la Guía de pfSense (recientemente publicada) se dice que a nivel de filtrado no hay diferencias entre interfases en modo bridge o en modo router. Por tanto, las reglas deberían filtrar el tráfico entrante en cada interfase.
Si al equipo de la LAN se le pone como default gateway el pfsense parece que esta parte funciona. Pero por el contrario cuelga sesiones establecidas y se pierde al conmutar ciertos paquetes.
Entiendo que esto no es correcto y, por tanto, normal la pérdida de paquetes. Si pfSense está en modo bridge, la gateway es el router que tienes en el lado WAN. La IP de la LAN de pfSense sólo sirve para su administración.
Saludos,
Josep Pujadas
-
Hola de nuevo,
aquí os dejo una captura del syslog para que veais que en modo bridge, aunque pongas reglas de filtrado, existen unas entradas en el registro que no se pueden evitar, ya que cuando se crean la reglas, en las opciones disponibles para elegir la interface, tenemos:
WAN/LAN/PPTP/PPPOE/IPSEC y las OPT diferentes de cada uno
En ningún momento podemos elegir BRIDGE y en el log podemos ver que el origen del paquete es la interface: BRIDGE. Ver imagen.
A partir de la linea negra hacía abajo no aplico ninguna regla y de la linea negra hacía arriba aplico reglas para evitar el tráfico. Como se puede ver tan solo puedo bloquear las de procedencia de la interface WAN y no la de la if bridge.Saludos
