Best Practice for "permit" rules by location
-
After reading … and reading I moved ahead with pfBlockerNG for a limited set of blocking.
The good news is that things seem to be working as we wanted, but the pfSense admin UI seems to be much slower when a NAT or rule needs to be updated. Also I'm wondering if I have not created a bit of a maintenance nightmare going forward.
Looking for some critique/advice on how we did this.
Our first objective was to reduce the our surface area for attacks. We have a number of authenticated services, a number of simple websites -some have quite a limited audience, others a much broader audience (e.g. customers/prospects). Both were getting banged pretty badly.
We first tried to just use each geographic area/continent and the list action of "Permit Inbound" or "Permit Both" - but we had too complex a mix of services for a single "List Action" to handle.
So we decided to let pfBlockerNG build the litss we wanted but we would apply these to the firewall rules we wanted.
Since our current and prospective customers are only in three of the seven continents (and then a subset of those countries) we did the following:
-
For each continent selected the countries we wanted to permit, set the List Action as Alias Permit. (we also set Enable Logging but I'm wondering how this would apply to Alias Permit)
-
Under the IPv4 option created a list composed of the "/var/db/aliastables/pfB_<continent>_v4.txt" files for each continent. Actually we created two lists "PUBLIC" and "AUTH" - the "AUTH" (authenticated) list was more restrictive (fewer countries).</continent>
Saved everything, pressed update and made sure the pfSense alias was created and visible once the update finished.
Next we went through our NAT rules and entered one one of the two lists as the "Source Address" on each NAT rule. And "voila!" it works. It's really nice to look at pfSense Firewall-NAT display and see what audience (IP list) applies to each service we've got forwarded.
OK - so what's wrong with this? I already mentioned the performance issue (I don't think I'm imagining this). Another issue is that we've got about 70 NAT rules- if we need to make changes it's a real effort. I imagine we'll be refining these lists to be more granular as our business is expanding - we'll have more than two IP lists for sure. We are working to reduce the NAT rules in a number of ways (moving to remote access/VOIP to a VPN, etc) but that's not happening immediately.
I'm wondering if it makes sense (or even if it's possible) to do the following:
-
Remove the IP list from the "Source Address" for each NAT rule. It was nice, but …
-
Manually code a small number of firewall rules that has an IP list for it's source address and an ALIAS listing the applicable service ports for the "Destination Port".
Would that make less work for the overall pfSense engine? If not are there other ways we could do this?
Also, we currently have Snort running to in warning mode. Once we are stable with our approach for pfBlockerNG, we'll be looking at turning Snort on.
Thank you much - Richard
-
-
Instead of using the Pre-Defined Continent Pages, you can goto the IPv4 tab, and create a single Alias for all the Countries that you want to whitelist…
In the Source Fields, you can reference a Country as follows:
/usr/local/share/GeoIP/cc/US_v4.txtThis alias can then be referenced in your Rules as required… You can also disable logging for these "permit" rules if you do not wish to log that traffic...
-
Sorry, did not confirm sooner - thank you for the tip.
That seemed to be working - until we received a report yesterday.
We had created an IPV4 alias as you suggested for three countries and applied that alias as the allowed source address for a NAT rule to a website:
-
Format - State - Source - Header/Label
-
Auto - On - /usr/local/share/GeoIP/cc/US_v4.txt - web1_US_v4
-
Auto - On - /usr/local/share/GeoIP/cc/CA_v4.txt - web1_CA_v4
-
Auto - On - /usr/local/share/GeoIP/cc/AU_v4.txt - web1_AU_v4
We got a report that IP address 192.99.57.142 was not able to access the site. We can find an entry that includes that address in "/usr/local/share/GeoIP/cc/CA_v4.txt", the line, with before and after is this:
192.99.44.0/22 192.99.48.0/20 <-- 192.99.64.0/19But when we look in the created alias rule "/var/db/aliastables/pfB_PERMITTED_AUTH_IP.txt" that address range does not appear to be covered - there's a gap:
192.99.41.0/24 192.99.97.0/24What are we missing?
BTW, I'm not 100% sure what the "Header/Label" is for. Does it need to be unique across all aliases?
-
-
Did you define the "Update Frequency" setting? This determines how often the Alias is updated…
-
What are we missing?
If you look further down the alias file, you will find another section around line 54321 with
192.99.44.0/22 192.99.48.0/20 192.99.64.0/19 -
Did you define the "Update Frequency" setting? This determines how often the Alias is updated…
Yes - I did, I even set it to hourly.
-
What are we missing?
If you look further down the alias file, you will find another section around line 54321 with
192.99.44.0/22 192.99.48.0/20 192.99.64.0/19Arrggh! Thanks - I made a (bad) assumption that they would be ordered/condensed for faster lookup. Does that happen when they get loaded?
But, OTOH, not sure why those sites were being blocked since this was a permit rule.
-
But, OTOH, not sure why those sites were being blocked since this was a permit rule.
If you are using Permit for the tables it depends on your choice of
Firewall/pfBlockerNG/General : Firewall 'Auto' Rule OrderIf you are creating your own rules, you have to put the Permit rules before the Block rules.
If it blocks at some point, it should generates a Firewall log entry or a pfBlockerNG alert.
Remember that the pfBlockerNG Floating Rules Block are quick rules.
-
Arrggh! Thanks - I made a (bad) assumption that they would be ordered/condensed for faster lookup. Does that happen when they get loaded?
The alias table seems to be created by appending the file one after the other (US_v4 + CA_v4 + AU_v4 > pfB_PERMITTED_AUTH_IP.txt).
