PfBlockerNG Alias types (Deny, Permit, Match, and Native)
-
I've spent about 20 minutes doing a Google search to try to find the answer on my own, but I'm stumped. From the pfBlockerNG GUI:
'Alias' Rules: 'Alias' rules create an alias for the list (and do nothing else). This enables a pfBlockerNG list to be used by name, in any firewall rule or pfSense function, as desired. Options - Alias Deny, Alias Permit, Alias Match, Alias Native 'Alias Deny' can use De-Duplication and Reputation Processes if configured. 'Alias Permit' and 'Alias Match' will be saved in the Same folder as the other Permit/Match Auto-Rules 'Alias Native' lists are kept in their Native format without any modifications.
-
In Alias Deny, what is being denied?
-
In Alias Permit, what is being permitted?
-
In Alias Match, what is being matched?
Are there any guidelines for which type of alias to select in different circumstances. For example, if one has an IPV4 list composed of multiple blocklists, is that usually when Alias Deny would be chosen because that's when de-duplication would be most effective?
Thanks in advance.
-
-
Hi fmaxwell,
With v1.09 I have added "Adv. Inbound Firewall settings" where you can fine-tune the Inbound Port/Destination instead of needing "Alias" type rules… But for more complicated Rules, you can still use Alias types...
When using De-duplication, all of the Aliases/Lists are acting as a whole. So one list can have a blocked range instead of many lists having the reference to a blocked range. So if you create alias type rules, you need to add rules for all of the aliases to get full coverage...
With "Native", any lists that are used are not de-duplicated so that you can create a rule using that Alias for a certain configuration.... So its all about choice and what you are trying to achieve. Native is also good if you want to block say "Facebook" using the Hurricane Electric list. This way all of the IPs that the list has are used in the Alias without any chance of being affected by other Aliases.
Match and Permit also do not use any De-duplication.
Hope that helps.
-
Hello BBcan17,
Thank you. That's a great help.
I do use aliases as my filter rules tend to get a bit more complicated and I use the same alias in multiple ways. For example, I usually Reject unwanted packets (those from countries or blocklists I've decided to firewall) destined for the SMTP server as I find that rejects get fewer retries. But for other service ports, like Telnet, I let the packets "fall into the bit bucket" using a Block rule. I also employ port aliases fairly extensively in my rules.
As I am not using Reputation and am using the aliases individually, it sounds like Alias Native is the right choice for me.
As an aside, pfBlockerNG is the primary reason why I am running pfSense. It's a really amazing package.
Thanks again, not only for the package, but also for your generous assistance.
-
Hello, I don't think I got that, or at least don't know how to put it in practice in my case, so maybe please clear the following issue for me if you are so kind? I have quite a few (I would consider them "solid") IPv4 alias lists with bad IPs, aggregated from various providers. Also geoblocking.
Now I would love to make sure the search engines don't get blocked, and decided to make an "AllowedSearchEngines" whitelist with IPs collected from here http://www.iplists.com/ (do you people know a better alternative?). Selected "Permit_Both" and got a floating rule. I am under the impression that this rule allows everything from those IPs, overriding my WAN rules? Is there a better way to achieve this? My only floating rules are the pfblockerng ones.
Thank you.
-
Selected "Permit_Both" and got a floating rule.
You should not do that… Permit Both is allowing those IPs to bypass any other Block/Reject Rule on the WAN...
Set that to "Permit Outbound" this way, a device on the LAN needs to make the request to go outbound…
What Lists are blocking Search engines... I am assuming they are IBlock lists... Some of those lists are no the greatest...
-
Thanks, did some reading the same day and deactivated the rule, my impression was correct, confirmed by you. Problem is I really don't know which one of my lists is causing problems. Banned also some countries, maybe some of the search engines are sometimes coming from those… Really don't know.
Any ideea how can I really and safely enable and mantain some search engines list, to ensure those reach my servers, have a /27 subnet pfsense being my gateway? Checked the mentioned link and... Google for example has at least 10 times more IPs than the ones there (tried to manually add those into SNORT, also creating problems, took half a day omg :) ).
-
Hello again, just wanted to report back for future references.
First, had a problem strictly related to me, for the blocked IPs I couldn't see what list it was blocking (was getting only a "-" char? should have known better that a nice piece of software as pfblockerng is smarter than this); I don't know why was happening, but after I completely reinstalled the package from the GUI, to the latest version, reconfigured everything from scratch, I could clearly see the damn Dragon web exploits list blocking Google and Bing… thanks Dragon dudes :) what the hell is that? So disabled that one.
Second; I added the search engines to a pfblockerng list, but specified the alias for my servers and the alias for the ports in the Advanced Inbound Firewall Rule Settings section. And just set the Permit_both behavior. In my case this is fine because, even it if overrides all the rules, it will do so only from the iplists.com specified IPs (the search engines), only on opened ports, only for the servers which of course are exposed anyway on those ports and services.
If something sounds fishy, would appreciate dropping a comment.
-
I have found a little caveat with pfBNG, "Adv. Inbound settings" -
If you set the ports field and leave the "protocol" setting as "any", then pfSense uses "any" in the rule bypassing the ports setting. So set the "protocol" setting to "tcp/udp" or as required. I will address this in the next release.
-
Thanks, tcp/udp here!
-