Too many ports to firewall, any idea?

JT40

Hello,

I'm trying to configure my firewall in the best way possible, but I already see that going crazy is just one step ahead :D .

Look at this example, these are the ports required for Whatsapp and Facetime

WhatsApp
TCP 4244
TCP 5222
TCP 5223
TCP 5228
TCP 5242
UDP 3478
UDP 45395
TCP/UDP 50318
TCP/UDP 59234

FaceTime
TCP 5223
UDP 3478-3497
UDP 16393-16402

These are taken from a random website, but the list for Whatsapp for example is more or less posted also in many other places, but certainly not in the official doc :D .
In case you wonder, yes, it's genuine, I've seen it in the firewall state table...

My question is, I can't go crazy, so, I wonder what I can do to reduce the number of rules...
It seems that every software has custom ports...
At this point, I wonder what's the meaning of firewalling ports one by one, if any of them can be exploited as long as the attacker knows my IP and port where I'm already connected to a website for example, port 443 is the standard...
Internally, I have internal ports, which means different ports, and there is NAT, ok thanks, but how does this solve the problem?
I don't have filtering by services, OS, hostnames, etc, so, technically, an attacker could exploit me quite easily, as long as he knows enough info...

Certainly, I'll look into some protection like Snort or Surricata, but this is the ABC, so first I need to resolve this vulnerability.
Thanks in advance to anyone that will provide some help, any contribution matters.

JT40

I need to rectify one thing, I got confused by the fact that NAT is supposed to protect me from such scenario, but at the same time, I don't understand why so many network engineers configure the firewall for each port...
Also in my home network becomes tricky to manage too many VLANs with so many FW rules, so, if NAT protects me, then why should I firewall each port manually?

Is it not enough to specify a rule that everything can go out as long as I requested it, as I always did?
In any case, even a malware that is already in one of my systems, can easily go out using a manually firewalled port, like 443.
So here the point is to use an additional method of security like Snort or Surricata, and leave the ALLOW ALL OUT as I always did, am I missing something?

SteveITS

@jt40 Are you sure those are not outgoing ports? It's not normal to open ports to the Internet unless you're the one running the server. I've not had to open inbound ports for those programs. Among other things if that was the case (which it's not) it would only allow one device to work.

JT40

@steveits said in Too many ports to firewall, any idea?:

@jt40 Are you sure those are not outgoing ports? It's not normal to open ports to the Internet unless you're the one running the server. I've not had to open inbound ports for those programs. Among other things if that was the case (which it's not) it would only allow one device to work.

Do you mean if those are internal ports in my FW?
No, I checked, for example the ports 5222 and 3478 are being used by my phone IP, casually when I started a videocall. I want to clarify that I didn't find a better way to record the usage at that time, I was a bit in a hurry :D .
These ports were not in the state table before the test.

I've written the following rule to make it work without allowing every single port which looks crazy also for other services in future, I had no other choice:

ALLOW ALL OUTBOUND | ANY protocol | DENY to RFC1918 addresses |

ANY protocol didn't allow me to select any port, I'm not sure if it's ok...
The videocall was successful, same for the voice call.

What you described is port forwarding if I'm not wrong, I'm really not willing to do it :D , I just need to videocall

SteveITS

@jt40 said in Too many ports to firewall, any idea?:

Do you mean if those are internal ports in my FW

I meant, why do you think it's required to open those ports inbound. Did you try it without doing anything? It should work without doing anything, based on the default "allow LAN to any" rule.

IPs/ports in the state table are normal for any open connection.

JT40

@steveits said in Too many ports to firewall, any idea?:

@jt40 said in Too many ports to firewall, any idea?:

Do you mean if those are internal ports in my FW

I meant, why do you think it's required to open those ports inbound. Did you try it without doing anything? It should work without doing anything, based on the default "allow LAN to any" rule.

IPs/ports in the state table are normal for any open connection.

I'm okay with opening only the ports in OUTBOUND, I just discovered that it's not necessary to also allow INBOUND, it would only expose me to risks, it's the worst I can do...

Without doing anything, it doesn't work because by default, there is NO ALLOW rule.
So, it seems that the rule I've written above is the only one to make it easy, right?

