when used pfctl should log any changes to state of FW

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

when used pfctl should log any changes to state of FW

S. Donaldson
I have been working with OpenBSD since 2.6, have deployed it in many roles.
Have hacked authpf to have authpfnoip with ip functionality (there is a reason!).
So I have some experience with the OS...mostly as an implementer/admin not a dev type.

Motivation:
I am configuring a 'segregating' Openbsd based firewall that I want to
maximize the auditibility/accountability on/for.

Question/Suggestion:
So why does pfctl not appear to (I could not find a command line option - nor previous request)
 log to syslog every command (who when what exit status) that changes anything within
 the pf context such as : rules, table contents, states?

I don't want the detailed changes that may occur within pf - just establishing accountability.

Scott Donaldson

Reply | Threaded
Open this post in threaded view
|

Re: pfctl parse issue with negated protocol list: block on $int proto ! { prot1 prot2 prot3 } leads to syntax error

Stuart Henderson
On 2017/11/21 12:21, S. Donaldson wrote:

> Applies to stable:
>
>  OpenBSD 6.1 GENERIC.MP amd64  
>
> and stable
>
>   OpenBSD 6.2 GENERIC.MP amd64
>
>
> pf rules that block using the proto key work with a negation fail with a syntax error.
>
>  block on $int inet proto ! tcp

I think you'll just need two rules for that:

block on $int inet
pass on $int inet proto tcp

> and list based negations also fail
>
>  block on $int inet proto ! { tcp udp }
>
> with a syntax error.

Beware of list negations! If this was allowed it would expand to this:

block on $int inet proto ! tcp
block on $int inet proto ! udp

Which is not what you want.

It may seem to work in some cases with a list of IP addresses as the
ruleset optimizer will convert them to a table if there are enough
addresses, but this is dangerous as if you remove enough addresses it
will start to do the wrong thing.

In general avoid negation with lists.
Reply | Threaded
Open this post in threaded view
|

Re: pfctl parse issue with negated protocol list: block on $int proto ! { prot1 prot2 prot3 } leads to syntax error

S. Donaldson
Stuart,

        Thanks for the feedback. The warning about list expansion is appreciated I was aware of the downside.

        It seemed to be an error in the parser to me, but I'd have to review the grammar again. Ah yes no negation in the grammar for 'protospec' or proto-list !!!

        I've moved past simple block / allow and am trying to add 'forensic' rules that generate log data that I can perform  some low level analysis against. I have not found documentation that clearly states that a block rule such as you suggest:

                block on $int inet

will also effectively block all non-ip protocols. I assume that it does.


> On Nov 23, 2017, at 2:21 AM, Stuart Henderson <[hidden email]> wrote:
>
> On 2017/11/21 12:21, S. Donaldson wrote:
>> Applies to stable:
>>
>> OpenBSD 6.1 GENERIC.MP amd64  
>>
>> and stable
>>
>>  OpenBSD 6.2 GENERIC.MP amd64
>>
>>
>> pf rules that block using the proto key work with a negation fail with a syntax error.
>>
>> block on $int inet proto ! tcp
>
> I think you'll just need two rules for that:
>
> block on $int inet
> pass on $int inet proto tcp
>
>> and list based negations also fail
>>
>> block on $int inet proto ! { tcp udp }
>>
>> with a syntax error.
>
> Beware of list negations! If this was allowed it would expand to this:
>
> block on $int inet proto ! tcp
> block on $int inet proto ! udp
>
> Which is not what you want.
>
> It may seem to work in some cases with a list of IP addresses as the
> ruleset optimizer will convert them to a table if there are enough
> addresses, but this is dangerous as if you remove enough addresses it
> will start to do the wrong thing.
>
> In general avoid negation with lists.

Scott Donaldson
IS Manager
SED Systems a division of Calian Ltd.
Saskatoon, SK
Canada

Office Phone: 306-933-1577

Reply | Threaded
Open this post in threaded view
|

Re: when used pfctl should log any changes to state of FW

Kenneth Gober
In reply to this post by S. Donaldson
On Tue, Nov 21, 2017 at 1:21 PM, S. Donaldson <[hidden email]> wrote:
> So why does pfctl not appear to (I could not find a command line option - nor previous request)
>  log to syslog every command (who when what exit status) that changes anything within
>  the pf context such as : rules, table contents, states?

pfctl doesn't do this because it is so easily evaded.  Anyone with the
access to run pfctl also has the access to compile their own version
with logging disabled.  The only way to prevent this is to deny people
root access, and once you have done that there are far easier ways to
log who is doing what, for example doas(1).

-ken
Reply | Threaded
Open this post in threaded view
|

