Blocking of graph.facebook.com does not work

[cgone]

I put graph.facebook.com in the blacklist and mark everything with facebook in "App Control" for blocking.

Code: [Select]

nslookup graph.facebook.de (on the firewall itself):

Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
graph.facebook.de canonical name = www.facebook.com.
www.facebook.com canonical name = star-mini.c10r.facebook.com.
Name: star-mini.c10r.facebook.com
Address: 185.60.216.35
Name: star-mini.c10r.facebook.com
Address: 2a03:2880:f12d:83:face:b00c:0:25de

but "telnet 185.60.216.35 80" with "GET /" on the client still works.

Zenarmor listens on the LAN-Interface.
I have a pihole on different segment which interface is not covered by Zenarmor.
The client gets from pihole 0.0.0.0 as the ipaddress through the LAN-interface.
(Zenarmor should not use this answer from pihole anyway.)

Has Zenarmor problems with CNAME obfuscation?

[cgone]

The problem is bigger than expected, since it applies to other blocked domains, too.

I tried with other domains, which are already blocked in the reports and it seems that, if there is no valid dns request/answer before the connection attempt there connections is NOT BLOCKED!

It seems that Zenarmor relies/depends on the previous dns request to match the ip adress.

But this is a (design) flaw, since there are clients, which uses encrypted dns request (doh/dot) or have a buildin ip adress and makes no dns request at all. So Zenarmor ist not able to watch (and store) the dns response...

[mb]

Hi @cgone,

Zenarmor employs a variety of methodologies to classify applications. Hostnames and DNS Enrichment is one of them and generally used as one of the last resorts where there's not much information available in the packet payload where it can deduce enough information to come to a confident decision.

Having said that,

Can you try the telnet test by also providing the "Host" HTTP Header? eg:

Code: [Select]

telnet 185.60.216.35 80 and then enter:

Code: [Select]

GET / HTTP/1.1
Host: graph.facebook.com
Connection: close



Then you should see it blocked.

[cgone]

Hi mb,

but i am sorry, it is not blocked:

Code: [Select]

telnet 185.60.216.35 80

Trying 185.60.216.35...
Connected to 185.60.216.35.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: http://www.facebook.com/
Content-Type: text/html; charset="utf-8"
X-FB-Debug: CLbXVA7Pz8pd/PY/h+ZUyQY2LZXNliZ1lkdPovpKUscuMVS+s0M6m4Uleti3eH6vbIVbaOtT1T5uuzBk0FMEiQ==
Date: Fri, 11 Feb 2022 06:43:36 GMT
Priority: u=3,i
Alt-Svc: h3=":443"; ma=3600, h3-29=":443"; ma=3600
Connection: keep-alive
Content-Length: 0


[mb]

Hi @cgone,

It's missing the Host header. Please provide the Host header like:

Code: [Select]

GET / HTTP/1.1
Host: graph.facebook.com
Connection: close

[cgone]

(wrong result posted and deleted)

[cgone]

Ahhh. I focused on the tcp stream and Zenarmor does a introspection of the http protocol.

With the host parameter I see a block in Zenarmour while using "telnet 185.60.216.35 80"!

But with ssl the request is still fullfilled:

Code: [Select]

openssl s_client -quiet -connect 185.60.216.35:443

Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = California, L = Menlo Park, O = "Facebook, Inc.", CN = *.facebook.com
verify return:1
GET / HTTP/1.1
Host: graph.facebook.com
Connection: close

HTTP/1.1 400 Bad Request
Vary: Origin
x-fb-rlafr: 0
Content-Type: text/javascript; charset=UTF-8
WWW-Authenticate: OAuth "Facebook Platform" "invalid_request" "Unsupported get request. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api"
Access-Control-Allow-Origin: *
facebook-api-version: v6.0
Strict-Transport-Security: max-age=15552000; preload
Pragma: no-cache
Cache-Control: no-store
Expires: Sat, 01 Jan 2000 00:00:00 GMT
x-fb-request-id: AOLNGCYUGORip4rQO1SwLE3
x-fb-trace-id: FtDm7H1ss36
x-fb-rev: 1005057900
X-FB-Debug: 82VX1gs1sPkv0Nr6nhyRXSWYENcnhgeJQuhVr9jpw07ebjQLFFfd71E4Ik3qZUgkkU5BK6SCVRM2hT/JyVQXtQ==
Date: Fri, 11 Feb 2022 11:18:49 GMT
Alt-Svc: h3=":443"; ma=3600, h3-29=":443"; ma=3600
Connection: close
Content-Length: 241

{"error":{"message":"Unsupported get request. Please read the Graph API documentation at https:\/\/developers.facebook.com\/docs\/graph-api","type":"GraphMethodException","code":100,"error_subcode":33,"fbtrace_id":"AOLNGCYUGORip4rQO1SwLE3"}}read:errno=0


[mb]

Hi @cgone,

Yes, similarly, you'll need to supply servername parameter to simulate a browser behaviour:

Code: [Select]

$ openssl s_client -quiet -connect 185.60.216.35:443 -servername graph.facebook.com
4377019948:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/System/Volumes/Data/SWE/macOS/BuildRoots/5b2e67f8af/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75.60.3/libressl-2.8/ssl/ssl_pkt.c:585:
$

[cgone]

Hi @cgone,

Yes, similarly, you'll need to supply servername parameter to simulate a browser behaviour:

Code: [Select]

$ openssl s_client -quiet -connect 185.60.216.35:443 -servername graph.facebook.com
4377019948:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/System/Volumes/Data/SWE/macOS/BuildRoots/5b2e67f8af/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75.60.3/libressl-2.8/ssl/ssl_pkt.c:585:
$

I am still shocked to read this. Only a small variation of the protocol is needed to bypass Zenarmor?
I am not sure, if i should rerate Zenarmor and look for a more secure alternative.

[mb]

Hi @cgone,

I agree that this might seem like a small detail.

However, SNI is quite important for the operation of HTTP over TLS. Without the SNI information, browsers do not have a way of communicating the hostname they want to access.

For more information:

https://www.cloudflare.com/learning/ssl/what-is-sni/