Port List Checker

Introduction:

Port lists look small until they move between firewall rules, scan targets, change tickets, and runbooks. A handful of entries can mix single ports, ranges, service names, TCP-only exceptions, UDP-only services, duplicate lines, and scan output copied from another tool. The practical problem is not only finding the numbers. It is knowing which transport each number belongs to and whether the cleaned list still says what the network change was meant to say.

TCP and UDP use the same numeric range from 0 through 65535, but a port number under one protocol is not the same destination as the same number under the other. 53/udp and 53/tcp may both relate to DNS, while 161/udp is a different review signal from 161/tcp. Lists copied from scanners often carry protocol prefixes such as T: and U:, while firewall notes may write the same intent as tcp/443, 443/tcp, or simply https.

Normalization is useful because reviewers need one compact view before they approve exposure, build a scan command, or compare two policy versions. Sorting and range compression turn noisy input into stable groups. Duplicate removal shows whether repeated entries added no coverage. Band and service review cues help separate ordinary web ports from management ports, database listeners, wide exceptions, and dynamic/private ranges that may have been copied from source-port evidence by mistake.

A clean port list is still not proof that a service is safe to expose. It means the syntax and review clues are easier to inspect. Ownership, approved source ranges, authentication posture, scan scope, and actual listener behavior still need to be checked in the network or system that will use the list.

Technical Details:

Transport ports are 16-bit numbers. IANA groups them into System Ports, User Ports, and Dynamic or Private Ports, and the same number can carry different operational meaning depending on whether it is used with TCP or UDP. That split is why a port review should keep protocol attached to every entry instead of reducing everything to a plain numeric set.

The parsing model is deterministic. Each line is tokenized on common separators, scanner status words such as open or filtered are ignored, punctuation around tokens is cleaned, and explicit protocol markers override the default protocol. A protocol prefix at the start of a token, such as T:8443 or U:161, can continue across later tokens on the same line until another explicit marker appears. Service aliases are optional; strict numeric mode treats service names as ignored tokens rather than silently guessing.

Transformation Core:

Port list cleanup follows a fixed path from raw tokens to reviewable outputs. The important point is that deduplication happens per protocol-port pair, while the headline unique-port count counts each port number once even when both transports are present.

IANA banding gives the range review a shared vocabulary. A system port is not automatically dangerous, and a user port is not automatically safe, but the band helps explain why a list contains management services, application listeners, or high-numbered destinations that might really be ephemeral source ports copied from another context.

The service review severity is a queue signal, not a vulnerability score. Internet-facing review keeps critical and high labels strongest. Internal policy review reduces the harshest label by one step for some services because segmentation work usually starts from ownership and zone intent. Scanner-target review reduces severity again where the list is meant to define an authorized validation run rather than approve permanent exposure.

Everyday Use & Decision Guide:

Start with the source of the list. For a web or admin firewall rule, keep Default protocol on TCP unless the note explicitly names UDP. For resolver, time, telemetry, VPN negotiation, or monitoring lists, choose UDP or add protocol markers on the individual tokens. Use TCP and UDP only when the rule genuinely needs both transports for unmarked numbers.

Choose Review context before judging the service rows. Internet-facing firewall or NAT should make management services, databases, SMB, RDP, Telnet, Docker API, Redis, and similar listeners stand out. Internal firewall or segmentation policy is better when ownership and zone scoping matter more than perimeter exposure. Scanner target or validation run keeps the language closer to scope control.

• Leave Service-name tokens on recognition for pasted runbooks that say ssh, dns, https, or wireguard.
• Switch to Strict numeric ports only when validating a generated firewall export, because names in that mode should become ignored-token notes.
• Use Broad range threshold as a review sensitivity control. A threshold of 1024 calls out very wide ranges; a lower value catches smaller exceptions such as 8000-9000.
• Press Normalize only after the summary is valid. It rewrites the source as compact tcp: and udp: lines, which is useful after you have checked the ignored and corrected tokens.
• Read Service Review before copying Target Strings. The target text can be syntactically useful even when the service review says the list needs owner approval or cleanup.

Do not read No high-signal findings as a security approval. It means the current catalog, context, broad-range threshold, and parsed tokens did not produce a high or critical row. It does not prove the service owner is correct, the host should be reachable, or the listener is patched and authenticated.

