View previous topic :: View next topic |
Author |
Message |
2bbionic Apprentice
Joined: 24 Mar 2005 Posts: 152
|
Posted: Tue Jul 09, 2024 1:17 pm Post subject: [gelöst]fail2ban - Anpassen der Gruppe im /run/fail2ban -... |
|
|
Hallo,
für meine Überwachung frage ich regelmäßig fail2ban ab, ob es Einträge in der Jail hat.
Das geht leider nur, wenn der anfragende Benutzer die entsprechende Rechte hat, per default nur root - was ich im Prinzip OK finde.
Da ich meine Abfrage allerdings über einen nicht privilegierten Account stelle geht das natürlich erstmal schief.
Als Workaround habe ich die Lösung gefunden, die Gruppe der Datei /run/faiul2ban/fail2ban.sock anzupassen; von "root" auf z.B. "fail2ban" und den anfragenden Benutzer in diese Gruppe zu setzen.
Das funktioniert auch soweit.
Beim Restart bzw. Start von fail2ban schaffe ich es aber nicht, in /etc/init.d/fail2ban die Gruppen(berechtigungen) anzupassen - ein chgrp/chmod kann ich dort nirgends einfügen.
Hat daher jemand eine Idee, wie ich mit einem nicht privilegierten Benutzer auf den Socket von fail2ban zugreifen kann - oder evtl eine Lösung für mein Problem mit der init.d - Datei?
Anbei noch meine init.d - Datei; evtl hat die ja auch was - bin nicht so firm mit openRC:
Code: |
#!/sbin/openrc-run
# This file is part of Fail2Ban.
#
# Fail2Ban is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# Fail2Ban is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with Fail2Ban; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
#
# Author: Sireyessire, Cyril Jaquier
#
description="Ban hosts that cause multiple authentication errors"
description_reload="reload configuration without dropping bans"
extra_started_commands="reload"
# Can't (and shouldn't) be changed by the end-user.
#
# Note that /usr/bin is already supplied by the build system. Some
# day, it might be nice to have @RUNDIR@ supplied by the build system
# as well, so that we don't have to hard-code /run here.
FAIL2BAN_RUNDIR="/run/${RC_SVCNAME}"
FAIL2BAN_SOCKET="${FAIL2BAN_RUNDIR}/${RC_SVCNAME}.sock"
# The fail2ban-client program is also capable of starting and stopping
# the server, but things are simpler if we let start-stop-daemon do it.
command="/usr/bin/fail2ban-server"
pidfile="${FAIL2BAN_RUNDIR}/${RC_SVCNAME}.pid"
# We force the pidfile/socket location in this service script because
# we're taking responsibility for ensuring that their parent directory
# exists and has the correct permissions (which we can't do if the
# user is allowed to change them).
command_args="${FAIL2BAN_OPTIONS} -p ${pidfile} -s ${FAIL2BAN_SOCKET}"
retry="30"
depend() {
use logger
after iptables
}
checkconfig() {
"${command}" ${command_args} --test
}
start_pre() {
# If this isn't a restart, make sure that the user's config isn't
# busted before we try to start the daemon (this will produce
# better error messages than if we just try to start it blindly).
#
# If, on the other hand, this *is* a restart, then the stop_pre
# action will have ensured that the config is usable and we don't
# need to do that again.
if [ "${RC_CMD}" != "restart" ] ; then
checkconfig || return $?
fi
checkpath -d "${FAIL2BAN_RUNDIR}"
}
stop_pre() {
# If this is a restart, check to make sure the user's config
# isn't busted before we stop the running daemon.
if [ "${RC_CMD}" = "restart" ] ; then
checkconfig || return $?
fi
}
reload() {
# The fail2ban-client uses an undocumented protocol to tell
# the server to reload(), so we have to use it here rather
# than e.g. sending a signal to the server daemon. Note that
# the reload will fail (on the server side) if the new config
# is invalid; we therefore don't need to test it ourselves
# with checkconfig() before initiating the reload.
ebegin "Reloading ${RC_SVCNAME}"
"/usr/bin/fail2ban-client" ${command_args} reload
eend $? "Failed to reload ${RC_SVCNAME}"
}
|
Gruß,
2bbionic
Last edited by 2bbionic on Tue Jul 09, 2024 4:09 pm; edited 1 time in total |
|
Back to top |
|
|
Max Steel Advocate
Joined: 12 Feb 2007 Posts: 2267 Location: My own world! I and Gentoo!
|
Posted: Tue Jul 09, 2024 3:36 pm Post subject: |
|
|
Statt die fail2ban init-file zu verändern, was generell keine gute Idee ist, kannst du deinen Wunsch in der fail2ban conf.d-file verewigen.
Code: | # /etc/conf.d/fail2ban
start_post () {
ebegin "Change Socket Group"
chgrp adm ${FAIL2BAN_SOCKET} || eend $? && exit
chmod 750 ${FAIL2BAN_SOCKET} || eend $? && exit
eend $rc
}
|
Einfach an die Datei anhängen und die Befehle werden bei einem restart und einem start nach dem normalen Prozedere ausgeführt.
Man könnte die Gruppe jetzt noch in eine eigene Variable packen... aber da das ja auch in dieser Datei gesetzt werden würde, bin ich okay damit. Kann jeder für sich selbst entscheiden. _________________ mfg
Steel
___________________
Heim-PC: AMD Ryzen 5950X, 64GB RAM, GTX 1080
Laptop: Intel Core i5-4300U, 16GB RAM, Intel Graphic
Arbeit-PC: Intel i5-1145G7, 16GB RAM, Intel Iris Xe Graphic (leider WSL2) |
|
Back to top |
|
|
2bbionic Apprentice
Joined: 24 Mar 2005 Posts: 152
|
Posted: Tue Jul 09, 2024 4:08 pm Post subject: |
|
|
Ja, perfekt!
Ich stimme zu, die Änderung innerhalb der init-Skripte hielt ich auch nicht für elegant - wusste aber nicht, dass man in der conf.d ein start_post konfigurieren kann.
Habs's getestet, funktioniert tadellos!
Gruß und vielen Dank,
2bbionic |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|