0

I appear to be a victim of TCP reset attacks with the purpose of preventing me from downloading specific data. I know this is the case at this stage.

For the time being I am staying at a hotel and so I do not have access to the router firewall here, but my question is: Would it be possible to prevent TCP reset style attacks through iptables?

What I have attempted to do is block RST (and FIN) packets with iptables like so:

iptables -I OUTPUT -p tcp --tcp-flags ALL RST -j DROP iptables -I INPUT -p tcp --tcp-flags ALL RST -j DROP (Same for FIN packets)

However, the attacker still appears able to kill the connection -- from analysing wireshark I can see that an RST packet was still sent from my IP to the server. I do not see why it would send this given the iptables settings.

Would it not still be possible for an attacker connected to the same LAN to send an RST packet to the server and kill my connection? In that case I guess I will need control over the networks firewall - which I don't at this time.

A VPN does not prevent the attack -- presumably because the attacker is aware of the server I am using.

I also want to point out that I am using qubes, with all Internet traffic going through the sys-net qube where the iptables rules are active

What I'm looking for is a way to mitigate these kinds of attack, even while using a firewall and blocking these packets it appears the connection can still be killed by a determined attacker, with little evidence on my side from wireshark -- I presume they send the packets themselves to the server with my ip spoofed.

Improve this question
3
  • Honestly, the obvious things like "use a VPN" or a bad connection can be ruled out at this stage. My Internet was otherwise fine on my phone/browser, it was only specific downloads which would cancel consistently, for days on end, but other connections were fine. This also happened at my home network also - the situation is more complex than this.
    – jkayes_
    Commented Jun 21, 2021 at 5:46
  • 1
    copy pasting the comment I wrote on the same question asked on SF ( serverfault.com/questions/1067236/…) : "Also a case where a TCP RST is a symptom rather than an attack is when two nodes in the same network use the same IP address by mistake, but this would affect more than TCP then. On linux you can check with the arping command in DAD mode (-D) (on both sides)" . I would add that 1/ rst comes from hotel so this would be at the hotel side 2/ if it's an attack rather than an actual misconfiguration arping might not find anything anyway.
    – A.B
    Commented Jun 21, 2021 at 14:27
  • "I can see that an RST packet was still sent from my IP to the server" It's also possible the use of iptables and REJECT rules is the cause of TCP RST. That's now documented in iptables there: manpages.debian.org/iptables/… (see the Warning). This would happen in presence of retries and "lost packets" finally arriving: probably favorised by an hotel environment.
    – A.B
    Commented Mar 26 at 17:20

2 Answers 2

Reset to default
1

A VPN does not prevent the attack -- presumably because the attacker is aware of the server I am using.

If they are in position to monitor your traffic to be able to send RSTs to you, they can just as easily send fake RSTs to the server, which you can do nothing about. Once that's done, the server will stop sending you data anyway, and the resets received by you from the server would be completely legitimate (so ignoring them is useless).

TCP itself can't really guard against reset attacks effectively (whereas later transport and tunnel protocols such as QUIC or Wireguard were designed with that in mind), so changing the network to make the traffic inaccessible to the attacker seems like the only option.

Workarounds depend on where the attacker is between you and the server. VPNs might be more effective when your VPN server is far away from you (and maybe closer to the target server). For example, a VPN endpoint that happens to be in the same datacenter as the target server should work very well (this can be easy to accomplish if the site is hosted on a public cloud provider).

Improve this answer
4
  • "When using a VPN, it might be useful to enable strict "reverse path filtering", so that" seems to be incomplete. Is a chunk of your answer missing?
    – DavidPostill ♦
    Commented Jun 20, 2021 at 13:50
  • This post made sense to me -- simply using a VPN isn't enough -- I assume because they can then connect to the same VPN server and send an RST packet with that IP. In fact, at my home Internet, the attacker was even able to kill a tor connection. I did eventually download the file I needed by using another LAN elsewhere, which implies they might have had access.
    – jkayes_
    Commented Jun 21, 2021 at 5:54
  • If that's the case (though somewhat unlikely), then the answer would be "get a VPN that they cannot connect to". But I was thinking more about the specific VPN tunnel protocol itself being susceptible to similar attacks. (In theory, at least. It's difficult to aim for realistic guesses from this side of the internet.)
    – grawity_u1686
    Commented Jun 21, 2021 at 6:11
  • Yes I think a dedicated IP vpn might work, but I would have to fork out more cash and it is by no means garenteed. I still can't see how they killed the tor connection though... I know China uses thus kind of attack regularly against it's people but I am a UK citizen. It is worth the community knowing about it because it does seem to be a vulnerability.
    – jkayes_
    Commented Jun 21, 2021 at 7:25
0

Since you are staying in a hotel, the TCP reset attacks might not be specifically aimed at you. I can see two possibilities:

  • The hotel's router has been compromised, or some other routing node that is between the hotel and the internet
  • The hotel's internet connection is poor and causes disconnection.

Here is how bad connection can cause TCP reset, from Wikipedia TCP reset attack:

One common application is the scenario where a computer (computer A) crashes while a TCP connection is in progress. The computer on the other end (computer B) will continue to send TCP packets since it does not know that computer A has crashed. When computer A reboots, it will then receive packets from the old pre-crash connection. Computer A has no context for these packets and no way of knowing what to do with them, so it might send a TCP reset to computer B. This reset lets computer B know that the connection is no longer working. The user on computer B can now try another connection or take other action.

A scenario where the connection is broken, will be very similar to the effect that a computer crash in the above description.

It might be that you are not under attack, just suffering from a bad connection.

You could contact the hotel staff, asking them to contact their ISP. In the worst case where they are unable to help, you could resort to using your phone as a hotspot.

Improve this answer
2
  • Yeah, honestly this is a lot more complex than the detail I have discussed here and all the obvious things like "bad connection", "use a vpn" have been tried. I have never experienced a connection so bad that a specific file fails to download consistently for several days in a row, but the Internet ony phone/browser still seems fine.
    – jkayes_
    Commented Jun 21, 2021 at 5:44
  • If it works for the phone but not for the hotel connection, then the problem is with the hotel. I have once been in a hotel that had a system fir throttling the extensive use of their internet that caused me a lot of problems.
    – harrymc
    Commented Jun 21, 2021 at 8:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .