Slashdot Mirror
Graphing Randomness in TCP Initial Sequence Numbers
Saint Aardvark writes "This is neat: Graphic visualization of how random TCP Initial Sequence Numbers really are for different OSs. It's a great way of seeing how secure a TCP stack really is. Cisco IOS is great; OS9, OpenVMS and IRIX aren't. Posted to the ever-lovin' BugTraq mailing list." This is a follow-up to the previous report.
He must be running a server with no tcp stack. heh.
I propose a new flag in the standard TCP/IP packet. We shall call this the Slashdot Flag. The general purpose of this flag is to state whether or not the bandwidth limits of the server can handle the requirements a Slashdot posting can impose. If the flag is set false, Slashcode will automatically generate numerous, random, 'this page has been slashdotted' posts requesting a link to a mirror.
That being said, the page *is* finally loading up so I'm going to go look at some pictures now.
tinfoilmedia
Original report here:
t ml
http://razor.bindview.com/publish/papers/tcpseq.h
You will find the original report here, and you might like to check out the linux section. Credit to a previous poster for that link, however.
Try NetBSD... safe,straightforward,useful.
Comment removed based on user account deletion
>certainly more common than many of the other
>selections.
>
>Should we assume Linux matches *BSD or some other
>flavor? or do I need to read more carefully
You need to read more carefully.
"Please could you violate the site's copyright before posting the story"
although "please use server xxx.xxx as the proxy" for submissions could be a solution
could even set up Apache to do that on a url therefore subtly circumventing the copyright problem, banners could be passed through.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Lets face it: current computers and humans are both as bad as each other at randomness. The fact that computers have to "calculate" randomness is a bad sign in itself, and the humans that program these computers are almost utterly incapable of perceiving true randomness anyway. I'm waiting for the day when the national lottery comes up 1,2,3,4,5 with a bonus ball of 6. Society will crumble, public enquiries will be called for and conspiracy theorists will have something to bang on about for years. I think that barring the sudden development of Quantum x86 chips (at which point randomness becomes "real" and encryption becomes pretty much unbreakable), the only real solution for decent randomness must surely be TCP/IP seeding based on Lava Lamps
It's too late for me to die young
't be cool to have a board with a bit of radioactive alpha source and a counter to make genuine random numbers. Like this, or, ha, here's one (3rd from the top) that proposes using disk drive air turbulance to generate random numbers!
try { do() || do_not(); } catch (JediException err) { yoda(err); }
If you read the article is says:
- Raynet --> .
Agreed, such devices tend to have poor ISNs, but then again, they are for home use, and the ports they serve only respond on the INSIDE. Outbound traffic passes thru with more-or-less the same ISN it started with.
Unless you don't trust people on your home lan, it's not much of an issue. Yes, it should be done right, but the only people that can exploit this are those within your network. If they are in your home, they can do much worse than hijack your session as you configure the router.
As for outbound traffic, if you connect to an outside website from an inside PC, it uses the ISN that the PC generated and doesn't change it or adds some simple fixed constant. It still retains all of the entropy of the original PC's ISN. Nobody from the outside should be able to connect to the configuration server in the "DSL router" device. Hence, nobody from the outside really sees the poor entropy of the DSLRouter's ISNs.
Only higher-end firewall products, ie: the cisco PIX, attempt to mangle the ISN generation as they translate hosts. Most of the simple products do not, and certianly none of the $100 DSL routers do.
Also good ISN generation is actualy important to more "commercial" grade routers, since these devices are sometimes deployed and administered remotely, generate tunnels, etc. Thus these routers/firewalls sometimes have exposed ports, or exposed client traffic on a public network as they are being reconfigured.
Of course, many are only configured localy, or over a local LAN, which makes the risk a lot lower, but also users on corprate lans are generaly less trusted than those in your own home.
-Matt
A TCP implementation that generates initial sequence numbers using a trivial time dependency may be secure against sequence number guessing attacks if it implements RFC 1948.
The idea is to add a bias to the sequence numbers that depends on the source address. A client will be able to predict his own sequence numbers but not the sequence numbers of others. The bias is calculated using a cryptographic hash of the connection ID and a secret value.
A TCP implementation that uses RFC 1948 may still get a very poor rating for initial sequence number predictability from tools like nmap.
Does anyone know any TCP stack that actually implements it?
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.