Unmaintained open ports on a server pose a security risk. If there's a way to communicate with your server that you don't know about, you can't protect it. You should know exactly what ports are open on your systems. If any of them aren't intentionally available, you should close them on the server and block them at the firewall level.

The Quttera port scanning API lets you set up custom scripts for checking the status of your ports and discovering any that are unexpectedly open. It lets you eliminate vulnerabilities and reduce your attack surface.

Every service that runs on an IP network has a unique address, which clients use to communicate with it. It consists of the IP address (either IPv4 or IPv6) and a port number. They identify the server and the service, respectively. Ports are numbered from 1 through 65535.

The TCP and UDP transport layer protocols each have their own ports. TCP port 80 is a different port from UDP port 80. Port 0 is a wild card reserved for internal use and never occurs in a request or response. Under TCP, ports 1 through 1023 are "well-known" ports reserved for specific uses. Here are a few examples:

Some ports above 1023 are widely recognized, such as 8080 for private Tomcat servers. Any service can use any unclaimed port number above 1023, and private services may change ports to be less discoverable. The use of a given port number is only a convention, and there's no guarantee that it represents a particular protocol or service. Running a mail server on port 80 would be confusing and pointless, though.

Every open port represents access to software on the server. The more ports are open, the greater the attack surface to defend. The default installation of an operating system or application may open up ports that aren't necessary in your environment. You might not know that there's software listening on a port, and you can't maintain what you don't know about.

Some ports may be open for legacy software that shouldn't be used today. Examples are unencrypted FTP and Telnet, which SFTP and SSH have superseded. The software operating those ports could be old and buggy.

Some applications install servers without telling you. There may be legitimate reasons for doing it, but sometimes they verge on spyware and are poorly protected. You should at least know that these servers exist and what ports they're listening on. If you don't want them, you can block access to them.

A hosted public website can run on a shared or dedicated service.
With shared hosting, you are one of several tenants on a server. The hosting company carries much of the responsibility. It manages the server and installed software, installs updates and patches, and decides on the configuration. As a customer, you have little control over the system that underlies your website.

The risk is higher because attackers might exploit other tenants' vulnerabilities. For instance, if your directories aren't properly protected from each other, a directory traversal exploit on another website might let an attacker infect your Web directory. It could install malware that runs on a previously unused port.

You can complete port scanning on your shared-hosting domain for open ports. If you find any unexpected ones, you can report them to the hosting company, possibly letting it discover otherwise unnoticed malware.

Dedicated hosting is growing more popular, even for small websites. A virtual private server (VPS) doesn't cost much more than a shared site. It gives you better security since no one else is on the same server. At the same time, you have greater responsibility for maintaining it. You need to keep its software updated and monitor its activity. Port scanning is an important part of security operations.

The Quttera port scanner API gives you a list of all the open TCP and UDP ports. It gives the number of each open port, the protocol, and the name of the service or application listening on the port.
For each port, the report states whether it is open, filtered, or closed. A filtered port is blocked by a firewall; a closed one means the request reached the server, but no service responded.

More precisely, a filtered port doesn't respond at all; the ping times out. A closed port sends a response rejecting the query. A service can be configured not to respond at all, in which case it will be reported as filtered.

For each open port, the administrator can decide whether a service is mandatory, optional, or unauthorized. To decrease the attack surface, the admin can turn off all services that aren't needed and examine the source of unauthorized ones. The safest course is to block the unwanted ports in the firewall as well as disable them on the server.

The port scanner API is a subset of the Quttera Malware Scanner REST API. It uses GET and POST requests to initiate a scan, check its status, and report the results. It provides three request types:

• Port Scan (POST): Issues an asynchronous request to find the open ports on a domain. The results can be returned as JSON, XML, or YAML. If information no more than 15 minutes old is available, it will return a report immediately.
• Port Scan Status (GET): Returns the status of the current port scan request. If no request is current, it will return a 404 (not found) status. The value it returns will be NEW, SCAN, SCANNED, or DONE.
• Port Scan Report (GET): Returns the information from a prior port scan.

For each port, the report includes the port number, the transport protocol (TCP or UDP), the service or application, the state of the port, and the status of the request. The report will follow this pattern:

When you join the Quttera API program, you can automate scans for malware, SSL support, and open ports and promptly discover any unexpected changes. One more piece of your security strategy is in place, keeping your network running properly.