[{"_1":2,"_153":-5,"_154":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_132":133},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_84":-5,"_85":86,"_125":-5,"_126":11,"_127":17,"_128":11,"_129":-5,"_130":131},"canonicalUrl","https://hub.docker.com/r/jonasal/fail2ban/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","jonasal","reponame","fail2ban","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":11,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2018-11-02T16:23:54.945904Z","description","A fail2ban container used to block network traffic destined for the Docker network.","is_private","last_updated","2020-03-17T11:12:28.148399Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",619,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# docker-fail2ban\n\nThis Alpine based Docker image runs [fail2ban][1] on the host's network with\nprivileges to edit the [iptables][4]. Create custom \"filters\" and \"jails\" to\nblock spam and brute-force attacks before they hit your other containers.\n\n> :information_source: This has been configured to block the spam from reaching\n containers that are using the normal **Docker network**, and not the **host**\n network. See full explanation under [Extensive Details](#extensive-details).\n\n> :warning: This container require a docker version greater than 17.06 to\n function without some [slight modifications][11]!\n\n> :warning: There is currently some compatibility issues with the new\n `nftables` and this container. Check out how to revert back to the old\n `iptables` [here](#nftables).\n\n\n\n# Acknowledgements and Thanks\n\nThis repository was forked from `@crazymax` to be able to modify it so that it\nworks with my setup, and to add some additional functionality. If you are\ninterested, [check out his][2] other Docker images.\n\n\n\n# Usage\n\n- Check out the [Jails, Filters, Actions & Logs](#jails-filters-actions-and-logs)\n section to understand how to create ban rules.\n- The [Good to Know](#good-to-know) section will highlight some behavior that\n you probably want to know about before starting.\n- The [Extensive Details](#extensive-details) section is long and rambly and\n used by me to remember all the intricate details that were necessary to\n figure out while designing this. Feel free to read if you want.\n- The [Changelog](#changelog) is at the bottom.\n\n\n## Available Environment Variables\n- `TZ`: The [timezone][13] assigned to the container (default: `Etc/UTC`)\n- `IPTABLES_CHAIN`: The [iptables CHAIN](#fail2ban-and-chains) used for\n attaching banned IP addresses to (default: `DOCKER-USER`)\n- `F2B_LOG_LEVEL`: Log level output (default: `INFO`)\n- `F2B_BAN_TIME`: How long a ban should last (default: `600` [i.e. 10 minutes])\n- `F2B_FIND_TIME`: Window of time to determine repeat offenders\n (default: `600` [i.e. 10 minutes])\n- `F2B_MAX_RETRY`: Number of failures before a host gets banned (default: `5`)\n- `F2B_DB_PURGE_AGE`: Age at which old bans should be purged from the database\n (default: `86400` [i.e. 24h])\n- `F2B_DEST_EMAIL`: Destination address to send\n [notification e-mails](#notification-mails) to\n (default: `root@localhost`)\n- `F2B_SENDER`: Sender e-mail address used by some actions\n (default: `fail2ban@$(hostname)`)\n- `F2B_ACTION`: Default [e-mail action](#notification-mails) on ban (default:\n `%(action_mw)s`)\n- `SSMTP_HOST`: SMTP server host\n- `SSMTP_PORT`: SMTP server port (default: `25`)\n- `SSMTP_HOSTNAME`: Full hostname (default: `fail2ban`)\n- `SSMTP_USER`: SMTP username\n- `SSMTP_PASSWORD`: SMTP password\n- `SSMTP_TLS`: SSL/TLS (default: `YES`)\n\n\n## Volumes\n- `/fail2ban_db` : Contains fail2ban's database of previous bans\n\n\n## Run with `docker run`\nWhen launching this container as a stand-alone instance, I would probably use\nhost mounted folders to make data persistent and shared between services. The\nfollowing two commands will facilitate that:\n\n```bash\ndocker build --tag jonasal/fail2ban:local .\ndocker run -d --network host --cap-add NET_ADMIN --cap-add NET_RAW \\\n -v $(pwd)/shared/logs:/xlogs \\\n -v $(pwd)/persistent/db:/fail2ban_db \\\n -v $(pwd)/data:/data \\\n --name fail2ban jonasal/fail2ban:local\n```\n\n\n## Run with `docker-compose`\nDocker-Compose is my preferred way to run this image. See the example of a\ncompose file inside the `examples/` folder, and you may use the `fail2ban.env`\nfile to define all the variables in a separate location. Then it can all be\nlaunched via the following commands:\n\n```bash\ndocker-compose build --pull\ndocker-compose up\n```\n\n\n\n# Jails, Filters, Actions and Logs\n\nFail2ban issues bans by scanning through [log files](#logs) to find a regex\npattern (see [filters](#filters)) which indicates that some IP has performed,\nfor example, a failed login attempt. If these failed attempts continue it may\nbe because of a brute-force attack, and fail2ban will then perform the\ndefined \"[`ban action`](#actions)\" to stop this. The default action is that\nfail2ban will store the offending IP in its database before adding a rule to\nthe `iptables` which block any further communication with that peer.\n\nSo for this service to be useful you will first need another service that\nproduce a log file that fail2ban can monitor for suspicious behavior. In the\nrest of this section I will use a basic example with [Nextcloud][12] as the\nservice to protect, and it will output any login attempts to the file\n`nextcloud.log`. How this log is made readable from another container is\nexplained further in the [Logs](#logs) section, but for now we will just say\nthat it is located at `/xlogs/nextcloud.log` in the `fail2ban` container.\n\n## Custom Jails, Actions and Filters\nAny custom jails, actions or filters, that are created by the user, should be\nmounted/copied into the container under the following folder locations:\n\n- `/data/jail.d/`\n- `/data/action.d/`\n- `/data/filter.d/`\n\nFiles found in these folders will be symlinked over to the corresponding\nfail2ban folders, under `/etc/fail2ban/<...>`, at startup of this container. If\nyou add a custom file that has the exact same name as a file which exist at\none of those locations, the destination file will be overwritten by the custom\none while a message is printed in the log notifying you about it.\n\n### Jails\nJail files allows you to tailor the ban settings for each individual service\nbeing monitored. Create a new `jail` file called `nextcloud.conf` in\n[`/data/jail.d/`](#custom-jails-actions-and-filters):\n\n```\n[nextcloud]\nenabled = true\nfilter = ncFilter\nlogpath = /xlogs/nextcloud.log\n```\n\nThese are the minimal amount of settings that are needed to be defined, and\nanything else will use the [default values][17].\n\n> NOTE: The default values may also be changed via the environment variables\n `F2B_BAN_TIME`, `F2B_FIND_TIME` and `F2B_MAX_RETRY`.\n\n\n### Filters\nIn the config file above we defined that this jail should use a custom filter,\ncalled `ncFilter`, when monitoring the Nextcloud log file. This \"filter\" is\nanother file which will contain the regex(s) used to identify what lines in the\nlog file that should be identified as failed login attempts. Fail2ban expects\nto find this filter inside `/etc/fail2ban/filter.d/`, so if this is not a\n\"default\" filter the file `ncFilter.conf` needs to be created and copied into\nthe [`/data/filter.d/`](#custom-jails-actions-and-filters) folder.\n\nA usable filter for the Nextcloud service might look something like this:\n\n```\n[Definition]\nfailregex=^.*Login failed: '.*' \$Remote IP: ''\$.*$\n```\n\nThis regex will then trigger on any line that looks like this:\n\n```\n2019-05-18T14:44:45Z Random text. Login failed: 'whatever' (Remote IP: '192.168.0.1') More text\n```\n\nHere the `` parameter is the most important thing, as this is the IP\nwhich will be added to the `iptables` when a ban is handed out.\n\nCheck out [Log File Layout](#log-file-layout) section for additional notes\nabout some interesting limitations imposed on log file's format, and the\n[official manual][14] for more info about the regex options.\n\n### Actions\nThe default action taken, when fail2ban identifies an IP that need to be\nbanned, is defined in the file `/etc/fail2ban/jail.conf` on the following line:\n\n```\nbanaction = iptables-multiport\n```\n\nThis means that it is the instructions that are found in the file\n`/etc/fail2ban/action.d/iptables-multiport.conf` that will be followed in order\nto properly add the correct rules to the `iptables`.\n\nThis can be changed for each individual jail, but this will most likely be\nbetter to define on a more \"global\" scale in the main `jail.conf` file. However,\nunless you are running some alternative firewall program (like `firewalld`,\n`shorewall` or [`nftables`](#nftables)) you will not need to edit this.\n\n> NOTE: The environment variable `F2B_ACTION` allows you define what \"action\"\n the [mail program](#notification-mails) will make when you need to be\n notified about something. This is not directly related to \"`banaction`\",\n so the naming is a bit unfortunate.\n\n\n\n## Logs\nUp till now we have assumed that the `fail2ban` container had easy access to the\nlog files of interest. However, in an environment with many other containers,\nwhich are running a single service each, we must design a method that can be\nused by all of these to share their logs so they are readable by our `fail2ban`\ncontainer.\n\nThe most simple and straight forward method is to use a host mounted folder,\nwhere you later configure all external services to place their log files.\nHowever, it is also possible to use a `named volume`, which might be preferred\nif you are using `docker-compose`.\n\nInside the container running Nextcloud you need to mount the named volume\n`log_collector`, or whatever name you give it, and make sure the Nextcloud\nservice place its logs inside this. This volume is then mounted at `/xlogs` in\nthe fail2ban container, which is where it expects to find the log file since\n`logpath = /xlogs/nextcloud.log` is defined inside the jail config file. This\nway multiple services' logs can be observed from a single `fail2ban` container.\nThe only issue is that this requires the folder/volume to be writable by all of\nthe monitored services, which often means that you have to set the `777`\npermission on this folder.\n\nA `docker-compose` file for this may look something like this:\n```yaml\n.\n.\n.\n nextcloud:\n build: ./nextcloud\n restart: unless-stopped\n volumes:\n - nextcloud_www:/var/www/html\n - nextcloud_data:/var/nc_data\n - log_collector:/log/path\n depends_on:\n - fail2ban\n\n fail2ban:\n build: ./fail2ban\n restart: unless-stopped\n network_mode: \"host\"\n cap_add:\n - NET_ADMIN\n - NET_RAW\n volumes:\n - log_collector:/xlogs\n\nvolumes:\n nextcloud_data:\n nextcloud_www:\n log_collector:\n```\n\n\n\n# Good to Know\n\n## Use the fail2ban-client\n[Fail2ban commands][3] can be given to the container directly if so desired.\nHere is an example if you want to ban an IP manually:\n\n```bash\ndocker exec fail2ban-client set banip \n```\n\nIf you want to manually un-ban someone this can be executed:\n\n```bash\ndocker exec fail2ban-client set unbanip \n```\n\n\n## Log File Layout\nThe [documentation][14] states that the log files that are parsed needs to have\na timestamp in the beginning of the line. This is a built in functionality of\nfail2ban, and **cannot** be changed. If a regex is created with a `^`, i.e.\n\"at the beginning of the line\", then the anchor actually refers to the start of\nthe **remainder** of the line, _after_ the preceding timestamp and intervening\nwhitespace.\n\nIf fail2ban is unable to interpret the timestamp in the beginning it will tell\nyou so in its output, and then you have two options:\n- Reconfigure your daemon to log with a timestamp in a more common format.\n- File a [bug report][18] to fail2ban asking to have your timestamp format\n included.\n\nHowever, since this functionality is still undocumented for the users, trial and\nerror has shown it is [not always necessary][15] for the timestamp to be at the\nbeginning of the line, if you allow for some wildcard expansion in the regex.\nFor example: in the Nginx log format it will be able to find the timestamp if\nit looks something like this:\n\n```\n1.2.3.4 - - [19/May/2019:08:52:51 +0000] \"GET / HTTP/1.1\" 200 1100 ....\n```\n\nWith the following filter:\n\n\n```\nfailregex = ^ -.*\n```\n\n\n## Missing Log Files\nIf a log file is defined in a `jail`, but the service that produce this file\nhas not started yet, fail2ban will crash since it lacks error handling in\nthe case where files are missing. I have therefore created the functionality\nwhere the startup script will monitor the file paths of the logs defined in\nevery `jail` config, and disable them until the target file shows up. This then\nenables the `jails` again and reloads fail2ban when the missing log files\nshows up.\n\n\n## Notification Mails\nFail2ban can send mail through the `sendmail` program. By default it sends a\nmail every time the server starts, a jail starts and a ban is issued. This got\na bit annoying so anything else than mails regarding bans issued has been\n[shut off][9] by setting the two variables `actionstart` and `actionstop`,\ninside `/etc/fail2ban/action.d/sendmail-common.local`, to empty strings. This\nis done by a function inside the `util.sh` script, but the original\nfunctionality can be restored by including a completely empty\n`sendmail-common.local` file as a custom \"action\" in the\n[`/data/action.d/`](#custom-jails-actions-and-filters) folder.\n\nIf no external mail provider is specified (check out the `fail2ban.env` file\nfor an example with Gmail), all mail will be directed to `root@localhost:25`.\nThis way you should be able to read any mails by simply typing `mail` (or\n`sudo mail`) in you host machine's terminal.\n\nThe content of these mails are regulated by the string that is assigned to the\nenvironment variable `F2B_ACTION`. If you are using the \"sendmail\" program there\nare currently four different options available for you, and they point to\nspecific files that should be run when sending a mail. The options are:\n\n- `action_`: action.d/[**sendmail**.conf][19]\n- `action_mw`: action.d/[**sendmail-whois**.conf][20]\n- `action_mwl`: action.d/[**sendmail-whois-lines**.conf][21]\n- ` `: _Don't send any mails_\n\nIf you enter a blank line no mails will be sent, and the contents of the other\nones can be observed by following the links to their source files.\n\n\n\n# Extensive Details\n\nIf you are really interested in how this container works I welcome you into this\nsection. However, I try to write down as many details I can, in order to be able\nto come back to this code in a couple of years time and understand why I did\nwhat I did. So it might be a bit rambly at some places.\n\n\n## Iptables and Chains\nIptables are, as the name suggests, tables of rules deciding how internet data\npackets shall be routed inside the computer. In these tables there are, by\ndefault, five **CHAINS**:\n\n- `PREROUTING`\n- `INPUT`\n- `FORWARD`\n- `OUTPUT`\n- `POSTROUTING`\n\nI really like [this post][6], about how a packet is routed around inside these\nchains, but to summarize you may say that first `PREROUTING` decides if the\nincoming packet should be handed over to either `INPUT`, `FORWARD` or `OUTPUT`.\nInside these three chains you usually apply rules that only affect the packets\nwho have to go through them. For example you may want to block all incoming\nconnections to port 22, which is SSH, in which case you may add a DROP rule from\nall IP addresses going to port 22 inside the `INPUT` chain. However, you also\nwant to be able to connect to another computer, from your current one, over SSH\nso therefore you allow any IP going to port 22 in the `OUTPUT` chain.\nThis way you may split up rules in an easy way so they do not conflict with\neach other. Finally some `POSTROUTING` is made before the packets are sent on\ntheir way again.\n\n\n## Docker ≥ 17.06 and Chains\nAs mentioned above, the `PREROUTING` chain is allowed to divide the incoming\ntraffic into three different \"sub-chains\" depending on what classification it\nsets on the data packet. In a similar manner you can actually split traffic\ninside these \"sub-chains\" into further \"sub-sub-chains\" for even finer control\nof what should happen to the packets.\n\nThis is actually what the Docker service does, by attaching a `DOCKER`\nchain onto the `FORWARD` chain. If you have the Docker service running you\nshould be able to see these chains if you run the following command on your\nhost:\n\n```bash\nsudo iptables -nL\n```\n\nMore detailed information can also be obtained trough following command:\n\n```bash\nsudo iptables -t nat -nL --line-numbers\n```\n\nIn this chain any rule set by the Docker service would end up. What is good\nwith this is that packets would only end up here if they were destined for a\nDocker container in the first place. This way the rules set here could be easily\nformulated without affecting the rest of the host system's internet connection.\n\nHowever, as this chain is modified automatically by the Docker service, you\nwould not have much luck setting custom rules you wanted to be persistent there.\nLuckily, in a [pull request][5] leading up to the 17.06 release of Docker, there\nwere new features added to the `iptables` that are created by the Docker\nservice. It introduced a new chain called `DOCKER-USER` which will be placed\nbefore the normal `DOCKER` chain. This is empty by default and will not be\ntouched by Docker at all, since it is [intended][7] to be used for custom user\ndefined rules.\n\n\n## fail2ban and Chains\nFail2ban creates one unique chain for every `jail`/service defined, in order\nto easily divide different rules for different services. This way you may have a\nspecific IP banned for one web service while it is allowed to access another.\n\nNevertheless, what is important to know is that these fail2ban chains are, by\ndefault, attached to the `INPUT` chain of the host. This is desired if the\nservices you are trying to protect are running directly on the host, since those\npackets will be directed to the `INPUT` chain by the `PREROUTING` rules.\nHowever, when you are running your services inside Docker containers they will\nusually reside inside the **Docker network** (unless you specify them to use\nthe **host** network). As mentioned [above](#docker--1706-and-chains), packets\ndestined for the Docker network instead gets routed through the `FORWARD` chain\nby `PREROUTING`, and the fail2ban rules present in `INPUT` will be completely\nbypassed if nothing is done to combat this.\n\nTo remedy this I configure fail2ban to attach its chains to the `DOCKER-USER`\nchain instead of `INPUT`, by default, as that chain is specifically created for\nuser defined rules that are meant to be applied to the containers located in\nthe Docker network. In the startup script this is done by editing a single line\nin the file `/etc/fail2ban/action.d/iptables-common.conf` to instead use the\nvalue from the environment variable `IPTABLES_CHAIN` mentioned in the\n[beginning](#available-environment-variables) of this README.\n\nUnfortunately this means that any packets now coming in to the `INPUT` chain\nwill bypass these rules that now reside under the `FORWARD` chain. If you have\nservices running on your **host's network** you could just spin up an additional\ncontainer of fail2ban and set `IPTABLES_CHAIN=INPUT` for that one.\n\nFor an even more advanced method, where you would only need one container to\nblock traffic for both `INPUT` and `FORWARD`, continue reading the next section\n[below](#custom-chains).\n\n\n## Custom Chains\nWhen I designed this container I only use chains I know will exist on all\ncomputers, so other people can use this without too much tinkering. But, as\nstated in the section [above](#fail2ban-and-chains), the problem remain where\nfail2ban only affects either the **host's network**, by applying rules to\n`INPUT`, or only the **Docker network** by applying them to `DOCKER-USER`.\n\nHowever, in my research I stumbled upon a guide that seems to create a\ncompletely new `FILTER` chain that resides right after `PREROUTING`, but at the\nsame time before the other chains. This new chain then becomes responsible for\nthe task of splitting the traffic into `INPUT` or `FORWARD`, which means that\nany rules applied to `FILTER` will affect both of these following chains.\n\nThis sounds nice, but there is some extra manual labor required by the user to\nmake this work as intended. You may have a [look at the guide][8] if you want\nto experiment with this, just remember change chain name in the\n`IPTABLES_CHAIN` variable afterwards.\n\n\n## Older Docker Versions\nIf you have an older version of Docker, and you desperately need this to work\nwithout upgrading, you may just change the `IPTABLES_CHAIN=DOCKER-USER`\nenvironment variable to `IPTABLES_CHAIN=FORWARD` instead.\n\nThis should make all the fail2ban rules come before any Docker rules and the\neffect [should be the same][10] as having them in the `DOCKER-USER` chain.\nHowever, remember that these bans now apply to **ALL** forwarded traffic.\nUsually this will not cause any problems, in a home server, but might be\nproblematic in other cases.\n\n\n## `nftables`\nI have not yet had time to go into detail on how to use the new `nftables`\nwith fail2ban inside Docker, so for now I have just reverted to use the old\nlegacy `iptables`. I used this guide for [Debian Buster][16], where you have\nto run the following commands as root:\n\n```\nupdate-alternatives --set iptables /usr/sbin/iptables-legacy\nupdate-alternatives --set ip6tables /usr/sbin/ip6tables-legacy\nupdate-alternatives --set arptables /usr/sbin/arptables-legacy\nupdate-alternatives --set ebtables /usr/sbin/ebtables-legacy\n```\n\nAfter this it is necessary to reboot so that all services start using the\nlegacy settings again. This solved the problem where fail2ban would output\nthe following error messages:\n\n```\nstderr: 'iptables: No chain/target/match by that name.'\nreturned 1\n```\n\n\n\n# Changelog\n\n### 0.11.1.1-Beta1 (2020-03-16)\n\n* Upgrade Alpine to v3.11\n* Upgrade fail2ban to [v0.11.1][23]\n * New schema in the database, downgrades are therefore not supported.\n * Not all ban actions are IPv6-capable (not really relevant since this\n container does not yet support IPv6).\n* Complete overhaul of the folder structure in the repository.\n* Update examples.\n\n### 0.10.4.4-Beta1 (2020-03-16)\n\n* Fix troublesome sender domain ([Bug report][22]).\n* Add `IPTABLES_CHAIN` environment variable.\n* Move the creation of [`sendmail-common.local`](#notification-mails) in to a\n function in `util.sh` instead of copying a file.\n* Update documentation.\n\n### 0.10.4.3-Beta2 (2020-03-15)\n\n* Add check to make sure all referenced `filter`s are present at startup.\n* Rewrite the `config_watcher` function, to utilize the shared mutex better.\n* Add the `--optimize=2` flag when installing Fail2ban.\n* Make clarifications to previous entries in the changelog.\n\n### 0.10.4.3-Beta1 (2020-03-13)\n\n* Move over fully to Python 3.\n* Include `pyinotify` backend to allow being notified about logfile changes\n instead of polling.\n* Include `dnspython3` pip package to allow fail2ban to print more info about\n the banned IPs.\n* Fix HEALTCHECK command.\n\n### 0.10.4.2-Beta2 (2020-03-13)\n\n* Make so that `jails`, `actions` and `filers` are instead symlinked in from\n `/data/...`\n* Fix the `auto_enable_jail` functionality for multiple files and make so it\n handles symlinks.\n* Reduce the number of build steps in the Dockerfile.\n* Add information about incompatibility with `nftables`.\n* Make better comments in the code.\n\n### 0.10.4.2-Beta1 (2019-05-19)\n\n* Refactor basically all the code.\n* Create the `auto_enable_jail` functionality.\n* Include colored output.\n* More input parameters.\n* A ton more documentation.\n\n### 0.10.4.1-Beta2 (2018-11-02)\n\n* Remove `wget`.\n* Update the documentation.\n* This container is now available on Docker Hub under `jonasal/fail2ban`.\n* Include a Makefile with some nice commands.\n\n### 0.10.4.1-Beta1 (2018-11-02)\n\n* `@JonasAlfredsson` forks the repository.\n* Make fail2ban attach to the `DOCKER-USER` chain in the iptables.\n* Make the mailing functionality send to the right location.\n* Refactor the entrypoint.sh script.\n* Refactor the Dockerfile.\n* Remove unused files and refactor folder structure.\n* Much more documentation.\n\n### 0.10.4-RC3 (2018-10-06)\n\n* Add whois (Issue #6).\n\n### 0.10.4-RC2 (2018-10-05)\n\n* Allow to add custom actions and filters through `/data/action.d` and\n `/data/filter.d` folders (Issue #4).\n* Relocate database to `/data/db` and jails to `/data/jail.d` (breaking change,\n see README.md).\n\n### 0.10.4-RC1 (2018-10-04)\n\n* Upgrade to Fail2ban 0.10.4\n\n### 0.10.3.1-RC4 (2018-08-19)\n\n* Add curl (Issue #1).\n\n### 0.10.3.1-RC3 (2018-07-28)\n\n* Upgrade based image to Alpine Linux 3.8.\n* Unset sensitive vars.\n\n### 0.10.3.1-RC2 (2018-05-07)\n\n* Add mail alerts configurations with SSMTP.\n* Add HEALTHCHECK command.\n\n### 0.10.3.1-RC1 (2018-04-25)\n\n* Initial version based on Fail2ban 0.10.3.1\n\n\n\n\n\n\n[1]: https://www.fail2ban.org\n[2]: https://hub.docker.com/r/crazymax/\n[3]: http://www.fail2ban.org/wiki/index.php/Commands\n[4]: https://en.wikipedia.org/wiki/Iptables\n[5]: https://github.com/docker/libnetwork/pull/1675\n[6]: https://askubuntu.com/a/579242\n[7]: https://docs.docker.com/network/iptables/\n[8]: https://unrouted.io/2017/08/15/docker-firewall/\n[9]: https://serverfault.com/questions/257439/stop-fail2ban-stop-start-notifications\n[10]: http://blog.amigapallo.org/2016/04/14/configuring-fail2ban-and-iptables-to-get-along-with-docker/\n[11]: https://github.com/JonasAlfredsson/docker-fail2ban#older-docker","has_starred","hub_user","immutable_tags_settings",{"_71":11,"_72":73},"enabled","rules",[74],".*","is_automated","permissions",{"_78":17,"_79":11,"_80":11},"read","write","admin","user","storage_size",270581751,"orgData","recentTags",[87],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":96,"_46":114,"_115":90,"_116":29,"_117":52,"_53":118,"_119":120,"_121":105,"_122":114,"_123":62,"_124":17},"content_type","creator",4300186,"full_size",20810567,"id",39098929,"images",[97],{"_98":99,"_100":101,"_102":103,"_104":105,"_106":107,"_108":109,"_110":103,"_111":-5,"_112":92,"_59":62,"_113":-5},"architecture","amd64","digest","sha256:af3181fe5c09cc3dcfe4782ae49e5a9136bd67aaa8108e613c4ccf04e4803c38","features","","last_pulled","2026-09-17T19:16:59.594344193Z","last_pushed","2020-03-17T11:12:28Z","os","linux","os_features","os_version","size","variant","2020-03-17T11:12:27.776503Z","last_updater","last_updater_username","media_type","latest","repository",6236648,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":134,"_141":142,"_130":151,"_152":11},{"_36":135,"_38":136,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":137,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":138,"_75":11,"_76":140,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":139},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_143":60,"_144":-5,"_145":-5,"_146":147},"count","next","previous","results",[148],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":149,"_46":114,"_115":90,"_116":29,"_117":52,"_53":118,"_119":120,"_121":105,"_122":114,"_123":62,"_124":17},[150],{"_98":99,"_100":101,"_102":103,"_104":105,"_106":107,"_108":109,"_110":103,"_111":-5,"_112":92,"_59":62,"_113":-5},[],"canDeleteTags","actionData","errors"]

jonasal/fail2ban

Tags for jonasal/fail2ban