Test Traffic Measurement Project Security Document Olaf Kolkman (okolkman@ripe.net) Henk Uijterwaal (henk@ripe.net) RIPE NCC March 27, 1998 Document: RIPE-179.ps Version: 1.0 1 Introduction This document is part of a series that describes the design, setup and implementation of the Test-Traffic project at the RIPE-NCC [1]. Here we will discuss the security issues that are relevant to the test-traffic measurement program. This is a dynamic document, which will be updated when need arrises. The test-traffic measurement boxes are connected to networks that are vital for ISP operations. Some of the security issues that come to mind when thinking about of hosting such a box are: * Use of the test-boxes to generate a very high load on the network. (Denial of service attack). * Using the test-box as a stepping stone to other machines in the network. * Using the box as a packet sniffer. However, if a measurement machine should be compromised it will not be useful for packet sniffing if it is on a switched network. If there is the possibility to put the test-traffic machine in a switched network we advice to do so. These kind of 'attacks' can only be done by persons having control over the test-measurement box. In the section 2 we describe how we secure the test-boxes so that only authorized personnel can access the machines. Not important for the day-to-say operation of the hosting ISP but important to the project itself is the issue of data integrity. In section 3 we will address the issues that have to do with the measurements itself. 2 Securing the test-boxes Our policy is to implement mechanisms and procedures so that only authorized personnel has access to the machine. To check the success of these measures we constantly monitor the system on unauthorized changes. 2.1 The OS The operating system we the test-boxes is FreeBSD 2.2. Since this operating system is freely available, `hackers' might find security holes faster than in proprietary systems. On the other hand there is a broad user base that checks and upgrades the system if needed. The open nature of the OS also implies that the security policy cannot be based on 'security through obscurity'. We actively track the mailing list and web sites on FreeBSD security issues and immediately take action when security holes are discovered. 2.2 Access The machine is accessible via the network and physically through the use of a console. 2.2.1 Physical access Physical access to the machine should be restricted to persons that are trusted by the network operator where the box is positioned. The network operator should realize that somebody with access to the machine and proper knowledge can become root without difficulty. Technical contacts at the site should only connect a console to the test-box when asked by RIPE NCC personnel. (See appendix A for further information on how such a request will be made) 2.2.2 Network access Only ssh connections are allowed to and from the machine Access to a user shell on the machine over the network can only be established using ssh [2]. The authentication takes place over an encrypted channel using RSA based authentication. In order to reduce the risk exploits of (yet unknown) bugs in network daemons all the services except those that are strictly necessary for operations have been disabled. The disabled services include all the daemons from the rsh suite, telnetd and ftpd. Services 'listening' to specific ports are specified in table 1 Table 1: Services listening to external traffic protocol protocol port number tcp ssh 22 udp ntp 123 syslog 514 router 520 To reduce the risk that a compromised system is used as a stepping stone we removed most of the network client programs (telnet, ftp etc) and utilities such as compilers. Note, however, that these measures do not provide security as such; a powerful shell language like Perl needs to remain on the system for the measurement software, can be used for any network client or server task. We believe that the disabling of these services has a delaying and hopefully discouraging effect on trespassers. 2.3 System Monitoring The system is monitored using scripts that * Check on the file system content, * Check on change of file permissions and ownership. * Check general system health (availability of resources etc). The data generated by these scripts is collected and checked at by the test-traffic operators on a regular basis. 2.4 Additional comments If we notice that a machine has been compromised we will contact the local technical contact (see section A) and take appropriate actions. If a technical contact at the ISP has a strong suspicion of a hacking attempt originating from our test-box at his site, he may switch the system off (see appendix B). We prefer you contact our operation staff first before performing an emergency system stop, but always contact us after a security related event. The hosting ISP's can increase security in the following ways. * Place the measurement machine in a locked rack in an area with access control. * Be careful not to add the host name or IP address of the test-box in local configuration files. (As a bad example, you might run scripts that use your zone file as an input for /etc/host.equiv). Please notify us when you are applying (router) filters. This will allow us to perform more efficient trouble shooting. 3 Measurement integrity Measurement may be influenced either per accident or my malicious intend. Although we consider this very improbable, we can think of the following issues: * Modification of time on the test-boxes. This might be done through the use of the ntp daemon control program xntpdc. As a countermeasure we only accept control commands from xntpdc after proper authentication. * Denial of service attacks on the test-box or the local network. In cases this becomes an issue countermeasures can be configuring in routers of the hosting ISP. * Benchmark optimizing. Although we consider this kind of attack very improbable we implemented handles in the software design to somewhat disguise the measurement packets. In general, the data will constantly monitor on internal consistency. References 1 H. Uijterwaal, O. Kolkman, ``Internet Delay