TCP vulnerability
Since no one's mentioned it yet, apparently there was a change in plans. It was just released a day early. http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat And the official one: http://www.uniras.gov.uk/vuls/2004/236929/index.htm Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
On Tue, Apr 20, 2004 at 10:36:48AM -0700, Grant A. Kirkwood wrote:
Since no one's mentioned it yet, apparently there was a change in plans. It was just released a day early.
http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat
And the official one:
Allow me to quote some of my favorite parts for a second:
Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).
The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper Slipping In The Windo: TCP Reset Attacks, presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or window) of the expected sequence number. The window makes TCP reset attacks practicable.
Sooooooooooooooooooooooooooooooooooo... This begs the question... Exactly how much research DID it take to read RFC793 page 37, which clearly states: Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state. This is not rocket science, every TCP stack in existance implements this exactly this way. The fact that ANYONE ever thought it was 2^32 packets to hit upon the sequence number for a forged reset shows pure ignorance and an inability to read on their part, but the massive amount of confusion, rumor, and worry which the major router vendors (Cisco and Juniper) created by essentially rediscovering the god damn spec and then telling only their major customers about so that only rumors could filter down to the rest of the industry is absolutely pathetic. If you have a support contract and were not told about this "attack" (if you could call it that) or were blatantly misinformed as many people seem to have been, you should demand to know why you didn't receive better treatment. Bottom line, this attack is no more practical now than it was yesterday. Let's run some numbers for a second shall we. First off, as I'm sure everyone knows, BGP sessions are formed when one side establishes a tcp connection from a high numbered ephemeral port to port 179. Both sides actively attempt to connect to each other on and off through an alternating series of Connect and Active states, but eventually one side will connect to the other and only one session will survive the collision handling process. Now, let us just use Juniper as a worst case example, since they seem to have a very very restricted set of ephemeral ports for some reason or another (low 1024 high 5000, 3976 possible ports). Given the default settings of a recvsockbuf size 16384, the maximum advertised receive window will be 16384. This cuts the total sequence space to be scanned down from 2^32 to 2^32 / 2^14 = 262144 packets. Now, even though the outbound port is a simple incrementation, an outside party has no way to know what the current number is (and in the case of long lived connections it may not do them any good at all, though theoretically routers just rebooted could be more vulnerable). It is also impossible for an outside party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. Anyone who seriously wanted to protect against this attack could easily deploy RST rate limits against their management interfaces, rather than run around trying to set up MD5 with every peer. As a long term improvement, a random ephemeral port selection process could be used. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Tue, 20 Apr 2004, Richard A Steenbergen wrote:
Anyone who seriously wanted to protect against this attack could easily deploy RST rate limits against their management interfaces, rather than run around trying to set up MD5 with every peer. As a long term improvement, a random ephemeral port selection process could be used.
Insufficient to completely protect against the identified vulnerabilities. Please continue reading.
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:
party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. <snip> I dont understand why the large differences in claims
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt says Modern operating systems normally default the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535 RST segments (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). With the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier. Also, with the various 'bots' at peoples disposal, why the assumption the attack would not be distributed. ---Mike
On Apr 20, 2004, at 9:23 PM, Mike Tancsa wrote:
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:
party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. <snip> I dont understand why the large differences in claims
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
says Modern operating systems normally default the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535 RST segments (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). With the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier.
You missed the "(assuming the attacker can accurately guess both ports)" part. This is BY NO MEANS a given. In fact, it is pretty much guaranteed to not be a given on any router which has not recently been rebooted. (Or at least that the attacker doesn't know has been recently rebooted. :)
Also, with the various 'bots' at peoples disposal, why the assumption the attack would not be distributed.
Who made that assumption? I do not see it above. Also, if you have a 'bot army at your disposal, it is trivial to packet a router off the 'Net - orders of magnitude easier than guessing sequence / port number - and faster too. In fact, you can probably do it in far less than 200 seconds, more or less 59 hours. And then you take down *all* BGP sessions, not just the one in question. Since miscreants are at least as lazy as you and I, would someone explain to me why they would bother trying to guess the sequence & port numbers, even with this new "vulnerability", rather just just packet the router off the 'Net? Especially now that we have made it easier by forcing the router to calculate MD5 signatures on each packet.... Honestly, once the hysteria dies down, I think we will be going to all our peers and asking to take the MD5 stuff off. I honestly believe we will suffer more downtime - and longer downtime - from MD5 keys going out of sync than any RST style attack. If people are really worried about this, then they should ingress filter at the leaf nodes. If they did, no one could spoof the source IP of your neighbor router and life would be good. Add on things like the TTL hack and you have at least as good a protection as the MD5 gives you without any issues of higher CPU, 1000s upon 1000s of keys to manage, and all the other associated risks. But we all know people will not bother source filtering leaf nodes. Everyone will clamor about MD5 keys and how you should be protecting BGP sessions. Kinda like guarding the windows while the doors are open and unattended. -- TTFN, patrick
You missed the "(assuming the attacker can accurately guess both ports)" part.
This is BY NO MEANS a given. In fact, it is pretty much guaranteed to not be a given on any router which has not recently been rebooted. (Or at least that the attacker doesn't know has been recently rebooted. :)
A significant number of BGP sessions will be with a source port of 11000, 11001 or 11002; BGP sessions are generally quite stable and Cisco routers start the source port at 11000. So attackers could cause enough disruption just targeting these three source ports. The other thing the attacker has to guess is which router established the BGP session. As to IPs which sessions exist on, they can guess from traceroute each inter-provider hop. Answering another poster's concern about DoS risk... TCP MD5 is not a significant DoS risk as you only MD5 once the source, destination, sequence, etc are valid - ie. you only MD5 a packet which would already have broken your BGP session! [*] Worse than breaking the session, I'm told by people who have tested in labs that they could typically break BGP sessions in under half an hour, which then caused flapping and dampening of the routes if the attack was repeated. So the risk is not just the occasional BGP session flap, it's a frequent enough flap that your routes can be dampened. So, you're best to implement TCP MD5 on your BGP sessions. With an up to date IOS, if you both implement the password within about a second, the BGP session doesn't even flap to implement the password. Older IOS (12.1) resets the BGP session as a password is set. Other vendors vary. David. [*] in any reasonable implementation. it is possible some old implementation does this wrong, though.
On Apr 20, 2004, at 11:09 PM, David Luyer wrote:
You missed the "(assuming the attacker can accurately guess both ports)" part.
This is BY NO MEANS a given. In fact, it is pretty much guaranteed to not be a given on any router which has not recently been rebooted. (Or at least that the attacker doesn't know has been recently rebooted. :)
A significant number of BGP sessions will be with a source port of 11000, 11001 or 11002; BGP sessions are generally quite stable and Cisco routers start the source port at 11000. So attackers could cause enough disruption just targeting these three source ports. The other thing the attacker has to guess is which router established the BGP session. As to IPs which sessions exist on, they can guess from traceroute each inter-provider hop.
Really? I certainly hope an attacker tries those three ports on a router I know about. Looking at a random cisco router at a random NAP with a significant number of peers, there are a total of zero session on those ports. Wow, this attack is even easier to avoid than I thought! Thanx for proving my point....
Answering another poster's concern about DoS risk... TCP MD5 is not a significant DoS risk as you only MD5 once the source, destination, sequence, etc are valid - ie. you only MD5 a packet which would already have broken your BGP session! [*]
Interestingly, cisco confirmed to me the sequence number was not checked until after the MD5 signature was checked. Again, thanx for proving my point. You really must post more often.
Worse than breaking the session, I'm told by people who have tested in labs that they could typically break BGP sessions in under half an hour, which then caused flapping and dampening of the routes if the attack was repeated. So the risk is not just the occasional BGP session flap, it's a frequent enough flap that your routes can be dampened.
I would love to see these results, as I am interested in the methodolofy. For instance, did they turn on a lab router, configure some new BGP sessions, then attack it? Notice that both Richard and I repeatedly say "for a router which has not recently been rebooted". Of *course* it will be easy when you set things up like that. Even granting the results, flapping a BGP session once per half hour is far from the worst thing 10 Kpps can do on the Internet. In fact, it is probably the *least* damaging thing I have heard miscreants do with 10 Kpss.
So, you're best to implement TCP MD5 on your BGP sessions.
Many people also report taking entire routers down in far less than 30 minutes with 10 Kpps of MD5 signed packets if MD5 is turned on. So I am not sure why this is better - sorry, best - than flapping a session every half hour. Guess we did not agree on this one. I really think flapping a session every 30 minutes (if it really only takes that long) is not better than killing a whole router in far less time.
With an up to date IOS, if you both implement the password within about a second, the BGP session doesn't even flap to implement the password. Older IOS (12.1) resets the BGP session as a password is set. Other vendors vary.
And how do you track a thousand passwords? Okay, maybe that is not too hard. But how do you guarantee a thousand peers will never screw up and forget, lose, fat-finger, etc. a single one of them? This one I would really like to know, 'cause I sure as hell can't figure it out.
[*] in any reasonable implementation. it is possible some old implementation does this wrong, though.
Guess IOS counts as both old and unreasonable. I buy that. Again with the agreement! Well, three out of four ain't bad. :) -- TTFN patrick
Hi, Patrick. ] Really? I certainly hope an attacker tries those three ports on a ] router I know about. Looking at a random cisco router at a random NAP ] with a significant number of peers, there are a total of zero session ] on those ports. The ephemeral ports are used for active opens, not passive opens. In other words there won't be a listener bound on the ephemeral ports. Try nmap'ing the source port you use to SSH to TCP 22 on a remote server, for example - same negative result. That doesn't mean it isn't using the "closed" port as a source port. :) Or did I misunderstand the post? I'm low on coffee tonight. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On 20 Apr 2004, at 23:40, Patrick W.Gilmore wrote:
And how do you track a thousand passwords? Okay, maybe that is not too hard.
Right :-)
But how do you guarantee a thousand peers will never screw up and forget, lose, fat-finger, etc. a single one of them? This one I would really like to know, 'cause I sure as hell can't figure it out.
If someone forgets a password, you talk on the phone and agree a new one, and apply it to both sides. It's the same kind of procedure that I guess we would follow if peers spontaneously forgot our IP addresses or AS numbers. Or you could just tell them what their password is, since you have all the details in your peering database (see above). (If the reaction to this is "hey, not everybody has a peering database you know" then people should let me know; we can tidy up and publish the postgres schema that we use if there is interest). Joe
A significant number of BGP sessions will be with a source port of 11000, 11001 or 11002; BGP sessions are generally quite stable and Cisco routers start the source port at 11000. So attackers could cause enough disruption just targeting these three source ports. The other thing the attacker has to guess is which router established the BGP session. As to IPs which sessions exist on, they can guess from traceroute each inter-provider hop.
Really? I certainly hope an attacker tries those three ports on a router I know about. Looking at a random cisco router at a random NAP with a significant number of peers, there are a total of zero session on those ports.
Wow, this attack is even easier to avoid than I thought!
Thanx for proving my point....
OK, if you look at half a dozen routers from vendor C, do a 'sh ip bgp nei | in port', depending on the stability of your network and peering sessions I would expect at least 1 in 4 will be in the 11000 to 11099 range based on some slightly wider searching. Granted it's not "the port is always X", but it's also not true randomization, and most OSs have some constrained range of ports which will be used (eg. Linux which has a sysctl tunable "ip_local_port_range") and sequential scanning. Admittedly, on one large looking glass, I couldn't find any peers in the 11000 to 11099 range; however that range has been quite popular in stable production networks I have looked at. My initial scan covered routers with _very_ stable BGP sessions (up for months) - for non-multihop BGP, the sessions often come up just after router reboot and stay up for a very long time. A few sessions had numbers nowhere near this - which would imply that once you've killed the existing BGP sessions once, the new session is likely to use a harder to predict port number if the router has been up a long time. Unless you can also extract the current port numbers from the router somehow (remembering that most routers use sequential allocation); there are some cases where you may be able to trick a router into making an outbound tcp connection and look at the source port (if rsh is enabled or there's any other way to trigger an outbound connection). Also if the router is a looking glass or is connected to a looking glass you can find the port number of the looking glass session and you can then attempt to kill the looking glass session and see what port number it comes back at, giving you a couple of hints as to the port number other sessions may be at.
And how do you track a thousand passwords? Okay, maybe that is not too hard. But how do you guarantee a thousand peers will never screw up and forget, lose, fat-finger, etc. a single one of them? This one I would really like to know, 'cause I sure as hell can't figure it out.
The passwords are saved in your router config CVS repository. They are not encrypted, they are only encoded or stored in plain text, so you can recover (decode) them if you need to move between platforms. You can also store them in your tracking system or wherever else you store such data. Or in the worst case you can negotiate new passwords if you've lost your records. And if you're thinking of customer passwords, worried about saving passwords in your config repository and don't want to augment your customer information systems with the data -- then you can make some kind of non-reversible hash (eg. md5-based) to generate the passwords based on the two BGP peers' IP addresses.
[*] in any reasonable implementation. it is possible some old implementation does this wrong, though.
Guess IOS counts as both old and unreasonable. I buy that.
Again with the agreement! Well, three out of four ain't bad. :)
If this is true, and more CPU is used in checking a MD5 signature than in checking the ports and sequence number, then I'm sure it won't be long until someone logs a bug with Cisco to change the situation. David.
On 2004-04-20-23:09:31, David Luyer <david@luyer.net> wrote: [...]
Answering another poster's concern about DoS risk... TCP MD5 is not a significant DoS risk as you only MD5 once the source, destination, sequence, etc are valid - ie. you only MD5 a packet which would already have broken your BGP session! [*] [...]
If only this were true. Fact of the matter is, MD5 computation/verification is not cheap, and many Cisco and Juniper platforms aren't designed to handle a barrage of MD5-hashed TCP packets. We've found that ower-end Cisco gear, like the kind your customers would use for DS1/DS3 CPE, is particularly flaky in this regard, though even a Juniper RE2-333-768 could be made to fall over with < 20mb/s of traffic, as was pointed out earlier. All things considered, I think MD5 authentication will lower the bar for attackers, not raise it. I'm sure code optimizations could fix things to some degree, but that's just not the case today. Which begs the question, what is one to do, shy of moving (private) peering/transit/customer /31's and /30's into non-routable IP space, which opens up an entirely new can of worms? Differentiating between legitimate "directly connected" and spoofed traffic is a Good Thing(tm), and the TTL hack sounds great on paper, but isn't exactly easy to implement when you consider that vendor J and others can't filter based upon TTL... yet.
[*] in any reasonable implementation. it is possible some old implementation does this wrong, though.
Try IOS 12.0S, JunOS 6.2, etc... the kind of stuff still in wide deployment. -a
ASR> Date: Wed, 21 Apr 2004 06:44:14 -0400 ASR> From: Adam Rothschild ASR> [T]he TTL hack sounds great on paper, but isn't exactly easy ASR> to implement when you consider that vendor J and others ASR> can't filter based upon TTL... yet. This is more appropriate for cisco-nsp, where it's already been covered, but the TTL 255 hack was introduced in 12.0(22)S and 12.3(7)T if memory serves me. Pretty sparse pickings, but I guess it's a start. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
EBD> Date: Wed, 21 Apr 2004 10:56:26 +0000 (GMT) EBD> From: E.B. Dreger EBD> This is more appropriate for cisco-nsp, where it's already EBD> been covered, but the TTL 255 hack was introduced in EBD> 12.0(22)S and 12.3(7)T if memory serves me. Pretty sparse Memory did not serve me. s/12.0(22)S/12.0(27)S/ http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guid... Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
On 21-apr-04, at 12:44, Adam Rothschild wrote:
All things considered, I think MD5 authentication will lower the bar for attackers, not raise it. I'm sure code optimizations could fix things to some degree, but that's just not the case today.
Which begs the question, what is one to do,
How about: access-list 123 deny tcp any any eq bgp rst log-input access-list 123 deny tcp any eq bgp any rst log-input Unfortunately, not all vendors are able to look at the RST bit when filtering...
On Wed, Apr 21, 2004 at 01:00:07PM +0200, Iljitsch van Beijnum wrote:
All things considered, I think MD5 authentication will lower the bar for attackers, not raise it. I'm sure code optimizations could fix things to some degree, but that's just not the case today.
Which begs the question, what is one to do,
How about:
access-list 123 deny tcp any any eq bgp rst log-input access-list 123 deny tcp any eq bgp any rst log-input
Unfortunately, not all vendors are able to look at the RST bit when filtering...
The general ignorance to the fact that SYN works as well is astonishing. :-)
On Wed, 21 Apr 2004, Daniel Roesen wrote:
access-list 123 deny tcp any any eq bgp rst log-input access-list 123 deny tcp any eq bgp any rst log-input
Unfortunately, not all vendors are able to look at the RST bit when filtering...
The general ignorance to the fact that SYN works as well is astonishing. :-)
What are you talking about?
On Wed, Apr 21, 2004 at 01:23:54PM +0200, Iljitsch van Beijnum wrote:
On Wed, 21 Apr 2004, Daniel Roesen wrote:
access-list 123 deny tcp any any eq bgp rst log-input access-list 123 deny tcp any eq bgp any rst log-input
Unfortunately, not all vendors are able to look at the RST bit when filtering...
The general ignorance to the fact that SYN works as well is astonishing. :-)
What are you talking about?
http://www.uniras.gov.uk/vuls/2004/236929/index.htm First paragraph of the summary: "The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set." You can break TCP sessions not only be injecting harmfully crafted RST packets, but also with SYN packets. All talk I see going on is always about harmful RST packets only. Seems like noone realized that the thread is equally intense with SYN packets.
On Wed, 21 Apr 2004, Daniel Roesen wrote:
The general ignorance to the fact that SYN works as well is astonishing. :-)
What are you talking about?
First paragraph of the summary:
"The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set."
And: "It is also possible to perform the same attack with SYN (synchronise) packets. An established connection will abort by sending a RST if it receives a duplicate SYN packet with initial sequence number within the TCP window." So the attacker sends a spoofed SYN to router A, and router A sends an RST to router B and router B terminates the BGP session. I don't see anything in RFC 793 that suggests that "connections in a synchronized state" should be terminated because of a SYN. Hopefully our favorite vendors didn't either... The good part here is that filtering RSTs should still work. The advantage of that approach is that it moves the problem from the control plane to the data plane.
On Wed, Apr 21, 2004 at 02:10:05PM +0200, Iljitsch van Beijnum wrote:
"The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set."
And:
"It is also possible to perform the same attack with SYN (synchronise) packets. An established connection will abort by sending a RST if it receives a duplicate SYN packet with initial sequence number within the TCP window."
So the attacker sends a spoofed SYN to router A, and router A sends an RST to router B and router B terminates the BGP session.
Correct.
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the authorized sender and your edge anti-spoof filtering for RST doesn't help a single millimeter.
On 21-apr-04, at 14:38, Daniel Roesen wrote:
So the attacker sends a spoofed SYN to router A, and router A sends an RST to router B and router B terminates the BGP session.
Correct.
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the authorized sender and your edge anti-spoof filtering for RST doesn't help a single millimeter.
Now it's your time to overlook something: the filters I listed in my earlier message simply filter RSTs to/from the BGP port without looking at the address fields. Filtering ALL RSTs is probably a bad idea as broken sessions will then have to time out, possibly inconveniencing users (and thereby generating support calls). But for BGP this isn't much of an issue as the BGP hold timer takes care of business here anyway. So I believe filtering out all BGP RSTs on all edges is probably a good idea.
On Wed, Apr 21, 2004 at 03:09:15PM +0200, Iljitsch van Beijnum wrote:
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the authorized sender and your edge anti-spoof filtering for RST doesn't help a single millimeter.
Now it's your time to overlook something: the filters I listed in my earlier message simply filter RSTs to/from the BGP port without looking at the address fields. Filtering ALL RSTs is probably a bad idea as broken sessions will then have to time out, possibly inconveniencing users (and thereby generating support calls).
As you didn't specify where to apply these filters, I guessed on the edges. I would have never thought that someone would really suggest to deliberately break RST for valid BGP sessions.
So I believe filtering out all BGP RSTs on all edges is probably a good idea.
RST and SYN. But that's still patchwork. Do anti-spoofing filtering in general, not only mitigating _this_ thread. Don't allow packets from source IPs of your originated IP spaces enter your network, ADDITIONALLY to securing the transport via TCP MD5 authentication or even better with IPSEC. Having always two lines of defense is good security practise, especially if the doors to properly close are many (edge interfaces).
On 21-apr-04, at 15:21, Daniel Roesen wrote:
As you didn't specify where to apply these filters, I guessed on the edges. I would have never thought that someone would really suggest to deliberately break RST for valid BGP sessions.
Try me. :-) But don't forget the borders, those are more important.
So I believe filtering out all BGP RSTs on all edges is probably a good idea.
RST and SYN.
I can live with legitimate RSTs as collateral damage, but legitimate SYNs are probably best left alone... Unfortunately, at the receiving end there is no way to determine whether a packet is spoofed, so we must allow all pertinent SYNs through.
But that's still patchwork. Do anti-spoofing filtering in general, not only mitigating _this_ thread. Don't allow packets from source IPs of your originated IP spaces enter your network,
Of course. The problem is that this offers no protection against remote spoofers.
ADDITIONALLY to securing the transport via TCP MD5 authentication or even better with IPSEC.
I'm not recommending this for "small" peers as the crypto DoS risk is worse than what happens when the attack is executed successfully.
Having always two lines of defense is good security practise, especially if the doors to properly close are many (edge interfaces).
No disagreement there.
IvB> Date: Wed, 21 Apr 2004 15:09:15 +0200 IvB> From: Iljitsch van Beijnum IvB> [T]he filters I listed in my earlier message simply filter IvB> RSTs to/from the BGP port without looking at the address IvB> fields [...] the BGP hold timer takes care of business here IvB> anyway [...] Interesting thought. Smells like IRC. Still leaves SYNs to be addressed, at least in theory. Has anyone tried hitting * with an in-window SYN to know if this is indeed an issue? Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
On Wed, 21 Apr 2004, David Luyer wrote: : > You missed the "(assuming the attacker can accurately guess both : > ports)" part. : A significant number of BGP sessions will be with a source : port of 11000, 11001 or 11002; BGP sessions are generally : quite stable and Cisco routers start the source port at : 11000. If true, *that* would be a security risk in Cisco's port selection algorithm. Many modern OS's do not do simple sequential allocation of ports, making this point invalid. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
Interesting that Cisco uses random port selection with SNMP (http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml, see the Detail selection) but not with TCP. Too bad that TCP ports aren't randomized even with the "fixed" IOS versions. Would seem that as long as you're implementing security features like TCP RST confirmation, might as well implement randomized source ports.
From Theo de Raadt at OpenBSD: http://archives.neohapsis.com/archives/openbsd/2004-04/1351.html
This entire thing is being "sold" as `cross-vendor problem'. Sure. Some vendors have a few small issues to solve in this area. Minor issues. For us, those issues are 1/50000 smaller than they are for other vendors. Post-3.5, we have fixes which make the problem even smaller. But one vendor -- Cisco -- has an *UTTERLY GIGANTIC HUGE* issue in this regard, and as you can see, they have not yet made an announcement see.. You are being told "lots of people have a problem". By not seperating out the various problems combined in their notice, or the impact of those problems, you are not being told the whole truth. --- Pete. On Wed, 21 Apr 2004, Todd Vierling wrote:
Date: Wed, 21 Apr 2004 11:37:04 -0400 (EDT) From: Todd Vierling <tv@duh.org> To: David Luyer <david@luyer.net> Cc: 'Patrick W.Gilmore' <patrick@ianai.net>, nanog@merit.edu Subject: Re: TCP/BGP vulnerability - easier than you think
On Wed, 21 Apr 2004, David Luyer wrote:
: > You missed the "(assuming the attacker can accurately guess both : > ports)" part.
: A significant number of BGP sessions will be with a source : port of 11000, 11001 or 11002; BGP sessions are generally : quite stable and Cisco routers start the source port at : 11000.
If true, *that* would be a security risk in Cisco's port selection algorithm. Many modern OS's do not do simple sequential allocation of ports, making this point invalid.
Assuming that he do not know port number and must try 20 - 40 ports, it takes 200 * 10 = 2000 seconds to resert a single session... Useless except a very special cases 9such as a big community decided to knock down SCO, for example).
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:
party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr,
again
worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. <snip> I dont understand why the large differences in claims
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
says Modern operating systems normally default the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535 RST segments (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). With the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier.
Also, with the various 'bots' at peoples disposal, why the assumption the attack would not be distributed.
---Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-04-20, at 23.09, Richard A Steenbergen wrote:
but the massive amount of confusion, rumor, and worry which the major router vendors (Cisco and Juniper) created by essentially rediscovering the god damn spec and then telling only their major customers about so that only rumors could filter down to the rest of the industry is absolutely pathetic. If you have a support contract and were not told about this "attack" (if you could call it that) or were blatantly misinformed as many people seem to have been, you should demand to know why you didn't receive better treatment.
this was to the best of my knowledge not handled by Cisco and Juniper and also to the best of my knowledge they did not pre-warn any customer. But I might be mistaken. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQIYJ1qarNKXTPFCVEQIFVACfdbhaVD3lHDhKZvtHUd1ugUUFeToAn1Us FpSX+E9RmmezY4liEiInxYCR =hEOv -----END PGP SIGNATURE-----
participants (16)
-
Adam Rothschild -
Alexei Roudnev -
Daniel Roesen -
David Luyer -
E.B. Dreger -
Grant A. Kirkwood -
Iljitsch van Beijnum -
Joe Abley -
Kurt Erik Lindqvist -
Mike Tancsa -
Patrick W.Gilmore -
Pete Kruckenberg -
Richard A Steenbergen -
Rob Thomas -
Sean Donelan -
Todd Vierling