Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178145 > unrolled thread

Mixing firewall tools

Back to article view | Back to linux.debian.user

Contents

  Mixing firewall tools Richard Hector <richard@walnut.gen.nz> - 2017-02-25 08:00 +0100
    Re: Mixing firewall tools Dan Ritter <dsr@randomstring.org> - 2017-02-25 15:30 +0100
      Re: Mixing firewall tools Richard Hector <richard@walnut.gen.nz> - 2017-02-25 15:50 +0100
        Re: Mixing firewall tools Dan Ritter <dsr@randomstring.org> - 2017-02-25 16:50 +0100

#178145 — Mixing firewall tools

[Multipart message — attachments visible in raw view] — view raw

Hi all,

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?

I do have a hitch on this machine (but not on another similar one) in
that it hangs on boot ... I'm not sure why, except I suspect running an
init script on a systemd system may be a contributing factor - except
that my other firewall was also upgraded to jessie+systemd, and it
works. I haven't figured that one out yet.

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?

Are there any good tools out there that allow for integration of
multiple firewall systems, and produce reasonably straightforward rule sets?

Any other tips - ie answers to questions I didn't think of asking? :-)

Thanks,
Richard

[toc] | [next] | [standalone]

#178161

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.

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.

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.

> 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.

-dsr-

[toc] | [prev] | [next] | [standalone]

#178162

[Multipart message — attachments visible in raw view] — view raw

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.

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.

> 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.

>> 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 ...

Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#178165

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-

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web