Multiple processes

Issue #120 closed
Darin Hensley created an issue

I am running SSHGuard 2.1.0 with Gentoo(installed from portage).


two@develop ~
\% cat /etc/sshguard.conf
#!/bin/sh

sshguard.conf -- SSHGuard configuration

Options that are uncommented in this example are set to their default

values. Options without defaults are commented out.

REQUIRED CONFIGURATION

Full path to backend executable (required, no default)

BACKEND="/usr/libexec/sshg-fw-iptables"

Space-separated list of log files to monitor. (optional, no default)

FILES="/var/log/auth.log"

Shell command that provides logs on standard output. (optional, no default)

Example 1: ssh and sendmail from systemd journal:

#LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t sendmail -o cat"

Example 2: ssh from os_log (macOS 10.12+)

#LOGREADER="/usr/bin/log stream --style syslog --predicate '(processImagePath contains "sshd")'"

OPTIONS

Block attackers when their cumulative attack score exceeds THRESHOLD.

Most attacks have a score of 10. (optional, default 30)

THRESHOLD=10

Block attackers for initially BLOCK_TIME seconds after exceeding THRESHOLD.

Subsequent blocks increase by a factor of 1.5. (optional, default 120)

BLOCK_TIME=180

Remember potential attackers for up to DETECTION_TIME seconds before

resetting their score. (optional, default 1800)

DETECTION_TIME=3600

Size of IPv6 'subnet to block. Defaults to a single address, CIDR notation. (optional, default to 128)

#IPV6_SUBNET=128

Size of IPv4 subnet to block. Defaults to a single address, CIDR notation. (optional, default to 32)

#IPV4_SUBNET=32

EXTRAS

!! Warning: These features may not work correctly with sandboxing. !!

Full path to PID file (optional, no default)

PID_FILE=/var/run/sshguard.pid
IPV6_SUBNET=128
IPV4_SUBNET=32

Colon-separated blacklist threshold and full path to blacklist file.

(optional, no default)

#BLACKLIST_FILE=90:/var/lib/sshguard/enemies

IP addresses listed in the WHITELIST_FILE are considered to be

friendlies and will never be blocked.

#WHITELIST_FILE=/etc/friends
two@develop ~
\%


[code]develop /home/two # /etc/init.d/sshguard start

  • Starting sshguard ... [ ok ]
    develop /home/two # /etc/init.d/sshguard status
  • status: crashed
    develop /home/two # ps -elf | grep -i sshguard| nl
    1 0 S root 2844 1 0 80 0 - 2173 - 21:25 ? 00:00:00 /bin/sh /usr/sbin/sshguard -i /var/run/sshguard.pid -l /var/log/auth.log
    2 1 S root 2845 2844 0 80 0 - 2173 - 21:25 ? 00:00:00 /bin/sh /usr/sbin/sshguard -i /var/run/sshguard.pid -l /var/log/auth.log
    3 0 S root 2847 2844 0 80 0 - 2740 - 21:25 ? 00:00:00 /usr/libexec/sshg-blocker -a 10 -i /var/run/sshguard.pid -p 120 -s 1800
    4 1 S root 2848 2844 0 80 0 - 2173 - 21:25 ? 00:00:00 /bin/sh /usr/sbin/sshguard -i /var/run/sshguard.pid -l /var/log/auth.log
    5 0 S root 2879 2746 0 80 0 - 1965 - 21:25 pts/0 00:00:00 grep --color=always -i sshguard[/code]

I checked in /var/log/auth.log and sshguard is running and blocking successfully.

Nothing in the dmesg or /var/log/messages shows anything wrong with it.

Why is openrc showing status crashed? And are there supposed to be 3 duplicate processes of it with /bin/sh /usr/sbin/sshguard -i /var/run/sshguard.pid -l /var/log/auth.log?

