21 Security of local CESNET2 networks

21.1 Summary

The CESNET National Research and Education Network consists of a number of local networks containing computers with various operating systems. Ensuring the security of large heterogeneous networks brings about great demands for the work capacity of their administrators, and it is known that especially large university networks often include insufficiently secured machines. The objective of this project was to make the unenviable job of administrators easier by providing them with access to a very useful software - partly available under the GPL licence, partly created within this project framework.

21.2 Security audit using the NESSUS program

The NESSUS program, its auxiliary programs as well as their use within the CESNET Association networks have been described in the last year's annual report already. The NESSUS program has been upgraded significantly; its authors have corrected many of its errors and its installation has become much easier - running a single installation program is sufficient. NESSUS security tests have become plentiful; they numbered around 1900 in mid-December 2003.

The NESSUS auxiliary programs developed within this project framework did not have to undergo any significant changes.

21.3 Intrusion Detection System using the SNORT program

The SNORT program is generally regarded as the most widely used one in its field (network traffic monitoring at zero costs). It has been described sufficiently in the last year's annual report, too. No SNORT auxiliary programs have been developed within this project.

21.4 Intrusion Detection System using LaBrea

The previous annual report has already stated that LaBrea slows down and limits the propagation of computer viruses and network worms - moreover, almost without any need for human intervention. One should add that LaBrea also checks for any received SYN-ACK packets which signify that someone is trying to set up a TCP connection using our forged source IP address - most likely, to attack the target using a Denial of Service attack. However, LaBrea responds to SYN-ACK by sending a RST packet and as a result, TCP connection is terminated and this attack fails. This proves again the usefulness of the LaBrea program for the overall Internet community.

The usefulness of the LaBrea program can be further extended significantly using several auxiliary programs developed within this project's framework. This year, our efforts have concentrated on them to make the life easier not only for the LaBrea administrators but also for those network or domain administrators who would be receiving our reports on their potentially compromised machines. These programs process the data recorded in the LaBrea output files; this way, LaBrea turns into a simple and very effective system for detecting attacks which target our network. In comparison with standard Intrusion Detection Systems, LaBrea with our supplementary programs is characterised by these important differences:

No complex and difficult configuration is necessary.
No physical servers have ever existed on the IP addresses monitored by the LaBrea system. As a result, noone but network viruses, worms and hackers can have any reason to attempt connecting there - every connection attempt can be rightfully classified as an attack.
LaBrea records only data from received packet headers; no data from received packets are recorded. This means that we know that an attack has occured as well as its source and destination addresses; however, we cannot tell the kind of virus or the sort of attack.
LaBrea records only the source and destination TCP addresses (including the port numbers) as well as the ICMP ECHO packets. All other protocols including UDP are ignored. However, we do not have to regret this; the UDP packets are forged too easily and too often.

21.5 LaBrea auxiliary programs

21.5.1 LaBreaBackEnd

This program can be terminated prematurely, as well as restarted later, without losing any results.

The LaBreaBackEnd operator can limit the number of resulting output files created; in addition, a limit count can be set on the command line. This limit count determines the number of connection attempts at which further processing terminates. The default limit count value is the minimum number of connection attempts detected; usually, this value equals "1".

To make the program run faster and to minimise the communication with WHOIS servers, results of previous WHOIS queries are cached. Therefore, no further WHOIS queries for the same IP address space or for the same domain are necessary. (Still, administrators of the APNIC WHOIS server have asked the CESNET director to confirm that this was an official project of the CESNET Association.)

Program ignores all connection attempts originating from those address ranges which IANA had not assigned to any Regional Internet Registry yet. (Therefore, administrators should monitor official reports about new assignments of IP space to the RIRs.)

If a reverse record of the originating (source) IP address exists, program checks if it matches the address record. Should they differ, no domain data are sought.

This program can be given a list of IP ranges which are of some special interest to its operator - e.g., all networks belonging to our autonomous system. Records about connection attempts originating within theses IP ranges can be processed separately - e.g., more often or in a different way than the records about the rest of attacks.

The LaBreaBackEnd can also be tailored according to wishes of domain or network administrators in the following ways:

to ignore attacks coming from given single IP addresses or IP address ranges
not to send the reports to given e-mail addresses
to replace given administrator address(es) by another - this is useful especially for those administrators who cannot update their contact records in their WHOIS databases
to send administrators of certain networks a single report for each recorded attacking IP address instead of the usual bulk report, if their RTT system requires this.

21.5.2 LaBreaReport

We can send the LaBrea IDS reports to a better set of CESNET network and domain administrators than to those found in the public WHOIS databases. Because of that, the LaBreaReport program has been modified to run in two passes. The first pass puts aside the reports addressed to the CESNET administrators to be checked manually; reports intended for the rest of Internet are sent in the usual way. (Usually, only several reports addressed to the CESNET administrators exist.) In the second pass, reports for the CESNET administrators are sent; unnecessary generic addresses, e.g., abuse@cesnet.cz, are removed automatically.

The program checks the administrator addresses to determine if the report is to contain only the Czech language message, English language message, or both.

Two different test modes can be selected on the command line: in the first one, no mail is sent; in the second one, all mail is sent only to a single preselected test address.

21.5.3 LaBreaReportDetailed

