Guidelines for NAT Policy Compliance

Security Operations is responsible for monitoring the campus networks for signs of compromised systems and other intrusions, as well as vulnerabilities that could be exploited by hackers to gain unauthorized access to campus systems. When security issues are detected, notifications are sent to the registered security contact for remediation. Security notifications include the following information:

  • IP address of affected host
  • Port used by affected host (for TCP/UDP traffic)
  • Timestamp of observed incident (all times are UC Berkeley local time unless otherwise specified)

Using this information, the security contact is responsible for locating the system responsible for the notification and ensuring that required corrective actions are taken. When multiple systems are using the same shared public IP address, it can be difficult to determine the system responsible for the observed network traffic and ensure that the reported issue is corrected. Implementing these guidelines will help ensure that security incidents involving NAT devices can be successfully resolved.

Access control

Your NAT device must use an appropriate method to restrict access to specific hosts authorized to use the device. It is not acceptable to offer public, unauthenticated access to the campus network, especially over wireless when physical access to the ports is not required to connect. Some acceptable access control methods include:

  • MAC Address filtering
  • WPA2-PSK ("Personal")
  • 802.1x ("Enterprise")

Note that for wireless routers, WEP is a very weak protocol and the access password can be obtained easily by "sniffing" traffic to and from the wireless device, and therefore it is not an appropriate method for access control.

Logging

Setting up appropriate logging on your NAT device is essential in order to identify hosts behind the device in response to security incidents. Without these logs, Security Operations cannot help to identify the responsible system, and we cannot resolve reported incidents until the system is identified. Guidelines for appropriate logging:

  • Log all private IP addresses assigned by the device, or configure fixed private addresses for each authorized device
  • Log inbound and outbound connections made through the device, including timestamp, source IP address/port, and destination IP address/port
  • Synchronize the device to a network time server, such as the campus network time servers: http://www.net.berkeley.edu/time/
  • Save at least two week's worth of logs from the device. Since devices has limited internal memory, it may be necessary to offload logs to external storage. Commonly supported methods include:
    • Sending logs via email
    • Storing logs on flash memory connected to the device through a USB port
    • Sending logs to an external syslog server
  • Review your logging setup for completeness, and make sure you understand how to retrieve and review logs in response to security incidents

Request for exceptions

If you are unable to comply with the requirements under this policy, you may submit an exception request:

https://security.berkeley.edu/MinStdsException.html

Please be prepared to answer the following questions when submitting your request:

  • What aspect of the NAT policy are you unable to comply with, access control or logging?
  • Is airbears/airbears2 wireless coverage available in this location? If so, why can't this service be used as an alternative to the NAT device?
  • Is the NAT device under current vendor support, with the latest firmware/software updates?
  • If you are unable to maintain logging in compliance with NAT policy, are you prepared to remove all access to the NAT device in response to security alerts, and add devices back only after they have been checked for the identified security issue?
  • What is your long term plan for compliance with the NAT policy?

Exceptions will be granted for a fixed period of time, up to a maximum of one year, with an opportunity for renewal.