Overcoming blocking in TTC (Transtelecom) with pf
After reading the article by the respected ValdikSS, I decided to study the DPI of my provider and, with favorable developments, find ways to circumvent it. Below are the results of my research.
So, the provider is TTK Ulyanovsk (formerly DARS Telecom), PPPoE connection with external IP allocation for the duration of the session. Blocking is accomplished by wrapping blocked subnets / hosts on your DPI. DNS is not replaced.
And some sites are simply and simply blocked by IP (thanks at least send RST). For example, Rutreker's bt-announcers:
For the same sites where you need to show the blocking page, passive DPI works. Consider the example of Rutreker:
')
Let's look at this conclusion in more detail. From 605860 to 646913, the client performs a triple handshake with the "real" Rutreker. In 647281, the client sends an HTTP request to Rutreker, 77 bytes long, but instead of the usual ACK, FPA with a 246 bytes HTTP redirection receives from the fake Rutreker. And note that with the correct ACK 78, but the left, within this TCP connection, the sequence number is SEQ. Next, the client closes the connection and goes to where they said. ACK and HTTP response from Rutreker never come.
In principle, it is clear why the provider needed this strange TCP with FPA flags: FIN to start terminating the connection from the client, PUSH to push this segment into the client's TCP queue, and the correct ACK to make everything look beautiful and this “fake” TCP segment did not TCP / IP client stack was dropped. But this FPA killed him.
So, the main strategy is to discard TCP segments with FPA flags set, as if coming from addresses of blocked resources.
FreeBSD works on the old Atom as a router in my home network, pf works with a packet filter. The main problem was that pf is a statefull firewall, i.e. after our first allowed outgoing SYN, a record (state) and all subsequent requests are added to the Rutreker state table, and all subsequent requests and, most importantly, the answers within this TCP connection do not go through any firewall rules anymore.
This behavior greatly increases the performance of the firewall and reduces the number of rules, but in our case prevents effective filtering. Therefore, all requests / responses to the blocked resources will be made in stateless mode, i.e. without saving the state. In pf, the rules are as follows:
The no state directive in the permitting rules prohibits state saving, the first rule in the UNBLOCK block allows outgoing to a blocked resource, the second rule blocks “fake” incoming with FPA flags set, the third one allows all other incoming ones. The quick directive in all rules stops the firewall from viewing all subsequent filter rules if it matches this rule. Result (triple handshake omitted):
221343 - HTTP request to Rutreker
237686 - response from provider DPI with FPA flags (dump from the external interface of the router, so it is visible here; the client does not receive it)
563977 - the client did not wait for an answer, repeats the request
604853 - Real Rutreker sends ACK
605043 - the real Rutreker sends an HTTP response
PS The same can be done with the help of any modern firewall, pf here just because I use it. Also, an attentive reader might have noticed that the IP-spoofing carried out by the DPI provider is elementarily detected by IP TTL (58 vs. 61). But pf does not know how to filter all fields of IP packets, only the main ones. When using other firewalls, IP TTL mismatch can be used as an additional sign of a “fake” packet, along with TCP FPA.
That's All Folks!
So, the provider is TTK Ulyanovsk (formerly DARS Telecom), PPPoE connection with external IP allocation for the duration of the session. Blocking is accomplished by wrapping blocked subnets / hosts on your DPI. DNS is not replaced.
% traceroute ya.ru traceroute to ya.ru (87.250.250.242), 64 hops max, 40 byte packets 1 bras.ulttk.ru (79.132.125.1) 0.899 ms 0.787 ms 0.817 ms 2 ulk06.ulk26.transtelecom.net (217.150.41.98) 1.552 ms 1.536 ms 1.536 ms 3 * * * 4 Yandex-gw.transtelecom.net (188.43.3.213) 21.828 ms 15.955 ms 17.003 ms % traceroute rutracker.org traceroute to rutracker.org (195.82.146.214), 64 hops max, 40 byte packets 1 bras.ulttk.ru (79.132.125.1) 1.778 ms 0.843 ms 0.751 ms 2 ulk06.ulk26.transtelecom.net (217.150.41.98) 1.656 ms 1.698 ms 1.439 ms 3 * * * 4 188.43.0.18 (188.43.0.18) 16.589 ms BlackList-gw.transtelecom.net (188.43.30.130) 16.435 ms BL-gw.transtelecom.net (188.43.31.170) 16.377 ms 5 Filter-gw.transtelecom.net (188.43.30.33) 17.006 ms 16.859 ms 17.080 ms % traceroute kinozal.tv traceroute: Warning: kinozal.tv has multiple addresses; using 104.24.107.53 traceroute to kinozal.tv (104.24.107.53), 64 hops max, 40 byte packets 1 bras.ulttk.ru (79.132.125.1) 0.810 ms 0.809 ms 0.739 ms 2 ulk06.ulk26.transtelecom.net (217.150.41.98) 1.653 ms 1.802 ms 1.736 ms 3 * * * 4 Filter-gw.transtelecom.net (188.43.30.34) 16.451 ms BL-gw.transtelecom.net (188.43.31.170) 16.405 ms 16.418 ms 5 Filter-gw.transtelecom.net (188.43.30.33) 99.751 ms 78.541 ms 17.021 ms 6 Cloudflare-msk-gw.transtelecom.net (188.43.3.65) 212.754 ms 107.803 ms 117.062 ms 7 104.24.107.53 (104.24.107.53) 28.015 ms 17.216 ms 17.357 ms And some sites are simply and simply blocked by IP (thanks at least send RST). For example, Rutreker's bt-announcers:
02:48:58.530078 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) ip109.176.ulttk.ru.22099 > bt.rutracker.org.http: Flags [S], cksum 0xd538 (correct), seq 3425095266, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 1991139339 ecr 0], length 0 02:48:58.546482 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 40) bt.rutracker.org.http > ip109.176.ulttk.ru.22099: Flags [R.], cksum 0x13b9 (correct), seq 0, ack 3425095267, win 0, length 0
For the same sites where you need to show the blocking page, passive DPI works. Consider the example of Rutreker:
')
02:27:28.605860 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [S], cksum 0xeafc (correct), seq 3703194126, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 1989849414 ecr 0], length 0 02:27:28.646812 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 48) rutracker.org.http > ip109.176.ulttk.ru.27338: Flags [S.], cksum 0x81d2 (correct), seq 2683499593, ack 3703194127, win 14600, options [mss 1400,nop,wscale 8], length 0 02:27:28.646913 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [.], cksum 0xe266 (correct), seq 1, ack 1, win 1028, length 0 02:27:28.647281 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 117) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [P.], cksum 0xb1d5 (correct), seq 1:78, ack 1, win 1028, length 77: HTTP, length: 77 GET / HTTP/1.1 Host: rutracker.org User-Agent: curl/7.56.0 Accept: */* 02:27:28.663665 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 286) rutracker.org.http > ip109.176.ulttk.ru.27338: Flags [FP.], cksum 0xf88c (correct), seq 1:247, ack 78, win 0, length 246: HTTP, length: 246 HTTP/1.1 301 Moved Permanently 02:27:28.663724 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [.], cksum 0xe126 (correct), seq 78, ack 248, win 1024, length 0 02:27:28.664047 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [F.], cksum 0xe121 (correct), seq 78, ack 248, win 1028, length 0 02:27:28.695429 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) ip109.176.ulttk.ru.42348 > dib-filtr-gw.transtelecom.net.http: Flags [S], cksum 0x0556 (correct), seq 2835326510, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 1989849504 ecr 0], length 0
Let's look at this conclusion in more detail. From 605860 to 646913, the client performs a triple handshake with the "real" Rutreker. In 647281, the client sends an HTTP request to Rutreker, 77 bytes long, but instead of the usual ACK, FPA with a 246 bytes HTTP redirection receives from the fake Rutreker. And note that with the correct ACK 78, but the left, within this TCP connection, the sequence number is SEQ. Next, the client closes the connection and goes to where they said. ACK and HTTP response from Rutreker never come.
In principle, it is clear why the provider needed this strange TCP with FPA flags: FIN to start terminating the connection from the client, PUSH to push this segment into the client's TCP queue, and the correct ACK to make everything look beautiful and this “fake” TCP segment did not TCP / IP client stack was dropped. But this FPA killed him.
So, the main strategy is to discard TCP segments with FPA flags set, as if coming from addresses of blocked resources.
FreeBSD works on the old Atom as a router in my home network, pf works with a packet filter. The main problem was that pf is a statefull firewall, i.e. after our first allowed outgoing SYN, a record (state) and all subsequent requests are added to the Rutreker state table, and all subsequent requests and, most importantly, the answers within this TCP connection do not go through any firewall rules anymore.
This behavior greatly increases the performance of the firewall and reduces the number of rules, but in our case prevents effective filtering. Therefore, all requests / responses to the blocked resources will be made in stateless mode, i.e. without saving the state. In pf, the rules are as follows:
WAN="ng0" LAN="re0" Blocked="{ .IP1, .IP2, .IP3, .. }" ... # -UNBLOCK- # for LAN hosts pass in quick on $LAN proto tcp from $LAN:network to $Blocked no state block drop out quick on $LAN proto tcp from $Blocked to $LAN:network flags FPA/FPA pass out quick on $LAN proto tcp from $Blocked to $LAN:network no state # -UNBLOCK- # for me (router itself, for testing) pass out quick on $WAN proto tcp from ($WAN) to $Blocked no state block drop in quick on $WAN proto tcp from $Blocked to ($WAN) flags FPA/FPA pass in quick on $WAN proto tcp from $Blocked to ($WAN) no state ...
The no state directive in the permitting rules prohibits state saving, the first rule in the UNBLOCK block allows outgoing to a blocked resource, the second rule blocks “fake” incoming with FPA flags set, the third one allows all other incoming ones. The quick directive in all rules stops the firewall from viewing all subsequent filter rules if it matches this rule. Result (triple handshake omitted):
01:48:10.221343 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 117) ip109.176.ulttk.ru.42714 > rutracker.org.http: Flags [P.], cksum 0xccb6 (correct), seq 1:78, ack 1, win 1028, length 77: HTTP, length: 77 GET / HTTP/1.1 Host: rutracker.org User-Agent: curl/7.56.0 Accept: */* 01:48:10.237686 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 286) rutracker.org.http > ip109.176.ulttk.ru.42714: Flags [FP.], cksum 0x136e (correct), seq 1:247, ack 78, win 0, length 246: HTTP, length: 246 HTTP/1.1 301 Moved Permanently 01:48:10.563977 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 117) ip109.176.ulttk.ru.42714 > rutracker.org.http: Flags [P.], cksum 0xccb6 (correct), seq 1:78, ack 1, win 1028, length 77: HTTP, length: 77 GET / HTTP/1.1 Host: rutracker.org User-Agent: curl/7.56.0 Accept: */* 01:48:10.604853 IP (tos 0x0, ttl 58, id 42669, offset 0, flags [DF], proto TCP (6), length 40) rutracker.org.http > ip109.176.ulttk.ru.42714: Flags [.], cksum 0x00c5 (correct), seq 1, ack 78, win 58, length 0 01:48:10.605043 IP (tos 0x0, ttl 58, id 42670, offset 0, flags [DF], proto TCP (6), length 422) rutracker.org.http > ip109.176.ulttk.ru.42714: Flags [P.], cksum 0x9bc5 (correct), seq 1:383, ack 78, win 58, length 382: HTTP, length: 382 HTTP/1.1 301 Moved Permanently Server: nginx Date: Thu, 26 Oct 2017 21:48:10 GMT Content-Type: text/html Content-Length: 178 Location: http://rutracker.org/forum/index.php Connection: keep-alive
221343 - HTTP request to Rutreker
237686 - response from provider DPI with FPA flags (dump from the external interface of the router, so it is visible here; the client does not receive it)
563977 - the client did not wait for an answer, repeats the request
604853 - Real Rutreker sends ACK
605043 - the real Rutreker sends an HTTP response
PS The same can be done with the help of any modern firewall, pf here just because I use it. Also, an attentive reader might have noticed that the IP-spoofing carried out by the DPI provider is elementarily detected by IP TTL (58 vs. 61). But pf does not know how to filter all fields of IP packets, only the main ones. When using other firewalls, IP TTL mismatch can be used as an additional sign of a “fake” packet, along with TCP FPA.
That's All Folks!
Source: https://habr.com/ru/post/341266/
All Articles