Created attachment 158319 [details] Convert all sshguard ports into one port & make use the OPTIONS framework Hi, Patch that converts the sshguard(8) port to use the OPTIONS framework which eliminates the slave ports. Patch also includes support for the NULL backend. The NULL back does not call any firewall command at all, it can however, be used to call a custom script or binary. Users can specify a custom script or binary by: # sysrc sshguard_flags="-e /usr/local/sbin/sshguard-null" Attached is the patch to convert all sshguard ports into one port. Following is sample custom script to call ipfw(4) making use of the table name sshguard instead of a table number: $ cat /usr/local/sbin/sshguard-null #!/bin/sh # Sourced from: # https://sourceforge.net/p/sshguard/mailman/message/34151601/ fwcmd="/sbin/ipfw" table_id="sshguard" print_debug="0" fwcmd_debug() { if [ ${print_debug} -gt 0 ]; then /usr/bin/logger -i -p local0.notice -t sshguard-null ${@} fi } fwcmd_debug "${0}: Incoming sshguard(8) action" case ${SSHG_ACTION} in init) fwcmd_debug "${SSHG_ACTION}" ;; fin) fwcmd_debug "${fwcmd} table ${table_id} flush" ${fwcmd} table ${table_id} flush ;; block) fwcmd_debug "${fwcmd} table ${table_id} add ${SSHG_ADDR}" ${fwcmd} table ${table_id} add ${SSHG_ADDR} ;; block_list) for a in `echo ${SSHG_ADDR} | sed 's/,/ /g'` ; do fwcmd_debug "${fwcmd} table ${table_id} add ${a}" ${fwcmd} table ${table_id} add ${a} done ;; release) fwcmd_debug "${fwcmd} table ${table_id} delete ${SSHG_ADDR}" ${fwcmd} table ${table_id} delete ${SSHG_ADDR} ;; flush) fwcmd_debug "${fwcmd} table ${table_id} flush" ${fwcmd} table ${table_id} flush ;; *) fwcmd_debug "${SSHG_ACTION} unsupported" ;; esac exit 0
Created attachment 158321 [details] Udpated patch to make use of .elif for OPTIONS
Hello, This is great work. However I have just realized that the primary benefit of the slave ports is that official packages are built for each backend. After this change users will have to compile their own sshguard if they did not want the default backend OPTION (null) and very few people will want that backend. Even if we change the default OPTION to a more popular backend like pf I am still unsure how many users this will displace. I will need to think about this for a while and maybe consult with some others. Please do not be discouraged from submitting future patches to ports. Patches are *good* and invoke important thought and discussion. :-) Cheers!
(In reply to Mark Felder from comment #2) When time permits, I will submit another patch that adds a separate security/sshguard-null port. It is my understanding that there is work in progress for pkg to handle different flavours of the one port; the flavours coming from the configurable port options. Perhaps we could review the single sshguard port then?
(In reply to Alastair Hogge from comment #3) Yes that would be the ideal way to approach this. I'll take a quick look at creating another slave port for the null backend. I'm sure it's easy.
reopening so we can get an sshguard-null slave port
Created attachment 158911 [details] sshguard-null slave port Would you mind testing this patch?
(In reply to Mark Felder from comment #6) Tested & works. Thanks
A commit references this bug: Author: feld Date: Sun Jul 26 15:04:37 UTC 2015 New revision: 392923 URL: https://svnweb.freebsd.org/changeset/ports/392923 Log: security/sshguard-null portable do-nothing backend for applying detection but not prevention PR: 201323 Changes: head/security/Makefile head/security/sshguard/Makefile head/security/sshguard-ipfilter/Makefile head/security/sshguard-ipfw/Makefile head/security/sshguard-null/ head/security/sshguard-null/Makefile head/security/sshguard-pf/Makefile