F19 Firewall

[P J P]

  Hello,

A long thread about firewall & Firewalld application+daemon is running on fedora-devel
list.

   About F19 Firewall ->
https://lists.fedoraproject.org/pipermail/devel/2013-September/189272.html

The
 upstream authors are in the process of rewriting Firewalld in C (from 
Python). The current discussion is oscillating between 
features+complexity and  usability+security that firewall has to offer.

I
 thought may be folks here could offer valuable suggestions to authors 
while they are re-writing the application; So that it ends-up being 
usable & secure, instead of bloated and swollen.

Thank you.

---
Regards
   -Prasad
http://feedmug.com

[Eric Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, Sep 24, 2013 at 11:53:29PM +0800, P J P wrote:
>  A long thread about firewall & Firewalld application+daemon is
> running on fedora-devel list.
>  
>     About F19 Firewall ->
> https://lists.fedoraproject.org/pipermail/devel/2013-September/189272.html 
Yeah, I've been reading that conversation but I never made any replies to it.  I
haven't investigated firewalld that much but here's my shoot-from-the-hip thought
on the subject:

I wrote a paper on using iptables at the end of one of my college courses on security. 
iptables (and its varient ip6tables) is a very powerful tool that allows people to do all
kinds of things to incoming and outgoing packets.  Here's the problem as I see it. 
iptables *can* be confusing to implement and software that needs a port opened hasn't
really been able to interface with iptables very well in the past.  Supposedly firewalld
fixed the problem with iptables not being very dynamic.  This would mean that if you
stopped your SSH daemon TCP port 22 should also close as well (I haven't tested this
and I won't comment on whether this actually works).

firewalld also provides a nice GUI for people to use so they can setup complex rules based
on what network they are connected to.  Creating zones in iptables was always possible but
it just sucked when you tried to manage it.  This GUI, however, means that iptables rules
now look horrible when you query them directly.  Does this mean it has been done
incorrectly?  Nope.  It just means that when you decide to use complex rules you get
complex rules.

System administrators should figure out if firewalld is a problem or an asset.  firewalld
does things like make sure that rules are echoed across iptables and ip6tables which
further reduces the complexity of setting up rules.

In my opinion, firewalld works very well when used on desktop (user) machines and not so
much on servers and the like.  This would not be the first tool that falls into this
category.  I suspect that when the F21 releases come out (different desktop and server
images) we'll see a more specialized set of tools on each so that each group is
happier (maybe).

Does firewalld make systems more vulnerable?  No, not any more than iptables did.  

Does it make the iptables ruleset look horrible?  Why are you configuring iptables using a
GUI tool and then looking at the raw rules anyway?

- -- Eric

- --------------------------------------------------
Eric "Sparks" Christensen
Fedora Project

sparks(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQGcBAEBCgAGBQJSQcR2AAoJEB/kgVGp2CYvxSEL/1Z8kwzGX7vpOIbWyFLVm1hT
> UfgA4jUceYoJY0vt+MNcUBFo1tU28sh637Fnau69S2qev7oirCdz3oj5WtOBtyw9
> d/H3ipywnZzBRnT3lu1BREjvSMDph3iHP3sksFrJP9w6jGXoquiBPxv1j9gC81+h
> KtcOJwQ47X0m1d1wTZcxVBm1hNSqTvsShe3i9T4vRQa+fIdGAax2qYc3hrVVfiH/
> 5N/OCyxpo0sLQW2CBVvrp56hX2jL9tr8M/BTQHfz32EKSySt15PvVU9qOfUKtz3t
> w/IeTT28Hzu7akpUZWhW4XsobqcWNuVtY0ArtmYoLbAFpIRDqm5Jv10YsDcHO7d0
> RgbWYcr0aaRkAKJmTxZKsvJ5HXDsENGfuXKzuTbg3EwjpKaLaZb8Tx8UWb2nN+b7
> tDrGoaBLlZq/Guo3wNkPunT+u7uThiaHqUwDZeEn7CHViD51XcrRJzSw26vm9S29
> Tni2B98n9Df9O+n6/Rx97dtraaVnwHpP1BnV8i6yPQ==
> =8wYN
> -----END PGP SIGNATURE-----

[P J P]

----- Original Message -----
>  From: Eric H. Christensen <sparks(a)fedoraproject.org&gt;
>  Subject: Re: F19 Firewall
>  Does firewalld make systems more vulnerable? 

   If it allows applications/daemons/users to edit firewall rules, I guess that is not
impossible.

 
>  Does it make the iptables ruleset look horrible?  Why are you
> configuring 
>  iptables using a GUI tool and then looking at the raw rules anyway? 
   Well, that is to say that Firewalld is a replacement for iptables(8). :)


---
Regards
   -Prasad
http://feedmug.com

[Kurt Seifried]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some random thoughts:

1) it would be nice to have capabilities like "do you want to let
program X talk to the internet/receive connections" for client
software with a GUI notification (like basically all the windows
client/Mac OS X client firewall stuff). I would say this is probably
the biggest capability needed for normal end users.

2) Tying firewall into networking detection, e.g. windows "is this
your home/business/public network" and then remembering it (I assume
IP/Mac address of default gateway would be a reasonably good way to
identify networks).

