Re: ipchains DENY question
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
Reply to: