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:
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.
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.
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.
The machine is accessible via the network and physically through the use of a console.
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)
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.
The system is monitored using scripts that
The data generated by these scripts is collected and checked at by the test-traffic operators on a regular basis.
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.
Please notify us when you are applying (router) filters. This will allow us to perform more efficient trouble shooting.
Measurement may be influenced either per accident or my malicious intend. Although we consider this very improbable, we can think of the following issues:
In general, the data will constantly monitor on internal consistency.
The test-measurement boxes do not need any support from the local technical contact during normal operations. In the rare events that local support is needed the RIPE NCC operators will contact the local technical contact with a request for local support.
You can expect requests for operations by letter, email, phone or fax. Please check the identity of the requester in one of the following ways.
If you doubt the reliability of a request please contact the test-traffic operator.
Halting the machine is a task that is preferably performed by the test-traffic operator. However there might be cases a system needs to be shutdown. In the case such a emergency shutdown is needed proceed as follows.
A power-cycle will normally be sufficient to reboot the machine.
Address: | RIPE NCC |
Test Traffic Measurement Project | |
Singel 258 | |
1016 AB Amsterdam | |
The Netherlands | |
Telephone: | +31 20 5354444 |
Fax: | +31 20 5354445 |
email: | [email protected] (for operational issues) |
[email protected] (for other issues) | |
URL: | http://www.ripe.net//test-traffic |
Project Members: | Henk Uijterwaal |
Olaf Kolkman | |
Daniel Karrenberg | |
PGP Fingerprint | pub 1024/861884CD 1998/02/05 |
RIPE NCC Test Traffic Project | |
Key fingerprint = | |
97 B5 07 E3 66 23 FA 35 9C 5B A3 07 00 6D B7 36 |