Structuring the European Research Area Specific Programme
RESEARCH INFRASTRUCTURES ACTION
DESIGN STUDY
A European Network of Affined Honeypots
Contract No. 011923
Deliverable D3.1: Demonstrator Pilot Operation
Outline: Because of organisational reasons, the deliverable is organised in two separate parts. Part 1 covers the set up of the NoAH pilot testbed whereas part 2 details the enhancements of the testbed towards a large scale network infrastructure resulting from the experiences gained during the operation of the testbed.
Abstract: For a test of the NoAH architecture a pilot testbed was set up which was utilized to evaluate all technical components as well as organisational procedures developed in the NoAH project. Technical components include Argos sensors, components to redirect connection to a high interaction honeypot (e.g. honey@home), the central database storage, and the presentation of the resulting data. In addition, organisational workflows to integrate new sensors and to co-operate with external partners have been tested. In addition, an outlook to an extension into a full scale productive environment is given.
Although the original architecture is well-designed some limitation remain affecting an operative deployment of a large scale infrastructure. All components monitoring address space redirect this data to a single high-interaction honeypot which does not change. In addition, the central data storage poses a single point of failure. To improve the overall performance of the network, we introduce a load-balancing mechanism which dynamically redirects data to one or more cluster of honeypots. This will spread the load equally to all honeypots. In addition, a high-availability solution will be used to eliminate single points of failure. This will improve the robustness of the architecture against hardware failures and denial of service attacks.
In addition, the experimental evaluation of the pilot testbed reveals some weaknesses of the weasel application for data presentation. These weaknesses grow in the importance with an increasing number of attacks. To overcome these weak points, a complementary web-application called Polecat was developed which is introduced in this deliverable.
Contractual Date of Delivery 30 September 2008
Actual Date of Delivery 7 November 2008
Deliverable Security Class Public
Editor DFN-CERT
Contributors
The NoAH Consortium consists of:
FORTH-ICS Coordinator Greece
VU Partner Netherlands
TERENA Partner Netherlands
FORTHnet Partner Greece
DFN-CERT Partner Germany
ETH Zurich Partner Switzerland
Virtual Trip Partner Greece
Table of Contents Part 1
1 Introduction ...8
2 Deployment plan...11
2.1 NoAH NDA and co-operation agreement...11
2.3 Technical and organisational workflows...14
2.4 Stepwise set-up of the pilot testbed...17
2.5 Towards a productive large-scale infrastructure...19
3 Technical Components...21
3.1 Central database repository...22
3.2 Sensor Technology ...23
3.3 Network infrastructure...25
3.4 NoAH Data Presentation Service ...27
4 Evaluation of the network architecture...30
5 Evaluation of attack data...31
5.1 Attack Statistics...31
5.2 Analysis of Snort alerts...34
5.3 Analysis of Argos alerts...37
5.4 Evaluation of the experimental results...46
1. Motivation of the improved architecture...1
2. Overview of current Linux and OpenBSD high-availability and load-balancing solutions...4
2.1 Relayd, CARP and pf in OpenBSD...11
2.2 Linux LVS and Linux-HA...17
2.3 Evaluation...19
3. Technical adaption in the NoAH architecture...21
4. Experimental Results...23
5. Enhancements of the data presentation...27
6. Summary...29
Appendices...31
A) Study on the presentation service...31
B) Non Disclosure Agreement...47
C) Co-operation Agreement...50
D) Configuration of the Relayd and pf in OpenBSD...56
Figure Index Part 1
Figure 1.: Schematic overview of the data and control flow in the NoAH environment. The black arrows symbolize the flows pf the data while the blue arrows symbolize the dependencies of data and
user groups. ...15
Figure 2.: Schematic overview of the NoAH pilot testbed architecture(demonstrator)...21
Figure 3: Schematical overview of the improved NoAH infrastructure. Improvements are the balancing of the honeypot loads and the avoidance of all potential single points of failure...27
Figure 4: Public weasel website presenting a list of Snort alerts...28
Figure 5: Overview of all Argos alerts recorded by the sensors...29
Figure 6: Details of an Argos alert caused by the W32.Blaster worm...29
Figure 7: Overall attack statistic.Each part of the chart represents the number of attacks exploiting a specific vulnerability...33
Figure 8: Overall attack statistic.Each part of the chart represents the unique number of unique sources exploiting a specific vulnerability...33
Figure 9: Attack originating from the IP address 206.183.178.160. The boxes in the middle contain the names of the corresponding class of Snort signatures. ...35
Figure 10.: Extract of the attack in figure 7.: In contrast to figure 7 the box EXPLOIT WINS overflow attempt represents the name if specific Snort signature instead of the name of the signature class misc-attack. ...35
Figure 11.: Extract of the attack in figure 7.: The specific Snort alerts are shown for the class web-application activity. ...36
Figure 12.: Extract of the attack in figure 7.: The specific Snort alert is shown for the class web-application attack. ...36
Figure 13.: Statistical overall of all Snort signatures triggered during an attack originating from the IP address 62.204.241.194. ...37
Figure 14: Analysis of the Argos alert caused by the attack of the W32.Blaster worm. The image shows the protocol specific information of the attack...40
Figure 15: Analysis of the W32.Korgo worm. Shown are the detailed protocol fields as presented by wireshark...42
Figure 16: Packet-dump of an attack targeted at the WINS replication service Windows 2000 server. ...44
Figure 17: Packet dump of an unknown exploit against a vulnerability in the WINS replication service in Windows 2000 server...45
Figure 18: Packet dump of an exploit of the Metasploit framework against a vulnerability in the WINS replication service...46
Figure 1: Schematical overview of the architecture of the NoAH pilot testbed ...2
Figure 2: Schematical overview of load-balancing...5
Figure 3: Load-balancing: Forwarding the connection via NAT...7
Figure 4: Load-balancing: connection forwarding by IPv4 tunneling...8
Figure 5: Load-balancing: Forwarding the connection via an application layer proxy...8
Figure 6: Cluster of servers sharing a common data storage...9
Figure 7: High-availability by redundant load-balancer...10
Figure 8: Relayd - Software Design...13
Figure 9: CARP Firewall Cluster...15
Figure 10: co-operation of PF and Relayd...17
Figure 11: Schematical overview of the components of Linux-HA...19
Figure 12: Schematical overview of the improved NoAH architecture...22
Figure 13.: Evaluation of the load balancer...24
Figure 14: Flow statistics to the cluster of honeypots...26
Figure 15: Tabular presentation of an attack by polecat. All snort alerts originating from a selected IP address are displayed...28
1 Introduction
The goal of the NoAH project is to produce a design study and perform the necessary technical work towards the development of an infrastructure for security monitoring based on honeypots technology. The project aims to gather and analyse information about the nature of Internet cyberattacks. It will also develop an infrastructure to detect and provide early warning of such attacks, so that appropriate countermeasures may be taken to combat them.
In order to test the functionality of the NoAH infrastructure and the integration of new sensors, the NoAH Demonstrator is implemented.
Technical aspects of an early warning system are an important issue: But it is necessary to understand not only the human interactions but also the organisational context. For an efficient and effective initiative against all kind of attacks as many as possible co-operating partners are needed. However, co-operating partners have different interests resulting in different roles and tasks. For example, some partners may be more interested in the analysis of the observed attacks whereas others focus on the protection of their own network using the results (e.g. attack signatures) of the project. In addition, the NoAH project aims to co-operate with external sites contributing data to the project (e.g. universities). This is why we distinguish between the following user groups:
Data analysts and researchers/scientists
Data contributors Public
Commercial customers
NoAH project partners
Data Contributors Public Customers
NoAH-Project
AnalystsTo establish a fair co-operation, partners will have multiple roles. For example, a site which will contribute data to the project will also be granted access to non-public attack data. The user groups and their descriptions are in detail:
NoAH project partners: The first user group consist of all NoAH partners officially participating in the project. First, their duties and responsibilities are the operation and administration of the NoAH demonstrator. For example, the administrative tasks include the registration and integration of new sensors, the technical administration of all technical components, and the maintenance of contact information and administrative documents like policies. Furthermore, the demonstrator is operated and maintained by the NoAH partners. For example, this includes the solution of technical problems and the analysis and presentation of the attack data.
Data contributors/suppliers: Data suppliers to NoAH are organisations,
teams or person(s) who are running a sensor / honeypot. They collect data and provide it to the NoAH project for an evaluation. In return they get information resulting from the analysis of attacks in order to protect their own systems. The data exchange can be done automatically or manually but in both cases it is necessary to synchronize the communication between inhomogeneous communication systems. It is possible to define preprocessing rules to reduce the amount of data and filter out unwanted information at this point.
In most cases the collected data is sensitive, so the contributors expect either a confidential treatment or limit the exposure of the transferred data (e.g. by anonymization). In general, all data may remain property of its collectors if required. To make sure that all mentioned aspects are attended, every participant has to sign a Non Disclosure agreement and optionally a Co-operation agreement according to the NoAH policies.
Analysts and scientists: Analysts and scientists are organizations, teams or
persons with access to the collected data of the NoAH project. They have and will get more special knowledge of how to interpret and analyse this data than other user groups, e.g the public. By participating in this project, analysts and scientists expect to get a more detailed overview of the current situation of network attacks and malware.
Every participating analyst or scientist will have to sign a Non Disclosure agreement (NDA) to make sure that they use the provided sensitive data in an appropriate way. Then the analysis results will be published in different ways, depending on the access rights (views) of the receiving user group.
Customers and commercial partners: This is a potential user group which may rely on NoAH services to secure their network (e.g. by subscription to a signature service) or to support their products (e.g. analysis of the attack data).
Since the demonstrator will not directly support any commercial services this user group is omitted in the rest of this document. However, since the demonstrator should prepare the project for the commercialization in a production environment we decided to list this user group in this section.
Public: This group contains all users that do not fall into one of the previously
mentioned groups, e.g. all persons who are interested in computer security. In addition, the honey@home contributors are assigned to this group although they contribute data to this project. The reasons for this decision are: the operation of a honey@home sensor is fully voluntary and for everyone available. Thus, any user can set up this honeypot without signing e.g. a NDA or co-operation agreement. As a consequence, this user group cannot be limited in any form and there is no way to test if the users are trustworthy. The remainder of this document is organised as follows. Chapter 2 summarises the organisational aspects of the pilot testbed set up. This covers the overall strategy how to set up and extend the testbed and how to acquire external partners for a co-operation. In Chapter 3 the technical components of the testbed are described in detail. The experiences gained by the pilot operation show if the testbed performs as expected. This evaluation is discussed in the next Chapter. The experimental results of the attack data colltected by the sensors of the NoAH testbed are presented in Chapter 5. Chapter 6 summarises the major results of the first part of the deliverable.
The experiences gained by the first phase of the pilot operation were used to improve the network performance of the testbed. These improvements are especially intended to support an expansion of the testbed into a large-scale operative network. These improvements are the scope of the second part of this document. Chapter 2 of the second part summarises the current load-balancing and failover solution in Linux and OpenBSD operating systems. With load-balancing and failover mechanism the robustness and efficiency of the architecture is fundamentally improved. Technically, this enables to dynamically relay network traffic to different honeypots. In the following chapter we discuss the application of these products in the context of the NoAH architecture and propose an enhanced NoAH architecture that overcomes the previously mentioned drawbacks. Chapter 4 gives an overview on the experimental results gathered by the application of the load-balancing.
2 Deployment plan
The NoAH project is more effective if there is a large number of external participants from all user groups. To acquire new co-operating sites all members of the project start introducing their established contacts first. IT-Conferences and other meetings related to computer security are good platforms for presenting the project and to get in contact with potential partners.
However, as previously pointed out each user group has its individual interests and requirements which must be appropriately considered for a smooth operation of the NoAH architecture. Further on, these interests can be even oppositional in some aspects. For example, a data contributor may insist on the privacy of its data or on the limited usage. However, a researcher may prefer as many details as available for a publication. Once this data is published it cannot be withdrawn any more. This is critical because a data contributor may only become aware of the sensitivity of their data after its public disclosure. Because of these reasons, formal regulations and rules of conduct are necessary to avoid conflicts. These are specified by the following documents:
A public Non-Disclosure Agreement (NDA) specifies the usage and access of
all confidential data for NoAH partners and the appropriate technical protection of the private data.
A co-operation agreement signed between the data contributors and NoAH
administrative role. Basically, this document specifies the rights and duties of both sites and the terms of data usage.
A co-operation agreement between the scientific partners and the NoAH project. Although the interests of data contributors and research sites differ in detail they are similar in most aspects and can be consolidated in the same document.
A technical specification of the set-up and integration of new sensors into the architecture.
According to the official NoAH policy, each new participant will sign an optional co-operation agreement and/or a Non Disclosure Agreement to protect confidential data. These documents are described in the remaining part of this chapter.
2.1 NoAH NDA and co-operation agreement
One of the most important asset of all projects concerned with computer security is trust. No project can survive without a trustworthy reputation, because each project relies on the co-operation with external sites, e.g. for the contribution or sharing of data as well as for the evaluation of its results. An important component to receive a high degree of trust is to define rules for the usage and handling of sensitive data. This includes the terms and rights of the data usage as well as the protection of confidential data. The later is defined in a non disclosure agreement (NDA).
The NoAH co-operation agreement defines expectations both in regard to the NoAH infrastructure and its service to the community and the NoAH partners, but also towards the NoAH partners themselves, that are participating in this effort. In addition, all terms of data usage are specified. For example, a commercial site won't co-operate with the NoAH project consortium, unless the rights to use the data are specified and the rights are compatible to the intended usage. This might include the right to use data for commercial services or the requirement that no data made available can be attributed to the commercial site. This co-operation agreement as well as the expectations defined within will be periodically reviewed by the NoAH partners to ensure that it is relevant and appropriate as defined by the mission of the NoAH project consortium.
Specific subsets of data might be handled differently from the whole set or other subsets as defined by this policy. For the purpose of the NoAH infrastructure the following subsets are defined:
Public data this data is designated for public consumption, for example for
anonymized data on a public web server informing about NoAH.
Private data this data is designated for consumption by NoAH partners
only. No publication of this data or work derived from this data revealing the identity of any NoAH partner or its systems is allowed. For example, this data includes raw attack data gathered by the honeypots. In addition, raw Argos alerts are in this subset.
Pseudonymized or anonymized data: To avoid privacy issues this data can
be stored in either in raw or in anonymized or pseudonymized form. Although the data is anonymized it may still contain confidential data. However, this data may be released for publication if all NoAH project partners agree.
Attack Signatures attack signatures are derived from the attack data and
allows to identify corresponding attacks.
In addition other types of information are handled and covered by the NDA, most notably the following:
Administrative data of NoAH partners and co-operating sites which
includes the contact information of each participating site this data belongs to the individual NoAH partner and is not designated for publication or use outside the scope of NoAH. Each NoAH partner might decide, which data about itself as well as NoAH components under its administrative control, is published and in which format or scope.
Administrative data about NoAH infrastructure including all components
not designated to be part of the local infrastructure of a NoAH partner this data does not belong to any specific NoAH partner but is important for the administration and operation of the testbed. While the NoAH partners agree on making information as widely available as possible, sensitive as well as critical details especially addressing operational concerns must be protected. For a smooth operation of the NoAH infrastructure and to avoid conflict of interests between the NoAH project and operating sites a regulation in form of a
co-Basically, this document formalizes the usage and import of data and how a new site can be integrated into the testbed. To consider the requirements of different user groups we distinguish between data contributors and scientific partners.
Co-operation Agreement between scientific partners (analysts/scientists) and NoAH
The interest of scientific sites is mainly related to the analysis and interpretation of resulting data. For example, detailed attack data gathered by the Argos sensors contains a lot of details like memory blocks of attacked processes. Analysis of this data can reveal which vulnerability has been tried to exploit and which effects are intended by the attack. However, this data may also contain sensitive information of data contributors or NoAH partners which must not be disclosed in any way. Thus, the partly contradictory interests of both sites have to be regulated. The co-operation agreement and NDA should consider the following points:
Analysts and scientists may use the resulting data for development, further
development, testing and measurements of their own concepts, applications or systems of all affected sites. This includes scientific publications after checking if there is any sensitive data that needs to be sanitized to remove all attributions to the actual owner/site .
All sensitive data has to be protected by appropriate technical solutions, i.g.
replacing site identifies through anonymized place holders.
Names of involved analysts/scientists/groups are published only with their
consent.
The NoAH project has to be immediately informed in the case of security
breaches that allowed unauthorized access to the protected or if protected data is disclosed by accident.
A description of the intended usage of the NoAH data is necessary before any
access can be granted. Eventually further information has to be given on request to further clarify the intended usage.
Co-operation Agreement between data suppliers and NoAH
Data suppliers are mainly concerned about the privacy and protection of sensitive information. In contrast, the NoAH project partners strive to avoid any disruptions of the NoAH infrastructure. This may happen if data sources or the import/export of data fails. In addition, the interpretation of statistical data requires a continuity of the data sources in terms of number of sensors and its quality. Thus, the NoAH project is interested to ensure a specific service level for all data sources. In addition, the ownership and usage rights for the data have to be specified. This is of especial importance for commercial partners. For those, a usage right to exploit the data for their business will be required to make the participation into the project worthwhile.
The ownership of the data gathered by a honeypot has to be defined. We
propose that the data supplier stays the owner of their contributed data.
All sensitive data has to be protected by technical and organisational
measures.
Non-Disclosure Agreement (NDA)
Basically the NDA bounds all projects partners and co-operating sites to keep all sensitive data private. While the co-operation agreement defines the rights of data usage, the NDA specifies which data is private and must not be disclosed in any form. This concerns data on storage devices or databases as well as all other private information about the sensor technology or interim / final results.
The NDA specifies all information that must be kept secret, basically:
The location of all sensors.
Sensitive information (e.g. information about unknown vulnerabilities yielded by the analysis of attack data) concluded from the sensor data. Information about participating sites.
Names of involved data contributors are published only with their allowance All contributed network address data may be anonymized either by the NoAH
project or by the participating site itself if requested. Which portions of the data are anonymized will be specified by the co-operating site.
All data will be transmitted via encrypted communication channels. 2.3 Technical and organisational workflows
The schematic overview of the data flow and co-operation is presented in figure 1. Each data supplier operates and administrates at least one sensor core symbolized on the left side of the figure. A sensor core consists of one or more sensors that are combined into an administrative unit and are assigned organisationally as well as operationally to the data supplier. The sensors might be clustered and combined with a load-balancing or high-availability solution. The sensor core encompasses sensors as a single administrative and operational unit and should not be confused with the NoAH core.
The data gathered by the sensor core is exported to the central data storage (in the bottom of the image). In addition, each site administrates their administrative data stored in a central database:
The configuration and type of sensor (e.g. operating system and running services)
The information about the site and its contact information.
The data storage is the collection of all sensor data. This data is used to produce signatures and alerts from the Argos data and is presented by a web-application (e.g. weasel). As introduced in Chapter 1 the users are distinguished by their role concerning the usage of the data:
Data analysts and researchers/scientists: Although both user groups analyse data and require access to data their exact role differ leading to different privileges:
• Data analysts: They analyse the data and have privileges to access the web-application presenting the data of the NoAH network. In particular, the data contains the Snort and Argos alerts.
• Researchers/scientists: This group benefits from the anonymized data made available for their own scientific contributions. For an efficient handling of the data it can be exported in an individualized format based on the requirements of any particular researcher.
Public: Statistical data is presented to the interested public.
Figure 1.: Schematic overview of the data and control flow in the NoAH environment. The black arrows symbolize the flows pf the data while the blue arrows symbolize the dependencies of data and user groups.
CERTs: The NoAH sensors see a lot of known attacks like Internet worms. The machines from which the attack originated is in almost all cases compromised itself. Interest of a CERT is to inform the sites about the security problems which affect them. For that reason the NoAH project will support the CERTs by providing them incident data in a specific format. For that reason export interfaces to the CERTs have to be implemented.
Data suppliers: This user group operates a sensor core in their administrative domain. All data gathered by these sensors is exported to NoAH's data storage. In addition, administrative data of data suppliers is kept in the NoAH data repository.
While black arrows show the technical data flow blue arrows symbolize control flows within the NoAH environment. The control flow from the site data to the presentation service affects the anonymization of the data. Each site can configure networks and IP addresses which are being anonymized. The networks are usually the networks operated by the site. Anonymization of the addresses included in the network ensures the protection of its data. No analysts of another site is therefore aware of the specific security problems affecting any particular site. Although all analysts can access the data as such this data cannot be attributed to a specific network or site.
The quality of attack signatures and published alerts is very critical. Especially, when commercial partners rely on the corresponding information. Therefore, all attack signatures and alerts are manually approved by analysts. This process of verification is symbolized by the two blue arrows which start at the analysts and end at the boxes signatures and alerts, respectively.
Each sensor core as shown on the left side of figure 1 is operated by a data supplier. Usually, a data supplier will operate a single sensor core. The following tasks are required if a new data supplier is integrated into the NoAH environment:
Registration of the co-operating site: The first step of the workflow is the
registration of any new participating site: Registration of contact information
(Only for data contributors) Registration of sensor information and integration into the demonstrator network. In the pilot testbed this comprises the exchange of the following information:
A SSH key and the IP address of the sensor for establishing a SSH tunnel from the sensor to the NoAH database. The SSH key is used to authenticate the sensor against the database server. All data is exported encrypted through this tunnel.
The exchange of credentials for accessing the database. For each new sensor, an individual database user is created and the the necessary privileges to import honeypot data are assigned to this new user.
As shown in figure 1 all contact information is collected in the central NoAH data repository. Currently, this is technically implemented as a WIKI based web application.
agreement. Since the pilot testbed focuses on the technical evaluation of the NoAH architecture, only the signing of the NDA is required.
Exchange of certificates or access credentials: To enable the partner's access to resulting data access credentials are exchanged. Currently, only passwords are used for authentication. For a large scale environment, digital certificates will be advantageous. Access is granted to:
Access to the web-application presenting the NoAH data. Optionally, full access to the database interfaces.
2.4 Stepwise set-up of the pilot testbed
Primary aim of the demonstrator is to show the effectiveness of the architecture and to gain experiences with the deployment of a large scale infrastructure. This includes to demonstrate that the previously developed components work together as intended and do not reveal any critical weaknesses. Beside the technical realisation of the infrastructure workflows for administrative and organisational tasks have to be established for the operation and administration of the demonstrator testbed. In addition, an important aim is to show that the demonstrator fulfils all requirements for a large scale NoAH network. For example, this contains the integration of external sites into the framework. These aims have been achieved by the following proceeding:
First step: Operation of the basic technical components:
• Sensor running a high interaction honeypot based on Argos and a Snort IDS system.
• Interfaces for the export and import of IDS data and Argos data. • Database components for the storage of the resulting data. • Web server with the basic features to present the attack data
Second step: extension of basic components and analysis of gained data: • Extension of the data presentation features
• Integration of additional high interaction sensors located at the NoAH partners
• Analysis of attack data
Third step: co-operation with external sites
• Data exchange and co-operation with external sites
• Integration of new sensors into the architecture (data contributors)
First step: Technical Evaluation of the basic components
Aim of the first step was to evaluate the technical components and their inter-operation and to gather first preliminary results. In addition, intention was to solve minor technical problems after their identification. The evaluation considered the following issues:
Estimation of the attack load: The load and capacity of the high-interaction
be exceeded in order not to loose any data. Even if the amount of attack data is limited by a sampling mechanism the expected attack load is important for a proper design of the sampling algorithm.
Identification of bottle necks: The NoAH architectures relies on an efficient
sharing of the workload by low- and high-interaction honeypots. The fraction of both components has to be well-balanced. For example, a balance between the number of low-interaction and high-interaction honeypots has to be found in order not to overload the latter. In addition, the export and import interfaces have to be designed in such a way that bottle-necks can be avoided. Otherwise, data gathered at the honeypots may get lost on the transport to the database.
Evaluation of attack data: Overall aim of the NoAH project is to gather data
on honeypots, to analyse attack data and the presentation of the corresponding data. The first stage of the demonstrator will show that the NoAH architecture is well-suited to reach these goals.
Second step: Extension of the demonstrator
Based on the experiences gained in the first step the testbed infrastructure was extended. These extensions also effect the scale of the infrastructure as well as the presentation service:
Extension of the testbed infrastructure: The testbed infrastructure was
extended in respect to the integration of new low- as well as high-interaction honeypots. Aim was to evaluate the scalability of the infrastructure. These experiences are fundamental for a large scale infrastructure.
Extension of the monitored address space. The NoAH architecture is designed to allow the extension of the number of monitored IP addresses. This is easily done by adding more low-interaction honeypots, or funnels like the NoAH router.
Enhancements of the presentation service: Extensions of the presentation
service are implemented to support a graphical presentation of the resulting honeypot data. In addition, extensions for including Argos alerts into the weasel web application are implemented.
Third step: Co-operation with external partners:
Beside the technical implementation, organisational and administrative solutions are required to co-operate with external sites. In this context, all sites are denoted as external which are not part of the NoAH consortium. The co-operation will start with a small number of selected sites to ensure the proper working of the workflows before it will be extended in due course later:
Co-operation with external sites that contribute data
Sharing data with researchers and CERT community sites
Integration of honeypots into the architecture which are operated by external sites. Thus, a technical and organisational integration of these honeypots into the NoAH network is required.
Although a large-scale infrastructure is beyond the scope of the pilot testbed it prepared for a large-scale infrastructure emerging from the testbed. The experiences gained by the previously introduced three-step process build the basis for a large scale infrastructure later considering all technical, administrative, and organisational aspects for a successful operation. For extending the demonstrator testbed towards a large scale productive infrastructure the co-operation with a large number of external sites is required. The locations of sensors will need to cover:
Academic networks Company networks
Networks of Internet provider CERT teams
The set up of sensors in different networks will guarantee to uncover attacks of different characteristics and to detect changes in requirements and technical pre-requisites. For example, some types of attacks are very wide-spread in networks of Internet service providers or academic networks but can hardly be observed in company networks. In contrast, targeted attacks are much more likely to occur in company networks. However, it should be noticed that the inhibition threshold of deploying honeypots at commercial organizations is much higher than at academic sites. In addition, legal issues often tend to be more impedient regarding the deployment of honeypots in company networks or other commercial networks. This is why the testbed focuses on the co-operation with academic and non-commercial partners in the first place.
The chance to detect an unknown attack or zero-day heavily depends on the size and the distribution of the sensor network. The probability for the early detection of randomly spreading Internet-worms and zero-day exploits increases directly with the number of sensors within the sensor network. Therefore, for a productive network it is crucial to acquire a large number of external sites operating sensors to transfer the NoAH testbed into a productive network.
Starting point for the acquisition were the existing contacts of the NoAH partners. For example, the DFN-CERT is associated with the German research network and already co-operating with universities and research institutes in other security projects. With over 300 members including almost all German universities and research institutes the research network is well-suited as one of the main data contributors for an NoAH sensor network. In addition, contacts to the European CERT community can be used for the acquisition of participating sites.
Most crucial point of the technical extension to a large scale architecture is the scalability of the architecture. This is affected by:
The ability to integrate new sensors: The architecture and workflows have to consider an easy integration of new sensors into the architecture.
The management of the sensor network: Ideally, the management of the sensor network is not or only loosely impacted by changes in the quantity of sensors and participating sites.
The operation of the sensor network: For high performance and high-reliable operation, all single points of failure and bottle-necks have to be avoided. This affects the central data storage, the sensors, and the data presentation.
As pointed out in the second part of this deliverable a combination of load balancing and high availability mechanism can help to meet these requirements. High availability solutions eliminate all single points of failures making the architecture more robust against failures. Load balancing mechanism enhance the scalability of the network management and ease the integration of new sensors. In addition, bottle necks of the sensor resources are avoided leading to an improved performance of the NoAH architecture. For an experimental evaluation we refer to the Chapter 4 of the second part of this deliverable.
3 Technical Components
The architecture of the pilot testbed (demonstrator) is shown in figure 2. The sensors are either directly connected to the Internet or they receive data from a tunnel, funnel, honey@home sensor, or a load balancer. Note, that the load balancer in figure 2 is optional and part of the enhanced architecture. Load balancing and other enhancements of the architecture are described in detail in the second part of this deliverable.
In the pilot testbed all sensor nodes are equipped with a Snort IDS and an Argos detector. All data gathered by the honeypots are sent to a central NoAH database. To protect the data during transport an encrypted SSH tunnel is established between the sensor and the database server. This data is presented by the web-application. In the remaining of this Chapter, these components will be introduced individually.
3.1 Central database repository
All data is exported by the sensors to a central database repository. Snort alerts are exported by an Snort export plug-in that is shipped with the weasel application. Argos alerts are transmitted by using the tool noahdb. Technically, a MySQL server based on a SuSE Linux 10.3 system is used as data storage.
For Snort as well as Argos alerts individual databases exist which allow a structured storage of both alert types. For privacy reasons, all communication between the sensors and the database server is encrypted. Technically, encryption is implemented by a ssh tunnel tunneling the connection to the database server. This solution is advantageous because the tunnel can be easily established with minimum configuration and no specialized software is required. A watch-dog script monitors processes and ensures that Snort and the data export are running and will restart both components if required.
Additionally, privacy concerns require an anonymization scheme to protect all confidential information of the architecture and participating sites. Technically, approaches can be separated into two categories: anonymization and pseudonymization of data records. While both eliminate all references to persons or concrete systems, pseudonymization retains the relation between data records and allows to identify correlations. For example, pseudonymized data can be tracked among different data records. For that reason, pseudonymization offers a lot of advantages for data analysis which cannot be done on anonymized data. In addition, pseudonymization is bijective and can for that reason be reversed by authorised persons. If the data is used for incident handling this is required to identify and inform all affected sites.
Technically, pseudomization in the NoAH testbed is realised by a constant mapping of sensitive data to pseudonyms:
Transformation of all sensitive IP addresses to a pseudonymized address. The
pseudonymized addresses must be distinguishable from real ones (e.g. by assigning addresses which are not routed in the Internet). In addition, a constant transformation is advantageous, which is a function of the transformed IP address. Thus, the analyst can rely on the property that equal pseudonymized IP addresses results from equal transformed addresses. Sensitive data is:
• IP addresses of the sensors.
• All IP addresses contained in the home networks of the data suppliers.
Allows each data supplier to reverse the anonymization regarding to the own
sensor and their home network.
Allows all other external partners to analyse the data with respect to their
needs. However, external partners must not be able to break the anonymization scheme. Thus, these sites must not be able to track back security attacks to a specific external partner of the project. Although, all partners can access the
example, statistical data about incidents can be compiled from anonymized data. In addition, the analysis of single attacks (e.g. zero-day exploits) does not require the knowledge about the sensor locations or the origin of the attack (raw IP addresses).
For the pilot testbed, a static transformation scheme was chosen which assigns all private IP address to bogus addresses. Anonymized data can be identified because bogus addresses can be distinguished from operational addresses. This scheme fulfills all above mentioned requirements and is efficient to implement. The anonymized data is stored in a separate database whose structure is equivalent to the database scheme used by weasel's Snort plug-in. The anonymized database provides the information for the internal presentation service to which all partners have access.
3.2 Sensor Technology
The sensor technology is the heart of the NoAH architecture. These sensors are designed to detect attacks and to record detailed data about the attack. Technically, the sensor is capable of the detection of known as well as unknown attacks. This data is the basis for the analysis and the generation of attack signatures. Most important aim is to reveal attacks which try to exploit unknown vulnerabilities (zero-day exploits). For that purpose, it is necessary to find out which vulnerability was intended to be abused to compromise the honeypot. Thus, the recorded data on the honeypot has to contain all details about the attack required for this analysis. In addition, the attack data reveals important information about compromised machines in the Internet, e.g. supporting the incident handling services of CERTs. To follow these aims, all sensors run the following sensor technology:
An Argos high-interaction honeypot: The Argos node is the primary
detection engine of the sensor. Its advantages are the high accuracy of the attack detection and the comprehensive data recorded from the attack. Special advantage is that the attack detection does not rely on a given attack signature. Instead Argos directly monitors the data flow inside the operating system and pinpoints the attack as soon as the control flow of a program is maliciously subverted. This technique is advantageous because it is generic and does not rely on any specific information about individual vulnerabilities. Thus, the detection mechanism exploit the generic characteristics of attacks to compromise a system. Because of this property, it is nearly impossible to elude this detection mechanism and all attacks that abuse all kind of buffer overflow and related vulnerability are reliably detected. Thus, Argos is capable of the detection of all attacks related to zero-day exploits.
A Snort sensor: A Snort sensor complements the Argos sensor functionality and is intended to detect and identify all known attacks. Argos implements a generic attack detection based on monitoring the data flow. While this approach is very accurate and reliable it is not capable of
the direct identification of a specific attack or vulnerability. In contrast, the Snort IDS relies on a list of signatures which are individually generated for a specific attack. All network traffic is redirected to a Snort sensor which applies a list of known attack signatures to the traffic. An attack signature is a set of elements characterizing a specific attack. In detail, a signature can contain:
Specification of IP packets to which the signature applies: • Source and destination IP addresses or network notations • Source and destination ports.
• Header properties (e.g. TCP flags)
The characteristics of the packet payload: • Constant strings or byte sequences • Regular expressions
For each attack, a corresponding signature exists. Thus, if a new attack or vulnerability is found, a new attack signature has to be produced. These signatures can be either produced manually or the signature is generated automatically by an algorithm (for example, machine learning) automatically from a set of attack packets. Automatic approaches of signatures have been developed in the NoAH project and were successfully evaluated in [D3.2 2008]. The drawback of the Snort IDS is that only known attacks are reliably detected. In general, new attacks are missed or only detected by incident because the IDS lacks a corresponding attack signature. However, a Snort IDS is very efficient for identifying known attacks and can be very easily deployed. Thus, both sensor technologies are complementary and can be ideally combined.
To summarize the sensor technology, Argos provides information about the success of the attack and its details. Snort contributes the identification of the vulnerability by correlation of the Argos alert with Snort alerts, if an attack signature is already available. For example, a single attack may lead to one Argos alert and one or more Snort alerts. The evaluation of the attack requires a correlation of these interrelated alerts. For that purpose, it is reasonable to assume that all correlating alerts are produced within a very short time interval and will usually originate from the same attacking host (same source IP address). Thus, correlation of both types of alerts is done by comparison of the time stamp and the IP address of the alerts. For instance, the cargos library allows to pinpoint the Ethernet frame which contains the attack payload. Thus, an Argos alert is correlated with one or multiple Snort alerts if and only if:
The source and destination IP addresses are equal
The time stamp of the Argos alert and the Snort alert are within a short time
interval
The identification of the vulnerability gets more complicated for zero-day exploits because the corresponding attack is missed by the Snort IDS. Thus the vulnerability has to be identified manually by the analysis of the Argos data. For the detailed description of the manual analysis of Argos alerts we refer to section 4.3.
file or database. Concerning the pilot testbed a plug-in of the weasel application has been chosen that exports the Snort alerts into a central database. We considered the weasel plug-in as the best alternative because it is designed to work in large sensor networks.
Currently, the following honeypots are deployed in the pilot testbed:
SuSE Linux 9.3: This is a Linux based honeypot intended to pinpoint attacks on outdated linux systems. Although the versions of the service programs are not actual, they do not suffer from severe known vulnerabilities which can be easily exploited from the network. The honeypot runs the follwing services: • VSFTPd FTP Service
• Apache2 webserver as included in the SuSE 9.3 distribution • OpenSSH server as included in the SuSE 9.3 distribution
Windows XP without service packs and security patches: This honeypot is
subject of a large list of known vulnerabilities which are abused be common Internet worms. Therefore, a large number of known attacks are monitored which produce a corresponding Argos alert. This honeypot is intended to analyse known attacks. As an advantage, the Argos alerts can be correlated with Snort alerts because all known attack should be detected by Argos and Snort simultaneously. Services include:
• A outdated Apache webserver vulnerable to the vulnerability in CVE-2002-0392 (Apache chunked encoding vulnerability).
• Vulnerable Windows services (RPC DCOM, LSASS)
Windows XP SP 2 fully patched: This honeypot is equivalent to the other
Windows XP honeypot except that Service Pack 2 and all available security patches are applied. Since all security patches are applied, no known vulnerabilities exists affecting the Windows services. For that reason, all Argos alerts are potential caused by zero-day exploits which is in contrast to the insecure Windows XP honeypot.
Windows 2000 Server SP4 without security patches: Although Windows 2000 is outdated, it is still largely deployed. Special aim of this honeypot is detect known attacks as well as zero-day exploits affecting Windows 2000 server. For that reason, the honeypot runs a large list of services which are prone to a large number of vulnerabilities:
• Microsoft IIS 5.0
• WINS replication service • Terminal services
• SMTP Server
3.3 Network infrastructure
The goal of the NoAH project is to produce a design study and perform the necessary technical work towards the development of an infrastructure for security monitoring based on honeypots technology. The project aims to gather and analyse information about the nature of Internet cyberattacks. It will also develop an infrastructure to
detect and provide early warning of such attacks, so that appropriate countermeasures may be taken to combat them.
The technology chosen is a network of co-operating honeypots shown in figure 2 which consists of :
Sensor nodes: Sensor nodes are realized by Argos and Snort IDS. They
implement the honeypot functionality which provides a fully operative system instrumented for attack detection.
Relays, tunnels, and funnels: These components are in the first line of the network and accept connections from attackers. They provide the following functionality:
Established connections are redirected to a sensor node (e.g. Argos VM). The sensor, to which the connection is relayed, can be either statically or dynamically chosen. The description of the second alternative will be the primary concern of this document.
The second aim is to concentrate IP addresses. For example, a range of consecutive IP addresses can be bound by such a component. All connections are relayed to a sensor node as described above.
A centralized data storage: All data gathered on the sensor nodes are sent to
a central database server.
A presentation service: This is a web application to present the data to the
project partners and the public.
To improve the network performance and the robustness against failures and attacks of the NoAH architecture, additional network devices are required:
The sensor nodes running Argos are the most critical components of the architecture. Primary reason is the high demand of resources which is required by the Argos virtual machine for the emulation of the guest CPU. In other words, the bottle-neck of the utilization of resources are the Argos sensors. For that reason the network performance can be improved by balancing the load between the Argos sensors. Technical solution is to integrate a load-balancer into the network architecture which redirects connections to the honeypots.
Failure of some components are critical for the NoAH architecture. For example, the central database server and the optional load-balancers are single points of failure. To overcame this problem all identified points should be made redundant. For all common operating systems solutions exist to realize high-availability services.
The improved NoAH architecture is shown in figure 3. In this architecture the load between the honeypots is balanced and all single points of failure are omitted. Technically, OpenBSD's relayd is selected for load balancing and Linux-HA to implement high availability. For further background and explanations we refer to the second part of this deliverable Improvements of the NoAH architecture.
3.4 NoAH Data Presentation Service
The presentation of all data gathered by the honeypots is implemented by a modified version of the weasel web-application. Basically, weasel presents Snort alerts of a distributed network of sensors in tabular form (figure 4). For instance, the public version of the presentation service is shown in which all sensitive data is anonymized. The selection of this product is the result of a survey of all potential applications which was conducted at the beginning of the working package. For the details we refer to the survey in the Appendix A.
The weasel web-application has been extended to include Argos alerts (figure 5) and to present attack graphs. To consider Argos alerts, two separate tablular views have been added presenting an overview of all Argos alerts as well as the details of a single Argos alert. The first table shows all Argos alerts in analogy to the corresponding weasel table Alert listing. Analogous to the weasel table, the table can be sorted by selecting a column and the order in which the column is sorted. For example, classification of the alerts can be done by sorting the table in respect to the value of the EIP. As a result, all types of alerts caused by prominent worms are grouped together. Unusual alerts show up as a single entry.
Figure 3: Schematical overview of the improved NoAH infrastructure. Improvements are the balancing of the honeypot loads and the avoidance of all potential single points of failure.
As a drawback of the tabular format correlations between multiple entries cannot be easily identified. Correlations between multiple entries exist, if
An attacking site attacks multiple sensors
During an attack, multiple different vulnerabilities are tried to exploit. Alternatively, the attacker applies different alternative exploits for the same vulnerability.
A combination of both is conducted.
Understanding of these correlations is important, to identify attack tools or to interpret the behaviour of an attacker. Attack graphs allow to represent such correlations in a graphical form. For example, they present all attacks which originated from a single host. Because similar attack tools produce similar graphs they allow to identify typical this tool. In addition, they help to interpret single attacks. For example, a manual attack will typically involve preparing scans for vulnerabilities and one or more subsequent attacks. Examples of attack graphs are shown in Section 4.2. During the evaluation of the testbed it points out that weasel is in trouble when the number of attacks exceeds a limit. For that reason, a new web-application Polecat has been developed which complements weasel (we refer to the second part for further information).
Figure 5: Overview of all Argos alerts recorded by the sensors.
4 Evaluation of the network architecture
The experimental operation of the pilot testbed revealed the strengths and weaknesses of the initial NoAH architecture. Overall, the experimental evaluation did not expose any weaknesses which affected the operation of the pilot testbed as such. However, it pointed out that the scalability of the testbed limits its practical size. For that reason, the architecture has been improved as described in second part of this deliverable to satisfy all additional requirements of a large scale productive environment.
One aim of the pilot testbed is to evaluate the scalability of the architecture. For a realistic stress test simulating a large-scale network of sensors the number of monitored IP addresses were increased to cover 10 class C networks. To simulate a peak of the traffic load, a distributed Nessus scan was conducted against this network. The experimental results of this stress test are:
Within a week the number of attacks exceeded 1.000.000. Most frequent attacks were originating from the MS-SQL worm and automatic attack tools trying to exploit the Windows vulnerability CVE-2003-0533 (LSASS service).
The data export as well as the database capacity were able to cope with this
amount of data.
The network load was balanced among the honeypots to avoid bottle necks
(we refer to the second part for further details).
The Weasel web-application showed problems while processing some requests. This includes all request which require an aggregation of attacks within the database query like the list of unique Snort alerts. If too many distinct attacks are selected, the web-application becomes overloaded and will not process the request properly. In addition, the features of weasel lacks functionality to analyse this amount of attacks.
To overcome the weaknesses of weasel an enhanced complementary web-application was developed Polecat which is introduced in the second part of this deliverable. An interesting observation is, that the number of attacks increased straight proportional to the increase of the IP addresses. The linear relationship can be expected to result from the randomly scanning behavior of Internet worms and automatic attack tools. Thus, the probability of an attack hitting the address space is proportional to its size.
5 Evaluation of attack data
The experimental results concerning the detetion of attacks are presented in this chapter. All attacks can be classified as follows:
Manual attacks. The attacker manually selects a system for the attack. Usually, this system is of special interest for the attacker. Attractive properties include the location, application, and connection to the Internet. For example, frequently used webservers are an attractive target because they can be manipulated to automatically attack other systems (e.g. [honeynet project 2007]).
Automated attacks. These automated attack tools are typically either originating from Internet worms or combined with malware deployed to build a bot network. A bot network is an architecture usually build by an attacker to easily control a large number of compromised hosts. For that purpose, after the initial compromise, a bot1 is installed which connects to a central control server. The control server allows the attacker to control all compromised systems on which a bot is running. Typically, these bot-networks are misused to scan for other vulnerable systems or to attacker system by distributed denial of service attacks (DdoS). Usually, the IRC protocol is abused for bot networks. In detail, the control server runs a IRC service. All IRC-bots joins an IRC channel established by the attacker and wait for commands on this channel (see [honeynet project 2005]).
In the remaining chapter first the overall statistics of all attacks detected by the pilot testbed are presented. After that, the specific results of the Snort IDS sensors and the Argos sensors are discussed.
5.1 Attack Statistics
Overall, 888100 attacks have been recorded in the time period until 29th Aug 2008
which contribute to the attack statistic. During the deployment of the pilot testbed, the numbers of monitored IP addresses increased monotoneously by increasing the number of sensors and extending the monitored IP address space. The address space was extended by components which monitor an address space and redirects all connection to a sensor (we refer to the second part of this deliverable Improvements on the NoAH network architecture for further details). Attacks have been seen originating from 5397 unique source addresses targeting 2150 monitored IP addresses. Overall, 235 distinct Snort signatures triggered during this time period. Pie-charts reqresenting attack statistics are shown in figure 7. and 8. which are based on the evaluation of the number of recorded snort alerts. Both statistics visualise the
1The word bot is derived form the word robot. It is a piece of malware that allows the attacker to control a compromised system.
top four attacks exploiting a specific vulnerability. In this context the quantity of each attack class is derived from the number of recorded snort alerts corresponding to the specific vulnerability. It is important to note that more than one snort signature can correspond to a vulnerability. For example, an attack exploiting the Windows LSASS vulnerability in CAN-2003-0533 results typically in three or even 4 snort alerts each corresponding to a different snort signature. In this case, we chose the maximum of all related snort signatures as the number of attacks. In detail, the attacks correspond to the following snort signatures:
Most frequent rule was MS-SQL Worm propagation attempt which is related to the Slammer worm. Next prominent rules exposing a similar number of occurrences were signatures to detect Windows exploits abusing a vulnerability in the Windows LSASS service (CAN-2003-0533):
BLEEDING-EDGE EXPLOIT LSA exploit
BLEEDING-EDGE EXPLOIT MS04011 Lsasrv.dll RPC exploit (WinXP) NETBIOS SMB-DS DCERPC LSASS DsRolerUpgradeDownlevelServer
exploit attempt
NETBIOS SMB-DS lsass DsRolerUpgradeDownlevelServer unicode little endian overflow attempt
This vulnerability is actively abused by a large number of different malware products including the Sasser and W32.Korgo worm and different trojan families (Win32/Gaobot, Win32/Sdbot,Win32/Spybot). The analysis of related Argos alerts resulted in the identification of the W32.Korgo worm. For that reason, most alerts are believed to be caused by this worm.
The signatures
NETBIOS DCERPC ISystemActivator path overflow attempt little endian
unicode
NETBIOS DCERPC NCACN-IP-TCP ISystemActivator
RemoteCreateInstance little endian attempt
which are related to the MS Blaster worm triggered 1758, respectively 594 times. This worm exploits a vulnerability in the Windows DCERPC service. Overall, 71 and 24 unique instances of the worms (unique source IP adresses) targeted 545 respectively 350 honeypots. Other exploited vulnerabilities in Windows are:
NETBIOS SMB-DS Session Setup NTMLSSP unicode asn1 overflow attempt
(CVE-2003-0818 / MS04-007)
BLEEDING-EDGE EXPLOIT MS04-007 Kill-Bill ASN1 exploit attempt
(CVE-2003-0818 / MS04-007)
NETBIOS SMB-DS umpnpmgr PNP_QueryResConfList unicode little endian attempt (CVE-2005-1983, MS05-039)
NETBIOS SMB-DS umpnpmgr PNP_QueryResConfList unicode little endian attempt (CVE-2005-1983, MS05-039)
Typically these attacks are conducted by trojan malware (e.g. win32/rbot). Evaluation of the statistics in figure 7 and 8. reveals a different attack characteristic. In contrast to the quantity of sources of Slammer attacks (unique IP addresses), the number of
(LSASS and DCERPC) or 65 (ASN.1). The exact number depended on the specific signature. The difference is believed to be caused by a different scanning behavior of the malware. The Slammer worm is known for its random selection of targeted IP addresses. Thus the worm chooses the next target address randomly. However, the W32.Korgo worm always attacked a continous range of IP addresses. As a consequence, an instance of Slammer worm hit our sensor network in the average only a few times, whereas the other malware often attacked all of the monitored networks. MS-SQL attack LSASS attack DCERPC attack ASN.1 attack Other attacks
Figure 7: Overall attack statistic.Each part of the chart represents the number of attacks exploiting a specific vulnerability.
MS-SQL attack LSASS attack DCERPC attack ASN.1 attack Other attacks
Figure 8: Overall attack statistic.Each part of the chart represents the unique number of unique sources exploiting a specific vulnerability.
5.2 Analysis of Snort alerts
As previously mentioned, the Snort IDS detects and identify all well-known attacks for which an attack signature exists. In general, these attacks can be distinguished as follows:
Attacks originating from Internet worms:
• The worm either selects a random IP address and conducts a constant list of exploits.
• The worm select a random network, scans this network (e.g. Ping scan) and attacks all responding hosts using a constant list of exploits.
Attacks conducted by automated attack tools
• An attacker configures an attack tool to automatically attack a network using a constant list of exploits.
Manual attacks:
• An attacker attacks a specific system using an exploit which has a large probability of success. Usually, the attacker manually scans the system for known vulnerabilities before the attack.
Specific for a worm attack is the payload of the attack which does not vary. Thus, all exploits contain a constant payload characterising the worm. Automatic attack tools show is similar characteristic and are not clearly distinguishable from worm attacks. However, most attack tools allow to arbitrarily configure the list of exploits. Typically, an exploit tool is applied to a continuous range of IP addresses. As a consequence all machines in the network are attacked by the same set of exploits. Thus, by chance a specific fingerprint can be found for each exploit tool or worm. Manual attacks are very often initiated by a preparatory scan for available services and vulnerabilities. For example, a connection to a service is established. Usually the service respondes with an announcement of its type and version. For instance, the response of a webserver contains product information, the version, and part of its configuration:
GET / HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Thu, 28 Aug 2008 08:24:58 GMT
Server: Apache/1.3.37 (Unix) mod_perl/1.29 mod_ssl/2.8.28 OpenSSL/0.9.7g
Connection: close
Content-Type: text/html; charset=iso-8859-1
These information allow the attacker to choose a specific exploit which likely succeeds to compromise the machine. However, a lot of attacker use different systems for the scan and the subsequent attacks to avoid an easy correlation between both activities.
