So it's great that shorewall has a DOCKER option. It saves docker's
rules on restart, and docker can do it's own iptables thing when a new
docker starts up and ports need to be forwarded, etc. Awesome.
However, the current implementation of DOCKER in shorewall introduces a
huge security flaw
On 8/4/2020 2:24 PM, Preston A. Elder wrote:
> So it's great that shorewall has a DOCKER option. It saves docker's
> rules on restart, and docker can do it's own iptables thing when a new
> docker starts up and ports need to be forwarded, etc. Awesome.
>
> However, the current implementation of
@Matt,
That ONLY works if I have static IP addresses for my docker containers,
and know ahead of time what port will be assigned to what IP.
And that I have specifically named each bridge for each docker container
I am going to create.
And I am essentially replicating all the stuff docker
This is a good catch,
This kind of thing is exactly why one should be very hesitant to put
any type of monolithic obfuscated interposer between security and bare
metal. I do use VMs for point-of-entry firewalling, rather than an
application container, and those VM are configured to absorb t
On 8/4/2020 5:24 AM, Preston A. Elder wrote:
> So it's great that shorewall has a DOCKER option. It saves docker's
> rules on restart, and docker can do it's own iptables thing when a new
> docker starts up and ports need to be forwarded, etc. Awesome.
>
> However, the current implementation of
On 8/4/2020 5:24 AM, Preston A. Elder wrote:
> So it's great that shorewall has a DOCKER option. It saves docker's
> rules on restart, and docker can do it's own iptables thing when a new
> docker starts up and ports need to be forwarded, etc. Awesome.
>
> However, the current implementation of
