On Sun, Feb 26, 2017 at 03:40:53AM +1300, Richard Hector wrote: > On 26/02/17 03:19, Dan Ritter wrote: > > On Sat, Feb 25, 2017 at 07:54:32PM +1300, Richard Hector wrote: > >> I have a machine with a hand-rolled firewall script, which just runs > >> iptables commands - all well and good. > >> > >> The trickiest bits are for my LXC containers; I need to forward ports > >> etc - but that's ok. > >> > >> The complications start when I add fail2ban - now I have an extra bit in > >> my init script that reloads fail2ban after reloading my script, because > >> my script does a flush of all existing rules. This is now getting ugly, > >> but it still worked. > >> > >> Does anyone have better ideas for that stage? Do any of the many > >> firewall tools cope with this adequately? > > > > > > Take a step back and describe your topology, please. > > A remotely hosted VPS (yes, many layers ...) with a single IP address > allocated. Getting more from this provider is tedious at best. > > At the moment, it runs a few things itself, but most public services are > in LXC containers. Everything public-facing is supposed to be in a > container. It does however run nginx, proxying to the internal web > services, and that does all the TLS. There's a mail container running > postfix and dovecot; that all gets forwarded by iptables. > > There's a postgresql and an internal-only BIND on the host, running on > the host's internal ip. > > SSH is accessible on the host, on a non-standard port; containers are > sshable via forwarded non-standard ports. There is or will be a git > container which needs the standard port. > > > Remember that fail2ban needs to run on the "machine" (host or > > container or VM or whatever) where both the daemon logs are > > stored and iptables decisions can be made. In order to cleanly > > accomplish that, you should have a fail2ban instance and an > > iptables instance inside each machine, and leave the host > > firewall to take care of the host and generically handle any > > needed NAT. > > That would mean fail2ban needs to run on the host (for ssh, nginx) _and_ > on each container. It still needs to coexist.
Correct, but it doesn't need to cross boundaries. The fail2ban on the host runs solely for ssh and nginx. The fail2ban on your mail server machine runs for IMAP and SMTP, and doesn't share information out to the host on which it lives. > However, AFAIK it doesn't make sense to run iptables inside a container; > it's all one kernel. It currently doesn't work, anyway. That means that > any fail2ban instances running in containers would have to somehow > control iptables outside, which is probably not desirable. It's probably > better to have fail2ban monitoring the container filesystems (which are > visible from the host) instead. It's all one kernel, but by giving each container its own IP address, you get to operate in a different network namespace. iptables inside a network namespace should work smoothly, believing it is in sole control. http://containerops.org/2013/11/19/lxc-networking/ seems to be a good reference. > > If you can, it's cleaner and easier to give an IP address to > > each machine and use routing instead of NAT. Push NAT to the > > perimeter of your network. > > The only available public IP address is on the host. Everything else is > RFC1918. NAT on the host, then, and RFC1918 addresses internally. > >> Now the biggie: I want to add Docker. Docker wants to do its own thing > >> with iptables. Do I need to resort to just telling Docker to keep its > >> hands off, and do everything myself? > > > > Doing Docker and LXC at the same time is oddly duplicative. But > > the same principles apply. > > It is. I've been learning Docker more recently than the machine was set > up, and I'm starting to see benefits - partly the fact that much of the > work might have been done for me, and partly I think it'd use less disk > space overall due to the layering. > > I would certainly consider migrating the other containers from LXC to > Docker. > > Mind you, I'm also starting to think the poor thing's getting a bit > overloaded ... LXC and Docker add very little CPU overhead by themselves, but they are not so great at network and disk I/O. The big loss, however, is in quantity of memory used by duplicative services. Docker is usually set up to use the network namespace feature from the beginning, so that's probably the biggest difference. -dsr-