3) Make it easy to modify policy, e.g. in section 1) if you choose to
block/deny something and realize that was the wrong decision how do
you go in an modify it? In Windows this is a PITA for normal users.

Overall I'm not really sure firewalld solves much, anyone running a
server will probably be able to tweak iptables to allow incoming
services they want. So do we aim it at the end user/workstation style
usage primarily (especially ones that move around networks)?

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBAgAGBQJSQdXYAAoJEBYNRVNeJnmTC6wQAIW3HNlAqfSkMSZqbFG6kbj/
> GOlnzjJOrUzt/LWwOGPCTmg/GgSOHrT4t1gT1577sL2LM5wPGCF/oll84RehiZd8
> PXNiyq3QnsOJFLjmEbm1YfGpDGae5+uR4IR3Bm1MVHBjvquhlqaje0b1yI2gs8Do
> LY9sXeGmYh+YjKIUDJrOCCS/I/xE8Zl4D+aU/s1BumV9LxwsOURTzXv5x32C8zwS
> 5MH5rvX9LO5vJn0VMByRsoXrCSybyLnRmsDvAH9yYx+WjforKsU4wq2QVLYDtjU/
> 0TO/n7qP1WO7doixYLymxwm+Fnk8J7HGa2t/2of2ZvX2AB3eRLmzj+tKzKohZR4H
> jxCLImHLx/puPr6VA/4ENSrHltCCbTSDvlZGxTHAeHwszmQzYMXZ8Qv/leRf4ThO
> E3wvuoIpgUWSEbE8RjVmXjX/Cd1GYz6ns35ydy2kZgHr4AfQifF+hdWHPP63/hrJ
> C21iZylvIMJKF2cWOXwR4X+Zr9tDthf+UDeEE3J/uQAfj3LDvjdHXqd0xcgOSrae
> nP0hPHj0apZrzY0zJfcn3JNipRDDl3qNgs8Q8tFAut5WvubCdLlVFXvLWMs6mOA2
> 6TmN4ZzEh0zfeGLq+LZ1kAY0ZsIds9ziyKsxAPGlTQz3Ax9rjb40BOwClHc4wbOF
> 6DzOg7WN87fRSO/wCTy3
> =dDnL
> -----END PGP SIGNATURE-----

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/24/2013 02:11 PM, Kurt Seifried wrote:
>  Some random thoughts:
>  
>  1) it would be nice to have capabilities like "do you want to let program X
>  talk to the internet/receive connections" for client software with a GUI
>  notification (like basically all the windows client/Mac OS X client
>  firewall stuff). I would say this is probably the biggest capability needed
>  for normal end users.
>  
>  2) Tying firewall into networking detection, e.g. windows "is this your
>  home/business/public network" and then remembering it (I assume IP/Mac
>  address of default gateway would be a reasonably good way to identify
>  networks).
>  
>  3) Make it easy to modify policy, e.g. in section 1) if you choose to 
>  block/deny something and realize that was the wrong decision how do you go
>  in an modify it? In Windows this is a PITA for normal users.
>  
>  Overall I'm not really sure firewalld solves much, anyone running a server
>  will probably be able to tweak iptables to allow incoming services they
>  want. So do we aim it at the end user/workstation style usage primarily
>  (especially ones that move around networks)?
>  
>  -- security mailing list security(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/security
>   
Well I would like to add SELinux support to it to control which processes are
allowed to manage which ports.  But I want to wait until their is a C Version.

This would control that NetworkManager can modify zones, while cups can modify
the cups port rules.  And other services are not allowed to modify any rules.
I am a little worried about auditing/journaling which process modified the
iptables rules.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJEIA8ACgkQrlYvE4MpobO3DQCfbBdUjPpMDCXOEiTk11NVKq7S
> XmYAoIAFYAe/B1YyHTpIoqKBiuE3fXTm
> =kQd4
> -----END PGP SIGNATURE-----

[Miloslav Trmač]

On Tue, Sep 24, 2013 at 8:11 PM, Kurt Seifried <kseifried(a)redhat.com&gt; wrote:
>  1) it would be nice to have capabilities like "do you want to
> let
>  program X talk to the internet/receive connections" for client
>  software with a GUI notification (like basically all the windows
>  client/Mac OS X client firewall stuff). I would say this is probably
>  the biggest capability needed for normal end users. 
This really doesn't work.  On the UI level:

