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 22 Feb 2010 18:45 James Taylor wrote: > Tony wrote: > >> 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. > > Yes, you'd expect them to send RSTs to both ends, but they seem to be > sending them only to my end because I can see plenty of normal data > packets arriving from the other end with later TCP sequence numbers than > are in the spoofed RSTs. 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. I do see RST packets with sequence numbers earlier *in sequence* than normal data packets, but these RSTs arrive later *in time* than all normal data packets. The pattern seems to be like this: The first RST that I see arrives immediately after the last data packet and it has a sequence number placing it correctly after the data packet. Then, after a short delay I see several RSTs with earlier sequence numbers corresponding to the data packets that I have recently ACKed. My conclusion is that the first RST is the spoofed one sent by the ISP to tear down the connection, and the remaining RSTs are bounced by the server itself when it gets my ACKs for data packets it has already sent on a connection it now believes to be reset (because it was also sent a spoofed RST packet by the ISP). Hope that makes sense. -- James Taylor
From: Tony on 22 Feb 2010 18:56 In uk.comp.os.linux, James Taylor <usenet(a)oakseed.demon.co.uk.invalid> wrote: >James Taylor wrote: > >> Tony wrote: >> >>> 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. >> >> Yes, you'd expect them to send RSTs to both ends, but they seem to be >> sending them only to my end because I can see plenty of normal data >> packets arriving from the other end with later TCP sequence numbers than >> are in the spoofed RSTs. > >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? -- 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: James Taylor on 22 Feb 2010 19:14 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? Actually, due to the multi-faceted nature of the download setup process I think it would have to be a VPN rather than a simple port-based ssh tunnel. The real problem is not the tunnelling, it's the fact that the tunnel has to end somewhere so that the naked connection can continue on to the server itself. I would be using both the upload and download capacity of the VPN endpoint's Internet line fairly heavily so I'd need to own that line or have a very friendly relationship with its owner. Which ISP should I choose for this line and, given that my own ISP is monkeying around with my downloads, what guarantee is there that the new ISP won't do the same? 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, and I can see no easy way to get a VPN endpoint in the UK with guaranteed unfettered high-bandwidth low-cost Internet access. -- James Taylor
From: Tom Anderson on 23 Feb 2010 08:43 On Tue, 23 Feb 2010, 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? > > Actually, due to the multi-faceted nature of the download setup process I > think it would have to be a VPN rather than a simple port-based ssh tunnel. > > The real problem is not the tunnelling, it's the fact that the tunnel has to > end somewhere so that the naked connection can continue on to the server > itself. Like the server - any chance it will talk IPsec to you? Raw or over UDP would solve this problem. 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. I have a vague memory that you said it was bittorrent. I would have thought that would be fairly tolerant of killed connections. Maybe it would benefit from having more connections, each running slower? I know BT suffers from going too far that way, but it beats being stabbed. > 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. tom -- Tristan Tzara offered to create a poem on the spot by pulling words at random from a hat. A riot ensued and Andre Breton expelled Tzara from the movement.
From: James Taylor on 23 Feb 2010 17:41
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? >> >> Actually, due to the multi-faceted nature of the download setup >> process I think it would have to be a VPN rather than a simple >> port-based ssh tunnel. >> >> The real problem is not the tunnelling, it's the fact that the tunnel >> has to end somewhere so that the naked connection can continue on to >> the server itself. > > 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? Is IPsec over UDP a recent innovation or has it always been part of the way IPsec works? 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. > 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? Is there any way iptables can be used to throttle individual TCP flows? > I have a vague memory that you said it was bittorrent. No, BitTorrent was mentioned by someone else. My downloads are a mixture of HTTP and RTSP. If it were possible to use BitTorrent then I don't think I'd have any problem with connections getting broken; throttled perhaps, but not broken. >> 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. -- James Taylor |