New User to pfSense - some doubts

HansSolo

@johnpoz said in New User to pfSense - some doubts:

So I see this warning

Also consider protecting just the specific open WAN ports and it's just as important to protect the outbound LAN traffic.

And if you open the advanced, you can limit to specific ports..

But yeah if just set to inbound us, it creates this rule
===[  Aliastables / Rules  ]================================

Firewall rule changes found, applying Filter Reload
Yeah this is a HORRIBLE implementation... Just freaking HORRIBLE!!

That should be limited to wan address on specific PORTS, unless the user changes it... Then that would be on them.. But I can see how new users might just open wide their wan... Arrrgghhh!!

So I'm not nuts or insane?......
I gave the system the benefit of the doubt that it was performing some kind of "magic" on the back end.

Then checked to see if my system was compromised in any way from outside my network and couldn't find any compromises or openings etc. I agree those settings could be dangerous but again, it didn't seem to allow the access it appears it would. maybe because of redundant filters I had setup on the Opt1 and LAN interfaces.

I ALSO changed the port on which the WebConfigurator resides early on. I didn't like it on port 80 at all.

johnpoz

In the past when I had played with this, I had always just used the aliases in my own rules.. This really needs to be changed to force the user to easy select their wan address as destination or the any, vs forcing them to use an alias. And it should WARN them about ANY as destination especially above all other rules on the wan,

HansSolo

@johnpoz said in New User to pfSense - some doubts:

In the past when I had played with this, I had always just used the aliases in my own rules.. This really needs to be changed to force the user to easy select their wan address as destination or the any, vs forcing them to use an alias. And it should WAN them about ANY as destination especially above all other rules on the wan,

Totally agree.
But would still like to hear from the developer to make sure there is no "back end" magic going on here.

Seems to write something like this they would know better, right?

HansSolo

also, Jon....this is probably a totally different topic but....
You said you have no WAN rules, only outgoing LAN rules.....correct?

If you have no WAN rules, then everything inbound at least (probably outbound as well) "should" be blocked by default, right? WAN is your "gateway" to external ie the Internet.

So how then does anyone get to your server?
Only way a server is available to the public that I know of is specific WAN rules that allow traffic inbound.

Such as ALLOW from * * TO 'server address' 'server port'

And most often, it involves Natting from your Public IP address to the server's IP (which is usually Opt1)

Just curious. Always ready and eager to learn something new.

stephenw10

Yes, that's true. Without any pass rules on WAN no external clients can open a connection to a server behind the firewall.

However traffic from LAN side client can still open outbound connections as long as there are pass rules on LAN to allow it in.

Sorry, initially I though that was what you were trying to do. It's a common misconception to put pass rules on WAN to allow traffic out.

Technically the pf packet filter that pfSense is built on can filter traffic in both directions on all interfaces. pfSense configures it to allow traffic out on all interfaces by default and filter traffic in according to the user rules.
The only exception to that are rules on the floating tab that can be applied outbound. But don't worry about that until you're familiar with the normal rules.

Steve

Gertjan

@HansSolo said in New User to pfSense - some doubts:

You said you have no WAN rules, only outgoing LAN rules.....correct?

I guess I can answer that one on behalf of @johnpoz (as he said so above) :
He has some pass firewall rules on his WAN interface, created when building the a NAT rules.
An incoming UDP port 123 directed to his NTP server.
An incoming TCP port 80/443 directed to his Plex server.
Probably a VPN UDP port too.

chpalmer

@HansSolo

How do you have your port forwards configured? Specifically "Filter rule association" ??

chpalmer

@johnpoz said in New User to pfSense - some doubts:

@HansSolo said in New User to pfSense - some doubts:

So are you also agreeing that pfSenseBlockerNG has incorrectly configured their settings?

NO!!! I just ran through the wizard and it didn't create single rule on my WAN!!

pfBlockerNG 2.1.4_16 here.. Yep- no wizard on NG.
It does not do any good to modify those rules because an update will rewrite them back to the way they were..

HansSolo

@chpalmer said in New User to pfSense - some doubts:

@johnpoz said in New User to pfSense - some doubts:

@HansSolo said in New User to pfSense - some doubts:

So are you also agreeing that pfSenseBlockerNG has incorrectly configured their settings?

NO!!! I just ran through the wizard and it didn't create single rule on my WAN!!

