Port 150: SQL-NET — Oracle's Abandoned Front Door

The Abandoned Reservation

Port 150 is assigned by IANA to SQL-NET, a service name tied to Oracle's database networking protocol¹. Every time an Oracle client connects to a database server, it uses a protocol descended from SQL*Net, Oracle's Transparent Network Substrate (TNS). But that connection almost certainly does not happen on port 150.

It happens on port 1521.

Port 150 is one of the Internet's ghost ports: officially assigned, formally reserved, and functionally empty.

What SQL-NET Was

In the late 1980s, Oracle Corporation built SQL*Net to solve a genuine problem: how do you let a client application talk to a database server when the client might be running on a completely different operating system, using a completely different network protocol?²

The answer was TNS, the Transparent Network Substrate. TNS sat between Oracle's software and whatever networking protocol the system was running, whether that was TCP/IP, SPX/IPX, DECnet, or even AppleTalk³. The "transparent" part meant the application didn't need to know or care what was underneath. You wrote your SQL, and TNS figured out how to get it to the database.

This was not a trivial accomplishment. In the late 1980s and early 1990s, networks were a mess of competing standards. Getting an Oracle client on a Novell network to talk to an Oracle server on a TCP/IP network required exactly this kind of abstraction layer.

SQL*Net version 1 shipped in the late 1980s. Version 2 arrived in 1992 with Oracle 7, bringing the full TNS architecture⁴. By 1997, Oracle 8 repackaged the whole thing as Net8. Today it's called Oracle Net Services, and it still uses TNS at its core.

The Port That Oracle Left Behind

Here's where it gets strange.

Oracle registered two well-known ports with IANA for SQL*Net. Port 66 was the original, registered under the name sql*net⁵. When IANA later standardized service names (asterisks don't play well with service discovery), they assigned port 150 under the cleaned-up name sql-net¹. The contact listed on the IANA registration is Martin Picard.

Both ports sit in the well-known range (0-1023), the most privileged addresses on the Internet. On Unix systems, binding to these ports requires superuser privileges⁶. Getting a well-known port assignment is a mark of significance. It means IANA considered your protocol important enough to deserve a permanent, low-numbered home.

Oracle got two of them. And then chose neither.

When Oracle set up its default listener configuration, it chose port 1521, a registered port with no special system-level privileges. That's the port that appears in every Oracle installation guide, every DBA's muscle memory, every firewall rule in every enterprise data center in the world⁷. Port 1521 became synonymous with Oracle databases.

Port 150 became a footnote.

Why the Move?

Oracle never published a detailed explanation for choosing 1521 over its IANA-assigned well-known ports, but the practical reasons are clear. Well-known ports (0-1023) require root or administrator privileges to bind on Unix systems. For a database listener that needs to run reliably as a service, requiring elevated privileges adds complexity and security risk. A registered port like 1521 can be bound by any user with appropriate application-level permissions.

There's also the matter of timing. The IANA assignments for ports 66 and 150 were made early, when the port registration process was less formalized. By the time Oracle's networking stack matured into SQL*Net v2 with TNS in 1992, the practical advantages of using a higher-numbered port were well understood.

The Well-Known Range

Port 150 sits in the well-known port range (0-1023), managed by IANA under strict assignment procedures defined in RFC 6335⁶. These ports are reserved for system-level services and widely-used protocols. Historically, this range was a mark of legitimacy, a signal that the Internet's governing bodies recognized your protocol as critical infrastructure.

The ports surrounding 150 tell the story of an era:

Some of these are thriving (IMAP on 143 carries email for billions). Others, like port 150, are historical artifacts.

Checking Port 150

If something is listening on port 150, it's almost certainly not SQL-NET. You should investigate.

Linux/macOS:

# Check if anything is listening on port 150
sudo lsof -i :150

# Or with ss
sudo ss -tlnp | grep :150

Windows:

netstat -an | findstr :150

Network scan:

nmap -sV -p 150 target_host

Finding an active service on port 150 in a modern environment is unusual enough to warrant attention. It could be a misconfigured legacy Oracle installation, or it could be something that has no business being there.

Security

Port 150 does not have a significant history of exploitation tied to its assigned service, primarily because SQL-NET was never widely deployed on this port. However, precisely because it's a well-known port with an obscure assignment, it can be used as a hiding place. Malware authors have historically used little-known well-known ports as communication channels, relying on the assumption that administrators won't scrutinize traffic on ports they don't recognize⁸.

The best security posture for port 150 is simple: if you're not running SQL-NET on it (and you're not), it should be closed.