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 <[email protected]> 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.

Reply via email to