Internet Site Security 122
| Internet Site Security | |
| author | Erik Schetina, Ken Green and Jacob Carlson |
| pages | 432 |
| publisher | Addison Wesley |
| rating | 8 |
| reviewer | Mirko Zorz |
| ISBN | 0672323060 |
| summary | This book manages to shed new light on the problems of security implementation; a good gift idea for both your IT manager and your system administrator. |
About the authors
Erik Schetina, CISSP, is the CTO for TrustWave Corporation. He spent 14 years with the U.S. Department of Defense developing information security systems and public key cryptosystems. Jacob Carlson is a senior security engineer for TrustWave Corporation. His primary role is leading the penetration testing and vulnerability assessment team. In his copious free time he likes breaking things and writing code. Ken Green is a senior security engineer for TrustWave Corporation where he works extensively on intrusion detection systems, firewalls, and virtual private network initiatives.
When you read biographies like the ones above you can be somehow reassured that the content of the book is good. All of the authors come from TrustWave Corporation and the fact that they work together has influenced the writing of this book, in a very good way.
The basics
At the very beginning of the book the authors show us that the starting point of building a secure environment is not the implementation of a solution but rather the defining of the assets we want to protect. You have to know what's a threat to your assets in order to choose the best security solution.
The authors manage to successfully illustrate how different things such as system administration, policy and audits fit into an overall security plan. Through the book, the authors educate the reader by making sure he sees "the big picture." The bottom line is that "the transition from a techie to a security professional consists in the recognizing the importance of all the components of security." In the second chapter some great material is covered: description of the security process, assessment and policy, asset protection, monitoring and detection.
Which one is better?
When describing the way things can be done, the authors always give you the pros and the cons. For example, at one point they describe the difference when using commercial scanners in penetration testing compared to using a team of people who will do it by hand. They provide good pros and cons for both ways, and that's one of the great things about this book, you always get to look at the other side of the coin.
The insecurities
What we all know is that the Internet is inherently insecure -- that's why this book was published in the first place. The authors explain why it's insecure, who administers it and how it works. Some of the topics presented here are: an overview of TCP/IP, the Domain Name Service (DNS), Whois databases, anonymity, and much more.
History is also present in this book. Chapter 4 begins with a brief overview of the history of the Internet and the TCP/IP protocol suite. Also mentioned is the Morris Worm (November 1998). As we move on, the DNS is explained in greater detail (with some security issues addressed specifically), and we are slowly presented with an abundance of technical details that stretches over several chapters. Some of the things that are explained in the book include: secure protocols, virtual private network protocols and encapsulation, the secure shell (SSH) and authentication systems.
As an inevitable part of a book of this kind, there's a part dedicated to passwords (and good rules for their generation), and another on digital certificates. The authors present the shortcomings of certificates as well as their best uses. Although neither of these are explained in great detail, you'll be able to get an overview of the things presented.
Moving on, we get a plethora of information covering: firewalls, DMZs, VPNs, external and internal threats, the security of wireless networks, workstation management issues, intrusion detection systems and log processing, etc.
Operating systems
The book also gives some good information when it comes to operating systems and server software. Some of the covered topics include:
- Windows NT and 2000 - authentication, access tokens, security identifiers, object access control lists, tightening Windows users rights, etc.
- Linux - overview of the Linux Kernel, file system permissions, authentication mechanisms, how PAM works, etc.
- Server security: web, mail, FTP, etc.
If you want information about attacks, denials of service attacks are covered in great detail, along with many other attack scenarios. Since you also want to protect yourself from all of these attacks there's naturally much material dedicated to firewalls: their functions, implementation issues and vulnerabilities. Now that's not enough, is it? Now you want more. There's a whole chapter dedicated to intrusion detection systems and one dedicated to incident response and forensics. The chapter on incident response and forensics will be of particular interest for all of you who want more knowledge of legal and privacy issues.
Secure Code
To complete the book, there's a chapter dedicated to the developers, which discusses the development of secure Internet applications. Here you'll be able to read about common sources of programming mistakes, exploiting executable code, application-level security, coding standards, and more.
The verdict
This book manages to shade a new light on the problems of security implementation by explaining the position of the system administrator and the position of the IT manager in order to make them both understand their role in the overall process of security in the company. It's a good idea to give it to both your IT manager and your system administrator, they will both learn from it and in the process start to understand each other on a new level. With this book, you basically learn to think on a larger scale.
There are not many downsides. There are basically only two things that I didn't like about this book: the lack of resources, and (in parts) the writing style. There are not enough resources listed, and I always like to get to more information. As regards the writing style it's obvious that this book was not meant to entertain in any way, but it sometimes seems a bit too serious. I always believed that learning should be fun. That's just me :)
Overall, this is an excellent book, two thumbs up!
If you're interested in hearing what one of the authors of the book has to say, you can check out an interview with him here. You can purchase Internet Site Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I like big Books, and i cannot lie... (Score:3, Funny)
I thought we all wanted bigger manhood. At least that's what 30% of my spam has been promising. And for only $50!
Re:I like big Books, and i cannot lie... (Score:1)
little suggestion (Score:5, Insightful)
Re:little suggestion (Score:4, Informative)
actually (Score:1)
Time is money
Re:little suggestion (Score:2, Informative)
BTW, the $ symbol tells everyone it is US currency, hence the US is redundant in your price post.
Re:little suggestion (Score:3, Funny)
Really? Maybe we outta go smack those damn Canadians around then for weezing our gig</Pauly_Shore>
Re:little suggestion (Score:1)
Re:little suggestion (Score:1)
Yep, Australia, Canada, New Zealand, Hong Kong, the Bahamas, Barbados, Bermuda, Eastern Caribbean, Fiji, Jamaica, Singapore, Taiwan, Trinidad and Tobago, and probably some others I'm not aware of, have STOLEN the name of the AMERICAN currency!
This is one of the funniest things I have seen on /. in a long time, because it was serious. My sig is aimed at people like you.
Re:Books on security... (Score:3, Insightful)
If the book's about how to ensure a given app is secure (e.g DIND, IIS) then you're right, as both apps keep having vulnerabilities found.
If it's about the general proinciplers of security then it will become out of date but not at quickly as you make out.
Tom.
Re:Books on security... (Score:5, Insightful)
Not necessarily.
Books that cover the latest vulnerability in RandomOS can go stale very quickly; books that teach sound security principles tend to have a much longer shelf life.
There's plenty of good rreading though. (Score:2)
There's plenty of good reading though
By that, I meant that the concepts, etc are still relevant. *shrugs* mods....
Ask Slashdot...A little OT (Score:5, Interesting)
So, I ask the Slashdot crowd; Do you really want big/bigger books? Or, is 300 pages plenty, provided the information is in there?
Quality over size (Score:5, Interesting)
Re:Quality over size (Score:5, Informative)
Some people buy cars with the turning radius of an oil tanker, books with 10 pages of useful content and 1000 pages of bug-ridden listings, and big plastic boxes with a couple of silicon chips in them, so maybe this is a cultural thing. I leave admiring the bigger is better idea to personal attributes (Jouko Ahola/Lola Ferrari/Filip Smirnov for example) or possibly monumental architecture rather than consumer items.
Stroustrup edits a series... (Score:2)
...of books called the C++ In-Depth Series. Very well-written, all by experts.
One of the series' rules is that the main body text of a book must be no more than 300 pages. Be clear, be concise, get to the point and shut up.
Most excellent books.
Re:Quality over size (Score:4, Interesting)
Yes, it's a nitch market. Geek books will never have the market of someone like Stephen King. However, attempting to gouge me only means I buy a couple of computer books a year. Whenever I look at a computer book, I ask, "do I NEED this book", as opposed to just wanting it. Very few books can get by this rule.
And why the hell is a paperback geek book more expensive than a hardbound novel?
Re:Ask Slashdot...A little OT (Score:3, Informative)
K&R book was OK. Anything beyond 500 pages is way too much, unless you're aiming at "The World Explained for Really Dumb People: From Physics to Philosophy"
Re:Ask Slashdot...A little OT (Score:1)
Re:Ask Slashdot...A little OT (Score:3, Informative)
Re:Ask Slashdot...A little OT (Score:2, Insightful)
Quality, not quantity (Score:4, Insightful)
I honestly will not buy a technical book in the 1,000+ page range, especially if the title:
Why? Because I know I'm unlikely digest the contents of 1000+ pages of text on one subject, if I manage to finish it. I also generally suspect large books of rehashing FAQs or other widely-available docs just to fill pages.
I don't consider myself an O'Reilly bigot, though I do lean towards their books since they tend to publish smaller, focused books. If a book is pure reference, I may consider buying it if it's 1000+ pages. Following are examples of some great books I've bought that I found very useful and readable due to their small size:
The Internet already offers me an overwhelming, disorganized pile of information on any subject--and at least it's searchable via Google. Dead tree books have use when they're usable and organized, and I've found that generally translates into a smaller book.
Re:Quality, not quantity = Buy British (Score:1)
Just my own personal experience.
Size Doesn't Matter... (Score:1)
It does not matter what size the technical book is, it only takes 5 pages to induce deep sleep and dooling!
Life is like an elevator, sometimes you get the elevator and sometimes you get the shaft
Re:Size Doesn't Matter... (Score:2, Funny)
I'm not a spelling nazi, hehe, it just reads funny.
Don't be seduced by big books (Score:3, Insightful)
Not only is a big book not necessarily better; it is almost invariably worse. For simple reasons: Writing well is difficult. It takes a lot of work for an author--or a team of two or three working closely--to produce 200 quality pages. 1000 quality pages would be a monumental effort that, frankly, nobody's going to put into a book on Visual Basic. Further, concision is a mark of good writing, so when you see a big book, you should wonder, "why were they not able to get this into 200 pages?". Not to mention that a big book takes longer to read, is harder to find things in, and is less convenient to use and carry.
For most technical books, the only ways to get to 1000 pages are to write sloppily, add filler, or employ many authors working independently. The last tends to produce an incoherent whole, and make each author care less about his contribution.
The main exceptions are books with a justifiably large reference section (large because there is truly a lot of valuable material to reference, which is uncommon), and, to some extent, books that have been through several editions, whose authors have put new effort into each edition.
Re:Ask Slashdot...A little OT (Score:2, Insightful)
The idea behind "big" books, is that it's a reference book. You only open it once or twice a week when you want a specific information (aka phone book).
if you want a book to introduce you to a subjet, it should'nt be 10000+ pages... just a small good read... that you read once and you can easily re-read when you to refresh you memory.
Re:Ask Slashdot...A little OT (Score:2)
It would have been extremely difficult to fit the material we covered in 300 or so pages. The standard layout stuff that tends to add pages is there, but no appendices with code listings or anything like that.
There are some sections that I would call beginner sections that could have been left out if we were targeting specificly advanced users, it could have been smaller, maybe 500 pages.
Still, at 800, there are still topics that didn't get coverage that could have, so I don't think page count by itself is any measure of how good the book will be.
Its not the size, it's how you use it.
Re:Ask Slashdot...A little OT (Score:2)
What else is there to say? There is wisdom in these two statements that I can't really expand on, and the trend towards bigger tech books certainly ignores.
Like K&R's book, a lot of these tech books of arcana are about highly specialized areas. Taking a random stroll down the books that have a current place on my desk shelf, I've got books on: MySQL & Perl for the Web, HTML4, Programming Internet Email, VPNs, NFS/NIS, SQL, Perl DBI, TCP/IP admin, Bash, mod_perl, Perl LWP, and others. All of these are small subjects, and at a glance it doesn't look like any of these books goes much above 400 pages. Ah, I tell a like -- the mod_perl "eagle book" is much longer, but then it gets deep into the Apache API, so it isn't exactly padded.
On the other hand, some of the longer books I've got -- one of FreeBSD, one on MySQL, Perl Cookbook, etc -- tend to cover a much wider variety of sub-topics within their stated area, but it's hard to do this in a non-superficial way. It's one thing to go down a checklist & mention every subject area (the FreeBSD & MySQL books seem to be guilty of this); it's much harder to say just enough about each area to be continually useful (Perl Cookbook does well here).
In general, there's a sweet spot between brevity & long windedness. A proper density of information is hard to strike. If there is much to be said about a subject, then I personally would rather see aspects of the larger subject broken out into a more coherent text -- witness all the Perl books that, aside from the language itself, really don't have anything to do with one another (algorithm theory, database programming, client side http, server side http, graphics programming, win32 administration, web database automation, xml, bioinformatics, etc). Is the subject is big enough & cohesive enough to cover overlapping, related areas in one text -- Apache/mod_perl being a good example -- then fine, keep them together and let the book grow longer. But on the other hand if everything you need to know about the SQL implementation of half a dozen RDBMS engines will fit in a skinny little 200 page pamphlet, then let's just save everyone some time and not try to pad that out any further. I for one will never spend my money on those 1000+ page monsters unless they're in the remainder bin & it seems like five bucks would be worthwhile if I ever have to deal with one of those beasts some day.
But was he with the DOD when ... (Score:5, Funny)
Joshua: "Do you want to play a game?"
Re:But was he with the DOD when ... (Score:2)
I have seen many books on internet security (Score:5, Insightful)
Synopsis. (Score:5, Funny)
Don't use IIS.
what were the other 1399 pages for?
Re:Synopsis. (Score:1, Flamebait)
Although, since you're a BSD nut, I'm not surprised.
The IIS server I used to admin had never been hacked. And yes, it was directly on the net and received a fairly high volume of traffic. Personally I would trust someone very knowledgeable with WinNT to put an IIS server up more than I would trust ye olde random Linux elitist to put his "uber-secure" Apache "b0x" on the web.
Re:Synopsis. (Score:2)
I guess that's why Microsoft says UNIX is better [slashdot.org].
Re:Synopsis. (Score:2)
As for that "unsecured" box -- it's not like it was a compromised box or anything. Some asshat uploaded the white paper to a public FTP server. That's their fault, not an inherent fault in the server software, which to me seems to be what you are implying.
Re:Synopsis. (Score:1)
As for that "unsecured" box -- it's not like it was a compromised box or anything. Some asshat uploaded the white paper to a public FTP server.
Interesting, I stand corrected. Thanks.
Re:Synopsis. (Score:2)
I enjoy MS bashing as much as any Linux and *BSD (and Solaris) user, but this is wrong. The box this document was on was not cracked -- it was fulfilling its intended purpose as a public file server, allowing uploads to MS support and downloads by customers of files left there by the support staff. The security failing was in policy, not a technical problem.
The server did what it was supposed to do -- staff members at MS who put a confidential document on a public server as a way of subverting policies related to internal filesharing.
The boxes that MS puts on the 'net are generally fairly well secured. Most problems are due to people, not systems. (Yes, even though I am a UN*X bigot, I'm saying that it is possible to secure a Windows box on the big bad Interweb. Possible doesn't mean easy.)
Re:Synopsis. (Score:2)
very knowledgeable with WinNT AND Apache AND Linux, to setting
up either system.
For instance, I'd certainly trust my own configuration of my own Apache
server, before I'd trust my cat's setup of windows, but that's no more
meanignful than your comment.
Re:Synopsis. (Score:1)
Re:Synopsis. (Score:2)
Re:Synopsis. (Score:1)
Which would you rather run? Which one, if compromised poses a greater risk? I don't know about you, but I'd rather have users on _my_ network running apache (heck, I'd prefer an eggdrop with a hand-written TCL web server
At the very least, script kiddies seem to gravitate to IIS. Perhaps they just think it's cool to bash microsoft, perhaps they like the fact that exploits often run on windows, or perhaps they just like Administrator access better than non-priviledged "nobody" user.
Re:Synopsis. (Score:4, Interesting)
Re:Synopsis. (Score:5, Informative)
We ran about 30 of them, and if you are clever about it, you can do all kinds of things to keep the bugs out.
Step 1. Remove all mappings apart from asp.dll
Step 2. Keep web content on a different drive to the system (thus negating
Step 3. Disable, and never use the default website.
With those 3 things, you don't get affected by about 60% of the bugs.
Add things like making all the static content read only, and only allowed a certain secured firewalled server to update the DBs, and you're almost there. Disallowed any net connections originated by the webservers (with exceptions of course) and you rule out strange shells making connections to IRC servers, etc.
The only other thing is then to STAY PATCHED.
Having said what I've said, I wouldn't like to do it again. Keeping those things secure took up so much of my time. Should it be a full time job to keep webservers running securely?
rpm --freshen -vah apache*.rpm anyone?
Now I have lots more time to do more interesting things
Re:Synopsis. (Score:2, Insightful)
Honestly, if IIS was as insecure as Slashdot likes to think it is, wouldn't the Microsoft site have been hacked more often?
Microsoft's site isn't the problem. The problem is the hundreds of thousands of sites run by people that don't have unlimited budgets like Microsoft, nor the knowledge of the internals, nor the tweaked OSs. MS tried tweaking the hell out of their Hotmail backend to no avail.
MS works OK on the desktop, heck I have one Windows machine at home for gaming but that's it. Robustness and security are not on the MS game plan, point-&-clickability and profit are.
Big Books (Score:4, Insightful)
It has a lot to do with how much they charge for these books. You want $50 for a book that costs $3 to print? (I can hear the anti-RIAA trolls now
If you were to get a normal sized entree (or book) for the amount of money you are spending, you would feel that something is wrong, that you are getting ripped off somehow. Big books sell more than small books. Even if the content is the same. They will make the typeface larger and include tons of screenshots if that is what it takes to make a massive volume.
Expensive and small... (Score:2)
Lots of the true tech books (Fowler on UML for instance is $35 [amazon.com] and is brilliant.
I'd say as a rule that like fine food, the best books are small compact and just tell you what you need to know.
The big books are the crap resturants of the world, lots of food... not much quality.
Re:I'm afraid this book doesn't cut it (Score:1)
Morris worm (Score:3, Informative)
1998: Maurice Worm (Score:5, Funny)
Hmmm (Score:2)
Besides the fact that one chapter is about history leads me to think that this is quite a general thing. However, for people who may want a startup on security, considering the level of the authors, this book may be some good stuff for them.
Re:Hmmm (Score:2)
the authors take a somewhat different approach, one that is less connected to software versions and that will endure in time
While a bit melodramatic, the principles of security are apparantly the subject of the book, not the method. It's quite possible to discuss what an ACL is from a system independant standpoint, without getting into the nitty-gritty of how Windows/Linux/OS 'o choice implements it.
That's what the other 1400 some page books are for. Specifics.
You may have noticed a Barnes and Noble bfast link (Score:4, Informative)
The whole idea is this (Score:1)
This does 2 things:
A: It keeps good job security: Once an idiot(person with low intellect for my purpose) sees the 50+books on the shelf, each over 1k pages, he'll decide that it's a bad idea to go for an IT job. Or better, he shells out $500 for a class and finds out he's expected to read 2000 pages of text plus do a lab manual, plus tests. Makes more money for us who can endure it, or actually figure out how the stuff works.
B: Provides an invaluable recource for referencing to. You're in a bind and can't remember a prociedure, dive into that book and you can find what you need to know.
For example, I have 3 A+ cert books on my shelf. Each of them explain nada to me about the important stuff; how the processer works, how the busses work, basic electronics and binary, etc. eow most of the new stuff works becuase I never learned how the old stuff works in detail.
It's also partially dependance. If you get your cert on one line of books, you'll buy the new editions to keep upto date, ensuring the next book will sell well. However, anyone with half of a brain knows that you read reviews about the new prociedures with the new tech before it comes out. If you don't you are most likely an idiot technician, or the guy who broke the simm slot on my grandma's motherboard, called a better tech over to save your ass, and taped the sim into the slot with masking tape...then stole the dip ram out of it...
I feel the need to go down to best buy and open a can of whup-ass on their "techs"...
Morris Worm... (Score:2, Funny)
Path
Re:Morris Worm... (Score:1)
the main problem is not technical. (Score:5, Interesting)
The main problem is that security is often developed at the end of the project, or completely forgotten, because it doesn't add any functionality to the application.
At the beginning of the project, a prototype is developed (without security, because the goal is to show the application functionality), then a first version (still without security, because you're in a hurry), then the whole thing is developed and someone sometimes starts thinking about security.
Since the application hasn't been designed at the very beginning with security aspects in mind, you end up adding hacks and workarounds to the application to make it a bit more secure, but it's sometimes very hard because it might break the functional spec or make the application look different than in the demo.
At the end, you often end up with a solution which uses security through obscurity: since there is no link to this administration page in the welcome page, users won't find it! BAHAHAHAHA!
JB.
Password generation (Score:5, Interesting)
Some examples:
gymolifi
tosenima
qopanela
Because of the alternating pattern, the results are almost always pronouncable, which makes the passwords signifigantly easier to remember. Digits or symbols can be added to satisfy password requirements and increase security.
Re:Password generation (Score:2)
Of course, capitalise one of the letters, and fling in a little dash of puctuation somewhere, and it'll be x^n times hard to guess...
Re:Password generation (Score:2)
You really want to discover one of those passwords by brute-force guessing it?
For comparison: using all alfanumeric characters (A-Z,a-z,0-9), we obtain 218.340.105.584.896 combinations - wow!
ms
--
Re:Password generation (Score:3, Interesting)
People seem to select lexographical patterns (words with numbers replacing some of the letters
And I don't have to remember the password proper; only the non-trivial pattern it makes on my qwerty. Results are usually with letters, numbers, and symbols, but its very easy to remember the visual footprint of these passwords.
Re:Password generation (Score:2, Informative)
"I like to take the initials of a sentence" -> "iltttioas"
You can do things like alternate case and add symbols before/after.
Re:Password generation (Score:1)
I'd like to fly, Shipwrecked and Comatose, Drinking fresh Mango Juice
Would yield the password: Il2fSaCdfMJ
Yes, I am a Red Dwarf Fan, and No, I have never used this as an actual password!!
The phrase is more easily remembered than the password, and yields a password which is relatively hard to break by brute force. Of course, phrase based passwords can be weak to Social Engineering, but that's another issue entirely!
non text passwords (Score:2)
Re:Password generation (Score:2)
$ key.pl
Password:
Website: slashdot.org
Password for slashdot.org:
llynUngiltBerneLobal
Its fairly useful on a day to day basis.
who wants big books? (Score:4, Insightful)
No we don't. Personally, since reading Kernighan & Ritchie, I've been convinced that good books have to be slim.
(another precondition is that it doesn't have a "Learn X in x minutes/hours/days" title)
Re:who wants big books? (Score:1)
Usually true, but not necessarily. Sams Publishing's "Learn Java 2 in 21 Days" is a wonderful book.
Re:who wants big books? (Score:1)
"Thinking In Java" is not too slim (not massive either though), but it's a really great book.
Re:who wants big books? (Score:3, Interesting)
I couldn't agree more. In fact, K&R themselves said it best in the preface to the second edition:
some what contradictory (Score:4, Interesting)
Overall, this is an excellent book, two thumbs up!
This seems kind of odd, or is it just "thumb" inflation. Two thumbs up does not mean what it used to...
Newer and cheaper book available (Score:5, Informative)
Big Books (Score:1)
Papers on securing your website (Score:2, Informative)
www.cgisecurity.com/lib [cgisecurity.com]
From your review it sounds like great theory (Score:2, Offtopic)
Windows NT and 2000 - authentication, access tokens, security identifiers, object access control lists, tightening Windows users rights, etc.
Ok, I could have ignored this review until I got to that part.
Windows 2000 sounds like a complete, powerful system in theory. To salespeople and even project managers, Windows 2000 is packed with all of the buzzwords they want to hear. "Security Reference Monitor", "Policies", etc.
Of course, anyone with practical, in-the-trenches experience knows that it's an impossible system to keep secure. It is big, it is bloated, it is closed source. It discourages deep understanding and is too complicated and restrictive to allow you to strip down to the parts you only need.
The best reference manual you can find on Windows 2000 internals is "Inside Windows 2000", which is at best a pedestrian overview of the system. This is not the fault of the authors, it is the fault of the system.
It is simply pathetic compared to The Design & Implementation of the 4.4BSD Operating System, or Linux Kernel Source Commentary, or UNIX System Internals, et al. You cannot download the source to Windows 2000 and evaluate it for yourself. You cannot compile out support for everything but the core essentials. You cannot identify and understand every process running on the system. You do not have the option of replacing them with specialized alternatives.
Do not confuse this with Linux being unbreakable. That is not what I'm saying. I'm saying that in the hands of a competent person, one can achieve a far greater degree of security with Linux than they ever can with Windows. To some admins, this is not a big deal. To me, Windows is simply unacceptable.
The authors appear to be blinded to technical realities by buzzword compliance. Not too suprising given their background.
Many professionals are content with Windows, but anyone who is passionate about technology finds it reprehensible. It comes down to who you'd rather deal with. Would you rather hire a brain surgeon who was passionate about his craft or just one who simply treated it as a job?
Please explain... (Score:3, Insightful)
why the parent post got modded down as a troll. I don't find anything particularly incindiery about what the poster said. Unlike a lot of posters here on slashdot, he actually took the time to think of something unique to say rather than repeating the same tired old arguments.
You may not agree with what he said, but I think he made his points rather well. If you disagree with what the poster said, why not post a reply?
Windows fans get to moderate too (Score:1)
I bought "Inside Windows 2000" a year and a half ago, and it's a good introduction for someone completely unfamiliar with the system, but is sorely lacking for critical details. It also is very politically-correct, in terms of advocating the Microsoft way.
The icing on the cake was the shrink-wrap EULA on the enclosed CD. After having spent a lot of time working with Linux, I found it positively insulting.
Morris Worm - 1988 (Score:2)
See: http://www.wikipedia.org/wiki/Morris+Worm [wikipedia.org]
Writing secure programs... (Score:4, Informative)
Re:Other pages? (Score:1)
Morris Worm (Score:1)
Just use a Mac. Not one exploit ever ( BugTraq ) ! (Score:1, Informative)
You cannot use the unix OS X mac OS, it has already had over 30 remote exploit weaknesses that had to be pathced.
I am talking about using a comemrcial webserver progrom on Mac OS 8.x or 9.x
9.2.2 is latet Mac OS, yet NO mac OS from 8.x through 9.2.2 has ever had one remote weakness that did not involve specific user interaction to causea problem, the defaults are very secure.
In fact so secure not one mac server has ever been compromised, though at one point a 3rd party addon cgi tool was found to be buggy and could cause a problem back in 1995 I believe. I forgot its name.
I do not care for a reply to this. Therefore by definition, it is not a troll. I am sick of linux fans moderating "0" posts to -1 because they cannot handle the fact that NOT ONE REMOTE EXPLOIT FOR MAC OS exists and has ever been published or used.
And, yes, macs are fast, and cached static pages are the same speed on almsot any OS, and Webstar 4.0 is fully featured.
This 1400 page book should mention that a mac would give you 7 years of hassle free no-exploit web serving.
Macs have no filename extensions, nor heavy usage of C strings (null terminated), nor root account, nor shell, nor dangerous way to pass return addresses, and avoid intel making hacking a little more difficult, also macs require files to have a second invisible file associated with them called "resource forks" to execute and network tools typically will not create these resource forks. There are countless reasons makes have not been exploited remotely.
400+ pages! And not 1 page praising true security (Score:2, Informative)
It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.
The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.
In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac for a web server.
I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 exploits and potential exploits ) I am talking about current Mac OS 9.x and earlier.
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 process to process communication that is heavily typed and "pipe-less"
2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff 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.
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 (length prefixed) 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.
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, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
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 design of 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.
4> Stack return address positioned in safer location than some intel Osses. 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.
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.
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 or a rouge 3rd party CGI tool ages ago in 1995, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc. They few mistaken defacements recently attributed to Mac OS are actually Mac OS X (unix) events.
I think its quite amusing that there are over 200 or 300 known remote exploit 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 remote 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 most commercial airlines for there in-house security.
Hi Ellen! (Score:2)
Anyhoo, I'm sure what you say has some merit. If all you care about is security, and you've got the budget and available manpower of the US military.
From perspectives other than security an OS9 web serving solution strike me as expensive, not terribly scalable, and - from my admittedly limited experience of OS8 and 9 - possibly not all that stable either.
<cheap shot>Anyway, if it's so secure, how come you're whining that there's no section in the book for it?</cheap shot>
Ah well, maybe there just wasn't anything the authors could say that could possibly improve the security of the mighty Mac...
Why I don't like big computer books (Score:1)
Why?
Big computer books are often filled with fluff, such as large illustrations, fancy typography or sidebars that don't add much meat.
What is really worse is that it takes a lot more work for a writer to explain a complex point concisely. I imagine it also takes more works for the editors to cut down on material that doesn't really add value to the book. My experience is that the big computer books are often poorly written.
Also, I don't have enough time to read all the technical books. It simply takes less time to read a compact, well-written book than a big, verbose tome. There's also the problem of fitting a bunch of big computer books on my limited bookshelf space.
I have observed that there seem to be an awful lot of big books for windows & web programming, and Java programming. The situation seems quite a bit better for C++ programming, with such slim books as Scott Meyers' "Effective C++".
There are long books which are worthwhile, but the ones that are both big and good are covering a topic that is very broad and detailed, for example Foley, Van Dam, Feiner and Hughes' "Computer Graphics".
My wife wanted to learn to use cascading stylesheets for her web design. The bookstore had two books, a small one by O'Reilly and a much larger one that seemed to cover the same material but had lots of fancy typography and illustrations and verbose text. In the end she chose the O'Reilly book, and after using it to design a website for some friends of ours [divinemaggees.com] she said she was very glad to have gotten the O'Reilly book.
Finally, I'd like to suggest that before you purchase a new technical book, check to see if there is a review of it at the Association of C and C++ Users [accu.org] book reviews section [accu.org].
Aberdeen Group? (Score:5, Insightful)
Let's look at some previous work of theirs, reprinted here [microsoft.com]
More Aberdeen Group work (Score:2)
Re:E-Week Article on security (Score:4, Insightful)
I think that this comment by a M$'ie is the key point. If OS people sit around patting themselves on the back because of how much more secure OS is because of all those "talented eyes" that are poring over the code, then they are going to be in for a very rude awakening. All this "your software is less secure than mine" blustering just simply points out that the overwhelming majority of software that is used out there (regardless of the religious camp from which it originated) has serious security issues. The OpenBSD camp seems to be the only ones that are making a focused effort to try to shore things up in this regard, and until others (M$ and Linux) tackle the issue with the same zeal, we'll continue to have problems.