Slashdot Mirror
New Two-Headed Hard Drive Intended To Secure Web Sites
dlur writes: "This article states that Scarabs (In Japanese), a Japanese company, is developing a hard drive with two heads, one read-only and another that is read/write. With this comes two cables, the read-only side going to the external web server, and the r/w cable going to an internal protected server. While this should make it quite a bit tougher for script kiddies to place their mark on a page, I doubt it will stop any real hackers from getting to a site's DB as that would still need to be r/w."
First a 60-foot squid, now a mutant two-headed hard drive. What next, the announcement of the Bearded Lady Linux distro?
Karma: Good (despite my invention of the Karma: sig)
How would user generated data be processed and placed on the hard drive through the r/w cable? This hard drive seems like a great idea for static or non-interactive websites, but if you're going to have user generated data, then it's going to be hard to not let anyone get access to the hard drive.
~ now you know
Does the whole drive die?
Two hard drives heads, one OS, one root/administrator account. If your box is r00ted, it doesn't matter how many hard drives or hard drive heads you have you have still been 0wn3d.
Zaphod's been using this kind of drive for years to store his porn collection.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
This sounds like a nice drive to use in TiVo-type units as well, so that the read head can return data as the r/w head updates the media, rather than flopping the only head back and forth.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
That is a really good idea!
I hope they patent it quick before someone steals it and makes millions off their hard work.
In other words, is it even useful?
It seems a malicious user could still attempt to serve defaced pages off of a ram disk on the compromised machine. Yes, a reboot will fix the problem, but that's only slightly more convenient than restoring a compromised system from backups. Furthermore, I suspect that the read-only harddrive would encourage admins to become lazier with regard to applying server patches, since the system would be perceived as "secure".
Having a read and a read-write cable doesn't really solve anything. You really have to take the web-site down while you are updating, otherwise you need a very interesting combo of web site and file system.
See my journal, I write things there
Comment removed based on user account deletion
It seems like this would be fairly useful for sites that just serve content, and are completely static to the typical user--but there aren't too many of those. Most sites in real life are still going to have databases that will be using the "unsecured" read/write head (for example, when a user changes preferences), and will still be hackable...definitely an innovative solution to the problem though.
"I may be quite wrong." - Socrates
Why not write your website to a cdrom and run the site off of the cdrom drive? Your drive would spin like crazy but it would be a lot cheaper.
"I doubt it will stop any real hackers from getting to a site's DB as that would still need to be r/w." Why? Just take the ethernet card out of the DB computer.
Too easy... Must resist!
Nah, forget it.
"I mean, two heads are better than one."
As Timothy points out, this only prevents script kiddies from being able to modify existing content using a backdoor or whatnot. However, it won't do anything about denial of service attacks, since the server software and its modules/plugins are all in RAM, and will still be receiving inputs. Buffer overflows and whatnot are still possible. However, defacements will at least go away, and those are the second-most high-profile types of attacks, as they're visible to the general public. Database attacks would be the worst, though, since, as Timothy again points out, they must be writeable.
"Mod, mod, mod...and another troll bites the dust."
That way it is possible to use the intranet to produce pages to be read by the internet. Theoretically that can all be in 1 room managed by 1 person. In this case it is really theoretically impossible to hack the device.
Googlefight "Slashdot Troll" against "BSD is dying" 303:229. BSD thus cant die.
You don't need to write to the disk to make a compromised server serve up bogus content.
Furthermore, we can already do this same thing by mounting a network file system (say) in read-only mode. Other than being funky, what's the point?
As the article poster touched on, this won't do anything if you're concerned with RDBMS integrity (and have a site which requires write access to your RDBMS).
For static content, it sounds like a cool idea, even if they get root all they can do is view things and not touch. Of course, if that compromised boxen is attached to an internal network to your RDBMS, then they can go to hax0ring the heck out of your DB, they just have to use whatever tools you have installed on the web server.
Thanks,
--
Matt
This way, the drive could be perpetually monitored, kind of like the TVs in "1984" that send and receive at the same time. Having one of the heads break would render the drive inoperable in at least 1 way, like a blind person walks around. Or, if the write head is broken, a paralyzed person. I just don't think they're reliable, and that's why servers have redundant drives. -- Move 'zig' --
We're Doomed
Kinda like this '733+ script kiddie who can't even figure out how to install spamassassin?
You give people far too much credit.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
I've been saying for years that we need a hard drive with multiple independent heads. Lets take it a step further and put 4 voice coils in the drive. Make one set of heads R/W and the other 3 read only. (I wouldn't trust multiple R/W heads something would be bound to screw up)
Every e-commerce Web site I can think of requires writing data to the server based on user-entered data using the Web site itself. If I want the site to store my credit card number, or even an account profile with my shipping address, the Web server needs to be able to write to a hard drive somewhere.
Now, the sites that are the greatest/most significant targets for hackers are the ones that store personal data on the site's users, credit card data being the most valuable. So this hard drive would be useless for the servers that need it most.
Besides, even if the above weren't the case -- for instance, a banking site that (for some reason) only allowed you to read your account data, not make any transactions online -- does read-only really prevent hacking? All it means is that the hackers can't make changes to the server data; it doesn't mean that they can't steal passwords to access that data. So this might be good for the companies that use it, but it also gives a false sense of security by providing no additional protection to me, the user.
Well an external web server could be set up to mount everything NFS read only. Seems like that would be a bit simpler.... ...but since 99% of sites are dynamic it seems to be an impossibility anyway...
Remember you can do the SAME thing with the hard drive you currently own and a CD drive. Here are some simple instructions...
/mnt/cdrom
A create your website
B burn it to CD
C modify httpd.conf, document root, set to
Voila! and I didn't need to hire a team of japanese researchers to figure it out either.
I've often wondered why slower RPM drives don't do dual read-write heads for faster access times and transfer speeds. I'd rather buy a dual-headed 7200 RPM drive with a single Serial-ATA rather than some 15000 RPM drive. The slower dual-headed drive should be able to keep up with the faster RPM drive, yet be quieter (the platter motor -- two head positioning motors would be a bit louder, but not much so), utilize a higher on-disk bit density, and with a good control system, give me better overall speed with a random access usage pattern.
The admins most likely have a network connection on their machine, and if so, that could be hacked.
Why not a hack that resides in RAM?
It doesn't seem that this would stop a determined attacker; they'd just do an end run around the tech. It does seem that this would be an excellent way to speed up harddrives in general..audio and video... ohhhh.
I can already do this setup for my web server:
NFS server exports directories with web pages to web server read-only and does not allow logins from the web server (and firewall does its best to block even attempts of such). So even if the web server is fully compromized, the web page cannot be changed.
Of course, if the web server has writeable disks of its own the cracker could make it serve a page from there instead of the real page; but the two-headed disks will have the same problem, you can only solve it by not giving the web server any writeable disks, boot it from CDROM or from the network.
Lots of people secure there sites on = 650 megs and thus put it all on CD-ROM. True you can turn to this funky HD if you need more space for your web-site but most of the bulk of a web portal is the DB which does have to be RW and thus that's the hard drive part. So why not just continue to use your CD-ROM the same way they suggest?
modded down? this is goddamn funny...
I think the damn moderator never read Douglas Adams...
Now what kind of a geek would that make him?
"The majority is always sane, Louis." -- Nessus
http://slashdot.jp
The weakest point any in system is and always will be the people running it and / or administrating it.
This kind of technology is a bit of a waste. The time and money would be much better spent on education and implementation of methodologies to minimize the risk of a break in, and how to handle it when it happens. (Because chances are, sooner or later, IT WILL) No matter how many firewalls or dual cable IDEs you have.
Of course none of the R/W computers will be in any way attached to the internet.... in the best possible setup a machine that has access to both networks can be compromised, etc. If it's not, updating will be a major pain, so much so they might as well flip the read-only jumper on the drives between updates rather than use this system.
Aside from the obvious, there are much better uses for more than one head in a drive. Multiple simultaneous seeks, faster seeks, and twice the raw read rate. The market for this should be huge. Hard drive transfer rate is the bottleneck for most tasks, including boot time. All the while with less heat, power, and noise of the 7200+rpm drives.
"I don't know that atheists should be considered citizens, nor should they be considered patriots." George HW Bush
This would completely screw up any modern OS (or Windows).
The OS assumes that it, and it alone, modifies the disk, and that the disk won't change state without the OS making that change. This is one of the reasons you don't want to allow raw disk access from a VMWare or DOSemu session to a mounted file system - the emulated OS will access the disk, and the host OS's file system won't know about it. Boom! Instant corrupted file system.
In the case of this double-ended drive, the web server will assume that, since it has read the disk once, it needn't read that sector again. Then the write side computer modifies the disk, and the web server won't pick it up.
I'd rather see a disk with dual heads, and the logic to allow the system to read different sectors at the same time, all kept coherent by the drives controller as a way to increase throughput.
But to use this as a protection on a web server is just plain dumb.
www.eFax.com are spammers
I've had a similar idea when it comes to making a log server. If it is only physically possible to write to the log server, then there would be no way someone could erase their tracks.
Hacker Media
I would like to make a withdrawl, Mr. ATM.
Got friends?
Sure, this new drive can protect existing data from destruction, but we need protection from the wrong people reading the information that's already in a website.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
Well, cookies (by definition) are stored on the client. Now, the session data they're linked to can be stored in a variety of ways ... either in a DB or in a file that acts as a single record of a DB. Either way - wherever the session data is stored wouldn't have to be on the media that the web server is pulling content from, they can be distinct, providing some level of protection.
... seems rather dubious to me. Don't know that the cost of such a drive would warrant the minimal amount of protection it offered.
Not that I'm all that excited about this technology
--nt--
This has been done before on a slightly different scale.
When you have a storage array that supports multi initiator SCSI you can connect one connection of the array to the external facing machine in read-only mode and the other connection to the internal facing machine in read-write mode.
Unless you want to go to the trouble of making an OS that is 100% read-only, you'll need to have something writeable on that web server. It'd be cheaper to serve your website off CD-ROM (for the sake of this argument) but who's to keep a script kiddie from mounting your website on a ramdisk or another writable area?
Besides, you can always make hot-swap hard drive read-only with a jumper block.
Cookies will be stored as they always were... on the client's hard drive.
Session (and application) variables will be stored in... that's right! the Memory of the server or perhaps in swapfiles
"The majority is always sane, Louis." -- Nessus
http://slashdot.jp
It's the same deal with a SAN (Storage Area Network). I could easily zone two physical servers into the same LUN on the SAN and make one mount r/o and the other r/w, but unless the OS has some sort of understanding that this kind of thing is going to happen (like a clustering system), I would expect some problems on the r/o mounted system.
p.s. I'm no expert, I'm just wondering logistically how this is all going to work. It doesn't make sense to me...
p.p.s. I know there is no real security in mounting a disk r/o because someone could just remount r/w, unlike the physical solution this product provides. But in either case, I would think the issues with two boxes mounting the same file system without clustering would be a problem. If it isn't, I'd love to do something similar with my SAN just for performance and load balancing purposes...
How about 2 r/w heads, to increase performance?
Which cable gets priority over where the platter spins? DoS: I bet you could seriously cripple the write speed of the "secure" zone, if not eliminate its access to the disk through hogging and/or olde skool motor fatigue hardware destruction.
Yeah, that doesn't necessarily modify the data. BUT you can already remap all requests to the "read-only" zone, assuming it's compromised. So the external world sees the same result: keebler elves own u.
Assuming the hardware xploitation is accounted for, this disk's functionality is essentially emulated with a unidirectional backup. We all know how to do that, right? Leaving the market for this white elephant to the money-is-no-object / NSA / all-obfuscation-r-belong-to-us crowd.
So sayeth the article:
Hackers will be unable to attack Web sites protected by a new security system unless they can change the laws of physics, according to Naoto Takano
I'm working on it all ready. So far I've managed to get the relativity theory down to E/2 = MC^(1.9)
And standard Earth Gravity now has a value of 8.8m/s/s.
Up.
And don't try to fill up a garbage bag anytime soon. I've been playing with volume. They're now "Garbage Bags of Holding."
CDROMs cost less money and have none of the hassle of operateing a multihomed drive. If access time is an issue make sure your machine has enough ram to hold your contents.
For CDROM based linux distros look at Ellison's network computers - there are instructions on the net how to hack and build custom versions of their CDROM. Sentry Firewall is a good example of a CDROM based linux distro.
Besides, the read-only connection is probally only as read only as the drive's firmware wants it to be. This doesn't "solve" the security problem, it only moves the negotiation/attack from the computer to the hardrive's firmware.
A CDrom on the otherhand can't be changed - no amount of firmware tinkering is going to make the nessesary hardware "appear from nowhere" to make a CD drive act like a CDR(W)
This is SO a gimmick. It is no replacement for a properly configured server that's 99.98% locked down. You're going to need a second machine to feed files onto the box anyway, so why not just grant the webserving box read-only access on the file server ? Ideally this server would be totally isolated from the internet, and wouldn't accept write requests coming from the web box. So the only way to update anything is to be sitting on a workstation on the inside, and then to have a valid login on the fileserver.
This is so frickin' simple, the only reason this Scarabs company is even in business is because there are too many idiots running semi-important servers out there. Having your network admin'd by a clueless fuck is not something that will be solved by a piece of buzzy hardware.
-Billco, Fnarg.com
On a different disk, in other words yes. OS, pagefiles, and files that the web server would be writing to are still on a R/W drive. Information you only view would be on the read only drive.
I built a system like this with 2 and later 3 heads, years ago. actually wrote an article on it for a magazine:)
:)
.
Uses 20 Meg MFM single platter 5 1/2 drives (the tolernaces were the most forgiving, I probably had the only 486 with MFM hard drives in it
It was WAY cool though, (I had it under glass to watch it)
We took pictures, and the rejected aticle, sealed em in an envelope with a signed notarized affidavit. and had the post office postmark the flap
I was going to patent it (this is circa 1992) but I was told by many contemperaries it was the dumbest idea they had heard.
Now if I can find it watch out
Sig went tro...aahemmm.....fishing........
Does this mean that the website comes with the hard drive?
Unless you have an internal network with NO access to the outside world, the RW server would still be vulnerable. Also, many attacks come from within corporations. The only way this would make much of a difference would be if the internal server wasn't networked at all and had great physical security. That would make updates rather inconvenient considering you'd have to bring some sort of media to the rack to load site updates. Otherwise, you're still depending on the firewall and server configuration to keep people off of the internal system.
This product seems to me to be useless for any site that provides access to database information through dynamic pages.
Seeing how most web sites who would be in the market for a product like this have "advanced" sites, I would argue this product has a very small potential customer base.
-Pete
Soccer Goal Plans
Uhhh, once you have control of the web server, can't you write outside of DocumentRoot if you choose?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
The content machine on the other hand can be fortified to the hilt since that its only task is to supplie a secure way in. It doesn't listen on port 80 and in fact it could be placed on a seperate net or even a simple direct line setup.
Unless I am very much mistaken you have just taken care of almost all script kiddies attacks, lets face it most of these attacks are extremely lame, except for (D)DOS but then again very little works against that. I really would like one of these disks.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Yes indeed, this is a complicated, sure-to-cause-more-problems-than-it-solves solution to a non-problem. Export filesystems read-only to your static Web servers and read-write to your back-end thinkers (DB servers, content management systems, etc).
If you're really smart, you're doing all of this on a netapp filer so that the access speed is as good as or better than local-attached storage (and, yes that's true even though it sounds wacked... it's because of thier NVRAM-based journaling filesystem for which their NFS server code is hand-tuned).
Great.
/. ever taken a security class? /. ever worked in on security projects and/or audits?
Now, we have to explain one more thing to VCs and MBAs. All they know is there is this thing called a website that exists on a thing called a webserver.
Hasn't anyone on
Has anyone on
Let me break it down for the rest of you:
This ads exactly zero extra security for a well-run website. Most well-run sites already have seperately firewall'd http-webservers and database machines. Some well-run sites have the application server on yet a third firewall'd network (or vlan etc).
Any place worth 5cents will not have valued data sitting on an httpd server!
This is really Ooooga-Boooga in a nutshell for VCs and MBAs trying to make a buck on security-scared VCs and MBAs running other companies.
I don't buy it.
Secure your site properly - as one other poster mentioned, for the less-funded (read: cheap/poor/startup/blah) company/service you can simply mount a CD-R with your site's static content on it. Even JSPs can live on a CDr (as long as they're precompiled into servlets, or there's a scratch disk for the JSP-container to compile them).
Not all sites use cookies. Not all sites have user accounts. You'd be surprised at the number of sites that only have one person that ever accesses their data. If you think banks and e-commerce are the only sites on the web that worry about defacement then you're very wrong.
And with the CD-Rom trick, would you store the configuration files on the CD as well? If not, then couldn't a defacer simply change those configs to serve their files off of the hard drive? If the web server is incapable of being written to, period, then RAM disks would be the only way they could do anything. Restart the machine and you're up and running good as new. None of the configs have been changed.
While I think this is somewhat useless, I forsee this possibly being picked up by p0wergamers. A read head that is independant of the read/write. No OS overhead for reading your games. Put the games on the read side, and let the OS have control of the read write, with some way to make saves go to the read/write side. Now you don't have to worry about silly w1nbl0ws taking up all your IO bandwidth. Run as much P2P as you want in the background, and play Q3/NWN/WC3 etc etc etc at full speed.
But again, the databse is the soft chewy center of a website.
-Otto
01100101 01111001 01100101 01100010 01101001 01110100 01100101 01110010
RMS got a girlfriend?
Not sure if they do anymore, but IIRC hard drives already have or have had write protect tabs available. Write protect works just fine for floppy disks.
Multiple heads seems like it would be a massive extra expense compared to changing the firmware that doesn't really provide a whole lot of extra security.
Yes, a reboot will fix the problem, but that's only slightly more convenient than restoring a compromised system from backups.
I'd say a reboot is a lot more convenient than a resore from backups [if you have them!], and the bigger your site then the bigger the job of restoring the whole lot after r00t1nG. Just ask Taco! Hehehe...
I see this drive helping by having one machine on the read-only head, serving the website and only the website [r00tage risk is minimised]. If that system is somehow compromised, it's only a reboot needed.
OK now for DB based sites, or any site that needs write access, as mentioned many times already. Here's my idea: Have database update requests sent via a trusted computer [perhaps on a read-only drive head itself? With an unconnected drive having r/w access] to filter them, and alert the admin if needed, then on to the computer with the RW access to the website drive/array. Any attack on the site would be a A LOT harder! :) R00t1nG would not be an all-or-nothing affair. The network cable between the webserver and "filter" could have an undetectable packet logger on it to log the database change requests, greatly helping system restoration, and detecting which records were compromised.
Ali
P.S. I've ALWAYS wondered why HD's didn't have read only switches on them, or a flash eprom to store a table of sections to be read-only, which would be a good compromise for us poorer geeks! P.P.S. A for lazy admins, that's what Windows Update is for! [sorry, couldn' resist]
Ph33r m3!!!
Just to mount the filesystem through some mechanism where the server exports the data read-only? So.. NFS as an example.. the NFS server exports data to the clients as a read-only share, and the clients won't be able to modify no matter what. (Add caching NFS and systems like that to better speed performance..)
Add in remote logging for the server/servers, and that should be reasonably tight.
Of course, most of the older drives also had prominent lights and pushbuttons on the front that let you write-protect the drive, in some cases on a per-port basis.
What has often been missing is OS support for dual-ported drives; the lack of support is most conspicuous today. As a result most modern OS's trying to use a dual ported drive will have to "take its turn" having the disk mounted if there's any possiblity the other machine is going to do a write. If the OS doesn't even support the simple concepts of mount and dismount, then you probably cannot use it at all!
According to this "The God Janus, husband of Jana, is known as the custodian of the universe, the God who watches over doors and gateways, and the two-headed God of ... "
Please send any patent inquires to
Cesear, Emporer of Rome
123 Pantheon Drive
There are 01 kinds of cars in the world. The General Lee, and everything else.
Conner used to make a two-headed hard drive, but for performance, not security reasons. They had really interesting algorithms for choosing how to allocate requests to the heads, so that you could interleave, or plant one set to manage the inner tracks, and another the outer tracks, etc. Was supposed to be much higher performance (circa 1992), but I never heard of it again. Probably too expensive, and RAID was just becoming popular...
From the article:
"The original idea of a hard disk having two heads emerged around 1985..."
Funny that the technology hasn't been implemented after all this time... Or has it?
From the StorageReview.com reference section:
"Such hard disks have been built. Conner Peripherals, which was an innovator in the hard disk field in the late 1980s and early 1990s (they later went bankrupt and their product line and technology were purchased by Seagate) had a drive model called the Chinook that had two complete head-actuator assemblies: two sets of heads, sliders and arms and two actuators. They also duplicated the control circuitry to allow them to run independently. For its time, this drive was a great performer. But the drive never gained wide acceptance, and the design was dropped. Nobody to my knowledge has tried to repeat the experiment in the last several years.
There are several reasons why it is not practical to make a drive with more than one actuator. Some are technical; for starters, it is very difficult to engineer. Having multiple arms moving around on a platter makes the design complex, especially in small form factors. There are more issues related to thermal expansion and contraction. The heat generated inside the hard drive is increased. The logic required to coordinate and optimize the seeks going on with the two sets of heads requires a great deal of work. And with hard disk designs and materials changing so quickly, this work would have to be re-done fairly often.
However, the biggest reasons why multiple actuators designs aren't practical are related to marketing. The added expense in writing specialty electronics and duplicating most of the internal control components in the drive would make it very expensive, and most people just don't care enough about performance to pay the difference. Hard disks are complex technology that can only be manufactured economically if they are mass-produced, and the market for those who would appreciate the extra actuators isn't large enough to amortize the development costs inherent in these fancy designs. It makes more sense instead to standardize on mass-produced drives with a single actuator stack, and build RAID arrays from these for those who need the added performance. Compare a single 36 GB drive to an array of four 9 GB drives: in effect, the array is a 36 GB drive with four sets of everything. It would in most cases yield performance and reliability superior to a single 36 GB drive with four actuators, and can be made from standard components without special engineering."
So, from the looks of things, it would be easier and cheaper to use single-head drives in easy-to-put-together configurations than put two heads in the same drive. Admittedly, the StorgeReview.com reference's author didn't mention setting up a read-only/read-write scheme, but the logic still works. I'd guess that it would still be easier to make a RAID container that provides read-only access on one channel and read-write on another.
Again, from the article:
"Scarabs is also working on a different version of the technology--instead of putting two heads on a hard disk, the company is connecting two SCSI interface circuits to a conventional hard disk with one head, one set to send read-only electronic signals and the other to send read/write signals."
This company already knows that their gimmick drive won't sell. No one will buy an over-priced drive with higher probability of failure over a (comparatively) cheap SCSI trick that requires no extra moving parts.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(And what's the symbolism of the Scarab beetle? In Egypt they stand for immortality -- life from dung. The www.scarab.com site has an animated graphic of a beetle rolling a dung ball. Is this their metaphor for backups? Those whacky Japanese...)
"Fundamentalism" isn't about divine morality. It's about human authority.
Just 2 ports to the computers. There's no need for the 2 heads and it just complicates the cache issue. Just add another SCSI or ATA port and disallow writes. Duh.
Yeah. Hardware locking can get you a dynamic unidirectionally updated disk. At IDE speeds.
But see my other message about the white elephant aspect.
Security through Obscurity.... How many times does it have to be proven that this doesn't work?
Your mammas flamebait.
So you're going to use the ATM while speaking with a Texas accent?
"Withdrawl". Hahahah!
This sounds to me like an "Air-Gap".
Whale Communications has had a similar product out for years.
Bruce Schneier has some thoughts on "Air-Gap" technologies.
-SPG
Not really all that usefull. In a real production environment it is easier to place OS and web server data on a CD blank and boot from it (already mentioned) on a machine with CD-ROM and no HDD. However this does not solve much as a smart hacker can just overwrite contents in the memory cache. Granted it is much easier to recover from a defacement in such a scenario by simply rebooting the server. You can probably even write a script that will monitor and reboot any web server in event of changes. If you have a decent load ballancer and a few web servers, this will work just fine.
:-)
As for the DB problems mentioned, that could be solved with a real DB (not MS Access). If you make multiple users and limit the public web site write access to only parts that are absolutely necessary, you can probably get rid of majority of the risk.
You are never perfectly safe though, and I do not see this multi-headed HDD to be much of an improvement on current situation.
Now if they could make all of the web servers read from a single hard drive... or wait, they already have that, it's called a NetApp
-Em
RelevantElephants: A Somatic WebComic...
I'm getting sick and tired of vendors like AOL and Microsoft writing to and constantly "upgrading" my harddrive without having any way of checking or approving what's going on. Now I can set it up so that my Linux box is constantly watching my Microsoft box and other softqware I use.
How do you get the date to the read only side anyway??????
You can do the same with dumb sun boxes, that boot off the net, mount a read only parition with apache/content, and connect to a database. Good thing, if you update the content directly, your stack of boxes all have updated content. Make sure you have a nice storage array that can push data to the boxes.
Simple, Secure, and very easy to maintain.
> ...how do they keep the 2 heads from bumping into each other?
Mount them at 90 - 180 degrees apart from each other. Simple.
Other than expense, why not just use some sort of shared storage appliance. The admin can be allowed to mount the appliance rw, while the webserver can be given read only access? I think EMC has products that do this.
When I want your opinion I will beat it out of you.
A headline to draw in the geek girls?
Tsk tsk... Timothy!
Blearf. Blearf, I say.
This would be a great harddrive for all sorts of performance sensitive applications. I'm thinking of things like video transcoding or tivo-like situations where you're storing in one place and reading in another.. it would make a huge screaming fast ring buffer too.
But even for regular server-type activities, I think that decoupling read/write on a hdd would make sense.. and besides, if you're not doing any writing you get an immediade 2x performance boost on your random access reads (or better if you're smart about writing the elevator code)
If you don't know where cookies are stored, then my guess is you have a lot of cleaning up to do before your significant other stumbles upon your browser's cookie stash.
example.org - powered by Linux!
Not if writes to the disk as physically prevented which they are in this case. The general idea is not to prevent the trashing of the web server, but rather it is to protect the data it is serving from being wiped out. Which of course as others have said is pretty pointless, people generally don't break in just to erase things.
If this were extended to having two read/write servos, and if it were cached like most modern hard disks are, then wouldn't the Japanese be creating the Beast with Two Write Backs?
I believe John Ketchersid was in negotiations to sell such technology to Seagate years ago. Don't think it ever went through though. >
I remember someone telling me from back in the magnetic drum days, that the fastest drums had one head per track, so you only ever had rotational latency delays (average half the the rotation time) - no physical seek (move the head) delays. I often wondered if multiple heads on a modern disk drive would improve performance...
... again, let the disk controller decide to move the closer head ... I know that I can pick items out a heap much quicker with two hands than one due to economy of movement....
I know on a modern disk the tracks are too tightly packed to do a head-per-track, but was wondering if you had (say) 2 heads on a single arm seperated by a third the width of the disk, then any track could be read with a much smaller movement (compared to full disk seeks) by seeking with the closest head, and when queuing up reads for an "elevator algorithm" of seeks you could also get performance gains by grabbing out of order data with the "trailing" head.
I realise the price goes up with complexity, and the heavier head might take longer to settle, but was wondering if this wouldn't give better performance for scattered reads for those who need it (eg servers) and don't mind paying....
Now I'm a software geek, not a hardware bod, so does anyone know why this isn't done ? (I can guess lots of reasons myself, thanks). Is it effectively just RAID striping on a single disk ?
And how about more heads (5 across, 10 across...), or 2 sets of heads on opposite sides of the disk to cut rotational latency in half (if kept in step) or
--
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
Why not use two hard drives, and a bit of cleverness in the software to write the incoming data stream to one while the user is viewing a stream on the other? This seems cheaper than custom hard drives, and preserves the ability to keep upgrading the capabilities by going to new commodity hard drives as biggers ones continue to get cheaper.
ooooh la-de-dah. fast moderation there
FUCKER!!!!!
Not only is the new idea useless and in fact unworkable with most OSes as already pointed out by several posts, the "original idea" of having two heads to speed up analysis by reading from the drive what was just written was just as bad. All they had to do was remember what they wrote. As I remember it, the cost of modifying the drives versus adding cache memory was a loser even in 1985.
Now, what I'd much much rather see is multiple independent read/write heads per platter on consumer level drives!!! Even two heads are enough to provide continuous streaming at the bit rate of the platter as the track to track seek time on most modern hard drives is less than the single rotation time. And, when it is detected that two areas of the disk are being accessed in an interwoven pattern, thrashing could be completely avoided.
I've seen a couple of projects on freshmeat that do this. Basically, a daemon sits around and watches files and if they change, they do something about it. This could be anything from logging to sounding an alarm to replacing the content.
I could have a repository sitting offline storing all of my content (or even everything... OS, databases, scripts, tools, etc etc) and have it "log in" to the servers from the inside and check everything for changes periodically. In a lot of cases, tests could be done from the outside as well (web content specifically). That machine, though physically connected, would simply shut off its interfaces and block everything unless it was doing its work.
I think a recent website hack occurred at USA Today... such a scheme could have caught the hack within minutes and even have replaced the forged content with whatever was supposed to be there.
Just how protected is that internal server? Hackers will of course find a way to get into that.
We're Doomed
Is it my imagination, or is it a particularly sad commentary on the state of software development that something like this drive is needed? Honestly, things like this are why so many of my consulting clients ask me if programmer have a clue about how to do things. (Yes, I know it's not that simple, given how hard it is to build a system with truly good security, but still...)
Anyone else reminded of the silly scene where Arnie has to instruct his friends how to flip his neural net from R/O to R/W mode?
[
I've been hearing a lot of people say "clip pin 23 to your IDE cable" to prevent writing.
Would it be difficult for a company to come up with a "plug between" adapter between the harddrive and the IDE cable? maybe it would have a jumper on it that you could remove, or better yet, plug in an extension cable with a switch onto the jumper location so you wouldn't have to open the case every time a change is made. If there was enough of a demand, these could be manufactured cheaper than IDE cables.
I think it could be a much cheaper solution to the folks that don't need top of the line. Then again, Mounting the filesystem "read only" would be even easier.
I read the article and it described a system where if you have a website that serves only static content you can use this snake oil technology to prevent people from defacing your website. Why is the technology snake oil:
Get two of them. One to serve "content", the other to record transactions. Content server has the read only head on, the transaction server has the write only head on. Hot swap them for updates and transfer of information.
Not as convient as it is currently done, but for a little ma/pa shop, it might be perfect.
Burn Hollywood Burn
How about we actually write proper software and/or have software engineers sign off on the security of the software. Software is becoming more and more of a hack job because of the abundance of high school/community college lame programmers who are leet because they wrote a H4X0|2 web site with php.
Don't let n00bie programmers write critical software. The quality (more or less) is dependant on the amount you spend on properly educated/experienced software engineers (engineers, not coders.. there is a difference).
A company that underestimates the importance of proper software engineering DESERVES to get burned just as a car manufacturer should get burned if an incompetant engineer designed a car that blew up whenever you hit 120 Km/h.
Software engineering is virtually non-existant as companys think faster project turnover equates to faster profits. The capacities of common programming practices does not provide the needs & demands of the aggresive growth of the current market.
Give software engineers a professional status, with no limits to personal liability.
Wouldn't this make the web server unable to read cache, the information could change.
Can't you have the same effect by having the web server with read only permission to be the only externally accessible program?
Or just mount a ro network drive, over dedicated gigabit ether it shouldn't be that big of an issue.
Take a copy of their site using tools like..
0 14 301003
:D)
http://fileforum.betanews.com/detail.php3?fid=1
Its HTTrack that copies web sites (strangely enough).
Host it on a free website page (or 100 for redundancy - watch em take all those down
Then somehow force a DNS query to go from their original to your copy.
Instant remote defacement.
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
The concept of two heads is not new. On an old IBM System/36, the hard drive had two heads on each arm, one for the outer half of the disk, one for the inner half of the disk (they moved straight in and out radially(sp?) to simplify seeking).
One way cables? That is so cool! I hope the RIAA and MPAA don't hear about this.
What great inventions could possibly be waiting in the wings? Stairs that only go down? One way pipes? Screwdrives that only tighten screws?
Gosh! This new-fangled technology sure is cool!
-- What you do today will cost you a day of your life.
I used "mount" and "file system" where an MCSE might read it.
Sorry. I'll explain.
You see, kiddies, real computers do what is called "mounting" a "file system", which is usually stored on a "hard drive" (the things your computers call "C drive", "D drive", etc.). These "file systems" can be "mounted" or accessed by the operating system (which, by the way, has nothing to do with browsing the Internet) with a bunch of options.
Of these many options, "read-only" can be used to make sure your data doesn't get changed inadvertently.
Of course, if you get r00t3d, you're still fucked.
Comment removed based on user account deletion
Where I work we have two old Interdata ID-70 computers that have that sort of protection. The original tape reels are long since gone, having been replaced by two 3.5" floppies and a solid-state drive containing two megabytes of RAM. When we turn on the machine we have to toggle in the bootstrap code to get the machine to read in the first sector of the floppy, which then takes over and copies the run-time software and static data into the SSD. When we flip the write-disable switch on the SSD is disconnects the write signal from the lower 512K of RAM. This allows the system to store dynamic data updates in the upper regions of the SSD while protecting the program and static data against overwrites.
Isn't it obvious by now that any security can be passed by some means, or else it wouldn't be accessible to the user in the first place?
sir_haxalot
stuff |
What's the difference between this fancy solution and one server (file server or database server) providing read only access to another (web) server?
Just a question...
Hey, anyone remember Lisa's floppy drive? Was it something like this? Or were the 180-degree seperated heads, just for different surfaces?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The only reasonable application I could think of this is for file sharing on a closed network (such as a schools) where files need to be shared out and distributed and still maintain the security to lock out script kiddies. I cant see this being used for anything other than static pages (I know redundant). While this techonology is meant to be used for web purposes, I think that the majority of the people that buy hard drives with two heads will find much better uses for it in networks that need to protect data that still needs to be read. Yes, most of this can already be done in software, however, I usually tend to think of the hardware solution as the best.
While this should make it quite a bit tougher for script kiddies to place their mark on a page, I doubt it will stop any real hackers from getting to a site's DB as that would still need to be r/w."
;o)
I think this is made light of. Even if a script kiddie defaces your webpage, it's still embarassing to the company. You can call him a lamer all you want, it doesn't help any.
These hard drives make your server just that much more secure... even if it is just a little.
AND it's plug in and go (nearly), because believe it or not, there's more to business than computers!
Find Escorts, Strippers, Massage Parlours, Swingers
Connor's drive also only wrote from one head.
But more importantly, the 4 9GB drives=1 36GB drive thing is misleading. The reason to put multiple heads on is primarily to reduce latency. It cuts latency in half.
To show this we ignore tracks (seeks) for the moment. Any one sector can be anywhere from under the head right now to having just passed the head, in which case it will be a full rotation before it passes again. In the right under case the latency is 0, if it has to go a full rotation it is 1/120th of a second (8ms) on a 7200rpm drive away. On average, you can assume the sector is 1/2 the way around the disk from here for an average rotational latency of 4ms on a 7200rpm drive.
If you have 4 drives, the average sector is still half a rotation away on the drive it is located on, physics says so. If you have 4 heads though, the head can take no longer than 1/4 rotation and will on average be 1/8th rotation away. This is an average rotation latency of 1/2ms for a 4 head 7200rpm drive.
Thus 4 drives striped together do not reduce latency, but 4 heads on 1 drive do.
Note that when you stripe drives together you will actually increase latency if you don't spindle lock them together. This is because you must wait until the sectors you want (they are split up between drives) ALL pass under the heads. Thus your latency is equal to the worst latency of your multiple drives. Striping makes latency worse if you don't spindle lock.
In summary, having two heads reduces latency by half. Doubling the rotational speed (15,000rpm drive) does also. Finally, mirroring all the data across two drives and spindle locking them so they are 180 degress out of phase also has the same effect on read latency.
to wit, ibm implemented it first in their 14gxp series like 5 or 6 years ago. ide drives support it. ide controllers support it. the only limitation is the queue depth isn't as great.
You don't have to modify data on the drive to deface a website if you're that far into a system that the only resort is a read only drive.
:-)
Pop open a RAM drive point Apache there and put whatever questionable material you want on there.
Someone set us up the bomb, so shine we are!
This is just stupid. If you want a read-only hard drive, just set the read-only jumper next to the SCSI connector. Or use a read-only NFS mount to a server behind an additional firewall (transparent if possible). Or get lots of RAM, set up a virtual file system, and copy the content of of a CD-ROM into the VFS.
The drive is just pointless stupidity for pointy-haired managers.
the read-only harddrive would encourage admins to become lazier with regard to applying server patches
Look around at the staggering number of machines still infected with Code Red. I don't think they can get any more lazy.
read the other comments, don't mod me
I hereby place the above post in the public domain.
Wouldn't it be cheaper run it on an OpenBSD machine?
Hrm there is a much easier solution to this problem FCAL drives and a decent switch will allow certine HBA's to see the drive(s) as RO and others to see it as RW. On the higher level you still have to deal with a filesystem thats RO and hases changes happening (weird inode table issues) windows REALY dosent like this happening. Now with all this said there is little to stop somebody from unmounting the partition and putting up other data on the web servers RW partitions. This custom hardware dosent take into account reliability.
No sir I dont like it.
Why not just keep your content on an NFS server and export it read-only via GigE?
This actually sounds like a great idea, sort-of. But why have write ability at all? /floppy disks/ have had a similar option for as long as I can remember. This wouldnt just be flipping a bit, though [as obviously to a malicious user this doesnt really matter], but would have the effect of opening up the case and bending-back the write-head's control pins.
Think about this: You update your site, finish with everything you were going to do for a while, no one has any reason to be writing to the disk for now, unless they're doing something they shouldnt be, so you flip a switch.. and writing is now utterly, 100%, impossible, without having physical access to the machine. [which, in general, would make your data doomed anyway]
Obviously there are problems regaurding remote-administration, but something so simple that
So why not?
["If you really want to, burn it to CD.":: that works for all those 600MB web sites out there (yeah, I know, I'm sure there are plenty of respectable ones out there)]
-- 'The' Lord and Master Bitman On High, Master Of All
Couldn't this potentially cause problems with log files being written? Unless you'd prefer not to have log files, but we are on the subject of security, right?
to turn off the buffer cache.
Wow, I wasn't thinking. Of course, cookies are on the client.
However, there are lots of interactions between client and server that need to be saved that aren't necessarily for the DB to handle.
I also fail to see how all OS'es/hardware combinations are going to be compatible w/ this.
BTW, there are already dual voice-coil drives out there in SCSI and SSA flavors....
EOM
This piece of hardware is the funniest thing I've heard all day. Wahoo! Next I want monitors that require a Buck Rogers decoder ring!
So, yes, the cookie is stored client side. The data it represents, however does not (and shouldn't for a number of reasons, including security) reside on the client computer.
Good web programmers should also delete the cookies from the browser for login data when the user 'logs out' from the site.
You dumb ass. You're a total fucking retard. You should drop on the ground and stop breathing right now.
I don't think you've read it either. Go back to McDonald's you cheesburger reject. You don't know shit.
We mount this read only, which is basically the same damn thing.
When an update is to be flushed to production, I have a script that drops the webserver, umounts the fs, mounts it read+write, copies staged code/html over, umounts it again, remounts it +r and restarts apache.
php, cgi, mysql etc all work fine. No worries. No need for a bunch of engineers to figure out what's simply common sense for UNIX guys... hmm?
Yea, I can see you read slashdot too. But guess what, that doesn't make you a fucking authority on shit, ass wipe. You are posting the most obvious shit known to techy man. Congradulations, I think there's a spot for you on the "Pointing out Fucking Obvious shit that people's already read on slasdot" panel and you can be the president.
It seems to me that this has already been done using NAS (netowrk attached storage). That could be a separate hw in the restricted zone, that can be contacted by two users: on r/w, and one r/o. The public server uses the RO user, the private uses the RW. This way, if someone hacks the public part, they will get no chance to connect by RW, therefore they cannot erase/update the data. Simple enough.
Besides, this is more secure and faster, since RAID and caching are usually implemented on NAS.
So, I see no point to this.
(IIRC some VAXes had disks with two independent controllers and cabling, so they could be connecterd to two separate machines. These were both r/w, though.)
Surely two heads is going to have a considerable effect on the MTBF, in the order of 40% maybe, since most of the the drive failures I've had have resulted from head failure. With enough drives in your storage array that increase is going to become very visible, very quickly.
UNIX? They're not even circumcised! Savages!
Create and mount a ramdrive.
Ta-da; read/write access. Web site defaced.
Quoting from that site's page:
"The prototype currently works on Windows NT4.0 CD-ROM running Active Server Pages and IIS..."
Yep, this would be the bonehead target market. It sure seems IIS gets cracked a hell of a lot more than Apache. Use a real webserver.
Of course, now this Guardian is itself a great target for hackers... Plus I think this technique is already patented :-)
I do not deploy Linux. Ever.
Many old school coders still feel that the only way to debug source code is with a blue bic pen on greenbar.
I do not deploy Linux. Ever.
IDIOT! ST12450W Double headed!
They were very fragile, but for over 3 years no hard idks on earth was faster when formatted using 2K blocks.
I own 6 ST12450W personally.
They transfer more data per second into a Mac than a Sun workstation transferred null data into dev/null
Hurray for cachline DMA pumping.
It amazes me how shortsighted everyone is.
Seagate made 12450W ages ago and they were fast fast fast.
Use a Mac webserver. No Mac ever rooted in history.
Using non-Unix Mac OS 9.x or older and a webserver application such as WebStar , no mac has EVER been rooted or exploited remotely according to BugTraq.
Despite many huge contests.
Once in 1995 a buggy 3rd party addon package created a rare backdoor, but was quickly discoverred and not widely used.
Macs are the most secure webservers for many technical reasons (stack return address, lack of ANSI C strings in most code, use of Pascal strings in ROM, lack of command line, lack of root accounts (everything except kernel runs at root), lack of file extensions settable by users, lack of file extensions to signify executable code, requirement that all executable code have two forks (files), cgi files needing special file types, etc etc.
Macs have always been 100% secure when runnin os9.x or older and thats why the US army used macs for some of its webservers.
This is about the second dumbest thing I have ever heard of! There are so many easier ways to solve this problem then the complexities of integrating two computers to the same hard drive! If you are so damn stupid that this is the only way you can think of to completely protect the integrity of your web site (and it better not do anything but display content as there will not be any way for your customers to made database updates) why not just burn the entire file set to a CD and run it from there? That is certainly read-only! When ever you need updates, just burn another. LOTS cheaper!
I have to use this cause I can't afford a real sig...