Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
News Books Media Book Reviews

Network Intrusion Detection: An Analysis Handbook 76

Posted by Hemos from the beating-the-bad-guys dept.
Thanks to D3 for reviewing Stephen Northcutt's Network Intrusion Detection: An Analysis Handbook. Recently published, this book is designed for those of you trying to keep people outside of your machines. Click below for more.
Network Intrusion Detection: An Analyst's Handbook
author Stephen Northcutt
pages 267
publisher rating 8/10
reviewer D3
ISBN
summary Any company or group that is serious about doing Intrusion Detection should read this book.
Background

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
This discussion has been archived. No new comments can be posted.

Network Intrusion Detection: An Analysis Handbook More

Network Intrusion Detection: An Analysis Handbook

Comments Filter:

  • This if offtopic, but... (Score:1)

    by Anonymous Coward
    The only sure-fire way to keep people OUT of your machine is to keep yourself from being connected in the first place.



  • cheaper at bookpool (Score:1)

    by Anonymous Coward
    i like this writer's style and approach, it's pretty good. i just finished the crypto and security book by stallings, and so... maybe this one is next (jumping ahead of the other books in the to read pile).

    oh yeah, it's cheaper at bookpool: http://www.bookpool.com/.x/ej94qos0a0/sm/073570868 1

    jnazario

  • I mean when you say there is a hole in version x.x of sendmail (e.g.), you're practically telling crackers that, "Hey! Here's the back door! Start probing the net for servers running this software! Come on down!". This kind of information should only be traded among LICENSED security consultants (yes, we need licensing) because... this is dangerous stuff.

  • IP filter works (Score:1)

    by Anonymous Coward
    I use OpenBSD's IPF (ip filter).

    What I do is deny all ICMP, SYN, IP fragments, any UDP other than my ISP's DNS from their DNS port. If you use ICQ or equivalent linux/bsd/solaris clone, then you should only allow UDP packets from their main server.

    Block any spoofed IPs (ones from the internal network that are supposedly coming in on your external interface....such as if you receive a class A IP (10.x.x.x or Class B 192.168.x.x or class C IP 192.168.0.x from your modem ppp0 or eth0 if you have a cable modem) then deny such packets as they are spoofed.

    The IP filter homepage has a list of suggested packets to ignore and allow. The best bet is to deny all and work from there. Also, if you plan on doing portscanner, make sure you do it from a non-local host else it will screw up your results (or use nmap which has added functions).
  • On top of what you said...

    Announcing security holes publicly (via bugtraq or whatever) motivates people to fix the software. Now, if you are stuck on a closed-source system, you have to wait for the company to put together a patch/update. Who knows how long that can take with some companies. Or you can use Open Source software and be assured a fix in hours, or minutes if you fix it yourself.

    This is perhaps one of the strongest arguments to use Open Source software on sensitive equipment. You are not stuck disabling a service or just hoping you aren't attacked if the service is important to your business, while waiting for the company to get together a proper fix.
  • > I mean when you say there is a hole in version x.x of sendmail (e.g.), you're practically telling crackers that, "Hey! Here's the > back door! Start probing the net for servers running this software! Come on down!". This kind of information should only be > traded among LICENSED security consultants (yes, we need licensing) because... this is dangerous stuff.

    You're not serious are you? This is nonsense and naive at best. You're not familiar with BUGTRAQ are you? BUGTRAQ is a mailing list that is a critical resource for admins all over the world. BUGTRAQ is also a full disclosure mailing list and it is open to anyone to read. Attempting to hide this information will only serve to keep it out of the hands of the people who need it. Clever crackers will find it regardless. Furthermore, open disclosure encourages the fixing of security holes. Hiding this information will lull people into a false sense of security.

    Perhaps you should spend some time reading at Security Focus [securityfocus.com] and Packet Storm [securify.com] to understand why full disclosure is a _good_ thing. You are fooling yourself if you thing licensing and attempting to hide security holes will provide any protection whatsoever.

  • I can recommend "Maximum Security: A Hacker's Guide to Protecting your Internetsite and Network" by Anonymous, published by SAMS. It's a real hacker's/cracker's eye view of network security. Concentrating on explaining techniques and software for cracking and defending against attacks. It's really heavy on catelogueing the different attacks and exploits and explaining how they work, but being (comparatively) light on the "ensuring security" side. But this is made up for by the fact that the book is full of links to RFC's, BUGTRAQ postings etc. Basically you read about a class of attacks here, then follow the links to the Web and the detailed info. This also helps stop the book from immediately becoming out of date.

    I learnt a hell of a lot. Go get it.
  • That's what I gathered from the line: 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. But it's even better to know that he uses REAL WORLD examples.. Good review.. Thanks..
  • Can't they just do mount -o remount,rw /usr (or wherever)? Or can you get R/O switches on the actual hard drive in the same way as with floppies?

    Is there a way of mounting / R/O bearing in mind that parts of /etc need to be R/W at least for root (mtab is one that springs to mind)? Can you do it with an initrd?

    axolotl
  • There appear to be a lot of errors in the firewall-seen FAQ. *ahem*
  • Listed at $25.95, but out of stock...

    Fatbrain.com has it for $39.99 (Newriders list)

    Amazon.com is $31.99

    Buybooks.com as found by
    booksearch is lowest at $24.50 and it's listed w/24-48hr shipping!


    Edges are for leadin' not bleedin'
  • Does that mean then that you should require a license to run your own site, because you need to be licensed in order to be a security consultant?

    Or does it merely mean that you can't handle security yourself on your own site, that you need to hire a licensed security consultant?

    Either way, it smacks of dictatorship.
    --
  • Heavily flawed? Would you mind enumerating a few of those "flaws"?

    I'm sorry, but a lot of newbies and experts alike have found A LOT of value with this document.

  • The Linux Administartor's Security Guide [securityportal.com] by Kurt Seinfried is a pretty expansive online reference on securing linux systems.
    As an answer to your question it has a long description on log-files, how to use them and suggested tools for automaticly checking them, but it is still mostly aimed at prevention rather then finding out how they got in in the first place.
    For a list of exploits try bugtrack or rootshell.
    The second good thing about LASG is the extensive list of references (also online) for more detailed information.
  • Yes, Northcutt points out a couple of free ones in the book. Good to see the links for these as well.
  • simply echo 1 >/proc/net../tcpv4/icmpecho_reply
    i.e. switch off the icmp echo. check linux.com for further details in the tuning section.
  • Really? And how are you going to get that control? Maybe more script kids read BUGTRAQ than sysadmins. But that's the fault of the sysadmins. Qualified sysadmins SHOULD read BUGTRAQ. If they're so unknowledgeable about security listservs like CERT, BUGTRAQ and the like, then they should look for a line of work for which they have more skills. And let's say BUGTRAQ never publishes a vulnerability anymore. Do you think that will solve the problem? Do you honestly think the bad guys aren't going to know how to break into systems anymore? Get real...
  • One would think there would be. But intrusion detection seems to be a relative newcomer to the whole security picture of network and system administration. Although I've often maintained that good system administration involves a balance of preventing attacks (using firewalls, restricting services, keeping up with patches) and detecting attacks, it seems to be a novel new concept. Only recently has it become a strong topic at SANS and USENIX as the second part to the whole. I've never felt that any system administrator should spend the time to try to prevent all break ins. You will never be as good as the best hacker out there. So it's not a question of "IF" they will break in, but when, and when that happens, how do you know? Hopefully, we will see more books like this in the future.
  • And what stops the crackers who create the exploit scripts and documentation on those same holes from publishing their stuff on the Web or even BBSs? *We* don't need licensing...system and network administrators need better education on security to understand how to keep up with the exploits, and we need to make it clear to operating system vendors that they have a responsibility to security as well. Many of the recent exploits of NT were fixed in other OSs years ago - there's no excuse for Microsoft to have made the same mistakes.
    "If you outlaw guns, only outlaws will have guns." or something like that...

    And yes, who on earth would be responsible for licensing us? Who decides who gets one and who doesn't?

  • What can you do if your bombarded by constant ping attacks?
  • actually it was more related to pinging a firewall till it goes down...then allowing easier entry.

    what can you do about that?

    (i guess ishould've phrased the original question better).
  • actually it was more related to pinging a firewall till it goes down...then allowing easier entry.

    what can you do about that?



    Seems like the easiest thing to do would be to ignore pings for 30 seconds if you recieve more than X in a given time frame.

    Kintanon
  • Ermm. I don't see how this works besides pissing a lot more people off. If the attack is strong enough it's going to saturate the line no matter where you 're-route' the traffic. Just get your ISP or their tier1 provider to filter it at their border. I've escalated DoS attack issues with sprint and uunet before and they are usually willing to install filters at their border where it is a lot harder for packet kids to do any damage.

    Yes, you are right that it does take a while for the diplomacy route though. I had to threaten sprint that I would be moving my main DS3 service over to cerf if they didn't get their act together and install the filters I asked for.
    ----------
  • While you are partially right when it comes to the case of posting to mailing lists such as bugtraq, you fail to understand that many of the posters notify the developer of the software before doing such a thing. Unfortunately, if no one puts a message on bugtraq after the problem is taken care of and there is a patch (or the developer never responds, even after a couple of months) -- then the message makes its way to bugtraq where the problem WILL get fixed.

    I hate to tell you, but bugtraq isn't the only way kids get these exploit scripts. Many are passed around on irc months and/or weeks before they make their way there. If you've ever ventured on efnet, you'll notice half the bots in a number of channels are hacked university/nasa/navy, and other boxes hacked with exploits that were cracked before and after the exploits made their way to bugtraq. If you want an example, I'll give you one. Last year there was an exploit for qualcomm pop3d that would allow anyone to remotely get root. Script kids had the exploit maybe a month before anyone knew about it, and so hacked a couple hundred boxes. Now, word of this made its way to qualcomm, and they did provide a patch. However, most people wouldn't know of the problem and have fixed it if they hadn't read about it on bugtraq.

    So how does not mailing these problems to places like bugtraq fix the problem? It doesn't. It may stop a certain group of people from doing so, but it sure as hell won't stop the people who are a real threat.

    And as for you alluding to terrorist attacks that kill people as proof that people shouldnt post to bugtraq -- that's just absurd.
    ----------
  • oh yeah, I forgot. If you're an admin at a university, you're pretty much screwed when it comes to public access boxes. No matter how much work you put into them, you're still going to have intruders. So just get proactive on auditing every so often; or just forget about it.
    ----------
  • >How much do they update realsecure?

    Pretty often, but I think RealSecure has the functionality to let you define your own intrusions, so you don't have to wait for the update.
  • Be careful depending on Tripwire. There are ways around it. Check out phrack.
  • I've been looking for a good book like this. Surely there must be some more out there like this on the market - any suggestions from anyone?
  • Also maybe a little outdated, I found that "Firewalls and Internet Security" by William R. Cheswick and Steven M. Bellovin (Addison-Wesley) is a good one on the subject.

    They describe in detail their (multi-) firewall setup, how they log intrusion events, etc.

    Their main advise is like you said: keep the firewall system to a bare minimum of services. It makes configuration and intrusion detection easier.

  • Yeah, bud. The next time I build a Linux server for one of my buddies with a cable modem who wants IP masq, I'll be sure to bring in some consultant at $120 and hour to do an "official" review of my security.

    Besides, the *only* way to really know how to secure systems is by trying to bust into them. Some of us call it White Hat Cracking, other just call it common sense. The first thing I do when I think I'm done setting up a network is to pound the hell out of it every way I know how. Generally, if I can't get in, neither can 99% of the baddies out there.

    You'll never stop the script kiddies from having access to this info -- making it illegal will only keep it out of the hands of people who need it the most - admins. Security through obscurity is BS; read Cliff Stoll's "The Cuckoo's Egg [amazon.com]" if you need an object lesson as to why.

    ----

  • The best thing I know to do (short of a counterstrike, which raises liability issues) is to block 'em at the router. It's a pain, but it's not really difficult. This is probably the problem of your upstream provider, unless you're MCI or something.

    ----

  • Comment removed based on user account deletion
  • Actually, after reading further down, I suggest people just skip that document entirely. It's heavily flawed, and it's not going to do anything but confuse newbies. (Although it may make experienced system administrators chuckle a bit.)
  • At http://www.networkice.com [networkice.com], you can buy a $40 intrusion detection system (BlackICE Defender) for Win95-WinNT that detects over 300 different intrusions (listed at http://advice.networkice.com/advice/ intrusions [networkice.com]. It also comes with a built-in firewall that's actually managed by the IDS component (i.e. somebody attacks your personal web server, then he IDS component reconfigures the firewall rules).

    The reason its sold for $40 rather than $4000 is that it runs "non-promiscuous". The personal version is just the "Sentry" version with the sniffing component removed.

    Doesn't work on Linux, though :-( But it will detect/block intrusions if the Windows box is used as a router (though that violates the license agreement, it doesn't check).

  • I guess this wasn't clear from what I wrote. The examples he uses are compiled from real world incidents. He only cleans the data in some cases to keep you from knowing which real IP address it was.
  • You may also want to check out Intrusion Detection: An Introduction to Internet Surveillance, Correlation, Trace Back, Traps, and Response by Edward Amoroso. I think it's a good introduction to the topics which covers a bunch of the theory behind this stuff.

    I've also looked at Intrusion Dection: Network Security Beyond the Firewall by Terry Escamilla, and it's not bad.

    I know I've got another book lying around somewhere, but I can't find it and don't remember who wrote it. :(

    "IT is easy to run a secure computer system. You merely have to disconnect all dial-up connections and permit only direct-wired terminals, put the machine and its terminals in a shielded room, and post a guard at the door." - F.T. Grampp and R. H. Morris.

  • Actually, I use a slightly modified version of AIDE. It has the same feature set as tripwire as well as a couple of other features. Search on freshmeat with the keyword 'tripwire' and you'll get many similar utilities.

    As well as that, I run a tty watching daemon that monitors user commands and pages me and mails a message if someone tries something especially stupid. I also have the regular userland jailed to prevent regular users from doing something stupid as well.

    Another tip for the real sysadm nazi is to mount the filesystem with system commands as read only so that idgits can't install their handy rootkit that prevents you noticing what they are doing.

    As well as that, you could also set it up to log certain breaking attempts and to automatically send mail to the set arin administrator of that ip range. That sometimes works and is satisfying when I get a reply back stating that the user doing such a thing was deleted (though you'll never get a response if it is a large ISP and doesn't care at all [see uunet dialup users and no responses for repeated spammers and breakin attempts]).
    ----------
  • Yes exactly. You have to get the packets filtered at the backbone provider though. It only makes matters worse when the DoS kiddie brings down your small ISP's (if you have one) entire network. Also note that we're talking about icmp echo-reps that come with smurf, not icmp echo's that would come with a ping attack. Why? Because it's almost impossible for someone to mount such an attack unless you only have a t1 and they have 20 shells. Now, if you're getting a genuine ping flood, you can do something about that (though it won't necessarily help much unless you pay by line traffic). Then there is the syn attack. Of course, you should already have all ports that shouldn't be available to external users closed. I'd recommend only opening privileged ports to certain ip ranges. This includes ssh, telnet, x, and other administrative ports. Anyway, the fewer ports abusive users have to attack, the better. The only useful way to stop syn attacks is to limit syns, or to drop ip addresses flooding (that is of course assuming they aren't spoofed addresses). If you're getting flooded with spoofed syn attacks, you're pretty much screwed, unless your operating system or firewall software will dynamically drop excess syn packets. The only patch I've ran into for this is for FreeBSD 3.x, and you can get it here [home.net] That text file also includes an explanation as to its use in a bugtraq message. Note that you can also limit all ICMP packets to an arbitrary number in FreeBSD with options ICMPLIMIT. Oh yeah, and if you're constantly getting flooded with syn or ICMP packets, then you've either pissed a lot of people off, or you have idiot users on IRC losing you a heck of a lot of money. So get to the root of the problem as well as preparing yourself.
    ----------
  • Realsecure is a nice complement to the system, yes. However, if you run a large network, it isn't the only thing you should be doing. How much do they update realsecure? There are sure to be many security vulnerabilities that ISS doesn't know about weeks or months before they add that support into the realsecure security scanner.

    In other words, use it as a complement to a large network with hundreds of machines not all administrated by you -- but don't think that by itself will stop all problems.
    ----------
  • The only sure-fire way to keep people OUT of your machine is to keep yourself from being connected in the first place.
    And the only surefire way to prevent pregnancy is abstinence. Yet there is a thriving contraception business. Y'see, what we really want to do is have sex, and be connected, and minimize the risk as much as possible. There's a nice wide gap between "surefire" and "please crack me cuz I'm an idiot" and that's where I want to build my house.

    And while we're at it, cutting the wire is not a surefire way, either. Several years ago, a nasty little Gollum of a burglar stole my machine and the two hundred-odd floppies that made up my software development archives. I was left with only the sadly out-of-date safety-deposit-box copies, and one box of diskettes that I had taken into another room to riffle through, as memoirs of almost three years worth of design and coding. Ah, hell, most of it was crap anyway, and as fast as PCs were changing, it was all for the best, but I didn't think so at the time.

    So, in summary, the only surefire way to keep people out of your computer is not to have one. And that sucks almost as much as not being connected. Or not having sex.

  • For those of you who are interested, there is a trial version of ISS's Real Secure [iss.net], which is a very good intrusion detection system; it's the best I have ever seen and used.

    I fully agree that IDSs work best as a part of a greater security infrastructure. This technology is the perfect complement to firewall, just as internal alarm system complements a locked door. How many people *here* would trust only a locked door to protect their computer?

    BTW: there are versions of RealSecure (agent, for sure, and I think manager to) that run on NT, Solaris, and (drum roll, please) LINUX, so check it out!
  • I highly recommend this book. I enjoyed every minute of this book and I feel that people can get a lot out of it no matter what their security knowledge is. Go read it!

  • "This kind of information should only be traded among LICENSED security consultants "

    Hey guy, I don't mean to burst your bubble but the crackers/hackers that you really should be worried about are security consultants and such. The dangerous ones are those good guys who got stepped on or just got plain bored one day. Don't worry about the script kiddies they are for the most part a harmless pain the butt.

    "(yes, we need licensing) because... this is dangerous stuff."

    Remember what crackers/hackers are really all about, knowledge and the demand for free access to information. You close that door in their face and you might as well be throwing out propoganda for a cyberspace riot.

  • Rerouting IP Traffic

    The idea that states you should get your ISP envolved is a good one. But you can also set your server up to reroute packets when your server is flooded with ip requests. Most people will reroute the traffic to a fake address in the 192.168.x.x or 10.x.x.x address ranges alotted for NAT. But I guess if your ISP refuses to help like mine did, you could reroute the traffic to their main webserver and see how long it takes them to respond to your request for help. Exactly 6 hrs and 3 DoS attacks later I was conntacted by the one of their senior network engineers. He informed that they would gladly look into the DoS matter if I would stop rerouting traffic to their site. HEHE... Diplomacy is way overrated!

    Rerouting the traffic will only do so much, even with a well designed plan for rerouting flood traffic your servers are still vulnerable to DoS. But if you reroute the traffic you will more than likely discourage those plebes who don't understand why their DoS attack wasn't effective in the first place.

  • Hmmmm, I must admit I don't see how a ping flooding question can be off topic when the subject was a network intrusion book.

    Maybe they are being VERY picky and ping flooding was considered off topic since it's not an intrusion attack but rather a DoS attack? :)

    Bah, just keep in mind that slashdot's system randomly assigns moderating rights to some users for a very limited amount of time. I guess the system is good in general, and like all systems sometimes weird people are given moderation rights (for a short while luckily). It's just frustrating for you since you are the victim, but in general it works ok.

    (and yes, my post is definitely off topic)

  • FYI: Free IDSs (Score:3)

    by Anonymous Coward on Tuesday September 28, 1999 @05:45AM (#1653885)
    There are some free (GPL) IDSs that are pretty good. If you're interested in examining the internal workings of IDSs, these might be a good place to start.

    There's one called Snort that's pretty neat at http://www.clark.net/~roesch/security.ht ml [clark.net]

    PortSentry is a port scan detector that can be found at http://www.psionic.com/abacus/portsentry [psionic.com]

    Northcutt's SHADOW project stuff is at http://www.nswc.navy.mil/ISSEC/CID/ [navy.mil]

  • Examples would make the book.. (Score:3)

    by Thomas Charron ( 1485 ) <twaffle@gmai l . com> on Tuesday September 28, 1999 @05:43AM (#1653886) Homepage
    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.

  • Re:Ping attacks? (Score:3)

    by dattaway ( 3088 ) on Tuesday September 28, 1999 @05:44AM (#1653887) Homepage Journal
    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.

  • My recent experience. (Score:3)

    by The Evil Dwarf from ( 17232 ) on Tuesday September 28, 1999 @06:09AM (#1653888)
    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)
    I had shadow passwords enabled, but they overwrote /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.

    Just goes to show that even after year of admin experience, anyone can get cracked when they do dumb things.

  • New Riders link (Score:3)

    by D3 ( 31029 ) <daviddhenningNO@SPAMgmail.com> on Tuesday September 28, 1999 @05:58AM (#1653889) Journal
    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 [newriders.com]

  • Excellent timing (Score:3)

    by Scurrilous Knave ( 66691 ) on Tuesday September 28, 1999 @05:44AM (#1653890) Homepage
    I just got cracked a couple of weeks ago, and a colleague got owned twice in close succession shortly thereafter. And neither of us knows how the intruders gained entrance, including the third time which was on a freshly-installed brandy-new system with nearly every available security upgrade in place. Two days after his second intrusion, my colleague saw a new CERT advisory that may explain how we were penetrated. But it's only a guess.

    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?

  • Intrusion Detection FAQs (Score:4)

    by RobertGraham ( 28990 ) on Tuesday September 28, 1999 @08:20AM (#1653891) Homepage
    If you are interested in this book, you might like the FAQs on my site. These documents describe intrusion detection in detail, and are really useful in "forensics", studying the evidence of the attack.

    Network IDS FAQ [robertgraham.com]
    This document explains how network intrusion detection systems works and how to use them.

    firewall-seen FAQ [robertgraham.com]
    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 [robertgraham.com]
    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.

  • Some Advice. (Score:4)

    by dennisp ( 66527 ) on Tuesday September 28, 1999 @06:35AM (#1653892)
    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.

    ----------

  • Re:Rerouting IP Traffic (Score:4)

    by terry ( 89685 ) on Tuesday September 28, 1999 @11:19AM (#1653893)
    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.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close