Standard rule sets?
-
Are there standard rule sets available for download somewhere?
What I mean a bunch of rules that assuming a LAN/WAN setup open up the most commonly used ports (mail, web, ssh, VoIP, etc)It would be much easier to load such rules and as needed disable some of them, then trying to have to recreate such a rule set from scratch. It seems right now everyone is reinventing the wheel over and over again each time they set up a system, potentially making key mistakes, rather than using a carefully reviewed set of standard rules that can be trimmed down/disabled as needed.
Such a rule set might also help establish naming conventions, common aliases, etc. which would help various set ups to be more readable/understandable by people other than the person who set things up initially.
-
@rcfa: I beg you pardon, but the key value that was nailed down over and over again in my times of college and beyond when it came to security is: DENY ALL. Start from that. Allow what has to be there.
A default rule set or even sets would defeat exactly that one rule that everyone handling security has. To start with nothing coming in and out when setting up the system. Not the other way round. As I see the benefit in perhaps making less mistakes to begin with, I see other flaws coming in very fast: Someone downloading the ruleset without even knowing what he/she's doing. Thereby opening valuable information to the public (aka evil) internet (perhaps a mail or webserver that was to remain internal only). Or not deleting all (un)necessary rules that aren't needed. And someone later adds a server that - BOOM - is instantly online without you wanting that. Just because there was a NAT rule or Firewall rule or even an alias you didn't make yourself and didn't consider harmful at that very moment.I'm not completely against this idea - don't get me wrong on that - but that opens up another can of worms I'm very wary about as I can see many folks on this forum "experimenting" with pfSense and learning their way around. If you dumb that process down to "click here, choose template, fire, forget" you will soon have other complaints as "it's complicated". More along the lines of "pfSense exposed my host/network/xy to the internet and so I was hacked".
As of a more general approach, one could use a stripped-down backup.xml of the rules-part of pfSense and modify it to your need so you can import it into a new appliance with - for example - a initial set of Aliases you always use and a few selected rules. Could be a bit difficult though, as the rules are bound to the IF-Names, that would have to match. But if you always use wan, lan, opt1 in the same configuration, that would be a possible start. Nevertheless I find blind-restoring of rules or rulesets dangerous, especially in a live setup.
Greets
Jens -
I am with JeGr, default stance should always be deny. Rules should be created as needed to allow the access that is allowed.
Now the default lan rule on pfsense out of the box is any any outbound, since this common configuration for any soho router. And allows users to use it out of the gate. While it might not be a great security stance if it was deny all on the lan out of the box.. New users would never get to the internet and give up would be my guess. Flood the forums, etc.
We see enough of those when they try and add a opt interface with the default deny as only rule.
The admin of the firewall needs to configure the rules as best to fit their policy. You have mentioned some standard ports. Simple enough to put those ports into an alias and create the 1 rule containing those if that is what you desire.
-
The concept of a "standard rule set" is impossible just by the nature of such things. What I need on my network is likely vastly different than what you need on yours. That said, there are a number of examples of rulesets for common scenarios in the 2.1 book that would satisfy the general need, guiding you through common scenarios, like only allowing SMTP to and/or from authorized mail servers, general egress filtering practices, a range of things.
-
Why not having a firewall-rules step throughout the setup wizzard, with the choice to allow ANYthing (with a hint, that it's not safe) or to allow just http/https and giving a hint to the forum/book/whatever on how-to add additional services?
-
@chemlud: Actually, I'm thinking a "rule wizard" like the traffic shaper wizard with a few example settings and questions could perhaps be helpful to see the first few rules created. If you look at them afterwards, modifying, copying or creating them should be a bit easier.
-
Not really related to the OP question about rulesets, but slightly related to 'naming conventions, aliases, etc' : there was a thread last year that I found helpful, where people contributed their sets of 'standard setup changes' for new pfSense installs. IE, what are your favorite tweaks for a new install? Sorry, I can't find the topic right now (so I guess this post is kind of useless), but I'll update it when I can dig a little deeper.
-
Well, two key points:
a) I was talking about standard rule sets that one can LOAD into a configuration, I wasn't talking about the system having these rules active by DEFAULT. There's a difference between a STANDARD rule and a DEFAULT rule. So, NO, I'm not suggesting that the firewall, after initial setup should be in any other state than the deny all setup.
b) while pfSense may be used in many different more or less exotic situations, I think it's fair to say that probably 75% or more of installations consist of a simple WAN/LAN or WAN/LAN/DMZ setup. It's also fair to say, that most users will want to be able to use Mail, Web, Skype, Viber, , AIM, access the AppStores (be that Android or Apple), etc.
So to have rules for such and similarly standard services, such as DNS client/server, mail server (IMAP/SMTP/POP), is something a large number of people have to do over and over from scratch. To be able to go to the rule page, and have a wizard or a load rule set button, from where one could load predefined rule sets would be great, particularly if one could also save rule sets, allowing users to share rule sets, or when setting up multiple systems, setting up one, and then saving the rules, and loading them on all the similarly configured devices.
I think IIRC one can save an entire configuration, and then just load a subset of it, but that's not quite as convenient or intuitive than just specifically saving/loading/sharing rule sets. -
As of a more general approach, one could use a stripped-down backup.xml of the rules-part of pfSense and modify it to your need so you can import it into a new appliance with - for example - a initial set of Aliases you always use and a few selected rules. Could be a bit difficult though, as the rules are bound to the IF-Names, that would have to match. But if you always use wan, lan, opt1 in the same configuration, that would be a possible start.
That is more or less what I was asking for, except with the addition that such ruleset.xml files would have a standardized place to live on the file system, and that certain templates would be there upon installing the system, such that they can be loaded on demand as a starting point or for simple SoHo setups.
Also, since rules can exist, but still be disabled, it wouldn't be difficult to have a rather extensive set of rules covering lots of services, but with all the rules disabled. That would still correspond to a denyAll setup, but it would make enabling certain services simply a click on checkbox and save affair, rather than a research port and protocol, set up rule, debug, etc. affair. After all, not everyone does network security for a living, so maybe aside from 80/443/22 the rest of the ports I have to go hunting for, because I don't and don't want to remember them for the two times in five years I need to know them.
As for interface naming: couldn't creating interface groups for WAN and LAN interfaces do the job, and then using these? -
b) while pfSense may be used in many different more or less exotic situations, I think it's fair to say that probably 75% or more of installations consist of a simple WAN/LAN or WAN/LAN/DMZ setup. It's also fair to say, that most users will want to be able to use Mail, Web, Skype, Viber, , AIM, access the AppStores (be that Android or Apple), etc.
@rcfa: What you describe is (mostly) outgoing traffic, that is allowed by the default any->any rule on LAN. Not sure what's complicated in bringing them alive, as almost any of them have stateful connections. Access to AppStores or (bigger) Mailclusters wouldn't be easy to do with a template either, as those often use a cluster of hosts or a CDN that you would have to allow with the rules IF you ship pfSense with all blocked per default (opposed to the current state, where NAT and LAN ANY rule is in place). But I haven't heard many complaints about mail, DNS, messengers etc.
-
If there was a standard to be had, I would say explicitly blocking ports 1-1023, so you can't accidentally have someone open up a service port. UPNP handles opening up ports for games. No real reason to have a standard for opened ports.
-
I am a NOOB and understand/agree with the fundamentals of both sides.
I was actually coming here to find out if there were "Downloadable Templates". I am a noob, and I'm damn proud to be one actively learning to get to another "Plane of Status". LOL
The Reason that "Downloadable Templates would be invaluable, is that it allows us to download rules for an interface, based on an existing set of variables which are in the description, and to try to adjust those rules where necessary.
The problem with jumping on a fresh page of PFSense, is the Vocabulary. I have tried multiple times to use YouTube, PFSense Forum, Outside Forums, "Definitive Guide…" (Outdated), the "question mark" on the PFSense page that I am working on (Most seem as useful and up to date as "Definitive Guide", and a number of other resources... and, I am in just about the same bowl of soup as I was 2 weeks ago. And, not a ton further along than a few months ago when I tried to set it up on vacation.
Let me be crystal clear... I love the PFSense Project, the resources provided (Even the outdated or limited ones), and all that is done. So, I offer the most sincere of apologies if anything that i've stated, has come across as judgement. That is not my intent.
I am merely attempting to convey that a new project, in a new OS, in a new language, with new menus... can be quite overwhelming.
Education, especially for DIY enthusiasts is often not only gained in the doing... but the value of resource material. The best resource material (I find), is the resource material that either allows, an adjustable template, a follow along video... and Optimally both.The Value of the template, lies in that we can download the template for a rule, or for an interface, etc.. For the quick fixers... they are on their way to cry when whatever else doesn't work, or to buy a Belkin or something. For those of us who want to learn, we can open the window with the template, and open either an existing and/or a new menu, to see what was done for that template, so that we can understand the "Menu Verbiage" and how to apply it to firewalls.
Granted, those rules would need a few descriptions on what does what (LINE BY LINE), but... I'd be $1M that if we had those templates, with accurate descriptions... within 3 quarters, you would see a 30% (or more) drop in your DIY Forum traffic, regarding new issues without previous references.
There would be much quicker resolutions as well, as a person could share which template that they were using, or basing it off of, and why, and people would be able to help each other in the forums, before there was much need for a hero member or admin.
I apologize for being so "verbose". However, I believe that templates and Line by line descriptions for them, would aid us, and free you guys up to to bigger and better things for the project. And, I truly hope that the team at pfSense will consider it...
Grateful Appreciation,
Sekrit_Skworl -
Most people that need "templates" use NAT right now, it'll be a while before they have IPv6. This means they will more than likely not be using a transparent firewall and can't just open ports, but also need to assign an IP address to forward to. This alone makes premade rules almost entirely useless.
Another issue you get with people who need this kind of help is they don't understand what they're doing. They get this huge list of "standard" rules and just add them all ahead of time before they even need them. To top it off, they have no idea what the rules are actually doing. At this point, you might as well just remove the firewall all together and open them directly up to the Internet.
We don't need "standard" rules for opened ports, at best we need a one-stop-shop of how each popular protocol and game uses which ports, and let the end user add them theirselves.
-
Well, i thought about what is a big part of the tedium of creating rules:
Looking up all the port and protocol combinations.
Worse, even if one sets up aliases for the ports for various protocols, one still has to go back and look up if the thing uses UDP or TCP or both.
Other things don't use any ports, because they use ESP, ICMP, whatever…So a massive usability improvement could be achieved without neglecting the concern of those who question the value of standard templates:
Improve the alias functionality to the point where one can define an entire protocol: allowing the user to define a protocol with all that belongs to it: port number(s) [as a combination of lists and ranges], protocols, etc.
That way, when setting up a new rule, one only needs to specify the interface, the IP version, the protocol name.
Such aliases should be possible to export, such that once defined on one system, one can load them on another, and doesn't have to go through the chore of looking all this crap up all over again. Standard stuff, such as NFS, SSH, HTTP, etc. could then be either provided as standard aliases or the templates could be shared by the community.
This would solve about 88.88% of what standard templates would solve, while at the same time being more generic and covering a wider range of deployment scenarios.
-
@rcfa: That would be a nice touch and reminds me of the Juniper setup of ports (you can group different types of ports together like udp/137-139, tcp/443, icmp-reply and attach it to the same from/to rule.
Problem is: PF (not pfSense but the underlying packet filter) isn't working that way. By introducing such a feature, pfSense would need the logic to recognize differen protocol/port combinations and convert that to a sane and workable ruleset. ATM pfSense mapps pf functionality to a WebGUI. With a job like that, much more logic, conversions etc. were needed and it would be more likely to introduce bugs or misbehavior, as to what the rule would actually do or not do, than what is now.
I can't speak for the project (leaders) but that seems like a big/huge chunk of work.
-
I've thought about that before several times. It would be useful, but it would be a lot of extra work and though it might help in some cases, it would make other parts more difficult/less intuitive. (e.g. when does a protocol choice on a rule get trumped by a protocol choice in an alias?)
-
I've thought about that before several times. It would be useful, but it would be a lot of extra work and though it might help in some cases, it would make other parts more difficult/less intuitive. (e.g. when does a protocol choice on a rule get trumped by a protocol choice in an alias?)
That's exactly what I meant. The priorization of that would be tricky to say the least. As PF rules don't mingle protos and port together, that would mean extra work to unravel the aliases into actual rules and what is the order of them. If PF's syntax were more along the lines of " <action>on <interface>src <ip alias="" table="">port <port group="" alias="">to <ip alias="" table="">port <port group="" alias="">[flags <flag flagmask="">]" and [port] was defined not as numerical but as combination like udp/137 or tcp/443, that would be easier to achieve in the GUI or with aliases alltogether. But as the "proto" section declares the protocol for the rule, it's quite a bit more complicated.</flag></port></ip></port></ip></interface></action>