https://github.com/ianblenke/docker-fail2ban

A systemd aware fail2ban that can be run as a docker container
https://github.com/ianblenke/docker-fail2ban

Last synced: about 1 month ago
JSON representation

A systemd aware fail2ban that can be run as a docker container

• Host: GitHub
• URL: https://github.com/ianblenke/docker-fail2ban
• Owner: ianblenke
• Created: 2014-09-18T17:20:53.000Z (about 10 years ago)
• Default Branch: master
• Last Pushed: 2015-02-04T03:35:56.000Z (almost 10 years ago)
• Last Synced: 2024-08-02T12:51:21.715Z (4 months ago)
• Language: Shell
• Size: 141 KB
• Stars: 5
• Watchers: 3
• Forks: 1
• Open Issues: 1
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

• awesome-starred - ianblenke/docker-fail2ban - A systemd aware fail2ban that can be run as a docker container (others)

README

        

NOTE: If you want something that works with CoreOS, check out [blackhole.cloud-init](https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blob/master/tested/blackhole.cloud-init)

This was an attempt at getting fail2ban to run as a docker container on a coreos host to watch the systemd journal and somehow react to block ssh scanner attacks.

_This does not presently work._

While there is a backend=systemd, it assumes that it can talk to a local running systemd, which doesn't help a docker container talk to the host it is running on.

There is an attempt here to map the CoreOS systemd /run/systemd directory tree to the docker container's /var/run/systemd via volume mount, primarily for /run/systemd/journal/stdout, /run/systemd/journal/socket, and /run/systemd/journal/dev-log

The sad reality is that systemd makes rapid breaking changes between point releases that essentially mandate that the EXACT SAME version of systemd client be used to talk to whatever version of systemd services are exposing those sockets.

As CoreOS alpha/beta/stable are moving targets and as systemd itself is tenuous to track this way from inside a container, it might actually be necessary to build systemd from source at docker image runtime to accomplish this feat.

Moreover, I will not pretend to be a systemd expert. What I've said above could be total lies based on some basic misunderstanding on my part.

So consider this a "work in progress". Know that it presently does not work, but that I am actively looking for a solution to this problem as well.

Also know that I have the same pain as you here: blocking dumb ssh scanners from walking CoreOS hosts.