Re: pfctl parse issue with negated protocol list: block on $int proto ! { prot1 prot2 prot3 } leads to syntax error

Kenneth Gober
In reply to this post by S. Donaldson
On Thu, Nov 23, 2017 at 4:37 PM, S. Donaldson <[hidden email]> wrote:
>         I've moved past simple block / allow and am trying to add 'forensic' rules that generate log data that I can perform  some low level analysis against. I have not found documentation that clearly states that a block rule such as you suggest:
>
>                 block on $int inet
>
> will also effectively block all non-ip protocols. I assume that it does.

In a router, non-IP protocols are effectively blocked if they are not
forwarded.  If you are routing then blocking IP is equivalent to
blocking everything (unless you have compiled support for other
protocols into your kernel).

If you are bridging (or doing something very unusual) then you will
want instead:

block on $int
pass on $int inet proto tcp

-ken
Reply | Threaded
Open this post in threaded view
|

Simple block of inbound ssh with exceptions

Rolf Loudon
Hello

I’m both new to pf and struggling with what I thought was a simple idea.  This is on a laptop, not a firewall per se.  I want to (a) allow incoming ssh connections for a small list of addresses, and (b) block other inbound ssh.  No outbound restrictions at all.

Can’t make it work.  /etc/pf.conf:

table <mytable> { 192.168.10.13, 192.168.10.14, 192.168.100.1 }

pass in proto tcp from <mytable> port ssh
block in proto tcp from any port ssh
block in log all

I also thought that using ‘quick’ on the second rule would obviate the need for the generic last block.  So achieving it in two rules, just like what my specification is.

I’ve tried many variation.  I think I’m missing some understanding.  I know the rules are being observed because I can put in very basic statements like blocking a certain IP address for any service and that works.

Help appreciated.

r.



Reply | Threaded
Open this post in threaded view
|

Re: Simple block of inbound ssh with exceptions

Alexandr Nedvedicky
Hello,

</snip>

> This is on a laptop, not a firewall per se.  I want to (a) allow incoming ssh
> connections for a small list of addresses, and (b) block other inbound ssh.
> No outbound restrictions at all.
>
> Can’t make it work.  /etc/pf.conf:
>
> table <mytable> { 192.168.10.13, 192.168.10.14, 192.168.100.1 }
>
> pass in proto tcp from <mytable> port ssh
> block in proto tcp from any port ssh
> block in log all
>

there are two problems:

    1) the order of your rules is not quite right. PF uses 'last matching rule
    wins' strategy.

    2) you are missing rule, which creates a state for outbound packets, hence
    responses from remote peers can be accepted by firewall

        block in proto tcp from any port ssh
        block in log all
        pass in proto tcp from <mytable> port ssh
        pass out all

hope it helps
regards
sasha
Reply | Threaded
Open this post in threaded view
|

Re: Simple block of inbound ssh with exceptions

Stuart Henderson
In reply to this post by Rolf Loudon
On 2017/12/04 15:17, Rolf Loudon wrote:

> I’m both new to pf and struggling with what I thought was a simple
> idea.  This is on a laptop, not a firewall per se.  I want to (a) allow
> incoming ssh connections for a small list of addresses, and (b) block
> other inbound ssh.  No outbound restrictions at all.
>
> Can’t make it work.  /etc/pf.conf:
>
> table <mytable> { 192.168.10.13, 192.168.10.14, 192.168.100.1 }
>
> pass in proto tcp from <mytable> port ssh
> block in proto tcp from any port ssh
> block in log all
>
> I also thought that using ‘quick’ on the second rule would obviate the
> need for the generic last block.  So achieving it in two rules, just
> like what my specification is.
>
> I’ve tried many variation.  I think I’m missing some understanding.  I
> know the rules are being observed because I can put in very basic
> statements like blocking a certain IP address for any service and that
> works.

Normally, PF runs through the whole ruleset, and the last matching rule
wins. This can be short-circuited with "quick" which terminates ruleset
processing if a "quick" rule matches.

This will do what you want:

table <mytable> { 192.168.10.13, 192.168.10.14, 192.168.100.1 }
block log
pass in proto tcp from <mytable> port ssh

It is usually helpful for the first rule to block *all* packets. There is
an implicit default rule (equivalent to "pass flags any no state") and
things can get confusing if you have some traffic being allowed by this.
Reply | Threaded
Open this post in threaded view
|

Re: Simple block of inbound ssh with exceptions

Kenneth Gober
In reply to this post by Rolf Loudon
On Sun, Dec 3, 2017 at 11:17 PM, Rolf Loudon <[hidden email]> wrote:
> I’m both new to pf and struggling with what I thought was a simple idea.
> This is on a laptop, not a firewall per se.  I want to (a) allow incoming
> ssh connections for a small list of addresses, and (b) block other inbound
> ssh.  No outbound restrictions at all.

