Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
Rich Freeman ri...@gentoo.org writes: On Thu, Jan 15, 2015 at 3:32 PM, lee l...@yagibdah.de wrote: Rich Freeman ri...@gentoo.org writes: 2. Run fail2ban in each container and have it monitor its own logs, and then add host iptables rules to block connections. Containers must not be able to change the firewalling rules of the host. If they can do such things, what's the point of having containers? A container on linux is really a set of kernel namespaces. There are six different namespaces in linux and a process can share any or none of them with the host. In this case the network namespace determines whether a process can see the host interfaces. There may also be capabilities that control what the process can do with those interfaces (I'd have to read up on that). A container may or may not have a separate network namespace. If it does most likely you're going to have to set up a bridged interface, DHCP/NAT, etc for the container. That's what I did. Until I learn more, I have to assume that the default settings are reasonably secure ... 3. Run fail2ban in each container and have each container in its own network namespace. Fail2ban can then add container iptables rules to block connections. That would waste resources. Depends on how you run it, but yes, you might have multiple instances of fail2ban running this way consuming additional RAM. If you were really clever with your container setup they could share the same binary and shared libraries, which means they'd share the same RAM. However, it seems like nobody bothers running containers this way (obviously way more work coordinating them). And they wouldn't be much separated anymore. I doubt it would take more CPU - 1 process scanning 5 logs probably doesn't use more CPU than 5 processes scanning 1 log each. Isn't there some sort of scheduling and/or other overhead involved when you run more processes? I mean the overhead of just being there: A process scheduler that needs to consider 500 processes might require more CPU itself than a scheduler considering 150 processes. You would get a security benefit from just running fail2ban on the host, since a failure on one container would apply a block to all the others. Plus when running fail2ban on the host, you can block connections from a particular IP for everyone. However, fail2ban didn't seem to do anything. It wrote into its logfile: , | INFOChanged logging target to /var/log/fail2ban.log for Fail2ban v0.9.1 | ERROR Unable to import fail2ban database module as sqlite is not available. ` That was all for a couple days until I stopped it. If some squlite library or something is required, I would expect it to have been pulled in through dependencies. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
On Sat, Jan 17, 2015 at 7:56 AM, lee l...@yagibdah.de wrote: Rich Freeman ri...@gentoo.org writes: Depends on how you run it, but yes, you might have multiple instances of fail2ban running this way consuming additional RAM. If you were really clever with your container setup they could share the same binary and shared libraries, which means they'd share the same RAM. However, it seems like nobody bothers running containers this way (obviously way more work coordinating them). And they wouldn't be much separated anymore. Yes and no. You can run 45 containers off of the same read-only root filesystem and they're just as separated as 45 containers running off of 45 copies of the same filesystem. The work comes from needing to design your containers so that they can share stuff. The processes are still isolated in memory, and they can't see outside of their container. If they share a writable filesystem then they are not separated with regard to that - you'd need to be careful what you shared and what you didn't. Typically in these kinds of setups you're going to use a gold image for most of your filesystem, and then use tmpfs or such for anything writable. This is one of the drivers for the /usr move - the goal is to consolidate the areas of a linux filesystem that an instance really needs to touch so that you don't end up having read-write areas all over the place. I doubt it would take more CPU - 1 process scanning 5 logs probably doesn't use more CPU than 5 processes scanning 1 log each. Isn't there some sort of scheduling and/or other overhead involved when you run more processes? I mean the overhead of just being there: A process scheduler that needs to consider 500 processes might require more CPU itself than a scheduler considering 150 processes. The overhead is very minimal as far as I'm aware. The scheduler itself is O(1) so no, it doesn't take longer to task-switch between 5 processes and 5M processes. I'm sure there are some CPU costs I'm not accounting for, but it should be pretty low. RAM is really the issue here. Maybe disk IO if all those processes are updating different files as well. You would get a security benefit from just running fail2ban on the host, since a failure on one container would apply a block to all the others. Plus when running fail2ban on the host, you can block connections from a particular IP for everyone. Also, if you have a container running apache and another running postfix, then a failed access attempt in postfix would result in access to your apache server being blocked as well. -- Rich
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
Rich Freeman ri...@gentoo.org writes: On Sun, Jan 11, 2015 at 1:47 PM, lee l...@yagibdah.de wrote: Same here, so why does fail2ban get involved with containers? Seems like there are three options here. 1. Run fail2ban on the host and have it look into the containers, monitor their logs, and add host iptables rules to block connections. That's what I'm trying. 2. Run fail2ban in each container and have it monitor its own logs, and then add host iptables rules to block connections. Containers must not be able to change the firewalling rules of the host. If they can do such things, what's the point of having containers? 3. Run fail2ban in each container and have each container in its own network namespace. Fail2ban can then add container iptables rules to block connections. That would waste resources. I actually gave up on fail2ban after a bunch of issues. The only place I get brute force attacks right now is ssh, and I'm using the Google authenticator plugin. I just ignore the thousands of failed ssh authentication attempts... Hm, it's not working at all? It doesn't seem to do anything here ... -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
On Thu, Jan 15, 2015 at 3:32 PM, lee l...@yagibdah.de wrote: Rich Freeman ri...@gentoo.org writes: 2. Run fail2ban in each container and have it monitor its own logs, and then add host iptables rules to block connections. Containers must not be able to change the firewalling rules of the host. If they can do such things, what's the point of having containers? A container on linux is really a set of kernel namespaces. There are six different namespaces in linux and a process can share any or none of them with the host. In this case the network namespace determines whether a process can see the host interfaces. There may also be capabilities that control what the process can do with those interfaces (I'd have to read up on that). A container may or may not have a separate network namespace. If it does most likely you're going to have to set up a bridged interface, DHCP/NAT, etc for the container. So, you can have it either way, which is why I offered three options. There are pros and cons to each. But, yes, if you do share the host interface then the amount of interaction is higher than if you don't. And, keep in mind that a container is not as compartmentalized as a VM in any case. 3. Run fail2ban in each container and have each container in its own network namespace. Fail2ban can then add container iptables rules to block connections. That would waste resources. Depends on how you run it, but yes, you might have multiple instances of fail2ban running this way consuming additional RAM. If you were really clever with your container setup they could share the same binary and shared libraries, which means they'd share the same RAM. However, it seems like nobody bothers running containers this way (obviously way more work coordinating them). I doubt it would take more CPU - 1 process scanning 5 logs probably doesn't use more CPU than 5 processes scanning 1 log each. You would get a security benefit from just running fail2ban on the host, since a failure on one container would apply a block to all the others. -- Rich
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
On Sun, Jan 11, 2015 at 10:48 AM, lee l...@yagibdah.de wrote: I don't want to run fail2ban in the container because the container must not mess with the firewall settings of the host. If a container can do that, then what's the point of having containers in the first place? I've never used the LXC scripts to set up a container, but I actually run a firewall inside a container. You just need to run it in a separate network namespace so that it is messing with its own interface. In general, though, I wouldn't want my containers messing with my host interfaces. BTW, why does Gentoo put containers under /etc? Containers aren't configuration files ... I'd never put a container there. I can't speak to how the lxc scripts are intended to be used - I don't use those tools to manage containers. I typically stick my containers in their own place in btrfs subvolumes for easy management. -- Rich
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
see https://bugs.gentoo.org/show_bug.cgi?id=536320 lee l...@yagibdah.de writes: Hi, I'm trying to get fail2ban to work on the host and keep getting error messages like: , | Jan 08 21:13:04 [/etc/init.d/fail2ban] You have to create an init script for each container: | Jan 08 21:13:04 [/etc/init.d/fail2ban] ln -s lxc /etc/init.d/lxc.container | Jan 08 21:13:05 [/etc/init.d/fail2ban] ERROR: fail2ban failed to start ` After 'ln -s lxc /etc/init.d/lxc.container', it says: , | Jan 08 21:17:08 [/etc/init.d/fail2ban] Unable to find a suitable configuration file. | Jan 08 21:17:08 [/etc/init.d/fail2ban] If you set up the container in a non-standard | Jan 08 21:17:08 [/etc/init.d/fail2ban] location, please set the CONFIGFILE variable. | Jan 08 21:17:09 [/etc/init.d/fail2ban] ERROR: fail2ban failed to start ` Naming the link 'lxc.acheron', with 'acheron' being the name of the container, gives the first error message again. The containers' configuration is at the default location: , | heimdali init.d # ls -la /etc/lxc/acheron/config | -rw-r--r-- 1 root root 967 5. Jan 01:14 /etc/lxc/acheron/config | heimdali init.d # ` What am I missing? Shorewall is used on the host, exim is running in the container, and I want fail2ban (on the host) to look into the logfile of the exim which runs in the container: , | heimdali fail2ban # cat paths-overrides.local | exim_main_log = /etc/lxc/acheron/rootfs/var/log/exim/exim_main.log | heimdali fail2ban # ` I don't want to run fail2ban in the container because the container must not mess with the firewall settings of the host. If a container can do that, then what's the point of having containers in the first place? BTW, why does Gentoo put containers under /etc? Containers aren't configuration files ... -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
On Sun, Jan 11, 2015 at 1:47 PM, lee l...@yagibdah.de wrote: Same here, so why does fail2ban get involved with containers? Seems like there are three options here. 1. Run fail2ban on the host and have it look into the containers, monitor their logs, and add host iptables rules to block connections. 2. Run fail2ban in each container and have it monitor its own logs, and then add host iptables rules to block connections. 3. Run fail2ban in each container and have each container in its own network namespace. Fail2ban can then add container iptables rules to block connections. I actually gave up on fail2ban after a bunch of issues. The only place I get brute force attacks right now is ssh, and I'm using the Google authenticator plugin. I just ignore the thousands of failed ssh authentication attempts... -- Rich
Re: [gentoo-user] fail2ban: You have to create an init script for each container ...
Rich Freeman ri...@gentoo.org writes: On Sun, Jan 11, 2015 at 10:48 AM, lee l...@yagibdah.de wrote: I don't want to run fail2ban in the container because the container must not mess with the firewall settings of the host. If a container can do that, then what's the point of having containers in the first place? I've never used the LXC scripts to set up a container, but I actually run a firewall inside a container. You just need to run it in a separate network namespace so that it is messing with its own interface. In general, though, I wouldn't want my containers messing with my host interfaces. Same here, so why does fail2ban get involved with containers? BTW, why does Gentoo put containers under /etc? Containers aren't configuration files ... I'd never put a container there. I can't speak to how the lxc scripts are intended to be used - I don't use those tools to manage containers. I typically stick my containers in their own place in btrfs subvolumes for easy management. I wouldn't put them there, either. Yet Gentoo does, very unexpectedly. I'll probably move the container into its own ZFS FS. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
[gentoo-user] fail2ban: You have to create an init script for each container ...
Hi, I'm trying to get fail2ban to work on the host and keep getting error messages like: , | Jan 08 21:13:04 [/etc/init.d/fail2ban] You have to create an init script for each container: | Jan 08 21:13:04 [/etc/init.d/fail2ban] ln -s lxc /etc/init.d/lxc.container | Jan 08 21:13:05 [/etc/init.d/fail2ban] ERROR: fail2ban failed to start ` After 'ln -s lxc /etc/init.d/lxc.container', it says: , | Jan 08 21:17:08 [/etc/init.d/fail2ban] Unable to find a suitable configuration file. | Jan 08 21:17:08 [/etc/init.d/fail2ban] If you set up the container in a non-standard | Jan 08 21:17:08 [/etc/init.d/fail2ban] location, please set the CONFIGFILE variable. | Jan 08 21:17:09 [/etc/init.d/fail2ban] ERROR: fail2ban failed to start ` Naming the link 'lxc.acheron', with 'acheron' being the name of the container, gives the first error message again. The containers' configuration is at the default location: , | heimdali init.d # ls -la /etc/lxc/acheron/config | -rw-r--r-- 1 root root 967 5. Jan 01:14 /etc/lxc/acheron/config | heimdali init.d # ` What am I missing? Shorewall is used on the host, exim is running in the container, and I want fail2ban (on the host) to look into the logfile of the exim which runs in the container: , | heimdali fail2ban # cat paths-overrides.local | exim_main_log = /etc/lxc/acheron/rootfs/var/log/exim/exim_main.log | heimdali fail2ban # ` I don't want to run fail2ban in the container because the container must not mess with the firewall settings of the host. If a container can do that, then what's the point of having containers in the first place? BTW, why does Gentoo put containers under /etc? Containers aren't configuration files ... -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
