Re: Fastnetmon OpenBSD Port update,

Hi Stuart Thanks for the feedback working on it  as we  speak 

re the bgpctl  ( it is often the case on a multi tenanted system that each rdomain /VRF  might have its own instance of bgp

so bgpctl will connect 

when in the management rdomain (240 in my case) (ssh is running on rdomain 240 ) 

mitigate1# bgpctl show summary
bgpctl: connect: /var/run/bgpd.sock.240: No such file or directory

mitigate1# route -T0 exec ksh

New shell in Rdomain 1
mitigate1# bgpctl show summary
Neighbor                   AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
NEIGHBR1              62129     150966         30     0 00:13:57 1061297
NEIGHBR2              62129         30         30     0 00:13:57      0
Cogent-RTBH               174         16         15     0 00:13:56      0
HE-RTBH                  6939         17         15     0 00:13:53      0

ok man bgpctl  shows that we can connect to a specific socket  I didnt know this :) 

mitigate1# bgpctl -s /var/run/bgpd.sock.0 show summary
Neighbor                   AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
NEIGHBR1               62129     152270         40     0 00:18:34 1061222
NEIGHBR1                62129         40         40     0 00:18:34      0
Cogent-RTBH               174         21         20     0 00:18:33      0
HE-RTBH                  6939         22         20     0 00:18:30      0

I see about automatically setting the permissions on /var/run/sock/bgpd.sock.0  

after bgpd starts...  

Ill update the new ban scripts with  this in mind 

the other suggestions now 

On Tue, 26 May 2026 at 13:47, Stuart Henderson <stu@spacehopper.org> wrote:

On 2026/05/25 10:46, Tom Smyth wrote:
> Folks, 
>
> I modified fastnetmon ban / unban scripts to use openBGPd to trigger remote blackholes using
> BGP  (RTBH) 
>
> I have included an example bgpd filter rule set to achieve that and set Blackhole communities
> and custom communities to distinguish the blackhole routes
>
>
> In my setup fastnetmon  runs and receives Sflow on a management Rdomain / VRF and then triggers
> OpenBGPD (which is running in rdomain0  to 
> advertise routes..
>
> to do this I modified doas.conf to allow fastnetmon to run the ban script as root to change
> rdomain and to add a bgp network advertisement using bgpctl 

> I feel uncomfortable about fastnetmon having root on a shell script but I have not been able to
> lock down executing  
> /sbin/route -T0 exec /usr/sbin/bgpctl network add $1/32 community $ASNUMBER:666 community
> BLACKHOLE 
> because the arguments change (for each Ip address) 

bgpctl communicates with bgpd over a local named socket, not a tcp
socket, so rdomain shouldn't matter.

untested but I think you should be able to chgrp the bgpd socket after
bgpd has started so the user running bgpctl doesn't need to be in group
'wheel'. just make sure the user running the ban script is in that
group. I'm pretty sure that should work.

> thinking out loud
> it would be nice if doas user could be permitted to run a shell script provided the checksum of
> the script matched a value set by the doas administrator

a script in /usr/local/bin that is only writable by root is no less
safe (anyone able to edit the script could also edit the checksum/hash).

>     on latest latest snapshot ( sunday afternoon UTC) 
>     Compiles with warnings,   I will discuss compiler warnings with upstream and see what can
>     be done about them, I see some low hanging fruit like strcpy vs strlcpy etc...

strcpy vs strlcpy etc changes still need to be done carefully. (we don't
generally want to patch these in ports btw, best done upstream if done
at all).

>     the system seems to be receiving flows and version information is correct  

good, I've readded to ports for -current. (also set to build debug
packages now, to help analysis if there are crashes).

>     It will be nice to see if the new version is more stable in OpenBSD, Ill report back 

thanks.

>     for info I have included, the check which I needed in the past to keep fastnetmon running
>     on OpenBSD

>     *       *       *       *       *        /bin/ksh /usr/local/sbin/crashdetect-fastnemon

you could just 'rcctl start fastnetmon' and root will get a mail if
it actually has to start it (because it will show some output).

or some tidying for the script:

>     mitigate1# cat /usr/local/sbin/crashdetect-fastnemon
>     #!/sbin/ksh -

check that fastnetmon is installed and not disabled before trying to
restart:

[ -e /etc/rc.d/fastnetmon ] || exit 0
[[ $(rcctl get fastnetmon flags) == NO ]] && exit 0

(avoids the script triggering during updates etc, or if you need to
disabl le it temporaroly)

>     #
>     pgrep ^fastnetmon$ >/dev/null
>     export ISNOTRUNNING=$?
>     if [ $ISNOTRUNNING -eq 1 ] ; then

above can be simplified:

if ! pgrep -q ^fastnetmon$; then

>     echo fastnetmon not running >>/var/log/fastnetmon/crashdetect.log
>     date >>/var/log/fastnetmon/crashdetect.log
>     rcctl restart fastnetmon

logger is good for this, then it ends up in normal syslogs. e.g.

logger -t fastnetmon-check 'not running, restarted'

(I'd probably also have it email me the tail of fastnetmon's log if
it has to restart)

>     else
>     echo 0

I think you have a lot of useless mails to root containong 0

>     fi
>     exit

no need to exit at the end

--

Kindest regards,
Tom Smyth.