Can iptables block TCP RST packets only?
in [UK Linux]
|
Prev: Compiling WiFi driver
Next: Curl RTE only runs as root
From: David Bolt on 24 Feb 2010 04:34 On Tuesday 23 Feb 2010 22:41, while playing with a tin of spray paint, James Taylor painted this mural: > Tom Anderson wrote: >> 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? Try aria2. It's able to use multiple servers, with multiple connections to each server, while downloading files. You can find the sources here: http://aria2.sourceforge.net/ Regards, David Bolt -- Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s openSUSE 11.0 32b | | | openSUSE 11.3M1 32b openSUSE 11.0 64b | openSUSE 11.1 64b | openSUSE 11.2 64b | TOS 4.02 | openSUSE 11.1 PPC | RISC OS 4.02 | RISC OS 3.11
From: Nigel Wade on 24 Feb 2010 05:06 On Tue, 23 Feb 2010 00:41:33 +0700, James Taylor wrote: > Nigel Wade wrote: > >> James Taylor wrote: >> >>> If I've understood it correctly, the full command line for blocking >>> RST packets coming from the download servers in my case is: >>> >>> # iptables -A INPUT -p tcp -s 92.123.153.0/24 --sport 1935 \ >>> --tcp-flags RST RST -j DROP >>> >>> And I can check that the rule exists with: >>> >>> # iptables -n -v -L INPUT >>> Chain INPUT (policy ACCEPT 436K packets, 526M bytes) pkts bytes target >>> prot opt in out source destination >>> 114 4560 DROP tcp -- * * 92.123.153.0/24 0.0.0.0/0 >>> tcp spt:1935 flags:0x04/0x04 >>> >>> The above report shows 114 matching packets during the course of a >>> download I tried, but unfortunately the resets are still getting >>> through the firewall... well, I can still see them in Wireshark and >>> the connections are still getting broken and having to be recontinued. >> >> Since you mention a firewall, is this rule really on a firewall? > > There is no separate hardware firewall. I am refering to "iptables", the > software firewall on my Linux computer. Ok, the problem is one of ambiguity in the term "firewall". In it's original meaning a firewall is an external device which protects internal networks and has at least 2 interfaces. But the term has been abused by vendors of both software "firewalls" and mock "firewalls" in routers, that the term now conveys little meaning, and much confusion, without additional information. > 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? Yes, I understand your intent from the thread. Blocking the RST packets may do what you want, but RST packets are used for perfectly valid and legitimate reasons on normal connections, so throwing them all away may result in other, strange issues. The question is, are you absolutely certain that these RST packets are being inserted by your ISP? Have you tried contacting your ISP for an explanation? They could be perfectly legitimate RST packets sent by the other end if that end has prematurely closed the socket (maybe the other end has crashed). If your connection is going via a NAT router the router may flush the NAT entry after a certain amount of inactivity, and it might send RSTs to ensure the connection is dropped - or it might be a bug in the routers NAT implementation. The other end could be using iptables and flushing/loading the rules or in some other way causing problems to the traffic flow e.g. flushing then loading new rules when ESTABLISHED,RELATED is not set might cause existing connections to have RST sent (I don't know this for certain, but it might be a cause). > >> The INPUT chain on the firewall is used to filter packets which >> terminate at the firewall itself. > > Yes, which is why the INPUT chain is the correct one to use in this case > I think. Please correct me if that's not right. Yes, in your context you want the INPUT chain. > >> The other point to note is that iptables rules do not work in >> isolation, they are part of a chain. Packets are dealt with by the >> first rule they match. You cannot just add/insert a rule into a chain >> without considering the other rules which precede it. Another rule >> prior to the rule you've added may be accepting the packets. > > Well, if you look at the iptables -n -v -L INPUT command I show above > you'll see exactly what the INPUT chain contains; just one rule to drop > RST packets from that particular IP range. Did I do this incorrectly? Looks ok to me, if that's the only rule. > >>> Can anyone tell me whether Wireshark *should* see the pre-firewall >>> traffic or not? How can I use Wireshark to see only the packets that >>> pass through the firewall? >> >> Yes, wireshark sees packets before they get to iptables module. If it's >> a firewall, capture packets on the internal interface. > > My computer has only one Ethernet interface. How can I point Wireshark > at the already filtered traffic to check that iptables is working as > expected? I don't know any way to do that. You may want to log the dropped packets before you discard them. At least that way you'd know that the rule is actually being invoked. Is there any way to monitor the connection on the other end, and determine what's really going on? -- Nigel Wade
From: James Taylor on 24 Feb 2010 09:50 David Bolt wrote: > Try aria2. It's able to use multiple servers, with multiple connections > to each server, while downloading files. You can find the sources here: > > http://aria2.sourceforge.net/ Ok, thanks, I'll look into that. -- James Taylor
From: James Taylor on 24 Feb 2010 14:15 Nigel Wade wrote: > James Taylor wrote: > >> There is no separate hardware firewall. I am refering to "iptables", the >> software firewall on my Linux computer. > > Ok, the problem is one of ambiguity in the term "firewall". In it's > original meaning a firewall is an external device which protects internal > networks and has at least 2 interfaces. But the term has been abused by > vendors of both software "firewalls" and mock "firewalls" in routers, > that the term now conveys little meaning, and much confusion, without > additional information. 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. > Blocking the RST packets may do what you want, but RST packets are > used for perfectly valid and legitimate reasons on normal connections, > so throwing them all away may result in other, strange issues. Well it results in some connections timing out instead of terminating immediately. If there were a lot of simultaneous connections this might become a resource hog, but in my case there are not so many and I can live with this timeout behaviour during downloads. Also, note that I am only blocking RST packets from the IP range of the servers in question which happens to be a /24 block owned by Akamai. > The question is, are you absolutely certain that these RST packets are > being inserted by your ISP? No I cannot be certain that it is them. It could be some other middleman. It seems unlikely that Akamai's CDN severs themselves would be terminating connections prematurely. I don't see what their motivation would be and they have more than enough capacity. I'm not sure who else would care. Only in the case of my ISP can I see a motive. > Have you tried contacting your ISP for an explanation? Haha! Have you ever tried asking an ISP technical questions? They never seem to have people who know what they're doing available to customers. Instead they have support monkeys who assume that if they don't understand your question then it must be *you* that's clueless, and they make little attempt to disguise their contempt. Drives me nuts! > They could be perfectly legitimate RST packets sent by the other end if > that end has prematurely closed the socket (maybe the other end has > crashed). It is certainly possible that Akamai might terminate all connections with a RST instead of the normal FIN handshake, just because it's a few less packets. But this isn't the full explanation because the files being downloaded are not complete when the connections are reset and so downloads must be resumed multiple times until they are complete. > If your connection is going via a NAT router the router may > flush the NAT entry after a certain amount of inactivity, But there is no inactivity during the course of a download, of course. > and it might send RSTs to ensure the connection is dropped - or it > might be a bug in the routers NAT implementation. I've had the same router for years and not encountered this kind of thing before. Also, the downloads were all working fine a week or so ago. These connection resets only started happening a couple of days before I started this thread. > The other end could be using iptables and flushing/loading the rules > or in some other way causing problems to the traffic flow e.g. > flushing then loading new rules when ESTABLISHED,RELATED is not set > might cause existing connections to have RST sent (I don't know this > for certain, but it might be a cause). Well, you certainly seem to know more about iptables than I do. What exactly is "ESTABLISHED,RELATED", and what does it mean to be flushing and loading rules? > You may want to log the dropped packets before you discard them. At least > that way you'd know that the rule is actually being invoked. Sounds like a good idea. I'm new to iptables, would you be kind enough to show me the best way to do that kind of logging? > Is there any way to monitor the connection on the other end, and > determine what's really going on? I can't see how I would do that short of getting a job with Akamai. -- James Taylor
From: Darren Salt on 24 Feb 2010 17:26
I demand that James Taylor may or may not have written... [snip] > 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. [snip] -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army | + http://www.youmustbejoking.demon.co.uk/ & http://tartarus.org/ds/ Sorry, you'll have to type up. I can't read you. |