Triggering pf.conf anchor load based on ip detected

[daemonbak]

I have an anchor for a service that is needed ONLY when the device is present. otherwise, those ports should be closed and that anchor ignored.

I can write a script that will load and unload the anchor from the cli obviosuly, but there must be a better way to check wether the anchor should be loaded.

I could write a script to run as a cron every 2 minutes / constant running loop to check if that ip is in use like:

#!/bin/bash
ping -c 1 $IP >> /dev/null
if [ $? -eq 0 ]; then
        echo "set return state 0"
        echo "run pfctl -a load anchor ports open on subset rules until connection down"
        pfctl -a $anchor -sr
fi

ping -c 1 $IP >> /dev/null
if [ $? -eq 1 ]; then
        echo "set return state 1"
        echo "connection down, unload anchor"
        pfctl -a $anchor -F all
fi

#!/bin/bash
result=1
while [ $result -neq 0 ]; do
    ping -c 1 $IP
    result=$?
done

But that would be a sloppy workaround. Would using something like ifstated to look for that machine and then load that rule?

Has anyone ever seen something like what i am looking to accomplish?

if machine detected (
pfctl load anchor
)
else (
ignore ruleset anchor)
if state changes and ip offline unload currently loaded anchor

And of course, obviously if machine exits network/loses connection/powered off unload that anchor effectively closing the ports and returning the firewall to stealth mode on change of machine state not present.

Would be nice if I didn't have to have cron jobs running every 2 minutes and then executing a script. Hoping there is a pf.conf setting to do this or something more elegant that my if ping works load anchor if ping fails unload anchor.

Thanks!

[jggimi]

Both ifstated(8) and hotplugd(8) are designed for this sort of automation.

I use ifstated(8) on a pair of firewalls with interfaces that cannot use carp(8) due to requiring dhclient(8) on a shared subnet. The scripts automatically manage the "shared" dhclient environment and present a single MAC to an ISP upstream.

[daemonbak]

Not sure why my post was deleted a few days ago. But I had said thank you!

Exactly what i was looking for. Spot on jggimi.

Thank you again sir.

[daemonbak]

Ok have the original ifstated working flawlessly for one event. Which is to run a pfctl command when an ip is detected. So when i power on the xbox, my ports go live. When I power it off, the firewall closes those ports and goes stealth.

However, when trying to have 2 INDEPENDENT rules in ifstated, it will never load the second ruleset or triggers.

These are unrelated service and should have no bearing on one another. if my workPC is present, the pfctl anchor rule should open up the VPN ports. But that will have nothing to do with the Xbox and visa versa. So they need to be in complete ignorance of each other.

Here is my code, I am curios if this is even a possibility or what i am doing wrong.

