Inspect non-standard ports with Sophos Firewall

Sophos Firewall inspects HTTP, HTTPS, FTP, SMTP/S, POP, and IMAP on their standard ports. When an application uses one of these protocols on a different port, service-param can extend protocol inspection to that port.

The command isn’t a general port opener. It creates neither a service object nor a firewall rule and doesn’t enable a web, TLS, or mail policy. For traffic to be inspected, the rule match, allowed destination port, and responsible inspection path must align. For new web rules, first determine whether the DPI engine or web proxy processes the flow.

⚠️ service-param is a global assignment. An additional port doesn’t only affect a single host or firewall rule. Record existing uses of the port, affected policies, and an executable rollback before making a change.

Choose the inspection path first

An additional destination port and inspection of that flow are two separate decisions. Under Hosts and services > Services, a TCP service object defines which destination port matches a firewall rule. When creating it under Hosts and services > Services > Add, normally leave Source port at 1:65535 because applications choose their source ports dynamically. The object alone doesn’t enable content inspection.

For web traffic, service-param usually isn’t the first step in SFOS 22:

• The DPI engine detects HTTP and SSL/TLS on all ports. An HTTPS portal on TCP 8443 therefore needs a matching service in the firewall rule and the intended web policy and scanning settings. If decryption is required, a matching rule under Rules and policies > SSL/TLS inspection rules is also necessary. These rules detect TLS on any TCP port and jointly evaluate source, destination, user, service, and website criteria.
• With Use web proxy instead of DPI engine, the transparent web proxy processes only HTTP on port 80 and HTTPS on port 443. HTTP and TLS traffic on other ports remains with the DPI engine. service-param therefore isn’t a way to extend the transparent proxy to arbitrary additional ports.
• With the direct web proxy, the client connects to the listener configured under Web > General settings > Web proxy configuration. This explicit proxy path works regardless of whether Use web proxy instead of DPI engine is selected in a firewall rule.

IPS is also a separate path. Intrusion prevention > IPS policies must be globally turned on, an active Network Protection subscription or trial license must be available, and the intended IPS policy must be set in the matching firewall rule. service-param doesn’t enable IPS and doesn’t show whether a signature recognized the flow. Correlate the Firewall Rule ID and IPS event in Log Viewer instead.

This leaves service-param primarily as a candidate when the protocol-specific service documented by Sophos must process an additional port, such as FTP or a mail protocol. For DPI web or TLS inspection alone, configure the rule path instead.

When service-param is appropriate

The command is appropriate when a known application actually uses HTTP, HTTPS, FTP, SMTP, SMTPS, POP, or IMAP on a non-standard TCP port, the DPI engine isn’t already responsible for inspection, and the corresponding protocol-specific service must process that traffic. Typical examples are FTP on TCP 2121 or an agreed SMTP configuration on TCP 2525.

An open TCP port isn’t proof of the expected protocol. If proprietary binary traffic runs on 8443, assigning it to HTTPS may disrupt connections instead of adding protection. For web traffic, also check whether the DPI engine already detects the protocol or whether a proxy service port really needs to be added. For mail traffic, distinguish SMTP with STARTTLS from SMTPS with TLS from the start of the connection. If you use Mail Protection in MTA mode, traffic follows a different path routed through the MTA.

service-param isn’t appropriate when only a firewall rule needs to allow an additional destination port. Create a suitable TCP service object under Hosts and services > Services and use it in the firewall rule. Add the inspection assignment only when the responsible proxy or mail service must also process the non-standard port.

Record the baseline in the Device Console

Access the command through 4. Device Console. Before any change, the following command shows the existing service ports and other global values:

show service-param

Record the complete output with the SFOS build, time, and change reference. In particular, check whether the intended port is already assigned to another service. Don’t assign the same port speculatively to HTTP, HTTPS, SMTP, and SMTPS at the same time.

Sophos documents these service names for SFOS 22:

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN and IM_YAHOO are legacy labels in the CLI. They aren’t a starting point for a new instant-messaging design. Protect new applications through firewall rules, Application Control, TLS inspection, and the protocol detection actually supported.

Add an additional port

The documented basic syntax for the supported services is:

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

For a confirmed SMTP connection on TCP 2525, a controlled pilot looks like this:

show service-param
set service-param SMTP add port 2525
show service-param

This example applies to transparent mail proxy inspection in Legacy mode. The firewall rule also needs a service that allows TCP 2525 as the destination port; select SMTP under Scan email content and configure a suitable mail policy. Before the change, determine that the port carries SMTP and whether it uses STARTTLS. A successful TCP connection or mail delivery alone doesn’t prove content inspection. In MTA mode, don’t modify the automatically created MTA firewall rule for this pilot.

The portID placeholder in Sophos syntax is used with the concrete port value in the Device Console. Only add a port after a packet capture or the application documentation confirms the protocol and destination port.

Don’t mix global special options with a port test

For HTTPS, Sophos additionally lists deny_unknown_proto on|off and invalid-certificate allow|block. SMTPS also has invalid-certificate allow|block. SMTP provides further global options for failure notifications, fast ISP mode, notification port, and strict protocol checking.

These values solve a different problem from add port. Don’t change them during the same port pilot. In particular, invalid-certificate allow can tolerate certificate errors globally, while deny_unknown_proto and strict-protocol-check change how non-conforming connections are handled. A successful connection after several simultaneous changes is difficult to attribute and may silently reduce protection.

The official syntax also includes:

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Before making one of these global changes, separately assess the exact existing output, affected senders or web applications, security impact, and support guidance. This article therefore doesn’t present these commands as recommended defaults.

Validate the effect with a real flow

Start the test with exactly one pilot source and a logged firewall rule. Before and after the change, use the same destination, destination port, and a new connection. In Log Viewer, the firewall rule ID, web or mail action, and time must match the pilot.

For HTTPS, also check the certificate issuer, TLS handshake, and expected block or allow action. If malware scanning is part of the design, run a controlled EICAR test over this exact port. EICAR only confirms the normal antivirus path, not every TLS, policy, or ML function. For SMTP, SMTPS, POP, and IMAP, use a uniquely identifiable test message and trace it through mail logs, quarantine, and the mail spool where applicable.

A packet capture confirms that the client actually uses the intended destination port. If only the firewall log shows Allow, there is still no evidence that the downstream proxy or mail service inspected the content. Test Sophos Firewall rules in a controlled way combines rule matching, Log Viewer, and packet capture.

Roll back the port assignment

Rollback removes only the port added by the change from the correct service:

set service-param SMTP delete port 2525
show service-param

Then establish the same test flow again. Connectivity must return to the documented baseline. Remove temporary firewall service permissions, pilot rules, and exceptions separately; delete port doesn’t delete these objects.

If adding the port fails, record the error and show service-param. Use them to determine whether the port is already treated as a standard port or assigned to another service. Don’t blindly delete an existing entry because another inspection path may depend on it.

Operational checklist

• The application, protocol, and actual destination port are confirmed.
• show service-param and the SFOS build are recorded before the change.
• Firewall service, rule match, and inspection assignment are treated separately.
• The port isn’t already assigned to a conflicting service.
• Only add port changes in the pilot, not a global certificate or protocol option.
• Positive test, negative test, inspection log, and packet capture are prepared.
• The matching delete port command and unchanged fallback path are ready.

FAQ