pf problem / maybe bug in parser
hi as an result of missconfiguration i found a line with just an pass. why did not detect the pfctl syntax parser a single lonely pass ? is this commando first valid if they have options , parameter like on interface from a to b ? in my mind the parser have to bring at least a warning it kills all block rule what you have. is this an bug ? a missing feature ? holger
Re: pf problem / maybe bug in parser
On 2009-07-17, Holger Glaess gla...@glaessixs.de wrote: hi as an result of missconfiguration i found a line with just an pass. why did not detect the pfctl syntax parser a single lonely pass ? is this commando first valid if they have options , parameter like on interface from a to b ? in my mind the parser have to bring at least a warning it kills all block rule what you have. is this an bug ? a missing feature ? this is totally valid syntax, we even use it in the default pf.conf.
Re: pf problem / maybe bug in parser
On Fri, Jul 17, 2009 at 09:59:51AM +0200, Holger Glaess wrote: hi as an result of missconfiguration i found a line with just an pass. why did not detect the pfctl syntax parser a single lonely pass ? is this commando first valid if they have options , parameter like on interface from a to b ? in my mind the parser have to bring at least a warning it kills all block rule what you have. is this an bug ? a missing feature ? holger Ehh, please describe your problem better. Show the pf.conf. What did you expect? What happened? Why might this be a bug? Compare what's happening with the documentation. It might just be a misunderstanding on your side. -Otto
Re: pf problem / maybe bug in parser
On Fri, Jul 17, 2009 at 09:59:51AM +0200, Holger Glaess wrote: | hi | | as an result of missconfiguration i found a line | with just an pass. | | why did not detect the pfctl syntax parser a single lonely pass ? | | is this commando first valid if they have options , parameter like | on interface from a to b ? Not quite sure what you are complaining about, but a single line with 'pass' is perfectly valid syntax. It's in a lot of my rulesets, the default ruleset has it too. Of course, I have it as the first rule so later rules can override it with more specific parameters (also in the default ruleset, see the 'block in on ! lo0 proto tcp to port 6000:6010'-rule). | in my mind the parser have to bring at least a warning it kills all | block rule what you have. Why should the parser warn you when you write valid syntax ? | is this an bug ? a missing feature ? Neither. Works as intended. Unless, of course, I misunderstood what you are complaining about. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: pf problem / maybe bug in parser
On Fri, Jul 17, 2009 at 09:59:51AM +0200, Holger Glaess wrote: hi as an result of missconfiguration i found a line with just an pass. why did not detect the pfctl syntax parser a single lonely pass ? is this commando first valid if they have options , parameter like on interface from a to b ? in my mind the parser have to bring at least a warning it kills all block rule what you have. is this an bug ? a missing feature ? holger Ehh, please describe your problem better. Show the pf.conf. What did you expect? What happened? Why might this be a bug? Compare what's happening with the documentation. It might just be a misunderstanding on your side. -Otto sorry ... for my bad ugly english i have less practice . i talk about from a line with just pass nothing else. example. pf.conf - block in on wan all block out on wan all # correct line ex. pass in on wan from any to http-server port 80 # kills block rule in/out this is the my question. pass i hope that deescribe it better ;) holger
Re: pf problem / maybe bug in parser
On Fri, Jul 17, 2009 at 10:35:03AM +0200, Holger Glaess wrote: | sorry ... for my bad ugly english i have less practice . | | | i talk about from a line with just pass nothing else. | | | example. | | pf.conf - | | | block in on wan all | block out on wan all | | # correct line ex. | pass in on wan from any to http-server port 80 | | | # kills block rule in/out this is the my question. | pass | | | i hope that deescribe it better ;) OK, so I did understand you correctly. Your ruleset is valid. This is how pf (pf.conf) is supposed to work. As I said before : works as intended. You can write very solid rulesets in pf.conf but you can also put absolute nonsense in it and it can still be valid pf syntax. Remember that, as pf.conf(5) states, last matching rule decides what action is taken. 'pass' matches all packets and the action will be to pass the traffic. Your ruleset isn't necessarily absolute nonsense, btw. When debugging my rules, I sometimes add a 'pass' as the last rule, reload, verify everything works, then move the 'pass' rule up until whatever problem I had shows up again. Helps identifying problematic rules. You wouldn't complain if you put a 'rm -f /' at the end of /etc/rc.local, now would you ? You won't get a warning for it either. Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: pf problem / maybe bug in parser
On Fri, Jul 17, 2009 at 10:35:03AM +0200, Holger Glaess wrote: | sorry ... for my bad ugly english i have less practice . | | | i talk about from a line with just pass nothing else. | | | example. | | pf.conf - | | | block in on wan all | block out on wan all | | # correct line ex. | pass in on wan from any to http-server port 80 | | | # kills block rule in/out this is the my question. | pass | | | i hope that deescribe it better ;) OK, so I did understand you correctly. Your ruleset is valid. This is how pf (pf.conf) is supposed to work. As I said before : works as intended. You can write very solid rulesets in pf.conf but you can also put absolute nonsense in it and it can still be valid pf syntax. Remember that, as pf.conf(5) states, last matching rule decides what action is taken. 'pass' matches all packets and the action will be to pass the traffic. Your ruleset isn't necessarily absolute nonsense, btw. When debugging my rules, I sometimes add a 'pass' as the last rule, reload, verify everything works, then move the 'pass' rule up until whatever problem I had shows up again. Helps identifying problematic rules. You wouldn't complain if you put a 'rm -f /' at the end of /etc/rc.local, now would you ? You won't get a warning for it either. Cheers, Paul 'WEiRD' de Weerd hi you are right but i think it is really helpful if pfctl give an warning if he found those kind of line that you can decide if this rule to want or a miss typo that have to be correct. holger
Re: pf problem / maybe bug in parser
On Fri, Jul 17, 2009 at 11:11:22AM +0200, Holger Glaess wrote: | you are right but i think it is really helpful if pfctl give an | warning if he found those kind of line that you can decide if this | rule to want or a miss typo that have to be correct. And the next guy wants a warning when you block ssh access. Then the next guy has yet other things he thinks his firewall should never allow and wants to get warned when his rules do not match that. Yet another guy wants warnings for whatever it is he doesn't want his firewall to do. What I think you want is `pfctl -vf /etc/pf.conf`. The -v will tell you what rules are loaded. Should be enough warning for you. If you can't verify your ruleset after loading it, I really think you have bigger problems than what can be solved with a warning. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: pf problem / maybe bug in parser
Holger, we should adhere to KISS principle. So, pf rulesets are fine like they are if they are working as expected, and this is our case. If you're missing some warning feature maybe you would try to write an aux app -` la lint for C- that could parse a pf.conf and look for suspect behaviour. But keep in mind, these needs are not usual between heavy users of pf, so it's unlikely it would be implemented anytime soon -never is more like it-. Regards! Dani Paul de Weerd escribis: On Fri, Jul 17, 2009 at 11:11:22AM +0200, Holger Glaess wrote: | you are right but i think it is really helpful if pfctl give an | warning if he found those kind of line that you can decide if this | rule to want or a miss typo that have to be correct. And the next guy wants a warning when you block ssh access. Then the next guy has yet other things he thinks his firewall should never allow and wants to get warned when his rules do not match that. Yet another guy wants warnings for whatever it is he doesn't want his firewall to do. What I think you want is `pfctl -vf /etc/pf.conf`. The -v will tell you what rules are loaded. Should be enough warning for you. If you can't verify your ruleset after loading it, I really think you have bigger problems than what can be solved with a warning. Paul 'WEiRD' de Weerd
Re: pf problem / maybe bug in parser
On 2009-07-17, Paul de Weerd we...@weirdnet.nl wrote:
You wouldn't complain if you put a 'rm -f /' at the end of
/etc/rc.local, now would you ? You won't get a warning for it either.
that can be fixed.
Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.22
diff -u -p -r1.22 rm.c
--- rm.c10 Jun 2008 17:14:16 - 1.22
+++ rm.c17 Jul 2009 16:18:05 -
@@ -122,9 +122,12 @@ main(int argc, char *argv[])
if (*argv) {
stdin_ok = isatty(STDIN_FILENO);
- if (rflag)
+ if (rflag) {
+ if (strcmp(*argv,/) == 0)
+ printf(oh hai, i r in ur hard driv
+ nomming ur files\n);
rm_tree(argv);
- else
+ } else
rm_file(argv);
}
it doesn't really help though; same as with printing a warning
while loading firewall rules, it's too late.
I could see some value in a pflint tool, but really you should
aim for rulesets simple enough to understand by reading through
them..
Re: pf problem / maybe bug in parser
You wouldn't complain if you put a 'rm -f /' at the end of
/etc/rc.local, now would you ? You won't get a warning for it either.
that can be fixed.
Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.22
diff -u -p -r1.22 rm.c
--- rm.c 10 Jun 2008 17:14:16 - 1.22
+++ rm.c 17 Jul 2009 16:18:05 -
@@ -122,9 +122,12 @@ main(int argc, char *argv[])
if (*argv) {
stdin_ok = isatty(STDIN_FILENO);
- if (rflag)
+ if (rflag) {
+ if (strcmp(*argv,/) == 0)
+ printf(oh hai, i r in ur hard driv
+ nomming ur files\n);
I think you should append ``. Srsly'' if -f is given.
Miod