pfBlockerNG 2.1.4_16 here.. Yep- no wizard on NG.
It does not do any good to modify those rules because an update will rewrite them back to the way they were..

Whoa!
I just ran into this on my pfSense machine.
I had changed ALL those rules and then a bit later when I went back it had reset them ALL to ANY ANY.

Anyone know what's going on? Is it SUPPOSED to re-write them back to ANY ANY ????

stephenw10

That's what pfBlocker does, it creates and maintains those rules. But you can set what port and destination it uses:

Or you can set the list action to alias only and then add the rules manually. Which is what I would do.

Steve

johnpoz

@HansSolo said in New User to pfSense - some doubts:

You said you have no WAN rules, only outgoing LAN rules.....correct?

What I meant is pfblocker didn't create any wan rules... Only a lan rule filtering traffic to ad sites, etc.

I do have multiple inbound wan rules that "I" created..

HansSolo

@stephenw10 said in New User to pfSense - some doubts:

That's what pfBlocker does, it creates and maintains those rules. But you can set what port and destination it uses:

Or you can set the list action to alias only and then add the rules manually. Which is what I would do.

Steve

I think I'll do it like you do , manually.
Wasn't aware of this configuration requirement. That's on me.

Thanks for this. It's all a learning curve.

chpalmer

@HansSolo said in New User to pfSense - some doubts:

I think I'll do it like you do , manually.
Wasn't aware of this configuration requirement. That's on me.

Im not sure Id call that a configuration requirement but more an option.

In my case I block from a few areas to several addresses. So an any destination works for me.

As mentioned don't allow all to any on your WAN..

chpalmer

@chpalmer said in New User to pfSense - some doubts:

@HansSolo

How do you have your port forwards configured? Specifically "Filter rule association" ??

BBcan177

@HansSolo said in New User to pfSense - some doubts:

So maybe, as I mentioned, it's a problem with the GeoIP database. Giving pfsense the benefit of the doubt, I'd bet a nickel that the foreign IP addresses making it through are in the USA database because those block do occasionally change the countries they are allocated to. ONE of the IP's that whistled right past pfsense is this one....45.65.128.250

This IP is in South America (Brazil) as per MaxMind:

mmdblookup -f /usr/local/share/GeoIP/GeoLite2-Country.mmdb -i 45.65.128.250

{
  "continent":
    {
      "code":
        "SA" <utf8_string>
      "geoname_id":
        6255150 <uint32>
      "names":
        {
          "de":
            "Südamerika" <utf8_string>
          "en":
            "South America" <utf8_string>
          "es":
            "Sudamérica" <utf8_string>
          "fr":
            "Amérique du Sud" <utf8_string>
          "ja":
            "南アメリカ" <utf8_string>
          "pt-BR":
            "América do Sul" <utf8_string>
          "ru":
            "Южная Америка" <utf8_string>
          "zh-CN":
            "南美洲" <utf8_string>
        }
    }
  "country":
    {
      "geoname_id":
        3469034 <uint32>
      "iso_code":
        "BR" <utf8_string>
      "names":
        {
          "de":
            "Brasilien" <utf8_string>
          "en":
            "Brazil" <utf8_string>
          "es":
            "Brasil" <utf8_string>
          "fr":
            "Brésil" <utf8_string>
          "ja":
            "ブラジル連邦共和国" <utf8_string>
          "pt-BR":
            "Brasil" <utf8_string>
          "ru":
            "Бразилия" <utf8_string>
          "zh-CN":
            "巴西" <utf8_string>
        }
    }
  "registered_country":
    {
      "geoname_id":
        3469034 <uint32>
      "iso_code":
        "BR" <utf8_string>
      "names":
        {
          "de":
            "Brasilien" <utf8_string>
          "en":
            "Brazil" <utf8_string>
          "es":
            "Brasil" <utf8_string>
          "fr":
            "Brésil" <utf8_string>
          "ja":
            "ブラジル連邦共和国" <utf8_string>
          "pt-BR":
            "Brasil" <utf8_string>
          "ru":
            "Бразилия" <utf8_string>
          "zh-CN":
            "巴西" <utf8_string>
        }
    }
}

Also see these threads:
https://www.reddit.com/r/pfBlockerNG/comments/b8r18c/cannot_load_alias/
https://www.reddit.com/r/pfBlockerNG/comments/aqb4pl/geoips_not_matching_correctly/