If i ifstated -dvv I see the first rule (ping -q -c 1 -w 1 192.168.10.4 > /dev/null" every 90) running every 90 seconds and if a change is made, it detects and it runs the rule. However the second on I never see it in the ifstated -dvv output.

# $OpenBSD: ifstated.conf,v 1.1 2014/07/11 16:36:35 deraadt Exp $

## Open up ports when xbox is powered on for Multiplayer
## Close ports when xbox is powered down for stealth

xbox_ip = '( "ping -q -c 1 -w 1 192.168.10.4 > /dev/null" every 90)'


state console_off {
        init {
                run 'pfctl -a console -F rules'
        }
        if $xbox_ip
                set-state console_on
}


state console_on {
	init {
		run 'pfctl -a console -f /etc/pf_anchor_console'
	}
	if ! $xbox_ip
		set-state console_off
		
}


## Open up ports when work pc is present to open VPN
## Close ports when work pc is not present for stealth

workpc_ip = "( "ping -q -c 1 -w 1 192.168.10.125 > /dev/null" every 60 )"

state vpn_off {
        init {
                run 'pfctl -a vpn -F rules'
        }
        if $workpc_ip
                set-state vpn_on
}


state vpn_on {
	init {
		run 'pfctl -a vpn -f /etc/pf_anchor_vpn'
	}
	if ! $workpc_ip
		set-state vpn_off
		
}

Thanks

[jggimi]

States are not independent. There is only one active state at any point in time. So saith ifstated.conf(8):

The init block is used to initialise the state and is executed each time the state is entered. The body of a state is only executed when that state is the current state and an event occurs.

[daemonbak]

So a little confused. I have 4 states.

2 states are controlled by ping for the on/off state. That works fine.

Now add the other 2 states that are controlled and dictated by another ping to control which state loads.

Are you saying that I can only pick one or the other?

is there a way to have ifstated "listen" to two different independent states?

i.e. one for ping -q -c 1 -w 1 192.168.10.125 and one for ping -q -c 1 -w 1 192.168.10.4?

[jggimi]

The ifstated application use a Finite State Machine model.

When you have two possible states (A and B), the state machine is in one state or the other: A or B. That is why the "two state" model works for a single binary test. When you added a third and fourth state (C and D), you assumed they were independent. They are not. However many states you define, only one is active at any moment. If you have four states A through D, the machine will always be in one of those states: A, B, C, or D. Not any combination. There is no independence. No parallel operation.

At the moment, you're trying to manage 2 independent tests, that actually have 4 possible states: xbox on vpn on, xbox off vpn on, xbox on vpn off, and xbox off vpn off. Lucky you. Another binary test and you'd have 8 possible states. Another, 16 states, and so on.

You can either redesign the states and tests to account for all four possible states, or you can run multiple instances of ifstated. One takes a little design time, the other takes administrative consideration. The choice, of course, is yours, since the operational outcome would be equivalent.

[daemonbak]

Ok think i am getting there.
let me run this by you.

So i have 4 states. 2 sets of 2 states. Each set hoping to monitor and trigger an event within that set.

However, from what i am getting from you is even though by looking at the conf, it looks to be 2 different sets, ifstated only sees it as 1 set of 4 states, not 2 sets of 2 states. Am i correct in my understanding?

So my options are to combine the 2 sets into one ala:
if this and this then choose state one
if this and not that choose state 2
if not this and not that choose state 3
if not this and that then choose state 4.

Is that what you were talking about to combine?
That would not work given the 2 end results are different and should not be in themselves triggers.

So my other option, if I am reading this correctly is to have a /etc/ifstated.1 and and /etc/ifstated.2. Each one effectively breaking mine in half. Xbox for one, VPN for the other.

I would assume that i would make a modification to /etc/rc.conf.local with 2 entries?

Also, if I were to run 2 instances, are there any security or performance drawbacks i should b aware of?

Thanks again

[jggimi]

Originally Posted by daemonbak

Ok think i am getting there.
let me run this by you.

So i have 4 states. 2 sets of 2 states. Each set hoping to monitor and trigger an event within that set.

However, from what i am getting from you is even though by looking at the conf, it looks to be 2 different sets, ifstated only sees it as 1 set of 4 states, not 2 sets of 2 states. Am i correct in my understanding?

Yes. You happened to place a macro in between the second and third state of 4. But that does not change the fact that there are four distinct states.

So my options are to combine the 2 sets into one....That would not work given the 2 end results are different and should not be in themselves triggers.

I didn't see it that way, because each state's test can be a script which tests both situations and has 4 possible outcomes. But this was only one option that I perceived was possible.

So my other option, if I am reading this correctly is to have a /etc/ifstated.1 and and /etc/ifstated.2. Each one effectively breaking mine in half. Xbox for one, VPN for the other.

Yes.

I would assume that i would make a modification to /etc/rc.conf.local with 2 entries?

You could create two separate rc.subr(8) scripts and manage them via rc.conf.local, or you could use a simple rc.local(8) script that starts both.

Also, if I were to run 2 instances, are there any security or performance drawbacks i should b aware of?

None that I am aware of. But I have never run two instances; it was merely an option I suggest you explore.

[daemonbak]

So lets see if I am understanding this. This is new territory for me, so want to make sure I am doing this right.

cp -p /etc/ifstated /etc/ifstated.console

/etc/ifstated.console:

# $OpenBSD: ifstated.conf,v 1.1 2014/07/11 16:36:35 deraadt Exp $

## Open up ports when xbox is powered on for Multiplayer
## Close ports when xbox is powered down for stealth

xbox_ip = '( "ping -q -c 1 -w 1 192.168.10.4 > /dev/null" every 90)'


state console_off {
        init {
                run 'pfctl -a console -F rules'
        }
        if $xbox_ip
                set-state console_on
}


state console_on {
	init {
		run 'pfctl -a console -f /etc/pf_anchor_console'
	}
	if ! $xbox_ip
		set-state console_off
		
}

cp -p /etc/ifstated /etc/ifstated.vpn

/etc/ifstated.vpn:

# $OpenBSD: ifstated.conf,v 1.1 2014/07/11 16:36:35 deraadt Exp $

## Open up ports when work pc is present to open VPN
## Close ports when work pc is not present for stealth

workpc_ip = "( "ping -q -c 1 -w 1 192.168.10.125 > /dev/null" every 60 )"

state vpn_off {
        init {
                run 'pfctl -a vpn -F rules'
        }
        if $workpc_ip
                set-state vpn_on
}


state vpn_on {
	init {
		run 'pfctl -a vpn -f /etc/pf_anchor_vpn'
	}
	if ! $workpc_ip
		set-state vpn_off
		
}

Then
cp -p /etc/rc.d/ifstated /etc/rc.d/ifstated.console
cp -p /etc/rc.d/ifstated /etc/rc.d/ifstated.vpn

Then add the following to rc.conf.local:

Turn off ifstated default daemon and feed string to ifstated daemons I copied linking to correct config fil.

ifstated_flags="NO"
ifstated.console_flags="-f /etc/ifstated.console"
ifstated.vpn_flags="-f /etc/ifstated.vpn"

[jggimi]

One of the options I'd recommended was the simple expedient of starting two copies from rc.local(8). You only need a three line file, and I suggest before investing in significant effort with the rc.d subsystem that you just test two ifstated instances, such as shown here:

#!/bin/sh
/usr/sbin/ifstated -f /etc/ifstated.vpn
/usr/sbin/ifstated -f /etc/ifstated.console

But ... looking at your more complex provisioning, I have four comments:

First, the configuration file you planned to copy is /etc/ifstated.conf, rather than the shorter file name you've posted. I assume this was just a typo.

Second, you need not set ifstated_flags=NO. You can instead remove the line from rc.conf.local. The default NO is set in rc.conf.

Third, these are not standard daemon names. You must treat them as if they are packages, and add them to your list of package daemons in pkg_scripts

Fourth ... I'm not sure if there is any value in this effort. My understanding was that if packets are passed by PF to a system that isn't operational, no return packets will be transmitted. This is the equivalent in behaviour to a PF block drop rule. Do I misunderstand your intentions?