Richard Hector said: > I get stuck in a loop when I try to figure out what to monitor.
totally depends on what you WANT to monitor really and how much time you want to spend doing it. My home network I recently revamped everything so it is monitored like a hawk (see http://monitor.aphroland.org best viewed in 1600x1200). I don't do this because i have to or need to, I do it because I want to, keep my skills up while I look for a job. And it allows me to learn new things. Thats just the start though, my network is protected by a freebsd box with 4 NICs in it. 2 of them are in bridged mode inbetween my bridged modem and my switch. In bridged mode everything that goes into NIC 1, goes out NIC 2 and vise versa. So say NIC 1 is on the "outside"(connected to modem), and NIC 2 is on the "inside"(connected to switch). Note Bridged mode is IP-less meaning it is impossible to connect to the interfaces which process the data. That and it is transparent. the switch and modem have no clue that they are conneced to a freebsd box where the traffic passes through. So NIC 1 is on the outside thats my firewall, I drop packets there. NIC 2 is on the inside, I run snort(well, Puresecure - http://www.demarc.com) on this interface, so snort does NOT see the packets that are dropped, so I know what does and does not get through the firewall. NIC 3 is my managment NIC which connects to my internal network(behind yet another firewall which runs NAT on debian), which I can use to connect to the IDS/NIDS console to monitor events. NIC 4 is not in use at the moment. On top of that, the freebsd box runs a syslog-ng server which listens on the management interface for messages, I have my other 5-6 systems log to it, the syslog-ng daemon filters the input into various files depending on the contents. I run logrotate which runs weekly to rotate logs, and keeps archives for 6 months. On top of that I run logcheck which at the moment emails me daily on anything that could be unusual in the logs(such as my nameserver denying a query for a non authoratative zone, or kernel messages etc). on my network monitoring side I run SNIPS which is mainly an availability monitoring tool, I have it track about 50 different services. I run big brother which is mainly a system monitoring tool, tracks processes, load average, disk space etc. Then I run MRTG for long term historical data as well as tracking other things such as temperature, UPS load, and much more. It took a long time to come up with the configuration, I mostly copied what I did at my company since the implimentation there was complete. All in all probably 75-80 hours of tuning the monitoring setups over the past year. Not something that one can do in a afternoon :) (from scratch anyways). > If I'm filtering it out, I know (more or less) what it is, and it's not > getting in, so why bother logging? It can be helpful to log, but you don't have to review those logs unless something specific needs your attention. e.g. in my prev email I mentioned how my former employer activiated a ICMP monitoring tool I used to use, but long discontinued and shortly after that their network was flooding me with ICMP packets, to the point where I had 75% packet loss on my network to my ISP. A quick check of the logs showed their IP so i called em up and helped them shut it off. > If I log everything (even everything I don't block), I've got a lot of > reading to do - or I'm stuck with grepping for something I haven't > identified. exactly, It makes no sense to overload yourself with data if you cannot review it all. Its a hard balance to achieve. my former company I had dozens of servers emailing me reports and stuff day in and day out, at the end of perhaps a 2 week period I'd have 300 automated emails. Many times I had no time to review all of them. I may review 1 in 10. But if theres a problem its handy I can go back in the logs and see what may of happened, or when the problem occured. I was the main administrator for about 80-90 servers. "main" meaning that I did about 95% of the work on them. > > I'm not saying it's a bad idea; I'm just saying I don't know how to do it. > Any suggestions? see above. but it takes a lot of experimentation, to determine your thresholds for information. information overload sucks. good luck nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
