firewalld vs iptables vs ? as default (was Comparison to Workstation Technical Specification)

[Reindl Harald]

Am 04.03.2014 13:40, schrieb Miloslav Trmač:
> Even in such a case it would not make sense for the /role/ to decide whether to poke holes for itself: either the
> system roles are assumed to be competently administered or not, and in both cases all roles on the system should be
> treated the same.
> 
> And I don't think the case you describe is frequent in the firsts place.  It requires:
> 
>   * A multi-user UNIX system (in itself becoming rare, everyone has a powerful personal computer, and remoting the
>     GUI loses features; you would have a git server or a file server or a VPN server, but not so much a general
>     shell server)
>   * A multi-user UNIX system that /also/ provides other roles at the same time (tightly coupling things that
>     probably shouldn't be coupled, using separate VMs would result in more flexibility)
>   * A system that is reachable from an environment that is more hostile than the users (e.g. with a public IP
>     address); again note that the firewall setups we are talking about don't affect outgoing connections, only
>     incoming connections matter.
> 
> So, a multi-user server with a public IP address:  Yes, there is a specific and frequent kind of them - web hosting
> servers; but those are also not something that we really can support as a default setup, and longer-term I'd expect
> them to go the OpenShift way, giving each user a separate container with a separate network namespace.  Other than
> web hosting, are public multi-user servers with ability of users to run arbitrary code really that frequent?
> Mirek

first:
ship whatever OS with shields down and no packet filter blocking anything incoming
is a flawed design and unacceptable (no matter if it is a server or a workstation)

second:
you never know in which way a port get opened and if it is because packaging
bugs as i showed whith avahi pulled for no reason - nonody can gurantee that
similar things are not happening in a future point of time

third:
even if you install a service or webapplication and enable it that does not mean
at the same time it should be reachable from the web - in most cases the
opposite is true because after the first start you typically configure and
test whatever you have installed on localhost, otherwise the admin should
not do an IT job

fourth:
"to run arbitrary code really that frequent" define that - any scripting language
with commands like exec(), system() and so on is in danger to run code if it is
not perfectly secured what a default installation is unable to do

so there is still a difference if any badly written script executes code and is
able to open a unprivileged port and having that one immediately reachable from
the WAN or blocked by a packet filter giving the admin a timewindow to realize
something is going wrong before more damage happens

and so finally: now, in the past and in any future you have to block any incoming
connection in whatever operating system by default or nobody with security knowledge
will install that "product" because he is aware about the wrong security attitude
of it's creators and that it is not worth the time for a second look

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140304/877f3f38/attachment.sig>