Snort y OpenAppID:Bloquear protocolos de capa 7: openvpn,Facebook,twitter



  • Hola

    Tras investigar cómo ntopng y Snort detectan loos protocolos de capa 7 ( https://forum.pfsense.org/index.php?topic=120520 , https://forum.pfsense.org/index.php?topic=120399 )

    Ahora he configurado Snort para que me bloquee en la LAN, el tráfico de OpenVPN, FaceBook y Twitter.

    Obviamente se debe añadir la interfaz LAN a Snort, configurarala sgún necesidades de tu red (hay mucha doc en el foro y google), y para bloquear: OpenVPN, Facebook y Twitter.:

    Services > Snort > RulesLAN > Lan Rules > Custom Rules: añadir las reglas

    alert tcp any any -> any any (msg:"Facebook1"; appid: facebook; sid: 9000101; classtype:misc-activity; rev:1;)
    alert udp !192.168.0.13/32 any -> any any (msg:"OpenVPN"; appid: openvpn;sid: 9000103; classtype:misc-activity; rev:1;)
    alert tcp any any -> any any (msg:"Facebook2"; appid: facebook_apps;sid: 9000105; classtype:misc-activity; rev:1;)
    alert tcp any any -> any any (msg:"Facebook3"; appid: facebook_like;sid: 9000107; classtype:misc-activity; rev:1;)
    alert tcp !192.168.0.13/32 any -> any any (msg:"Twitter1"; appid: twitter;sid: 9000109; classtype:misc-activity; rev:1;)
    

    Atendiendo de poner el sid adecuado (que no esté en uso por otra regla) y asgurándose que en Snort esté habilitado

    -    Services > Snort > Global Settings > Sourcefire OpenAppID Detectors
    Enable OpenAppID

    Click to enable download of Sourcefire OpenAppID Detectors

    -    Services > Snort > Preprocessors and Flow > LAN > Application ID Detection
    Enable

    Use OpenAppID to detect various applications. Default is Not Checked.

    Las reglas con source !192.168.0.13/32 , indican cualquier origen menos la IP 192.168.0.13 (la forma de definir una excepción en una regla de snort . No aplicamos la restricción a esa IP).

    Salu2



  • Hola

    Se me olvidaba.
    Una cosa importante a la hora de añadir una custom rule en Snort para bloquear protocolos de capa 7, es saber cómo Snort denomina los protocolos para construir la regla.

    Por ejemplo para saber todos los protocolos relacionados con FaceBook que Snort reconoce.
    Bastaria con hacer un grep filtrando lo que buscamos al volcado del fichero:

    /usr/local/etc/snort/appid/odp/appMapping.data

    [2.3.2-RELEASE][root@pfSense232a.localdomain]/root: cat /usr/local/etc/snort/appid/odp/appMapping.data | grep facebook
    149 Facebook Apps 0 0 852 ~ facebook_apps
    629 Facebook 0 161 17 ~ facebook
    4068 Facebook Like 0 0 1846 ~ facebook_like

    Y ya podremos implementar la regla, con sid adecuado (empezar por el sid 9000000 y >,  asegura que no interfiera con sids de otras reglas ya definidas)

    alert tcp any any -> any any (msg:"Facebook3"; appid: facebook_like;sid: 9000107; classtype:misc-activity; rev:1;)

    El classtype en una regla personalizada en snort en pfSense, tras leer posts del foro, se recomienda poner alguno siempre, por ejemplo : misc-activity

    @bmeeks:

    It is also vital that you always include a "classtype:" keyword in your custom rules

    Salu2



  • Ok. Me funcionan las reglas para openVPN y twitter, pero Facebook se me sigue colando por navegador  ;D



  • Hola.

    Ok. Me funcionan las reglas para openVPN y twitter, pero Facebook se me sigue colando por navegador  ;D

    Las reglas bloquean sockets TCP para Twitter y FaceBook
    Y sockets UDP para OpenVPN.

    Tras las pruebas mias, OpenVPN y Twitter bloqueado al completo y FaceBook me lo bloqueó, pero es verdad, vía navegador NO.

    La forma de saber que protocolo de capa7 (google, facebook, etc) se esta usando en una conexión SSL/TLS (encriptada) es mirando el contenido del certificado del servidor, imagino que FaceBook "hace algo" para evadir la detección …

    Una forma complementaria de bloquear FaceBook es usar DNSBL de pfBlockerNG y añadir el dominio facebook.com a la lista de bloqueos (y ahora sí que no accedo a FB ni vía navegador :) )

    Salu2



  • Ok, probaré con DNSBL



  • Hola

    Si pruebas con DNSBL, a parte del dominio bloqueado en un DNSBL feed,  también se puede definir en:
    Firewall > pfBlockerNG > DNSBL > TLD Blacklist ; facebook.com

    Y defines con eso un Top-Level Domain (facebook.com) a bloquear
    La redundancia nunca está de más :)

    Salu2



  • Ok, creo que en el TLD blocklist se pondría solo facebook,  lo miro



  • Hola

    Sí, en el TLD blacklist del DNSBL se pone el dominio de nivel alto (facebook.com => facebook), pruebalo.

    Y por cierto, rectifico, sí me bloquea Facebook (vía navegador y vía App) las reglas de Snort personalizadas, lo que pasa es que en la prueba se me olvidó dejar de navegar vía tunel ssh :) jejeje, despiste (devil is in details :) )

    Salu2



  • A mi me faltaba una regla de las 3 de FB. Todo ok.



  • Yo tengo Facebook bloqueado con pfBlockerNG, añadiendo una regla en el apartado IPv4, allí añado los ASN de facebook




  • Hola

    Yo tengo Facebook bloqueado con pfBlockerNG, añadiendo una regla en el apartado IPv4, allí añado los ASN de facebook

    Sí, pfBlockerNG es un paquete que facilita la vida mucho en el tema de bloquear sitios,, ya sea por listas de  IP , dominios (DNSBL) y ASN. Es un paquete imprescindible en pfSense :)

    Lo que ocurre es que pfSense en sus nuevas versiones abandonó el DPI (Deep packet Inspection and layer 7 filter con  ipfw-classifyd ), por su elevado consumo de CPU, y la alternativa para bloquear protocolos de capa 7 o de aplicación es Snort (o Suricata), ellos mismos lo dicen en:

    https://doc.pfsense.org/index.php/Layer_7

    _Layer 7 filtering or shaping is identifying traffic at layer 7 (Application Layer) of the OSI model.

    pfSense used to contain a Layer 7 classifier, ipfw-classifyd, but it has been removed. It was non-functional on pfSense 2.2.x and removed entirely from pfSense 2.3 because it was not feasible to fix. L7 classification consumed large amounts of CPU and rarely had the intended effect, and it was a rarely used feature even when it did function.

    For those intending to block based on L7 identification, consider using Snort instead, which can much more efficiently identify such traffic.

    Alternate L7 inspection methods may be considered for a future version if they are viable._

    Salu2



  • Hola

    Un buen ejemplo de reglas personalizadas de Snort, para bloquear Ultrasurf

    https://forum.pfsense.org/index.php?topic=48482.msg295806#msg295806

    
    # Rules by Jorge Talamas
    alert udp $HOME_NET any -> any 53 (msg:"DNS Request for www.hfdxjshm.info"; content:"|03|www|08|hfdxjshm|04|info"; metadata:service dns; nocase; classtype:policy-violation; sid:1232313; rev:1;)
    alert udp $HOME_NET any -> any 53 (msg:"DNS Request for www.rvzjon.info"; content:"|03|www|06|rvzjon|04|info"; metadata:service dns; nocase; classtype:policy-violation; sid:1232314; rev:1;)
    alert udp $HOME_NET any -> any 53 (msg:"DNS Request for www.ukwprf.info"; content:"|03|www|06|ukwprf|04|info"; metadata:service dns; nocase; classtype:policy-violation; sid:1232315; rev:1;)
    
    # Rule by SERPRO-Recife Security Team
    alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"Possible External Ultrasurf DNS Query"; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; classtype:policy-violation; detection_filter:track by_src, count 1, seconds 5; sid:1000059; rev:2;)
    
    # IP POOL by Jorge Talamas
    var ULTRASURF_POOL [1.160.0.0/16,1.161.122.228/32,1.162.0.0/16,1.163.233.171/32,1.168.0.0/13,12.48.83.220/32,24.11.192.218/31,36.227.0.15/32,36.227.75.242/32,36.229.197.181/32,36.232.154.1/32,46.22.213.8/32,46.22.214.10/32,46.37.175.62/32,46.37.180.174/32,46.105.135.99/32,46.105.135.123/32,46.105.151.18/32,46.105.224.154/32,58.138.34.200/32,59.104.160.0/19,59.112.0.0/15,59.115.0.0/16,59.121.0.0/16,61.31.128.0/19,61.62.0.0/17,61.62.192.0/18,61.216.0.0/17,61.216.128.0/18,61.223.0.0/16,61.224.0.0/16,61.227.0.0/16,61.228.0.0/16,61.230.0.0/15,63.215.202.0/24,63.223.86.79/32,63.223.100.58/32,63.223.101.44/32,63.223.102.73/32,63.223.103.77/32,63.223.124.119/32,63.226.208.180/31,63.245.209.30/31,64.4.44.80/31,64.25.35.100/31,64.25.35.200/31,64.37.73.8/32,64.120.138.55/32,64.120.206.154/32,64.191.20.238/32,64.191.124.239/32,65.49.2.12/31,65.49.14.0/24,65.175.93.68/32,65.175.93.72/32,65.175.93.76/32,66.201.71.143/32,66.201.71.145/32,66.245.218.2/31,67.19.60.8/31,68.65.210.20/32,68.65.238.190/32,69.61.28.24/32,69.61.28.51/32,69.162.176.238/32,69.162.177.246/32,69.162.177.250/32,69.162.179.250/32,69.162.180.238/32,69.162.180.244/32,69.162.180.250/32,69.162.181.241/32,69.162.181.248/32,69.162.182.250/32,69.162.183.246/32,69.162.185.239/32,69.162.185.247/32,69.162.186.245/32,69.162.187.239/32,69.162.189.240/32,69.162.189.246/32,69.162.190.247/32,69.162.191.248/32,70.32.68.126/31,72.21.194.0/24,72.21.203.148/31,72.21.211.170/31,72.21.214.0/24,72.69.176.100/31,74.80.131.100/32,74.80.152.203/32,74.80.167.179/32,74.80.181.109/32,74.127.24.68/32,74.127.52.39/32,74.127.52.42/32,76.191.99.99/32,76.191.102.131/32,76.191.103.56/32,76.191.105.5/32,76.191.105.20/32,76.191.114.32/32,80.79.125.53/32,91.121.253.92/32,95.143.33.144/32,95.143.33.179/32,96.9.133.170/32,96.9.174.174/32,101.128.162.236/31,111.240.0.0/14,111.248.0.0/13,112.104.0.0/17,112.104.128.0/18,112.104.192.0/19,112.105.64.0/18,112.105.128.0/19,112.105.192.0/18,113.197.194.198/31,114.24.0.0/14,114.36.0.0/14,114.40.0.0/13,118.160.0.0/15,118.165.0.0/16,118.166.0.0/15,118.168.0.0/14,122.118.0.0/16,122.120.0.0/14,122.124.162.0/24,122.125.0.0/16,122.126.0.0/15,123.204.74.103/32,123.204.96.0/19,123.205.224.0/19,124.8.72.25/32,124.9.128.0/17,124.11.53.0/24,124.11.128.0/17,124.12.0.0/17,125.224.0.0/15,125.227.0.0/16,125.229.0.0/16,125.230.0.0/16,125.231.91.188/31,125.232.0.0/15,126.126.189.185/32,128.120.32.96/31,129.59.210.100/31,149.5.113.168/32,173.208.227.209/32,173.212.193.131/32,173.212.193.142/32,173.212.193.156/32,174.24.248.14/31,175.180.64.0/18,175.180.128.0/17,175.181.64.0/18,175.181.128.0/17,175.182.0.0/17,184.26.194.70/31,184.82.51.116/32,184.82.113.169/32,184.82.137.235/32,184.82.145.69/32,184.82.205.136/32,195.43.51.21/32,199.114.216.57/32,199.114.217.39/32,199.114.219.83/32,199.114.219.93/32,199.217.100.54/32,199.217.101.32/32,199.217.101.61/32,199.217.102.49/32,203.67.0.0/19,203.67.116.201/32,203.73.50.4/31,203.73.55.210/31,203.73.192.0/18,205.251.242.164/31,207.195.235.35/32,207.195.235.195/32,208.117.17.239/32,208.117.18.242/32,208.117.19.250/32,208.117.22.249/32,208.117.23.246/32,208.117.26.239/32,208.117.27.241/32,208.117.29.246/32,208.117.29.250/32,208.117.31.240/32,210.64.96.0/19,211.74.96.0/19,211.74.191.68/31,212.69.166.19/32,212.69.169.54/32,212.69.191.38/32,212.69.191.237/32,216.13.11.50/31,216.13.113.50/31,216.15.183.18/32,216.15.183.27/32,216.198.215.3/32,216.198.220.120/32,216.198.220.126/32,218.160.0.0/14,218.165.0.0/16,218.166.0.0/15,218.168.0.0/14,218.173.0.0/16,218.174.0.0/15,219.80.130.234/31,219.84.192.0/18,219.85.128.0/17,220.100.55.208/32,220.129.0.0/16,220.131.0.0/16,220.136.0.0/16,220.138.0.0/16,220.141.0.0/16,220.142.0.0/15]
    
    alert tcp $HOME_NET any -> $ULTRASURF_POOL 443 (msg:"Ultrasurf Connection Detected"; flow:established; classtype:policy-violation; sid:5000000; rev:3;)
    alert tcp $HOME_NET any -> $ULTRASURF_POOL 10000 (msg:"Ultrasurf Connection Detected"; flow:established; classtype:policy-violation; sid:5000001; rev:3;)
    
    

    Salu2



  • La pega es que el pool de servidores ultrasurf así en una regla de Snort es estático,  lo interesante seria programarlo dinámico,  como hace pfBlockerNG



  • Hola

    Lo veo dificil en una custom rule, no conozco si Snort permite scripting en sus reglas, (variables si permite)

    Salu2



  • Hola

    Una cosa que se me ocurre para obtener el pool de servidores Ultrasurf dinamicamente seria:

    En el fichero de conf de snort (snort.conf), añadir que incluya otro fichero:

    http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node16.html

    include

    por ejemplo pool-surf-snort.inc

    Donde se defina y reescriba la variable ULTRASURF_POOL con la lista actualizada de servidores (esto ya seria tarea de un cron que vía scripting reescriba ese fichero con los valores actualizados, y de esa forma, creo que cada vez que actualice snort se refrescaria)

    Pero no lo he testeado, si lo hago aviso :)

    Salu2



  • Hola

    Pues tras leer en el foro. Parece ser que bloquear en destino Ultrasurf no es muy viable. Ya que usa servidores Google, Amazon, etc, y si bloqueamos esas IPs bloqueamos otros servicios  y recursos (Google, Amazon, etc).

    Pero he visto unas reglas personalizadas de Snort para bloquear Ultrasurf en origen según el contenido de la petición:

    Referencia: https://forum.pfsense.org/index.php?topic=91163.msg515530#msg515530

    alert tcp any any -> 192.168.1.254 any (content:"|48 6f 73 74 3a 20 73 75 70 70 6f 72 74 2e 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 3a 34 34 33 0d 0a|"; msg:"ultrasurf14 pacote suportmicrosoft"; dsize:266<>270; gid:120; sid:1509; rev:1;)
    alert tcp any any -> 192.168.1.254 any (content:"|47 45 54 20 68 74 74 70 3a 2f 2f 77 77 77 2e 67 6f 6f 67 6c 65 2e 63 6f 6d 2f 20 48 54 54 50 2f 31 2e 31 0d 0a|"; dsize:137<>139; msg:"ultrasurf13_12 pacote google"; gid:120; sid:1510; rev:1;)
    alert tcp any any -> 192.168.1.254 any (content:"|36 35 2e 34 39 2e 31 34 2e|"; content:"|34 34 33|"; msg:"ultrasurf10 pacote 65.49.14.0/24:443"; gid:120; sid:1511; rev:1;)
    

    Me rsulta curioso que Ultrasurf use servidores de Google (y con certificados de Google!!!).

    ¿Es Ultrasurf el TOR particular de Google? :) … a saber

    ref: http://www.maravento.com/2014/05/ultrasurf-secuestra-ips-de-google-y.html

    Salu2


Log in to reply