Date: Sun, 16 Sep 2001 16:17:46 +0200 (CEST) From: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: "Karsten W. Rohrbach" <karsten@rohrbach.de>, security at FreeBSD <freebsd-security@FreeBSD.ORG> Subject: Re: Dynamic Firewall/IDS System, Was: portsentry's stealth mode - works under fBSD with ipf? Message-ID: <Pine.BSF.4.21.0109161544070.457-100000@lhotse.zaraska.dhs.org> In-Reply-To: <20010915204756.A70057@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Sep 2001, D J Hawkey Jr wrote: > On Sep 16, at 01:47 AM, Karsten W. Rohrbach wrote: > > > > Krzysztof Zaraska(kzaraska@student.uci.agh.edu.pl)@2001.09.15 16:16:26 +0000: > > > On Sat, 15 Sep 2001, D J Hawkey Jr wrote: > > [...] > > > > By way of further explanation, the cron'd script analyzes the read in > > > > log entries for blocked source IPs that either hit on the box a smallish > > > > number of times, each hit within a defined frequency (port scans and DOS > > > > attempts), or hit on the box at all a larger number of times (for more > > > > general idiocies). > > > There's an add-on for snort, called Guardian that reads the alert log file > > > in tail -f style (every 1 second IIRC) and updates firewall ruleset. I'm > > > not sure if it supports ipf right now but should be easily hackable (it's > > > a Perl script). > > > > > > Personally, I'd rather use snort than portsentry since this is a more > > > flexible and powerful solution. And it can detect "stealth" port > > > scans under FreeBSD (verified personally). Basing on your description I > > > think it would suit your needs. See http://www.snort.org/ > > > > who else, besides me, would be interested in having a dynamic system for > > blocking/ratelimiting based on ids or packetfilter output and the like? > > Well. I am, obviously. Sounds interesting to me, too. > > > i am not talking perl here, rather implementing a native p2p or client > > server framework which does this, including crypted communications and > > policy based remote firewall configuration (perhaps ipfilter as > > proof-of-concept basis). it should run realtime (not cron or whatever > > exec() based scheduler) as a native event handler. it should be modular > > in design, to be able to add input and output handlers and to have a > > good choice of logging/alerting features. Sounds cool to me. Do you want to build it into firewall code or just use firewall logger output? > FreeBSD already has dummynet for rate limiting, and two firewall techno- > logies. > > The encryption stuff seems disjointed. That seems like another topic > altogether. > > > i already got lots of ideas for it, but haven't gotten around to > > implement something yet, and after a long time of being a quite passive > > member of the *bsd community, this would be an interesting project i > > would like to contribute design, ideas and code and more. > > My first post was a simple Q to see if all of portsentry's features were > available on FreeBSD (the answer appears to be "No."). > > Krzysztof snipped off the last sentence of that post, where I thought > about putting my script's logic into portsentry, or maybe even ipmon. Sorry for that. > > What I currently have is a working proof-of-concept for what I want. I > browsed the source to ipmon today, and there's ample room for me to hack > at it. Yes, I need userland. > > > tell me if you are interested in developing such a thing from scratch, > > together... > > I don't think this is necessary. It seems, to me anyway, redundant to > existing technologies. Does any OS need three firewalls in its base? Well, I don't think this project should aim towards building another packet filter, however a system gathering alerts from various sources (firewall, IDS, etc.) and reacting appropriately could be a good thing. Also, if it was modular in design and implementation then it could posibly run with many packet filters or IDS systems just by selecting appropriate "plugins". Is this what "different input/output handlers" means? > > All I want is what I've got proven, but to move it into a daemon for > something more realtime; I've got it down to 2 minute intervals via cron, > but that's not frequent enough, and draws too many resources for what > it does at that interval. > > Myself, I think I'll decline active participation in such a project. > I've got a pretty well defined criteria, and it's small. With this, my > needs will be met. I can daemonize it over a weekend. > > Besides, aren't you [basically] describing snort? I don't think this is a description of snort. Snort documentation explicitely states that it's a tool for intrusion detection only and snort itself does not have any options allowing to react to an alert, except the posibility of sending RST to tear down hostile TCP connections. I think the tool described by Karsten is rather something that could use snort as one of possible alert sensors, right? Besides, I like the idea of updating rulesets between firewalls real-time. It's been discussed on this list before in slightly different context, but did not lead to implementing anything. Sounds cool even as a purely research project. > > ...and include a short description of your skills, programming > > languages and os platform you're on, if you like. > > P/A and Systems Admin by profession. C, shell, awk, sed, m4. FreeBSD, QNX, > Linux, and a little Solaris. X11R5/6. Administration part-time, FreeBSD, Linux, C/C++, bash, a little Perl and Java. Regards, Krzysztof > > > /k > > Let me know how and where things go, though, > Dave > > -- > > It took the computing power of three C-64s to fly to the Moon. > It takes an 800Mhz P3 to run Windows XP. Something is wrong here. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109161544070.457-100000>