...
| # | Name | Description | Status | Tools | Review Comments | ||||
|---|---|---|---|---|---|---|---|---|---|
| 1 | Deploy a Firewall | A layer 4 firewall MUST separate all internet-facing RADIUS servers and the internal network. Access must be controlled and monitored. | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 2 | Allow ICMP | Firewalls MUST permit ICMP to allow centralised monitoring of RADIUS servers | MUST | NRO shows web site with ICMP monitoring results (OT manually) | |||||
| 3 | Limit admin access | System administration (RADIUS and associated systems) MUST be preformed over a private internal network ONLY. | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 4 | Assess connectivity risks | All protocols permitted access to the servers MUST be risk-assessed (e.g. SMB and RDP may present security risks) | MUST | Carry out assessment (OT manually) | |||||
| 5 | Regulate external port access | A deny-all policy MUST be applied, permitting only the minimum ports necessary for authentication (e.g. UDP 1812, Status-Server 18121, TCP 2083 if RadSec is used). | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | Why do we care about not running 1645. (Or even random other ports, like the hosted SP may do.) | ||||
| 6 | UDP fragmentation | Make sure UDP fragmentation works | MUST | Test this once a year with eduroam managed IdP - one account per organisation, verify results (OT automatic) Can be checked by peers. | |||||
| 7 | Regulate Internal port access | A deny-all policy MUST be applied, permitting only the minimum ports necessary for administration functions (e.g. TCP 3389 for RDP or TCP 22 for SSH) | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 8 | Undertake patch management | All server operating systems and applications MUST be kept fully patched and up to date (SysAdmins must apply risk assessment criteria to deciding whether to deploy early patches against zero-day exploits or to follow stable releases) | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 9 | Ensure consistent timestamps | All servers MUST be configured against the same time-synched NTP server to minimise issues with log reconciliation. | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 10 | Make back-ups | All servers and configuration files MUST be regularly backed up (as a minimum after every configuration change) | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 11 | Conduct monitoring | Servers MUST be configured to detect and log rogue behaviour such as password brute forcing. Where automated defence is possible, it SHOULD be deployed (e.g. increasing authentication back-off times) | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 12 | Retain authentication logs | All authentications to eduroam infrastructure systems MUST be logged. Such logs may constitute personal data and MUST be managed in a GDPR-compliant way. All such logs should be timestamped against a synced NTP source and held for a minimum of <central policy specified period?>. | MUST | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 13 | Enable Alerts | Servers MUST be configured to send alerts (with copies of logs) to SysAdmins so that incidents can be detected and responded to in real time. Alert systems should be regularly tested for effectiveness. | MUST | NRO checks that this is the case with the FTLRs (show test results) & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 14 | Deploy secure CA servers | CA servers MUST be hosted on a dedicated, locked-down server in a secure location, configured for minimum user access. Such servers SHOULD have a fully qualified domain name, although this MAY not be published through DNS. | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 15 | EAP requests always carry it | ||||||||
| 16 | Adopt AES | eduroam wi-fi services MUST implement WPA2 Enterprise with the use of the CCMP (AES) algorithm | MUST | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 17 | Don't intercept traffic | NROs and members MUST NOT deploy interception technology or otherwise monitor the content of visitor or roaming traffic (e.g. do not use TLS or SSL interception proxies) | MUST NOT | NRO checks that this is the case with the FTLRs & NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 18 | Disable PAP | Password Authentication Protocol MUST NOT be used between access points and RADIUS servers | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 19 | DIsable SPAP | Shiva Password Authentication Protocol MUST NOT be used, as their encryption is reversible (see reference 7) | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 20 | Disable MS-CHAPv1 | Challenge Handshake Authentication Protocol is considered weak and MUST NOT be used. | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 21 | Disable WPA-TKIP | The WPA specification MUST NOT be supported and the TKIP algorithm MUST NOT be employed in eduroam services | MUST NOT | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 22 | Suppress Accounting | RADIUS accounting messages MUST NOT be forwarded to the eduroam international RADIUS Proxies. They may contain potentially sensitive information and therefore GDPR compliance duties. NB: conflicts with existing policy, which states it SHOULD be supported. | MUST NOT | Check accounting messages towards the TLRs (OT automatic) | |||||
| 23 | Secure RadSec server identities | If RadSec is used, X.509 certificates must be used to identify RADIUS servers | MUST (optional) | Check FTLR server configuration (NRO self), check TLR configuration (OT automatic) | |||||
| 24 | Deploy dedicated servers | NRO-level RADIUS servers SHOULD be dedicated to the task, not supporting other local or national services, in order to reduce their attack surface. | SHOULD (MUST?) | NRO verifies that this is the case with the FTLRs (NRO self) | |||||
| 25 | Suppress VLAN attributes | Dynamic VLAN attributes SHOULD NOT be sent in Access-Accept replies to the NRPS. | SHOULD NOT (MUST NOT?) | 26 | Adopt network segmentation | Network segmentation SHOULD be considered, placing roaming users into a separate segment to local organisation users. | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |
| 2627 | Deploy VLAN spoofing countermeasures | the visitor network design SHOULD prevent devices from mailiciously placing themselves into unauthorised VLANs | SHOULD | NRO verifies that this has been communicated to eduroam IdPs/SPs (NRO self) | |||||
| 2728 | Conduct external penetration testing | NROs SHOULD regularly conduct vulnerability assessment of internet-facing eduroam infrastructure. | SHOULD | To be carried out by the NRO in cooperation with the national CERT team (NRO self) | |||||
| 2829 | Conduct internal vulnerability testing | NROs SHOULD regularly conduct vulnerability testing from within the internal network of eduroam infrastructure. | SHOULD | To be carried out by the NRO in cooperation with the national CERT team (NRO self) | |||||
| 2930 | Separate non-eduroam guests | NRO and its members may offer a public guest Wi-Fi service for those unable to access eudroam; such users SHOULD be provisioned onto a separate network from eduroam visitors, with its own authentication, monitoring, and anti-circumvention measures. | SHOULD | ||||||
| 3130 | Incorporate redundancy | NRO-level RADIUS servers SHOULD be deployed in a redundant, diverse configuration to maximise availability and meet SLAs | SHOULD | ||||||
| 3231 | Deploy hardened servers | NRO-level RADIUS servers SHOULD be hardened to recognised best practice standards (includes secondary/backup RADIUS, certificate servers etc.) | SHOULD | ||||||
| 3332 | Adopt encrypted comms | NRO SHOULD recommend to members that they use a VPN to protect communications between Access Points and the RADIUS server. | SHOULD | ||||||
| 3433 | Set Operator-Name | Where possible, NRO and members SHOULD ensure all Access-Request packets proxied to the NRPS contain the Operator-Name attribute correctly set to the relevant realm. | SHOULD | ||||||
| 3534 | Set eduroam-SP-Country | Advised to NROs to set eduroam-SP-Country attribute in particular for RadSec | SHOULD | (etlr also does it, but not for RadSec) |
...