ALLOW ALL OUTBOUND | ANY protocol | DENY to RFC1918 addresses |

With this one, I can achieve the following:

Create PVLANs, which are actually created in the L2+ switch first, but considering that PFSense handles the routing, that concept is moved into PFSense
I get an easy setup for connections in OUTBOUND, I really don't see the way to do it manually for each port and for each VLAN...
I just wonder if this is the only AND/OR right way to do it.

bmeeks

By default, if you change absolutely nothing other than assigning an IP address to your LAN interface, pfSense will work out-of-the-box. There is a default ALLOW ALL to ANY rule in place for the LAN interface. There is also a default DENY ALL for unsolicited inbound traffic on the WAN (meaning a random stranger on the Internet trying to communicate back to your firewall WITHOUT your firewall having talked out to that stranger first will be blocked). pfSense is a stateful firewall. That means when traffic from a host on your LAN initiates a connection to a host out on the Internet (via the WAN), pfSense will automatically let return traffic from that host enter the firewall if destined for the host that originally started the conversation. You need to do absolutely nothing for this process to work.

Now, if you have created VLANs and additional interfaces besides the default LAN interface, then "yes" you will need to manually create a rule to allow hosts hanging off that interface to initiate traffic to the Internet because newly created interfaces have no rules applied to them. Most users, and especially home network users, simply use a rule such as ALLOW ALL to ANY on their internal interfaces unless there is specific need to limit communications for hosts hanging off that interface.

pfSense evaluates and filters traffic as it ENTERS an interface. So, using the default LAN as an example, rules are applied to traffic as it comes from the LAN NIC and flows into the pfSense firewall LAN interface. Many folks mistakenly assume rules are applied to traffic leaving an interface, and this is not true with the exception of Floating Rules. But Floating Rules are an advanced feature.

Patch

@jt40 said in Too many ports to firewall, any idea?:

example, these are the ports required for

Create a port alias for the groups of ports you need. If necessary you can include an alias in a higher level alias if required.

Your firewall rules can then use an alias to cover a broad range of ports.

A separate issue is how tight you make your firewall rules. More specific rules are more likely to catch unexpected / malicious traffic but do require more effort to generate and maintain. The easiest is to be specific only for externally initiated traffic, but having tight rules for internally initiated traffic can also be of value.

JT40

@bmeeks said in Too many ports to firewall, any idea?:

By default, if you change absolutely nothing other than assigning an IP address to your LAN interface, pfSense will work out-of-the-box. There is a default ALLOW ALL to ANY rule in place for the LAN interface. There is also a default DENY ALL for unsolicited inbound traffic on the WAN (meaning a random stranger on the Internet trying to communicate back to your firewall WITHOUT your firewall having talked out to that stranger first will be blocked). pfSense is a stateful firewall. That means when traffic from a host on your LAN initiates a connection to a host out on the Internet (via the WAN), pfSense will automatically let return traffic from that host enter the firewall if destined for the host that originally started the conversation. You need to do absolutely nothing for this process to work.

Now, if you have created VLANs and additional interfaces besides the default LAN interface, then "yes" you will need to manually create a rule to allow hosts hanging off that interface to initiate traffic to the Internet because newly created interfaces have no rules applied to them. Most users, and especially home network users, simply use a rule such as ALLOW ALL to ANY on their internal interfaces unless there is specific need to limit communications for hosts hanging off that interface.

pfSense evaluates and filters traffic as it ENTERS an interface. So, using the default LAN as an example, rules are applied to traffic as it comes from the LAN NIC and flows into the pfSense firewall LAN interface. Many folks mistakenly assume rules are applied to traffic leaving an interface, and this is not true with the exception of Floating Rules. But Floating Rules are an advanced feature.

Thanks, so I can consider it safe enough to ALLOW ANY TO WAN.
In any case, it's the only option at the moment .

@patch said in Too many ports to firewall, any idea?:

@jt40 said in Too many ports to firewall, any idea?:

example, these are the ports required for

Create a port alias for the groups of ports you need. If necessary you can include an alias in a higher level alias if required.

