However, there is a valid use for the RST flags and blindly dropping TCP connection with RST flags may introduces problem down the line to the user that is hard to debug.
tl;dr on the proposed behavior from aforementioned link
User attempts to establish a connection, the ISP maliciously forged a reply with RST from the endpoint. Normally, the connection will be reset and that’s it
Rather than resetting the connection outright, router reply with ACK
If source reply with RST again, we assume that the RST is valid and reset the connection
If source DID NOT send RST again, then it’s a malicious packet and we ignore the first RST packet
Any attempts to open blocked domain will be thrown into ERR_CONNECTION_RESET in Chrome and PR_CONNECT_RESET_ERROR in Firefox (see
…
This indicates that a middleman had sent a RST packet, masquerading as the endpoint.
first, any isp (read : routers) are mitm - in terms of traffic routing.
second, not necessarily because of those chrome or Firefox throw reset error literally means your isp doing dpi/spi (although they are permissible by law). it could be target server itself doing the rst.
third, have you ever thought about cgnat and server clusters?
I’m 100% sure those were because of DPI because the ISPs are required by law to employ DPI as part of the blocking processing (on top of DNS poisoning, which was easily bypassed nowadays with DoH/DoT and ESNI/ECH), think the Great Firewall of China but still in their adolescent, so VPN and such were still untouched, for now at least).
Because of those, a few critical websites that a lot of people in my network uses were affected for whatever reason. VPN won’t work because the traffic were quite bandwidth intensive, and redirecting traffic should be approved by the higher-ups and ta.kes time.
For now, those firewall rules on top of redirecting all DNS requests through DoH works but I’m having complaints against random sites being broken (I assume those were because the RST packet were legitimate and the endpoint already closes the connection, while the client were unaware that there is a RST request from the endpoint).
this is the last part from your referenced link above.
To help protect the router from TCP RST and SYN DoS attacks:
Issue the tcp ack-rst-and-syn command in Global Configuration mode.
host1(config)#tcp ack-rst-and-syn
Use the no version to disable this protection (the default mode).
and I don’t know which part are you in this very topic? as the isp subscribers? the isp?
but for short - as i said above - those errors probably not on your isp side, it could be the remote end sent you rst.
if you are asking whether MT / iptables could tweak tcp sequence firewalling as on your link above, maybe they could, maybe you might want to read this wiki :
Yes, it's possible to filter said RST packet but only globally, hence the unexpected problem on other sites due to legitimate RST packet being dropped. I'm looking to either (1) modify how the RST packet were processed like linked above, or (2) selectively and programmatically accept RST from legitimate response. The list of blocked sites is public (afaik) but that's a huge list.
Yes, and no. Wouldn't you help the Chinese to bypass the Great Firewall to avoid only consuming government propaganda? Wouldn't you use VPN to access otherwise Geo-restricted content? Whistleblower is usually prosecuted in a authoritarian government, wouldn't you help them post the leaks through secure channel like TOR? Look what happened in CN due to the internet being mainly contained inside. Censorship is a whole can of worms and while there is a legitimate use of it (i.e. stopping the distribution of CP), again that's a whole can of worms with a lot of ethical issues and that is not the point of this thread.
It should be from the same endpoint, as the ISP is spoofing the source IP. IIRC RST from another IP shouldn't be processed by the browser or throw another error, maybe tripping HSTS like DNS poisoning.
Sniffing the N-th packet sounds promising, I'll try to wireshark the traffic tomorrow and look if there's any pattern in the RST from the "fake" server. The connection always RST-ed before any data being received from the endpoint so maybe there's a pattern. I'd like to have a selective rules (I have a hunch that "add-src-to-address-list" will be useful) to avoid unexplained behavior.
What makes you think that, if you somehow manage to filter the injected RST packets, connection would continue? If I’d be implementing DPI, I’d first make sure that packets are actually dropped. Sending RST (both sides, so filtering on one side can’t salvage the connection) is only courtesy to both client and server (and any stateful firewalls in between) to inform them that connection is broken. Without it, browser would simply hang until some timeout expires.
The first reset will be matched and and dropped in a period of 5 seconds. The next four will be accepted or accepted because the address-list entry has timed out.
By adding more nth you can filter more reset replies. Underneath the first two reset replies are dropped within 5 seconds.
You’re putting too much credit on my government. The ISP knows that hassle = losing costumer so its kind like the streaming situation where they’re obligated to Geo-block their content by the IP owner but understand that consumer want as much content as possible or they’ll leave. It’s just CYA and thankfully a simple RST drop is suffice.
Addresses timeout on first packet sounds like what I’m looking for, thank you!
On another note, the documentation on Nth packet says its “every,packet” and honestly the explanation is quite vague, so if my understanding is correct:
5,1 means for every five packet, match the next one packet (rule matched on packet No. 6, then 12, 18, and so on)
5,2 means for every five packet, match the next two packet? (rule matched on packet No.6 and 7, 13 and 14, 20 and 21, and so on?)
Think about it you sitting, and waiting for the correct bus.
one, is take the first bus and if you not get on that bus you have to wait again for bus six or then eleven…
two, get on the second bus and if you don’t catch that one, take bus seven or even twelve…
It is not timing out, you hide (drop) the reset for the connecting table. So that it would not throw away that connection. When the server answers you the connection table is ready to receive that answer.
The timeout is there so that stored addresses do not fill up the address list while they are not needed anymore.
Forgive me for being dense, so the two rules basically means that, after a SYNs (->add to src-lists) then if the next two packet from addresses in src-lists is ACK,RST then drop it. The every 5th packet is an arbitrary number then? (i.e. 10,1 and 10,2 will achieve the same results?).
I’m surprised (not really) to see the “experts” of this forum not understanding how DPI deployments work in the service provider market space, and how authoritative regimes or malicious ones force the SPs to “Block sites” given on a list, who in turn, go to DPI vendors and buy the middle-boxes for MITM TCP Reset attacks, which is just one variant, there’s TLS 1.3/ECH blocking, there’s SNI inspection and iFrame injection and many more.
And even worse, there are legal experts on this forum now, who thinks bypassing the DPI or “great firewall of China” is a “crime”, lol.
@OP, you can drop TCP reset attacks, but it won’t work if the connection between the site and their CDN is MITM’ed by a SP. Regardless, you drop the reset like this:
five is indeed just a number abd I could have chosen two or any number higher.
It just allows to block a specific up to five times before starting again as long the dst/src address is on the list syncreset.
All traffic goes througha VPN so my ISP only sees the outside off a tunnel and not even get my DNS resolve requests. I life in the EU which is ver hungry for private information and eant to put a “camera on my shoulder” (client side scanning) to see all I type or see.
Then even the best VPN is of no use then. The EU knows then every secret you might have. Comparing the EU with China then China are the nice guys…who had ever thought that would be possible!?
The EU really wants to push China from position one of that infamous list.
Nah, you just caught lacking. You may have some networking knowledge, you may debate on networking stuff, but it's plain as day you're no lawyer, and I wouldn't be taking legal opinions from you.
I’m slightly modify the address list timeout and after a few days, with a total of ~1.2mio SYN matched, only 4k were deemed as an “attack” and blocked. Obviously there’s a false positive but overall there’s no complaints for broken websites. Thanks!