formatting and simplifying page (remove unrelated stuff)

Fail2Ban-and-Docker.md

@@ -6,46 +6,36 @@ The idea that you want more server resources used just to accomplish what is a r
 
 **Changing the default chain to DOCKER-USER:**
 
-While this will protect your docker based software, it will leave any bare metal services wide open (i.e. SSH and often FTP). Again, bad idea.
+While this will protect your docker based software, it will leave any bare metal services wide open (i.e. SSH and often FTP). Again, bad idea (if you would not set the chain for every such a jail to INPUT).
 
 **The correct way to consider your server protection:**
 
-When you are running both bare metal and Docker based software, you should use the jail.local file to custom configure each jail independently. This way, not only can you provide a specific name for each chain (i.e. f2b-<name>), which will separate out the banned IP addresses, but you can also use the `chain = CHAINNAME` option to specify the IPTables chain in which it should reside.
+When you are running both bare metal and Docker based software, you should use the `jail.local` file to custom configure each jail independently. This way, not only can you provide a specific name for each chain (i.e. `f2b-<name>`, where by default `<name>` is name of jail), which will separate out the banned IP addresses depending on the used `banaction`, but you can also set the `chain` option to specify the chain of `iptables` or `nftables` in which it should reside.
 
-Let's look at SSH running on the host, and Apache running in a Docker container. Yes, I know I am specifying a very lengthy bantime, but I am a big fan of getting rid of attackers, instead of banning them for a short period of time and then potentially having them come back and try again. Modify these values however you wish. The only two items of note here are the banaction and chain entries.
+Let's look at SSH running on the host, and Apache running in a Docker container. The only items of note here are the `chain` entries.
 
 Remember, you can always manually unban an IP address across all jails with `fail2ban-client unban IPADDR`.
 
-Edit your /etc/fail2ban/jail.local file with the following entries:
+Edit your `/etc/fail2ban/jail.local` file with the following entries:
 
-```
+```ini
 [DEFAULT]
-banaction = iptables-allports[name=fail2ban]
-ignoreip = 127.0.0.1/8 ::1
-bantime = 8640000
-findtime = 3600
-maxretry = 3
-action = %(action_mwl)s
+chain = INPUT
 
-[apache]
+[apache-auth]
 enabled = true
-filter = apache-auth
-port = http,https
 logpath = /path/to/*error_log
-banaction = iptables-allports[name=apache]
 chain = DOCKER-USER
-action = %(action_mwl)s
 
 [sshd]
 enabled = true
-filter = sshd
-port = 22
-logpath = /var/log/auth.log
-banaction = iptables-allport[name=sshd]
-chain = INPUT
-action = %(action_mwl)s
+# chain = INPUT by default
+
+[pam-generic]
+enabled = true
+# chain = INPUT by default
 ```
 
-With this configuration, any IP that is banned due to Apache will be placed in the f2b-apache chain and that jump will be placed at the top of the DOCKER-USER chain. Likewise, any IP that is banned due to SSH will be placed in the f2b-sshd chain and that jump will be placed at the top of the INPUT chain.
+With this configuration, any IP that is banned due to Apache will be placed in the `f2b-apache-auth` chain and that jump will be placed at the top of the `DOCKER-USER` chain. Likewise, any IP that is banned due to SSH or PAM will be placed in the `f2b-sshd` or `f2b-pam-generic` chains and that jump will be placed at the top of the `INPUT` chain.
 
 Now you are directly protecting the services in which the attack is occurring, rather than trying to manage an all-in-one solution that will either tax your system resources OR not really offer you the protection you want/need.