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
