Funny, there's already at least one company doing exactly that... an anonymous traffic proxy. I'm not going to post a link and thus slashdot their server. However, as "256,934" other people have hit the site (so says the counter), I'm sure you'll find it...
[censored] allows the user to traverse the Internet anonymously, across all ports and protocols.
The only question that you need to ask is "Do I want to be UNKNOWN..."
PMTU adjusts the maxiumum send size (mss) for a connection in a downward direction. It starts out at the interface MTU. Ethernet is limited to 1500 without some "jumbo frame" voodoo. (bad things happen when this value is increased on hardware/software that doesn't know how to deal with it.)
BIC will only make a difference for "distant" nodes -- let's say 10,000miles (~16,000km). At that distance, it takes 89.408ms for the bits to get from end to end assuming it's a straight shot (no switches, routers, etc.) The initial connection opening will take 3x the link delay for the required SYN, SYN+ACK, ACK. It takes.12112ms to transmit a single packet. TCP will stop at 3 to 5 packets to await an ACK. In that time, 733 additional packets could have been sent. Jumbo frame (9KB) would increase throughput by ~6x, but there'd still be a 118packet-time pause. All this boils down to ~480KB/s with jumbo frames.
DSL is a modulation technology. You can do whatever you want with the bits entering and leaving the modulator/demodulator (mo-dem). Frame Relay and ATM are the predominant "layer2" transports with PPP gaining ground (PPPoKitchenSink is all the rage) and RFC1489(?) bridged ethernet losing ground (which is a shame as it has the lowest protocol overhead of all of them, esp. PPP.)
What is BIC trying to fix? It certainly isn't "the internet" as most links, on average, run at a fraction of their available bandwidth. TCP can fill up more bandwidth than most people can aford. It looks like the researchers with these insane connections and even more insane data sets want the holy grail of zero protocol overhead and none of the inherent throttling. (TCP limits the number of packets it will transmit before pausing for an ack. As a result, a single TCP connection usually will not consume a gigE link -- 4 connections certainly can.)
Unplug the battery. The ignition computer will default back to the factory calibration. (then follow the "my battery died" calibration proceedure -- or not, it'll eventually re-adapt to your driving patterns.)
[My dad was a mechanic for the DOT and thus had both "the cable" and the documentation for ford systems. (among a few others)]
Have you looked at the gas milage of the modern junk people seems to die for? Those huge death traps have worse milage than anything produced in the 50's and 60's. They might polute less, but they sure do eat gas. Raise gas prices to 4+$/gal and see how many people turn on their SUVs.
I like power too, but I like 40+ mpg better. (my turbo bug (2001) gets about 30 city and over 40 long distance -- completely stock, I love it too much to take it apart.)
This is not exactly true... modern cars have a "closed loop" system where various sensors feed data into the computer which it uses to tune engine parameters. Thus, the computer is "self learning"... about a decade ago, Ford recalled a number of Tempo's. They replaced the injector and downloaded the engine calibration data -- they used a federally mandated recall to collect this "millions of dollars" worth of data.
In fact, it actually takes a mere afternoon to build the calibration data. It takes a fair bit of equipment (diag station, dynamo, etc.), but the process is rather simple. (that is, for those that know how to do it.)
Ironic side discussion... the only real difference between the VW 1.8T engines (150hp and 180hp anyway) is the ECU programming. I can "upgrade" my engine with a serial cable:-)
I can go one step further... does the vendor handle your sensitive data securely beyond the web server? One can expend significant energy in securing the transport and the end-points, but if the web server is, oh say, logging your credit card information to a file and emailing it to a distribution list containing "yahoo" accounts, what the hell's the point? Many years ago (several employers ago), I was alarmed to see CC#'s in the postmaster inbox... One of the customers (a news reader vendor) was doing exactly that. And that information is still on backup tapes to this day (of course, that tape is over a decade old and probablly not readable.)
I tend to stay away from on-line sites that's store my CC#. It's not a big deal for me to enter that number every time I purchase something. I can ensure the security of my use of the card; I cannot say anything about the number in a file at some yahoo store merchant... if they can read it, so can the hackers.
It's not 5 years before "The Good Guys" spotted it; it's taken many years for anyone to spot it.
Had there not been other problems with mremap(), no one would've looked this closely at the code. What they've found is a very involved exploitation despite their claim of "easy to exploit".
I can tell the future... the broadcast flag will be (mis)used in exactly the same manner as the "fcc" bit in DVDs. The bit that disables the remote while the FCC warning is on screen is already improperly applied to what seems like hours of f***ing previews and other worthless crap on more than just Disney DVDs.
(Incidentally, the previews are a complete waste of space and time as they hold very little meaning years after those movies have been released. How many times do people need to be forced to watch previews for Planet of the Apes?)
Maxtor's diag tools disable read reallocation (and write reallocation) as step one. No drive will remap a read if the read actually FAILED. If it can read the sector, but with problems (it had to retry, ECC was called for, etc.) THEN it can reallocate the sector. Otherwise, data would be randomly corrupted WITHOUT NOTICE.
I wasn't performing write tests or a "low-level format" (which isn't a low-level format, btw. -- takes special tools to make an IDE drive do that.)
I said "tends to lock"... DOS, oddly enough, usually would boot.
It's hard to mark a sector bad when it isn't there. In fact, the entire track was gone -- magnetically detroyed from a write-during-power-failure (firmware buglet.) That stuff is stored on the media, ya' know. The diags intentionally disable remapping before initiating a surface scan. SMART counted the errors, but the application failed to report them and proceeded to declare the drive "A OK". They were 2 years old -- 3 year warrantee. Maxtor replaced them without question even without a coveted diag result code.
[memtest86] Let me send you my IProc PC-100 SDRAM DIMM... the idiots put the wrong timing values in it's SPD. I've only found one machine, ever, to work properly with that damn thing. Tyan MB's tend to lock as soon as the POST is complete. Memtest86 ran for 7 days and could not find a problem with the DIMM.
[hard drive diag floppy] I just returned two Maxtor drives that passed multiple "extended" tests with their diag utils. BOTH have entire tracks that aren't readable -- sector mark not found... they aren't there anymore.
Just because it passed a limited set of tests doesn't mean it's not broken.
foobar had been powered off for a year -- the power went off during the ice storm of 12/2002, and I left it off. chickenboo had a hardware RAID snafu and "/" disappeared -- it took me a few weeks to get around to fishing everything out of/lost+found
...one of the reasons 100k people die a year from medical errors...
Enter one chicken and one egg. This is a double edged sword. People make mistakes because they are people. They also make mistakes because they are relying ever more on computer systems to do their job (read: "dumbing down".) I miss the days of the old country doctor (all of my childhood doctors have passed on.) Let's face it, wholesale medicine accounts for a lot of these deaths.
As for filesystems permissions on default installs, the whole point of this thread is that it can be locked down, not that the defaults are bad.
No it isn't. Without a very diligent and cluefull admin, a windows system will almost never be secured to same extent as a UNIX platform. Out-of-the-box is what's being looked at... windows makes nothing secure and even makes the user an admin; UNIX secures the filesystem (almost everything is owned by root and not writable by anyone but root) and never creates more than one "root" user.
Given the hassle of using a windows system without admin rights, almost no one uses a non-admin account. Only in a large company does the hassle become worth the pain... jump through hoops to do things or let 10,000 idiots screw up the desktop they require to do any work?
[cramer:ttyp1]dominion:~/[1:38pm]:uname -a Linux dominion 2.3.42-SMP #11 SMP Sun Feb 6 20:06:02 EST 2000 i686 [cramer:ttyp1]dominion:~/[1:38pm]:cat/etc/redhat-release release 4.1 (Vanderbilt)
[ttyp0]foobar:~/[2:46pm]:uname -a Linux foobar 2.3.18-SMP #10 SMP Mon Sep 20 17:27:00 EDT 1999 i686 unknown [ttyp0]foobar:~/[2:46pm]:cat/etc/redhat-release release 5.1 (Manhattan)
[jfbeam:pts/0]chickenboo:~/[2:11pm]:uname -a Linux chickenboo 2.4.2-SMP #1 SMP Tue Feb 27 17:04:47 EST 2001 i686 unknown [jfbeam:pts/0]chickenboo:~/[2:11pm]:cat/etc/redhat-release Red Hat Linux release 6.2 (Zoot)
(And no, they are not publically accessible machines.)
This is part of the biological analogy that doesn't work in the computer world... see in the real world, viruses physically invade a cell and implant their DNA into specific locations within the host DNA. Evolution has led to a bunch of "junk" DNA free for the viruses to attack; as it isn't an active part of the organism, there's no harm. HOWEVER, in the computer realm, viruses don't "invade" they use flaws in the active executible code to get in. At that point, programs are point-blank replaced -- not patched like a biological virus. Junk code would only waste space and slow down program execution.
As M$ aptly points out, comparing computer viruses to biological ones is a very weak argument... unlike a corn or potato crop, a computer can be unplugged and rebooted; the virus can easily be removed and corrected. (not that M$ actually does the latter.)
Use of uncertified systems in "life supporting systems" is against the law. (grounds for malpractice, revokation of certifications and licenses, and even dissolution of a medical practice -- hospital, private practice, clinic, etc.)
Pharmacy systems in a hospital can always fall back to pencil and paper tracking. #2 is a problem, however, doctors should not be relying entirely on computer systems as their knowledge base. #3... how many days do you think people are going to go without food? #4... see above. Anything in the ER is a "life support system". #5... umm, that's called a radio. (yes, they'll lose remote bio-telemetry. but that's why there are trained medics in the chopper.)
[I've worked around medical systems before. It's a f'ing pain in the ass.]
There is no difference between "machine user" and "machine admin". Only companies and large orgainizations will have an "Administrator" to fill the role of "machine admin". In every household in suburbia, there's no differentiation -- the person(s) using the box maintains it.
... provided a link to some Redhat 5.2 hack from 6 years ago
Ok. In that case, the link would only be useful if someone was still running an unpatched RH 5.2 -- this is very unlikely. However, there's a fair chance the 6 year old Windows hack will still work on the most modern Windows versions.
There in lies the difference... Linux (UNIX) fixes their mistakes and move on. Microsoft ignores everything until the bug crashes a small country. (I know first hand, they don't give a shit about people reporting bugs in their products.)
limiting Windows users to a non-privileged account...
No it doesn't. Have you looked at the filesystem permissions after a default windows install? (assuming there are any... FAT doesn't support access rights) The whole system is open for "Everyone". A great deal of (stupid) software requires admin rights to even run -- I've ran into that one several times.
All phone companies charge fees. They'll charge you every last penny they think they can get away with without a utility commision crawling up their ass. Most of these fees are "allowed" by FCC regulations. None of them are "required". Do you think any of these "FCC fees" go to the FCC? Not a penny of it.
LNP allows for the telco to charge a fee to recoop the costs of upgrades for a period of five years from the first time the charge appears. (Beleive you me, I'm watching Bellsouth like a hawk.) However, this is complete bullshit. LNP features were available as of 5e14, I think, (for lucent 5ess) which is minimum version to be CALEA compliant. All telcos were required by federal law to be CALEA compliant by 2000 -- if they aren't, it's a 10k$/day fine PER tap order they fail to fulfill. A large chunk of cash was set aside for CALEA upgrades, so there's no excuse.
Slashdot Mirror
The only question that you need to ask is
"Do I want to be UNKNOWN
PMTU adjusts the maxiumum send size (mss) for a connection in a downward direction. It starts out at the interface MTU. Ethernet is limited to 1500 without some "jumbo frame" voodoo. (bad things happen when this value is increased on hardware/software that doesn't know how to deal with it.)
.12112ms to transmit a single packet. TCP will stop at 3 to 5 packets to await an ACK. In that time, 733 additional packets could have been sent. Jumbo frame (9KB) would increase throughput by ~6x, but there'd still be a 118packet-time pause. All this boils down to ~480KB/s with jumbo frames.
BIC will only make a difference for "distant" nodes -- let's say 10,000miles (~16,000km). At that distance, it takes 89.408ms for the bits to get from end to end assuming it's a straight shot (no switches, routers, etc.) The initial connection opening will take 3x the link delay for the required SYN, SYN+ACK, ACK. It takes
(somebody go check my math.)
... Pigeon...
Where does the air come in... the pigeon cannot fly in a vacuum. (and wouldn't live very long either.)
DSL is a modulation technology. You can do whatever you want with the bits entering and leaving the modulator/demodulator (mo-dem). Frame Relay and ATM are the predominant "layer2" transports with PPP gaining ground (PPPoKitchenSink is all the rage) and RFC1489(?) bridged ethernet losing ground (which is a shame as it has the lowest protocol overhead of all of them, esp. PPP.)
What is BIC trying to fix? It certainly isn't "the internet" as most links, on average, run at a fraction of their available bandwidth. TCP can fill up more bandwidth than most people can aford. It looks like the researchers with these insane connections and even more insane data sets want the holy grail of zero protocol overhead and none of the inherent throttling. (TCP limits the number of packets it will transmit before pausing for an ack. As a result, a single TCP connection usually will not consume a gigE link -- 4 connections certainly can.)
No, it does not. The ECU eeprom is reprogrammable via the diag connector. (granted, it's a 200$ serial cable.)
Unplug the battery. The ignition computer will default back to the factory calibration. (then follow the "my battery died" calibration proceedure -- or not, it'll eventually re-adapt to your driving patterns.)
[My dad was a mechanic for the DOT and thus had both "the cable" and the documentation for ford systems. (among a few others)]
Have you looked at the gas milage of the modern junk people seems to die for? Those huge death traps have worse milage than anything produced in the 50's and 60's. They might polute less, but they sure do eat gas. Raise gas prices to 4+$/gal and see how many people turn on their SUVs.
I like power too, but I like 40+ mpg better. (my turbo bug (2001) gets about 30 city and over 40 long distance -- completely stock, I love it too much to take it apart.)
This is not exactly true... modern cars have a "closed loop" system where various sensors feed data into the computer which it uses to tune engine parameters. Thus, the computer is "self learning"... about a decade ago, Ford recalled a number of Tempo's. They replaced the injector and downloaded the engine calibration data -- they used a federally mandated recall to collect this "millions of dollars" worth of data.
:-)
In fact, it actually takes a mere afternoon to build the calibration data. It takes a fair bit of equipment (diag station, dynamo, etc.), but the process is rather simple. (that is, for those that know how to do it.)
Ironic side discussion... the only real difference between the VW 1.8T engines (150hp and 180hp anyway) is the ECU programming. I can "upgrade" my engine with a serial cable
- But is the web server itself secure?
I can go one step further... does the vendor handle your sensitive data securely beyond the web server? One can expend significant energy in securing the transport and the end-points, but if the web server is, oh say, logging your credit card information to a file and emailing it to a distribution list containing "yahoo" accounts, what the hell's the point? Many years ago (several employers ago), I was alarmed to see CC#'s in the postmaster inbox... One of the customers (a news reader vendor) was doing exactly that. And that information is still on backup tapes to this day (of course, that tape is over a decade old and probablly not readable.)I tend to stay away from on-line sites that's store my CC#. It's not a big deal for me to enter that number every time I purchase something. I can ensure the security of my use of the card; I cannot say anything about the number in a file at some yahoo store merchant... if they can read it, so can the hackers.
It's not 5 years before "The Good Guys" spotted it; it's taken many years for anyone to spot it.
Had there not been other problems with mremap(), no one would've looked this closely at the code. What they've found is a very involved exploitation despite their claim of "easy to exploit".
I can tell the future... the broadcast flag will be (mis)used in exactly the same manner as the "fcc" bit in DVDs. The bit that disables the remote while the FCC warning is on screen is already improperly applied to what seems like hours of f***ing previews and other worthless crap on more than just Disney DVDs.
(Incidentally, the previews are a complete waste of space and time as they hold very little meaning years after those movies have been released. How many times do people need to be forced to watch previews for Planet of the Apes?)
That can be done on a single, tiny chip these days.
Maxtor's diag tools disable read reallocation (and write reallocation) as step one. No drive will remap a read if the read actually FAILED. If it can read the sector, but with problems (it had to retry, ECC was called for, etc.) THEN it can reallocate the sector. Otherwise, data would be randomly corrupted WITHOUT NOTICE.
I wasn't performing write tests or a "low-level format" (which isn't a low-level format, btw. -- takes special tools to make an IDE drive do that.)
I said "tends to lock"... DOS, oddly enough, usually would boot.
It's hard to mark a sector bad when it isn't there. In fact, the entire track was gone -- magnetically detroyed from a write-during-power-failure (firmware buglet.) That stuff is stored on the media, ya' know. The diags intentionally disable remapping before initiating a surface scan. SMART counted the errors, but the application failed to report them and proceeded to declare the drive "A OK". They were 2 years old -- 3 year warrantee. Maxtor replaced them without question even without a coveted diag result code.
[memtest86] Let me send you my IProc PC-100 SDRAM DIMM... the idiots put the wrong timing values in it's SPD. I've only found one machine, ever, to work properly with that damn thing. Tyan MB's tend to lock as soon as the POST is complete. Memtest86 ran for 7 days and could not find a problem with the DIMM.
[hard drive diag floppy] I just returned two Maxtor drives that passed multiple "extended" tests with their diag utils. BOTH have entire tracks that aren't readable -- sector mark not found... they aren't there anymore.
Just because it passed a limited set of tests doesn't mean it's not broken.
okie dokie...
/lost+found
[cramer:ttyp0]dominion:~/[12:39am]:uptime
12:39am up 150 days, 10:50, 2 users, load average: 0.02, 0.02, 0.00
[ttyp0]foobar:~/[1:45am]:uptime
1:45am up 5 days, 14:07, 2 users, load average: 0.00, 0.00, 0.00
[jfbeam:pts/0]chickenboo:~/[1:14am]:uptime
1:14am up 8 days, 53 min, 5 users, load average: 0.00, 0.00, 0.00
foobar had been powered off for a year -- the power went off during the ice storm of 12/2002, and I left it off. chickenboo had a hardware RAID snafu and "/" disappeared -- it took me a few weeks to get around to fishing everything out of
(Yeah, I need to set their clocks, too.)
- ...one of the reasons 100k people die a year from medical errors...
Enter one chicken and one egg. This is a double edged sword. People make mistakes because they are people. They also make mistakes because they are relying ever more on computer systems to do their job (read: "dumbing down".) I miss the days of the old country doctor (all of my childhood doctors have passed on.) Let's face it, wholesale medicine accounts for a lot of these deaths.- As for filesystems permissions on default installs, the whole point of this thread is that it can be locked down, not that the defaults are bad.
No it isn't. Without a very diligent and cluefull admin, a windows system will almost never be secured to same extent as a UNIX platform. Out-of-the-box is what's being looked at... windows makes nothing secure and even makes the user an admin; UNIX secures the filesystem (almost everything is owned by root and not writable by anyone but root) and never creates more than one "root" user.Given the hassle of using a windows system without admin rights, almost no one uses a non-admin account. Only in a large company does the hassle become worth the pain... jump through hoops to do things or let 10,000 idiots screw up the desktop they require to do any work?
/me whistles innocently...
/etc/redhat-release
/etc/redhat-release
/etc/redhat-release
[cramer:ttyp1]dominion:~/[1:38pm]:uname -a
Linux dominion 2.3.42-SMP #11 SMP Sun Feb 6 20:06:02 EST 2000 i686
[cramer:ttyp1]dominion:~/[1:38pm]:cat
release 4.1 (Vanderbilt)
[ttyp0]foobar:~/[2:46pm]:uname -a
Linux foobar 2.3.18-SMP #10 SMP Mon Sep 20 17:27:00 EDT 1999 i686 unknown
[ttyp0]foobar:~/[2:46pm]:cat
release 5.1 (Manhattan)
[jfbeam:pts/0]chickenboo:~/[2:11pm]:uname -a
Linux chickenboo 2.4.2-SMP #1 SMP Tue Feb 27 17:04:47 EST 2001 i686 unknown
[jfbeam:pts/0]chickenboo:~/[2:11pm]:cat
Red Hat Linux release 6.2 (Zoot)
(And no, they are not publically accessible machines.)
This is part of the biological analogy that doesn't work in the computer world... see in the real world, viruses physically invade a cell and implant their DNA into specific locations within the host DNA. Evolution has led to a bunch of "junk" DNA free for the viruses to attack; as it isn't an active part of the organism, there's no harm. HOWEVER, in the computer realm, viruses don't "invade" they use flaws in the active executible code to get in. At that point, programs are point-blank replaced -- not patched like a biological virus. Junk code would only waste space and slow down program execution.
As M$ aptly points out, comparing computer viruses to biological ones is a very weak argument... unlike a corn or potato crop, a computer can be unplugged and rebooted; the virus can easily be removed and corrected. (not that M$ actually does the latter.)
Use of uncertified systems in "life supporting systems" is against the law. (grounds for malpractice, revokation of certifications and licenses, and even dissolution of a medical practice -- hospital, private practice, clinic, etc.)
Pharmacy systems in a hospital can always fall back to pencil and paper tracking. #2 is a problem, however, doctors should not be relying entirely on computer systems as their knowledge base. #3... how many days do you think people are going to go without food? #4... see above. Anything in the ER is a "life support system". #5... umm, that's called a radio. (yes, they'll lose remote bio-telemetry. but that's why there are trained medics in the chopper.)
[I've worked around medical systems before. It's a f'ing pain in the ass.]
Maybe you need a few more whacks yourself :-)
There is no difference between "machine user" and "machine admin". Only companies and large orgainizations will have an "Administrator" to fill the role of "machine admin". In every household in suburbia, there's no differentiation -- the person(s) using the box maintains it.
- ... provided a link to some Redhat 5.2 hack from 6 years ago
Ok. In that case, the link would only be useful if someone was still running an unpatched RH 5.2 -- this is very unlikely. However, there's a fair chance the 6 year old Windows hack will still work on the most modern Windows versions.There in lies the difference... Linux (UNIX) fixes their mistakes and move on. Microsoft ignores everything until the bug crashes a small country. (I know first hand, they don't give a shit about people reporting bugs in their products.)
- limiting Windows users to a non-privileged account
...
No it doesn't. Have you looked at the filesystem permissions after a default windows install? (assuming there are any... FAT doesn't support access rights) The whole system is open for "Everyone". A great deal of (stupid) software requires admin rights to even run -- I've ran into that one several times.All phone companies charge fees. They'll charge you every last penny they think they can get away with without a utility commision crawling up their ass. Most of these fees are "allowed" by FCC regulations. None of them are "required". Do you think any of these "FCC fees" go to the FCC? Not a penny of it.
LNP allows for the telco to charge a fee to recoop the costs of upgrades for a period of five years from the first time the charge appears. (Beleive you me, I'm watching Bellsouth like a hawk.) However, this is complete bullshit. LNP features were available as of 5e14, I think, (for lucent 5ess) which is minimum version to be CALEA compliant. All telcos were required by federal law to be CALEA compliant by 2000 -- if they aren't, it's a 10k$/day fine PER tap order they fail to fulfill. A large chunk of cash was set aside for CALEA upgrades, so there's no excuse.