It's unclear whether you want to block other inbound traffic besides
ssh.  I am going to assume that you do.

# allow ssh from specific hosts
table <mytable> { 192.168.10.13, 192.168.10.14, 192.168.100.1 }
pass in quick proto tcp from <mytable> port ssh

# if you want to allow incoming ping requests uncomment next line
# pass in quick proto icmp icmp-type echoreq

# all other inbound blocked
# "quick" rules above will never get here
block in log all

# no outbound restrictions
pass out all
Reply | Threaded
Open this post in threaded view
|

policy routing with pf

Rolf Loudon
In reply to this post by Kenneth Gober
Hello

I’ve had several goes at this but can’t work it out.  Hoping there may be some assistance available. I cannot find examples I can refine online.

I have two interfaces which I can use for outbound traffic.  One ethernet, one wifi.  I want to send some traffic out via a given interface depending on the service I’m connecting to (eg ssh  via ethernet, https via wifi, etc).
(In the past with linux iproute2 and netfilter this is pretty straightforward).

Do I need to use route-to or is rdr the tool?

If I only wanted to choose via destination network then simple routing is sufficient.  Adding a port decision has me stuck.

Or is pf not the tool for this?

Many thanks

r.




Reply | Threaded
Open this post in threaded view
|

Re: policy routing with pf

Alexandr Nedvedicky
Hello,

On Fri, Mar 23, 2018 at 03:09:45PM +1100, Rolf Loudon wrote:

> Hello
>
> I’ve had several goes at this but can’t work it out.  Hoping there may be some assistance available. I cannot find examples I can refine online.
>
> I have two interfaces which I can use for outbound traffic.  One ethernet,
> one wifi.  I want to send some traffic out via a given interface depending on
> the service I’m connecting to (eg ssh  via ethernet, https via wifi, etc).
> (In the past with linux iproute2 and netfilter this is pretty
> straightforward).
>
> Do I need to use route-to or is rdr the tool?

    you want to use route-to

>
> If I only wanted to choose via destination network then simple routing is
> sufficient.  Adding a port decision has me stuck.
>
> Or is pf not the tool for this?

    PF is right tool if you want to make decisions by port number.

    Assuming your LAN connects to em1 interface on your router.

        pass in on em1 proto tcp from $LAN to any port = 443 route-to [ next hop ]@iwn0

    rule above sends all HTTPS traffic coming from your LAN over wifi. The '[
    next hop ]' parameter is IP address of next-hop router, which forwards
    traffic from you towards server. e.g. if your next hop is 10.10.10.10 then
    route-to option looks as follows:

        route-to 10.10.10.10@iwn0


hope it helps
regards
sasha
Reply | Threaded
Open this post in threaded view
|

Re: policy routing with pf

Evaldas Auryla
In reply to this post by Rolf Loudon
Hi, tags with route-to can do, something like that:

# internal interface
if_int1 = "em1"
# external interfaces, first ISP
if_ext1 = "pppoe0"
# second ISP
if_ext2 = "vlan832"
# second ISP gateway
router_isp2 = "2.2.2.2"

# apply tags to incoming traffic for specific ports
pass in log on $if_int1 inet proto tcp from any to any port ssh tag SSH
pass in log on $if_int1 inet proto tcp from any to any port { http,https
} tag WEB

# assuming $if_ext1 is default OS route
pass out log on $if_ext1 inet all tagged SSH nat-to ($if_ext1)
pass out log on $if_ext2 inet all tagged WEB nat-to ($if_ext2) route-to
($if_ext2 $router_isp2)

Should work for outgoing traffic. For incoming you would need
corresponding "reply-to", although it could get a bit messy with more
rules, I find it more simple to have multiple routing tables with
rdomain, rtable.


Best regards,
Evaldas

On 23/03/18 05:09, Rolf Loudon wrote:

> Hello
>
> I’ve had several goes at this but can’t work it out.  Hoping there may be
> some assistance available. I cannot find examples I can refine online.
>
> I have two interfaces which I can use for outbound traffic.  One ethernet,
> one wifi.  I want to send some traffic out via a given interface depending
> on the service I’m connecting to (eg ssh  via ethernet, https via wifi,
> etc).
> (In the past with linux iproute2 and netfilter this is pretty
> straightforward).
>
> Do I need to use route-to or is rdr the tool?
>
> If I only wanted to choose via destination network then simple routing is
> sufficient.  Adding a port decision has me stuck.
>
> Or is pf not the tool for this?
>
> Many thanks
>
> r.
>
>
>
>