Feature #14710
open
Possible Idea for new firewall feature "ACL CONNECTED RED LED FLAG FEATURE"
0%
Description
Hello fellow Netgate pfSense Redmine community members,
I wanted to share this with you all to see if this is anything that could be tied directly into the GUI firewall rules page.
RULE BASE FLAGGING VIA VISUAL LED ON FRONT PANEL
Value addon: Increase in visibility for specific firewall rules and or devices that are connecting without any changes to hardware. Can be coded to only work with dormant non utilized LEDS.
Example:
Example of what can occur: .... Drifting off into dreamland ....
It's 11pm and someone turns on a gaming system, you know this individual has a test or maybe a soccer game tomorrow, all the sudden your firewall'a state established LED turns on and glows red.
I sprang from my bed to see what was the matter. Away to the TV I flew like a flash, tore open the door, and went with dash. When, what to my wondering eyes should appear, the little one again with game controller in hand. Now little one, you stand with a solemn face... go to bed ! Go to bed! Go back to bed now!"
Reality this is a possible way to tie LEDS directly into a rule id within the ACL list
You could even tie this into VPN rules or anything you wanted to alarm you.
I have tested this and it does work with cron
deviceonlinenight.sh
#!/bin/sh
pfctl -vvss | grep ', rule 79' >/dev/null
res=$?
if [ $res = 0 ];
then
sysctl -q dev.gpio.2.led.0.pwm=1
gpioctl -f /dev/gpioc2 0 duty 200 >/dev/null
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 200 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 6 duty 200 >/dev/null
else
sysctl -q dev.gpio.2.led.0.pwm=1
gpioctl -f /dev/gpioc2 0 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 1 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 2 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 4 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 5 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 6 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 7 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 8 duty 0 >/dev/null
fi
deviceonlineday
#!/bin/sh
pfctl -vvss | grep ', rule 79' >/dev/null
res=$?
if [ $res = 0 ];
then
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 100 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 6 duty 100 >/dev/null
else
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 7 duty 100 >/dev/null
fi
Ref researching:
https://forum.netgate.com/topic/182391/2100-led-question
https://forums.freebsd.org/threads/bin-sh-how-to-save-a-shell-command-output-into-a-string-variable.90088/
https://github.com/luckman212/Netgate-SG2100-scripts
https://www.zacharyschneider.ca/2019/12/customizing-leds-netgate-sg-3100/
https://forum.netgate.com/topic/122407/netgate-sg-3100-leds?ref=zacharyschneider.ca
Files
| IMG_20230824_104757565.jpg (2 MB) IMG_20230824_104757565.jpg | Researching proof of concept with RED led activated | ||
| IMG_20230824_220920858.jpg (1.6 MB) IMG_20230824_220920858.jpg | Three LED test with device online test completed | ||
| IMG_20230825_171454810.jpg (1.17 MB) IMG_20230825_171454810.jpg | Purple |
Updated by Jonathan Lee over 1 year ago
The capability is you can take any rule ID you have that establishes a connection and you could configure it to be used to enable a LED with a selected color, from rules that have alias with full fleets of IP phones, to rouge laptops, or even devices you want to alarm you if they come online.
It could also be set up with the ability to provide knowledge of when not to reboot equipment do to high availability equipment being used during an unspecified time.
It could be tied into a ring doorbell so when a button is pushed it turns a LED on. The possibilities are endless.
In the 90s I remember so often all the instructors being told to log out for network servicing on their PC systems.
Today the network service would have complete knowledge when systems are no longer using a rule.
VPN connections,
Users logged in your server purchasing goods.
You could set it to any rule.
Updated by Jonathan Lee over 1 year ago
pfctl -vvss| grep '192.168.1.11' would work great too as it would be IP address based not rule based
also
pfctl -vvss| grep -e 192.168.1.18 -e 192.168.1.11
Multiple IP addresses and or multiple rules
Updated by Jonathan Lee over 1 year ago
Side note, I recently learned "The Air force one Executive Phone has a light on the back that lights up red when secure."
This kind of add on LED adapting feature would give PfSense the ability to have the red lights turn too for specific access control lists
Updated by Jim Pingle over 1 year ago
- Project changed from pfSense Plus to pfSense Packages
- Category changed from Aliases / Tables to New Package Request
- Release Notes deleted (
Default)
I don't see anything like that being added to the base system, but maybe someone might design a package around it.
The main problem is that continually polling the state table in that way scales very poorly and can incur a drastic performance penalty when done frequently. The higher the load and larger the state table, the bigger hit it takes polling for states. If it's in the base system, it's more likely people would enable it without realizing the consequences.
Updated by Jonathan Lee over 1 year ago
I wonder if there is another way to do it maybe with the active state tables counters. Thanks for looking into this idea. I have to admit I was impressed that I got it to work correctly with the game system, I did not know efficiency could be degraded.
Updated by Jonathan Lee over 1 year ago
Here is a photo of testing with the three LEDs enabled when rule 79 went active.
Does the state table counters also degrade system performance?
Updated by Jonathan Lee over 1 year ago
If anyone knows of a more efficient want to poll the state table, please let me know.
Have a good day
Updated by Jonathan Lee over 1 year ago
Non standard colours also
#!/bin/sh
pfctl -vvss | grep ', rule 79' >/dev/null
res=$?
if [ $res = 0 ];
then
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 100 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 7 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 6 duty 100 >/dev/null
gpioctl -f /dev/gpioc2 8 duty 100 >/dev/null
else
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 6 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 8 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 7 duty 7 >/dev/null
fi
You can even combine colours into purple if needed.
Updated by Jonathan Lee over 1 year ago
Different way to iterate the variable for multiple cases
You can also use the the case command to iterate over the variable I named state for any item you want to set up for led interactors
@#!/bin/sh
state=$( pfctl -vvss )
res=1
resb=1
case "$state" in
, rule 79)
res=0
;;
esac
case "$state" in
192.168.1.11)
resb=0
;;
esac
if [ $res = 0 ] && [ $resb = 0 ];
then
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 50 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 7 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 6 duty 50 >/dev/null
elif [ $res = 0 ];
then
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 7 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 6 duty 50 >/dev/null
elif [ $resb = 0 ];
then
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 7 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 6 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 50 >/dev/null
else
sysctl -q dev.gpio.2.led.1.pwm=1
gpioctl -f /dev/gpioc2 3 duty 0 >/dev/null
sysctl -q dev.gpio.2.led.2.pwm=1
gpioctl -f /dev/gpioc2 6 duty 0 >/dev/null
gpioctl -f /dev/gpioc2 7 duty 50 >/dev/null
fi@