Port List Checker
Normalize mixed TCP and UDP port lists into compact ranges and target strings with IANA bands, duplicate checks and service exposure cues.{{ values.target_text }}| Protocol | Port range | Count | IANA band | Service hints | Source tokens | Copy |
|---|---|---|---|---|---|---|
| {{ row[0] }} | {{ row[1] }} | {{ row[2] }} | {{ row[3] }} | {{ row[4] }} | {{ row[5] }} |
| Priority | Port or range | Protocol | Finding | Evidence | Next action | Copy |
|---|---|---|---|---|---|---|
| {{ row[0] }} | {{ row[1] }} | {{ row[2] }} | {{ row[3] }} | {{ row[4] }} | {{ row[5] }} |
Port lists often move from scanner output or a ticket into a firewall rule with less cleanup than the decision deserves. A useful review keeps the port number, transport protocol, range width, and source context together before anything is approved or scanned.
TCP and UDP each use port numbers from 0 through 65535. The same number can name different services under the two protocols, and a service name is only a convention. Port 53 often indicates DNS, for example, but the number does not prove that a DNS server is listening or that the traffic is safe.
| Band | Inclusive range | Review meaning |
|---|---|---|
| Reserved port zero | 0 | Often wildcard syntax rather than a destination service |
| System ports | 1 to 1023 | Well-known and privileged service territory |
| User ports | 1024 to 49151 | Registered or application-specific services |
| Dynamic/private ports | 49152 to 65535 | Unassigned by IANA and often used for ephemeral client ports |
Normalization removes accidental variety without erasing meaning. Duplicate protocol-and-port entries can collapse, consecutive values can become ranges, and reversed ranges can be corrected. Protocol markers must survive that cleanup because 53/tcp and 53/udp are distinct destinations even though they share a number.
Broad ranges deserve deliberate review. A request for 8000-9000 includes 1001 ports because both endpoints count. An all-ports token expands to 0 through 65535. Those may be legitimate scanner targets, but they are rarely a safe substitute for named destination services in an internet-facing allow rule.
A cleaned list answers what the text contains. It does not scan a host, confirm a listener, inspect a firewall, or decide that exposure is acceptable. Ownership, source restrictions, authentication, patch status, and live reachability remain separate checks.
How to Use This Tool:
Paste the list as received, then state how unqualified numbers should be interpreted.
- Paste ports, ranges, scanner fragments, or supported service names into Port list. Commas, whitespace, semicolons, vertical bars, and new lines can separate entries.
- Choose the Default protocol for numbers without a TCP or UDP marker. Use both only when the policy or scan genuinely targets both transports.
- Select the Review context. Internet edge, internal policy, and scanner validation use different caution levels without changing the normalized set.
- Choose whether common service names should be recognized, and adjust the broad-range threshold when the neutral 1024-port default does not fit the review.
- Correct ignored tokens and reversed-range notes, then compare the target strings with the normalized set and service review before reuse.
Interpreting Results:
Unique ports counts distinct numeric port values across both transports. The TCP and UDP counts remain separate, so one number present under both protocols contributes once to the unique-port total but once to each protocol total.
Use the normalized set as the parser's source of truth. Service names and severity labels are review cues, not detection results. A Critical database or remote-management cue means that exposure needs strong justification; it does not prove that the named application runs there.
Dynamic/private ports are not automatically unsafe. Their presence is a prompt to distinguish intentional destination listeners from ephemeral source ports copied out of logs. Confirm the direction of traffic before turning them into allow rules.
Technical Details:
The parser models a port list as a set of protocol-and-port pairs. This set representation removes exact duplicates while preserving the difference between TCP and UDP. Consecutive values are compressed only after parsing and deduplication.
Transformation Core
The normalization path is tokenization, protocol resolution, range expansion, deduplication, compression, band lookup, and contextual review.
| Input form | Transformation |
|---|---|
tcp/443, 443/tcp, T:443 | Assign TCP explicitly; UDP and combined TCP/UDP forms follow the same rule. |
Nmap-style T: or U: prefix | The protocol remains active for later tokens on that same line until another marker appears. |
| Bare number | Apply the selected default protocol. |
8000-8010 | Expand both endpoints and every integer between them; count = end - start + 1. |
8010-8000 | Swap the endpoints, retain a correction note, then expand 8000 through 8010. |
any, all, or * | Expand to the inclusive range 0 through 65535. |
| Recognized service name | Map to the curated conventional port and protocol pair or pairs; strict numeric mode reports the token as ignored. |
| Scanner status word | Ignore common words such as open, filtered, and tcpwrapped without treating them as ports. |
| Repeated protocol-port pair | Keep one set member and increment the duplicate count. |
Port numbers above 65535 and unrecognized tokens are invalid. Valid entries remain available when some tokens are ignored; the service review records those input notes. If no valid port survives, result generation stops.
Rule Core
Review rules run after normalization, so severity changes never alter the underlying TCP and UDP sets.
- An inclusive input range receives a broad-range row when its count is greater than or equal to the selected threshold. The threshold accepts 1 through 65536 ports.
- Dynamic/private destinations from 49152 through 65535 receive a Medium cue for edge and internal reviews, or Low for a scanner target.
- The internet-edge context keeps catalog severity unchanged. Internal policy reduces Critical to High. Scanner validation reduces Critical to High, High to Medium, and Medium to Low.
- Catalog matches are sorted by contextual severity and port number. Critical and High rows contribute to the high-signal count.
Output strings compress consecutive values independently for TCP and UDP. The Nmap form uses T: and U:; nftables lines preserve the transport before the destination-port set.
Limitations and Privacy Notes:
Parsing and file reading happen in the browser. The checker does not connect to an address, scan ports, query a service registry, or change firewall rules.
- Text analysis accepts up to 200,000 characters. Large ranges expand into individual set members before being compressed.
- Service aliases and security cues come from a bounded catalog. Ports can run unrelated software, and unlisted services can still be risky.
- Remove sensitive hostnames, ticket details, and internal notes before sharing exported lists.
Worked Examples:
Mixed scanner and runbook notation
Given three lines containing T:22,443, U:53, and 8082-8080 https filtered, the parser produces TCP 22, 443, and 8080 to 8082 plus UDP 53. The reversed range is corrected, https repeats TCP 443 and increments the duplicate count, and filtered is ignored as a scanner status word.
References:
- Service Name and Transport Protocol Port Number Registry, Internet Assigned Numbers Authority.
- RFC 6335: Internet Assigned Numbers Authority Procedures for Transport Protocol Port Number and Service Name Registry, RFC Editor, August 2011.
- How to check if a Linux service is listening on a port, Simplified Guide.
- How to allow a port through the firewall in Linux, Simplified Guide.