* It's impossible to ask about outgoing connections: "Do you want
/usr/bin/yncp program to connect to 23.56.68.226 port 31337"?  At
best, the user will be afraid and click "no"; or perhaps they will
guess that yncp stands for "your new chat program" that has been
recently installed, and understand that it is wanting to connect - and
of course they want the chat program to connect.  Nobody will ever
realize that that IP address is what www.nsa.gov resolves to, and that
the port is the default for Black Orifice.

* It's impossible to ask about opening listening sockets: "Do you want
/usr/bin/yncp to accept connection requests over the Internet?"  - "Of
course I want my chat program to accept conversations!"

* There isn't any practical difference between the two any more
anyway, due to the prevalence of NAT firewalls.

On the security architecture level, we don't have a concept of
"program X" that is good enough for making security decisions (e.g.
due to ptrace, shared access to the configuration in home directory,
lack of X11 access control).  This is a known problem, and is being
slowly worked on, and will hopefully eventually be solved; however the
UI problems are pretty much unsolvable.


>  Overall I'm not really sure firewalld solves much, anyone running
> a
>  server will probably be able to tweak iptables to allow incoming
>  services they want. 
Anyone running a server will probably be able to learn iptables
if
they have to.  Still,
>  -A INPUT -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack
> --ctstate NEW -j ACCEPT 
is a pretty sad thing to have to type in 2013 - we have all
these
computer things that are supposedly good at automating boring work, so
why shouldn't this be automated/abstracted away by the computer?

>  So do we aim it at the end user/workstation style
>  usage primarily (especially ones that move around networks)? 
No, firewalld is primarily aimed at "network end-points", managed by
an administrator who understands IP networks but not necessarily
knowing iptables by heart.
    Mirek

[Miloslav Trmač]

On Tue, Sep 24, 2013 at 7:28 PM, P J P <pjp(a)fedoraproject.org&gt; wrote:
>  ----- Original Message -----
> > From: Eric H. Christensen <sparks(a)fedoraproject.org&gt;
> > Subject: Re: F19 Firewall
> > Does firewalld make systems more vulnerable?
>
>     If it allows applications/daemons/users to edit firewall rules, I guess that is not
> impossible. 
This is controlled by polkit, and only restricted to system
administrators, so hopefully safe.  See
/usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.policy .
    Mirek

[Miloslav Trmač]

