New Two-Headed Hard Drive Intended To Secure Web Sites 366
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."
More Speed? (Score:4, Interesting)
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.
Re:What would be the input route? (Score:2, Interesting)
But then, of course, I'm no expert with these drives and there may be other factors which I am overlooking.
NFS? (Score:3, Interesting)
Do it for SPEED, not SECURITY (Score:2, Interesting)
NFS can do the same for you (Score:2, Interesting)
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.
*yawn* (Score:3, Interesting)
*yawn*
Seems to me that a database that doing this the other way around (write only head, separate read head) would be the smart way to go, store customer data, but only trusted computers can get any of it off! (though displaying customer info might be a bit of a challenge, heh, oh well, store name and address on regular drive, store valuable information on the special drive)
Isn't it easier.. (Score:1, Interesting)
Add in remote logging for the server/servers, and that should be reasonably tight.
Industry rejected multi-head drives long ago... (Score:5, Interesting)
"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.
Re:Protection from defacement only, and then iffy. (Score:3, Interesting)
That's a nice point, however, I don't think this should have any impact on your decision wether to use this product/strategy or not.
DOS attacks are a problem that are near impossible to solve no matter what hardware you may have (even your 10's of thousands of dollars worth of Cisco routers). This product isn't targetted at DOS attacks.
Buffer overflows and whatnot are still possible.
BUT BUT BUT! They are FAR less effective. One of the problems with overflows are that they give you access to the machine. The danger is when they can login to the machine, install all their hacking tools, packet sniffers, and what not. That's where the real damage is done.
Now, if the ENTIRE hard disk on the web server is read only, and the machine that they use to make changes to the partition is on a complete seperate network (perhaps not even connected to the internet at all) this could be a VERY effective way of limiting damage done (especially if you are carefull about what applications are installed on your server to begin with).
Database attacks would be the worst, though, since, as Timothy again points out, they must be writeable.
Finally, this is not necessarilly true as well. If you run a website that provides the user with realtime information (such as stock quotes, or mortgage rates), most of the data is coming from some source internal to your company. You can easily make that database readonly for the web server, and seperate any minimal user info database into it's own read/write database thus further limiting the damage they can do. In fact, if you aren't doing this already you're probably doing something wrong. Here at work we have two seperate copies of our database (replicated in realtime). One is linked directly to our internal accounting system and updated frequently. The other is 100% read only and ALL reports are run from that.
I'm not nitpicking you, or anybody in particular. This is a GREAT option. It's not perfect yes, but if you really think about it, you can use this thing in many very very powerfull ways (and as mentioned above you can do some similar things by tweaking IDE cables and useing CD roms). Same thing can be said for Linux router distributions running off of read only 3¼ floppies or CD-Roms! :)
Bryan
Re:how about this? (Score:2, Interesting)
Which is all fine and dandy, until the guy who just rooted you figures out that all he needs to do is 'mount -o remount,rw
Seriously, you can't rely on the OS to protect you from this (with the possible exception of BSD's hich security more coupled with the immutable flag - so the file can only be modified when the system is in runlevel 0..)
Re:Protection from defacement only, and then iffy. (Score:2, Interesting)