4. Bloqueo de conexiones por reglas de Firewall

Bloqueo de conexiones por reglas de Firewall

  • B

    Hola a todos,

    Estamos analizando la opción de pfsense para una implementación, sin embargo, estamos detenidos con una situacion que no podemos explicar.

    A continuación les proporciono información del ambiente donde tenemos este problema.

    Como existe una red en producción, de manera paralela se estan haciendo pruebas con la instalación de Pfsense y diversos equipos.
    En el Pfsense se estan utilizando 3 tarjetas de red, con una de ellas con 4 VLAN´s, distribuidas de la siguiente manera

    1. WAN (em1)
    2. LAN (em0)
      3-1) VLAN_16 (sk0)
      3-2) VLAN_17 (sk0)
      3-3) VLAN_20 (sk0)
      3-4) VLAN_21 (sk0)

    Al inicio de la configuración validamos la comunicación de todas las redes verificando su salida a Internet y funciona de manera correcta, pero al momento de utilizar conexiones por SMB en los logs aparecen registros de bloqueo de esas conexiones, sin embargo, en las reglas que agregamos, no aparece bloqueado.

    De manera normal no aparecen registros en los logs, solo cuando habilito la opción "Log packets blocked by the default rule" aparecen los registros de las IP con las que estamos haciendo pruebas y coinciden cuando estamos tratando de hacer una copia de datos por SMB de una PC a otra.

    De lo que podemos estar seguros es que el bloqueo es por reglas del firewall, ya que cuando habilitamos la opción "Disable all packet filtering" si podemos hacer la copia de material, aunque no podemos navegar en Internet.

    Los logs que observamos en la consola del pfsense son como estos

    00:00:00.000000 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:00.299164 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:00.250549 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445:  tcp 312 [bad hdr length 0 - too short, < 20]
    00:00:00.349433 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:01.200219 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:00.066188 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:02.326072 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:04.800490 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:09.600865 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:00.010365 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:00.000098 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:00.502211 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445:  tcp 20 [bad hdr length 0 - too short, < 20]
    00:00:01.020266 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:02.040052 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]
    00:00:04.081394 rule 1/0(match): block in on sk0_vlan20: 192.168.20.52.35393 > 192.168.15.18.445: [|tcp]

    La comunicación por SMB se hace desde 2 redes distintas, en la LAN(em0) y cualquier otra de las redes.

    Revisamos información relacionada con estos logs (Logs show "blocked" for traffic from a legitimate connection, why?) en el siguiente link
    http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F
    pero no aplica para este caso, ya que si existe bloqueo de comunicación.

    Estos son los datos de la versión que estamos usando:

    System Information
    Version 2.0.3-RELEASE (i386)
    built on Fri Apr 12 10:22:21 EDT 2013
    FreeBSD 8.1-RELEASE-p13

    You are on the latest version.
    Platform pfSense
    CPU Type Intel(R) Xeon(TM) CPU 2.80GHz
    Uptime
    Current date/time
    Wed Aug 14 18:26:48 CDT 2013
    DNS server(s) 127.0.0.1
    192.168.15.1
    Last config change Wed Aug 14 16:14:17 CDT 2013

    Agradezco de antemano la orientación que puedan brindar para encontar el porque de esta situacion




    0
  • B

    Olvide comentar que este bloqueo se presenta en cualquiera de las VLAN´s hacia la LAN. Este es el listado de la reglas en el equipo

    [2.0.3-RELEASE][admin@routerpv.virtual.com]/root(6): pfctl -sr
    scrub on em1 all fragment reassemble
    scrub on em0 all fragment reassemble
    scrub on sk0_vlan16 all fragment reassemble
    scrub on sk0_vlan21 all fragment reassemble
    scrub on sk0_vlan20 all fragment reassemble
    scrub on sk0_vlan17 all fragment reassemble
    anchor "relayd/" all
    block drop in log all label "Default deny rule"
    block drop out log all label "Default deny rule"
    block drop in quick inet6 all
    block drop out quick inet6 all
    block drop quick proto tcp from any port = 0 to any
    block drop quick proto tcp from any to any port = 0
    block drop quick proto udp from any port = 0 to any
    block drop quick proto udp from any to any port = 0
    block drop quick from <snort2c>to any label "Block snort2c hosts"
    block drop quick from any to <snort2c>label "Block snort2c hosts"
    block drop in log quick proto tcp from <sshlockout>to any port = ssh label "sshlockout"
    block drop in log quick proto tcp from <webconfiguratorlockout>to any port = http label "webConfiguratorlockout"
    block drop in quick from <virusprot>to any label "virusprot overload table"
    block drop in on ! em1 inet from 192.168.40.0/24 to any
    block drop in inet from <__automatic_86219efe_0> to any
    block drop in on ! em0 inet from 192.168.15.0/24 to any
    block drop in on ! sk0_vlan16 inet from 192.168.16.0/24 to any
    block drop in on ! sk0_vlan21 inet from 192.168.21.0/24 to any
    block drop in on ! sk0_vlan20 inet from 192.168.20.0/24 to any
    block drop in on ! sk0_vlan17 inet from 192.168.17.0/24 to any
    block drop in on sk0_vlan16 inet6 from fe80::20a:5eff:fe1b:46c5 to any
    block drop in on sk0_vlan21 inet6 from fe80::20a:5eff:fe1b:46c5 to any
    block drop in on sk0_vlan20 inet6 from fe80::20a:5eff:fe1b:46c5 to any
    block drop in on sk0_vlan17 inet6 from fe80::20a:5eff:fe1b:46c5 to any
    block drop in on em1 inet6 from fe80::20e:cff:fe3d:f497 to any
    block drop in on em0 inet6 from fe80::20e:cff:feb8:7307 to any
    pass in on lo0 all flags S/SA keep state label "pass loopback"
    pass out on lo0 all flags S/SA keep state label "pass loopback"
    pass out all flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass out route-to (em1 192.168.40.254) inet from 192.168.40.5 to ! 192.168.40.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    pass in quick on em0 proto tcp from any to (em0) port = http flags S/SA keep state label "anti-lockout rule"
    pass in quick on em0 proto tcp from any to (em0) port = ssh flags S/SA keep state label "anti-lockout rule"
    anchor "userrules/    " all
    pass quick on sk0_vlan20 inet proto tcp from 192.168.20.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
    pass on em0 inet proto tcp from 192.168.15.0/24 to 192.168.20.0/24 flags S/SA keep state label "USER_RULE"
    pass in quick on em1 reply-to (em1 192.168.40.254) inet proto udp from 192.168.40.254 to 192.168.40.5 port = netbios-ns keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
    pass in quick on em0 inet proto tcp from 192.168.15.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
    pass in quick on em0 all flags S/SA keep state label "USER_RULE"
    pass in quick on em0 inet from 192.168.15.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
    pass in quick on em0 inet from 192.168.15.0/24 to 192.168.20.0/24 flags S/SA keep state label "USER_RULE"
    pass in quick on em0 inet from 192.168.15.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
    pass in quick on sk0_vlan16 all flags S/SA keep state label "USER_RULE"
    pass in quick on sk0_vlan21 all flags S/SA keep state label "USER_RULE"
    pass in quick on sk0_vlan20 all flags S/SA keep state label "USER_RULE"
    pass in quick on sk0_vlan20 from <easyruleblockhostsopt3>to any flags S/SA keep state label "USER_RULE: Easy Rule: Blocked from Firewall Log View"
    pass in quick on sk0_vlan20 inet from 192.168.20.0/24 to 192.168.20.0/24 flags S/SA keep state label "USER_RULE"
    pass in quick on sk0_vlan20 inet from 192.168.20.0/24 to 192.168.15.0/24 flags S/SA keep state label "USER_RULE"
    pass in quick on sk0_vlan17 all flags S/SA keep state label "USER_RULE"
    anchor "tftp-proxy/*" all
    [2.0.3-RELEASE][admin@routerpv.virtual.com]/root(7):


    </easyruleblockhostsopt3></virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c>

    0

  • Puedo sugerirte hacer algo sencillo.

    Mira, ejemplo

    LAN 192.168.1.0/24
    VLAN_20 192.168.2.0/24  Samba Server

    Samba solo requiere 2 puertos TCP, 139/445.

    Quiero que todo lo que esta detras de mi LAN pueda pegarle a los servidores samba que esta en la vlan_20
    samba server 192.168.2.24

    Borra las reglas de ambas nics al cabo estas en pruebas, si lo deseas sacas un respaldo por si ya tienes algo y no deseas hacerlo desde 0 cuando te funcione.

    crea una regla en tu LAN:

    TCP LAN NET TO VLAN_20_NET PUERTO 445
    TCP LAN_NET TO VLAN_20_NET PUERTO 139

    palomea que logie la reglas para que veas todo lo que hace…

    De cualquier pc de la LAN pruebas con el buen amigo telnet:

    telnet samba_ip 445/139

    Te recomiendo en la VLAN_20 crees una regla que permita todo y sobre todo palomea que logie todo, para que veas tambien que esta recibiendo.

    El samba creo que debe estar listo para poder permitir el trafico de otras redes verdad?

    A ver como te va, saludos.

    0
  • B

    Muchas gracias por tus comentarios. Realize los cambios que comentas, sin embargo, persiste el bloqueo de la conexion. Pero tambien persiste el hecho que no existe ningun registro en los logs, aun especificando esta opcion en las nuevas reglas.

    Lo que me llama la atención es que la unica forma de tener un registro de estos bloqueos es cuando habilitamos la opcion "Log packets blocked by the default rule" en Status: System logs: Settings.

    0

  • Haz una regla en ambos lados, que permita todo y que logie todo, pruebas y vez que esta haciendo!!!

    0
  • B

    Pasa lo mismo el trafico se bloquea.

    En este momento solo estoy probando con la la LAN(Datosy Servers) y una VLAN(Wireless_Internos) con las siguientes reglas

    Con estas reglas los logs que que se registran no muestran un bloqueo

    Pero cuando habilito la opcion "Log packets blocked by the default rule" se registra estos eventos que corresponden al bloqueo

    Los datos de las redes y de las ips con las que estamos probando son:

    LAN DatosyServers 192.168.15.0/24,
    Servidor de archivos : 192.168.15.1

    VLAN:Wireless_Internos 192.168.16.0/24
    Equipo : 192.168.16.48

    0
  • B

    Revisando los registros de los logs desde el shell lo que observo es lo siguiente, que corresponden a los bloqueos y que se registran cuando esta habilitada la opcion " Log packets blocked by the default rule"

    pudieran ser estos  mensajes "[bad hdr length 0 - too short, < 20]" son los que provocan el bloqueo??

    login as: admin
    Using keyboard-interactive authentication.
    Password:
    *** Welcome to pfSense 2.0.3-RELEASE-pfSense (i386) on routerpv ***

    WAN (wan)                -> em1        -> 192.168.40.5
      DATOSYSERVERS (lan)      -> em0        -> 192.168.15.10
      WIRELESS_INTERNOS (opt1)  -> sk0_vlan16 -> 192.168.16.10
      WIRELESS_INVITADOS (opt2) -> sk0_vlan21 -> 192.168.21.10
      OFFICE_INTERNET (opt3)    -> sk0_vlan20 -> 192.168.20.10
      WIRELESS_MOVILES (opt4)  -> sk0_vlan17 -> 192.168.17.10

    1. Logout (SSH only)                  8) Shell
    2. Assign Interfaces                  9) pfTop
    3. Set interface(s) IP address      10) Filter Logs
    4. Reset webConfigurator password    11) Restart webConfigurator
    5. Reset to factory defaults        12) pfSense Developer Shell
    6. Reboot system                    13) Upgrade from console
    7. Halt system                      14) Disable Secure Shell (sshd)
    8. Ping host

    Enter an option: 10

    tcpdump: WARNING: pflog0: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
    00:00:00.000000 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:00.203480 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445:  tcp 114 [bad hdr length 0 - too short, < 20]
    00:00:00.603553 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:01.207120 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:01.207011 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:01.206109 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:02.414627 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:04.828546 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:07.923052 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.2857 > 192.168.15.1.445: [|tcp]
    00:00:01.633976 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.48.2859 > 192.168.15.1.445: [|tcp]
    00:00:00.000063 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.48.2860 > 192.168.15.1.139: [|tcp]
    00:00:00.024895 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.48.2861 > 192.168.15.1.80:  tcp 28 [bad hdr length 0 - too short, < 20]
    00:00:01.582696 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.86.5353 > 224.0.0.251.5353: [|domain]
    00:00:07.023755 rule 37/8(ip-option): pass in on em0: 192.168.15.254 > 224.0.0.1: igmp query v2
    00:00:00.049867 rule 40/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.1: igmp query v2
    00:00:00.000171 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
    00:00:00.000006 rule 38/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
    00:00:00.618843 rule 40/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.2: igmp v2 report 224.0.0.2
    00:00:01.260035 rule 38/0(match): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.22: igmp v2 report 224.0.0.22
    00:00:00.000014 rule 38/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.22: igmp v2 report 224.0.0.22
    00:00:00.190516 rule 40/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.22: igmp v2 report 224.0.0.22

    0

  • Oyes, a ver si sigues en pruebas, deshabilita el firewall y observa que pasa?

    system->advanced->Firewall NAT->Disable Firewall.

    La option:

    Log packets blocked by the default rule

    Dejala habilitada.

    Saludos.

    0
  • B

    Deshabilitando el Firewall, si es posible la conexión y el paso de datos. En los registros del firewall no se registra ningun evento. Con ese cambio lo que no tengo en el equipo es salida a Internet, pero la comunicacion por SMB si es posible.

    0
  • B

    Realize una captura de paquetes en la interfaz donde esta el equipo en pruebas, con IP 192.168.16.48.

    Solo es necesario cambiar la extensión del archivo txt a cap para poder abrir el archivo y analizar la captura.

    packetcapture.txt

    0

  • Oyes, verifica esta opcion en la parte avanzada:

    Bypass firewall rules for traffic on the same interface.

    Quitala ponla…?

    0
  • B

    Al deshabilitar la opción que comentas persiste el bloqueo, estos son los registros que se generan

    tcpdump: WARNING: pflog0: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
    00:00:00.000000 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:00.230142 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:00.546918 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:01.328000 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:01.187806 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:01.202789 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:02.406252 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:04.812515 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 254 [bad hdr length 0 - too short, < 20]
    00:00:02.359110 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4139 > 192.168.15.1.445:  tcp 73 [bad hdr length 0 - too short, < 20]

    Al dejar habilitada la opción, como estaba de manera predeterminada, el bloqueo se mantiene y se generan los siguientes logs

    tcpdump: WARNING: pflog0: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
    00:00:00.000000 rule 37/8(ip-option): pass in on em0: 192.168.15.254 > 224.0.0.1: igmp query v2
    00:00:00.049853 rule 41/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.1: igmp query v2
    00:00:00.000773 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
    00:00:00.619286 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.22: igmp v2 report 224.0.0.22
    00:00:06.443711 rule 41/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.22: igmp v2 report 224.0.0.22
    00:00:00.933689 rule 42/8(ip-option): pass in on sk0_vlan17: 192.168.17.5 > 224.0.0.1: igmp query v2
    00:00:01.827844 rule 41/8(ip-option): pass in on sk0_vlan20: 192.168.20.5 > 224.0.0.2: igmp v2 report 224.0.0.2
    00:00:01.113045 rule 42/8(ip-option): pass in on sk0_vlan17: 192.168.17.5 > 224.0.0.2: igmp v2 report 224.0.0.2
    00:00:02.271259 rule 42/8(ip-option): pass in on sk0_vlan17: 192.168.17.5 > 224.0.0.22: igmp v2 report 224.0.0.22
    00:00:08.237831 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.1: igmp query v2
    00:00:02.854870 rule 39/8(ip-option): pass in on sk0_vlan16: 192.168.16.5 > 224.0.0.2: igmp v2 report 224.0.0.2
    00:00:02.219112 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4162 > 192.168.15.1.445: [|tcp]
    00:00:17.395214 rule 40/8(ip-option): pass in on sk0_vlan21: 192.168.21.5 > 224.0.0.1: igmp query v2
    00:00:03.781954 rule 40/8(ip-option): pass in on sk0_vlan21: 192.168.21.5 > 224.0.0.22: igmp v2 report 224.0.0.22
    00:00:03.562673 rule 40/8(ip-option): pass in on sk0_vlan21: 192.168.21.5 > 224.0.0.2: igmp v2 report 224.0.0.2
    00:00:18.919212 rule 1/0(match): block in on sk0_vlan16: 192.168.16.48.4164 > 192.168.15.1.445: [|tcp]

    En ambos casos reinicie el Pfsense antes de hacer las pruebas de conexión.

    0

  • Men yo me hiria a el foro gabacho, no tengo un laboratorio para ver el problema real.

    0
  • B

    Hola, Muchas gracias por todos los comentarios.
    Finalmente encontré el problema, decidí aislar todos los componentes e ir verificando su funcionamiento y todo funciona de manera correcta hasta que inicie con pruebas con algunos servidores y el problema resulta por le trafico que maneja los servers al tener diversos gateways, al trabajar con un solo gateway funciona correctamente y al tener los dos es necesario especificar el orden de las rutas para el trafico y que no cause problemas.

    Nuevamente gracias por todos sus comentarios

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2019 Rubicon Communications, LLC | Privacy Policy