New PFSense user needs PFBlockerNG advice
-
@jim1000:
Reported to moderator. Your reply was uncalled for and completely mystifying.
Yeah, feel free. Now, just piss off and help yourself. Incredible. What a waste of time.
-
@jim1000:
Reported to moderator. Your reply was uncalled for and completely mystifying.
Yeah, feel free. Now, just piss off and help yourself. Incredible. What a waste of time.
Same to you. Looked at NAT rules. Still nothing to screen print. PFBlockerNG makes no entries there. For 3500+ posts, you sure don't seem to know very much.
Edit: looked at firewall rules. PFBlockerNG made a few entries there, but they seemed to be related to the package, not thousands of individual rules. Only a few that looked pretty standard relative to the package.
So, back to the original question at entry #1 about the proper configuration of PFBlockerNG from someone who knows what they are talking about this time.
-
Indeed, I'm just a stupid beta tester of this damned package. Welcome to my ignore list.
-
Indeed, I'm just a stupid beta tester of this damned package. Welcome to my ignore list.
Watch me cry – Not.
-
Hi, Jim
Before doing anything to set up your first pfSense, you need to understand what 'inbound' and 'outbound' are. Make it simple, 'Inbound' is the ones from outside world to your WAN, 'outbound' is the ones from your LAN to outside world. By default pfSense blocks all the 'inbound' ones, so your 'Deny inbound' is useless, basically you just need to 'Deny outbound'. Thats what doktornotor told you. The only thing that you need to 'Deny inbound/both' is that you have setup NAT port forwarding or something like that, thats why doktornotor ask you to give some your NAT screenshots.
BTW, instead of denying all except US, why don't you just allow US only, thats simplify your firewall NAT rules, thats also doktornotor suggested to you.
I recommended that you really need to understand the basic firewall thing first before setting up pfSense and all the add on packages.
-
Hi, Jim
Before doing anything to set up your first pfSense, you need to understand what 'inbound' and 'outbound' are. Make it simple, 'Inbound' is the ones from outside world to your WAN, 'outbound' is the ones from your LAN to outside world. By default pfSense blocks all the 'inbound' ones, so your 'Deny inbound' is useless, basically you just need to 'Deny outbound'. Thats what doktornotor told you. The only thing that you need to 'Deny inbound/both' is that you have setup NAT port forwarding or something like that, thats why doktornotor ask you to give some your NAT screenshots.
BTW, instead of denying all except US, why don't you just allow US only, thats simplify your firewall NAT rules, thats also doktornotor suggested to you.
I recommended that you really need to understand the basic firewall thing first before setting up pfSense and all the add on packages.
I completely understand the difference between outbound and inbound. Countries are denied inbound. SPI allows me to still get out and communicate with them if I initiate the contact. All malicious site lists and the like are denied outbound and inbound.
As I have recently discovered, everyone on earth is scanning the internet all the time and searching for open vulnerabilities. Zmap can scan the entire internet in minutes if you have a large enough pipe. Not everyone has noble educational purposes in mind.
Your answers raise the question about why this firewall feature is even required if NAT and SPI are all you need, which is your answer by implication. Ditto with snort, by implication.
Please explain why PFSense does more than a $20 router and is preferable, as you imply the $20 router with NAT and SPI are all anyone needs.
I don't want to whitelist a few sites and be incapable of accessing a few I forgot. I want to blacklist a lot of bad ones. That's why I mentioned the new router specs as I understand more power is needed if you ask for more services and the speed of your connection matters as well.
-
Be nice please, doktornotor.
Jim - do you have any port forwards on WAN? If so, then specifying an alias with US IPs as the source is best to accomplish what you want. No need to process through millions of table entries on block rules when ~36K or so entries as a whitelist would accomplish the same end result. If you have no port forwards or allow rules on WAN, then what you're doing is pointless as everything inbound on WAN will be blocked.
-
@cmb:
Be nice please, doktornotor.
Jim - do you have any port forwards on WAN? If so, then specifying an alias with US IPs as the source is best to accomplish what you want. No need to process through millions of table entries on block rules when ~36K or so entries as a whitelist would accomplish the same end result. If you have no port forwards or allow rules on WAN, then what you're doing is pointless as everything inbound on WAN will be blocked.
Same question as before. Why offer these packages if they are essentially worthless, as appears to be implied by your answer? Also, please look at my Zmap reference above for additional depth about my concerns.
-
@jim1000:
Same question as before. Why offer these packages if they are essentially worthless, as appears to be implied by your answer? Also, please look at my Zmap reference above for additional depth about my concerns.
They're worthless only if you don't have anything open. Lots of people have to forward ports for mail servers, web servers, etc. and their use is a big plus there for many. If you don't have anything open on WAN, you're just adding a bunch of block stuff to process when ultimately that traffic's just going to hit the one default deny block rule and get blocked anyway.
Any kind of port scanner is going to come back with nothing/"stealth" if you have no ports open/no pass rules on WAN. Adding more block rules on WAN when you're already blocking that traffic doesn't accomplish anything but using CPU unnecessarily.
-
@cmb:
@jim1000:
Same question as before. Why offer these packages if they are essentially worthless, as appears to be implied by your answer? Also, please look at my Zmap reference above for additional depth about my concerns.
They're worthless only if you don't have anything open. Lots of people have to forward ports for mail servers, web servers, etc. and their use is a big plus there for many. If you don't have anything open on WAN, you're just adding a bunch of block stuff to process when ultimately that traffic's just going to hit the one default deny block rule and get blocked anyway.
Any kind of port scanner is going to come back with nothing/"stealth" if you have no ports open/no pass rules on WAN. Adding more block rules on WAN when you're already blocking that traffic doesn't accomplish anything but using CPU unnecessarily.
Thank you. This would have been a great answer for post #2.
What is your opinion about malicious lists vs virus checkers? PFBlockerNG makes their use available and easy. I use sandboxie religiously so my risks are low. I'm just asking in general.
also, how does snort figure into this?
Also, thinking abstractly, your best guess … with zmap being so powerful and available, what about unknown risks that might become real someday. Same answer as above?
Also, I am forwarding WAN, 3 ports tcp and udp, to a couple of slingboxes and a sling player. also OpenVPN on port 443 tcp with OpenVPN handling forwarding as needed. Same answer?
-
I did a little research and read that aliases will provide better protection and PFBlockerNG is unclear with respect to being needed. What are aliases and how do you use them?
There's a lot of conflicting info and it's all unclear info for the new user.
I have 3 ports plus OpenVPN 443 tcp open, according to port scan sites.
The open ports are for slingboxes, and along with OpenVPN, may be used at any time by me from an IP address that can not be known beforehand. This, however, is immaterial since any open ports for any purpose from anyone are analogous.
Where is info that answers these questions? I installed PFSense for additional protections that are apparently unneeded? That seems a little unlikely.
How do i use PFBlockerNG for additional protection? It appears following the pfsense html page and other commonly available references will start a flame war if referenced.
Edit: Based on the comments I've received so far, I have decided to disable, not remove, PFBlockerNG as it appears to be a solution in need of a problem. Please correct me if I am wrong.
-
@jim1000:
Also, I am forwarding WAN, 3 ports tcp and udp, to a couple of slingboxes and a sling player. also OpenVPN on port 443 tcp with OpenVPN handling forwarding as needed. Same answer?
I thought you'd mentioned earlier in the thread that you had nothing open on WAN. That changes things. Block all that if you want, but better off creating a US alias then using that as the source in all your WAN rules.
-
@cmb:
@jim1000:
Also, I am forwarding WAN, 3 ports tcp and udp, to a couple of slingboxes and a sling player. also OpenVPN on port 443 tcp with OpenVPN handling forwarding as needed. Same answer?
I thought you'd mentioned earlier in the thread that you had nothing open on WAN. That changes things. Block all that if you want, but better off creating a US alias then using that as the source in all your WAN rules.
No I stated open ports but didn't stress it, hoping it would elicit simple conversation. The initial post mentioned port forwarding in the first sentences.
What are aliases and how do you use them? I also asked that question … but it will undoubtedly fan the flames by asking it again.
-
@jim1000:
What are aliases and how do you use them? I also asked that question … but it will undoubtedly fan the flames by asking it again.
I can answer your Aliases question. Aliases are really nothing more than containers for IP addresses. Think of them as substitution variables. You can create an Alias called "my_addresses". Then you use that alias name in firewall rules as either the source or destination IP address. You can also use aliases when specifying ports. You literally have the text "my_addresses" in the rule.
Then, on the Firewall > Aliases tab, you can put actual IP addresses in your Alias. During runtime the firewall will automatically substitute the list of IP addresses you provided into all the places in the rules where you used the "my_addresses" alias name. The same idea works for ports. You can even use special aliases that are fully qualified domain names (FQDN). For FQDN aliases, you provide a valid hostname as the value. During runtime, the firewall will resolve that host name to an IP and use the IP in rules where the FQDN alias name was provided. The caveat is that the lookup of FQDN hostname to IP only happens every 5 minutes, so it has some limitations.
The beauty of Aliases is you can change the IP addresses they represent anytime you want to in just one place, and the updated list of IP addresses is used everywhere automatically in the firewall rules that reference that Alias. You don't have to go manually touch every single rule to update the IP address.
Now with all that said, pfBlockerNG has some special aliases it creates and uses. The guy that created the package, user BBcan177, can hopefully come along and explain that better than me.
Bill
-
@jim1000:
What are aliases and how do you use them? I also asked that question … but it will undoubtedly fan the flames by asking it again.
I can answer your Aliases question. Aliases are really nothing more than containers for IP addresses. Think of them as substitution variables. You can create an Alias called "my_addresses". Then you use that alias name in firewall rules as either the source or destination IP address. You can also use aliases when specifying ports. You literally have the text "my_addresses" in the rule.
Then, on the Firewall > Aliases tab, you can put actual IP addresses in your Alias. During runtime the firewall will automatically substitute the list of IP addresses you provided into all the places in the rules where you used the "my_addresses" alias name. The same idea works for ports. You can even use special aliases that are fully qualified domain names (FQDN). For FQDN aliases, you provide a valid hostname as the value. During runtime, the firewall will resolve that host name to an IP and use the IP in rules where the FQDN alias name was provided. The caveat is that the lookup of FQDN hostname to IP only happens every 5 minutes, so it has some limitations.
The beauty of Aliases is you can change the IP addresses they represent anytime you want to in just one place, and the updated list of IP addresses is used everywhere automatically in the firewall rules that reference that Alias. You don't have to go manually touch every single rule to update the IP address.
Now with all that said, pfBlockerNG has some special aliases it creates and uses. The guy that created the package, user BBcan177, can hopefully come along and explain that better than me.
Bill
Thank you for your reply. I will study it and play around with it as the understanding evolves.
However, the context of the replies to my initial question involves me using aliases and whitelists with respect to port forwarding for my slingboxes and, possibly, my OpenVPN config. This is particularly unclear, especially with respect to PFBlockerNG in general.
I would almost prefer if the original question could be answered without regard to the flotsam that has followed previous to your answer.
-
Let me take a stab at explaining what the folks here are saying.
First up, in your case you have port forwarding enabled for your Slingboxes and VPN. A forwarded port is really an open port. Think of them as the same.
You are correct to want to protect your Slingboxes and other devices behind those open Internet-facing ports. What the folks here are saying is that there are two ways to do that with pfBlockerNG. One way is much more efficient than the other. Let's talk about the methods.
Method 1
You use pfBlockerNG and add all the blacklist IPs to the inbound rules. So your firewall has to slug through potentially millions of IPs to see if one is on a blacklist. Only after checking them all and coming up "empty" will it let the packet through your firewall.
But I bet you really only want to keep out mostly bad guys in known bad countries. You don't want to block Amazon, Netflix, Facebook, etc. In particular you probably are OK with letting most US IP addresses in. So here is Method 2. It is more efficient.
Method 2
Configure pfBlockerNG to use a whitelist Alias as the "source IP" of an inbound rule and set the value of that Alias to the URL of US-based IP addresses. I don't use pfBlockerNG, so I can't tell you all the specifics of doing this. But generally speaking you now are using a much smaller list of "assumed good" IP addresses. Your firewall can run a match against this smaller list must faster and with less effort. So this method is more efficient at protecting your assets behind the firewall.
If you are more paranoid, then you can use a scheme where you allow only specific IP addresses or address blocks in.
EDIT: I forgot to mention that Method 2 relies on that "default deny" rule that is present in pfSense. If something is not explicitly allowed, then it is blocked. So in Method 2, if the source IP of the incoming packet does not match an IP on that "known good IPs" Alias list, then the packet is dropped.Bill
-
Let me take a stab at explaining what the folks here are saying.
First up, in your case you have port forwarding enabled for your Slingboxes and VPN. A forwarded port is really an open port. Think of them as the same.
You are correct to want to protect your Slingboxes and other devices behind those open Internet-facing ports. What the folks here are saying is that there are two ways to do that with pfBlockerNG. One way is much more efficient than the other. Let's talk about the methods.
Method 1
You use pfBlockerNG and add all the blacklist IPs to the inbound rules. So your firewall has to slug through potentially millions of IPs to see if one is on a blacklist. Only after checking them all and coming up "empty" will it let the packet through your firewall.
But I bet you really only want to keep out mostly bad guys in known bad countries. You don't want to block Amazon, Netflix, Facebook, etc. In particular you probably are OK with letting most US IP addresses in. So here is Method 2. It is more efficient.
Method 2
Configure pfBlockerNG to use a whitelist Alias as the "source IP" of an inbound rule and set the value of that Alias to the URL of US-based IP addresses. I don't use pfBlockerNG, so I can't tell you all the specifics of doing this. But generally speaking you now are using a much smaller list of "assumed good" IP addresses. Your firewall can run a match against this smaller list must faster and with less effort. So this method is more efficient at protecting your assets behind the firewall.
If you are more paranoid, then you can use a scheme where you allow only specific IP addresses or address blocks in.
Bill
I think we're getting closer. PFBlockerNG APPEARS to block efficiently with the country block pages, but someone with specific info should elaborate.
Also, PFBlockerNG offers blocking from specific 'bad sites' such as spam and threats via commonly accessible lists. These were configured by me for both inbound and outbound, mostly because that seemed right and I could find no specific instructions about them. Nobody had addressed this aspect yet. This is separate and distinct from country blocking. More like AV and spam protection at the IP address level. I could use some experienced advice here, also.
Edit: Unless a lot is hidden, it does not seem like it is reviewing a long list of foreign ip addresses. Also, all are inbound only and only if they fall out of SPI. Everything is ignored if I initiate the connection.
-
Depending on the horsepower of your firewall's CPU and what other packages you may have running, doing it with a sort of "block the world" approach on inbound/outbound will work. It's just that some of us guys who still remember needing to optimize assembler code to get a program to run decently on a 8 MHz 8-bit CPU in an IBM PC cringe when we see the poor CPU running through millions of IP comparisons when not completely necessary… :D.
If you don't have a mail server behind your firewall, then Spam lists are not really relevant. Nobody is going to send mail to your Slingbox nor any of your PCs directly. Mail has to go to the SMTP server of your ISP and then your devices connect to that to get their mail. Your ISP would benefit by having that Spam IP list in front of his mail server, but not you on your end.
I personally prefer a solution using Snort (or Suricata) running on my LAN interface. But then I don't have any inbound traffic except a VPN. Since that is certificate-based, I'm not worried much about that one UDP port.
If you were happy with your initial setup, you are not breaking any rule by doing it that way. It just may be that later, as you gain experience with more advanced firewalls like pfSense (advanced over say something like typical consumer routers), you may decide to change the way you do things.
Bill
-
Depending on the horsepower of your firewall's CPU and what other packages you may have running, doing it with a sort of "block the world" approach on inbound/outbound will work. It's just that some of us guys who still remember needing to optimize assembler code to get a program to run decently on a 8 MHz 8-bit CPU in an IBM PC cringe when we see the poor CPU running through millions of IP comparisons when not completely necessary… :D.
If you don't have a mail server behind your firewall, then Spam lists are not really relevant. Nobody is going to send mail to your Slingbox nor any of your PCs directly. Mail has to go to the SMTP server of your ISP and then your devices connect to that to get their mail.
I personally prefer a solution using Snort (or Suricata) running on my LAN interface. But then I don't have any inbound traffic except a VPN. Since that is certificate-based, I'm not worried much about that one UDP port.
If you were happy with your initial setup, you are not breaking any rule by doing it that way. It just may be that later, as you gain experience with more advanced firewalls like pfSense (advanced over say something like typical consumer routers), you may decide to change the way you do things.
Bill
The 'malware' lists are separate and distinct from the open port blocking. It's a completely different feature that applies to all connections including browsers, since they are configured inbound and outbound. Again, comments from experienced users are hoped for.
Also, as I said, 'block the world' is inbound only. I can go anywhere I want if I initiate the connection … unless it's on a 'malware site' list. I am still trying to better understand the malware site lists.
-
Same thought processes apply for any list. Do you want to selectively allow some packets based on their source IP, and let the default block handle everything else; or do you want to have an "allow from any source IP" on the WAN rule and let the firewall check each packet IP against a bunch of IPs on a bunch of lists to see if it should in reality block the traffic.
I, and some others on here, recommend the former approach. Use smaller "allow" lists in conjunction with the default block.
However, I'm not trying to change your mind. You seem to have formed an opinion for how you want to do it, so do it that way and don't fret over it.
Bill
