How to remediate – Nessus SYN scanner

1. Introduction

The Nessus SYN scanner vulnerability means an attacker can determine which TCP ports are open on your systems. This allows them to identify potential services running and target those with exploits. It affects any system connected to a network, particularly servers and firewalls. A successful attack could lead to information disclosure, service disruption or availability issues.

2. Technical Explanation

This vulnerability is caused by the use of a SYN ‘half-open’ port scanner which sends TCP SYN packets without completing the full three-way handshake. Attackers can identify open ports by observing responses to these probes. This scan is quicker than a full TCP connect scan, but may cause issues with less robust firewalls and leave unclosed connections if the network is busy.

• Root cause: The system responds to SYN packets without requiring a completed connection.
• Exploit mechanism: An attacker sends SYN packets to various ports on a target system, analysing responses to identify open ports. For example, an attacker could use Nmap with the SYN scan option (-sS) against a target IP address.
• Scope: All TCP-enabled systems are potentially affected.

3. Detection and Assessment

You can confirm vulnerability by checking for open ports using network scanning tools or analysing firewall logs. A quick check involves listing listening services, while thorough assessment requires a port scan.

• Quick checks: Use `netstat -tulnp` on Linux systems to list listening TCP ports and associated processes.
• Scanning: Nessus itself will flag this as an informational finding during a standard network scan. Other scanners like Nmap can also identify open ports.
• Logs and evidence: Check firewall logs for SYN packets received on specific ports.

netstat -tulnp

4. Solution / Remediation Steps

Protect your systems by implementing IP filters to control network access. This limits the ability of attackers to scan and identify open ports.

4.1 Preparation

• Ensure you have a rollback plan in place, such as restoring the previous firewall configuration. A change window may be required depending on your environment.

4.2 Implementation

1. Step 1: Configure your IP filter to block unsolicited inbound SYN packets to ports not required for legitimate services.
2. Step 2: Review and test the firewall rules to ensure they do not disrupt existing network connectivity.

4.3 Config or Code Example

Before

# No specific rules for inbound SYN packets

After

# Block unsolicited inbound SYN packets on ports 1-1023
iptables -A INPUT -p tcp --syn -dport 1:1023 -j DROP

4.4 Security Practices Relevant to This Vulnerability

Practices like least privilege and network segmentation can help limit the impact of this vulnerability. Input validation is less directly applicable here, but secure defaults on services are important.

• Practice 1: Least privilege – only allow necessary ports open to reduce the attack surface.

4.5 Automation (Optional)

# Example Ansible playbook snippet to block SYN packets on specific ports
- name: Block unsolicited inbound SYN packets
  iptables:
    chain: INPUT
    protocol: tcp
    destination_port: '1:1023'
    syn: yes
    jump: DROP

5. Verification / Validation

Confirm the fix by re-running a port scan and verifying that unwanted ports are no longer accessible. Also, test key services to ensure they still function correctly.

• Re-test: Re-run the Nessus scan or Nmap scan and verify that open port findings have been reduced.
• Smoke test: Test key services like SSH, HTTP/HTTPS to ensure they remain accessible.
• Monitoring: Monitor firewall logs for dropped SYN packets on blocked ports as an example of successful mitigation.

netstat -tulnp

6. Preventive Measures and Monitoring

• Baselines: Update firewall baselines to include default rules blocking unnecessary inbound TCP connections.

7. Risks, Side Effects, and Roll Back

• Roll back: Remove the iptables rule using `iptables -D INPUT -p tcp –syn -dport 1:1023 -j DROP`. Restore firewall configuration snapshot if taken.

8. References and Resources

• Vendor advisory or bulletin: No specific vendor advisory available for this informational finding.
• NVD or CVE entry: Not applicable as this is an informational finding, not a specific vulnerability with a CVE ID.