On Tue, Sep 24, 2013 at 6:57 PM, Eric H. Christensen
<sparks(a)fedoraproject.org&gt; wrote:
>  I wrote a paper on using iptables at the end of one of my college
> courses on security.  iptables (and its varient ip6tables) is a very powerful tool that
> allows people to do all kinds of things to incoming and outgoing packets.  Here's the
> problem as I see it.  iptables *can* be confusing to implement and software that needs a
> port opened hasn't really been able to interface with iptables very well in the past. 
> Supposedly firewalld fixed the problem with iptables not being very dynamic. 
It does; in my view the primary problem it fixes is iptables being at
too low level of abstraction.  The question "is port 22 open" can be
only answered for itpables by interpreting a Turing-complete language.
 The dynamic changes are more of a corner case

>   This would mean that if you stopped your SSH daemon TCP port 22
> should also close as well (I haven't tested this and I won't comment on whether
> this actually works). 
That's not what firewalld does, and it doesn't make that much sense
anyway - all it would protect against is vulnerabilities in kernel's
handling of CLOSED sockets.

>  firewalld also provides a nice GUI for people to use so they can
> setup complex rules based on what network they are connected to.  Creating zones in
> iptables was always possible but it just sucked when you tried to manage it.  This GUI,
> however, means that iptables rules now look horrible when you query them directly.  Does
> this mean it has been done incorrectly?  Nope.  It just means that when you decide to use
> complex rules you get complex rules. 
Eliminating the no-op chains would make sense, and a bug has been
already filed out for this.

>  In my opinion, firewalld works very well when used on desktop (user)
> machines and not so much on servers and the like. 
I don't think server/desktop is a very way to think about firewalls.
The primary classes are "self-managed desktop" vs. "network endpoints:
servers and IT-managed desktops" vs. "routers/NAT boxes/network
infrastructure".

For self-managed desktops, there really shouldn't be a firewall
blocking anything the user wants to do - because it's impossible to
reasonably ask the user for a firewall policy decision, all such a
firewall would do is annoy the user, or make the product seem broken.
(It might still make sense to have a default configuration blocking
"system" services that the user might not even know about, like the
sshd we run by default.)

For centrally-managed network endpoints. having an actual API to call
with firewalld instead of manually editing files and hoping that there
wasn't a typo is, I think, usually beneficial.  (Yes, administrators
can get similar level of safety by using a different iptables
front-end, like perhaps the puppet firewall module.)   With
http://fedoraproject.org/wiki/Features/FirewalldRichLanguage , it
seems to me that the major use cases for an endpoint server (not a
network gateway) have been covered fairly well.  Is there anything
missing?

For routers/NAT/network infrastructure, it's firewalld is likely not sufficient.

Will firewalld natively _everything_ that iptables can do?  No, that
would defeat the point of having a higher-level API.  Still, there is
the --direct API that allows users to talk to iptables directly; is
that not working well enough?
    Mirek

[Matthew Miller]

On Thu, Sep 26, 2013 at 04:00:03PM +0200, Miloslav Trmač wrote:
>  It does; in my view the primary problem it fixes is iptables being
> at
>  too low level of abstraction.  The question "is port 22 open" can be
>  only answered for itpables by interpreting a Turing-complete language. 
Or as everyone does it: by testing if a connection can be made. And,
frankly, if that test passes, do we care what mechnism is enforcing it?



-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Miloslav Trmač]

On Thu, Sep 26, 2013 at 4:40 PM, Matthew Miller <mattdm(a)mattdm.org&gt; wrote:
>  On Thu, Sep 26, 2013 at 04:00:03PM +0200, Miloslav Trmač wrote:
> > It does; in my view the primary problem it fixes is iptables being at
> > too low level of abstraction.  The question "is port 22 open" can be
> > only answered for itpables by interpreting a Turing-complete language.
>
>  Or as everyone does it: by testing if a connection can be made. And,
>  frankly, if that test passes, do we care what mechnism is enforcing it? 
That somewhat works when checking for an open port, but not when you
want the port to be closed.  Perhaps it's only closed for the
management machine that is doing the check, to shut the security
department up.
    Mirek