For change tickets, the best handoff is usually Normalized Port Set plus the rows from Service Review that explain duplicates, broad ranges, dynamic/private ports, or sensitive services. Keep Port Band Map nearby when a reviewer needs a quick view of how much of the list sits in system, user, or dynamic/private ranges.

Step-by-Step Guide:

Work from raw source to review evidence, then copy the normalized output only after the warnings make sense.

1. Paste the list into Port list, choose Browse, or drop a text-like file. The status below the field should move from the paste prompt to a valid-port summary, or show that no valid ports were found.
2. Set Default protocol for tokens that do not carry tcp, udp, T:, U:, /tcp, or /udp. Explicit protocol markers keep their own transport.
3. Set Review context to match the intended use. The same Service Review row can read more urgently for internet-facing exposure than for scanner scope preparation.
4. Open Advanced when names or ranges need stricter treatment. Use Service-name tokens to allow or reject aliases, and set Broad range threshold to the smallest wide exception you want called out.
5. Read the warning box if it appears. Notes such as ignored tokens, invalid values above 65535, or reversed ranges should be fixed before the normalized list becomes a firewall or scan input.
6. Use Normalized Port Set to inspect protocol, range, count, IANA band, service hints, and source tokens. This is the fastest place to catch a UDP service that accidentally became TCP through the default protocol.
7. Use Service Review to handle duplicate removal, broad ranges, dynamic/private destinations, and cataloged services. Treat Critical and High rows as review prompts, not automatic deny decisions.
8. Copy Target Strings or use JSON only after the summary badges and review rows match the policy or scan scope you plan to hand off.

Interpreting Results:

The headline count is unique ports, not unique protocol-port pairs. If 53 appears under both TCP and UDP, it still counts as one port number in the headline while the normalized rows preserve both protocol groups. Use the table rows when transport accuracy matters.

Port List Needs Review means the service review contains high-signal rows, broad exposure, critical services, or similar conditions under the selected context. Port List Normalized means parsing and review did not raise those stronger cues. Neither heading confirms the real listener, owner, patch level, or business justification.

The Port Band Map is useful for spotting shape, not for approving risk. A list dominated by user ports may still contain databases and admin consoles, while a system-port list may be expected for DNS, time, or identity infrastructure. Use the map with Service Review, not instead of it.

Worked Examples:

Firewall exception with mixed service names

A perimeter change note contains ssh, https, U:53,161, tcp/3389, 8080-8082. With Service-name tokens set to recognition and Review context set to internet-facing firewall or NAT, Normalized Port Set separates TCP ports 22, 443, 3389, and 8080-8082 from UDP ports 53 and 161. Service Review should slow the review on SSH, RDP, SNMP, and alternate HTTP entries before the target strings are copied.

Duplicate web port and reversed range

A copied rule contains 443, 443, 8082-8080 under the default TCP setting. The output keeps 443 once, normalizes the reversed range to 8080-8082, and adds notes for duplicate removal and range correction. The useful final source is the Normalized Port Set row set, not the original text that repeated the TLS port and reversed the range.

Strict numeric scanner target

A scanner handoff is meant to accept only numeric ports, but the source says ssh, 22, udp/ntp. Switching Service-name tokens to Strict numeric ports only keeps 22 and reports the names as ignored tokens. The warning box and Service Review make the failure visible, so the owner can replace ssh and ntp with explicit numeric entries before using Target Strings.

FAQ:

Glossary:

Protocol-port pair

A destination port with its transport attached, such as 443/tcp or 53/udp.

System Port

An IANA range from 0 through 1023, often associated with well-known infrastructure services.

User Port

An IANA range from 1024 through 49151, commonly used for registered and application services.

Dynamic/Private Port

An IANA range from 49152 through 65535, often used for temporary or private allocation.

Broad range

A source range whose size is at or above the selected broad-range threshold.

Service alias

A human-readable service token, such as ssh or https, that can map to one or more numeric ports when recognition is enabled.

References:

• Service Name and Transport Protocol Port Number Registry, Internet Assigned Numbers Authority.
• RFC 6335: Service Name and Port Number Procedures, RFC Editor, August 2011.
• Port Specification and Scan Order, Nmap Network Scanning.
• Guidelines on Firewalls and Firewall Policy, National Institute of Standards and Technology, September 2009.
• Preventing SMB traffic from lateral connections and entering or leaving the network, Microsoft Support.
• CIS Control 9: Limitation and Control of Network Ports, Protocols and Services, Center for Internet Security, 2025.