Comments (9)

  1. Kevin Zheng

    It could be a bug with the openrc script. Could you attach the contents of /etc/init.d/sshguard?

    It is normal for there to be 3 /bin/sh processes. The first one is invoked with the script, the second two are spawned as subshells when the last line in the driver script is run.

  2. Darin Hensley reporter
    #!/sbin/openrc-run
    # Copyright 1999-2011 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    
    depend() {
        after iptables
        use logger
    }
    
    SSHGUARD_PIDFILE=${SSHGUARD_PIDFILE:-/var/run/${SVCNAME}.pid}
    
    start() {
        ebegin "Starting sshguard"
        [ -z "${SSHGUARD_WAIT}" ] && SSHGUARD_WAIT=999
        start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet --exec \
            /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS}
        eend $?
    }
    
    stop() {
        ebegin "Stopping sshguard"
        start-stop-daemon --stop -p ${SSHGUARD_PIDFILE}
        eend $?
    }
    

    Just to note on 2.1 above:

    1. I get the redundant processes when I also run from command line.

    2) If I install 2.4 instead of 2.1, I get less processes but I still get 2 redundant processes.:

    develop /home/two # ps -elf | grep -i sshguard
    0 S root      7328  2774  0  80   0 -   954 -      00:29 pts/0    00:00:00 /bin/sh /usr/sbin/sshguard
    1 S root      7329  7328  0  80   0 -   954 -      00:29 pts/0    00:00:00 /bin/sh /usr/sbin/sshguard
    0 S root      7339  5164  0  80   0 -   769 -      00:29 pts/1    00:00:00 grep --color=always -i sshguard
    
  3. Kevin Zheng

    I can’t tell what’s wrong with the openrc script just by looking. Can you figure out what openrc is checking when it reports SSHGuard as crashed? Some things to look for are how it reads the PID file, and how it compares the process name to the service name. This will be OS-dependent; you’ll have to check what your OS does.

    The “redundant process” is normal; /usr/sbin/sshguard is currently implemented as a shell script, and the last two lines require /bin/sh fork and spawn a subshell.

  4. Marc Elser

    The problem with the init-script is probably that @Darin Hensley as me too has enabled sshguard by integrating it with syslog-ng3 as described in the sshguard-setup documentation. If you do this sshgard get’s auto-started by syslog-ng and not by the init-script as syslog service gets started a lot earlier then the sshguard init script runs and probably already has logged messages until it reaches the init script and that auto-spawned sshguard prior to init-script and init-script is then complaining that sshguard is already running.

    I too would appreciate if I could use the init-script and defer auto-starting. And there’s an even bigger problem with the syslog-ng integration. I don’t know how to stop/start the daemon in this case. I think even if I send it a INT or TERM signal it will just re-spawn. So there’s more or less no possibility to really stop the daemon without removing/commenting syslog-ng configuration part and restart syslog-ng prior to stopping sshguard.

    I don’t know how this intended to work with an init-script but a start/stop possibility even if sshguard is integrated with syslog-ng would be highly appreciated. I would also appreicate if really start-stop-daemon would take care of starting/stopping/monitoring of the daemon instead of just a system call done by syslog-ng without proper process handling.

    I guess the easiest process is just to integrate syslog-ng differently (by a LOGREADER?) and not directly feed the messages to sshguard but have sshguard parse /var/log/messages but I don’t know if a LOGREADER statement can do it as Gentoo is openrc based and therefore no systemctl command is available. I also don’t know if there are any drawbacks by using a LOGREADER in comparison to directly have syslog-ng feed the messages to sshguard and what the LOGREADER statement would be in case of openrc.

    By now I also played around a lot with the init-script a lot and tried to make it somehow integrate with the previously started process by syslog-ng but it’s all a ugly hack and I would really prefer if sshguard is properly started by openrc and not by syslog-ng also adhering auto-start if service is enabled etc

    Do you have a different solution for this or any help with the LOGREADER statement?

  5. Kevin Zheng

    Sorry, I’m having trouble understanding the issue. Is it that it’s unclear how to use FILES or LOGREADER in sshguard.conf to control how SSHGuard behaves?

    As the documentation points out, SSHGuard should not be started by syslog as a filter. The right way to integrate SSHGuard is to write an init.d script that starts SSHGuard.

    There are lots of different init systems out there – unfortunately I don’t have experience with openrc.

  6. Log in to comment