How to remediate – NIS Server Detection

1. Introduction

An NIS Server Detection indicates a Network Information Service server is running on a system. NIS shares user account information across a network without encryption, creating a security risk. This affects Linux and Unix systems commonly used for authentication and authorisation. A successful compromise could lead to loss of confidentiality, integrity, and availability of user credentials and access to networked resources.

2. Technical Explanation

The remote host is acting as an NIS server, broadcasting usernames, passwords, and other sensitive data in plain text over the network. Attackers can intercept this traffic to gain unauthorised access to systems within the domain. Exploitation requires network connectivity to the portmapper (port 111) and the NIS server itself. There is no specific CVE associated with simply running an NIS server; the risk lies in its insecure configuration.

• Root cause: Unencrypted communication of sensitive user data over the network.
• Exploit mechanism: An attacker uses packet capture tools like Wireshark to intercept NIS traffic and extract credentials. They can then use these credentials to log into other systems within the domain.
• Scope: Linux, Unix, and older macOS versions that utilise NIS for authentication.

3. Detection and Assessment

Confirming an NIS server is running involves checking listening services and network configurations.

• Quick checks: Use the command `rpcinfo -p` to list RPC programs, looking for ‘nisd’ or related entries.
• Scanning: Nessus vulnerability ID 10384 can detect an NIS server. This is provided as an example only.
• Logs and evidence: Examine system logs (e.g., /var/log/syslog) for messages related to ‘nisd’ or ‘ypserv’.

rpcinfo -p | grep nis

4. Solution / Remediation Steps

The best solution is to disable the NIS server and migrate to a more secure authentication method like Kerberos or LDAP.

4.1 Preparation

• A change window may be needed to minimise disruption. Approval from system owners is recommended.

4.2 Implementation

1. Step 1: Stop the nisd service using `systemctl stop nisd`.
2. Step 2: Disable the nisd service from starting on boot with `systemctl disable nisd`.
3. Step 3: Remove the NIS client configuration files (e.g., /etc/yp.conf).

4.3 Config or Code Example

Before

# /etc/yp.conf
domain example.com
server nis-server.example.com

After

# Remove /etc/yp.conf file entirely or comment out all lines.

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – limit the number of systems running NIS and restrict access to only those who need it.
• Practice 2: Secure defaults – avoid enabling unnecessary services like NIS by default.

4.5 Automation (Optional)

#!/bin/bash
# Stop and disable NIS service on multiple hosts via SSH
for host in $(cat /path/to/hostlist); do
  ssh $host "sudo systemctl stop nisd && sudo systemctl disable nisd"
done

5. Verification / Validation

Confirm the fix by checking that the NIS service is no longer running and network traffic is not being broadcast.

• Post-fix check: Run `rpcinfo -p` again; ‘nisd’ should no longer appear in the output.
• Re-test: Re-run the initial detection command (`rpcinfo -p | grep nis`) to confirm NIS is disabled.
• Smoke test: Verify that users can still log into systems using alternative authentication methods (e.g., Kerberos, LDAP).
• Monitoring: Monitor system logs for any errors related to NIS or user authentication failures.

rpcinfo -p | grep nis # Should return no output

6. Preventive Measures and Monitoring

Preventative measures include regular security assessments and policy enforcement.

• Baselines: Update your system baseline to disallow NIS servers unless specifically required.
• Pipelines: Include checks in your CI/CD pipeline to prevent the installation or configuration of NIS on new systems.
• Asset and patch process: Regularly review asset inventories to identify any unexpected NIS servers.

7. Risks, Side Effects, and Roll Back

Disabling NIS may disrupt applications that rely on it for authentication.

• Risk or side effect 1: Applications using NIS will be unavailable until alternative authentication is configured.
• Risk or side effect 2: Users may experience login issues if the transition to a new system is not seamless.

8. References and Resources

• Vendor advisory or bulletin: Consult your Linux distribution’s security advisories for specific guidance on NIS.
• NVD or CVE entry: No specific CVE exists for running an NIS server, but related vulnerabilities may be found by searching for “NIS” on the NVD website (https://nvd.nist.gov/).
• Product or platform documentation relevant to the fix: Refer to your Linux distribution’s documentation on configuring and disabling NIS services.