- Amazon Student members save an additional 10% on Textbooks with promo code TEXTBOOK10. Enter code TEXTBOOK10 at checkout. Here's how (restrictions apply)
CEH Certified Ethical Hacker All-in-One Exam Guide Hardcover – Sep 7 2011
|New from||Used from|
There is a newer edition of this item:
Special Offers and Product Promotions
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
About the Author
Matt Walker, CCNA, CCNP, MCSE, CEH, CNDA, CPTS, is the IA Training Instructor Supervisor and a Senior IA Analyst at Dynetics, Inc., in Huntsville, Alabama. An IT education professional for more than 15 years, Matt served as the Director of Network Training, the Curriculum Lead, and Senior Instructor for the local Cisco Networking Academy on Ramstein AB, Germany. After leaving the US Air Force, he served as a Network Engineer for NASA's Secure Network Systems, designing and maintaining secured data, voice, and video networking for the agency.
Inside This Book(Learn More)
What Other Items Do Customers Buy After Viewing This Item?
Top Customer Reviews
You still need search google to get some practice exams as well. you will see some exams but not introduce in this book.
overall, it's excellent for you to pass the CEH.
I used this book to review for my exam and it's really good.
I don't recommend using only this book and don't use the 2 official book from CEH to pass the exam.
Most Helpful Customer Reviews on Amazon.com (beta)
Note that I have *a lot* of InfoSec experience--including CISSP and OSCP certifications--but in my opinion, mastery of the material in this book, including the concepts covered in the end-of-chapter questions and ~ 150 sample test questions on the included MasterExam test, *should* allow you to pass the test.
The book is well-written and concise considering the breadth of material the CEHv7 covers.
I recommend this book for anyone pursuing their CEHv7 certification.
Edit: Many of the author's examples of how to use the "nc" command are clearly untested and incorrect, although he certainly is clear on the concept of what netcat is capable of. Be sure to test and experiment rather than taking the author's syntactic advice at face value.
I read this book from cover to cover. It has a lot of excellent information, however it is riddled with incorrect information. This book only provided me with (at best) 30% of what I needed to know for the CEH Exam.
Even worse, ~90% of the Labs DO NOT WORK. The labs might have worked on an old NT or XP system, but not on new technologies. If I was reviewing only the Labs, this book would be trash. NOTE: that ~80% of the CEH Exam requires you to be familiar with tools and techniques. Luckily, the CEH exam is also a few years out-dated, so this in all fairness, this book does provide some help in preparing you for the CEH Exam.
I also skimmed the Kimberly Graves book. I liked the structure of her book better, and it seemed to be a little more modern, however, the Kimberly Graves book uses terminology that ECCouncil does not. Unfortunately, even though I liked her book better, it didn't help with the Exam as much as this book.
Bottom-line: This book did help but it is not your All-In-One source for the ECCouncil CEH Exam.
I started reading, and had to stop around Chapter 5, since it was clear the authors and TE have pulled the wool over the eyes of newbies with their complete lack of truth and relevancy. This is like a scam, how so many people fell for this miserably incorrect book.
p2 - "Although authentication (using passwords, for example) is by far the most common method used to enforce confidentiality, numerous other options are available to ensure confidentiality, including options such as encryption, biometrics, and smart cards."
What doesn't make sense: Authentication can be done with something you know (password), something you have (smart card), and something you are (biometrics). Saying that Authentication is a different method than biometrics and smart cards is illogical. I know the parenthesis references passwords, but that's as you say, just an example of authentication. Biometrics IS authentication with something you are. Smart Cards are used for AUTHENTICATION, as something you have.
p15 - There were 4 original nodes on Oct 29, 1969, not 3, as the book states.
p40 - CAs do NOT create public/private key pairs, as the book claims. Here's Verisign's official policy:
NOTE: To generate a CSR, you will need to create a key pair for your server. These two items are a digital certificate key pair and cannot be separated. If you lose your public/private key file or your password and generate a new one, your SSL Certificate will no longer match. You will have to request a new SSL Certificate and may be charged.
p43 - Digital certificates from CAs are NOT encrypted, as the book claims! The way the CA is verified is through a digital signature hash, which is part of the actual certificate. If digital certificates were encrypted, there would be NO need for a digital signature. Furthermore, "digital signature could be not be verified" or "the certificate is not trusted" messages are seen in browsers. No one has ever seen a "cannot decrypt digital certificate." That's just illogical! Furthermore, you fail to mention that the browsers have the root CA certificates, which are used to verify the CA's signature. The certificate ITSELF is NOT encrypted, but rather the public key + digital signature hash on the certificate itself helps encrypt data.
p43 - student's heads should be students' heads (plural possessive)
p45 - PPTP is "widely used by VPNs"??? PPTP has been OBSOLETE for many years now due to L2TP and nowadays IPsec!
The SSL diagram on p45 is pitiful, at best. You fail to stress that the session key is encrypted with the server's public key, and then decrypted by the server's private key. From that point forward, symmetric encryption is used. Now, the client and server are using symmetric encryption, which is (literally) one million times quicker than asymmetric encryption, and the key was transmitted securely. That's the best of both worlds! SSL/TLS uses asymmetric encryption JUST for the exchange of the symmetric session key. The data going back and forth between client and server is encrypted and decrypted with the symmetric session key. Instead of that you chose to focus on finished messages with hashes??? Furthermore - They're encrypted, not hashed. Not the same thing!!
p46 - "...chosen cipher attack, where the same process is followed (statistical analysis without a plaintext version for comparisons), but it's only for portions of gained ciphertext."
A chosen-ciphertext attack (CCA) is an attack model for cryptanalysis in which the cryptanalyst gathers information, at least in part, by choosing a ciphertext and obtaining its decryption under an unknown key. In the attack, an adversary has a chance to enter one or more known ciphertexts into the system and obtain the resulting plaintexts. From these pieces of information the adversary can attempt to recover the hidden secret key used for decryption.
It seems you missed what the word "chosen" implies (You wrote that a chosen cipher attack is "without a plaintext version," when in reality, not only is there a plaintext version, it's a function of the ciphertext CHOSEN by the attacker!"
p47 - It's "John the Ripper," not "John and Ripper."
p47-48 - "Non-repudiation is the means by which a recipient can ensure the identity of the sender and that neither party can deny having sent or received the message." NR has NOTHING to do with denying a message was received, just sent.
Here's something encrypted with my private key. I want you to decrypt it with my public key. Wait you didn't receive it???? You must have, since I sent it, haha.
p48 - It's SHA-2, not SHA2. You have it correct earlier in the book, and you even wrote SHA-1 (with the dash in the same paragraph).
Oh yeah, in the Acknowledgements, you call Technical Editor Brad Horton "one of the best." Based on the above, that's clearly a mistake too.
Should I even continue to Chapter 3?
Out of morbid curiosity, I kept reading. More of the same illogical, incorrect, and mistaken information:
p62 - DNS stands for Domain Name System, NOT Domain Name Service
p66 - "..a choice between regular and unleaded gas" Huh? regular gas is unleaded gas!
p69 - output messed up
First read this from p87. By itself, there's nothing wrong with it:
p87 - "As a matter of fact, many administrators will disable ping responses on many network systems and devices, and will configure firewalls to block them."
But now read this from p88:
p88 - "Pay particular attention to Type 3 messages and the associated code, especially Code 13, which lets you know a poorly configured firewall is preventing the delivery of ICMP packets."
So on p87, it's a good thing that administrators do, and on p88, it's a stupid thing that administrators do.
p91 - If UDP is used, the layer 4 PDU is called datagram, not segment. Segment is specifically a term for TCP.
p91 - FTP datagram - Wrong. FTP uses TCP, so it would be a segment.
p93 - No netstat????
p94 - "...the sender can simple fire as many segments as it wants..." No! If UDP is the protocol, it's NOT called a segment. That's just TCP.
p95 - "UDP, as you can tell from the segment structure...." For someone who stressed networking fundamentals at the beginning of this book, continuously calling UDP a segment is really embarrassing.
p104 - "If you'd like to try a different protocol number, it follows the -pT switch." Wrong. Port numbers go after the -pT switch, NOT protocol numbers (TCP = 6, for example).
p109 - "The SAM database holds (in encrypted format, of course) all the local passwords" Wrong! It holds a hash of the passwords, which is not the same as encrypted, since hashes are one-way. p116 has this mistake too. Encryption is NOT the same as hashing.
p110 - TCP packets should be TCP segments. It's IP packets. Packets are the Layer 3 PDU.
p125 - In 1998 the TOS field in an IP packet was renamed DSCP and completely changed!!! Way to keep up!
p126 - "...if the IP address of the packet being sent is not inside the same subnet, the router will usually respond with its MAC address. Why? Because the router knows it will be the one to forward the packet along the way."
WRONG WRONG WRONG WRONG WRONG. This shows a real lack of any networking knowledge!!!!
The router will respond because the ARP Request is asking "Will the person will this IP address (the router's in this case) please send me your MAC address. That's why! The host knows to ask that IP address for its corresponding MAC address because the host routing table tells it so. The router has no idea what the destination network is when the ARP request comes in! The ARP just says "I need the MAC address that corresponds to this IP address."
p128 - Most NICs have, or will accept, drivers that support promiscuous mode.... WinPcap is an example.... and is used by a lot of sniffers on Windows machine NICs." OH MY GOSH. WHAT PLANET ARE YOU ON? Most NICs can NOT do promiscuous sniffing through Windows. Wireshark has tons and tons of info on this on their website! There are drivers close to $1000 that you can buy to allow this, but it's much easier to just run Backtrack and put your NIC into Monitor Mode.
p129 - CSMA/CD is disabled when the switch and host NIC run in full duplex mode, since collisions are completely eliminated. Or did you miss that too?
p130 - "turn off promiscuous mode - you'll catch more frames this way...." First of all, most of the time when you put a check in that box it DOESN'T do anything (see above). Secondly, you think that if you're sniffing everything and anything you'll get LESS results than if you're sniffing just your traffic???? Whoa.
p145 - The RFC 1918 private class C range is 192.168.0-255.0, Mr Editor. You did correctly identify Class B's range as 172.16-31.0.0, so why not Class C as well?
P177 - Randomly skimming ahead (lots more mistakes between p145 and p177), I came across this gem:
"Red Hat is one of the better known and most prevalent Linux distros."
Guess you "experts" missed this:
Red Hat Linux, assembled by the company Red Hat, was a popular Linux based operating system until its discontinuation in 2004.
Red Hat is a COMPANY. Red Hat Linux (which was referenced by the book) was discontinued in 2004. Red Hat discontinued the Red Hat Linux line in favor of Red Hat Enterprise Linux (RHEL) for enterprise environments. Red Hat ENTERPRISE Linux is a non-free version, which hardly qualifies as a "better known and prevalent distros," in the context of what the author was talking about (Ubuntu and other free ones).
That's it, I can't read anymore....
Look for similar items by category
- Books > Business & Investing > Industries & Professions > Accounting > Auditing
- Books > Computers & Technology > Certification Central
- Books > Computers & Technology > Hardware > Internet & Networking
- Books > Computers & Technology > History & Culture > Privacy
- Books > Computers & Technology > History & Culture > Security
- Books > Computers & Technology > Internet & Social Media > Hacking
- Books > Computers & Technology > Networking & Cloud Computing > Internet, Groupware, & Telecommunications
- Books > Computers & Technology > Networking & Cloud Computing > Network Security
- Books > Computers & Technology > Networking & Cloud Computing > Networks, Protocols & APIs
- Books > Computers & Technology > Programming > Algorithms > Cryptography
- Books > Computers & Technology > Security & Encryption
- Books > Professional & Technical > Accounting & Finance > Industries & Professions > Accounting > Auditing
- Books > Textbooks > Business & Finance
- Books > Textbooks > Computer Science & Information Systems > Networking