If he says "Tape and HD backup are not an option", well, I'd think he has considered all the other solutions. There are cases where CD archiving is the only solution. For example: - Legal requirements of read-only media. My case. - If archives must be guaranteed readable by common
hardware (and I mean COMMON, try buying a tape reader
in your favorite supermarket...)
Sure, backup on CD is a pain, but this was not his question.
Just go with a SCSI jukebox; it should work fine on Linux with "mt", "mtx" and some shell woodoo; ours did. You might perhaps check if your vendor supports standard SCSI commands, though.
>It is a concrete fact that that no MacOS based >webserver has ever been hacked into in the history of the internet.
It's also a concrete fact that there are very few MacOS based servers around...
>The MacOS running WebStar and other webservers as >has never been exploited or defaced, and are are >unbreakable based on ample historical evidence.
AMPLE evidence? Apache had some security issues, but about 60% of the market, too...
>In fact in the entire SecurityFocus (BugTraq) >database history there has never been a Mac >exploited over the internet remotely. Scan it >yourself....see the prevoius point
>That is why the US Army gave up on MS IIS and got >a Mac for a web server.
well, as stated by yourself, a Web server can always fool a client into thinking he's something different.
>Why is is hack proof? These reasons :
>1> No command shell. No shell means no way to >hook or intercept the flow of control with many >various shell oriented tricks found in Unix or >NT. Apple uses an object model for procces to >process communication that is heavily typed and >"pipe-less"
Ok, this is true. But now try to administrate
your nifty MacOS server via a remote session
300km away...
>2> No Root user. All mac developers know their >code is always running at root. Nothing is higher >(except undocumented microkernel stufff where you >pass Gary Davidians birthday into certain >registers and make a special call). By always >being root there is no false sense of security, >and programming is done carefully.
Ok, i'll run everything as root from now
on, my "false sense of security" will go away for sure.
>3> Pascal strings. ANSI C Strings are the number >one way people exploit Linux and Wintel boxes. >The mac avoids C strings historically in most of >all of its OS. In fact even its roms originally >used Pascal strings. As you know pascal strings >are faster than C (because they have the length >delimiter in the front and do not have to >endlessly hunt for NULL), but the side effect is >less buffer exploits. Individual 3rd party >products may use C stings and bind to ANSI >libraries, but many do not. In case you are not >aware of what a "pascal string" is, it usually >has no null byte terminator.
C string may or may not be slower than Pascal strings, according to what are you doing with those strings.
If you write code in C, you'll have C strings. What your OS does with them is not relevant.
>4> Macs running Webstar have ability to only run >CGI placed in correct directory location and >correctly file "typed" (not mere file name >extension). File types on Macs are not easily >settable by users, expecially remotely. Apache as >you know has had many problems in earlier years >preventing wayward execution.
Apache does, too.
>5> Macs never run code ever merely based on how a >file is named. ".exe" suffixes mean nothing! For >example the file type is 4 characters of >user-invisible attributes, along with many other >invisible attributes, but these 4 bytes cannot be >set by most tool oriented utilities that work >with data files. For example file copy utilities >preserve launchable file-types, but JPEG MPEG >HTML TXT etc oriented tools are physically >incapable by designof creating an executable >file. The file type is not set to executable for >hte hackers needs. In fact its even more secure >than that. A mac cannot run a program unless it >has TWO files. The second file is an invisible >file associated with the data fork file and is >called a resource fork. EVERY mac program has a >resource fork file containing launch information. >It needs to be present. Typically JPEG, HTML, >MPEG, TXT, ZIP, C, etc are merely data files and >lack resource fork files, and even if the y had >them they would lack launch information. but the >best part is that mac web programs and server >tools do not create files with resource forks >usually. TOTAL security.
A file is a file, is a file. Once I can run arbitrary code on a server, who keeps me from
creating both data fork and resource fork?
>4> Stack return address positioned in safer >location than some intel OSes. Buffer exploits >take advantage of loser programmers lack of >string length checking and clobber the return >address to run thier exploit code instead. The >Mac compilers usually place return address in >front or out of context of where the buffer would >overrun. Much safer.
Again, the flaw is in the C language - the stack contains both the return address and the parameters, if you overflow them -BLAM!- no matter where the stack is stored.
By the way Pascal does the same thing (only in a different order).
>7> There are less macs, though there are huge >cash prizes for cracking into a MacOS based >WebStar server (typically over $10,000 US). Less >macs means less hacker interest, but there are >MILLIONS of macs sold, and some of the most >skilled programmers are well versed in systems >level mac engineering and know of the cash >prizes, so its a moot point, but perhaps macs are >never kracked because there appear to be less of >them. (many macs pretend they are unix and give >false headers to requests to keep up the >illusion, ftp http, finger, etc). But some huge >high performance sites use load-balancing >webstar. Regardless, no mac has ever been rooted >in history of the internet, except with a strange >3rd party tool in 1995.
To crack a Mac, you would need at least:
- a mac
8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event ages ago in 1995, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc.
I think its quite amusing that there are over 200 or 300 known vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Not one exploit. And that includes Webstar and other web servers on the Mac.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.
BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.
BugTraq concurs! As does the WWW consortium. So you do not need a book to teach you how to pathetically try to secure a website, just use a Mac, as many colleges and large media sites do, and many commercial airlines for their in-house security.
I read, some years ago, a book containing interviews to famous programmers, included Simonyi.
He started writing code on a Russian vacuum tube calculator (The Ural II already mentioned) because he was working as a night guardian.
Vacuum tubes often die when turned on because of thermal shock: so to reduce downtime the monster was
never turned of, and our hero was left alone at night with it, as a sentinel.
Slashdot Mirror
Perhaps. Or, more probably, Italian alphabet only has 21 letters. As a side note, you live in US, don't you?
If he says "Tape and HD backup are not an option", well,
I'd think he has considered all the other solutions.
There are cases where CD archiving is the only solution.
For example:
- Legal requirements of read-only media. My case.
- If archives must be guaranteed readable by common
hardware (and I mean COMMON, try buying a tape reader
in your favorite supermarket...)
Sure, backup on CD is a pain, but this was not
his question.
Just go with a SCSI jukebox; it should work fine on Linux
with "mt", "mtx" and some shell woodoo; ours did.
You might perhaps check if your vendor supports standard
SCSI commands, though.
Auralizer? English is not my mother tongue, but if "Aural-" is for "Auricolar", what is an "Analizer" for?
argh, pressed return by mistake..
>It is a concrete fact that that no MacOS based >webserver has ever been hacked into in the history of the internet. It's also a concrete fact that there are very few MacOS based servers around... >The MacOS running WebStar and other webservers as >has never been exploited or defaced, and are are >unbreakable based on ample historical evidence. AMPLE evidence? Apache had some security issues, but about 60% of the market, too... >In fact in the entire SecurityFocus (BugTraq) >database history there has never been a Mac >exploited over the internet remotely. Scan it >yourself. ...see the prevoius point
>That is why the US Army gave up on MS IIS and got >a Mac for a web server.
well, as stated by yourself, a Web server can always fool a client into thinking he's something different.
>Why is is hack proof? These reasons :
>1> No command shell. No shell means no way to >hook or intercept the flow of control with many >various shell oriented tricks found in Unix or >NT. Apple uses an object model for procces to >process communication that is heavily typed and >"pipe-less"
Ok, this is true. But now try to administrate
your nifty MacOS server via a remote session
300km away...
>2> No Root user. All mac developers know their >code is always running at root. Nothing is higher >(except undocumented microkernel stufff where you >pass Gary Davidians birthday into certain >registers and make a special call). By always >being root there is no false sense of security, >and programming is done carefully.
Ok, i'll run everything as root from now
on, my "false sense of security" will go away for sure.
>3> Pascal strings. ANSI C Strings are the number >one way people exploit Linux and Wintel boxes. >The mac avoids C strings historically in most of >all of its OS. In fact even its roms originally >used Pascal strings. As you know pascal strings >are faster than C (because they have the length >delimiter in the front and do not have to >endlessly hunt for NULL), but the side effect is >less buffer exploits. Individual 3rd party >products may use C stings and bind to ANSI >libraries, but many do not. In case you are not >aware of what a "pascal string" is, it usually >has no null byte terminator.
C string may or may not be slower than Pascal strings, according to what are you doing with those strings.
If you write code in C, you'll have C strings. What your OS does with them is not relevant.
>4> Macs running Webstar have ability to only run >CGI placed in correct directory location and >correctly file "typed" (not mere file name >extension). File types on Macs are not easily >settable by users, expecially remotely. Apache as >you know has had many problems in earlier years >preventing wayward execution.
Apache does, too.
>5> Macs never run code ever merely based on how a >file is named. ".exe" suffixes mean nothing! For >example the file type is 4 characters of >user-invisible attributes, along with many other >invisible attributes, but these 4 bytes cannot be >set by most tool oriented utilities that work >with data files. For example file copy utilities >preserve launchable file-types, but JPEG MPEG >HTML TXT etc oriented tools are physically >incapable by designof creating an executable >file. The file type is not set to executable for >hte hackers needs. In fact its even more secure >than that. A mac cannot run a program unless it >has TWO files. The second file is an invisible >file associated with the data fork file and is >called a resource fork. EVERY mac program has a >resource fork file containing launch information. >It needs to be present. Typically JPEG, HTML, >MPEG, TXT, ZIP, C, etc are merely data files and >lack resource fork files, and even if the y had >them they would lack launch information. but the >best part is that mac web programs and server >tools do not create files with resource forks >usually. TOTAL security.
A file is a file, is a file. Once I can run arbitrary code on a server, who keeps me from
creating both data fork and resource fork?
>4> Stack return address positioned in safer >location than some intel OSes. Buffer exploits >take advantage of loser programmers lack of >string length checking and clobber the return >address to run thier exploit code instead. The >Mac compilers usually place return address in >front or out of context of where the buffer would >overrun. Much safer.
Again, the flaw is in the C language - the stack contains both the return address and the parameters, if you overflow them -BLAM!- no matter where the stack is stored.
By the way Pascal does the same thing (only in a different order).
>7> There are less macs, though there are huge >cash prizes for cracking into a MacOS based >WebStar server (typically over $10,000 US). Less >macs means less hacker interest, but there are >MILLIONS of macs sold, and some of the most >skilled programmers are well versed in systems >level mac engineering and know of the cash >prizes, so its a moot point, but perhaps macs are >never kracked because there appear to be less of >them. (many macs pretend they are unix and give >false headers to requests to keep up the >illusion, ftp http, finger, etc). But some huge >high performance sites use load-balancing >webstar. Regardless, no mac has ever been rooted >in history of the internet, except with a strange >3rd party tool in 1995.
To crack a Mac, you would need at least:
- a mac
8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event ages ago in 1995, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc.
I think its quite amusing that there are over 200 or 300 known vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Not one exploit. And that includes Webstar and other web servers on the Mac.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.
BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.
BugTraq concurs! As does the WWW consortium. So you do not need a book to teach you how to pathetically try to secure a website, just use a Mac, as many colleges and large media sites do, and many commercial airlines for their in-house security.
I read, some years ago, a book containing interviews to famous programmers, included Simonyi. He started writing code on a Russian vacuum tube calculator (The Ural II already mentioned) because he was working as a night guardian. Vacuum tubes often die when turned on because of thermal shock: so to reduce downtime the monster was never turned of, and our hero was left alone at night with it, as a sentinel.
mmm... a Beowoulf cluster of these...
Congrats!!!