Your firewall rules can then use an alias to cover a broad range of ports.

A separate issue is how tight you make your firewall rules. More specific rules are more likely to catch unexpected / malicious traffic but do require more effort to generate and maintain. The easiest is to be specific only for externally initiated traffic, but having tight rules for internally initiated traffic can also be of value.

My intention to improve security was about filtering ports one by one, the issue is that the are too many different ports...
Look at another service that I use a lot for example: Zoom-network-firewall-or-proxy-server-settings
There are almost 10 local ports to whitelist... If I want to do it well, I should actually whitelist those public IPs and ports all together, but normally the domain AND ports are enough, much easier.
Unfortunately, this is a mess for me, I can't imagine to do all this for every service I use...

Then, it's enough that one domain changes from .us to .com for example, and I need to modify my rules...
Are there ready made lists out there that I can include in PFSense?

johnpoz

@jt40 said in Too many ports to firewall, any idea?:

I can't imagine to do all this for every service I use...

Then don't - unless you were filtering because you don't want people to go anywhere other than where you want them to go. Doing this is not much security bonus.

Easier method of blocking users from going to bad stuff would be say dns filtering with a list of bad sites you don't want them to resolve. These lists are maintained by people that do that sort of thing ;)

Or lists that block based on bad IPs, trying to only allow good is very labor intensive..

bmeeks

@jt40 said in Too many ports to firewall, any idea?:

Thanks, so I can consider it safe enough to ALLOW ANY TO WAN.
In any case, it's the only option at the moment .

If you and your users are prudent computer users, then yes, an ALLOW ANY to WAN rule (meaning let LAN hosts go anywhere on the Internet) is usually fine. It is certainly the easiest to administer.

But if you have young kids as users, or if it is a commercial enterprise and you need to restrict users from visiting certain sites, then more restrictive rules are called for on the LAN. It is far easier, though, to use a tool such as pfBlockerNG-devel and its DNSBL option to block access to known "bad" sites either through DNS filtering or blocking of IP addresses via a third-party list than attempting to create the myriad of PASS rules it takes to have most modern applications work today. As you are seeing, most apps need a lot of open ports, and each app seems to have its own unique list of required open ports. And then all the destination IPs are different. The destination thing gets to be a huge issue with the major apps because they use CDNs that resolve to many, many different IP addresses that may change as frequently as every two to five minutes. The DNSBL option of pfBlockerNG-devel is needed there.

Tzvia

Part of having a firewall like this instead of the typical home router, is control of what ports are open, and the ability to break out the internet capable devices into vlans to at least have some control. It took some time but breaking down the ports into groups and making aliases gave me the control to allow what I know I need between the desktops and the IOT, for example. What is the point of VLANS if the rule is ANY-ANY. Yes a pain to setup, I have a number of aliases that I use to open what I need to the internet and between VLANS. They rarely change in my case. I think I created one alias this year, for a new doorbell. I open needed ports between my desktops and servers, to IOT, limit access to the security cameras... but it took a while, some digging around websites to get the ports, and a lot of testing. But once setup it's been smooth sailing the last 5 years or so.

occamsrazor

The above posters saying ALLOW ANY for outbound traffic seems right to me and that's what I do. But just on a semi-related note... if you do need to create rules for a bunch of ports for whatever reason - whether out or in - rather than create separate rules for each port you can create an alias of a group of ports, and then make a single rule applying to that alias:
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html

JT40

Thanks everyone, so here's my plan.

Limit access to the FW
ALLOW DNS access to the local DNS resolver for all the VLANs
Limit access to the WAN, no port based, but DNS/IP based, I need to evaluate pfBlockerNG
Surricata
The latest challenge came up with the VPN... Restrict the traffic with the VPN it's not possible unless I set a HAProxy before, performance wise I should be fine, I have overkill hardware, but it's an additional service to maintain and to troubleshoot in case of issues, I'm not sure if I'm gonna do that, would you?

In any case, this is the problem I've met there, and I didn't even restrict the traffic, any idea? openvpn-puts-down-internet-traffic
Please ignore the second message and jump to the 3rd, unfortunately I couldn't edit it.