Slashdot Mirror
Network Intrusion Detection: An Analysis Handbook
I have been learning about real computer and network security since January of this year. Thankfully I have been working under someone who really knows his stuff and once worked with the author, Stephen Northcutt. I have attended SANS '99 in Baltimore and will be at the New Orleans conference in October. I am by no means an expert on security or cracking. However, it is one of the most interesting aspects of what I do. I feel this book will be an essential tool in my career development.
To me the field of computer network security seems like a blossoming flower. Yes, people have been hacking, cracking, and fixing systems since the dawn of computing. However, I firmly believe once the we have recovered from the Y2K hangover, security will be the big buzz. You can already see it happening in the media with the attention certain incidents have had.
So where does Northcutt's book fit in? If you are an admin charged with securing the way your company interacts with other companies, the internet, your internal employees, e-mail, etc. this book can be an excellent resource. Keep in mind that Intrusion Detection is not a starting point. It is an integrated part to the overall picture. Having cool intrusion detection at your site does little good if you don't even have a decent firewall, acceptable use policies, e-mail filters, safe CGI's on your web, and current patch levels to your systems. Yes, you will be able to know where you were cracked from but you will have still been cracked. Likewise, if you don't understand networking and protocols to an advanced admin level this book may be a bit intimidating.
A search for Network Intrusion Detection on Amazon on Monday showed me a total of 3 titles on the subject and Northcutt's was one of them. He is certainly an expert in the field, having been the lead on the Navy Shadow Intrusion Detection Team for DoD, as well as being the current Chief Information Warfare Officer for the U.S. Ballistic Missle Defense Organization.
The Book
The best advice on how to get the value out of this book comes from the opening of chapter 6 which reads "If you do not have a lot of experience with Internet Protocol (IP), here's a suggestion to get the most out of this book: read Chapters 6, 7, and 8 twice." Northcutt starts out with a review of the Mitnick attack on Tsutomu Shimomura's system. The format of using real world examples carries throughout the rest of the book. His writing style is much the same as his lectures at SANS. He draws you in to interact with the examples he has chosen. Instead of just pointing out what he wants you to see he will ask you to think about what part of a given signature is important. Then he'll ask you to go back and look again for what he feels important. I wish textbooks in college were written this way because it helped me learn.
Included with Ch. 1 is a review of TCP/IP packet structure. Chapter Two carries on with introducing signatures and filters. This clearly explains how to tell what particular attack the script kiddie used to bring down your site. The chapter on Architectural Issues is a nice overview of sensor placement, hardware, and other implementation factors. This comes off as a little light with respect to comparing and contrasting, especially with regard to choice of OS. To be fair, these generalities will probably help keep the book relevant in the ever changing world of OS/Hardware combo. The final two chapters prior to the critical 6, 7, and 8 trio, deal with important factors to consider a good IDS solution should have and a review of known commercial and government software. Unfortunately the rapid changes involved in this field prevent a complete overview of all the available products out there. My suggestion is to read Ch. 4 more closely if you are about to make a decision on an IDS. It will help you ask the right questions to get the solution which will best suit your needs.
As I alluded to above, Chs. 6 through 8 are the guts of the book. The tcpdumps give you a real insider's view of what some classic attacks look like. Again, Northcutt is very thourough in what he presents. The exploits, like the IDS solutions, are also an ever evolving series and there is no way to write a book to cover them all. The point here is to begin to educate the eyes of the analyst. Only someone who has an idea of what traffic is normal versus what smells can hope to make good decisions when it comes to sounding the alarm. As Northcutt points out, sometimes the difference is as subtle as what port is being used. He is encouraging in that you can find the signature "fingerprint" of a given attack. He even admits that there are strange patterns he's seen but has not yet solved what tool or script was used to generate them.
Chapter 9's Introduction to Hacking takes you from the target to the attacker. With data from a crack where the attacker forgot to remove the history file, you can see how quickly a box can be 'owned'. Ten gives a look into coordinated attacks while Eleven shows some of the tools of the trade. The final chapters deal with convincing management to do things the right way and gives a taste of where IDS is heading. I don't mean to downplay the importance of these chapters. Keep in mind that the best way to play with cool toys on your job is to have management backing!
Summary
Any company or group that is serious about doing Intrusion Detection should read this book. Northcutt's tongue in cheek humor keeps things from getting too heavy. His reference to the best remote NT administration tool being a car had me chuckling for a while. The information provided is very thorough. His examples are clear and informitive. The areas where I wanted more information, he provides links to help follow up. I wouldn't be surprised if crackers used this as a reference to develop ways around detection and so the cycle will continue. I should also add the book went through technical review by Tim Aldrich, M. Dodge Mumford (of NFR), Judy Novak, and Larry Paccone.
Purchase this book at Amazon.
Contents
Acknowledgments
Tell Us What You Think
Introduction
Shadow History
Shadow Friends
1. Mitnick Attack
2. Introduction to Filters and Signatures
3. Architectural Issues
4. Interoperability and Correlation
5. Network-Based Intrusion Detection Solutions
6. Detection of Exploits
7. Denial of Service
8. Intelligence Gathering Techniques
9. Introduction to Hacking
10. Coordinated Attacks
11. Additional Tools
12. Risk Management and Intrusion Detection
13. Automated and Manual Response
14. Business Case for Intrusion Detection
15. Future Directions
Index
There's one called Snort that's pretty neat at http://www.clark.net/~roesch/security.ht ml
PortSentry is a port scan detector that can be found at http://www.psionic.com/abacus/portsentry
Northcutt's SHADOW project stuff is at http://www.nswc.navy.mil/ISSEC/CID/
Using REAL WORLD examples would really, REALLY make the book. It gives something to 'link' what your trying to grasp to real world implications. I think this is something many technical books on this topic lack.
I'm going to have to check this one out.
-- I'm the root of all that's evil, but you can call me cookie..
What can you do if your bombarded by constant ping attacks?
I'm not a sysadmin, nor do I play one on TV, but if you are getting a denial of service, contact your ISP and let them look into it. If they are incompetent pushbutton droids, change to a more enlightened localy owned service that are usually staffed by college students and other smart nerds. If even that isn't an option, well, all I can say is that your ISP only knows the source as pings can be spoofed. Leave them if they don't care about your service.
Saturday a system I built at home got cracked. This was largely my fault as I had installed RedHat 5.1 (I left my other distros at the office). I was in the process of downloading 6.0 when a script kiddy came in through the inetd hole. I noticed the introsion when my system response went into the toilet. (He had started a port scanner on the class A subnet 209.0.0.0. I caught it shortly after it started) /bin/login to disable them. They also mucked up all of the system commands too. The stupid things is they didn't even touch my log files, which were in the default location as I had just finished building the system. I have a complete view of the intrusion since they didn't even delete .bash_history. Also the secure log has a complete view of the attack since it took them a couple of hours to crack the box.
I had shadow passwords enabled, but they overwrote
Just goes to show that even after year of admin experience, anyone can get cracked when they do dumb things.
Just wanted to point out that the link under Publisher says D3 but I have _no_ affiliation with New Riders publishing. Also, the proper link should be: www.newriders.com
Do really dense people warp space more than others?
While buying this book is certainly on our agenda now, we were both wondering if there was any useful information currently on line about the subject. Most of the security stuff I could find was aimed squarely at prevention rather than detection and tracking. While that's a laudable goal, once you've been cracked, it would be nice to know who did it and how.
Not that I would track the little rat weasels down and wear their hides for coats, but knowing which hole to plug first, or again, would make me sleep better at night and urinate more freely during the day. Or is it the other way 'round?
Network IDS FAQ
This document explains how network intrusion detection systems works and how to use them.
firewall-seen FAQ
This document answers the age old question "I'm seeing XXXX on my firewall, what does it mean?". It also applies to intrusion detection system, it describes today's most common attacks, why the attacker is doing them, and which ones may be false-positives.
Sniffing/wiretap FAQ
Describes how "sniffing/wiretap/eavesdropping" works, which is the technology that IDS is base upon. Also describes how to analyze packets in detail, because when you get attacked, you NEED to be able to pull out a protocol analyzer and look at the attack.
Ok, I admit, I did some cracking back when i was 15. My advice to most admins would be to actually close all services to all but those machines that actually need the service. Do you really want to give the entire world a free chance at taking over one of your systems because you wanted to open a certain service to one or two people? What you should really do, is close everything except the absolutely needed ports (httpd, imap, pop3, smtp) and watch those closely. If you absolutely need un-ip-restricted access to a network, set up one box with ssh open, with nothing else on it, then allow that ip to connect to all your other boxes running the other services.
You also have to keep up on bugtraq. However, that's not going to always help, as people have a lot of these exploits weeks and even months before someone posts the vulnerability there. So that's where intrusion detection comes in. Tripwire and other nice programs work pretty well. You should probably also do a remote syslog or immediate mailings when problems are detected. This includes users or intruders editing or modifying files they shouldn't be, contacting remote ports they shouldnt be, having a local ethernet interface on promiscuous mode, immediate pager or mailing for commands that shouldnt be executed, such as su (use the command yourself, but copy it to another file name, so if someone else uses it, you know its unauthorized).
Now, if your problem is local authorized users, then you can do many things. You can, again, set up some intrusion detection -- or even a jailed login so you can minimize the damage that they can do once logged in. That, as well as limiting how man processes and memory users can take up, just in case you're worried about fork attacks or you just dont want your users using excessive resources.
heh, anyway. Have fun.
----------
As an administrator of a couple mid sized ISP's I think your approach is not only detrimental to the entire Internet but plain childish.
Most often the souce of the packets is spoofed and therefore very hard to block while still allowing normal traffic to come through. ISPs don't mind getting involved in helping to find the source of the problem but you must realize that they aren't the problem. This is akin to getting mad at Greyhound for the derelicts they keep dropping off in your neighborhood.
Your ISP is affected by this just as much as you are. ISPs do not, and cannot, buy enough bandwidth to support everyone at full speed. If an ISP sells 10 T-1's to customers chances are the ISP will only have the equivilant of 7 or 8 T-1's of bandwidth to the Internet. It's economically impossible to not oversell bandwidth. Because of this an attack to your connection that goes across the network of your ISP is using precious bandwidth.
You need to get in contact with hte ISP and give them as much data as you can. Simply calling and saying "it don't work" or something along those lines will not get to a solution as fast as getting some details and passing them along. You also need to realize that the ISP is probably just going to figure which incoming Internet connection this is coming from and call his upstream provider giving them the same information you gave. At this point the ISP can no longer do much about it except follow-up. And if you've ever dealt with a Telco or a bigger NSP you'll know how slow and incompetent these guys can be.
Your approach of just IP forwarding the packets to the ISP is not unlike finding unwanted garbage in your lawn and just tossing it to the neighbors lawn.