My trusty old heavily customized firewall-2.4-stronger script doesn't like systemd, so I think firewalld is probably the way to go, but it doesn't seem to support some of the things I need to do without resorting to direct rules, which seems to be undermining the whole "dynamic" idea. Maybe I missed something and there are better ways to do this. This is for a small office that I can't really replicate the setup of, so I can't test it properly without them being offline for a while. Maybe someone could tell me if I'm on the right track before I do that.
There are three relevant ethernet interfaces: 0) cable modem in bridge mode (p35p1) - "external" zone 1) office lan (p2p1) - "work" zone - 192.168.10.0/24 segment 2) dmz for testing client machines (p3p1) - "dmz" zone 192.168.20.0/24
question 1
Internet traffic is being routed successfully from both internal networks out to the world and back. I used to have rules dropping packets between the two localnets, just to keep the customer machines from spreading viruses to the office. Even without those rules, the few tests I was able to try without their network to test on didn't connect. Did I miss something? Do I have to do something more to /enable/ routing between the two localnets? Or is this a fluke/misconfiguration/bad test I need to be concerned about?
question 2
How exactly are zones applied? When a packet wants to be routed from the "work" localnet to the masquerading "external", which zone applies? Both of them? What if the packet is coming from an interface with one zone, from an address with another zone, routed to an interface with a third zone? How do zone rules translate to incoming, outgoing, and forwarding traffic?
question 3
What are the recommended methods of blocking specific localnet addresses or the whole "work" zone from connecting to specific ports on external host ranges, i.e. no FaceBook at work? Would rich rules in the "work" zone be the proper way? It's kinda messy not being able to note the purpose of blocking a specific address when you have 20 or so different address ranges blocked and keep adding more.
question 4
Is there a way to specify classes of destinations, like a destination zone? It would be nice to bundle up the ip ranges or even domains of FaceBook and Twitter and Tumblr and whatnot into a "SocialMedia" class and just block any traffic to those destinations, either from the "work" zone or from specific localnet IPs. Lists of IPs with no notes are pretty unwieldy and not very reliable. Although, the xml file does allow notes, so that's what I'm doing so far. It works, I think, but it's ugly.
question 5
If I want to allow the dmz to only call out to the internet on specific services, like http/https, but no smtp or ftp, is it sufficient to just enable the services I want in the dmz zone? Does that affect connections that would just be masqueraded and forwarded out the external zone? What if I want to temporarily enable ftp from the dmz to one specific address, like a server on the work localnet? Would a rich rule for FTP service with an accept action do it? Would it have to be passive FTP only?
That's a bit more question than I thought I had when I started writing this, but hopefully someone's still reading. Thanks in advance for any guidance you can offer.
On 08/06/2014 09:45 AM, David Andrew Michael Noelle wrote:
question 1 Do I have to do something more to /enable/ routing between the two localnets?
Does it change if you add masquerade into 'work' or 'dmz' ?
question 2 How exactly are zones applied?
https://bugzilla.redhat.com/show_bug.cgi?id=1097960#c1 might shed some light on this.
question 3 What are the recommended methods of blocking specific localnet addresses or the whole "work" zone from connecting to specific ports on external host ranges, i.e. no FaceBook at work? Would rich rules in the "work" zone be the proper way?
We AFAIK don't have a way how to restrict outbound traffic, so I guess 'direct' rules are the only way.
question 4
Is there a way to specify classes of destinations, like a destination zone? It would be nice to bundle up the ip ranges or even domains of FaceBook and Twitter and Tumblr and whatnot into a "SocialMedia" class and just block any traffic to those destinations, either from the "work" zone or from specific localnet IPs.
Sounds like ipsets might come in handy here: https://lists.fedorahosted.org/pipermail/firewalld-users/2014-July/000201.ht...
question 5
I'd rather not answer this as I'm not sure.
-- Jiri
On 08/12/2014 08:37 AM, Jiri Popelka wrote:
On 08/06/2014 09:45 AM, David Andrew Michael Noelle wrote:
question 1 Do I have to do something more to /enable/ routing between the two localnets?
Does it change if you add masquerade into 'work' or 'dmz' ?
Indeed, adding Masquerade to 'work' allows anything in 'dmz', or subnets off of 'dmz', to browse the web server on a machine in 'work'. This does not look particularly secure to me. Does it not also allow the same forwarding, potentially, from 'external' to 'work'?
I found that direct rules in the FORWARD_direct chain also work, but are rather a hassle. Given the choice between all, nothing, or a bit of work to get one port open now and then, I'll be sticking with nothing until individual needs rise. Fortunately, in this case, not allowing communication between the localnets was the whole point of separating them in the first place.
question 2 How exactly are zones applied?
https://bugzilla.redhat.com/show_bug.cgi?id=1097960#c1 might shed some light on this.
Thanks. That does help. And I see Scott Shambarger had similar concerns about allowing too much forwarding.
question 3 What are the recommended methods of blocking specific localnet addresses or the whole "work" zone from connecting to specific ports on external host ranges, i.e. no FaceBook at work? Would rich rules in the "work" zone be the proper way?
We AFAIK don't have a way how to restrict outbound traffic, so I guess 'direct' rules are the only way.
Okay. It's not very dynamic, but neither was our old solution. This is a mite more complicated to edit, though. I see something on the Fedora wiki about "planned" saving of direct rules? Does that mean that there are plans to write direct.xml from firewall-cmd, but it's not available yet? If I were to write a script to read lists of external IPs and ports to block traffic to, I suppose I should have it invoke firewall-cmd to set the direct rules after firewalld is running rather than have it overwrite direct.xml before firewalld starts. That way wouldn't interfere with future direct rule saving, right?
question 4
Is there a way to specify classes of destinations, like a destination zone? It would be nice to bundle up the ip ranges or even domains of FaceBook and Twitter and Tumblr and whatnot into a "SocialMedia" class and just block any traffic to those destinations, either from the "work" zone or from specific localnet IPs.
Sounds like ipsets might come in handy here: https://lists.fedorahosted.org/pipermail/firewalld-users/2014-July/000201.ht...
Hmm. That does look like what I was looking for. Thanks. I'll read up on that.
On 08/13/2014 10:19 AM, David Andrew Michael Noelle wrote:
On 08/12/2014 08:37 AM, Jiri Popelka wrote:
On 08/06/2014 09:45 AM, David Andrew Michael Noelle wrote:
question 3 What are the recommended methods of blocking specific localnet addresses or the whole "work" zone from connecting to specific ports on external host ranges, i.e. no FaceBook at work? Would rich rules in the "work" zone be the proper way?
We AFAIK don't have a way how to restrict outbound traffic, so I guess 'direct' rules are the only way.
Okay. It's not very dynamic, but neither was our old solution. This is a mite more complicated to edit, though. I see something on the Fedora wiki about "planned" saving of direct rules? Does that mean that there are plans to write direct.xml from firewall-cmd, but it's not available yet?
This was added in 0.3.6, see 'Direct Options' in firewall-cmd man page. The wiki page https://fedoraproject.org/wiki/FirewallD#Direct_options was outdated, I've just fixed it. Or you've seen it somewhere else ?
If I were to write a script to read lists of external IPs and ports to block traffic to, I suppose I should have it invoke firewall-cmd to set the direct rules after firewalld is running rather than have it overwrite direct.xml before firewalld starts. That way wouldn't interfere with future direct rule saving, right?
I don't understand the question. You can add the direct rules into both runtime & permanent configuration where the permanent change just modifies direct.xml.
-- Jiri
On 08/13/2014 07:14 AM, Jiri Popelka wrote:
On 08/13/2014 10:19 AM, David Andrew Michael Noelle wrote:
On 08/12/2014 08:37 AM, Jiri Popelka wrote:
On 08/06/2014 09:45 AM, David Andrew Michael Noelle wrote:
question 3 What are the recommended methods of blocking specific localnet addresses or the whole "work" zone from connecting to specific ports on external host ranges, i.e. no FaceBook at work? Would rich rules in the "work" zone be the proper way?
We AFAIK don't have a way how to restrict outbound traffic, so I guess 'direct' rules are the only way.
Okay. It's not very dynamic, but neither was our old solution. This is a mite more complicated to edit, though. I see something on the Fedora wiki about "planned" saving of direct rules? Does that mean that there are plans to write direct.xml from firewall-cmd, but it's not available yet?
This was added in 0.3.6, see 'Direct Options' in firewall-cmd man page. The wiki page https://fedoraproject.org/wiki/FirewallD#Direct_options was outdated, I've just fixed it. Or you've seen it somewhere else ?
Oh, sorry. I must have missed it. I see it now and it works fine. And yes, I believe that's exactly where I saw the "planned" bit.
If I were to write a script to read lists of external IPs and ports to block traffic to, I suppose I should have it invoke firewall-cmd to set the direct rules after firewalld is running rather than have it overwrite direct.xml before firewalld starts. That way wouldn't interfere with future direct rule saving, right?
I don't understand the question. You can add the direct rules into both runtime & permanent configuration where the permanent change just modifies direct.xml.
That's exactly what I was asking. It overwrites direct.xml by outputting the permanent rules as xml, so having my own script also overwrite direct.xml from some other annotated list the machine's owner can add IPs to would conflict with that function. Maybe I can script something with queries and adds, though.
It also outputs none of the comments that might previously have been in that file, so if I want to comment my rules to keep track of why I'm blocking which IPs, I have to keep my notes elsewhere or not use --permanent --direct --add-rule. I can live with that. I just needed to know what I was working with.
Thanks for the replies. I think I've got a handle on this now.
firewalld-users@lists.fedorahosted.org
-
David Andrew Michael Noelle -
Jiri Popelka