Network Security Assessment 92
| Network Security Assessment | |
| author | Chris McNab |
| pages | 396 |
| publisher | O'Reilly |
| rating | 8 |
| reviewer | Ben Rothke |
| ISBN | 059600611X |
| summary | To-the-point and practical book for testing your own network, an important tool in the fight to keep out malicious electronic visitors. |
With those two tests in mind, Network Security Assessment (NSA) passes with honors. The terms bulletproof or hacker-proof are not found at all. And at 355 pages in length, the book's discussion of nmap starts on page 324; a good sign indeed. NSA is written for a person who needs a thorough introduction to performing network assessments, but does not need the elaborate background that the Hacking Exposed series offers. The book's technical requirements are not that extensive; a basic understanding of security, IP networks, and generic networking is enough to understand the core concepts of the book.
The book's preface starts out with a simple fact, one that is not always obvious to many: It is never impossible for a hacker to break into a computer system, only improbable. When designing and security a network, it is the job of the security architect to maximize that level of improbability as much as possible. Anyone who makes their network even a little bit more security resilient will quickly find a drop in the number of security breaches.
The publication of Hacking Exposed a few years ago started a new era in books about network scanning. Hacking Exposed was the first popular book that detailed how to go about performing a penetration test. In a similar vein, NSA is comparable to Hacking Exposed in that it provides a framework for doing security assessments. The big difference is that NSA provides a much more structured approach to performing the assessment, whereas Hacking Exposed lacked that formal approach. Hacking Exposed also goes into more details in many areas, and its initial title has morphed into many other different titles.
This more formal approach is manifest in the books 14 chapters. The first two chapters of NSA start out with the fundamental need and requirements for performing a network security assessment, and then details the tools and methodologies required to bring that assessment to fruition.
Chapter 3 details the ins and outs of network enumeration and also shows how to use standard utilities such as whois and nmap for network enumeration. Perhaps one of the most beneficial features of the book is the selection of countermeasures that are found at the end of each chapter. These countermeasures are very useful in ensuring that any vulnerabilities are appropriately fixed.
Besides listing methods which an intruder might use to elude common security applications, the book also goes into numerous hacking tools. While some may see this as providing fuel to the fire, it is clear that the tools are readily available (and have been for years). Listing of such tools won't make hacking easier for miscreants and script kiddies; rather it provides a level playing field for systems administrators who need to defend against such hackers.
After network and host enumeration, NSA steps forward into topics such as dealing with web servers and CGI, remote access issues, and ftp and database security issues. Chapter 9 does a good job of focusing on Microsoft Windows security issues. While entire books have been written about weak Windows security protocols such as NetBIOS, SMB and CIFS, NSA does a good job encapsulating ways to keep vulnerabilities here in check. Readers are highly advised to put the Windows networks services countermeasures listed at the end of the chapter into use.
Chapters 10-12 deal with the myriad security issues with email, VPN and RPC issues. While most of the information in these chapters (and the book as a whole) has been elucidated elsewhere, there is nonetheless a lot of valuable information contained in the chapters.
Chapter 13, "Application-Level Risks," is important in that many organizations put far too much emphasis on security the perimeter and forgetting about the application. The need for more emphasis on application-level security is eloquently put by Marcus Ranum when he notes that "these days, with the kind of plug-ins that come in your typical browser, combined with all the bizarre undocumented protocols used by new Internet applications, make it highly unlikely that a firewall is doing anything more complex than a thin layer of policy atop routing. As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."
Chapter 14 closes the book with a methodology for running a network security assessment. The author notes that running an assessment requires more thought than simply running security tools in a haphazard manner.
Overall, Network Security Assessment provides a good framework for anyone who is serious about running network security scans to security his perimeter and interior networks. The book is written in a style that is readable and understandable style; while more of an introductory text, it does not treat the reader as a dummy.
When it comes to running a network security assessment, the methodology is often more important than the running of the tools. While there is nothing radically new detailed in NSA, it does provide an effective and comprehensive overview of the issues involved in only 355 pages. If you are looking for a to-the-point book that does not get bogged down with screen prints and meaningless hacker stories and myths, Network Security Assessment is a good place to start.
You can purchase Network Security Assessment from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Preface (Score:1)
Re:Preface (Score:2, Funny)
Hackerproof? (Score:5, Funny)
Re:Hackerproof? (Score:2)
BTW you might want to get the toe jam fungus thing on your foot checked out. It looked really frightning
"How to hacker-proof your server with nmap" (Score:5, Funny)
Re:"How to hacker-proof your server with nmap" (Score:2, Funny)
Nmap (Score:5, Interesting)
Re:Nmap (Score:5, Funny)
Re:Nmap (Score:1, Informative)
Posting AC for a reason
Re:Nmap (Score:3, Funny)
Re:Nmap (Score:2)
I don't care how old she is, she's just nasty. I wouldn't have her around the house anyway.
Re:Nmap (Score:1)
Proof. (Score:3, Interesting)
Re:Proof. (Score:3, Informative)
Very non-deterministic.
Re:Proof. (Score:3, Insightful)
Because we Human's are *not*. If it was written by a human, it will have 'undocumented features' whether purposely or not. Moreover though, if something is completely and utterly secure, it's also not likely to be very useful. A computer totally disconnected from the network can't be hacked from the network...but it defeats the purpose of having a network in the first place.
Re:Proof. (Score:3, Informative)
Re:Proof. (Score:2)
there is no reason why something should not be totally secure.
the only problem is making something secure AND easy AND cheap AND quick.
Re:Proof. (Score:2)
There is a direct relationship between the complexity of software, and bugs in said software.
It is not possible to make something totally secure and complex.
If I were to write a server who's whole purpose would be to, upon a TCP connection, print the date to the client, there wouldn't be much chance for a bug, and much less chance for an exploitable bug.
Now if I were to expand features on to my li
Re:Proof. (Score:2)
Right. But just for the memory, if you have say 512MiB (2^29B), that's 2^(2^37) possibilities (not counting processor state). For all practical purposes, it can be considered impossible to analyze all possibilities.
Re:Proof. (Score:2)
It is entirely possible to write proofs that programs are correct. In the Advanced Algorithms class I took, many of the homework problems were proving that short pseudocode programs were correct. (Proofs can be verified algorithmically, but that's not important the debate over whether it possible for software to not have security holes.)
You misunderstand the halting probl
Re:Proof. (Score:3, Informative)
I actually w
Re:Proof. (Score:1)
Yes, if by 'correct' you mean 'meets some definition of how it should behave'. There's no guarantee that your definition of 'correct' is actually correct.
Re:Proof. (Score:2)
Computers and software are complex (and getting more complex all the time). With complexity comes insecurity.
Re:Proof. (Score:1)
And a network connection is inherently a form of invite.
Vampires are rather crafty as well and are very adept at tricking you into inviting them in without your even knowing they're vampires. .
Re:Proof. (Score:2)
Now I am scared to death of my internet connection.
Re:Proof. (Score:2, Insightful)
Re:Proof. (Score:1)
One is that formal methods require a formal specification, and one can have a bug in a specification almost, but not quite, as easily as one can have a bug in code. And the day you security requirements change there is no reason anything you've done can be reused.
Another is that it is expensive. To be safe you need to verify the hardware, the OS, and every program (unless yo
Nothing is flawless (Score:3, Informative)
It's that simple. No matter how good the teams involved in hardware and software development, there is a virtual statistical guarantee that there is a mistake somewhere. If that mistake can be exploited over the network, you have a potentially serious vulnerability.
The best you can do is isolate your penetration risk.
Ideally you would want each network-enabled service on a distinct server. That way if there is a security risk with that service software on the platform, your penetration risk is the l
All I got to say is... (Score:5, Funny)
Re:All I got to say is... (Score:1)
TRINITY DIDN'T USE NMAP IN THE MATRIX!
The crew whose responsibility it was to shut down the power station actually breached the system. Prior to completing their mission, their ship and bodies in the "real world" were destroyed by squiddies. Trinity walked up to a breached system and ran the shut-down command.
*sigh*
Re:All I got to say is... (Score:1)
Jeez, I must have been hallucinating...
(PS. If I was using my home PC, I'd take a screenshot and prove it one way or the other)
Whole series (Score:5, Funny)
No, we have a whole series of books for that.
The Utility of Firewalls (Score:5, Insightful)
As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."
Firewalls were invented to essentially protect us from bad software engineering. Bad software engineering remains a problem. A good question is whether or not firewalls should be made more complex, or left as simple packet filters... there is simply no way for a firewall at the edge of a network to make intelligent decisions about application data flying past it.
We need fundamental advances in creating robust, secure, and self-recovering software.
Re:The Utility of Firewalls (Score:5, Informative)
Really, so then PIX fixup does nothing for you? How about Checkpoint's AI? Funny how I have lots of logs for the drops on my firewalls that are exactly because of application data triggering something the firewall doesn't like.
Re:The Utility of Firewalls (Score:5, Insightful)
Sure, firewalls can catch this sort of low-hanging fruit, but how can a firewall make a useful decision about an otherwise syntactically legal piece of data that goes past it? All sorts of stuff gets tunneled over HTTP. If the firewall knows about authorization decisions and correct behavior of all the applications behind it, that's a pretty meaty firewall, and probably very prone to subversion itself.
Re:The Utility of Firewalls (Score:3, Informative)
Also, with the speed of modern CPUs the performance hit is negligable. We have dual OC-3 pipes and our firewall doesn't break a sweat. Try a copy of Checkpoint's Secur
Re:The Utility of Firewalls (Score:5, Insightful)
After all, why do we have the problem that application-aware firewalls are trying to solve? Because we can't trust the applications to figure out whether their own incoming data is safe to eat. Can we make firewalls smarter about application data integrity than the applications are? If we can, do we want to put all that logic in a high-traffic area?
The niche where I'd recommend a layer 7 firewall is when it's unsafe to update production systems to fix a vulnerability.
Re:The Utility of Firewalls (Score:2)
I wouldn't just say "unsafe", but also when it is unfeasible. Production systems are sometimes commercial products, sometimes they are custom built but you don't have anyone who can read, understand or touch the code.
Sometimes it is a lot easier to implement and maintain a simple app-level filter that screens traffic for known-good patterns and leaves out everything else than it is to e
Re:The Utility of Firewalls (Score:2)
Re:The Utility of Firewalls (Score:1)
Re:The Utility of Firewalls (Score:2)
PIX fixups often don't work (SMTP, H.323, even Cisco's proprietary Skinny protocol for VoIP signaling). Maybe Checkpoint is better, but I doubt it.
My trouble with these "intelligent firewalls" is that they are extremely complex, sometimes even more complex than the systems that they are trying to protect. Complexity leads to configuration errors and software bugs, and ultimately to vulnerabilities.
Therefore, it seems to be bette
Re:The Utility of Firewalls (Score:2)
Re:The Utility of Firewalls (Score:2)
Perhaps the devolopment process of OpenBSD [openbsd.org] might give you a hint [openbsd.org].
Re:The Utility of Firewalls (Score:4, Informative)
There are plenty of ways for a firewall to make intelligent decisions about the application data going past it.
The first (and perhaps easiest) level is just to check that traffic conforms to known protocol specifications, as it's very often dealing with 'impossible' data that causes applications to have problems. As a simple example, simply blocking HTTP GET or POST requests with absurdly large fields can help prevent a whole range of webserver exploits.
You can't always count on the application software to properly check every field and flag to verify that the packets it's receiving conform to the protocols standards and limitations. In these cases it's very useful (and, for large or complex installations possibly much easier) to perform those checks at the firewall.
Beyond that, you really need to perform more in-depth characterization of your allowable traffic in order to intelligently characterize it, but there are numerous companies working on helping firewalls do just that.
"We need fundamental advances in creating robust, secure, and self-recovering software."
I'll agree with that, at least.
Software needs to learn how to laugh. (When people are confronted by the impossible, contradictory, or unexpected, we generally laugh and move on without crashing...)
protect us from bad software engineering (Score:2)
I belive we need much more to be protected from bad software purchasing decisions. The best-engineered software in the world can be out there, but if that's not what you buy, all of that engineering does you no good.
I have faith in the Linux kernel because I keep tabs on the lkml, and I know that these guys are concerned about doing a good job, and that there are some well-qualified people amoung them. I have faith on other Open Source p
Re:protect us from bad software engineering (Score:2)
I agree that
Security Book? (Score:4, Funny)
Style? (Score:5, Funny)
Is it written in a more grammatical style than your review?
memory scrubbing (Score:1, Interesting)
To make something "hackerproof".... (Score:2, Interesting)
Re:To make something "hackerproof".... (Score:1)
I think there is such thing as being realistically hacker-proof.
Hacks are typically caused by programs taking malicious input and doing something awe-inspiringly stupid with it. People can write secure code if they want to.
I call bullshit on hack-proofness being impossible.
Lame Criteria (Score:5, Informative)
WTF? By this heuristic, my upcoming O'Reilly book [seclists.org] on the Nmap Security Scanner [insecure.org] will be a miserable failure. No single security tool, be it Nmap, Nessus, Snort, or any of the other most popular security tools [insecure.org], is a holy grail, but don't judge a book based on what page numbers they appear on. That is almost as bad as making the title words a huge consideration. I do tend to look askance at books with "hacking" or "cyber" in the title, but give them a chance anway. It is often the publisher's marketing department, and not the authors, that have the most influence in the cover. I flipped through NSA, and found it good enough to ask O'Reilly for a copy (I haven't read it yet though).
In any case, NSA does not start its Nmap coverage on page 324. Nmap has its own subsection on page 11, and a peak at the index shows that Nmap is also discussed on pages 39, 47, 58, 69, 192, 322-324, 325-326, and 354. If the location of Nmap coverage is one of your two primary considerations in buying security books, at least check the index!
-Fyodor [insecure.org]
PS: Nmap 3.70 was just released [seclists.org] last week, with dozens of improvements.
Re:Lame Criteria (Score:2)
I've seen the aftermath of cowboy security professionals, who come into a company, run nessus for a day or two, print out the report in its entirety, grab their money and run. At the other end of the spectrum I've seen CESG CHECK certified teams spend months car
Re:Lame Criteria (Score:2)
Don't worry, he just invented it for this book review. Sounds a bit like my computer science alogrithm proofs.
Thanks for the great tool Fyodor!
a slight discrepency? (Score:2, Interesting)
Chapter 3 [...] shows how to use [...] nmap for network enumeration.
Are chapters one and two gargantuan, or is it just too late at night for me?
What about (Score:2)
unplugging?
Last I checked that was still hacker proof!
Re:What about (Score:1)
Now smashing it with a sledge hammer would make it completely hacker proof.
Hacker-proof.... (Score:2)
Really? Many black-hat hackers in prison for commiting crimes have found their cells hacker-proof. At the very least, extremely hacker-resistant.
Full Text Online (Score:3, Insightful)
http://safari.oreilly.com/059600611X [oreilly.com]
This is a great service for serious readers. (I have no connection with them other than as a subscriber.)
If the Book does indeed mention ISECOMM (Score:1, Insightful)
Otherwise, more thought and more experience has been put in the OSSTMM than any book published to date.
Security Testing, Penetration Testing, and Vulnerability Assessments should be done according to a complete plan covering more than just open ports found by nmap, but you have to have the methodology to go about it, or you are as bad as the proverbial "Script Kiddie".
my calculator is pretty hacker proof (Score:2, Funny)
Bug-free software is possible (Score:2)
It's quite possible to build very high security systems. With enough effort, you can take proof of correctness all the way down to the hardware level.
Nobody does this any more, because 1) the costs are very high, 2) you have to make the designs so brutally simple that you lose performance, and 3) everything becomes totally incompatible with Microsoft. . But go look at the list of systems approved under the old NSA Red Book criteria at the high
Apostrophes? (Score:1)
Why not discuss the placement of apostrophes?
Hacker-Proof (Score:1, Flamebait)
Oh yeah? My computer is completely hacker-proof. There's nothing you can do to break it. In fact, I insist you try. My IP address is 127.0.0.1. Go ahead and launch your worst exploits, DoS attacks, worms, or viruses against it -- I won't even notice the attack.
a good start (Score:2)
Spend, spend, spend. (Score:1, Interesting)
Bejtlich disciple (Score:1)
I think the poster just finished reading the intro to "The Tao of Network Security Monitoring" by Richard Bejtlich.
"This book strives to not repeat material found elsewhere. you will not read how to install Snort or run Nmap. I su