Network Services and Results
Overview
Section titled “Overview”Network scans produce two types of output: network service records that describe what is running on each discovered port, and vulnerability findings that describe specific security issues detected against those services. This page is a reference guide to both — what fields a network service record contains, which vulnerability types the scanner detects, and how these findings integrate with the rest of the vulnerability pipeline.
Network service record fields
Section titled “Network service record fields”Each open port discovered during the discovery phase creates a network service record. The record captures the following information:
| Field | Description |
|---|---|
| IP address | The target address — IPv4 (e.g., 203.0.113.5) or IPv6 (e.g., 2600:9000:20ef:d200::1) |
| Port | The open port number (e.g., 443, 22, 3306) |
| Protocol | The transport protocol: TCP, UDP, or SCTP |
| Service name | The detected service identifier (e.g., ssh, http, https, mysql) |
| Product | The software running on the port (e.g., OpenSSH, nginx, Microsoft IIS) |
| Version | The detected software version (e.g., 8.2p1, 1.18.0) |
| Banner | The raw service banner text returned by the service, if available |
| Virtual host | For services multiplexed on the same IP and port via SNI or HTTP Host headers |
The services list shows the Endpoint, IP Address, Port, Service, Product, Source (the cloud account or domain the target came from), and IP Owner for each service. For TLS services, the detail page also shows the TLS grade, supported TLS versions, cipher suite, and certificates.
Version and product fields are populated using service fingerprinting during the discovery phase. These fields may be empty if the service does not return identifiable version information.
Vulnerability types
Section titled “Vulnerability types”After discovery, each network service is assessed in a vulnerability phase that combines:
- Automated checks — Checks are chosen from the detected service fingerprint. What runs and how severe a match is depend on the checks that apply to that endpoint.
- Fencer protocol checks — Rules that flag especially risky internet exposure (cleartext remote access, common database protocols exposed to the internet, unencrypted HTTP, and similar patterns).
Automated checks by service
Section titled “Automated checks by service”| Detected service | Checks that run |
|---|---|
| Web services (HTTP and HTTPS) | HTTP and SSL/TLS checks |
| MySQL, PostgreSQL, Microsoft SQL Server, MongoDB, Redis, Memcached, Elasticsearch | Checks for that database or cache |
| SSH, RDP, VNC, Telnet, FTP, SMB, LDAP | Checks for that remote-access or file-sharing service |
| SMTP, POP3, IMAP, DNS | Checks for that mail or DNS service |
Services that match none of these are still recorded and evaluated by the Fencer protocol checks. Exact findings depend on how the service responds; the checks are not an exhaustive catalog of every possible CVE.
SSL/TLS vulnerabilities
Section titled “SSL/TLS vulnerabilities”HTTPS services that only offer TLS 1.1 or older (TLS grade F) are also tested for well-known SSL/TLS vulnerabilities:
| Vulnerability | Description |
|---|---|
| Heartbleed | OpenSSL memory disclosure vulnerability (CVE-2014-0160) allowing extraction of private key material and session data |
| POODLE | SSL 3.0 padding oracle vulnerability (CVE-2014-3566) enabling decryption of encrypted traffic |
| CCS Injection | OpenSSL ChangeCipherSpec injection (CVE-2014-0224) allowing man-in-the-middle decryption |
| DROWN | Cross-protocol attack via SSLv2 (CVE-2016-0800) enabling RSA decryption of TLS sessions |
| LOGJAM | Export-grade or weak Diffie-Hellman parameters (CVE-2015-4000) |
| ROBOT | Bleichenbacher RSA padding oracle in TLS |
| FREAK | Export-grade RSA accepted (CVE-2015-0204) |
| SWEET32 | 64-bit block ciphers (3DES) accepted (CVE-2016-2183) |
| RC4 | RC4 cipher suites enabled |
Protocol exposure checks
Section titled “Protocol exposure checks”Fencer flags these protocols when they are exposed to the internet:
| Severity | Protocols |
|---|---|
| Critical | Telnet, TFTP, remote shell (rsh/rlogin/rexec) |
| High | FTP, RDP, VNC, SMB, NetBIOS, LDAP, rsync, NFS |
| Medium | MySQL, PostgreSQL, Microsoft SQL Server, MongoDB, Redis, Memcached, Elasticsearch, unencrypted HTTP |
| Low | SSH |
Severity mapping
Section titled “Severity mapping”Findings are assigned severity levels as follows:
| Severity | Examples |
|---|---|
| Critical | Cleartext remote access (for example Telnet), severe issues raised by automated checks (for example Heartbleed) |
| High | Internet-exposed SMB, RDP, or VNC, cleartext FTP, severe TLS or application issues raised by automated checks |
| Medium | Internet-exposed database protocols, unencrypted HTTP, other high-risk exposure patterns |
| Low | Internet-exposed SSH, and other configuration weaknesses when severity is below Medium |
INFO severity filtering
Section titled “INFO severity filtering”Findings at INFO severity are automatically filtered out and do not appear as vulnerabilities. INFO results from scanners typically represent informational observations — such as confirming a protocol is in use — rather than actionable security issues on their own.
This filtering keeps your vulnerability list focused on actionable findings and reduces noise from routine service enumeration output.
Linking to cloud resources
Section titled “Linking to cloud resources”When a network scan target comes from a cloud account (e.g., AWS), Fencer links discovered services back to the originating cloud resource where possible. For example:
- An open port on an EC2 instance IP is linked back to that EC2 resource in the cloud account
- An RDS endpoint with a vulnerability is associated with the database asset
This linkage gives you context about which cloud resource needs remediation, rather than just an IP address.
Each finding includes
Section titled “Each finding includes”- Severity — Critical, High, Medium, or Low
- Description — A plain-language explanation of the vulnerability and its potential impact
- CVE references — Where applicable, the relevant CVE identifier(s)
- Remediation guidance — Specific steps to resolve the finding (e.g., “Disable SSLv3 support”, “Restrict access to trusted IP ranges”, “Enable Redis authentication”)
Examples
Section titled “Examples”Reading a network service record
After a discovery scan on an AWS account, you see a network service record with:
- IP:
198.51.100.42 - Port:
6379, Protocol:TCP - Service:
redis - Product:
Redis key-value store, Version:6.0.16 - Banner: (empty)
This tells you Redis is running on this IP. Fencer raises a Medium “Redis service exposed to the internet” finding, and the automated Redis checks may raise further findings (for example missing authentication), depending on what the service returns to the scanner.
Understanding a TLS-related finding
A critical-severity TLS finding means an automated check identified a serious flaw in the service’s cryptographic configuration or implementation. The description links to CVE references where applicable and includes remediation guidance (for example upgrading affected software or disabling weak protocols). Address Critical and High TLS findings before lower-severity items on the same service.
Troubleshooting
Section titled “Troubleshooting”- Service name shows “unknown” — The service could not be fingerprinted. This is common for custom or heavily modified services. The port is still recorded, but service-specific checks cannot be selected for it.
- Version is empty — The service did not return identifiable version information in its response. Checks that rely on version detection may produce incomplete results.
- Expected vulnerability not detected — Confirm that the target is reachable from Fencer’s scanning infrastructure. Some vulnerability checks require specific protocol handshakes that may be blocked by firewalls or load balancers.
- Too many INFO-level results — INFO findings are automatically filtered. If you are seeing INFO entries, they may be appearing in scan logs rather than the vulnerability list. Only actionable findings (Low and above) appear in vulnerability management.