This is a discussion on Re: Clearing State Table within the IPFilter forums, part of the System Security and Security Related category; Darren Reed wrote: > Jeff Durand wrote: >> Below is the output on 4.1.28. In this case ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Darren Reed wrote: > Jeff Durand wrote: >> Below is the output on 4.1.28. In this case my statemax is 7000 and >> you are right, it was at the default before and it's dumping the >> active states when it hits the defined maximum. What is TCP State >> 10? Is that TIME_WAIT? My tests in 4.1.28 now eventually have the >> states clearing but only after 4 minutes. Maybe before I wasn't >> patient enough and it's possible the only trials where I let it go >> for a long time where with older versions. If it is just in >> TIME_WAIT, then is that time setable? > > It should be but it isn't. See below for a white-space crippled patch. > > >> The host is set to only keep it in TIME_WAIT for 60 seconds. Even >> so, is there a way to make the (limit X) option in ipf.conf only >> count against connections in the ESTABLISHED state or just not >> include TIME_WAIT? Otherwise, it's still not really counting X >> concurrent connections as much as X connections per TIME_WAIT >> period? In my case, we would be getting a lot of connections in >> quick succession, but I want to limit the number of connections being >> made at simultaneously. That make sense? Thanks for your help. > > The "limit" is currently there to be counted against the total number > of sessions. > It sounds like you need a shorter time-wait timeout period...but this > may have > other implications, such as more packets not matching state and > generating > more problems elsewhere... For my needs it would have to be way to short of a time to be practical. > > Out of curiosity, what would you expect a per-timeout limit to do when > the > number for that rule/state was reached? FIFO? Least used first out? My ideal would have been maybe a block return-rst, but I really wouldn't care what happened to the future connections of an abusive user. I just wouldn't want those connections to grow past X. But with IPF counting TIME_WAIT, this won't really fit my needs. Thanks very much for your time though. > > Darren > > Index: fil.c > ================================================== ================= > RCS file: /devel/CVS/IP-Filter/fil.c,v > retrieving revision 2.243.2.130 > diff -u -r2.243.2.130 fil.c > --- fil.c 29 Mar 2008 23:19:24 -0000 2.243.2.130 > +++ fil.c 9 Apr 2008 08:01:27 -0000 > @@ -6000,6 +6000,8 @@ > sizeof(fr_tcpclosed), IPFT_WRDISABLED, > NULL }, > { { &fr_tcphalfclosed }, "fr_tcphalfclosed", 1, > 0x7fffffff, > sizeof(fr_tcphalfclosed), IPFT_WRDISABLED, > NULL }, > + { { &fr_tcptimewait }, "fr_tcptimewait", 1, > 0x7fffffff, > + sizeof(fr_tcptimewait), > IPFT_WRDISABLED, NULL }, > { { &fr_udptimeout }, "fr_udptimeout", 1, > 0x7fffffff, > sizeof(fr_udptimeout), IPFT_WRDISABLED, > NULL }, > { { &fr_udpacktimeout }, "fr_udpacktimeout", 1, > 0x7fffffff, > > -- Jeffrey G. Durand, Manager of CISS Computer Infrastructure Support Services Information Technology, MultiAd jdurand@multiad.com |
![]() |
| Thread Tools | |
| Display Modes | |
|
|