Hi,
A while ago (it's been at least two weeks now), Mike Silbersack
requested a review for:
http://www.silby.com/patches/ratelimit-enhancement-2.patch
To quote the description on his web page, this diff will:
* ICMP ECHO and TSTAMP replies are now rate-limited.
* RSTs gene
On Wed, 13 Dec 2000, Bosko Milekic wrote:
>Suppressing udp flood/scan: 212/200 pps
>Suppressing outgoing RST due to port scan: 202/200 pps
>Suppressing outgoing RST due to ACK flood: 19725/200 pps
>Suppressing ping flood: 230/200 pps
>Suppressing icmp tstam
* Richard A. Steenbergen <[EMAIL PROTECTED]> [001213 11:17] wrote:
> On Wed, 13 Dec 2000, Bosko Milekic wrote:
>
> >Suppressing udp flood/scan: 212/200 pps
> >Suppressing outgoing RST due to port scan: 202/200 pps
> >Suppressing outgoing RST due to ACK flood: 19725/200 pps
On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> I would be extremely careful with those descriptions... When you tell
> people directly that something is an attack, even if its not, there are
> enough who will jump to immediate conclusions and begin making false
> accusations. While it may
On Wed, 13 Dec 2000, Alfred Perlstein wrote:
> I think the word "possible" should be prepended to all of these messages.
>
> Now I have a weird question, I've seen the ICMP responce limit when
> getting pegged by a couple hundred hits per second on a port that isn't
> open by legimitimate connec
On Wed, 13 Dec 2000, Mike Silbersack wrote:
> > I also see no compelling reason to put ICMP Timestamp
> > in a seperate queue, but what I would recommend is seperate queues for
> > ICMP messages which would be defined as "query/response" and those which
> > would be called "error" messages. If so
On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> Is there some specific reason you need timestamp seperate? If you're
> really up for that, why not just limit each ICMP type seperately?
There's no real need for it to be separate, it just feels cleaner. I
prefer seeing the two cases have se
On Wed, 13 Dec 2000, Mike Silbersack wrote:
> On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
>
> > Is there some specific reason you need timestamp seperate? If you're
> > really up for that, why not just limit each ICMP type seperately?
>
> There's no real need for it to be separate, it ju
On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> > Hm, true. I was thinking of limiting the outgoing side, which would mean
> > ipfw comes later in the string, but I suppose that if you limit on the
> > incoming ipfw's sooner.
>
> Historically bandlim has been the process of stopping the
On Wed, 13 Dec 2000, Mike Silbersack wrote:
> On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
>
> > > Hm, true. I was thinking of limiting the outgoing side, which would mean
> > > ipfw comes later in the string, but I suppose that if you limit on the
> > > incoming ipfw's sooner.
> >
> > H
On Wed, Dec 13, 2000 at 02:42:53PM -0500, Richard A. Steenbergen wrote:
> It could just as easily be a SYN flood against a single port... or a large
> number of clients trying to connected to your crashed web server... :P Or
> it could just as easily be an ack flood against a port without a liste
On Wed, 13 Dec 2000, Bill Fumerola wrote:
> On Wed, Dec 13, 2000 at 02:42:53PM -0500, Richard A. Steenbergen wrote:
>
> > It could just as easily be a SYN flood against a single port... or a large
> > number of clients trying to connected to your crashed web server... :P Or
> > it could just as
On Wed, Dec 13, 2000 at 09:35:40PM -0500, Bosko Milekic wrote:
> > Bosko, please change the descriptions to something very generic before
> > committing them ("ratelimiting TCP RST packets: x/y pps" or something)
>
> Mike said he would do it and re-post the diff.
Excellent.
--
Bill Fume
On Dec 13, 2:42pm, "Richard A. Steenbergen" wrote:
} Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!)
} On Wed, 13 Dec 2000, Alfred Perlstein wrote:
} > Suppressing outgoing RST due to high rate of connections on an unopen
} > port (possible portsc
14 matches
Mail list logo
