Talk:FirewallD

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Zones small tutorial and example)
 
(2 intermediate revisions by 2 users not shown)
Line 43: Line 43:
 
  Error: Nothing to do
 
  Error: Nothing to do
 
  [root@fc17 ~]#
 
  [root@fc17 ~]#
 +
 +
 +
: I fully agree with above. We just had a debate about this in irc. How this page hops directly into details without describing what zones are, how those are related to services and interfaces and how those should be used. After skimming this page through I still don't know and thus cannot apply the details from this page when don't have the big-picture what I'm doing. Same with the provided GUI, it just lists those but zone-concept still remains unclear. That with security is not a very good starting point. Note that I maintain multiple iptables based systems and have history from Cisco, Enterasys, CheckPoint FW1, Stonesoft firewall and many other network security systems. I would change that main article myself if I knew what I would be writing. But I don't, so I wont. Pushing this into production release without introducting people into it wasn't that smart after all. [[User:Tuju|Tuju]] ([[User talk:Tuju|talk]]) 12:08, 2 February 2013 (UTC)
 +
 +
== Zones small tutorial and example ==
 +
 +
'''Firewalld''' zones could be used for several different purposes. Two examples:
 +
 +
(1) To define and switch firewall configurations easily for a portable computer (laptop, linux tablet). This would use zone “public” for limited inbound connections appropriate for use in a library or coffee shop; zone “work” for work-based inbound connections; and zone “home” for unlimited inbound connections in the home internet where the home router was trusted to block all inbound connections from outside the home. In this usage, the internet interface (or, more conveniently, each network manager “connection” associated with that internet interface) would be mapped to a different zone as the computer was moved from place to place.
 +
 +
(2) To define “zones of trust” for a server. If the server is public facing (for example, where a router has port forwarding to that server for HTTP, HTTPS, and SSH -- TCP ports 80, 443, and 22 respectively), then the “dmz” zone could be configured for unlimited access to those and only those services.
 +
 +
The following elaborates use (2): using zones to implements "zones of trust" for a home-based server.
 +
 +
Both network interfaces (e.g., “em1”) and address ranges can be associated with a zone. An interface can be associated to no more than one zone (although more than one interface can be associated with the same zone). Additionally, IP address ranges can be assigned to a zone.
 +
 +
For incoming connections:
 +
 +
(1) if the connection is coming from an interface (“em1”), then that connection can go to any service trusted (open) in that interface's zone.
 +
 +
(2) if the connection's IP address is associated with a zone (by virtue of being in any of the ranges of IP addresses associated with the zone), then that connection can go to any service trusted according to the IP address.
 +
 +
For example, the a home server is a web host (to be accessed from anywhere via a NAT router), supports SSH (for external command-line management and SFTP) and also is used as a DNS server inside the house. The main workstation (not this server) hosts a number of VMs, each with it's own IP address, so the DNS tables include about 20 devices. The server provides file storage (via NFS) to a few home workstations, but not to just anybody in the home. Also, it stores a bunch of MP3s that are served via MediaTomb to any renderers in the home (Android tablets, PS3, etc.). Finally, this server is a print server, so “ipp” needs to be available to anyone in the home.
 +
 +
SSH has been configured to refuse “root” logins and also to require RSA or DSA credentials (that is, username/password logins are not permitted). This configuration resists all dictionary-based hacking attempts.
 +
 +
The router is configured to forward ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) to the home server.
 +
 +
The router is a DHCP server that gives out addresses 192.168.0.64 and above; all the home workstations and their VMs are given fixed IP addresses of 192.168.0.2 and above.
 +
 +
To set this up, three zones are used:
 +
 +
(1) Zone “dmz” is associated with interface “em1”. It allows services ssh, http, https.
 +
