Can iptables block TCP RST packets only?
in [UK Linux]
|
Prev: Compiling WiFi driver
Next: Curl RTE only runs as root
From: James Taylor on 20 Feb 2010 18:19 Hi, I have discovered what I believe to be spoofed TCP reset packets being injected into the stream to kill some large downloads I am trying to make. I know the RST packets didn't come from the server I am downloading from because I can see normal data-bearing packets arriving after the RST packets and with later sequence numbers. It is probably some half-wit attempt by the ISP to limit my downloads. The problem is that when my computer receives the RST packets the connection breaks and the download stops. If I could get my computer to ignore these RSTs then I believe the connection would continue and my downloads would complete. Is there any way that I can use iptables to filter these RST packets from a specific set of IP addresses corresponding to the servers in question? A quick dip in the iptables man page has rather overwhelmed me with the learning curve required, but also encouraged me when I saw there was a --tcp-flags option. Can anyone help me by showing me how to form a complete iptables command line to block the RST packets? -- James Taylor
From: Tony on 21 Feb 2010 03:06 In uk.comp.os.linux, James Taylor <usenet(a)oakseed.demon.co.uk.invalid> wrote: >Can anyone help me by showing me how to form a complete iptables command >line to block the RST packets? http://tuxtraining.com/2008/06/21/beating-sandvine-on-linux-with-iptables If whoever is doing it, is doing it 'right' though, then you're in trouble because they'll be sending RST's to both ends of the connection, as far as I understand it. Slashdot discussion, http://tech.slashdot.org/article.pl?sid=08/06/30/0249249 -- Tony Evans Saving trees and wasting electrons since 1993 blog -> http://perceptionistruth.com/ books -> http://www.bookthing.co.uk/ [ anything below this line wasn't written by me ]
From: Graham Murray on 21 Feb 2010 04:06 James Taylor <usenet(a)oakseed.demon.co.uk.invalid> writes: > I have discovered what I believe to be spoofed TCP reset packets being > injected into the stream to kill some large downloads I am trying to > make. I know the RST packets didn't come from the server I am > downloading from because I can see normal data-bearing packets > arriving after the RST packets and with later sequence numbers. It is > probably some half-wit attempt by the ISP to limit my downloads. Is it possible that by spoofing the IP address of the server you are connected to that whoever is doing this is contravening the Computer Misuse Act or some other legislation?
From: James Taylor on 21 Feb 2010 04:24 Graham Murray wrote: > James Taylor writes: > >> I have discovered what I believe to be spoofed TCP reset packets being >> injected into the stream to kill some large downloads I am trying to >> make. I know the RST packets didn't come from the server I am >> downloading from because I can see normal data-bearing packets >> arriving after the RST packets and with later sequence numbers. It is >> probably some half-wit attempt by the ISP to limit my downloads. > > Is it possible that by spoofing the IP address of the server you are > connected to that whoever is doing this is contravening the Computer > Misuse Act or some other legislation? I wish I knew enough about the law on this kind of thing because it is appealing to think that I could throw the book at them. However, I suspect that the ISP are within their rights to manage and balance data flow across their network in line with the goal of providing reasonable service to all users. To that end I could accept a degree of bandwidth throttling. What I object to is having connections terminated entirely. -- James Taylor
From: James Taylor on 21 Feb 2010 05:28
Tony wrote: > <iptables command> -p tcp --dport 36745 --tcp-flags RST RST -j DROP; > > What I'm not 100% sure about is whether it's an iptables -A INPUT, or > iptables -I FORWARD, I've seen various options and without going and > checking the manual myself, I'm not sure which to use. But that's the only > command you need (where 36745 is the port you're doing the transfer over) Ok, thanks. I'll check those options and get my head around it. -- James Taylor |