Forgot your password?
typodupeerror

TCP Vulnerability Published 676

Posted by michael
from the DOS-for-fun-and-profit dept.
Bob Slidell writes "According to Yahoo!, there is a critical flaw in TCP that affects everyone and everything. The article is scant on details and long on fear, hopefully someone will post more details on this." The advisory has more information, and is long on details but only moderate on fear.
This discussion has been archived. No new comments can be posted.

TCP Vulnerability Published

Comments Filter:
  • by thedillybar (677116) on Tuesday April 20, 2004 @03:24PM (#8920535)
    It sounds (again) like proactive security auditting saves the day!

    It doesn't save anything. When someone exploits this and takes out 90% of the Internet's routers, you're screwed no matter what.

    It definitely makes a good argument for both OpenBSD and proactive security auditting. But it doesn't save the day.

  • Re:Good (Score:5, Insightful)

    by adam mcmaster (697132) on Tuesday April 20, 2004 @03:24PM (#8920539) Homepage
    I'm no expert, but wouldn't a security problem with TCP be completely unrelated to IP?
  • Way to go, Tony!! (Score:1, Insightful)

    by Anonymous Coward on Tuesday April 20, 2004 @03:24PM (#8920540)
    Tony had discovered this vulnerability about a year ago. Luckily it was first discovered by an intelligent and ethical IT security guy and not some unscrupulous hacker. He has quietly worked with vendors during that time helping them come up with a solution.
  • by Anonymous Coward on Tuesday April 20, 2004 @03:24PM (#8920544)
    Move along, little to see here.

    the chance of causing arbitrary BGP route flaps went from 1:2^32 to 1:2^2 and you say there is nothing to see here?

    you must be a windoze user if this doesn't faze you.
  • Re:Good (Score:5, Insightful)

    by robslimo (587196) on Tuesday April 20, 2004 @03:25PM (#8920563) Homepage Journal
    I don't think so.

    Looks like the weakest point for net-wide effects in routers implementing BGP. A concerted attack could tie up critical routers rebuilding routes after losing connection to their peers. Since this could be globally critical, I suspect the major hardware vendors and service providers will be jumping through hoops to get the fix in before some blackhats get coordinated with an exploit. There would still be weaknesses, but IPv6 will get to sit idle a bit longer.

  • by AndyBusch (160585) on Tuesday April 20, 2004 @03:27PM (#8920588)
    Good and funny :) but I think what they mean is that more details would give more info for exploits, so their sitting mum til things can get solidified a little more.
  • by LostCluster (625375) * on Tuesday April 20, 2004 @03:29PM (#8920615)
    Well, that means our home PCs aren't likely to get exploited by this. However, if our ISP's router gets exploited, we're knocked offline and our PC isn't as useful as it used to be.

    The threat here is a DOS aimed at a few things that we don't want to see go down.
  • by Percent Man (756972) on Tuesday April 20, 2004 @03:31PM (#8920630) Homepage
    ... since TFA goes on to say the vulnerability explicitly affects "long-lived" TCP connections, not the POP3 / HTTP / SMTP that Joe User relies on. However, for businesses and security wonks this is a potentially big deal.
  • by PeteDotNu (689884) on Tuesday April 20, 2004 @03:32PM (#8920657) Homepage
    Oh, right. Copy and paste job gets moderated +5. That's great.
  • by CyberBill (526285) on Tuesday April 20, 2004 @03:33PM (#8920669)
    No, its not a problem that is software-specific. They are utilizing a 'flaw' in the design of TCP by spoofing the sender's IP address and port, *AND* guessing the recvwindow number!!

    The reason it only affects long-term connections is because it takes awhile to probe for the magic number to reset the connection, and ALL this does is reset the connection, nothing more.

    This whole thing is retarded, if you know enough about TCP this exploit was already on your mind and forgotten because its stupid. :P

    -Bill
  • Re:OSVDB (Score:5, Insightful)

    by -tji (139690) on Tuesday April 20, 2004 @03:33PM (#8920671) Journal
    So, it's simply another type of denial of service. A TCP Reset packet can be faked, which will result in a legitimate open TCP connection being closed by a third party.

    It also assumes a few of things.. You would need to be in the network route, or have some other means of establishing the sequence numbers for the connection. You would also need to be in a network that does not filter out improper source addresses (which some networks do.. but more should do) to allow your spoofed packet to get through.

    So, the problem boils down to a low bandwidth method to DoS TCP connections. It does not give a method to hijack the connections, or otherwise gain access to data.

    Anyway.. Clear IP connections are very open, and completely based on trust. Any sensitive communication should be tunneled inside a VPN, where it would not be vulnerable to this type of attack. (A real IPSec tunnel would not be vulnerable - as it does not use TCP. "SSL VPNs" use TCP as a transport, so they might be open to DoS.. Stick with the security of IPSec for best results.
  • by Anonymous Coward on Tuesday April 20, 2004 @03:39PM (#8920758)
    From: Theo de Raadt <deraadt@cvs.openbsd.org>
    [snip]

    Let me be more clear.

    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.
  • by Anonymous Coward on Tuesday April 20, 2004 @03:43PM (#8920806)
    My understanding is that with this method it no longer "takes awhile to probe for the magic number to reset the connection"; the one article I read said he could do it in just a few guesses. By being able to do that, couldn't someone effectively keep a router in an almost permanent state of reset, resulting in a DOS?

    (Note, I don't really know anything about this stuff...)
  • by Anonymous Coward on Tuesday April 20, 2004 @03:43PM (#8920809)
    The scary thing is, he might not be.
  • by CyberBill (526285) on Tuesday April 20, 2004 @03:50PM (#8920895)
    The recv window is an int. Thats 2^32. The window size is unknown, but you can guess that its say... 65k, thats pretty big. Even at that rate, youd have to go:

    for(int i=0; i<0xFFFFFFFF; i+=0xFFFF )
    {
    //Test vulnerability with *this* number..
    }

    This doesnt seem too bad, this is only 65,000 guesses, but you have to keep in mind that the window is moving the whole time, so you might accidentally skip over it, or if your not going fast enough, never reach it! (And, 65k is a pretty damned big window, I havnt tested any long term connections, but chances are it wont get this big).

    -Bill
  • by quelrods (521005) <quelNO@SPAMquelrod.net> on Tuesday April 20, 2004 @03:51PM (#8920904) Homepage
    When I read this I had to laugh. It's an entire technical article on a "vuln" that has been known since the bsd4.4 days. Predictable ISN's are bad...enter windows. Tcp/ip stacks are not created equally, this is how nmap fingerprinting and p0f passive fingerprinting work. Anyone who has read tcp/ip illustrated by richard stevens would also be aware of this, btw that author is dead. If all the core internet routers were windows boxes this would be a big issue and the internet would have been DDoS'ed into extinction years ago. I would think that cisco routers ISN's aren't nearly that bad and in any case it's no where near as bad as the doomsayer(s) claim.
  • This is new?? (Score:3, Insightful)

    by venom600 (527627) on Tuesday April 20, 2004 @03:51PM (#8920914) Homepage Journal
    Maybe I missed something in the advisory, but this sounds like a good old TCP reset attack.....which is neither a new or novel concept. People have been doing this for ages with a sniffer and a packet generator.
  • Exactly. (Score:5, Insightful)

    by FreeLinux (555387) on Tuesday April 20, 2004 @03:55PM (#8920955)
    It is indeed a problem with TCP but, it is in no way new. Many people have relied on this "vulnerabillity" for years. This is the technique that many firewalls implement in order to terminate undesirable sessions.

    This vulnerabillity impacts the applications that are unable to handle session interruptions. BGP is such an appilication but, its impact on BGP is critical because this attack could seriously impeed BGP and since the internet backbone relies on BGP such an attack could covceivably shut down the internet. This is a known vulnerabillity in BGP, as you said, and it is surprising to me that BGP has not been modified to prevent this from happening.

    By and large most applications will be able to deal with this and only minor annoyances such as DoS will occur.

    As for earlier posts about OpenBSD being immune, I am very eager to hear how that is possible. No matter what the implementation, it is still possible to reset TCP sessions. This means that OpenBSD is still potentially vulnerable to DoS attacks.

    Provided that BGP is modified to make it more fault tolerant, I can't see this problem with TCP being anything more than a short-lived niusance. I'm sure however that many people will try to use this as leverage to force IPv6 migration however, I believe that it too is vulnerable.
  • by Geoff-with-a-G (762688) on Tuesday April 20, 2004 @03:56PM (#8920971)
    Hence this is an implementation issue that can be patched in TCP stacks.

    Ohhhhhh, all we have to do is upgrade the code in all BGP routers and major webservers on the entire internet! Do they have "Windows Update" for Cisco IOS yet?

    Seriously though, it would help to have a list of specific implementations which use the large window.


  • So I expect you'll see a distributed effort, using viruses. (shudder)
  • by JDizzy (85499) on Tuesday April 20, 2004 @03:58PM (#8921008) Homepage Journal
    I read the paper, which is nothing more than a rehash of what every security person already knows about: tcp sequence guessing.

    This issue erupted on the freebsd irc chat, and I had to kill it by posting this linkage: http://lcamtuf.coredump.cx/newtcp/ [coredump.cx]

    As you can see TCP sequncing is fairly random in most of the IP/TCP stacks out there in commercial use. The reasearch paper mentioned in the article only applies to the OS's in the above link that dont' have near true 32bit randomness.

    The feasability of overcoming realtime 32 sequence guessing is insane, however non-zero. just my .02c
  • by cascadingstylesheet (140919) on Tuesday April 20, 2004 @04:01PM (#8921070)

    He made a sweeping claim that he "took the initiative in creating the Internet" that was clearly intended to be taken as it was, and just as clearly intended to be deniable if called on it.

    It's not a "myth" that he did this, nor anything to be proud of, if you're a Gore-ite ... I notice Gore-ites sure get uncomfortable about it.

  • The real problem? (Score:5, Insightful)

    by getnuked (595037) on Tuesday April 20, 2004 @04:04PM (#8921123)
    The real problem is not in TCP (although sequence number windows are a bad idea), it's in allowing in spoofed IP datagrams. If network admins locked down their routers correctly then script kiddies wouldn't be able to send forget packets, and this wouldn't be an issue.

    Note to netadmins and sysadmins: block packets with source IPs that are not valid for the interface they came from! Geesh!

  • by Simon Lyngshede (623138) <simon.spiceweasel@dk> on Tuesday April 20, 2004 @04:20PM (#8921360) Homepage
    Now I what read up on TCP/IP and my memory isn't that good, but isn't it the TCP part which a problem, mening that switching to a different IP protocol won't help you at all. IPv6 is as far as I understood it, only adressing, the TCP stuff is the same... maybe not.
  • Re:BGP vulnerable (Score:5, Insightful)

    by mwood (25379) on Tuesday April 20, 2004 @04:20PM (#8921368)
    What I find most worrisome is this:

    "BGP, configured without an MD5 key (as is usually the case)...."

    So, critical infrastructure, worthy of "a priority...that has never been seen before", is routinely run unsecured? *shivers*
  • Re:OpenBSD SMP (Score:3, Insightful)

    by the morgawr (670303) on Tuesday April 20, 2004 @04:20PM (#8921370) Homepage Journal
    You are correct; OpenBSD doesn't support SMP right now. This is mostly because SMP is a way to get next year's computing power today (and paying a lot of money in the process). Combine that with the fact that almost all of the programs used on a modern UNIX-like system arn't CPU bound and it's easy to see why SMP took a back seat to more "interesting" issues.

    However there is a developer being paid to work full time writing SMP support for OpenBSD. He expects to have a working implementation by 3.6 or 3.7.

  • by Tackhead (54550) on Tuesday April 20, 2004 @04:21PM (#8921391)
    > A recently published I-D (here) claims 200 seconds is sufficient time for a broadband sub to successfully attack a TCP session, provided their ISP doesn't use egress filtering (and way too few do so).

    Maybe it's about fucking time ISPs started using egress filtering. At the very least, there'd be an order of magnitude less crap (smurfage, etc) if ISPs dropped spoofed source IP packets before they got to the backbone.

    OK, so the ability of any skript kiddie to spoof and insert a BGP update is a pretty fucking huge mess. But "pretty fucking huge" it may be the only kind of mess that motivates the clueless fucktards pretending to be "ISPs" these days.

  • by Anonymous Coward on Tuesday April 20, 2004 @04:22PM (#8921393)
    [...] For us, those issues are 1/50000 smaller than they are for other vendors. [...]
    Um, that's not really a whole lot smaller, is it. I mean, 4.9999 is 1/50000 smaller than 5.
  • by iabervon (1971) on Tuesday April 20, 2004 @04:27PM (#8921471) Homepage Journal
    More likely they want to make sure they're understanding the issue correctly and write up a good explanation.
  • BGP Dampening (Score:2, Insightful)

    by cabazorro (601004) on Tuesday April 20, 2004 @04:31PM (#8921513) Homepage Journal
    My research on the vague news note lead to the following information:
    Routers using BGP (Border Gateway Protocol) use
    a technique called dampening to control amount a traffic a link generates.
    Details:
    When a link goes up or down, updates must be passed to any router using such link. Those updates bubble up if a link goes up and down to often causing unwanted high levels of traffic. A link gets dampened when it's activity (going up or down) is ignored for the reason mentioned above.
    Exploit.
    A false (link up/down) update message may get a healty linked damped by a router or group of routers halting all traffic through such link.
    Of course, non of the above has to do anything w/
    tcp protocol but a lot with Routing Protocols which are the very foundation of the Internet.
    I may be not be on the right track.
    Cheers.
  • by httptech (5553) on Tuesday April 20, 2004 @04:47PM (#8921755) Homepage
    The randomness of the TCP ISN generator doesn't matter. The fact is, you don't need to guess the current sequence number in the connection. If you guess *any* sequence number in the window ahead of the current sequence number, it's just as good. So all you need to do is count from 0x0-0xffffffff by increments of just under the TCP window size. You can hit the right number within a few minutes if you already know the source and destination ports and you have sufficient bandwidth. Longer if you have to guess the source port.
  • Re:OUCH! (Score:3, Insightful)

    by BusDriver (34906) <tim@muppetz.com> on Tuesday April 20, 2004 @04:58PM (#8921879) Homepage
    I think you're getting a bit over excited.

    If people have cracked routers there's nothing to stop them already from adverting routes to the global routing table, claiming to have better path to "phishing site" than the router currently has for "proper site"

    This exploit isn't a crack. All it means is that the hacker can take down a number of BGP sessions if he so wishes.

    The sky is not falling, most ISPs with any clue have been working on this for the last week already.
  • Re:Good (Score:5, Insightful)

    by TwistedSpring (594284) * on Tuesday April 20, 2004 @05:06PM (#8921971) Homepage
    other TCP weaknesses are syn floods (not quite the same thing, but somewhat similar -- in fact, this vulnerability might as well be called a "RST flood"),
    1. We know what the other TCP vulerabilities were. Anyone who's still susceptible to them is a lunatic.
    2. This is not at all the same thing and in no way similar other than the fact "it uses TCP".
    3. This vulnerability should not be called an RST flood. That would confuse it with a SYN flood which works totally differently and is much simpler. This should be called a broken window attack or something.

    I wouldn't say TCP is broken
    After noting all the other kinds of irrelevant TCP attack and reading up on this rather serious one, you wouldn't say it was broken? Could it be that, like everyone else including me, you never realised it was broken because you never looked close enough?
    it would be tough to design a transport protocol that is still simple (and doesnt use CPU burning hashing/encryption techniques) that wouldn't have these sorts of vulnerabilities
    It's called IPSEC, it's secure on the IP level up so TCP is encrypted over it. The simpler way to increase security would be to maintain current window size but increase the sequence number field to 64 bits wide. This would make it nigh-impossible to find where the window is sitting.
    calling this vulnerability severe is like screaming that highways are fundamentally unsafe because someone could point their car the wrong way and start smashing into oncoming traffic
    Highways are fundamentally unsafe. They're full of retarded people shunting 3 ton hunks of metal around at speeds they're not comfortable with. But your point is void because people would not do that as they'd die as a result and kill a lot of people. I don't think a kid doing a TCP RST attack really needs to be that dedicated, and this could cost businesses millions of dollars if they don't wise up to it sharpish. Most people who'd took even a short course in networking would be wise to it already.

    The best defence against this? Simply check for a stream of RST packets. They dont come in huge bundles with incrementing sequence numbers often. Detect that signature, block IP, sorted.
  • by Zondar (32904) on Tuesday April 20, 2004 @05:16PM (#8922139)
    The problem with your idea is that it won't work for the very entities that are most vulnerable: Tier 1 ISPs.

    They have agreements with lots of ISPs to carry traffic from place to place, called Transit Agreements.

    There may be traffic flowing on my network that is not "from" me and not "to" me, but that I'm merely moving for someone that I have a transit agreement for. *They* may also have a transit agreement with someone else, down the line.

    It is possible, likely in fact, that there is traffic on my network (if I'm a big ISP, mind you) whose source address does not match one of my directly connected neighbor's networks, but that traffic is no less legitimate.

  • by Ricin (236107) on Tuesday April 20, 2004 @05:26PM (#8922256)
    Tss. Juniper is full of it. It clearly is an implementation flaw, not a specification flaw. As pointed out in an earlier post RFC-793 allows for and recommends checking ACK numbers as well as SEQ numbers when validating a RST, but apparently not many implementations do so (though they still may have other preventive measures that rules out the brute-force-RST scenario).
  • Re:OpenBSD SMP (Score:2, Insightful)

    by ForsakenRegex (312284) on Tuesday April 20, 2004 @05:32PM (#8922347) Homepage
    I don't know quite how to respond to this without it being taken as a flame. Here's the best I can do. If you truly want OpenBSD to succeed as an operating system on a grand scale, you're going to need to stop excusing it's weaknesses and admit those shortcomings that are obviously bad. SMP support is absolutely required for any widespread success in the enterprise, as well as the other areas mentioned in another reply to this post. You need to understand this if you want to truly have a dialogue on why someone will/won't use OpenBSD.
  • Re:Exactly. (Score:1, Insightful)

    by Anonymous Coward on Tuesday April 20, 2004 @05:42PM (#8922454)
    "As for earlier posts about OpenBSD being immune, I am very eager to hear how that is possible. No matter what the implementation, it is still possible to reset TCP sessions. This means that OpenBSD is still potentially vulnerable to DoS attacks."

    Linux = Penguin;
    OpenBSD = Ostrich.
  • Re:OpenBSD SMP (Score:2, Insightful)

    by the morgawr (670303) on Tuesday April 20, 2004 @06:02PM (#8922669) Homepage Journal
    >Until which time, the OpenBSD zealots will continue to deny the issue exists or is of any importance. I see...

    I am not an "OpenBSD zelot"; I use OpenBSD on a few servers and hence am subscribed to the misc@ list. This was recently discussed so I thought I'd fill the poster in.

    All of the software you mention, while important, isn't what's used on a majority of systems (and more importantly isn't what the developers use their systems for). Many many more systems operate web servers, routers, file servers, and mail servers: general work horse stuff. That's what OpenBSD likes to focus on (because that's what the developers use it for). Hence SMP isn't a huge priority. Most of the developers don't work on OpenBSD for a living; they just code to solve there own problems (which by necessity are in the domain of what they use the software for). If this happens to solve your problem too that's great; if it doesn't well you do have the code.

    Furthermore, all of the software you mentioned is corner case, no where near common. How many bank computers and render farms are there compared to the number of web servers, mail servers, and routers?

    As for databases, most databases are more in need of RAM and fast disks then CPU. Those that are CPU hogs are often poorly designed. For those that actually do need multiple CPUs, let me remind you that there is no such thing as an all-in-one-solves-every-problem-every-time tool: you proably don't want to use OpenBSD for that anyway.

    None of this changes my claim that SMP is a (useful) hack to squeeze more performance out of today's technology for those who just can't wait (and are willing to pay through the nose).

  • by illumin8 (148082) on Tuesday April 20, 2004 @06:35PM (#8923012) Journal
    Yeah. The biggest problem here is the ease with which one could DoS the BGP-4 protocol.

    Actually, if any backbone providers are getting a BGP feed and not doing any type of ingress/egress filtering they are asshats and deserve to be knocked offline, if only so that their Cisco engineers can be fired and they can get some compentent help to fix the problem.

    Really, this issue is not going to take the internet backbone down. Most of the major backbone providers are smart enough to know that you don't just accept BGP traffic on any interface that claims to be from the IP address of your peer.
  • by janoc (699997) on Tuesday April 20, 2004 @06:43PM (#8923089)

    Yep, sure, however, if you flood the network with your packets, it will be probably noticed soon. Also in order to flood the network, you need a fast connection to the attacked host, reducing the problem to the immediate neighborhood of the attacked host. That's why this attack is not very practical to perform and the impact on most normal mortals is low (except for the BGP issue, which could take out your upstream router)

    The problem with BGP, which is mentioned in the original article, is that it has a particularly bad failure mode - when a BGP session goes down, it is very expensive to restart it. To top it off, BGP uses very long transmission windows (because it transfers lot of data and that is more efficient with longer windows) and that makes it easier to squeeze-in the spoofed packet. This is quite messy affair, when it happens.

    However, if somebody attacks your favorite web site in this way, I doubt that you are even going to notice it, since http sessions are stateless and comparably cheap to establish.

    So, I think this is just a big scare for nothing, it is mainly BGP issue for now. It affects just people who know how to fix it (and are fixing it right now) and the machines involved are relatively few. Unlike some Windows RPC exploit which unleashed a massive world-wide worm in few minutes.

  • by g-san (93038) on Tuesday April 20, 2004 @07:14PM (#8923361)
    one part of the problem is looking glass [google.com] sites. they are great for admins, but they do tend to leak out some information that could be used to do just this sort of attack. go check these sites and look at the 'bgp summary' pages and you will see the source and destination IP pairs for the peering sessions. no source or destination tcp ports, but you know one is 179. That's still alot of combinations to try but NetSky-AJ.bis could have a field day with this type of DDoS. If the viruses have room for messages in 6 languages, you can bet they can store plenty of 4 byte IP addresses to lauch this kind of attack. You know how long it takes to flush 125k+ routes and reload them? Propagating all those updates to other peers would quickly make things worse, and dampening would exacerbate things further.

    better double check those ingress and egress filters. :)
  • by billstewart (78916) on Tuesday April 20, 2004 @09:05PM (#8924227) Journal
    The problem isn't TCP stacks that are flawed because they don't implement TCP properly. It's TCP stacks that failed to imagine some of the creative ways to attack them. Sequence number guessing has been around for a while (see papers by Bellovin and others), but apparently the guy has figured a somewhat more efficient way to guess them on some popular platforms, apparently including Cisco routers.

    Routers don't usually do a lot of TCP themselves, except SSH or telnet access for management, but the one big exception is the BGP protocol that routers use to connect to each other, primarily at the interfaces between carriers. The BGP sessions stay up for a long time, and killing them tells the router that it's no longer talking to its neighbor so it should go find a different route to get to that network, which is really really annoying. On the other hand, BGP has options to do more checking on BGP messages before accepting them, and carriers that do spoof-proofing to prevent their customers from forging packets have less risk, and carriers that block packets addressed to their routers accept from approved destinations are much safer.

    Some customer connections to ISPs use BGP, especially if the customer uses multiple ISPs, though most are static - these could be subject to spoofing by somebody inside the customer's network, if they're not careful. (The customer could be an ISP, or they could be a regular customer with an employee who has next month's interesting virus.) So customers who don't want to get thrown off the net should probably be careful to do good firewalls to keep their own users from spoofing their connections.

  • by GrpA (691294) on Tuesday April 20, 2004 @09:40PM (#8924493)
    Reading through the comments, the scariest thing about this thread isn't the original article...

    It's the comments posted by a fairly experienced bunch of geeks.

    The misconceptions illustrated throughout this thread demonstrate how badly some aspects of the Internet, TCP and protocols are misunderstood by people who think they have a full working knowledge of these mechanisms. (Some posts...Other posts admittedly correct some errors)

    It's because of these people who *think* they know what's going on while working in the industry that the true risk grows, because hostile hackers will always find a home in the huge gaps left by their ignorance.

    Ignorance is more dangerous in the long run than apathy. Apathy can change.

    Apologies that this post is slightly OT, but it's relevant to the theme.



    GrpA
  • by egoshin (702514) on Tuesday April 20, 2004 @10:57PM (#8925044)
    There is a simple solution - just use pair of any NON public IP addresses on both sides of BGP links. This addresses are not published (not propogated via BGP itself) and nobody is able to send packets to it besides BGP peer partener. Problem exists only for stupid IS staff.
  • Re:Good (Score:2, Insightful)

    by IndigoDarkwolf (752210) on Wednesday April 21, 2004 @01:41AM (#8925983)
    Well, no black hat worth their bits would send a sequence of RST packets with incremental sequence number. You don't know what the window is, so you're better off choosing an offset tailored to how long how plan to sit there guessing. Even then, it doesn't take much effort for a computer to randomize the sequence of, say, 400,000 such numbers and then send them out in this nigh-random order, and you've just gotten around the overly-complicated detection hueristic.

    So the routers are now supposed to deny access based on a send history? It would be easier, cheaper, and more reliable to just turn on the fisking anti-spoof stuffs at the ISP level. An ISP knows what IPs it has. Anything coming from inside their network claiming an IP from outside their network is trivially detected and should be just as trivially discarded.

Refreshed by a brief blackout, I got to my feet and went next door. -- Martin Amis, _Money_

Working...