will be appreciated especially by those LaBrea IDS system managers whom some network or domain administrators will have asked for a detailed information about attacks. This program allows looking up all records about attacks coming from a single IP address (in this case, the IP address will be given directly on the command line), or about attacks coming from several IP addresses (the name of a file containing their list will be given on the command line). Also, attacks coming from whole networks size /24 or /16 can be looked up. The resulting file gives human readable attack dates and times (as opposed to the LaBreaReport which gives the "epoch time"), as well as a complete log of attacks (unlike the LaBreaReport which reports only the first and last ones). Just like the LaBreaReport, the LaBreaReportDetailed program masks out a part of the target IP addresses to improve the system security.

21.6 SYSLOG-NG

The Technical University of Ostrava network includes a new SYSLOG-NG server, so far operating in a pilot phase. Selected Unix servers as well as network elements send it their data to be logged; these are saved in separate files according to their fully-qualified domain names and "syslog facility". Purpose-made programs analyse these files constantly; selection of the most suitable program for on-line analysis of logged data is still going on.

Some kinds of attacks threatening the system or network security may be logged and sent to the SYSLOG server. The on-line analysis program running on the SYSLOG server should notice these incidents and react accordingly. In addition to security incidents, other incidents of varying importance are recorded together with other facts which may influence the functionality of network systems and their services. To be able to put the SYSLOG server into regular operation, the following tasks must be solved first:

securing the communication between the network servers and SYSLOG server
interface for reliable and timely sending of warning messages using E-mail or SMS (via the attached SMS gateway)
adding proper filters for detection of important events
proper selection of one or several programs for on-line analysis of log files.

When selecting appropriate hardware for the SYSLOG server, the most important parameters are the CPU speed, RAM size, hard disk capacity and speed. We selected an Optiplex GX150 made by DELL. The Debian Woody distribution with standard kernel 2.4 was chosen for the operating system. A GSM modem Siemens MC35i connected to the server operates as a SMS gateway; this can send appropriate warning messages to the administrators who can react fast even if not present at their terminals. This solution is not complete yet but even now it is clear that it improves the functionality and security of the whole network.

21.7 Results and Experience

21.7.1 NESSUS

Some of our colleagues we had relied upon were too busy to fulfill the requirements of the CESNET Network Operations Department: to display the security audit results (created by NESSUS and WebBackEnd) using the XML format, making it more user-friendly (clearer arrangement, optionally hiding some results, etc.). However, security audit of machines connected to the Prague-Dejvice CESNET network was performed every two weeks for the whole year 2003; its results were made available on a CESNET HTTPS server for each authorised user who also had received an e-mail summary of results beforehand.

Security audit of the Technical University of Ostrava machines has been using the NESSUS program in combination with the PTS tool described in last year's report. Results of security audits are distributed directly to the administrators of appropriate systems. Security audits are performed once a week.

Results of NESSUS security audits within the Academy of Sciences network confirm a well-known fact: very few machines running the Microsoft Windows operating system can be regarded as safe. One cannot depend on ordinary users to properly look after the security of their machines; as a result, these machines must be managed centrally. Therefore, NESSUS runs only occasionally in the Academy of Sciences network, mainly to discover those machines whose security updates were overdue. The security audit results are made available only to the appropriate network administrators.

21.7.2 SNORT

No auxiliary programs are necessary to run the SNORT program. It just needs a proper set-up to report as few false alarms as possible; achieving this is not easy - it depends on the administrator's experience and network traffic. An important benefit is the availablility of complete data which can be used for a detailed attack investigation.

SNORT ran as an Intrusion Detection System on all three workplaces of this project, especially at the Academy of Sciences. It proved its usefulness when detecting external network penetration attacks, recording attacks targeting single TCP or UDP ports, as well as detecting any "suspicious" internal network traffic.

21.7.3 LaBrea

The LaBrea server in the Prague-Dejvice network has been running over a year. It has been distributing some 500 to 1500 e-mails per week to those network or domain administrators where the connection attempts had originated. Absolute majority of those administrators who responsed personally was grateful for these notices; their reactions and suggestions helped us improve the LaBrea auxiliary programs.

Figure 21.1: Attacks recorded by the LaBrea IDS system (18. 10.-8. 12. 2003)

Summer 2003 has witnessed a surge of extremely active network viruses; their activity is still going on and confirms the importance of the LaBrea server - see Figure. Note: Smaller bandwidth recorded between October 13-October 20 resulted from changed configuration (the "-p" parameter), not from a smaller number of attacks.

Figure 21.2: Detailed recording of attacks in November 28, 2003

Comparison of the latest data with those published in the previous annual report shows an alarming fact: The data flow from the attackers to the LaBrea server reached saturation (2 KBps) within some 14 days in Autumn 2002. One year later, in Autumn 2003, this data flow reached saturation (now 8 KBps) within mere 7 hours...

21.8 Conclusion and plans

All software developed within this project framework has been published regularly on our FTP server ftp://ftp.cesnet.cz/local/audit/. Up-to-date information on this project progress as well as on new software versions are made available to every subscriber of the AUDIT-L@cesnet.cz list.

21.8.1 Future plans and further progress

Auxiliary programs forLaBrea work quite well. We plan to continue maintaining them but most of work seems to be finished.

We do not inted to develop any auxiliary software for SNORT; this program is useful but we plan to run it only should all other problem-solving methods fail.

The NESSUS program has been running routinely for a long time - together with the PTS or WebBackEnd program according to the administrator preferences. Both alternatives provide the operators of audited machines with all necessary information using the text mode. An improved user comfort which the CESNET Network Operations Department prefers would require using the XML format and a radically reworked user interface. If sufficient work capacity is available, no obstacles should impede the progress of this project.

contents