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) 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) 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 -- 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). 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? 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 ; ) 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... Have Fun, all! Ben On Fri, 2002-06-28 at 18:21, Jacob Meuser wrote: > On Fri, Jun 28, 2002 at 04:34:07PM -0700, Ben Barrett wrote: > > On Fri, 2002-06-28 at 15:37, Jacob Meuser wrote: > > >..... > > > There are several apps to monitor traffic. What do you consider human > > > readable? Do you consider the output of tcpdump human readable? > > > Ethereal? > > (ha, ha) Oh, come on!! I doubt it. Anyone who *wants* to look at raw > > packet info would not be using the term "human-readable"... Yes, there > > are humans that can read 8-bit (and higher) machine code, and TCP/IP > > packets to some extent (low-bandiwdth!)... > > $ sudo file /var/log/pflog > pflog: tcpdump capture file (little-endian) - version 2.4, capture lenth 96 > > There's a new apache vulnerability? I wonder how many hits on port 80 > I got today? > > $ sudo tcpdump -nlqr /var/log/pflog port 80 | wc -l > > What is difficult to read about that? If you know a little regexp > and tcpdump, you can get about any info you want ... probably quicker > than a front-end program is going to parse, reformat and display it. > > > He did say he wanted to ssh in, so port 22 will be the only one open > > (unless he wants to run ssh on a non-standard port for fun!). > > He said no open ports ... I'm assuming he wants to ssh in from the > protected side of the firewall. > > > Ben, with the right setup, you will learn to stop bothering to check for > > port probes, since they can be disregarded... a watchful eye is worth a > > LOT though!!! > > Is there a better tool to watch interfaces than tcpdump? I've used > tcpdump on about every network service I've set up as a debugging tool. > Knowing how to use grep, sed etc are basic UNIX skills, applicable in > many, many situations. > > Many small prorgams working together ... > > -- > <[EMAIL PROTECTED]> > -- -- Ben Barrett Software & Systems Practitioner counterclaim Phone: 541.484.9235 Fax: 541.484.9193
