Can iptables block TCP RST packets only?
in [UK Linux]
|
Prev: Compiling WiFi driver
Next: Curl RTE only runs as root
From: Tony Mountifield on 24 Feb 2010 04:33 In article <7uftufFqfbU1(a)mid.individual.net>, James Taylor <usenet(a)oakseed.demon.co.uk.invalid> wrote: > There is no separate hardware firewall. I am refering to "iptables", the > software firewall on my Linux computer. I am trying to use iptables to > drop some spoofed TCP RST packets that are prematurely breaking some > large video downloads. I believe they are being spoofed by the ISP to > prevent me from downloading so much. I am within my rights to download > this legitimate media, so I want to bypass the ISPs meddling by > filtering out the spoofed RST packets. Am I wrong to use iptables for this? There may be another complication, if you are using an external router that provides NAT service (e.g. the router has a public IP on its WAN interface, but all your internal boxes are on 192.168.x.x). In that situation, the router has to maintain a session table of all open connections, so that it can translate the private IP:port of a connection into a corresponding public IP:port. If the router receives a RST packet from the remote end, then as well as translating it and passing it on to the internal host, it might also mark the session as terminated, causing the router to stop passing data packets through. I've never had reason to investigate or observe such behaviour, but it seems quite possible to me that it might occur. Cheers Tony -- Tony Mountifield Work: tony(a)softins.co.uk - http://www.softins.co.uk Play: tony(a)mountifield.org - http://tony.mountifield.org
From: Tom Anderson on 24 Feb 2010 19:47 On Wed, 24 Feb 2010, James Taylor wrote: > Tom Anderson wrote: >> James Taylor wrote: >>> Tony wrote: >>>> James Taylor wrote: >>>> >>>>> Just to follow up, I found the above to be wrong. More careful study of >>>>> the TCP sequence numbers and packet arrival times reveals that the ISP >>>>> must be sending a RST packet to *both* ends. >>>> >>>> Shame, can you tunnel the download over ssh or something? >> >> Like the server - any chance it will talk IPsec to you? Raw or over UDP >> would solve this problem. > > I didn't know IPsec could be wrapped in UDP. I guess doing this would > allow IPsec to work through NATs. Is that correct? Yes. And firewalls that block protocols that aren't TCP and UDP. > Is IPsec over UDP a recent innovation or has it always been part of the > way IPsec works? Pass. The Cisco VPN client has done it for ages, and it's possible it's largely a Ciscoism, although i believe it is a standard. > Unfortunately, in this case I do not control the servers and thus have > to put up with the various TCP connections provided. I may be able to > tunnel out past my current ISP (assuming they don't just kill my tunnel) > but the real question is where to end the tunnel. Oh well, no point worrying about that, though. >> If the download is over HTTP, you could split it into N chunks, and >> download each in parallel using a separate connection with a suitable Range >> header. You could then throttle the connections (or let them be throttled >> naturally) so that no single one of them is fat enough to attract the >> attention of the strangler. > > That's an interesting approach. The question is how? Is there any > software I can get to automate this? Special wget or curl options? There are almost certainly wget or curl options for this. Man page time, i'm afraid. > Is there any way iptables can be used to throttle individual TCP flows? Pass. But there's definitely a throttle option on at least one of wget and curl. >>> Maybe someone cleverer than me can see a technical solution, but I can't >>> see how you can bypass a middleman who sends RSTs to both ends, >> >> Prevent the RSTs from happening, or use UDP, which doesn't care. > > Neither are possible without changing the server, and that does not > belong to me. I can only use such techniques to tunnel and then we're > back to the problem of where to put the other end. Throttling your connections will (i hope) prevent the RSTs from happening. tom -- Hesgadin. It was in two parts - both of them silent. I remember this map came with a letter accusing me of stealing eggs. I had never understood the relationship of the map to the accusation. I still don't, but I'm grateful for the map.
From: James Taylor on 24 Feb 2010 21:31 Darren Salt wrote: > James Taylor wrote" > >> Precise use of terms is always preferable but rarely can you defeat the >> tide of common usage. If "firewall" is an inappropriate term, what would >> you describe iptables as? You could probably call it a "packet filter" with >> reasonable accuracy, but that term seems even more vague. > > It isn't that either. > > It's a convenient utility for viewing and altering netfilter's IPv4 > configuration. Aha, yes of course, but then the question becomes what to call netfilter? PS. Hi Darren, its a small world, in Usenet land anyway. Are you still using RISC OS, or are you entirely Linux now? I had to abandon RISC OS (kicking and screaming) years ago when I left the UK for a life of travelling with a laptop, and frankly I'm now rather glad to be a Linux user, although I've never reclaimed on this platform the assembler and GUI programming skill level I had on RISC OS. -- James Taylor
From: James Taylor on 24 Feb 2010 21:35 Tony Mountifield wrote: > James Taylor wrote: > >> I am trying to use iptables to drop some spoofed TCP RST packets >> that are prematurely breaking some large video downloads. I believe >> they are being spoofed by the ISP to prevent me from downloading so >> much. I am within my rights to download this legitimate media, so I >> want to bypass the ISPs meddling by filtering out the spoofed RST >> packets. Am I wrong to use iptables for this? > > There may be another complication, if you are using an external router > that provides NAT service (e.g. the router has a public IP on its WAN > interface, but all your internal boxes are on 192.168.x.x). Yes, I am. > In that situation, the router has to maintain a session table of all > open connections, so that it can translate the private IP:port of a > connection into a corresponding public IP:port. If the router receives > a RST packet from the remote end, then as well as translating it and > passing it on to the internal host, it might also mark the session as > terminated, causing the router to stop passing data packets through. Actually the NAT table entry does not timeout for some while. It certainly doesn't get wiped the very moment it sees a RST. -- James Taylor
From: James Taylor on 24 Feb 2010 21:50
Tom Anderson wrote: > James Taylor wrote: > >> Is IPsec over UDP a recent innovation or has it always been part of >> the way IPsec works? > > Pass. The Cisco VPN client has done it for ages, and it's possible it's > largely a Ciscoism, although i believe it is a standard. Ah, now that you mention it, I recall I've seen this from a Cisco VPN. >> That's an interesting approach. The question is how? Is there any >> software I can get to automate this? Special wget or curl options? > > There are almost certainly wget or curl options for this. Man page time, > i'm afraid. Hmmm, I don't remember seeing any for multi-server multi-connection downloads but I will check. Another issue is that not all of the downloads are over HTTP. Some are RTSP/RTMP and that may not be supported by either tool. >> Is there any way iptables can be used to throttle individual TCP flows? > > Pass. But there's definitely a throttle option on at least one of wget > and curl. Hmmm, now that you mention it, I do recall seeing a throttling option in one of them (wget I think). That could be useful. However, it would certainly be much easier to throttle the downloads with iptables (or some other filter utility) than it would be to hack the source code of the downloader utility I'm using to replace every type of connection with a wget/curl equivalent. Indeed that may not even be possible. > Throttling your connections will (i hope) prevent the RSTs from happening. If I can find a simple way to throttle, I'm certainly keen to try it. -- James Taylor |