Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 08:51:41PM +0100, Wouter Clarie wrote: > On Mon, 30 Dec 2002, David Krause wrote: > > > Henning already has a diff like this. However, we both think that > > states should be limited to a reasonable value (5000) by default, and > > unlimited should not even be an option. > > Fine, but then "set limits states unlimited" should be removed from > src/etc/pf.conf actually I left it there as a reminder for me to commit the default limit after I'm back from holidays. well, i'm not back, but daniel already committed ;-) -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 06:37:55PM +0100, Wouter Clarie wrote: > when it was moved to parse.y from pfctl.c. At that moment the "inf" > property vanished. So there's no way to actually set it to unlimited right > now. well, there is, but why bother. these should never be set to unlimited. there will be a default limit for state table entries. (hint: 0 = unlimited) -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Firewall spotting and networks analisys with a broken CRC
On Mon, Dec 30, 2002 at 04:39:49PM +0100, Ed White wrote: > I wrote that phile 8-) > and sent an advise to Daniel, Henning and Theo. > I had no reply, however, I would like to know which solution will be > choosed: we're still discussing. thanks for the note. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 08:21:55PM +0100, Srebrenko Sehic wrote: > How about having a possiblity to define a limit in relative way? Like > 80% of free memory or something. That way, kernel would not crash and > the limits could be dynamic, depending on the current memory utilization. The current pool(9) API requires pf to set an absolute limit. If you want to work on extending that, you're welcome :) I don't have a precise formula to calculate the highest safe limit, as it depends on many factors (amount of physical memory, kernel options, etc.). But if you really need to find the highest safe value, it's not terribly complicated to find it for a given machine/kernel. Just increase the limit and fill the state table (increasing state timeouts and port scanning does the job). The panic you get in case you set the limit too high will be obvious. One rule of thumb that works on all my GENERIC machines is that you can have around 65000 state entries per 64MB of RAM. If you have 512MB of RAM, you can safely allow 50 state entries. I haven't met anyone that really wanted to support more. :) Daniel
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 08:37:28PM +0100, Wouter Clarie wrote:
>
> On a related note: the default pf.conf in the distribution, does have:
>
> #set limit { states unlimited, frags 5000 }
>
> which is not parseable if uncommented.
/usr/src/etc/pf.conf also has,
#set loginterface none
#set optimization normal
#set block-policy drop
#set require-order yes
But they _are_ parseable ;)
// haver
Re: set limit states ulimited and pf.conf
On Mon, 30 Dec 2002, David Krause wrote: > Henning already has a diff like this. However, we both think that > states should be limited to a reasonable value (5000) by default, and > unlimited should not even be an option. Fine, but then "set limits states unlimited" should be removed from src/etc/pf.conf //Wouter
Re: set limit states ulimited and pf.conf
* Wouter Clarie <[EMAIL PROTECTED]> [021230 13:35]: > I just made a little diff, you can do with it as you please ;) I don't > have any more time to spend on this today. Diff is for parse.y and > pf.conf.5 man page, at the bottom of this mail. Henning already has a diff like this. However, we both think that states should be limited to a reasonable value (5000) by default, and unlimited should not even be an option. David
Re: set limit states ulimited and pf.conf
On a related note: the default pf.conf in the distribution, does have:
#set limit { states unlimited, frags 5000 }
which is not parseable if uncommented.
//Wouter
Re: set limit states ulimited and pf.conf
On Mon, 30 Dec 2002, Srebrenko Sehic wrote: > How about having a possiblity to define a limit in relative way? Like > 80% of free memory or something. That way, kernel would not crash and > the limits could be dynamic, depending on the current memory utilization. > > I understand that this could have performance penalities (since memory > checks should be done for every new state created). > > There must be a better way to handle this, rather then hardcoding state > limits. No? I think the amount of overhead that would cause, is not really worth it... //Wouter
Re: set limit states ulimited and pf.conf
I just made a little diff, you can do with it as you please ;) I don't
have any more time to spend on this today. Diff is for parse.y and
pf.conf.5 man page, at the bottom of this mail.
Greetings,
//Wouter
On Mon, 30 Dec 2002, Daniel Hartmeier wrote:
> Yes, it's rather simple to add support for either 'inf' or 'unlimited'
> to the parser (it just has to translate to UINT_MAX).
>
> Daniel
--- src/share/man/man5/pf.conf.5.orig Mon Dec 30 20:20:16 2002
+++ src/share/man/man5/pf.conf.5Mon Dec 30 20:23:51 2002
@@ -191,11 +191,11 @@
.Pp
For example,
.Bd -literal
-set limit states 2
+set limit states unlimited
.Ed
.Pp
sets the maximum number of entries in the memory pool used by state table
-entries (generated by 'keep state' rules) to 2.
+entries (generated by 'keep state' rules) to unlimited.
.Bd -literal
set limit frags 2
.Ed
@@ -1674,7 +1674,7 @@
seconds= number
limit-list = limit [ [ "," ] limit-list ]
-limit = ( "states" | "frags" ) number
+limit = ( "states" | "frags" ) ( number | "unlimited" )
pooltype = ( "bitmask" | "random" |
"source-hash" [ ( hex-key | string-key ) ] |
--- src/sbin/pfctl/parse.y.orig Mon Dec 30 19:36:41 2002
+++ src/sbin/pfctl/parse.y Mon Dec 30 20:08:15 2002
@@ -2576,14 +2576,38 @@
| timeout_spec
;
-limit_spec : STRING number
+limit_spec : STRING STRING
{
- if (pf->opts & PF_OPT_VERBOSE)
- printf("set limit %s %u\n", $1, $2);
+ u_long ulval;
+
+ if (atoul($2, &ulval) == 0) {
+ if (ulval > UINT_MAX) {
+ yyerror("illegal limit %s %u", $1, ulval);
+ YYERROR;
+ }
+ } else {
+ if (strcmp($2, "unlimited") == 0) {
+ ulval = UINT_MAX;
+ } else {
+ yyerror("illegal limit %s %s", $1, $2);
+ YYERROR;
+ }
+ }
+
+ if (pf->opts & PF_OPT_VERBOSE) {
+ if (ulval == UINT_MAX)
+ printf("set limit %s %s\n", $1, $2);
+ else
+ printf("set limit %s %u\n", $1, (unsigned
+int)ulval);
+ }
+
if (check_rulestate(PFCTL_STATE_OPTION))
YYERROR;
- if (pfctl_set_limit(pf, $1, $2) != 0) {
- yyerror("unable to set limit %s %u", $1, $2);
+ if (pfctl_set_limit(pf, $1, (unsigned int)ulval) != 0) {
+ if (ulval == UINT_MAX)
+ yyerror("unable to set limit %s %s", $1, $2);
+ else
+ yyerror("unable to set limit %s %u", $1,
+(unsigned int)ulval);
YYERROR;
}
}
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 07:40:23PM +0100, Daniel Hartmeier wrote: > On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote: > > > That should be more flexible eh? I'll see if i can cook up a diff for > > that tonight. > > Yes, it's rather simple to add support for either 'inf' or 'unlimited' > to the parser (it just has to translate to UINT_MAX). > > But it really makes no difference whether you set the limit to a high > number or unlimited. In fact, it makes little sense to leave the limits > unlimited, as the kernel will actually crash when memory is exhausted. > So you really want to set a low enough limit in any case, and not leave > settings unlimited. We already discussed setting the state limit to 5000 > by default. You can increase it depending on your memory, but it's > rather pointless setting it (back) to unlimited. How about having a possiblity to define a limit in relative way? Like 80% of free memory or something. That way, kernel would not crash and the limits could be dynamic, depending on the current memory utilization. I understand that this could have performance penalities (since memory checks should be done for every new state created). There must be a better way to handle this, rather then hardcoding state limits. No? // haver
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote: > That should be more flexible eh? I'll see if i can cook up a diff for > that tonight. Yes, it's rather simple to add support for either 'inf' or 'unlimited' to the parser (it just has to translate to UINT_MAX). But it really makes no difference whether you set the limit to a high number or unlimited. In fact, it makes little sense to leave the limits unlimited, as the kernel will actually crash when memory is exhausted. So you really want to set a low enough limit in any case, and not leave settings unlimited. We already discussed setting the state limit to 5000 by default. You can increase it depending on your memory, but it's rather pointless setting it (back) to unlimited. Daniel
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote: > On Mon, 30 Dec 2002, Dries Schellekens wrote: > > > If you don't specify a limit for states, it will be unlimited. But if you > > choice a number, there is no way to change it back to unlimited except by > > rebooting. So there is also no way to set to limit for frags to unlimited. > > That should be more flexible eh? I'll see if i can cook up a diff for > that tonight. DIOCSETLIMIT pf(4) ioctl hook is your friend ;) // haver
Re: set limit states ulimited and pf.conf
On Mon, 30 Dec 2002, Dries Schellekens wrote: > If you don't specify a limit for states, it will be unlimited. But if you > choice a number, there is no way to change it back to unlimited except by > rebooting. So there is also no way to set to limit for frags to unlimited. That should be more flexible eh? I'll see if i can cook up a diff for that tonight. //Wouter PS. Why the hell are we speaking english when our native language is dutch? ;-)
Re: set limit states ulimited and pf.conf
On Mon, 30 Dec 2002, Wouter Clarie wrote: > > I see this syntax has been changed on June 25: > > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/pfctl.c.diff?r1=1.80&r2=1.81 > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/parse.y.diff?r1=1.106&r2=1.107 > > when it was moved to parse.y from pfctl.c. At that moment the "inf" > property vanished. So there's no way to actually set it to unlimited right > now. [snip] > Will that be changed? If you don't specify a limit for states, it will be unlimited. But if you choice a number, there is no way to change it back to unlimited except by rebooting. So there is also no way to set to limit for frags to unlimited. Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
Re: set limit states ulimited and pf.conf
I see this syntax has been changed on June 25:
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/pfctl.c.diff?r1=1.80&r2=1.81
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/parse.y.diff?r1=1.106&r2=1.107
when it was moved to parse.y from pfctl.c. At that moment the "inf"
property vanished. So there's no way to actually set it to unlimited right
now.
Log message was:
move pfctl options -t, -m, -O and -l to pf.conf. These are set using the
"set" keyword. example rulefile:
set optimization aggressive
set timeout { tcp.closing 6, tcp.opening 6 }
set limit { states 1000, frags 1000 }
set loginterface wi0
pass out all keep state label "$nr:$srcaddr:$srcport:$dstaddr:$dstport"
block in all
fries@ is working on an updated pf.conf(5)
discussed at c2k2 and on icb
ok dhartmei@, kjell@
Will that be changed?
//Wouter
On Mon, 30 Dec 2002, Srebrenko Sehic wrote:
> On Mon, Dec 30, 2002 at 05:17:12PM +0100, Dries Schellekens wrote:
>
> > So I guess the correct syntax would be 'set limit states inf'. Can you try
> > this?
>
> Doesn't work either. I get,
>
> /etc/pf.conf:15: inf is not a number
> pfctl: Syntax error in file: pf rules not loaded
>
> // haver
Re: set limit states ulimited and pf.conf
On Mon, Dec 30, 2002 at 05:17:12PM +0100, Dries Schellekens wrote: > So I guess the correct syntax would be 'set limit states inf'. Can you try > this? Doesn't work either. I get, /etc/pf.conf:15: inf is not a number pfctl: Syntax error in file: pf rules not loaded // haver
Re: set limit states ulimited and pf.conf
On Mon, 30 Dec 2002, Dries Schellekens wrote: > On Mon, 30 Dec 2002, Srebrenko Sehic wrote: > > > Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf? [snip] > The old pfctl(8) (of OpenBSD 3.1) used to say >-m modifier > Gets or sets hard limits on the memory pools used by the packet > filter. See pool(9) for an explanation of memory pools. The > modifier has the form name[=limit], where name specifies one of > the following pools and limit is either a positive integer (maxi- > mum number of pool entries) or the string "inf" (removes the lim- > it): > -m states[=limit] Maximum number of entries in the memory pool > used by state table entries (generated by > 'keep state' rules). > -m frags[=limit] Maximum number of entries in the memory pool > used for fragment caching (generated by > 'scrub' rules). > -m all Display all maxima, cannot be set. > > So I guess the correct syntax would be 'set limit states inf'. Can you try > this? That should be it, yes, but it's not really logical. I believe there is a goal that says the pfctl output should be valid pfctl input. In this case, this obviously doesn't work: [rimshot@positron][/home/rimshot]$ sudo pfctl -s memory states unlimited frags hard limit 5000 So the output shows "unlimited", but the syntax is "inf". What should be done with this? Same counts for the frags limit. //Wouter
Re: set limit states ulimited and pf.conf
On Mon, 30 Dec 2002, Srebrenko Sehic wrote:
> Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf?
>
> I get this:
>
> root@hellspawn:/root# grep states /etc/pf.conf
> set limit { states unlimited, frags 5000 }
>
> root@hellspawn:/root# grep states /usr/src/etc/pf.conf
> #set limit { states unlimited, frags 5000 }
>
> root@hellspawn:/root# pfctl -Of /etc/pf.conf
> /etc/pf.conf:15: unlimited is not a number
> pfctl: Syntax error in file: pf rules not loaded
>
> If not, what is the proper syntax? (and someone should fix
> src/etc/pf.conf)
>
> This is on -current from 2 days ago.
The old pfctl(8) (of OpenBSD 3.1) used to say
-m modifier
Gets or sets hard limits on the memory pools used by the packet
filter. See pool(9) for an explanation of memory pools. The
modifier has the form name[=limit], where name specifies one of
the following pools and limit is either a positive integer (maxi-
mum number of pool entries) or the string "inf" (removes the lim-
it):
-m states[=limit] Maximum number of entries in the memory pool
used by state table entries (generated by
'keep state' rules).
-m frags[=limit] Maximum number of entries in the memory pool
used for fragment caching (generated by
'scrub' rules).
-m all Display all maxima, cannot be set.
So I guess the correct syntax would be 'set limit states inf'. Can you try
this?
Cheers,
Dries
--
Dries Schellekens
email: [EMAIL PROTECTED]
set limit states ulimited and pf.conf
Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf?
I get this:
root@hellspawn:/root# grep states /etc/pf.conf
set limit { states unlimited, frags 5000 }
root@hellspawn:/root# grep states /usr/src/etc/pf.conf
#set limit { states unlimited, frags 5000 }
root@hellspawn:/root# pfctl -Of /etc/pf.conf
/etc/pf.conf:15: unlimited is not a number
pfctl: Syntax error in file: pf rules not loaded
If not, what is the proper syntax? (and someone should fix
src/etc/pf.conf)
This is on -current from 2 days ago.
// haver
--
Library is an arsenal of liberty, -- unknown
RE: Firewall spotting and networks analisys with a broken CRC
> Phrack 60 describes a new technique of detecting firewalls using broken > CRC. Interesting reading material. > > http://www.phrack.org/phrack/60/p60-0x0c.txt I wrote that phile 8-) and sent an advise to Daniel, Henning and Theo. I had no reply, however, I would like to know which solution will be choosed: - add a new scrub-like rule to check the checksum - check the checksum before returning (rst or icmp) - ... Ed
Firewall spotting and networks analisys with a broken CRC
Hey, Phrack 60 describes a new technique of detecting firewalls using broken CRC. Interesting reading material. http://www.phrack.org/phrack/60/p60-0x0c.txt Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
Re: crash in pf_test_udp
On Mon, Dec 30, 2002 at 12:09:05PM +0100, Daniel Hartmeier wrote: > If I'm not mistaken, the line is pf.c:2190 's->nat_rule->states++;'. > > If you have pf.c prior to 1.278, that would explain the crash, it was > fixed with 1.278 later that day (s->nat-rule could be NULL before). I figured that something like that would be the case. I no longer have the old sources to confirm this, so I'll rebuild now and hopefully all will be well. Thanks. - jolan
Re: crash in pf_test_udp
If I'm not mistaken, the line is pf.c:2190 's->nat_rule->states++;'. If you have pf.c prior to 1.278, that would explain the crash, it was fixed with 1.278 later that day (s->nat-rule could be NULL before). Daniel
Re: crash in pf_test_udp
On Mon, Dec 30, 2002 at 03:04:43AM -0500, jolan wrote: > Please let me know if any other information is needed. If you still have the same sources that you built that kernel from, could you produce the objdump output as described on http://www.benzedrine.cx/crashreport.html Alternatively, do you have the the cvs revision number of your pf.c that was compiled into hat kernel? Should be around 1.277, but there were several commits to it on Dec 19th. Daniel
ICMP4/6 codes & types
Hi, While constructing a new ruleset, I couldn't find the definitions of the keywords for icmp codes & types. I now found out that they are in src/sbin/pfctl/pfctl_parser.c, but they're not documented anywhere. Are there any plans for a pf.conf man page section with the pf-style names of those things? tia, //Wouter
dcc redirect
Im running OpenBSD 3.2-stable, with tircproxy installed from the ports tree. I have
the following in my inetd.conf for tircproxy:
127.0.0.1:7666 stream tcp nowait root /usr/local/sbin/tircproxy -MIRH -i 192.168.0.1
-m 3 -x 30099
The following redirect rule, and pass rule is in my pf.conf:
DCCPorts="{ 3><30099 }"
rdr on $IntIF proto tcp from any to any port 6667 -> 127.0.0.1 port 7666
pass in on $ExtIF inet proto tcp from any to $ExtIF port $DCCPorts flags S/SA keep
state
I still can't get dcc sends to work from internal machines. If someone has had a
similar problem, or can offer some help, it would be much appreciated.
Jon
crash in pf_test_udp
uvm_fault(0xe37834f8, 0x24f47000, 0, 3) -> e kernel: page fault trap, code=0 Stopped at _pf_test_udp+0x7ff: incl0x198(%eax) ddb> trace _pf_test_udp(e37eba7c,2,d0ac1040,d0ad3700,0) at _pf_test_udp+0x7ff _pf_test(2,d0ac1040,e73ebd1c,d023bf5a) at _pf_test+0x322 _ip_output(d0ad3700,0,d0b9cb040,0,0) at _ip_output+0xb67 _udp_output(d0ad3700,d0b9cb00,d0b9e900,0,0) at _udp_output+0x25b _udp_usrreq(d0b7d960,9,d0ad3700,d0b9e900,0) at _udp_usrreq+0x397 _sosend(d0b7d960,d0b9e900,e37ebeb8,d0ad3700,0) at _sosend+0x684 _sendit(e37ac3b8,19,e37ebf1c,0,e37ebf80) at _sendit+0x1fc _sys_sendto(e37ac3b8,e37ebf88,e37ebf80,e34b9000,0) at _sys_sendto+0x56 _syscall() at _syscall+0x279 --- syscall (number 133) --- 0x400a17f: I was listening to mp3's over nfs. The machine that the crash happened on was the server. I had another crash in pf_test_udp earlier but unfortunately I did not transcribe it. FWIW, it was a bit shorter. Kernel is: OpenBSD 3.2-current (VENASQUE) #0: Thu Dec 19 00:14:47 CST 2002 Please let me know if any other information is needed. - jolan
