From owner-freebsd-security Mon Aug 10 17:01:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24335 for freebsd-security-outgoing; Mon, 10 Aug 1998 17:01:06 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from leaf.lumiere.net (leaf.lumiere.net [207.218.152.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24308 for ; Mon, 10 Aug 1998 17:00:53 -0700 (PDT) (envelope-from j@leaf.lumiere.net) Received: (from j@localhost) by leaf.lumiere.net (8.9.1/8.9.1) id RAA08232; Mon, 10 Aug 1998 17:00:35 -0700 (PDT) Date: Mon, 10 Aug 1998 17:00:35 -0700 (PDT) From: Jesse To: freebsd-security@FreeBSD.ORG Subject: ipfw log limits by connection vs. rule Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was wondering if anyone knew/came up with some way of setting an ipfw log limit that tracked by unique connection instead of by the ipfw rule. That's probably not very clear, so I'll give an example of what I mean. Currently, if I have the rule 55000 deny log tcp from any to any setup and my ipfw log limit is 50, then if stranger.someplace.com sends 50 packets to fbsd.mydomain.comport 23, I'll hit that log limit. Then he can portscan all my other ports, without being logged. Also, if stranger2.somewhere.org comes along, nothing from him will be logged (under the same rule). I'd like to make it so that after 10 packets or so, connections from stranger.someplace.com to my port 23 are no longer logged, however packets to different ports, or from different hosts are logged. That way, instead of just seeing my counter increase, I can still keep track of what kind of activity is going on without being spammed by a single person. Keep in mind, this setup might not work on extremely active servers, but it'd be nice in many smaller situations. Thanks, :) --- Jesse http://www.lumiere.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message