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 additionally assign that port to the classic inspection service.

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.

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 and the corresponding classic service must inspect that traffic. Typical examples are an internal HTTPS portal on port 8443 or an explicit mail configuration on an additional port.

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. Mail Protection in MTA mode explains the actual mail path.

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 HTTPS portal on TCP 8443, a controlled pilot looks like this:

show service-param
set service-param HTTPS add port 8443
show service-param

The firewall rule also needs a service that allows TCP 8443 as the destination port. For HTTPS, determine which inspection path decrypts, which certificate is expected, and whether the application uses certificate pinning. A visible webpage alone proves neither decryption nor malware scanning.

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 HTTPS delete port 8443
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 already fails, record the error and show service-param. The port is often already treated as a standard port or assigned to another service. Don’t blindly delete the 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