On Sat, Jun 29, 2002 at 10:08:04AM -0700, Ben Barrett wrote: > I agree, it'a fabulously direct and efficient to grep the logs directly, > but one must be comfortable witht he command line (and would likely be > spending significant other time on it (the CLI)) in order to do such > things beyond repetition of examples (true, examples are how one starts)
Uhh, we're talking about UNIX-like OSes here, right? Why would one *NOT* want to be comfortable with the CLI? If I can use grep, sed, my shell and all the other wonderful *standard* tools, I can do a lot more than what I can do with snort. > but since this case pertains to a separate firewall box, I assume that > Ben Huot simply wants to "check in on it" from time to time... > Snort is a great tool that I think is better than tcpdump (sorta like a > big brother or maybe a fast-growing grandchild) -- I see some auxillary > tools in contrib there: snortreport, demarc, and idscenter... > Since he's going to be working on his windows laptop, this might be > interesting: > > http://www.snort.org/docs/writing_rules/chap2.html#tth_sEc2.5.4 > 2.5.4 Alert_smb > This plugin sends WinPopup alert messages to the NETBIOS named machines > indicated within the file specified as an argument to this output > plugin. > (this is a new feature, and snort must be compiled with the right > option) Alert for what? That the packet filter is particularly busy? This is a home firewall. He doesn't have thousands of users. > There is also a program called SnortSnarf (by a company called > SiliconDefense that doesn't seem available on the web), but I did find > (thanx google) someone's installation to look at: > http://host4.rpi.wulimasters.net/snort/ > I like this, but Snort really shines as a NIDS (network-based intrustion > detection system)... having a firewall with good packet filtering is > only PART of the "secure" feeling we're going for: Using snort also on > the (windows laptop, in this case) workstation(s) as well as on the > gateway is the way to go Most IDS literature I've read says to put the IDS on a separate machine. Why? Because the gateway is the most likely machine to get compromised. That means all your IDS info is now untrustable, and that's all the IDS is good for, to know what has already happened. -- if there is ever any vulnerbility on the > workstation, say from web browsing or an email virus, that creates an > outgoing connection, your firewall becomes pretty USELESS. This is > because for a firewall to be "usable" and not crippling-to-function, it > must allow for any outgoing connections (even if on a strange port, who > knows what network-based game or file-sharing network you might try). What? Properly designed stateless packet filters only allow *responses* back in. How does that make the packet filter useless? There're blinking lights on hubs and switches for a reason ... so you can see if there's traffic. If you're not doing something to create traffic and the lights are blinking, hello, HELLO!!! Furthermore, a packet filter can just as easily block outgoing packets as it can incoming. It does not make it "crippling-to-function" to restrict the outgoing connections. The types of problems you describe are not really software problems, they are policy problems. A firewall isn't designed to stop people from using Outlook. That's what management is for. > Using an IDS is a good idea to keep an eye on things... the workstation > can send it's snort alerts to the firewall machine (running a > host-configured snort installation) to be logged, or better yet, dumped > into a database. There are several frontends for analysis of snort > databases (I think ACID is the most popular and best-supported). > For you hardcore users out there, you ought to be thinking of your SQL > queries rather than a silly grep of a flat log file!! : ) > That's some WAY advanced correlation capabilities, woo-hoo. > Here's where I found some ACID screenshots, lookin good: > http://www.andrew.cmu.edu/~rdanyliw/snort/acid_screencaps.html > > This is cool too: > > ACID has the ability to analyze a wide variety of events which are > post-processed into its database. Tools exist for the following formats: > * using Snort (www.snort.org) > o Snort alerts > o tcpdump binary logs > * using logsnorter ( www.snort.org/downloads/logsnorter-0.2.tar.gz) > o Cisco PIX > o ipchains > o iptables > o ipfw > Cool, huh? Maybe, if I worked at a large facility and didn't trust that management or the other admins knew what they were doing, or if "trusted" users weren't really trustworthy. > In regards to leaving a port (like 22 for ssh) open to the outside: > Ben Huot will have to be his own interpretter. Do you want to be able > to check on your DSL's security status while away from home? > If so, SSH probably the best port you could leave open -- you can > forward web requests through it if need be (I sometimes tunnel a web > proxy port over ssh for an ad-hoc web VPN, it works well on broadband, > even counting windows and OS X)... but if you want to get a lot of > alerts and see just how much port-scanning and exploit-searching happens > on broadband, run apache on port 80 with nothing but your ACID > frontend... I would bet money that your apache (if up to date) install > will never ever provide any vulnerability, letting the baddies in; but > it will give you access to your logs and providing an open port 80 will > show you how bad things would be if you ran an older IIS ; ) That's, at best, sketchy advice. That's like saying, "Hey, go punch that dog. Don't worry, he hasn't been known to bite." Hello, apache-scalp.c was out before the patches, HELLO!!! > Jacob, if you didn't catch it above, try some post-processing of your > logs, after which point you can use a variety of analysis tools... Yeah, I use tcpdump and grep all the time. I'm sorry, but I think security come from diligently following known "best practices" and using known and well written software ... basically just using common sense, not the latest and greatest logger (which is only useful *AFTER* an intrusion occurs). I'd much rather spend time looking for mistakes in my implementations, or ways to harden them, or simply get a greater understanding of them than install yet another piece of software that I will also need to make sure I'm using properly (and which has a less than stellar security history and is of limited use). Security comes from doing things right. In other words, it's a constant learning practice, because the definition of right is always changing. Adding more softare only adds to the burden. -- <[EMAIL PROTECTED]>
