Go to file
2023-05-05 12:53:10 +02:00
app Working communication code using socket 2023-05-04 01:02:05 +02:00
config Untested cli/daemon communication code 2023-05-03 20:03:22 +02:00
logo order 🧹 2023-04-26 17:11:03 +02:00
reaction Standardize go project structure 2023-05-05 12:53:10 +02:00
reactionc Standardize go project structure 2023-05-05 12:53:10 +02:00
.gitignore Standardize go project structure 2023-05-05 12:53:10 +02:00
default.nix Standardize go project structure 2023-05-05 12:53:10 +02:00
go.mod Update project info 2023-05-05 12:43:57 +02:00
go.sum Update project info 2023-05-05 12:43:57 +02:00
LICENSE Add AGPL LICENSE 2023-04-11 11:03:50 +00:00
README.md update readme 2023-05-05 10:06:34 +02:00

reaction

🚧 this program has not been tested in production yet 🚧

a program that scans program outputs, such as logs, for repeated patterns, such as failed login attempts, and takes action, such as banning ips.

(adapted from fail2ban's presentation 😄)

rationale

i was using fail2ban since quite a long time, but i was a bit frustrated by it's cpu consumption and all its heavy default configuration.

in my view, a security-oriented program should be simple to configure (sudo is a very bad exemple!) and an always-running daemon should be implemented in a fast language.

configuration

this configuration file is all that should be needed to prevent bruteforce attacks on an ssh server.

/etc/reaction.yml

definitions:
  - &iptablesban [ "iptables" "-w" "-I" "reaction" "1" "-s" "<ip>" "-j" "block" ]
  - &iptablesunban [ "iptables" "-w" "-D" "reaction" "1" "-s" "<ip>" "-j" "block" ]

patterns:
  ip: '(([0-9]{1,3}\.){3}[0-9]{1,3})|([0-9a-fA-F:]{2,90})'

streams:
  ssh:
    cmd: [ "journalctl" "-fu" "sshd.service" ]
    filters:
      failedlogin:
        regex:
          - authentication failure;.*rhost=<ip>
        retry: 3
        retry-period: 6h
        actions:
          ban:
            cmd: *iptablesban
          unban:
            cmd:  *iptablesunban
            after: 2d

/etc/systemd/system/reaction.service

[Unit]
WantedBy=multi-user.target

[Service]
ExecStart=/path/to/reaction -c /etc/reaction.yml

ExecStartPre=/path/to/iptables -w -N reaction
ExecStartPre=/path/to/iptables -w -A reaction -j ACCEPT
ExecStartPre=/path/to/iptables -w -I reaction 1 -s 127.0.0.1 -j ACCEPT
ExecStartPre=/path/to/iptables -w -I reaction 1 -s ::1 -j ACCEPT
ExecStartPre=/path/to/iptables -w -I INPUT -p all -j reaction

ExecStopPost=/path/to/iptables -w -D INPUT -p all -j reaction
ExecStopPost=/path/to/iptables -w -F reaction
ExecStopPost=/path/to/iptables -w -X reaction

StateDirectory=reaction
WorkingDirectory=/var/lib/reaction

See reaction.service and reaction.yml for the fully commented examples.

database

the working directory of reaction will be used to create and read from the embedded database. if you don't know where to start it, /var/lib/reaction should be a sane choice.

terminology

  • streams are commands. they're run and their ouptut is captured. example: tail -f /var/log/nginx/access.log
    • filters belong to a stream. they run actions when they match regexes.
      • regexes are regexes. example: login failed from user .* from ip <ip>
        • patterns are also regexes. they're inserted inside regexes. example: ip: ([0-9]{,3}.)[0-9]{,3}
      • actions are commands. example: ["echo" "matched <ip>"]

compilation

$ go build .