How to remediate – Centennial IP Transfer Agent Detection

1. Introduction

Centennial IP Transfer Agent Detection refers to a network auditing service listening on a remote host. This is part of Centennial Discovery, an enterprise tool for network monitoring and auditing. Affected systems are those running the Discovery application and its associated agents. A successful exploit could allow unauthorized access to network information, impacting confidentiality.

2. Technical Explanation

The vulnerability occurs because the IP Transfer Agent (XFERWAN) service is exposed on the network. This agent facilitates communication between client agents and the Discovery Control Center. An attacker can potentially intercept or manipulate this communication. There is no known CVE associated with this specific detection, but it represents a potential security risk due to unnecessary exposure of an internal service.

• Root cause: The XFERWAN service is listening on a network port without sufficient restriction.
• Exploit mechanism: An attacker could attempt to connect to the exposed port and potentially gain access to information transmitted by Discovery agents or manipulate communication with the Control Center.
• Scope: Systems running Centennial Discovery, including OEM versions, are affected.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking for the listening XFERWAN service. A quick check involves identifying the port it’s running on, while a thorough method includes network scanning.

• Quick checks: Use netstat -an | grep XFERWAN to identify any processes listening using this name or associated ports.
• Scanning: Nessus plugin ID 139280 may detect the Centennial Discovery service. This is an example only, and results should be verified.
• Logs and evidence: Check system logs for events related to XFERWAN activity. Specific log files will depend on the operating system and Discovery configuration.

netstat -an | grep XFERWAN

4. Solution / Remediation Steps

To fix this issue, limit incoming traffic to the port used by the IP Transfer Agent if desired.

4.1 Preparation

• Dependencies: Ensure limiting access does not disrupt Discovery functionality. A roll back plan involves restoring the original network configuration.
• Change window: Coordinate with IT teams and obtain approval for network changes, if required.

4.2 Implementation

1. Step 1: Identify the port XFERWAN is listening on using netstat -an | grep XFERWAN.
2. Step 2: Configure your firewall to allow only necessary traffic to that port, restricting access from untrusted networks. For example, in Windows Firewall use New-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN" -Direction Inbound -LocalPort {port_number} -Action Allow -RemoteAddress {allowed_IP_addresses}
3. Step 3: Verify the firewall rule is active using Get-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN".

4.3 Config or Code Example

Before

# No firewall rule in place, port is open to all traffic

After

New-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN" -Direction Inbound -LocalPort {port_number} -Action Allow -RemoteAddress {allowed_IP_addresses}

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Least privilege – restrict network access to only authorized systems and users.
• Practice 2: Network segmentation – isolate sensitive services like Discovery from untrusted networks.

4.5 Automation (Optional)

# Example PowerShell script to create firewall rule for multiple servers
$servers = @("server1", "server2")
foreach ($server in $servers) {
  Invoke-Command -ComputerName $server -ScriptBlock {
    New-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN" -Direction Inbound -LocalPort {port_number} -Action Allow -RemoteAddress {allowed_IP_addresses}
  }
}

5. Verification / Validation

Confirm the fix by verifying the firewall rule is active and that only authorized traffic can reach the XFERWAN port.

• Post-fix check: Run Get-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN" and confirm the rule exists with the correct settings.
• Re-test: Use netstat -an | grep XFERWAN to ensure the port is still listening, but attempt a connection from an unauthorized host – it should be blocked by the firewall.
• Monitoring: Monitor firewall logs for any denied connections to the XFERWAN port.

Get-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN"

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update your security baseline or policy to include restrictions on unnecessary network services like XFERWAN.
• Pipelines: Add checks in CI/CD pipelines to ensure new deployments do not expose sensitive ports without proper firewall rules.
• Asset and patch process: Regularly review asset inventories and apply necessary patches for Discovery and related components.

7. Risks, Side Effects, and Roll Back

• Roll back: Remove the firewall rule using Remove-NetFirewallRule -DisplayName "Centennial Discovery XFERWAN" and restore the original network configuration if necessary.

8. References and Resources

• Vendor advisory or bulletin: http://www.centennial-software.com/products/discovery/