BBcan177

@HansSolo said in New User to pfSense - some doubts:

As far as the country blocking, do you find that countries that are supposed to be blocked sometimes slip through?
So far in my experiments with pfsense, too many are "slipping" through and being so new to pfSense, I'm not sure why.
Do you know a way to examine the pfSenseBlockerNG files to see if a specific IP address is in it? I'd like to confirm just a few times that foreign IPs that are supposed to be blocked are NOT in the files just so I know why they're getting through because if they ARE in the file and still getting through, that's a whole different story.

I think your issue is that you selected "Represented ISOs" in the North America Tab:
https://dev.maxmind.com/geoip/geoip2/whats-new-in-geoip2/

BBcan177

@HansSolo said in New User to pfSense - some doubts:

So I'm not nuts or insane?......
I gave the system the benefit of the doubt that it was performing some kind of "magic" on the back end.
Then checked to see if my system was compromised in any way from outside my network and couldn't find any compromises or openings etc. I agree those settings could be dangerous but again, it didn't seem to allow the access it appears it would. maybe because of redundant filters I had setup on the Opt1 and LAN interfaces.
I ALSO changed the port on which the WebConfigurator resides early on. I didn't like it on port 80 at all.

The package is doing exactly what you asked it to do.

You selected "Permit Inbound", so it will create a firewall rule that will allow "any".... If you want to further refine the firewall rules, at the bottom of each GeoIP/IPv4/IPv6 Tab, there is an "Advanced Inbound/Outbound" Firewall rule settings, where you can define Ports and Destination Aliases etc that will be used for that rule.

You can also use "Alias Permit" and then the package will only create and maintain the IP aliastable and you can manually create your firewall rules as you require for your needs.

Click on the Blue Infoblock icons in the IPv4/IPv4/GeoIP tab beside the "Action" setting, and it will detail this some more.

BBcan177

@HansSolo said in New User to pfSense - some doubts:

Whoa!
I just ran into this on my pfSense machine.
I had changed ALL those rules and then a bit later when I went back it had reset them ALL to ANY ANY.
Anyone know what's going on? Is it SUPPOSED to re-write them back to ANY ANY ????

Again, Click on the Blue Infoblock Icon for the "Action" setting, and its all detail there.
"Auto type" rules are always controlled by the Package and the settings that you configured. Every cron run will move the rules as per the defined settings that you configured in the package.
If you want to manually create your own Firewall Rules and use a pfBlockerNG IP Aliastable, select any of the "Alias" type Action settings. Be sure to prefix the Firewall rule description with "pfb_" so that the Alerts tab and the Widget find these rules accordingly.

BBcan177

@johnpoz said in New User to pfSense - some doubts:

Yeah this is a HORRIBLE implementation... Just freaking HORRIBLE!!

That should be limited to wan address on specific PORTS, unless the user changes it... Then that would be on them.. But I can see how new users might just open wide their wan... Arrrgghhh!!
Or anything behind pfsense if they had a routed netblock, etc. etc.
paging @BBcan177 again, I don't see how such a thing would be ok... Ultimately its on the admin of the firewall to understand what they are doing, and what is set... But pfsense does try and keep the users from shooting themselves in the foot.. This is not doing that at all..

Anyone is more than welcome to create a PR, I am obviously not capable.

johnpoz

An ANY rule is horrible dude... You open up all services listening on the wan to the the internet, or atleast the sources they pick from the list, like North America. In the case of ipv6 or a routed subnet the whole network behind pfsense even.

If your going to do an allow for sources it needs to be limited to the ports they have forwarded.

At min there needs to be a HUGE warning... I mean HUGE these users love to shoot themselves in the foot.. If not their heads..

Blocking specific sources before the port forwards is fine with an any dest.. But an allow with any as destination is disaster waiting to happen.. User doesn't change their default admin password, and now their gui is exposed is low on the list, if routed or ipv6 it exposes everything.. This really needs to be addressed!!!!

edit: A safer approach would be for pfblocker not to create any rules on the wan, let the user just use the aliases pfblocker creates in their own rules and or port forwards.. If you want to create the rule on the lan to block access out to back stuff, or ads that fine... But creating a rule on the wan that can open up the whole network is not worth the risk, even if the user confirms they understand the implications... Which they prob don't in many cases.