Re: PF Tagging
* andy a...@brandwatch.com [2014-09-02 21:12]: Hoping this is a pretty dumb question and someone can just shoot me down with an instant answer but is there any reason why I can't compare against multiple tags? because list expansion for that case is not implemented in the parser. not hard to do at all... -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: PF Tagging
On Tue, 02 Sep 2014 18:33:02 -0300, Giancarlo Razzolini
grazzol...@gmail.com wrote:
On 02-09-2014 17:12, andy wrote:
So why does;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
NOT expand out to;
pass out quick on $if_ext tagged T_LAN keep state
pass out quick on $if_ext tagged T_DMZ keep state
I didn't tested. But if I recall correctly, that rule will expand
exactly as you want them to. But I disagree with you. I think you should
separate the rules for the internal network from the dmz. Even if they
are physically on the same interface (vlan), they should be on separate
rules. You could even use separate anchors with a file for the internal
net and another for the dmz. There is a point when too much
simplification starts getting into the way of doing things securely.
Which is what OpenBSD is all about. If you really, really want to
simplify your ruleset, you could first write it with security in mind,
then use the pf's ruleset optimizer, and then use the optimization as a
starting point.
Cheers,
The DMZ was just an example.. We can call it anything ;)
I'm just trying to ask why this doesn't work;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
It gets a PF syntax error? Why?
Thanks for your time, Andy.
Re: PF Tagging
On 03-09-2014 09:08, andy wrote:
The DMZ was just an example.. We can call it anything ;)
I'm just trying to ask why this doesn't work;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
It gets a PF syntax error? Why?
Thanks for your time, Andy.
I replied before without access to a OpenBSD machine. Now I've checked
the pf.conf man page (again). The BNF syntax for the tagged keyword
expects a string for the tag name. You can't use a list { }. That's why
you can't use that rule and pfctl will throw a syntax error. I will
check the source code latter today to see if it's even feasible to do
this. Perhaps some pf developer can weigh in.
Now, your example probably wasn't the best one. Mixing internal network
with dmz rules is not a good idea. You are prone to either blocking
legitimate packets from the internal network or you can end up allowing
things into your dmz that weren't supposed to get there.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
[demime 1.01d removed an attachment of type application/pkcs7-signature which
had a name of smime.p7s]
Re: PF Tagging
On Wed, 03 Sep 2014 09:33:24 -0300, Giancarlo Razzolini
grazzol...@gmail.com wrote:
On 03-09-2014 09:08, andy wrote:
The DMZ was just an example.. We can call it anything ;)
I'm just trying to ask why this doesn't work;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
It gets a PF syntax error? Why?
Thanks for your time, Andy.
I replied before without access to a OpenBSD machine. Now I've checked
the pf.conf man page (again). The BNF syntax for the tagged keyword
expects a string for the tag name. You can't use a list { }. That's why
you can't use that rule and pfctl will throw a syntax error. I will
check the source code latter today to see if it's even feasible to do
this. Perhaps some pf developer can weigh in.
Now, your example probably wasn't the best one. Mixing internal network
with dmz rules is not a good idea. You are prone to either blocking
legitimate packets from the internal network or you can end up allowing
things into your dmz that weren't supposed to get there.
Cheers,
No I agree it wasn't the best example, but I have *many* internal
workstation VLANs that need access to an internal-only server VLAN (not a
DMZ, have a separate VLAN for that).
If we could use a list here, it would allow for the shortening of many
rules and also as mentioned, also simplify the rules when NATing is
involved.
Hopefully the devs can see the merit of my previous example :)
Cheers, Andy.
Re: PF Tagging
On 2014-09-03, andy a...@brandwatch.com wrote:
I'm just trying to ask why this doesn't work;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
It gets a PF syntax error? Why?
It's just not implemented in the parser in pfctl, it shouldn't be
terribly hard to add..
Re: PF Tagging
On Wed, 3 Sep 2014 21:41:48 + (UTC), Stuart Henderson
s...@spacehopper.org wrote:
On 2014-09-03, andy a...@brandwatch.com wrote:
I'm just trying to ask why this doesn't work;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
It gets a PF syntax error? Why?
It's just not implemented in the parser in pfctl, it shouldn't be
terribly hard to add..
Oooo, thats an exciting possibility :)
Any opportunities for reducing PF rule sets is always great.
Re: PF Tagging
Oooo, thats an exciting possibility :) Any opportunities for reducing PF rule sets is always great. Yes, Indeed. +1 -- cat /etc/motd Thank you Indunil Jayasooriya http://www.theravadanet.net/ http://www.siyabas.lk/sinhala_how_to_install.html - Download Sinhala Fonts
Re: PF Tagging
On 02-09-2014 16:10, andy wrote:
Hi,
Hoping this is a pretty dumb question and someone can just shoot me down
with an instant answer but is there any reason why I can't compare against
multiple tags?
E.g.
pass out quick on $if_dmz tagged { T_LAN, T_ENGINEERING, T_WIFI, T_OPS }
queue (_wan_dflt,_wan_pri) set prio (1,4) keep state
I seem to only be able compare against one tag at a time which seem to be
quite limiting?
Cheers, Andy.
PS; Yes I am only just starting to get round to setting up policy based
rules for the first time as part of a big rewrite for a new much larger
office with *many* VLANs etc..
From the pf.conf man page:
tag string
Packets matching this rule will be tagged with the specified
string. The tag acts as an internal marker that can be used to
identify these packets later on. This can be used, for
example,
to provide trust between interfaces and to determine if packets
have been processed by translation rules. Tags are sticky,
meaning that the packet will be tagged even if the rule is not
the last matching rule. Further matching rules can replace the
tag with a new one but will not remove a previously applied
tag.
A packet is only ever assigned one tag at a time. Tags
take the
same macros as labels (see above).
So, as you see, your packet can only have one tag assigned at any time.
I think your best bet is to use match rules in association with the
tags. But you'll probably not be able to condense them that much (ie,
one rule per tag). In your case, I suggest you break down your pf.conf
into smaller anchors. This will save you time and make your pf rules
much more readable.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
[demime 1.01d removed an attachment of type application/pkcs7-signature which
had a name of smime.p7s]
Re: PF Tagging
2014-09-02 23:10 GMT+04:00 andy a...@brandwatch.com:
Hi,
Hoping this is a pretty dumb question and someone can just shoot me down
with an instant answer but is there any reason why I can't compare against
multiple tags?
E.g.
pass out quick on $if_dmz tagged { T_LAN, T_ENGINEERING, T_WIFI, T_OPS }
queue (_wan_dflt,_wan_pri) set prio (1,4) keep state
I seem to only be able compare against one tag at a time which seem to be
quite limiting?
Yes, only one tag maximum. This makes actual comparison in PF fast
easy: internal PF per-packet and per-rule structures both contain a
single number, reperesenting a tag. To allow multiple tags you'll need
to make size of those structures dynamic.
Cheers, Andy.
PS; Yes I am only just starting to get round to setting up policy based
rules for the first time as part of a big rewrite for a new much larger
office with *many* VLANs etc..
You'll probably want to play more with match rules.
--
WBR,
Vadim Zhukov
Re: PF Tagging
On Tue, 02 Sep 2014 16:28:27 -0300, Giancarlo Razzolini
grazzol...@gmail.com wrote:
On 02-09-2014 16:10, andy wrote:
Hi,
Hoping this is a pretty dumb question and someone can just shoot me
down
with an instant answer but is there any reason why I can't compare
against
multiple tags?
E.g.
pass out quick on $if_dmz tagged { T_LAN, T_ENGINEERING, T_WIFI, T_OPS
}
queue (_wan_dflt,_wan_pri) set prio (1,4) keep state
I seem to only be able compare against one tag at a time which seem to
be
quite limiting?
Cheers, Andy.
PS; Yes I am only just starting to get round to setting up policy based
rules for the first time as part of a big rewrite for a new much larger
office with *many* VLANs etc..
From the pf.conf man page:
tag string
Packets matching this rule will be tagged with the
specified
string. The tag acts as an internal marker that can be
used
to
identify these packets later on. This can be used, for
example,
to provide trust between interfaces and to determine if
packets
have been processed by translation rules. Tags are
sticky,
meaning that the packet will be tagged even if the rule is
not
the last matching rule. Further matching rules can replace
the
tag with a new one but will not remove a previously applied
tag.
A packet is only ever assigned one tag at a time. Tags
take the
same macros as labels (see above).
So, as you see, your packet can only have one tag assigned at any time.
I think your best bet is to use match rules in association with the
tags. But you'll probably not be able to condense them that much (ie,
one rule per tag). In your case, I suggest you break down your pf.conf
into smaller anchors. This will save you time and make your pf rules
much more readable.
Cheers,
Hi grazzolini,
Yes I wouldn't expect to be able to apply more than one tag, I'm asking
about checking for multiple matching tags?
I.e pass out of the packet is 'tagged' with XXX or YYY or ZZZ.
Thanks, Andy.
Re: PF Tagging
On 02-09-2014 16:32, andy wrote: Yes I wouldn't expect to be able to apply more than one tag, I'm asking about checking for multiple matching tags? I.e pass out of the packet is 'tagged' with XXX or YYY or ZZZ. But that's the point. If you assign a packet with multiple tags, only the last one (or the one with the quick keyword), is the one the packet will have. You can, however, use multiple match rules and control your packet flow with multiple tags, directing the packets as they switch their tags. But you can't compare for multiple tags at once. One thing that I do before writing my pf rules is to draw the flows into a paper. That way I can plan in advance. You have another option, which I also use, that is to use a pflow(4) interface in combination with nfsen and make your OpenBSD machine act as a simple router and monitor your packets for for a week or so. That way you can effectively know how your network behave and can program your rules accordingly. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: PF Tagging
On Tue, 02 Sep 2014 16:37:38 -0300, Giancarlo Razzolini
grazzol...@gmail.com wrote:
On 02-09-2014 16:32, andy wrote:
Yes I wouldn't expect to be able to apply more than one tag, I'm asking
about checking for multiple matching tags?
I.e pass out of the packet is 'tagged' with XXX or YYY or ZZZ.
But that's the point. If you assign a packet with multiple tags, only
the last one (or the one with the quick keyword), is the one the packet
will have. You can, however, use multiple match rules and control your
packet flow with multiple tags, directing the packets as they switch
their tags. But you can't compare for multiple tags at once. One thing
that I do before writing my pf rules is to draw the flows into a paper.
That way I can plan in advance. You have another option, which I also
use, that is to use a pflow(4) interface in combination with nfsen and
make your OpenBSD machine act as a simple router and monitor your
packets for for a week or so. That way you can effectively know how your
network behave and can program your rules accordingly.
Cheers,
Hi thanks for the ideas, but maybe I'm not being very clear.
I only want or expect the packet to have one tag at a time. But I would
like to write a rule that passes packets if they have any one of the
following tags;
For example;
pass out quick on $if_ext from { $lan, $dmz } to any
expands in the compiled rule set to;
pass out quick on $if_ext from $lan to any
pass out quick on $if_ext from $dmz to any
So why does;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
NOT expand out to;
pass out quick on $if_ext tagged T_LAN keep state
pass out quick on $if_ext tagged T_DMZ keep state
This way you could do the following;
match out on $if_ext from $dmz to any nat-to $dmz_natted_ip
match out on $if_ext from $lan to any nat-to $lan_natted_ip
pass in quick on $if_dmz from { $dmz } to any tag T_DMZ keep state
pass in quick on $if_lan from { $lan } to any tag T_LAN keep state
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
This is easier and has more control and is less error prone than having to
do things like the following just to cope with NATing;
match out on $if_ext from $dmz to any nat-to $dmz_natted_ip
match out on $if_ext from $lan to any nat-to $lan_natted_ip
pass in quick on $if_dmz from { $dmz } to any
pass in quick on $if_lan from { $lan } to any
pass out quick on $if_ext from { $dmz_natted_ip, $lan_natted_ip } to any
I.e. I have to think about the NATing in the pass rules..
Thanks for your replies and time.
Cheers, Andy.
Re: PF Tagging
On 02-09-2014 17:12, andy wrote:
So why does;
pass out quick on $if_ext tagged { T_LAN, T_DMZ } keep state
NOT expand out to;
pass out quick on $if_ext tagged T_LAN keep state
pass out quick on $if_ext tagged T_DMZ keep state
I didn't tested. But if I recall correctly, that rule will expand
exactly as you want them to. But I disagree with you. I think you should
separate the rules for the internal network from the dmz. Even if they
are physically on the same interface (vlan), they should be on separate
rules. You could even use separate anchors with a file for the internal
net and another for the dmz. There is a point when too much
simplification starts getting into the way of doing things securely.
Which is what OpenBSD is all about. If you really, really want to
simplify your ruleset, you could first write it with security in mind,
then use the pf's ruleset optimizer, and then use the optimization as a
starting point.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
[demime 1.01d removed an attachment of type application/pkcs7-signature which
had a name of smime.p7s]
Re: pf tagging and matching over more than one interface ...
hi
you only tag the package to port 1194 in both case and you are allowing only
tagged packaged to ports 22, 80, 443
David
2005/11/11, Karl-Heinz Wild [EMAIL PROTECTED]:
I try to tag a connection on the wan_if and
accordingly on the tag I'll restrict the
access on an other interface like.
an example ...
pass in quick on wan_if proto tcp from nuser to port 1194 tag NORM
keep state
pass in quick on wan_if proto tcp from puser to port 1194 tag POWER
keep state
pass in quick on tun_if to port { 80, 443 } tagged NORM keep state
pass in quick on tun_if to port { 22, 80, 443 } tagged POWER keep state
...
but I don't know why. It doesn't work.
I thought that works.
I ask for advice.
Thanks
Karl-Heinz
