- Shopping Bag ( 0 items )
Learn how to secure Windows 2000 from the hacker's perspective Optimizing security and...
Ships from: Nashua, NH
Usually ships in 1-2 business days
Ships from: Cleveland, OH
Usually ships in 1-2 business days
Ships from: Los Angeles, CA
Usually ships in 1-2 business days
Ships from: Fort Worth, TX
Usually ships in 1-2 business days
Learn how to secure Windows 2000 from the hacker's perspective Optimizing security and plugging the holes inherent in Windows 2000 networks is a daunting task and new vulnerabilities pop up every day. Break-ins,fraud,sabotage,and DoS downtime are constant realities in this target-rich environment. Hacking Exposed Windows 2000: Network Security Secrets ; Solutions will teach you,step-by-step,how to defend against the latest attacks by understanding how intruders enter and pilfer compromised networks. Renowned security experts and best-selling authors Joel Scambray and Stuart McClure provide examples of real-world hacks,from the mundane to the sophisticated,and detailed countermeasures to protect against them.
What You'll Learn:
From the best-selling co-authors of the world-renowned book, Hacking Exposed, comes Hacking Windows 2000 Exposed. You'll learn, step-by-step, how to defend against the latest attacks by understanding how intruders enter and pilfer compromised networks and weaknesses in password encryption, domain control, Web and IIS 5 communications, LM/NTLM protocols, Active Directory, NetBIOS services, and much more.
Block or Disable Everything That Is Not Explicitly Allowed We will repeat this mantra time and again in this book. With some very obscure exceptions, there are no known ways to remotely attack a system with no running services. Thus, if you block access to or disable services outright, you cannot be attacked.
This is small consolation for those services that are permitted, of course (for example, application services such as IIS necessary to run a Web application). If you need to allow access to a service, make sure you have secured it according to best practices (for example read Chapter 10 of this book to understand how to lock down IIS).
Since they are most always unique, applications themselves must be secured with good of fashioned design and implementation best practices.
Always Set a Password, Make It Complex, and Change It Often Passwords are the bane of the security world-they are the primary form of authentication for just about every product in existence, Windows 2000 included. Weak passwords are the primary way in which we defeat Windows 2000 networks in professional penetration testing engagements. Always set a password (never leave it blank!), and make sure it's not easily guessed (see Chapter 5 for some Windows 2000-specific tips). Use multifactor authentication if feasible (Windows 2000 is fairly easy to integrate with smart cards, for example).
Keep Up with Vendor Patches-Religiously! Anybody who has done software development knows that accidents happen. When a bug is discovered in a Microsoft product, however, the rush to gain fame and popularity typically results in a published exploit within 48 hours. This means you have approximately two days to apply patches from Microsoft before someone comes knocking on your door. As you will see from the severity of some of these issues described in this book, the price of not keeping up with patches is complete and utter remote system compromise (check out Chapter 10 if you need further proof).
Authorize All Access Using Least Privilege This is a concept that is the most infrequently e'by our consulting clientele, but it's the one that we exploit to the greatest effect on their networks. Authorization occurs after authentication to protect sensitive resources from access by underprivileged users. Guessing a weak password is bad enough, but things get a lot worse when we discover that the lowly user account we just compromised can mount a share containing sensitive corporate financial data. Yes, it requires a lot of elbow grease to inventory all of the resources in your IT environment and assign appropriate access control, but if you don't, you will only be as strong as your weakest authentication link-back to that one user with the lame password.
Limit Trust No system is an island, especially with Windows 2000. One of the most effecde attacks we use against Windows networks is the exploitation of an unimportant domain member computer with a weak local Administrator password. Then, by using techniques discussed in Chapter 8, we extract the credentials for a valid domain user from this computer, which allows us to gain a foothold on the entire domain infrastructure and possibly domains that trust the current one. Recognize that every trust relationship you set up, whether it be a formal Windows 2000 domain trust or simply a password stored in a batch file on a remote computer, expands the security periphery and increases your risks.
A corollary of this rule is that password reuse should be explicitly banned. We can't count the number of times we've knocked over a single Windows NT/2000 system, cracked passwords for a handful of accounts, and discovered that these credentials enable us to access just about every other system on the network (phone system switches, UNIX database servers, SNA gateways, you name it).
Be Particularly Paranoid with External Interfaces (Dial-up, Too!) The total number of potential vulnerabilities on a network can seem staggering, but you must learn to focus on those that present the most risk. These are most often related to systems that face public networks such as Web servers and so on. Front-facing systems (as we'll call them) should be held to higher standard of accountability than internal systems, because the risks that they face are greater. Remember that the public switched telephone network is a frontfacing interface as well (see Hacking Exposed, Third Edition, Chapter 9 for recommendations on dial-up security, which we will not treat in this book).
Monitoring, Logging, Auditing, and Detection Should Be Enabled This is not a book on the art of intrusion detection or forensic analysis, and we will not be covering monitoring, auditing, and logging indepth. We do make our recommendations for Windows 2000 audit settings (enable audit of Success and Failure of everything except process tracking) but will otherwise assume everyone understands the importance of such record keeping and has implemented it appropriately. Don't forget to actually review the logs you keepthere's no point in keeping them otherwise.
Plan an incident Response Capability, Business Continuity We are going to talk a lot in this book about how to avoid getting hacked. But what happens if the unthinkable occurs and you are successfully attacked? There are many critical procedures that should be followed immediately following a security incident to stem the damage, and these procedures should be laid down in advance. However, this is not a book on incident response, and we are not going to delve into those topics here. We highly recommend Incident Response by Mandia and Prosise if you want to learn the ropes of this aspect of security.
Technology Will Not Protect You from Social Attacks This book is targeted mainly at technology-driven attackssoftware exploits that require a computer and technical skills to implement. However, some of the most damaging attacks we have seen and heard of do not involve technology at all. So-called social engineering uses human-to-human trickery and misdirection to gain unauthorized access to data. This book can only protect you at the level of bits and bytes-it will not protect you from social attacks that circumvent those bits and bytes entirely. Educate yourself about common social engineering tactics (see Hacking Exposed, Third Edition, Chapter 14), and educate your organization through security policy (see next).
Develop a Security Policy, Get Management Buy-In, and Distribute Widely The classic security textbooks describe policy development as the first step in a comprehensive program of information system security. By the end of this book, you will have an excellent idea of what a Windows 2000 system security policy might look like, but there are many other elements to a corporate security policy. We strongly recommend that you consider your organization' s unique technology posture and develop at least a minimal policy before embarking on the point fixes detailed in this book. We have listed some references for good policy development at the end of this chapter, including RFCs 2196 and 2504, the Site Security Handbook and User Security Handbook, respectively; and Information Security Policies Made Easy by Charles Cresson Woods.
Also critical to the security policy development process is getting management buy-in. A policy without teeth is almost as bad as none at all.
Perform Real-World Risk Assessment Don't let paranoia disrupt business goals (and vice-versa!). Many of the specific recommendations we make in this book are fairly restrictive. That's our nature-we've seen the damage less restrictive policies can do. However, they are still just recommendations. We recognize the technical and political realities you will face in attempting to implement these recommendations. The goal of this book is to arm you with the right information to make a persuasive case for the more restrictive stance, knowing that you may not win all the arguments. Pick your battles, and win the ones that matter.
Learn Your Platforms and Applications Better than the Enemy This book is designed to convey a holistic view of Windows 2000 security, not just a "script-kiddie" checklist of configuration settings that will render you bulletproof. We hope that by the end of the book you will have a greater appreciation of the Windows 2000 security architecture, where it breaks down, and best practices to mitigate the risk when it does. We also hope these practices will prove timeless and will prepare you for whatever is coming down the pike in the next version of Windows (see Chapter 17) as well as from the hacking community....
|1||Network and System Security Basics||3|
|2||The Windows 2000 Security Architecture from the Hacker's Perspective||9|
|3||Footprinting and Scanning||37|
|10||Hacking IIS 5 and Web Applications||205|
|11||Hacking SQL Server||267|
|12||Hacking Terminal Server||309|
|13||Hacking Microsoft Internet Clients||325|
|15||Denial of Service||385|
|16||Windows 2000 Security Features and Tools||403|
|17||The Future of Windows 2000||435|
|A||Windows 2000 Security Checklist||451|