(2) Zone “home” with sources 192.168.0.1/25 (that's 192.168.0.1 to 192.168.0.126). It allows services dhcpv6-client, dns, ipp, ipp-client and for Mediatomb (a DLNA-based media server) TCP port 49152 and UDP port 1900.
 +
(3) Zone “trusted” with sources 192.168.0.1/26 (that's  192.168.0.1 to 192.168.0.62). It allows services nfs.
 +
 +
Notice in the above that IP address source ranges can overlap, so IP address sources can be assigned to multiple zones. An IP address 192.168.0.14 arriving on interface “em1” matches all three zones.
 +
 +
From outside the home network, an laptop/tablet/phone FTP client can access the server using SFTP and a public RSA key separately installed (supported by most FTP clients). This is possible because the router forwards port 22 to the host's “em1” interface and the firewall's “dmz” zone allows the inbound connection (and SSH authenticates the credentials).
 +
 +
Inside the home, a workstation (fixed IP 192.168.0.22) can point to the home server for DNS so it can translate “private” DNS names. A laptop (dynamic IP 192.168.0.67) configured with DHCP whose DNS server IP set to the home server can also translate “private” DNS names. This works because both IP addresses are in the 192.168.0.1/25 range that is a source for the “home” zone and that zone allows DNS access. They can also access the home web server because they are both accessing the home server through its “em1” internet adapter, and therefore the services and ports open in the “dmz” zone are available inside the home as well.
 +
 +
A PS3 is configured to use DHCP; suppose today it is assigned dynamic IP address 192.168.0.66. It can  find MediaTomb (via UDP broadcast to port 1900) and get streaming media from the home server through TCP port 49152. This is all possible because its IP address is in the source range for the “home” zone. Also, the workstations and VMs can also play streaming media because their (static) IPs are also in the “home” source range.
 +
 +
However, only the workstations and VMs with statically assigned IP addresses can use NFS. The PS3 (for example) does NOT have an IP address in the “trusted” zone's acceptable range, and therefore cannot connect to the “nfs” service. Note: the firewall by itself doesn't make “nfs” secure since one can assign any IP address statically.
 +
 +
--[[User:Richbr4pi|Richbr4pi]] ([[User talk:Richbr4pi|talk]]) 23:01, 25 January 2014 (UTC)

Latest revision as of 23:01, 25 January 2014

[edit] Documentation by Example

Forgive my potential ignorance here - but perhapas the documentation needs to be approaced from the point of view of guiding the first time user: Imagine, if you will - I have just installed my first copy of Fedora. I install a network service. I find it doesn't work. I find it has a firewall. I find it has firewalld. I come here to see how to allow my service. I spend 30 minutes reading and am no closer to an answer. I even sign up to come post here. Most experienced sysadmins would have uninstalled and chucked away firewalld by now. I, have, however, not.

My point is this: It is paramount to have documentation by example. Long tedious explanations of how things work and why is meaningless. Most people just need a list of examples, find the right example - and use it. Or have the whole process automated in the first place.

If I could find the answer, I would post it here. But I haven't. Perhaps theres a forum somewhere where I can go become part of a community and get this to work. But I don't have the time or patience for that right now - a pity, yes.

I can't find a way to configure this firewall. In short, I want to add Synergys support: iptables -I INPUT -p tcp --dport 24800 -j ACCEPT

Here are my attempts:

 706  yum install system-config-firewall
 707  system-config-firewall
 708  yum install firewall-config
 710  yum remove system-config-firewall
 711  firewall-cmd 
 712  firewall-cmd STATUS
 713  firewall-cmd --state
 714  firewall-cmd --port=24800/tcp --service=synergys
 715  firewall-cmd --passthrough --port=24800/tcp --service=synergys
 717  firewall-cmd --state
 718  firewall-cmd --query
 719  firewall-cmd --disable
 720  firewall-cmd --panic
 721  man firewall-cmd 
 722  history | grep firew

No help whatsoever. So I just run the iptables command - but how long will it work? Do it put it in rc.d? ...

What have I learnt: Yes, s-c-firewall is incompatible with firewalld. firewall-config doesnt exist. Can't find it. --service commandline option isn't a comment field.

[root@fc17 ~]# yum install firewalld-config
Loaded plugins: langpacks, presto, refresh-packagekit
No package firewalld-config available.
Error: Nothing to do
[root@fc17 ~]# yum install firewall-config
Loaded plugins: langpacks, presto, refresh-packagekit
No package firewall-config available.
Error: Nothing to do
[root@fc17 ~]#


I fully agree with above. We just had a debate about this in irc. How this page hops directly into details without describing what zones are, how those are related to services and interfaces and how those should be used. After skimming this page through I still don't know and thus cannot apply the details from this page when don't have the big-picture what I'm doing. Same with the provided GUI, it just lists those but zone-concept still remains unclear. That with security is not a very good starting point. Note that I maintain multiple iptables based systems and have history from Cisco, Enterasys, CheckPoint FW1, Stonesoft firewall and many other network security systems. I would change that main article myself if I knew what I would be writing. But I don't, so I wont. Pushing this into production release without introducting people into it wasn't that smart after all. Tuju (talk) 12:08, 2 February 2013 (UTC)

[edit] Zones small tutorial and example

Firewalld zones could be used for several different purposes. Two examples:

(1) To define and switch firewall configurations easily for a portable computer (laptop, linux tablet). This would use zone “public” for limited inbound connections appropriate for use in a library or coffee shop; zone “work” for work-based inbound connections; and zone “home” for unlimited inbound connections in the home internet where the home router was trusted to block all inbound connections from outside the home. In this usage, the internet interface (or, more conveniently, each network manager “connection” associated with that internet interface) would be mapped to a different zone as the computer was moved from place to place.

(2) To define “zones of trust” for a server. If the server is public facing (for example, where a router has port forwarding to that server for HTTP, HTTPS, and SSH -- TCP ports 80, 443, and 22 respectively), then the “dmz” zone could be configured for unlimited access to those and only those services.

The following elaborates use (2): using zones to implements "zones of trust" for a home-based server.

Both network interfaces (e.g., “em1”) and address ranges can be associated with a zone. An interface can be associated to no more than one zone (although more than one interface can be associated with the same zone). Additionally, IP address ranges can be assigned to a zone.

For incoming connections:

(1) if the connection is coming from an interface (“em1”), then that connection can go to any service trusted (open) in that interface's zone.

(2) if the connection's IP address is associated with a zone (by virtue of being in any of the ranges of IP addresses associated with the zone), then that connection can go to any service trusted according to the IP address.

For example, the a home server is a web host (to be accessed from anywhere via a NAT router), supports SSH (for external command-line management and SFTP) and also is used as a DNS server inside the house. The main workstation (not this server) hosts a number of VMs, each with it's own IP address, so the DNS tables include about 20 devices. The server provides file storage (via NFS) to a few home workstations, but not to just anybody in the home. Also, it stores a bunch of MP3s that are served via MediaTomb to any renderers in the home (Android tablets, PS3, etc.). Finally, this server is a print server, so “ipp” needs to be available to anyone in the home.

SSH has been configured to refuse “root” logins and also to require RSA or DSA credentials (that is, username/password logins are not permitted). This configuration resists all dictionary-based hacking attempts.

The router is configured to forward ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) to the home server.

The router is a DHCP server that gives out addresses 192.168.0.64 and above; all the home workstations and their VMs are given fixed IP addresses of 192.168.0.2 and above.

To set this up, three zones are used:

(1) Zone “dmz” is associated with interface “em1”. It allows services ssh, http, https. (2) Zone “home” with sources 192.168.0.1/25 (that's 192.168.0.1 to 192.168.0.126). It allows services dhcpv6-client, dns, ipp, ipp-client and for Mediatomb (a DLNA-based media server) TCP port 49152 and UDP port 1900. (3) Zone “trusted” with sources 192.168.0.1/26 (that's 192.168.0.1 to 192.168.0.62). It allows services nfs.

Notice in the above that IP address source ranges can overlap, so IP address sources can be assigned to multiple zones. An IP address 192.168.0.14 arriving on interface “em1” matches all three zones.

From outside the home network, an laptop/tablet/phone FTP client can access the server using SFTP and a public RSA key separately installed (supported by most FTP clients). This is possible because the router forwards port 22 to the host's “em1” interface and the firewall's “dmz” zone allows the inbound connection (and SSH authenticates the credentials).

Inside the home, a workstation (fixed IP 192.168.0.22) can point to the home server for DNS so it can translate “private” DNS names. A laptop (dynamic IP 192.168.0.67) configured with DHCP whose DNS server IP set to the home server can also translate “private” DNS names. This works because both IP addresses are in the 192.168.0.1/25 range that is a source for the “home” zone and that zone allows DNS access. They can also access the home web server because they are both accessing the home server through its “em1” internet adapter, and therefore the services and ports open in the “dmz” zone are available inside the home as well.

A PS3 is configured to use DHCP; suppose today it is assigned dynamic IP address 192.168.0.66. It can find MediaTomb (via UDP broadcast to port 1900) and get streaming media from the home server through TCP port 49152. This is all possible because its IP address is in the source range for the “home” zone. Also, the workstations and VMs can also play streaming media because their (static) IPs are also in the “home” source range.

However, only the workstations and VMs with statically assigned IP addresses can use NFS. The PS3 (for example) does NOT have an IP address in the “trusted” zone's acceptable range, and therefore cannot connect to the “nfs” service. Note: the firewall by itself doesn't make “nfs” secure since one can assign any IP address statically.

--Richbr4pi (talk) 23:01, 25 January 2014 (UTC)