your project looks nice and usefull. What i am making will utilze graphs & a sql database. I want to graph all packets droped the last-hour, today, this-week, this year.
Eventully i would like to establish traffic patterns so i can wright more abstract rules that what iptables can do. If anyone is intrested I will post here when its done. Also i figure I can use the logging in iptables, maybe with snmp, to make netflows that are aware of state, ports, and ips. jd [EMAIL PROTECTED] On Mon, 2003-03-31 at 22:38, Scott R. Godin wrote: > Jdavis wrote: > > >> > >> ($left,$right) = split(/word/, $sentence); > >> > > > > I am trying this but its not working. Im lost :) > > could someone take a look... > > > > This is the beggining of a scrip to make reports > > based on droped iptable packets > > I've done something like this with my tailfilter project. > > http://www.webdragon.net/tf/ > > >From the synopsis: > > -=- > > Tailfilter is something that started off as a perl one-liner, took on a life > of its own, and swiftly grew out of control because I couldn't stop > thinking of ways to enhance the original idea. > > Essentially, it's a logfile filter that reformats the output from the log > and 'pretty-prints' a more legible arrangement that lends itself better to > rapid and/or cursory analysis, as well as offering immediate audible > notification of new events as they occur (optional). It additionally caches > the results of DNS lookups, as well as the TCP-based services in > /etc/services to speed up the info lookups considerably. > > To use it, simply do one of the following (or similar, depending on where > you store the tailfilter script): > > tail -f /var/log/messages |tailfilter > > sudo tail -n 50 -f /var/log/messages |./tailfilter -l 40 -c --iptables > > -=- > > It works with both ipchains and iptables currently, as well as running under > anything above 5.6.0 (I haven't tried it with 5.005_03 but I don't believe > it will work, there. Anyone willing to play with it?) > > I'm still pondering ways to suppress flood symptoms in the script, such as > when a nmap comes in masked by several hundred other (bogus) IP's, but this > is a rare enough occurrance, that as long as you have the audible > notification on, you can stop/pause the script until the flood passes. A > flood from a single IP address is already cached by the existing script, > but when masked behind hundreds of other bogus non-valid IP's, a flood of > hostname lookups inevitably occurs. > > I'm also planning on replacing the external `host` lookup with perl's own, > now that I've found out how to do it properly. The only misgiving I have > about that is the notification error messages that one gets from `host` > have different qualities depending on the error, whereas I don't *think* > the internal perl way of doing it, does. Still experimenting in my (I wish) > copious spare time. > > suggestions are welcome. (as are patches :-) -- jd [EMAIL PROTECTED] Bad spellers of the world untie! "I can't tell if I have worked all my life or if I have never worked a single day of my life" Miguel de Icaza -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
