Como interpretar los bloqueos



  • Buenas a todos, figurense que mi pfsense esta trabajando bastante estable, he tenido algunas quejas de algunos usuarios que me comentan que hay ciertas paginas que no les abre y estuve revisando los bloqueos y me encuentro con algo como esto

    Nov 27 13:22:28 LAN 192.168.0.15:137 192.168.0.255:137 UDP
    Nov 27 13:23:30 LAN 192.168.0.19:1926 200.30.139.5:80 TCP
    Nov 27 13:23:30 LAN 192.168.0.19:1928 200.30.139.5:80 TCP
    Nov 27 13:23:33 LAN 192.168.0.19:1926 200.30.139.5:80 TCP
    Nov 27 13:23:33 LAN 192.168.0.19:1928 200.30.139.5:80 TCP
    Nov 27 13:23:35 LAN 192.168.0.19:1930 209.85.237.103:80 TCP
    Nov 27 13:23:38 LAN 192.168.0.19:1930 209.85.237.103:80 TCP
    Nov 27 13:23:38 LAN 192.168.0.19:1926 200.30.139.5:80 TCP

    como se puede interpretar, a donde querian entrar y no los dejo, etc., alguien me puede ayudar?



  • ¡Hola!

    Es frecuente ver bloqueos de este tipo en las conexiones http porque el usuario "abandona" sin más la web.

    Si no se puede ir a un sitio concreto o es debido a alguna regla incorrecta (de cortafuegos o de squid, si lo empleas) o a una no-resolución de DNS.

    Tendrías que indagar más con tus usuarios y probar, a ser posible, al mismo tiempo que ellos …

    Saludos,

    Josep Pujadas



  • Gracias Bellera por contestar, estare probando junto con los usuarios, pero quisiera saber un poquito mas sobre esas lineas, por ejemplo
    en la siguiente me dice que fue el 27 de nov., a las 13:23, de la terminal con terminacion 15, el siguiente numero no se a que se debe, me supongo que es el puerto que en este caso es el 1926 y de alli la direccion que sigue no se a que se refiere y nuevamente un puerto que ahora es el 80 por tcp, alguna lucesita que me puedan aclarar mas mi duda.

    Nov 27 13:23:38 LAN 192.168.0.19:1926 200.30.139.5:80 TCP

    Gracias nuevamente.



  • ¡Hola!

    Estación 192.168.0.19 con puerto 1926 (abierto dinámicamente por el navegador) va hacia 200.30.139.5 puerto 80, es decir, http.

    Y (seguramente) te aparece en el registro de bloqueos porque las conexiones http no tienen una operación de "logout", con lo que queda una especie de resto de la transmisión.

    Si haces http://200.30.139.5 en tu navegador verás qué web es.

    Haciendo nslookup 200.30.139.5 no me resuelve (desde Barcelona-Cataluña-España) ningún nombre para esta IP. ¿Tienes squid funcionando? Lo digo porque con squid es posible bloquear las direcciones que no tienen resolución inversa. Yo lo hago, no me gusta permitir IPs que no tienen nombre en Internet. Igual hay un problema relacionado con esto. Tendrías que preguntar al usuario cómo entra, si por IP o por nombre. Si entra por nombre casi seguro que hay un problema de resolución DNS (de fuera).

    Saludos,

    Josep Pujadas



  • Hola a todos,

    Entiendo que en el caso expuesto "Nov 27 13:23:38 LAN 192.168.0.19:1926 200.30.139.5:80 TCP" se bloqueo una comunicacion tipo tcp ubicada en el puerto 80, el detalle esta que en las reglas de seguro esta permitido el trafico tcp en el puerto 80 desde la lan hacia la wan, y en este caso se intento una comunicacion tcp desde la lan en un puerto dinamico no permitido hacia un puerto 80 tcp en la wan y el firewall lo bloqueo…

    ahora me pregunto... tengo entonces que colocar una regla que habilite la comunicacion tcp desde la wan hacia la lan tcp en el puerto 80 para evitar este bloqueo??? ???  y esto seria seguro? ya que al parecer es una comunicacion tcp normal... o me equivoco??? ???



  • ¡Hola!

    Insisto en que estos registros no tienen importancia en el caso de los accesos http. A mi también me llamaron la atención al principio de usar pfSense y Scott Ullrich (uno de los desarrolladores) me dijo en un correo que son típicos de PF, al dejar (más bien cortar) el cliente la conexión.

    Por otro lado, si haceis clic en la aspa del registro de bloqueo vereis qué regla está provocando esto y, en principio, debería ser la default del cortafuegos. La reglas que uno mismo configura no aparecen en el registro a menos que se haya marcado que interesa loguearlas.

    Saludos,

    Josep Pujadas



  • Gracias señores por contestar, pues fijate que la ip en mencion si entra normalmente aca en Guatemala, Guatemala, y una de mis preocupaciones es que de las 50 lineas del system log firewall, se llenan en aproximadamente 15 minutos, entonces no si estara bien, hay alguno que otro usuario que me ha dicho que a veces entran normal a las paginas y despues esas mismas paginas ya no las pueden acceder, me deja mucho que pensar, ademas porque el navegador esta tratando de usar dinamicamente el puerto 1926, ese esta bloqueado, ya que segui tu recomendacion para bloquear el p2p, en donde tengo abierto solamente estos, con balanceo de carga

    correoalias  25, 995, 465, 80, 110  Puertos de correo   
    httpsalias  443  Salida de https  (dirigido a un router)
    tcpalias  80, 21, 53, 119, 20, 22, 123  http,ftp,dns,nntp,ftp(datos),ssh,ntp   
    udpalias  53, 119, 123  dns, nttp, ntp

    ademas que en el log hay peticiones en los puertos 137
    Nov 27 13:22:28 LAN 192.168.0.15:137 192.168.0.255:137 UDP
    y son mucho, no se, si puede haber un spyware o algo parecido en las pcs, aunque tengo mi servidor debian, uso samba, pero no sale nada a internet, es solamente en servidor interno.
    Gracias por todo.



  • @bellera:

    ¡Hola!

    Insisto en que estos registros no tienen importancia en el caso de los accesos http. A mi también me llamaron la atención al principio de usar pfSense y Scott Ullrich (uno de los desarrolladores) me dijo en un correo que son típicos de PF, al dejar (más bien cortar) el cliente la conexión.

    Por otro lado, si haceis clic en la aspa del registro de bloqueo vereis qué regla está provocando esto y, en principio, debería ser la default del cortafuegos. La reglas que uno mismo configura no aparecen en el registro a menos que se haya marcado que interesa loguearlas.

    Saludos,

    Josep Pujadas

    Saludos…
    Bellera entendida tu aclaratoria, de hecho todos los bloqueos que he visto apuntan a la regla por defecto del pfsense, ahora como modifico esta regla "por defecto"?  otra pregunta como habilito ver el log de las reglas creadas por el usuario como tu comntas en el post??..  gracias bellera por tus comentarios...



  • byrpa,

    porque el navegador esta tratando de usar dinamicamente el puerto 1926, ese esta bloqueado

    No. El cierre de puertos dinámicos se refiere a puertos de destino, no de origen. Por favor, mírate bien:

    http://www.bellera.cat/josep/pfsense/cabal_cs.html#altra

    En origen no se corta nada, se permite todo. Es en destino que sólo se permiten una serie de puertos. Los clientes abren los puertos automáticamente (en origen) para ir a un puerto de destino concreto. Por ejemplo, si van a un servidor web van normalmente al 80, en destino.

    Basta con que en una máquina Windows emplees la orden netstat para ver lo que te estoy diciendo … No te asustes, porque verás muchas conexiones entre la propia máquina (es normal).

    hay alguno que otro usuario que me ha dicho que a veces entran normal a las paginas y despues esas mismas paginas ya no las pueden acceder

    Tiene pinta de problemas de resolución DNS. Testea bien desde los clientes empleando nslookup. Verifica también con ipconfig qué servidores DNS tienen configuradas las estaciones.

    ademas que en el log hay peticiones en los puertos 137
    Nov 27 13:22:28 LAN 192.168.0.15:137 192.168.0.255:137 UDP
    y son mucho, no se, si puede haber un spyware o algo parecido en las pcs, aunque tengo mi servidor debian, uso samba, pero no sale nada a internet, es solamente en servidor interno.

    Es normal. Toda red Windows emplea 137 UDP para su "master browser". Esto quiere decir que hay siempre una máquina que se erige como "examinador de la red" y envía broadcast (dirección 255 del rango de IPs) para confeccionar la lista de equipos en funcionamiento. Es decir, sin esto no existiría "Equipos próximos" en las máquinas Windows. Para no ver esto en los logs te bastará con poner una regla de bloqueo de LAN a LAN para el puerto UDP 137. Así no molesta en los logs. Como la interfase LAN pertenece al rango lógicamente recibe los broadcast.

    sanchezluis,

    ahora como modifico esta regla "por defecto"?

    Es la que ejecuta al final de todas las que pongas, como seguridad. Por defecto todo está denegado. Todas las reglas que pongas se ejecutarán antes que la default. Entiendo pues que no hay necesidad de meterse a modificar la default, entre otras cosas porque sería "salirse del guión" de la interfase gráfica.

    como habilito ver el log de las reglas creadas por el usuario como tu comntas en el post?

    Fácil. Fíjate que cuando estás editando una regla hay una casilla de "Enable login". ¡Ojo! En sistemas embedded no es recomendable, ya que las CF (Compact Flash) tienen una vida limitada en cuanto a escrituras; a no ser que se emplee un servidor de logs externo -cuestión prevista-. En disco duro ningún problema.

    ¡¡¡¡De nada!!!!

    Saludos,

    Josep Pujadas


Log in to reply