-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request about fail2ban running at Host level + many LXC containers with unique IP address + interface alias pairs #1470
Comments
Maybe using firewallcmd-ipset.conf in some way. |
Hum... This seems to work... Some let me know if this might be correct...
[lxc-sshd] |
I suppose the host /var/log/auth.log can go into the same logpath too. |
Once again fail2ban saves the day! |
Well, this doesn't work, because firewalld produces all manner of gnarliness, including flushing all NAT rules, which destroys all LXC communication paths, so back to the drawing board. |
Created new actions similar to iptables-* but with altered definition of |
Well, in my configuration I didn't want to run fail2ban with all dependencies, and also postfix with all dependencies, inside each container. If you want to ban IP on all containers simultaneously, you can do it by enumerating them with lxc-ls and xargs. Also, I don't think stopped container can generate fail2ban events. And you can achieve portability with includes. Don't get me wrong, I'd prefer a method of blocking incoming IPs on host, it's just that like you I didn't find one. Probably because the software switch on host is just that -- an L2 switch -- and it doesn't analyze L3 IP addresses at all. There's always an option of blocking IP addresses on some upstream router or nat, though. |
Just reading updates to this ticket + resolution I'm using matches suggestions. If found running fail2ban inside each container seems best. This allows custom fail2ban rules for each container's site(s). All clients sites are extremely high traffic sites, so Bot Blocking has a high priority. Different instances of custom fail2ban rules.
Running fail2ban at host level means a single set of rules, so no way to offer clients custom rulesets. Likely best approach is to always run fail2ban inside container with customer site(s) rules. |
Hello, Could you please indicate more precisely the different sections to be modified and in which files? Thank you for your help. |
Please write what you tried and what happened, otherwise it's going to be hard for me to help you.
Here's one example, for postfix service in container [DEFAULT]
action_mlw_lxc = iptables-multiport-lxc[name=%(__name__)s, container="%(container)s", bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-lines-whois[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s"]
[postfix]
enabled = true
port = 25,465,587
logpath = /mnt/vars/postfix/log/mail.log
container = postfix
action = %(action_mlw_lxc)s Note The only difference of /etc/fail2ban$ diff -aur ./action.d/iptables-multiport{,-lxc}.conf
--- /etc/fail2ban/action.d/iptables-multiport.conf 2015-08-01 01:32:13.000000000 +0000
+++ /etc/fail2ban/action.d/iptables-multiport-lxc.conf 2016-07-05 16:26:48.367934705 +0000
@@ -6,7 +6,7 @@
[INCLUDES]
-before = iptables-common.conf
+before = iptables-common-lxc.conf
[Definition] And the only difference of --- /etc/fail2ban/action.d/iptables-common.conf 2015-08-01 01:32:13.000000000 +0000
+++ /etc/fail2ban/action.d/iptables-common-lxc.conf 2016-07-05 16:26:40.599993044 +0000
@@ -10,7 +10,7 @@
[INCLUDES]
after = iptables-blocktype.local
- iptables-common.local
+ iptables-common-lxc.local
# iptables-blocktype.local is obsolet
[Init]
@@ -61,4 +61,5 @@
# Option: iptables
# Notes.: Actual command to be executed, including common to all calls options
# Values: STRING
-iptables = iptables <lockingopt>
+iptables = lxc-attach -n <container> -- iptables <lockingopt> ( |
@qm2k I modified the "iptables" command to handle the case when the container is off. I think my modifications are improvable but for now, with the basic SSH rule, it works. I will test with Postfix as you have shown but I am very excited in advance. Here are my modifications for those who might be interested:
[DEFAULT]
action_lxc = iptables-multiport-lxc[name=%(__name__)s, conteneur="%(conteneur)s", bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mlw_lxc = iptables-multiport-lxc[name=%(__name__)s, conteneur="%(conteneur)s", bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-lines-whois[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s"]
[postfix]
enabled = false
port = 25,465,587
logpath = /mnt/vars/postfix/log/mail.log
conteneur = postfix
action = %(action_mlw_lxc)s
[sshd-lxc-web]
enabled = true
port = ssh
conteneur = lxc-web
logpath = /var/lib/lxc/%(conteneur)s/rootfs/var/log/auth.log
action = %(action_lxc)s
maxretry = 2
ignorecommand =
bantime = 10m
findtime = 10m
filter = sshd-lxc
[sshd-lxc-mail]
enabled = true
port = ssh
conteneur = lxc-mail
logpath = /var/lib/lxc/%(conteneur)s/rootfs/var/log/auth.log
action = %(action_lxc)s
maxretry = 2
ignorecommand =
bantime = 10m
findtime = 10m
filter = sshd-lxc
--- /etc/fail2ban/action.d/iptables-common.conf 2020-02-19 21:12:19.161146756 +0100
+++ /etc/fail2ban/action.d/iptables-common-lxc.conf 2020-02-20 20:14:59.012165630 +0100
@@ -73,7 +73,8 @@
# Option: iptables
# Notes.: Actual command to be executed, including common to all calls options
# Values: STRING
-iptables = iptables <lockingopt>
+iptables = bash -c "if [ $(lxc-info -n <conteneur> -s -H) == RUNNING ]; then lxc-attach -n <conteneur> -- iptables <lockingopt>
+iptablesfi = fi"
[Init?family=inet6] As you can see, I had to use some tricks to make sure that there are no errors when applying an F2B rule when an LXC container is switched off. I adapt this trick in the multiport file to close the "if" structure: --- /etc/fail2ban/action.d/iptables-multiport.conf 2018-01-18 14:49:01.000000000 +0100
+++ /etc/fail2ban/action.d/iptables-multiport-lxc.conf 2020-02-20 18:03:11.276776368 +0100
@@ -6,7 +6,7 @@
[INCLUDES]
-before = iptables-common.conf
+before = iptables-common-lxc.conf
[Definition]
@@ -14,23 +14,23 @@
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
-actionstart = <iptables> -N f2b-<name>
- <iptables> -A f2b-<name> -j <returntype>
- <iptables> -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
+actionstart = <iptables> -N f2b-<name>; <iptablesfi>
+ <iptables> -A f2b-<name> -j <returntype>; <iptablesfi>
+ <iptables> -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>; <iptablesfi>
# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
-actionstop = <iptables> -D <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
- <actionflush>
- <iptables> -X f2b-<name>
+actionstop = <iptables> -D <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>; <iptablesfi>
+ <actionflush>; <iptablesfi>
+ <iptables> -X f2b-<name>; <iptablesfi>
# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
-actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'
+actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'; <iptablesfi>
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
@@ -38,7 +38,7 @@
# Tags: See jail.conf(5) man page
# Values: CMD
#
-actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
+actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>; <iptablesfi>
# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
@@ -46,7 +46,7 @@
# Tags: See jail.conf(5) man page
# Values: CMD
#
-actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>
+actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>; <iptablesfi>
[Init] However, it should be noted that the "actionstop" action does not seem to work. Each time the fail2ban service is restarted, a new "multiport dports 22" rule identical to the others is added to the "INPUT" chain. I will dig into this... If you notice anything out of the ordinary about the way I do things, please do not hesitate to report it. I'm sure it will help someone (there are few results on this subject). Encore merci ! |
You reminded me about one important detail: something needs to create iptables rule chain
Cool, I was too lazy to do it and prefer to simply ignore error messages. [ $(lxc-info -n <conteneur> -s -H) != RUNNING ] || lxc-attach -n <conteneur> -- iptables <lockingopt>
I didn't notice this problem here. First thing to check is fail2ban logs where output from all action commands is redirected. |
Thank you for your response.
I used your modification on my condition and it's working wonders 👍. --- /etc/fail2ban/action.d/iptables-common.conf 2020-02-19 21:12:19.161146756 +0100
+++ /etc/fail2ban/action.d/iptables-common-lxc.conf 2020-02-21 14:48:58.081002546 +0100
@@ -73,7 +73,7 @@
# Option: iptables
# Notes.: Actual command to be executed, including common to all calls options
# Values: STRING
-iptables = iptables <lockingopt>
+iptables = [ $(lxc-info -n <conteneur> -s -H) != RUNNING ] || lxc-attach -n <conteneur> -- iptables <lockingopt>
[Init?family=inet6] --- /etc/fail2ban/action.d/iptables-multiport.conf 2018-01-18 14:49:01.000000000 +0100
+++ /etc/fail2ban/action.d/iptables-multiport-lxc.conf 2020-02-21 14:22:34.415502555 +0100
@@ -6,7 +6,7 @@
[INCLUDES]
-before = iptables-common.conf
+before = iptables-common-lxc.conf
[Definition] After these modifications, the duplication of rules that used to occur when restarting F2B no longer occurs! The problem is therefore solved. This was indeed due to the f2b-sshd-lxc-web chain not existing at the start of the Fail2ban service. I'll continue my tests. If you are interested, here is the line I use to simulate a bad password in my auth.log to save time: echo "$(LANG=en_us_8859_1 date +"%b %d %H:%M:%S") lxc-web sshd[413]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.150.55 user=root" >> /var/lib/lxc/lxc-web/rootfs/var/log/auth.log |
Environment:
Ubuntu Xenial + LXC + Fail2Ban v0.9.3 + all latest OS updates.
The issue:
Trying to get fail2ban running at host level to track logs in all LXC containers (there are many).
Idea is to block attacking IP at host level for all containers, whenever any site on any container is attacked.
fail2ban config modification
[sshd]
enabled = false
port = ssh
logpath = /var/log/auth.log tail
/var/lib/lxc/*/rootfs/var/log/auth.log tail
Problem
This approach seems to simplistic, because what appears to be happening (my guess, haven't fired up tcpdump to figure it out yet) is that the iptables blocking rule added only applies to the base interface.
In my case I have the base interface + one alias/container, where all packets flow from public interface alias to each container's dynamically generated IP.
Base interface is eth2.
Alias interfaces are eth2:1 - eth2:XXX
My guess is anytime an iptables block rule is added via an iptables command, the same command has to run for each alias.
This means logic for actioncheck + actionban + actionunban requires some additional complexity to handle this.
My questions...
If there's a know approach for handling this type of setup, pass me a pointer.
If not, I'm imaging the way to approach this is to create an ipset + then change action files like iptables-multiport.conf to reference the ipset.
Suggestions are appreciated.
Thanks.
The text was updated successfully, but these errors were encountered: