Prebuilt Firewall Rules Alias [$100]

[JStyleG7X]

I'm hoping this can be an option down the road.  I'm not sure "Alias" is quite the best description of what I want but hopefully I can explain it.  What I'd like to do is create pre-defined firewall rulesets for specific applications or uses (Active Directory, Custom applications, Media Server, etc…) defining the ports and protocols needed by each setup.  Then I can simply add this Pre-Built ruleset to the interface firewall rules with the friendly name "Active Directory Traffic" and pass that traffic with one rule.

I know there are the floating rulesets but when you make these it's difficult to review a specific vlan ruleset at a glance because for one, the floating rules don't show up under the interface rules although it would be great if it did - kind of like what the pfBlocker does.  And second the floating rules need to opened to see which interfaces they are applied to, kind of tedious.

Perhaps there's a better way I should be doing this?

[azekiel]

Just add a Portgroup Alias in Firewall -> Aliases -> Ports and your good to go, If I understand you.

You can reuse that Alias for every interface rule config you like.

[adam65535]

azekiel, That doesn't help if you need to specify different src port requirements for UPD and TCP and also need ICMP.  You need multiple rules currently

Scenarios where the current scheme requires multiple rules for the same src and destination host…

For all of these the same src and dest host are the same (src 10.1.1.1 and dest 10.2.2.2):

• UDP service with src port of 53 and dst port of 53 (server UDP traffic).
• UDP service with src port 1024-65535 and dst port of 53 (client traffic)
• TCP service with src port of 123 and dest port of 123 (server traffic)
• TCP service with src port any and dst port of 80.
• ICMP echo-request

This would require 5 different rules in the GUI for the same traffic from 10.1.1.1 to 10.2.2.2.  Yes you could loosen up the src ports to get this down to 3 rules but for installations that really want to lock down both src and dst ports that is not acceptable so it requires 5 rules.  If you really wanted to loosen it up even further you could just set UDP and TCP for all the ports you want and reduce it down to 2 rules (TCP/UDP for 1 and ICMP for the other) but that would allow connections to UDP and TCP ports that were not intended (123 is for UDP only for example).

It would be great to be able to define services by their src and dest port requirements, advanced rule options (which would be service advanced options), and protocol(s).  You could then assign those service definition to rules and still have very well defined ports and mixed ICMP and TCP/UDP in one rule.  This would allow 1 rule in the GUI to replace the 5 above and make it easier to view the rule base IMHO.  In the background at the rule level there would still be 5 rules created but that complexity would be hidden from the user.  This is a big change though and definitely not a $100 change :).

[azekiel]

okay, understood. you are correct!

[johnpoz]

what traffic would this be?

"TCP service with src port of 123 and dest port of 123 (server traffic)"

These seem pointless..
UDP service with src port of 53 and dst port of 53 (server UDP traffic).

• UDP service with src port 1024-65535 and dst port of 53 (client traffic)

why not just allow any as your source here..  Your blocking a few source ports.  Coming from a server that your already allowing to talk to this dest server on 53 from pretty much any port anyway..  I see no extra security here.  Clearly you trust this server enough to let it talk on 53 to your box..  but your worried it might try from source port 100??

I can understand specific requirements in rule sets, but your examples are not very good..

[adam65535]

It still could provide some protection from for services on the 10.1.1.1 server.  You are assuming that the remote host is trusted for all services running on 10.1.1.1 which is not always true.  10.1.1.1 could be hosting NFS, FTP, etc, that should not be exposed.  The remote host could be another organization that is only trusted for a few services.

While the rule does not give direct access to connect to the 10.1.1.1 server externally on any port just because of the 'src any', there are some potential scenarios that could expose the service.  Some FTP servers and firewalls used to have flaws that allowed clients to manipulate the second data connection port and IP which firewalls would then open up to the client.  This exposed any TCP services hosted on the ftp server (or even another internal server) to the remote client.  This is not really as big of an issue any more and hopefully people have moved away from unencrypted FTP but it is an example of how ports can be accessed that were not intended.

Ports below 1024 are generally privileged ports.  If there is no reason for any traffic to be sent from or to them then blocking any chance of traffic using those ports is just another layer of protection.  While client apps tend to pick a port above 1023 so specifying 'any' for source port does not mean traffic will be sent with a src privileged port, It just makes sure that there is no direct chance for a client to create a connection with a source port in the privileged range where other more important services could be hosted, and makes sure nobody on the lan, or other client exploit can do packet manipulations to punch holes through the firewall using faked UDP ports exposing services hosted on privileged ports (send a spoofed packet from the Lan with the server IP and src port of nfs, radius, etc and destination the same as the rule allows for example).  While the destination host specification limits the risk significantly, If the destination is any then that risk opens up more.

I understand that being this restrictive is not always wanted or needed.  Different needs for different organizations and uses.  To the opposite extreme, Some use pfsense as just routers internally between fully trusted networks and never even use the firewalling.

Using any source ports is zero risk in some scenarios but it is not zero risk for all use cases.  Different needs for different use cases.  It only takes an extra few minutes to write the rules in the most strict form so why not do that unless it causes some kind of problem.  The only down side doing it this way with the current services/port definition scheme is that the GUI will show more rules between the same host.  Either way it is not a big deal… It just makes the rule base bigger to view.  As long as it doesn't make the rule base hard to understand I will tend to use that scheme.

[JStyleG7X]

I totally missed my notifications on this topic.  Anyway, to help clarify my original intent behind this request I'll give some examples.

The idea is to make some pre-built "rulesets" that effectively harden egress traffic in a quick and easy way.  I suppose it pretty much combines a firewall and port alias into one merged alias name with all the protocols pre-assigned for the source & destination.  What I think could be useful is if these "rulesets" became a sort of optional baseline preset that was available as a quick select (kind of like the preset QOS traffic types).  From my experience firewall rules have been one of the most time consuming things to setup and having an easy way to import/apply standard rulesets across various customer sites would be really helpful….emphasis on the various customers and different network settings abroad.

Concept Firewall Rule Aliases

Name: Client To DC Traffic
Interface : (Assign like any other rule on the interface and simply specify the Alias name.)
Source: Client Interface VLan/Subnet/Other
Destination: Domain Controller IP Addresses(s) (linked firewall Alias)
Source Ports: Any (Specify if needed)
Destination Ports: (linked port Alias)
UDP Port 88 for Kerberos authentication
UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
TCP and UDP Port 445 for File Replication Service
TCP and UDP Port 464 for Kerberos Password Change
TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.
udp 123 for time service
udp for netlogon and netbios
TCP 139

Name: RODC To DC Traffic
Interface : (Assign like any other rule on the interface and simply specify the Alias name.)
Source: RODC IP(s) (linked firewall Alias)
Destination Address: Domain Controller IP Addresses
Source Ports: Any (Specify if needed)
Destination Ports: (linked port Alias)
UDP 53 DNS DNS
TCP 53 DNS DNS
TCP 135  RPC, EPM
TCP Static 53248  FRsRpc
TCP 389  LDAP
TCP and UDP Dynamic
1025  5000 Windows 2000, Windows 2003, Windows XP Ephemeral Ports
TCP and UDP Dynamic 49152  65535 Windows 2008, Windows Vista and all newer operating systems Ephemeral Ports

Name: Corporate DNS Traffic
Interface : (Assign like any other rule on the interface and simply specify the Alias name.)
Source: Interface Subnet/Other
Destination Address: Corp DNS Servers/Domain Controllers (linked firewall Alias)
Source Ports: Any (Specify if needed)
Destination Ports: UDP 53 "DNS" (linked port Alias)

Name: VCenter Management Traffic
Interface : (Assign like any other rule on the interface and simply specify the Alias name.)
Source: Interface VLan/Subnet/Other
Destination Address: VCenter Server(s) (linked firewall Alias)
Source Ports: Any (Specify if needed)
Destination Ports: (linked port Alias)

vCenter Server 6.0 22 TCP/UDP vCenter Server SSH Client System port for SSHD. This port is only used by the vCenter Server Appliance
vCenter Server 6.0 80 TCP Client PC vCenter Server vCenter Server requires port80for direct HTTP connections. Port80redirects requests to HTTPS port 443. This redirection is useful if you accidentally usehttp://serverinstead ofhttps://server.

WS-Management (also requires port443to be open).

If you use a Microsoft SQL database that is stored on the same virtual machine or physical server as vCenter Server, port80 is used by the SQL Reporting Service.

When you install or upgrade vCenter Server, the installer prompts you to change the HTTP port for vCenter Server. Change the vCenter Server HTTP port to a custom value to ensure a successful installation or upgrade.
vCenter Server 6.0 88 TCP vCenter Server Active Directory Server VMware key distribution center port
vCenter Server 6.0 389 TCP/UDP vCenter Server Linked vCenter Servers This port must be open on the local and all remote instances of vCenter Server. This is the LDAP port number for the Directory Services for the vCenter Server group.

If another service is running on this port, it might be preferable to remove it or change its port to a different port. You can run the LDAP service on any port from 1025 through 65535.

If this instance is serving as the Microsoft Windows Active Directory, change the port number from 389 to an available port from 1025 through 65535.
vCenter Server 6.0 443 TCP vSphere Web Client vCenter Server The default port that the vCenter Server system uses to listen for connections from the vSphere Web Client. To enable the vCenter Server system to receive data from the vSphere Web Client, open port 443 in the firewall.

The vCenter Server system also uses port 443 to monitor data transfer from SDK clients.

Port 443 is also used for these services:

WS-Management (also requires port 80 to be open)
    Third-party network management client connection to vCenter Server
    Third-party network management clients access to host

vCenter Server 6.0 514 UDP Syslog Collector Syslog Collector vSphere Syslog Collector port for vCenter Server on Windows and vSphere Syslog Service port for vCenter Server Appliance
vCenter Server 6.0 636 TCP Platform Service Controller Management Nodes For vCenter Server Enhanced Linked Mode, this is the SSL port of the local instance. If another service is running on this port, it might be preferable to remove it or change its port to a different port.
You can run the SSL service on any port from 1025through 65535. This port is also used during install to verify SSL certificates.
vCenter Server 6.0 902 TCP/UDP vCenter Server ESXi 6.0/5.x The default port that the vCenter Server system uses to send data to managed hosts. Managed hosts also send a regular heartbeat over UDP port 902to the vCenter Server system.
This port must not be blocked by firewalls between the server and the hosts or between hosts.

Port 902 must not be blocked between the vSphere Client and the hosts. The vSphere Client uses this port to display virtual machine consoles.
vCenter Server 6.0 10080 TCP vCenter Server Inventory Service vCenter Server vCenter Inventory Service HTTP
vCenter Server 6.0 1514 TCP/UDP Syslog Collector Syslog Collector vSphere Syslog Collector TLS port for vCenter Server on Windows and vSphere Syslog Service TLS port for vCenter Server Appliance
vCenter Server 6.0 2012 TCP vCenter Server (Tomcat Server settings) vCenter Single Sign-On Control interface RPC for vCenter Single Sign-On(SSO).
vCenter Server 6.0 2014 TCP vCenter Server (Tomcat Server settings) vCenter Single Sign-On RPC port for all VMCA (VMware Certificate Authority) APIs.
vCenter Server 6.0 2020 TCP/UDP vCenter Server vCenter Server Authentication framework management
vCenter Server 6.0 6500 TCP/UDP vCenter Server ESXi host ESXi Dump Collector port
vCenter Server 6.0 6501 TCP Auto Deploy service ESXi Host Auto Deploy service
vCenter Server 6.0 6502 TCP Auto Deploy Manager vSphere Client Auto Deploy management
vCenter Server 6.0 7444 TCP

Secure Token Service
vCenter Server 6.0 8009 TCP vCenter Server vCenter Server AJP Port
vCenter Server 6.0 8089 TCP vCenter Server vCenter Server SDK Tunneling Port
vCenter Server 6.0 9443 TCP vSphere Web Client Server vSphere Web Client vSphere Web Client HTTPS
vCenter Server 6.0 11711 TCP vCenter Single Sign-On vCenter Single Sign-On VMware Directory service (vmdir) LDAP
vCenter Server 6.0 11712 TCP vCenter Single Sign-On vCenter Single Sign-On VMware Directory service (vmdir) LDAPS