Embed Size (px)
Citation preview
Active defence through deceptive IPSApostolos Machas
Technical Report
RHUL–ISG–2017–8
10 February 2017
Information Security GroupRoyal Holloway University of London
Egham, Surrey, TW20 0EXUnited Kingdom
Student Number: 100832320
Apostolos Machas
Title: Active Defence through Deceptive IPS
Supervisor: Peter Komisarczuk
Submitted as part of the requirements for the award of the
MSc in Information Security
at Royal Holloway, University of London.
I declare that this assignment is all my own work and that I have acknowledged all
quotations from published or unpublished work of other people. I also declare that I
have read the statements on plagiarism in Section 1 of the Regulations Governing
Examination and Assessment Offences, and in accordance with these regulations I
submit this project report as my own work.
Signature:
Date: 22 August 2016
“All warfare is based on deception.”
Sun Tzu, The Art of War
i
Table of Contents
Table of Contents ........................................................................................................................ i
List of Tables ............................................................................................................................. iii
List of Figures ............................................................................................................................ iii
Abbreviations & acronyms ........................................................................................................ iii
Executive Summary ................................................................................................................... iv
1. Introduction ........................................................................................................................... 1
1.1 Cyber Threat Intelligence ................................................................................................. 3
1.2 (Pro)Active Cyber Defence & Deception .......................................................................... 4
1.3 Objectives ........................................................................................................................ 5
1.4 Report Structure .............................................................................................................. 5
2. Intrusion Detection ................................................................................................................ 6
2.1 Introduction ..................................................................................................................... 6
2.2 Signature-based Intrusion Detection ............................................................................... 8
2.3 Anomaly-based Intrusion Detection ................................................................................ 8
2.4 Stateful Protocol Analysis .............................................................................................. 10
2.5 Problems of Intrusion Detection Systems ..................................................................... 10
3. Honeypots ............................................................................................................................ 13
3.1 Introduction ................................................................................................................... 13
3.2 Low Interaction Honeypots ............................................................................................ 14
3.3 Medium Interaction Honeypots ..................................................................................... 15
3.4 High Interaction Honeypots ........................................................................................... 16
3.5 Problems of Honeypots ................................................................................................. 17
4. Honeypots & Intrusion Detection Systems .......................................................................... 19
4.1 Introduction ................................................................................................................... 19
4.2 Honeypots for Intrusion Detection ................................................................................ 19
4.3 Honeypots combined with Intrusion Detection Systems .............................................. 20
4.4 Redirecting malicious traffic to honeypots .................................................................... 21
5. Proposed Solution ................................................................................................................ 24
5.1 Network Topology .......................................................................................................... 25
5.2 Detailed System Overview ............................................................................................. 27
5.2.1 The Main Gateway (IPS) .......................................................................................... 28
5.2.2 The Honeynet .......................................................................................................... 29
ii
6. Evaluation ............................................................................................................................ 32
6.1 Internal Scan .................................................................................................................. 33
6.2 Conventional IPS ............................................................................................................ 35
6.3 Proposed System ........................................................................................................... 36
6.4 Exploitation .................................................................................................................... 39
6.5 Network Performance.................................................................................................... 39
7. Conclusion ............................................................................................................................ 41
7.1 Future Work ................................................................................................................... 42
References ................................................................................................................................. v
Appendix A: Installation Guide ................................................................................................. ix
Step 1: Virtual Network Configuration ................................................................................. ix
Step 2: The Main Gateway (IPS) ............................................................................................. x
Step 3: The Honeynet ......................................................................................................... xiii
Appendix B: Snort’s Modified “detect.c” ................................................................................... v
iii
List of Tables Table 1: Nmap Internal Scan .................................................................................................... 34
Table 2: Nmap scan (Conventional IPS) ................................................................................... 35
Table 3: Nmap Scan Proposed System ..................................................................................... 37
List of Figures Figure 1: Original Network ....................................................................................................... 25
Figure 2: Proposed network ..................................................................................................... 26
Figure 3: Emulated Network Diagram ..................................................................................... 27
Figure 4: Evaluation Network (Conventional IPS) .................................................................... 32
Figure 5: Evaluation network (Proposed Solution) .................................................................. 33
Figure 6: Findings Reported (Internal Scan)............................................................................. 34
Figure 7: Findings Reported (Conventional IPS) ...................................................................... 36
Figure 8: Findings Reported (Proposed System) ...................................................................... 37
Figure 9: Top Honeypots and Ports attacked........................................................................... 38
Figure 10: Top Usernames and Passwords used in Kippo & Crowrie Honeypots .................... 38
Figure 11: Elastichoney Top Attackers & Payloads .................................................................. 38
Figure 12: Network Performance ............................................................................................ 40
Abbreviations & acronyms CTI: Cyber Threat Intelligence
DoS: Denial of Service
DDoS: Distributed Denial of Service
IDS: Intrusion Detection System
IPS: Intrusion Prevention System
SIEM: Security Information and Event Management
iv
Executive Summary
During the last few years, there is a constant increase in the occurrence of security breaches
focusing both large and small organisations. As companies are becoming more and more
dependent on digital systems for their stable operation, the impact that a security incident
may have on their business significantly increases.
Common security mechanisms and techniques have been proven effective to some extent
against low level attackers, however, they may still fail against advanced and persistent
adversaries. One of the reasons of their failure is that they highly rely on the security
administrator’s skills and knowledge for their configuration. As a result, most security
mechanisms are effective only against already known attacks and remain vulnerable to new
or slightly modified attacks. As a result, the I.T. security community needs to immediately
identify modifications of already known attacks, and remain informed about new
vulnerabilities, techniques and tools.
However, as most common security mechanisms will block an attack on its early stage,
security analysts are not able to obtain any further information about the attack’s next steps.
This information, could be later used to identify new vulnerabilities or tools and upgrade the
deployed security mechanisms. On the other hand, if the security mechanism does not block
a detected attack, it will soon result in a security breach. Consequently, there is a trade-off
between the amount of information being collected on each intrusion attempt against the
level of risk that the organisation is willing to face.
In this report, we present and evaluate a security mechanism that attempts to solve the above
problem by combining two popular security mechanisms, Honeypots and Intrusion Detection
Systems. This mechanism, using an intrusion detection system, is trying to detect an attack on
its early stages, redirect and retain it into a Honeynet. The Honeynet will then, allow the attack
to move on its next steps, providing valuable information to the security community while the
adversary’s access to the original protected network will be blocked. If the honeynet seems
identical to the original network, adversaries will falsely believe that they have successfully
infiltrated the security mechanism without being detected. However, they will be detected
and redirected to the honeynet soon before their attacks oppose a real threat to the protected
network.
1
1. Introduction
During the last few years, there is a constant increase in the occurrence of security breaches.
A security breach, can be defined any successful attempt to deliberately compromise a
systems confidentiality, integrity or availability. A recent survey, conducted by PwC [1],
reports that during the last year, 90% of large and 74% of small organizations had suffered a
security breach; a 9% and 14% increase compared to the same survey conducted in 2014.
According to the same report, it is extremely frightening that only 18% of the large
organizations, identified immediately the attack while none of them had identified the risk
before the occurrence of the breach.
Businesses are highly affected by cyber-attacks as recent reports indicate a constant increase
on both the occurrence and the cost of security breaches. PwC’s report [1], estimates the
average cost of security incident is ranging from £1.46m to £3.14m for large organizations and
from £75k to £311k for small businesses. A Detica report in 2011 estimated the cost of cyber-
crime to the UK to be £27 billion a year [2] £21bn of which is the cost of cyber-crime to
businesses. Garg A. et al. on their research [3] focusing on security breaches that affect big
organizations, measure the impact of a security breach to the share price of the organization.
Their results indicate an average fall in share prices of 2.7% in one day, while the overall cost
of the events studied amounts to $20.2 billion dollars.
Companies and organizations are highly investing in cyber security and increasing their
information security expenditure in the fear of a possible security breach. Common security
measures include the security training of their personnel as well as the installation of various
security mechanisms such as firewalls and intrusion prevention systems. However, as attacks
are constantly changing, the effectiveness of these devices is often questioned as their
capability to block an intrusion attempt is usually limited to the preconfigured rules or
signatures they are using to detect the attacks. These systems are mainly focusing on
detecting an attack on its early stages (reconnaissance) and blocking the attacker without
providing any further insights of the attackers’ motives, intentions or skills.
This lack of information, often causes difficulties in the investigation of security incidents and
to the discovery and analysis of new attacks. Skilled and persistent adversaries still manage to
bypass the security perimeter of the above devices and disrupt the normal operation of
businesses. This has led to the implementation of active monitoring solutions such as SIEM
systems that can assist the organizations in real-time detection. SIEM systems can process and
correlate events produced by multiple devices and provide a more detailed view of an
attacker’s actions allowing an organization to detect, respond faster and mitigate security
attacks.
However, SIEM systems are limited to the output of the security devices they collect events
from; and just like intrusion detection systems, they suffer from a huge number of false
positive alerts. S. Barish in his article [4] highlights the importance of the security analyst for
the operation of an IDS system as well as the need for its correct tuning. A security analyst has
to successfully analyse these events, detect the attack and perform the necessary corrective
actions in a reasonable time frame. As a result, the success of these systems lies both on the
2
ability of the security analyst to correctly distinguish a malicious incident against normal
events and on the ability of the security devices to correctly alert the analyst for each
malicious attempt.
3
1.1 Cyber Threat Intelligence
While the immediate identification of a security breach is important for an organization, it still
does not prevent the occurrence of it. In order for security analysts to prevent a security
breach, they have to win a race against the attackers as they must detect and respond to the
attack before it succeeds and as the attackers’ techniques are becoming more and more
sophisticated, it can be argued that the attackers are currently in the lead.
Most information security solutions focus on the denial of access to sensitive information or
services to an attacker. Firewalls, Antivirus Software, Intrusion Prevention Systems, Email
Gateways, and various other security mechanisms usually operate on a “Yes or No” ruleset
allowing or preventing access to the protected resources. While this approach has been
proven effective against common attacks and unskilled individuals that are trying to infiltrate
the security perimeter of an organisation, it has failed multiple times to protect an
organisation against determined sophisticated adversaries.
Cyber Threat Intelligence (CTI) has been widely used by the I.T security community to
accurately detect and respond to emerging threats in a timely manner [5] [6] [7]. Despite the
fact that attacks are constantly changing and evolving, attackers are frequently using pieces
of already known to the security industry malware and tools that in some part can be
detected. Moreover, exploit kits, malware and botnets being sold as-a-Service are flooding
the black hat market as their effectiveness is gathering more and more supporters. Security
vendors, based on the events collected by security incidents publish intelligence feeds to their
customers containing valuable information that will assist them to identify and respond to a
potential attack.
Providing more information about the attackers’ tools and techniques enables the
organisations to develop a much more effective defence strategy as they are shifting from
reactive to proactive defence. However, as CTI is becoming more and more popular, many
security vendors are providing their customers with a huge amount of un-processed
information instead of actual intelligence [7]. This huge amount of unfiltered information
results into confusing security teams, increasing the number of false positives and creating a
misconception of security to large organisations.
Sophisticated attackers are utilizing techniques such as specifically crafted phishing emails,
weak authentication credentials and social engineering, targeting directly the end-points that
lie behind the security perimeter of the organisation. These Advanced Persistent Threats
(APTs) successfully evade the conventional security mechanisms and require a more
intelligent approach and a further understanding of the attackers’ background than typical CTI
can provide. As a result, the defending organizations require advanced mechanisms that will
enable them to increase the timeframe of the investigators to respond, disrupt the attacker,
and successfully block the attack before it succeeds.
4
1.2 (Pro)Active Cyber Defence & Deception
While the term Active Cyber Defence (ACD) has been discussed thoroughly by information
security researchers, government agencies and organisations during the last years, it is yet
unclear whether it refers only to offensive operations that take place beyond the defender’s
network or not. The U.S Defence Advanced Research Project Agency (DARPA) [8] describes its
ACD research program as a strictly defensive program that involves however, direct
engagement with the attackers. Farwell & Rohozinski [9], BCS [10] and Hathaway [11], refer
to Active Cyber Defence as a defensive strategy that includes, if not defined by, offensive
operations in order prevent and minimize the effect of a cyber-attack. These procedures, are
not restricted only to cyber but also armed attacks targeting the adversary’s system and
network and as a result they cannot be utilised for the protection of a corporate
infrastructure.
On the other hand, Ernst & Young [12] describes Active Defence, as a continuous process that
does not interact with the attacker’s network. Instead it focuses on the organisation’s defence
from carefully designed threat scenarios and the continuous “hunting” for adversaries that
have already infiltrated the corporate network. In this report, we follow the definition of ACD
as a real-time defensive strategy, tightly connected with Cyber Threat Intelligence, that
focuses on the detection, analysis and mitigation of cyber-attacks by utilizing techniques,
methods, and mechanisms that can disrupt or deceive the adversaries before they manage to
successfully achieve their goals [13] [14] [15].
Either offensive or not, Active Cyber Defence, strongly relies on Cyber Threat Intelligence for
the detection of sophisticated attacks while its operations usually produce vital intel for the
mitigation of future cyber-threats. Deception, as a non-offensive implementation of ACD [14],
can significantly increase the cost of an intrusion attempt to the attackers by confusing and
delaying them. It can be achieved by the implementation of Honeypots, Honeytokens or any
other mechanism that may deceive an attacker.
Deception, when implemented under an Active Defence strategy, usually exceeds a common
Honeypot deployment. Its main focus is the protection of the organisation’s network and
services against sophisticated attackers and threats and as a result, it has to be carefully
designed to deceive and detect even the most skilled adversaries. As described later in more
detail, various security mechanisms have been proposed that offer deceptive capabilities and
have been significantly effective against determined adversaries and 0-day attacks. Deception
appears as one of the most promising defensive techniques not only due to its effectiveness
against advanced threats but also due to its capability to produce intelligence in a more
detailed and accurate way than common security mechanisms do.
5
1.3 Objectives
This project aims to develop an active defence mechanism that will provide deception
capabilities to common intrusion prevention systems. This mechanism will utilise an intrusion
prevention system to distinguish between malicious and legitimate users and redirect any
malicious traffic to a honeynet. The honeynet will then attempt to deceive the attackers and
collect further intelligence about their methods, tools and goals that can be later used to
adjust the security policy and configuration of other security mechanisms. The developed
mechanism will be evaluated for its effectiveness in mitigating an attack and increasing the
cost (in terms of time, technical skills or equipment) for the attacker.
1.4 Report Structure
The report is organised as follows:
Chapter 2 takes a detailed look on intrusion detection and prevention systems. We
analyse and compare their two main categories (signature or anomaly based), and
the benefits and problems of intrusion detection.
Chapter 3 discusses the most common deception mechanisms, Honeypots. This
chapter provides a more exhaustive view of modern Honeypot systems and
Honeynets and analyses some the most popular low and mid interaction Honeypots,
their effectiveness and problems.
Chapter 4 looks at implementations of Honeypots combined with, or used as,
intrusion detection systems as well as implementations that focus on the redirection
of malicious traffic to honeypots.
Chapter 5 starts by presenting our proposed solution and its goals. We provide a
detailed view of its technical implementation and its design.
Chapter 6 evaluates the effectiveness and efficiency of the proposed mechanism,
providing details on the evaluation methods and tools that have been used and
comparing it with common security mechanisms.
Chapter 7 discusses the outcome of this project based on its initial goals and
provides proposals for future work.
6
2. Intrusion Detection
2.1 Introduction
Intrusion detection is of great importance for the security of an organization. No matter how
strict a security policy is or how many security devices have been installed for the protection
of the corporate network, a security incident may occur and the organization must be capable
to identify and respond to it as soon as possible.
Firewalls, provide indications of intrusion attempts that have been successfully blocked
however, they fail to provide any indications for intrusions that are performed through
connections that are already allowed by its rules. On the other hand, intrusion detection
systems are capable of detecting intrusions by distinguishing malicious packets and events
against normal ones and producing relevant alerts. Unlike firewalls, intrusion detection
systems are not limited to the IP header of the packet being processed. Intrusion detection
systems are able to inspect the whole network packet detecting attacks that target multiple
layers of the OSI model.
The first references on the requirement for a more sophisticated system that can monitor
user’s and systems activity and identify intrusive actions was made by James P. Anderson Co
in 1980 [16] where the ground for intrusion detection was set by describing an off-line system
that will process systems audit trails. However, it was until late 80s when the first model for
intrusion detection systems was proposed by Dorothy E. Denning [17]. Denning’s model, has
set a solid basis for intrusion detection systems on which further researches, primitive and
modern intrusion detection systems rely. Denning’s model can be described as a combination
of a Signature and Anomaly Based IDS where statistical metrics are used to identify anomalies
while events are being matched on a specific ruleset.
Intrusion detection systems are network or host based security mechanisms that try to detect
attack patterns. Network based Intrusion Detection Systems (NIDS) are hardware or software
based security mechanisms that inspect network traffic for any malicious activity, they have
to be configured and placed in such a way so they will be able to observe all the network traffic
of the protected systems. Host based Intrusion Detection Systems (HIDS) are applications that
monitor the network interface and the operating system of the host they are running on for
any malicious or anomalous traffic and system actions.
Apart from their ability to detect malicious activity in real-time, another significant feature of
most Intrusion Detection Systems, is their ability to perform packet logging and file capture.
While this feature does not influence their real time ability to identify an intrusion, it provides
valuable data for later or real-time analysis and forensics investigations. Most intrusion
detection systems can also be configured to respond to security incidents by acting as
intrusion prevention systems (IPS) and blocking or altering the malicious network packet.
However, when a network based intrusion detection system has been configured as an IPS, it
requires to be placed in such a way so it can fully control the network traffic (inline) and not
only observe it.
7
Since host based intrusion detection systems are usually focusing on a single system they are
incapable of inspecting general network traffic and detecting attacks that target the whole
network or a different host. However, unlike network based intrusion detection systems they
are able to identify host based attacks such as local exploits, registry or file changes, that do
not produce any network traffic.
The most crucial part of an intrusion detection system is its detection engine and depending
on the way it operates it can be classified as a Signature Based, Anomaly Based, or Stateful
Packet Inspection intrusion detection system [18]. Despite this classification, many proposed
intrusion detection engines operate based not only on one but on a combination of the above
detection techniques (Hybrids). For each suspicious event that is being flagged (and blocked
in the case of an Intrusion Prevention System) an alert is created that is logged either to the
local log system or to a centralized log server.
These alerts, based on their precision can be categorised in the following four categories:
False Negatives (Type I errors): Malicious events that the IDS failed to detect and have
been flagged as legitimate.
False Positives (Type II errors): Non-malicious events that the IDS inaccurately has
flagged as malicious.
True Negatives: Non-malicious events that have been flagged as legitimate.
True Positives: Malicious events have been detected by the IDS and flagged as
malicious.
Ideally an IDS will have zero rate of Type I or Type II errors. However, in practice Intrusion
Detection Systems tend to have huge number of False Positive alerts as it is wiser and less
risky to inaccurately mark a suspicious action as malicious. Malicious flagged events can be
later reviewed by a security analyst, to decide whether the action has been intrusive or not.
On the other hand, in the case of Intrusion Prevention systems where suspicious actions are
being blocked, a high rate of Type II errors will disrupt the availability of the protected service
as multiple legitimate but suspicious-looking actions will be denied. Moreover, a high rate of
False Positives, may create confusion and disrupt the security analysts as it will increase their
workload [19].
As a result, IDS and IPS configuration, tuning and evaluation is highly based on the amount of
Type I and Type II errors they produce. Security professionals, need to adjust the detection
engine policy and their thresholds in order to find the perfect analogy of false positives and
false negative events. Due to the difficulty of eliminating type I and type II errors, the intrusion
detection system’s value significantly relies on the skills of the security team that is monitoring
and tuning it [4].
8
2.2 Signature-based Intrusion Detection
Signature based intrusion detection, is one of the most popular detection techniques and it is
widely used in intrusion detection systems, antivirus software, web application firewalls and
many other security mechanisms that are based on intrusion signatures to detect malicious
actions.
An intrusion detection signature can be described as any pattern, based on the events
monitored by the IDS, that can signify a security breach or an attempt. A signature can be a
regular expression trying to detect SQL injection attacks, a blacklisted IP address, strings that
can reveal the exploitation of a system vulnerability, abnormal flags and options set in a
network packet etc. Signatures are created so that they will be able to detect multiple
variations of the same attack and may correlate multiple events in order to identify an
intrusive action.
Signatures are implemented in an IDS in the form of rules. These rules specify which actions
should be taken when a successful match occurs between an event monitored by the IDS and
the signature it is being compared with. They follow an “if-then” logic where in one part they
contain the action, while the second part contains the actual signature in a form that can be
interpreted by the IDS. Actions, are highly dependent on the implementation and
configuration of the IDS and may be the generation of a simple alert, the initiation of a
network packet capture and more. In cases where the IDS is acting as an IPS, these actions will
also specify whether the IPS should allow the matched event or block it.
Signatures are usually structured in a form where they specify which fields should the IDS
extract from the event analysed before performing the comparison. A single event will usually
be compared with all the intrusion signatures that refer to this particular type of event and
are stored in the IDS database until it successfully matches one. Depending on the
implementation of the IDS, an event may match more than one signature or a rule may be
triggered only if a number of sequential events will match a number of signatures.
2.3 Anomaly-based Intrusion Detection
Anomaly-based intrusion detection relies on the assumption that every abnormal behaviour
is most likely an intrusion attempt. Intruders will probably have no previous experience with
the network and the systems they are attacking and as a result, their behaviour will present
significant anomalies compared to the one of a legitimate user. In order to detect and create
a behavioural profile, an anomaly-based IDS maintains a number of different metrics that may
indicate an intrusive activity. For example, some of these metrics may be based on the login
hours of a user, the average number of files accessed in a system, the average user logins in a
system or the network traffic of a system. As a result, unlike signature based intrusion
detection, anomaly detection systems are able to detect previously unknown threats since
they do not rely on a preconfigured signature database for their detection.
9
Anomaly-based detection, as described extensively Denning’s model [17], mainly uses
statistical measurements to identify malicious activities and subjects. Statistical anomaly
detection, as usually referred, uses the above metrics to generate two behavioural profiles,
the current and stored profile. The stored profile refers to previous “normal” and legitimate
metrics of the subject monitored while the current or active profile refers to real-time metrics
and is constantly updated. The current profile is being compared with the stored profile and
depending on the divergence of those two and the threshold that has been configured by the
security engineers, the IDS will flag the behaviour as intrusive or not.
Haystack [20], was one of the first anomaly-based offline intrusion detection systems strongly
related to Denning’s model. Haystack, monitors the system’s audit trail and uses a statistical
user model that defines a typical and non-intrusive behaviour. The model is based either to a
single user’s normal behaviour, a group’s acceptable behaviour or both. The user’s model
retains the statistical metrics of a user’s behaviour while the group’s model describes the
allowed and acceptable actions of a user. Whenever a single metric monitored exceeds during
Haystack’s time range the normal metric stored, the total statistical score of the user is
computed. Depending on the score’s value, Haystack will either raise an alert or ignore it.
A real-time IDS has been later proposed by Lunt T.F. et all [21] named “IDES”. Unlike Haystack,
IDES was able to detect intrusions in real-time, by monitoring each user’s and groups activity
on multiple systems as well as a system’s overall activity, and triggered an alert for any
deviations detected. IDES, was replaced a few years later by the “Next-generation Intrusion
Detection Expert System” (NIDES) [22]. NIDES, as the successor of IDES, had significant
performance improvements and enhancements against IDES’s statistical detection engine and
also included an implementation of a “resolver”, an automated tool that was able to reduce
the amount of false positives by computing the likelihood of the attack scenario. Moreover,
NIDES similarly to Haystack, was not only relying on its anomaly detection engine as it
provided security engineers with the ability to use intrusion signatures to detect already
known attacks1.
Haystack, IDES and NIDES as well as their successors, were able to update their stored profiles
with metrics produced by each behaviour that was not exceeding the system’s allowed
thresholds. This self-training technique allowed these anomaly-based intrusion detection
systems to adapt to any network and system were implemented, resulting into more accurate
stored profiles and reduced false positive alerts.
Multiple systems and research papers on anomaly based intrusion detection, have been
proposed after the publication of the above systems [23], even so, anomaly-based detection
is barely used in production environments as the number of problems their implementation
faces, requires further research. Despite the fact that NIDES and Haystack are using statistical
measurements to detect anomalies, other systems proposed are utilize machine learning
methods such as Markov models and Bayesian networks, while others are trying to classify
activities using data mining techniques.
1 Both the signature detection engine and the resolver were initially proposed as future work of IDES [21].
10
2.4 Stateful Protocol Analysis
Stateful Protocol Analysis is a detection technique that can be easily confused with anomaly
based detection as they both focus on the detection of anomalies in order to identify
intrusions. However, stateful protocol analysis instead of using user and system profiles, uses
predefined protocol state profiles to detect protocol anomalies caused by intrusion attempts.
These protocol state profiles, are static in nature and are usually based on protocol standards
and specifications such as RFC’s. As a result, they do not alter between different users or
systems and thus they are significantly different from the ones used in anomaly based
detection.
A stateful protocol analysis IDS, keeps track of the states of each protocol used in a session
and compares it with the one described in the stored protocol profile. Protocol profiles refer
mainly to network or service based protocols (TCP, SSH, SSL, FTP) and even authentication
protocols but they can also be any stateful procedure that can be monitored by an IDS. This
technique can detect known or unknown attacks accurately, as long as they will produce
events that diverge from the normal operation of the protocol. Some examples can be, the
execution of commands in an SSH session without any previous authentication or a buffer
overflow attempt where an input larger than the protocol specification is provided. As a result,
the IDS has to constantly monitor both the requests and the responses of the systems in order
to maintain the state of the session.
It can be argued, that since a stateful protocol analysis based IDS, will detect only violations
of the defined protocols any legitimate activity should follow the protocol sequence and will
not raise an alarm. As a result, these systems are expected to have a surprisingly low false
positive ratio.
2.5 Problems of Intrusion Detection Systems
All of the above intrusion detection techniques appear promising and have proven their
effectiveness in detecting adversaries trying to infiltrate a system or a network. However, the
implementation of an IDS requires the consideration of some significant drawbacks most
intrusion detection systems have.
The main disadvantage of intrusion detection is the huge amount of false positives (Type II
errors) as a “hyper-sensitive” IPS may have an increased number of false positive alerts, thus
blocking legitimate users from accessing the protected services [19] and confusing the security
analyst. In signature based detection, the origin of false positives is the need for intrusion
signatures to match as many variations of an attack as possible or their bad generation by a
poorly analysed CTI feed. Anomaly based detection, requires a huge amount of events to be
used for the generation of a precise stored profile. It has been shown, that a user’s or attackers
behaviour is hard to be modelled or predicted [21] [23] even by the most sophisticated
techniques and any false alarm may have severe effects on the detection of an intrusion.
Stateful protocol analysis, as the most promising detection technique regarding false positives
11
still may suffer as they are highly relying on standards. A vendor may not precisely follow a
standard; a standard may be updated to a newer version or different implementations of a
standard may exist due to an unclear implementation description. All the above, may render
a stateful protocol analysis based IDS completely impractical as it will begin to mark every
action as false positive.
On the other hand, false negatives (Type I errors) or failures to detect intrusive activity should
also be considered during the evaluation of an intrusion detection system or technique.
Signatures are highly depending on the skills and technical knowledge of the security engineer
implementing them. Representing attacks and its variations using a signature-specific
language is not always an easy task even for the most skilful engineers. It requires both the
engineer to have a deep knowledge of the vulnerability being exploited as well as the
variations that it may have. Attackers usually find ways, to avoid being detected by an IDS by
exploiting its incapability to detect small changes in the attack patterns they use or by using
techniques that do not exist in its signature database [24] [25]. Anomaly based intrusion
detection systems, are also vulnerable to careful attackers that are aware of their existence.
An attacker, may train an anomaly based IDS to ignore anomalous behaviour by performing
intrusive actions that remain under the acceptable thresholds. Stateful protocol detection is
incapable to detect any attack that does not violate any of the protocols used but exploit
vulnerabilities not affecting a define protocol profile.
Scalability, should also be taken into account when choosing an intrusion detection method
as their performance is highly affected by the number of the events they need to analyse
simultaneously. A large intrusion signature database, will degrade the performance of an IDS
as it will require each packet being analysed to be compared with every signature in its
database. On the other hand, the computations used in anomaly based detection are of higher
complexity than signature based detection. Each user’s actions and system states are being
monitored and taken into consideration during the above computations. The number of
metrics the anomaly based IDS maintains as well as the number of the subjects and events
being monitored has a huge effect on its performance. Stateful protocol inspection can be
also difficult to scale, as it requires the IDS to maintain a state for each active session being
monitored. Moreover, as different technologies may use different implementations of a
protocol, the IDS requires mechanisms able to detect and maintain multiple profiles of the
same protocol.
Both signature and stateful protocol analysis based intrusion detection systems, require to be
constantly updated in order to operate in the appropriate manner. Intrusion signatures need
to be kept up to date to detect the most recent attacks as well as the protocol profiles used
in stateful protocol analysis have to reflect the versions of the protocols implemented in the
actual systems.
Blocking an attack may not always be the wisest decision. An IPS will usually detect an attack
on its early stages (reconnaissance) and block it before it escalates. In this scenario, the
defender will not acquire any further information about the attack while the attacker may
detect the existence of an IPS and try to bypass it. In addition, attackers may abuse an IPS to
perform denial of service attacks on legitimate hosts by spoofing their IP addresses or in the
12
case of an IDS they may create a huge amount of false positives in order to hide their trails
and distracting the security analysts.
Last but not least, most IDS or IPS produce alerts that contain minimal information and require
further investigations to be conducted by the analysts in order to gather further intelligence
for the adversary’s motives, skills or techniques and to distinguish if these events have been
flagged correctly as intrusive by the IDS or not. When their alerts are used to generate threat
intelligence feeds, this minimal information they produce may affect further security
mechanisms that rely on their feeds.
As intrusion detection systems are constantly being improved they become more and more
precise on their alerts. Industry is currently moving towards the development of next
generation intrusion detection/prevention systems and firewalls (NGID/PS, NGFW) that can
detect previously unknown malicious traffic, perform event correlation and application based
traffic inspection using a combination of the above techniques (Hybrid intrusion detection)
[26] [27] [28]. As these systems are benefiting from the advantages of the above techniques,
it should be examined in what respect they are also influenced by their drawbacks.
13
3. Honeypots
3.1 Introduction
As Firewalls, Intrusion Detection Systems and common prevention mechanisms are failing
against sophisticated adversaries, the security industry is struggling to find new ways to detect
and defend against previously unknown and persistent threats. Honeypots are security
mechanisms, that have proven their success and value in detecting, identifying and tracking
attackers in the past. They are systems with no production role, which are used to lure,
deceive, and detain the attackers in order to analyse their methods and to keep them away
from the production systems. Consequently, honeypots’ value depends on their ability to lure
and deceive an attacker and on the amount of information they can provide for each attack.
What makes honeypots such powerful security devices, is that by definition they are not
production systems and no one should interact with them. Thus any activity on a honeypot
can be automatically marked as malicious, making honeypots ideal for intrusion detection.
Unlike other security mechanisms, honeypots can detect previously unknown threats as their
ability to detect an intrusion is not restricted to a discrete dataset of already known attacks.
Moreover, since they are usually designed for minimal interaction with the adversaries, they
do not require many resources. Moreover, they are not affected by the size and the traffic of
the network they are placed in and they usually produce a small amount of events. Since each
event will indicate an intrusive activity, Honeypots have an extremely small false positive rate.
Honeypots have been used against attackers, long time before the term honeypot was
introduced. The first documented use of a Honeypot, was in 1988 by Stoll C. [29] where he
describes how a persistent adversary has been tracked and caught through the constant
monitoring of a compromised computer in Lawrence Berkeley Laboratory (LBL). Stoll has been
informed for a security breach in one of their systems but instead of disinfecting the computer
and blocking the attacker, they decided to closely monitor the attacker’s activity and remain
unnoticed. They used external devices to fully capture the attacker’s actions and soon they
realised that their system was used as a pivoting point to attack military organisations.
Through their monitoring, they managed to inform many organisations that have been
breached, and with the assistance of the relevant authorities as well as the use of deceiving
material planted in their systems, they managed to successfully track the attacker.
While LBL’s system was not deliberately designed to be breached, their decision not to block
the attacker has been proven valuable as almost none of the other organisations attacked by
the same adversary has detected and identified the breach without LBL’s help. LBL’s decision,
had a significant impact on the security of critical networks and systems as well as on
successfully tracing the attacker.
One of the first deliberately designed honeypots has been presented by Cheswick [30], where
a vulnerable system was developed and monitored in order to identify and observe current
threats. Cheswick’s honeypot, contained a number of emulated or vulnerable services and a
restricted environment on which the attacker was monitored. Cheswick’s system, just like
14
Stoll’s, was able to deceive, detain an attacker and provide valuable and accurate information
about the attacker’s motives, skills and location that would not be available otherwise.
Despite the fact that Cheswick’s report provides many technical details regarding the
implementation and development of his system, the first publicly available honeypot was the
“Deception Toolkit (DTK)” [31] developed in 1997. The Deception Toolkit, focused in
deceiving, confusing and stalling attackers in order to discourage them by emulating a number
of known vulnerabilities and services without providing them with any further access to the
Operating System. Since the attacker’s actions were significantly constrained by DTK’s
emulation, the information produced was limited. On the next years, a big variety of more
advanced commercial and open-source honeypot solutions has been developed that are able
to produce more information about the current threats.
As the definition of the term Honeypot is vague so it is their implementation as well. There
are no standards for developing or deploying a honeypot since they rely on the type of the
threat the organisation wants to observe. As L. Spitzner mentions in his book [32], “The type
of the attacker you want to identify, detect or capture will also dictate the type of honeypot
you build and how you deploy it.”. He categorises the attackers into two different types, the
ones with no specific target that try to infiltrate as many systems as possible using minimum
effort (“Script-Kiddies”) and the persistent and highly skilled attackers that focus on a single
system or organisation (“Blackhats”). Finally, he classifies honeypots based on the level of
interaction they provide to an attacker as “Low” “Mid” or “High” Interaction Honeypots.
3.2 Low Interaction Honeypots
A “Low Interaction Honeypot” is a honeypot designed to emulate a service or an operating
system without actually providing it. Low interaction honeypots are security applications with
a strictly defined scope. As a result, the extent on which the attacker can interact with a low
interaction honeypot is limited to what the honeypot ‘s emulation allows. Attacker’s actions
are controlled by the honeypot keeping them retained and restricting them from escaping the
emulated service reducing the risk of deploying a honeypot in a corporate network.
Low Interaction Honeypots can simulate a huge amount of services and systems and are, in
general, easy to deploy and maintain. Running as a service, they require minimal resources
and since they do not interact with the real system, multiple low interaction honeypots can
be collocated in the same host.
On the other hand, as low interaction honeypots have limited functionality, they are limited
to the information they can provide to the security analysts. Their main role is the detection
of intrusions and not the collection of further information about the attacker, their techniques
or motives. Usually the service emulated by a low interaction honeypot, will accept
connections on its listening port but will not allow any further interaction to the adversary.
Thus the information that can be collected are limited to network addresses and ports.
15
Artillery [33] is a low interaction honeypot that tries to detect probes to a production system
and confuse the attacker. Artillery, is a lightweight daemon that will spawns multiple ports on
the system it is installed, providing the attacker with the deception that the system may be
vulnerable. On each connection, the honeypot will produce an alert and trigger a firewall rule,
that will block any further connections from the same source IP address.
Honeyd [34], is one of the most popular commonly available honeypots. It is a powerful low-
interaction honeypot that based on its plugins it can operate as a medium interaction
honeypot. Honeyd, listens to specified ports for any incoming connection and on each
connection, the emulated service (plugin) assigned on the port of the incoming connection
will interact with the attacker. A major advantage of Honeyd that makes it ideal for intrusion
detection, is its ability to capture attacks targeting unused IP addresses. Despite the fact that
Honeyd is a UNIX based honeypot, it can emulate the services and IP stack of various operating
systems such as Windows and Linux. The level of interaction and information a Honeyd
instance can provide and produce, highly depends on the amount of interaction its emulated
services (plugins) can provide.
Some less advanced low interaction honeypots will monitor only single service by listening to
specific ports such as SMTP (mailoney2) or NTP (honeyntp3) and will alert on each connection
attempt without providing any further information.
3.3 Medium Interaction Honeypots
Medium Interaction Honeypots as the most common type of honeypots, provide services that
will allow some further interaction with the adversary than a simple connection
establishment. Compared to low interaction honeypots, they are harder to deploy and
maintain but capable to produce more information. The services they provide, may be
emulated or actual system services running in a restricted environment (e.g. chroot or jail),
that will interact with the adversary and try to capture as many information as possible.
However, the level of interaction and information they provide, as with low interaction
honeypots, depends on the implementation and configuration of the emulated service.
Unlike low interaction honeypots, they do not only focus on the detection of an intrusion or
attempt, but they provide a higher level of deception that will assist in the creation of a more
accurate profile of the adversary. A medium interaction honeypot, may be able to detect
previously unknown tools and attacks, and create a more accurate profile of the attacker’s
motives and skills. It can be argued that an adversary with more flexibility in a system, will
eventually reveal more details regarding his techniques, motives and identity.
Many medium interaction honeypots usually focus on services that are commonly attacked
and every interaction with these services, due to their role, can produce valuable information.
Such a service may be the emulation of an SSH server as it is one of the most widely used
2 https://github.com/awhitehatter/mailoney 3 https://github.com/fygrave/honeyntp
16
protocols. Kippo4 is one of the most popular medium interaction honeypots written in Python
that provides a highly configurable emulation of an SSH server. When an adversaries
interacting with a Kippo honeypot successfully guesses the preconfigured authentication
credentials, Kippo will provide them with an emulated remote shell and directory. The
emulated service, includes a list of commands that will cause the adversaries to believe that
they have successfully infiltrated the system in order to monitor their further actions. Since
all of the commands are emulated, they are limited and restricted to ensure that the attacker
will not escape the emulated environment or attack other systems. Moreover, some of the
commands provided by Kippo are designed to confuse, stall the attackers and force them to
reveal most of their tools and skills. Every authentication attempt, command executed or file
downloaded or accessed by the attacker, is logged by the honeypot and can be later replayed
by the security analysts.
Specter [35] is a commercial medium interaction honeypot solution that emulates a large
number of common services and operating systems. It is an advanced highly configurable
honeypot that can be collocated on a production system to detect scans, and attacks on
various services (Telnet, FTP, HTTP, SMTP and others) and collect information about the
adversary. Spectre is unique not only due to its ability to emulate almost any operating
system, but also because it can provide a high level of interaction to the adversary that
includes advanced deception techniques such as password files, emails and executables that
will leave marks on the attacker’s device. Moreover, Spectre includes a simplistic user
interface on which allows the administrator to configure almost anything on the honeypot
and view its alerts.
3.4 High Interaction Honeypots
Unlike Low or Medium Interaction Honeypots a High Interaction Honeypot is a complete
system acting as a honeypot. It may be a retired server or new system that does not emulate
any services or systems, but is an actual system providing fully operational services, on which
an attacker can fully interact. As a result, high interaction honeypots are harder to build and
maintain. Since attackers will have full control of the operating system of a high interaction
honeypot, the only way to safely restrict their actions is through perimeter devices such as
Firewalls, IDS, routers etc.
A high interaction honeypot cannot be a production machine. Just like the other low and
medium interaction honeypots, its purpose is to be attacked but in their case there no
restrictions to the attackers’ actions. This allows the attacker to fully exploit the honeypot and
provide them with a more realistic and effective deception. Consequently, High interaction
honeypots can detect previously unknown attacks, software or system flaws and can provide
more information about the attacker’s motives and methodologies and trends making them
extremely useful in the security community.
4 https://github.com/desaster/kippo
17
However, as they require strict monitoring and high skills to be deployed, they are mainly used
for research purposes. While they can detect attacks, their main focus is the analysis of the
attackers’ trends, skills and techniques and as a result they are highly involved in the
generation of CTI feeds.
3.5 Problems of Honeypots
It is undeniable that honeypots are extremely powerful and irreplaceable security devices.
However, they come with a number of disadvantages that have to be considered before
introducing them into a corporate network. Since honeypots gain their value by being
attacked, they can introduce a significant risk inside a network if not configured or monitored
correctly. This risk mainly applies to high interaction honeypots, however, bugs in a low or
medium interaction honeypot may enable an attacker to escape their contained environment.
Providing malicious users, with a system they can fully interact inside a corporate network, is
not something that many network administrators will fill comfortable with as attackers may
successfully compromise, take over a honeypot system and use it to propagate themselves
into the internal corporate network. As Cheswick concludes in his research [30], “if a hacker
obtains a login on a machine, there is a good chance he can become root sooner or later”.
Adversaries are many times more skilled than the honeypot administrators and have tools
that may enable them to escape any restrictions placed. A great example of such a scenario is
Kippo’s emulation of the wget command. While Kippo provides adversaries with this
command in order to capture malicious files that the attacker may try to download in the
compromised machine, an advanced attacker may use it to conduct a network scan or a DDOS
attack.
Honeypots, mainly due to their low false-positive rate, are very effective for detecting
intrusions. However, it should be noted that their inspection angle is limited to the services
they emulate or to their network address. An SSH honeypot like Kippo, can detect only attacks
targeting the SSH service and a high interaction honeypot emulating a DNS server, cannot
detect attacks targeting other systems. In order to detect attacks using honeypots, attackers
must get lured to attack them. This restriction, makes honeypots un-efficient in detecting
attacks targeting specific production systems already known to the attacker. Honeypots
cannot prevent targeted or persistent attacks. As discussed in this chapter, they can detect
and slow down an attacker but their limited inspection angle disables them from successfully
preventing a security breach.
Moreover, low and medium interaction honeypots have a limited by their implementation
decoy capability. Bad implementations or configurations, may allow a suspicious attacker to
detect a honeypot and never interact with it [36]. It can be then argued, that an “un-masked”
honeypot, has lost its value as it has failed to decoy the attacker. In addition, if attackers
identify that they are interacting with a honeypot instead of a real system, then they can turn
against the security analysts by using is as a decoy. A honeypot misused by an adversary, may
flood the analysts with so many false alarms that will distract them and miss other significant
attacks performed by the same adversary.
18
A research conducted by Sysman D. et all [37] analysed some of the most popular low and
medium interaction honeypots in order to find “Indicators of Deception”. An Indicator of
deception is anything that may enable the adversaries identify that they are interacting with
a honeypot. Honeypots such as Artillery or BearTrap5 that will block by default any attacker
trying to connect with the services they emulate, are easy to be identified only due to their
default action. If installed on a production system, then attackers may spoof their IP addresses
and connect to the same emulated service causing a DOS attack to the host(s) owning the
spoofed IP(s). Honeyd can also be detected through its default emulated scripts as the SSH
service is partially implemented and the FTP service does not support the delete command.
Kippo, may provide an indicators of deception to attackers as well, through its “faulty”
useradd command or through its uname command that always returns the same output
regardless of the system Kippo is running on.
High interaction honeypots as more complicated systems, have a higher risk than the other
ones; it should be noted though that the risk that may be caused through a misuse of a bad
emulated command or service in a low or medium interaction honeypot can be equally
significant. While honeypots have shown their effectiveness in intrusion detection, the above
restrictions do not allow them to replace any of the conventional security mechanisms like
Firewalls or IDS. Instead they are extremely powerful in displaying their value and the value
of other security mechanisms on every attack they capture as well as providing further
information that can be of great significance during the investigation of an attack.
5 https://github.com/chrisbdaemon/beartrap
19
4. Honeypots & Intrusion Detection Systems
4.1 Introduction
As discussed in Chapter 3, honeypots are extremely powerful in detecting intrusions. Thus,
many researchers based on honeypot’s properties and capabilities have used them as, or
along with, intrusion detection systems. Their ability to simulate different types of services or
systems as well as their ability to interact and collect information from the attacker enables
them to detect attacks focusing the application layer that may evade common network
intrusion detection systems.
Honeypots provide an intrusion detection capability that does not rely on previously known
attacks without producing any false negative or false positive alerts.
4.2 Honeypots for Intrusion Detection
Hassan Artail et al. [38] have used honeypots to detect intrusions relying on the fact that each
interaction with a honeypot can be marked as a malicious attempt. Their research focuses on
assigning virtual honeypot (Honeyd) instances on all unused network IP addresses. As the
number of the honeypots inside the network increases, the probability of an attacker to
interact with a honeypot and not with a production machine rises. The selection of the
operating system of the honeyd instances is based on the current network setup as it tries to
maintain the ratio between Windows and Linux devices. Moreover, in order to increase the
decoying capabilities of honeyd instances, they have also installed full interaction honeypots
on which they redirect suspicious traffic captured by honeyds. However, attackers that
already know the IP address of their victims, such as insider attackers, may never interact with
the above instances and will remain undetected.
A similar approach but for detecting worms inside a local network is HoneyStat [39] proposed
by Dagon D. et al. HoneyStat is a collection of full interaction honeypots with minimal
resources that monitors network, memory and disk events in order to detect and analyse a
virus behaviour. Each HoneyStat node represents an individual full interaction honeypot that
reports the above events to a central analysis server. The analysis node correlates the events
produced by the honeypots, resets the compromised honeypots and in some cases redeploys
other similar vulnerable honeypots. The use of full interaction honeypots, enable HoneyStat
to acquire more information about worms’ behaviour and allows the identification of zero-
day attacks with a very low (or zero) rate of false positives. However, since HoneyStat focuses
only on the detection of worms on their early phase, it cannot be considered as a standalone
network intrusion system capable of identifying multiple types of attacks.
Prathapani A., Santhanam L. and Agrawal D.P. in their research [40] propose a honeypot agent
to detect attacks in wireless mesh networks. They focus on detecting malicious acting mesh
routers that advertise themselves as the fastest route available and drop all the incoming
20
packets from their victim to perform a DOS attack (black hole attack). Their proposed solution
is a honeypot that already knows the answer for the route request it makes. After getting the
response from the mesh router, the honeypot checks whether it is correct or not. This process
allows the honeypot to detect whether the router is performing a black hole attack or not.
Spitzner [41] proposes the use of “Honeytokens” to detect and identify inside attackers.
Honeytokens are not systems or services. They are digital entities like files, e-mails, credentials
or database entries with no production purpose so that their use will indicate an unauthorized
activity. Spitzner supports, that Honeytokens can be extremely effective in detecting inside
attackers or attackers that already know the organization’s network structure and are try to
remain undetected by acting carefully. Thus, they can detect and prevent attacks that do not
produce any suspicious traffic and most current intrusion detection systems would ignore.
4.3 Honeypots combined with Intrusion Detection Systems
Most honeypots deployments, and mainly the ones containing high interaction honeypots
include an intrusion detection or prevention system in order to increase their monitoring
capabilities and to restrict the attacker’s actions. While in normal deployments these two
security mechanisms operate individually many researches focus on set-ups on which
honeypots cooperate with intrusion detection systems in order to improve their detection
capabilities using CTI feeds produced by the honeypot.
Signature based intrusion detection systems, as discussed in Chapter 2, require a database of
attack signatures to operate. These attack signatures are usually made after an assiduous
inspection of malicious activity that tries to identify patterns that will enable the detection of
an attack. Generating attack signatures is a hard and time-consuming task as each signature
must be capable of identifying an attack and its variations without producing any false positive
alerts. Kreibich and Crowcroft [42] have developed Honeycomb. A honeyd plugin that detects
malicious activity and automatically generates attack signatures that can be used in network
intrusion detection systems (NIDS). Honeycomb is based on the fact that each interaction with
a honeypot can be marked as suspicious and focuses on identifying patterns on packet
payloads. Honeycomb compares each connection with previous ones that have the same
destination port, and attempts to identify similarities between their messages. The above
procedure results in the generation of attack signatures that can be used at popular network
intrusion systems for identifying previously unknown threats. It should be noted though that
as discussed in Chapter 3 and also stated in similar researches [39], low interaction honeypots
are not very efficient in identifying zero-day attacks or variations of already known attacks as
the level of interaction they provide is limited.
A similar system to Honeycomb is HoneyAnalyzer [43]. HoneyAnalyzer does not focus on the
automatic signature generation as its authors question Honeycomb’s ability to generate
precise signatures. They believe that Honeycomb may generate multiple signatures for the
same attack or signatures that may have a huge false positive ratio. HoneyAnalyzer provides
a web interface and uses honeyd and network sniffing tools to collect and analyse network
packets and propose possible signatures for the attacks identified. It provides the security
21
administrator enough information for the attack in order to assist in signature generation
procedure and the signature generation algorithm is applied only to the events chosen by the
security administrator. This results in more precise signatures than the ones produced by
Honeycomb.
An intrusion detection and prevention system for VoIP attacks based on honeypots has been
proposed by Nassar M. et al. [44]. They introduce a VoIP Honeypot situated in a different
subnet than the normal VoIP infrastructure connected with a central database accessible by
both subnets. Initially, in order to detect spamming or phishing attacks targeting the VoIP
infrastructure, they publish fake user URI’s corresponding to the honeypot in such a way that
will they will be ignored by humans but not by automated scanners. On each VoIP connection
to the honeypot, the system tries to fingerprint the attacker and gather as much information
as possible and an entry is created to the central database blacklisting the attacker. Finally, in
order to detect different types of attacks such as DoS or brute-force, they present an event
correlation engine for SIP events based on the events produced by agents deployed in the
VoIP infrastructure. It can be argued that the correlation engine they propose operates as an
intrusion detection system that is independent of the honeypot infrastructure as the agents
producing the events are not necessarily installed on honeypot devices. The honeypot
infrastructure is only used to provide additional information to the correlation engine
produced by automated attacks.
4.4 Redirecting malicious traffic to honeypots
While both honeypots and intrusion detection systems are assisting a lot in the defence
against cyber threats, the time race between attackers and defenders remains as both of
these systems can be evaded or detected. Detection mechanisms are effective only when
there is an appropriate incident response plan and enough time for the defender to respond.
In most cases, organizations fail to respond in time to an intrusion as security analysts require
more time and more precise alerts to successfully identify an attack. A solution to the above,
is the redirection of suspicious traffic to a honeypot in order to delay, deceive, and prevent
the attack while providing more information to the security analyst.
Secure Direct is a system proposed by Ram Kumar Singh and Prof. T. Ramanujam [45] that
redirects malicious web traffic to a honeypot. Secure Direct is implemented by a load balancer
between the protected web server and the honeypot. The load balancer, based on the
response of an intrusion detection system, forwards malicious traffic to the honeypot while
legitimate users are forwarded the real web server. While the success of this approach is
extremely relying on the correct classification of the request by the intrusion detection
system, it can be proven very beneficial when the honeypot is fully mirroring the protected
web server. Attackers, will not be able to determine whether they are interacting with a
honeypot or not, thus increasing the time window for a security analyst to detect them.
Moreover, their attacks, will provide valuable information about their attack methods for the
security analyst enabling a more accurate classification of the attack.
22
A more complicated system focusing on decreasing the false positive ratio of intrusion
detection systems is proposed by Babak Khosravifar and Jamal Bentahar [46]. They suggest a
honeypot infrastructure that cooperates with intrusion detection agents to divert malicious
traffic to a honeyd honeypot. The redirection is performed using a switch that duplicates the
packets and sends them to the honeypot manager. Each time an IDS agent detects a suspicious
packet it reports it to the honeypot manager and suspends the connection. The manager,
based on the host that reported the attack forwards the packet to the appropriate honeyd
instance that interacts with the adversary through the IDS agent. During honeypot’s
interaction with the attacker, the manager monitors the network traffic and honeypot’s alerts,
verifies the attack and blocks the attacker. Moreover, a signature is generated and saved in
the database to avoid executing the above procedure again for the same attack. If the
honeypot analysis reports the traffic as legitimate, the manager instructs the IDS agent to
forward the packet and resume the suspended connection. This approach has a significant
impact on reducing the amount of false positives produced by both intrusion detection
systems and honeypots. However, it is unclear whether the above system is capable to detect
attacks that require a higher view of the traffic inside the network since it based on agents
installed on individual systems (worms, network scans etc.). Moreover, shifting the
connection between different hosts may break a TCP or an application connection resulting
on an infinite loop in which the adversary reinitiates a connection to the initial target and gets
shifted to honeypot in the case of a suspicious packet. Finally, as it has already been discussed,
honeyd as a low interaction honeypot, has limitations in identifying attacks that exceed its
implementation. Thus, the above system, may have a high false negative rate classifying as
legitimate, attacks that could have been identified by an intrusion detection system but not
by a honeyd instance.
Anagnostakis et al. [47] in their research, introduce the notion of “shadow honeypots” in order
to reduce the false positives produced by an anomaly-based intrusion detection system. A
shadow honeypot is a modified version of the source code of the protected service able to
analyse, detect and prevent malicious attempts against it remaining invisible to the end user
as they share the same state with the original application. An anomaly-based intrusion
detection agent is responsible for identifying suspicious packets and redirecting them to the
shadow instance of the protected service. Based on the effects a suspicious packet may have
on the shadow honeypot they classify the attempt as legitimate or not and the shadow
honeypot gets rerolled to its initial state. If the request was marked as malicious, it gets
dropped while if it gets marked as legitimate, it gets normally served. In both cases the
anomaly detection engine is updated in order to optimize its detection capabilities. The above
system, is a novel low-interaction honeypot, capable to identify pre-defined types of
previously unknown attacks for a specific application. However, the shadow honeypot’s
requirement to share a state with the protected service and to modify its source code, limits
its ability to protect multiple services or systems or proprietary software applications.
Nathalie Weiler [48], suggests a system to prevent and defend against Distributed Denial of
Service (DDoS) attacks by redirecting DDoS packets to honeypots. The author, attempts to
disrupt the chain between the attacker and the slaves executing the attack by inserting a
honeypot node among them. To do so, Weiler uses honeypots that their vulnerabilities will
lure attackers to compromise it and add it in their DDoS botnet. A honeypot inside a DDoS
23
botnet can provide the security analysts with valuable information about the attacker’s
motives and techniques and also prevent the execution of a DDoS attack. In order to increase
honeypot’s transparency, Weiler suggests the use of honeypots that mimic the organizations
network on which only DDoS related traffic will be redirected by either a transparent packet
forwarder or a next-generation router that attempts to detect DDoS signatures.
The effectiveness of redirecting malicious traffic to honeypots in order create a more
convincing deception, is highlighted by Heckman K. E. et al. through their experiment [15].
The experiment is based on a simulation of a cyber-warfare scenario in which the adversaries
have compromised a set of credentials to a military service and the defending team tries to
deny their access using two different deception techniques. The access to the protected server
is controlled by a reverse HTTP proxy that is initially used to redirect the malicious traffic to a
content filtering system named “Blackjack”. Blackjack tries to deny access to classified
information and deceive the attacker using predefined policies and rules that alter the
protected system’s responses. While promising, Blackjack failed to successfully deceive the
adversaries in Heckman’s experiment as it introduced a noticeable delay in systems responses,
and there were significant differences in their content. The adversaries have compromised
more accounts than the defending team was aware of and managed to access the protected
server evading Blackjack. Their second deception technique was the use of the HTTP proxy to
redirect the adversaries to a high interaction honeypot that is based on an original system’s
image. Combined with some social engineering techniques and convincing fake content on
the honeypot, the defending team managed to successfully deceive the attackers and deny
their access to classified information. However, their deception would have failed if the
attackers managed to utilise a different set of compromised credentials to access the system.
In order to mitigate this vulnerability, the defending team should have more accurate
methods to identify the compromised accounts and redirect them accordingly.
24
5. Proposed Solution
Similarly to the systems discussed in Chapter 4, our research focuses on the use of an IDS to
redirect malicious traffic to honeypots without being limited to specific attacks, systems or
services. The proposed system is an advanced active defence mechanism that attempts to
benefit from the advantages that both of the above mechanisms provide. The scope of this
research is not to provide an alternative to existing intrusion detection systems or honeypots
but to emphasize the benefits of their collaboration and introduce an active role to current
honeypot systems.
Our mechanism focuses on creating a deception that will delay or prevent the success of an
attack as much as possible giving enough time for the security analyst to respond. Once an
attack is detected the malicious packet will be dropped, and all future traffic originating from
the same attacker will be routed to a honeynet while traffic from legitimate users will be
served by the original production system. All traffic to the honeynet will be monitored but not
dropped, ensuring the transparency of our mechanism and increasing the time cost it
introduces to the attacker. The use of honeypots and appropriate monitoring mechanisms,
enables our system to provide detailed information about the attacker methods, motives and
tools that can be used to further tune the installed security mechanisms and will assist the
security analysts in the correct classification of the incident.
As a proof of concept we implement our system over Snort [49], a popular open-source
signature based network intrusion system, and we evaluate it in a small simulated corporate
network. A similar but more complicated system was “Bait and Switch” developed by Violating
Networks in 2003 and was based on earlier versions of Snort (1.9.0 & 1.9.1) that are no longer
supported [50]. Bait and Switch used a number of system configurations, an output module
and a software running as a daemon named “switchcore” to redirect an attacker to a
honeypot. The main functionality of Bait and Switch was implemented in switchcore which
handled the necessary firewall rules and routing tables to perform the redirection. Switchcore
was reading the malicious IP addresses through an FIFO data structure that was populated by
the Snort’s output module and through a user-defined Blacklist. For each malicious IP
detected, switchcore added a redirection rule that is removed if the attacker remains inactive
for a time interval defined by the system administrator.
While Bait and Switch’s system and network configuration could protect multiple systems and
allow the redirection of malicious packets to a honeynet, it’s redirection engine, switchcore,
is limited to a single system/honeypot and it is unclear whether it can be combined with
network-emulating honeypots such as honeyd. Moreover, as corporate networks are
becoming bigger and complicated, the advanced features of switchcore (Anti-DoS checks and
shorting algorithms) as well as its FIFO data structure, could exhaust the IDS resources and
introduce significant network delays.
Our solution, implemented over a centralized network intrusion detection system, is able to
detect an attack, targeting multiple or single systems, during its reconnaissance step (port,
network or vulnerability scans) and redirect the attacker to the honeynet. Monitoring the
whole network traffic, instead of a single instance provides better visibility enabling also the
25
detection of worms or network scans. Moreover, the proposed system, introduces minimal
overhead to a traditional Snort implementation and does not limit the number or type of the
systems protected and their honeypots that lie in the honeynet.
We assume that the intrusion detection system has been tuned properly and we evaluate our
research by reviewing the results of popular open source scanning tools such as OpenVas and
nmap. Finally, we compare the precision of their results with our system in place, against an
IPS that blocks the attacks without doing any redirection, or a network without any firewall or
IPS at all.
5.1 Network Topology
In our proof of concept, we emulate a small corporate network that consists of two networks
named DMZ network and Management network respectively (Figure 1). The DMZ network
contains systems that are publicly accessible over the internet through its main gateway. The
management network is not publicly accessible and is used by the network administrator to
access the main gateway through its management interface.
DMZ Network: 10.10.1.0/24
Management Network: 10.10.10.0/24
Main Gateway
switch
Internet
Webserver10.10.1.4
switch
Figure 1: Original Network
On the above network we introduce a centralised network intrusion detection system and a
honeynet that is mirroring the protected network (Figure 2). The NIDS, replaces the original
main gateway as it requires full control of the network traffic targeting the DMZ network. A
firewall/router is placed between the main gateway and the honeynet to control the routing
of the network packets to the honeynet and provide a better control of the network traffic
26
originating from the honeypots. The logs from the honeynet and its firewall are collected and
analysed by a centralized log server lying in the management network.
DMZ Network: 10.10.1.0/24
HoneyNet: 10.10.1.0/24
Management Network: 10.10.10.0/24IDS
switch
firewall
Internet
172.16.1.0/30
switch
Webserver10.10.1.4
Webserver (Honeypot)10.10.1.4
Honeypot 2
switch
Log Server
Figure 2: Proposed network
In the above network, the IDS acting as the main network gateway is capable to monitor and
swift the any malicious network traffic from its DMZ interface to its honeynet interface. The
network isolation enables the network administrator and the security analysts to safely access
the management interface of the IDS and the firewall and view all the alerts created by both
the IDS and the honeypots. Finally, the firewall prohibits any malicious traffic originating from
the compromised honeypots targeting the production or the management network. Further
rules can be applied on the honeynet’s firewall and other security mechanisms such us a
conventional intrusion prevention system can be installed to restrict honeypot’s access to the
Internet.
27
5.2 Detailed System Overview
The network described in Figure 2 is emulated in a virtual environment using the virtualisation
platform VMware Workstation 11.1.46. The network separation is achieved using the
VMware’s Virtual Network Editor where we configure the following five virtual networks that
can be seen in more detail in Figure 3:
1. VMnet8 represents the external public network, the Internet. It is managed by the
Host machine and each device connected to it receives an IP address in the network
192.168.10.0/24 and has unrestricted access to the Internet.
2. VMnet1 is used as our management network. VMnet1 is also managed by the Host
machine, however, the devices lie in a different virtual network (10.10.10.0/24) and
do not have access to VMnet8 or the internet.
3. VMnet3 is our honeynet. As already discussed, our honeynet is mirroring the DMZ
network (10.10.1.0/24) and is managed through its firewall/router.
4. VMnet4 represents the corporate DMZ network (10.10.10.0/24). VMnet4 is publicly
accessible from VMnet8 and is managed and protected by its main gateway the IDS.
5. VMnet5 is a network shared only between the IDS and the honeynet router/firewall.
It is used to allow the IDS to distinguish and route the traffic through the honeynet
and DMZ interfaces.
DMZ Network: 10.10.1.0/24
HoneyNet: 10.10.1.0/24
Management Network: 10.10.10.0/24
IDS
Switch 10.10.1.0/24
pfSense
Internet
172.16.1.0/30
Switch 10.10.1.0/24
Webserver10.10.1.4
webserver 10.10.1.4
VMnet4
VMnet8
VMnet5
VMnet3
VMnet1
srv0310.10.1.7
srv0210.10.1.6
srv0110.10.1.5
Switch 10.10.10.0/24
mhnsrv10.10.10.9
Figure 3: Emulated Network Diagram
6 https://www.vmware.com/
28
5.2.1 The Main Gateway (IPS)
Our main gateway, the IPS, is an Ubuntu Server 14.04.4 LTS installation with dual functionality
as it is acting both as a router and as a network intrusion detection system. It has four network
interfaces mng0, eth0, eth1 and wan0 that are connected to the VMnet1, VMnet4, VMnet5
and VMnet8 networks respectively. Its router functionality is configured and managed using
the open-source software Webmin7. Webmin provides a web-based management interface in
which the system administrator can configure the network interfaces, the DHCP and DNS
server, the firewall rules and many other services and parameters required for a network
router.
The IDS, as the most crucial component of our network, is implemented using Snort 2.9.8.2
and is inspecting all the traffic to and from the DMZ network (VMnet4). Snort is a popular and
highly configurable open-source intrusion detection system developed by Sourcefire that in
our network is running in IPS mode (inline). It consists of two main modules, the main intrusion
detection engine (snort) and the Data Acquisition Library (DAQ) that is responsible for
retrieving and forwarding the network packets to snort. Snort’s behaviour can be modified
and extended using detection or pre-processor plugins and output or dynamic modules. The
detection or pre-processor plugins as well as the dynamic modules are allow snort to perform
specific checks and operations on the inspected packets and use dynamic rules while snort’s
output modules control the format of snort’s alerts. DAQ’s configuration allows the use of a
number of different modules that control the way it performs packet acquisition.
In order to reduce the number of false positive alarms and the overhead of our IDS, we are
using DAQ’s NFQUEUE module to monitor only the interface connected to the DMZ network.
NFQUEUE uses a queue to push the network packets from the network layer to snort that will
inspect each packet and decide whether it should be forwarded or dropped. In order to specify
which packets should be inspected by snort, iptables8, the host’s firewall is configured to push
only the packets that are related to the DMZ interface in the NFQUEUE. Further firewall rules
have been also configured in order to control the access to the other networks controlled by
the IDS.
Snort’s alerts are being logged to a MySQL database using Barnyard29 and are accessible
through BASE10, a web based interface that allows the analysts to search and analyse the alerts
produced by snort. Snort uses its unified2 output module to write its alerts to a log file that is
later processed by Barnyard2. Barnyard2 inserts the above alerts to the database that is used
by BASE. As a signature based IDS, snort maintains a database with its signature based rules.
In order to keep our IDS up to date with emerging threats, we use an automated tool,
PulledPork11, that periodically checks and updates snort’s rules.
In order to enable snort to redirect an adversary to the honeynet we had to modify its source
code. Our aim was to introduce as minimal overhead as possible to the original
implementation and to redirect each adversary instantly when a detection rule is triggered.
One of the most popular techniques to extend snort’s capabilities based on its alerts, used
7 http://www.webmin.com/ 8 http://ipset.netfilter.org/iptables.man.html 9 https://github.com/firnsy/barnyard2 10 http://base.professionallyevil.com/ & https://sourceforge.net/projects/secureideas/ 11 https://github.com/shirkdog/pulledpork
29
also by Bait and Switch, are its output modules. However, as reported also in snort’s mailing
list [51], an output module may introduce undesirable delays. Driven by our aim to create a
lightweight active defence mechanism, we decided to perform our modifications directly on
snort’s main detection engine.
The redirection of the adversaries is performed based on their IP address, and in our system
is achieved through Policy Routing [52]. In addition to the default policy routing tables of a
traditional Linux implementation, our system maintains one more policy routing table named
“blocked” that contains a single line which specifies the honeynet firewall as the default
gateway and for every network destination.
default via 172.16.1.2 dev eth1
By default, the routing table “blocked” is never used for routing until a malicious packet gets
detected by the IDS. Our modifications, are made on “detect.c” snort’s source file and
alter the behaviour of its DROP and SDROP actions. The modified actions will drop any
malicious packet and add a routing rule that instructs the router to use the “blocked” routing
table for any future traffic originating from the same source IP address. These rules can be
later viewed and modified or removed by the system administrator and the security analysts.
5.2.2 The Honeynet
Our approach does not restrict the size of the honeynet or the type of the honeypots that will
be used, however it requires the honeynet to have the same address space as the network
being protected. As already discussed, high interaction honeypots are very effective in
deceiving a sophisticated attacker, thus they are highly recommended our security
mechanism. However, for the purpose of this project and due to the abstract nature of high
interaction honeypots, we decided to analyse in depth and experiment with a number of
popular open-source medium and low interaction honeypots for our honeynet.
The honeypots that should be used in similar implementations, should be as close to the
original systems that will be protected by the mechanism. If desirable, the honeynet can also
contain more systems than the actual network does. In that case, it is recommended to add
the respective rules to the main IDS that will drop every traffic targeting the IP addresses not
included/used in the original network. This approach has been widely seen in previous
chapters, as each connection attempt to an unused (unpublished) IP should be considered
suspicious and redirected to the honeynet.
Every network connection to and from the honeynet is controlled by its router & firewall that
is based on the open-source software pfSense 2.3.112. It has three network interfaces that are
connected to VMnet5 (wan interface), VMnet3 (Lan interface) and VMnet1 (management
interface). Our honeynet firewall restricts every direct connection to its wan interface, and
any connection from the honeynet address space targeting the management network, the
firewall’s Lan IP address or VMnet5. Moreover, honeynet’s firewall as well as the main
gateway of our network, can be configured to restrict honeynet’s internet access in order to
ensure that the compromised honeypots cannot be used to attack external systems. In
12 https://www.pfsense.org/
30
addition, pfSense supports extension packages and a Snort package can be installed to further
monitor and retain honeynet’s network activity.
The honeynet is composed of four different hosts that can be seen in Figure 3. Each host, is
an Ubuntu server 14.04.4 LTS and has a number of honeypots running that are managed and
deployed using Threatstream’s Modern Honey Network (MHN)13. MHN’s architecture
requires a centralized machine acting as the MHN server that in our implementation is located
in the management network (mhnsrv). The MHN server, provides deployment scripts that
facilitate the deployment and configuration of many popular honeypot solutions. Each
deployed honeypot reports its alerts to the MHN server using Honeynet Project’s data feed
protocol hpfeeds14. MHN stores the above alerts to a database and provides statistical
information to the security analysts through its web interface. In addition, to achieve a more
detailed view of honeynet’s activity, we have installed a free version of Splunk15 (Splunk Hunk)
in our MHN server that uses MHN’s application for Splunk16 that provides statistical
information and detailed logs of honeynet’s activity. Moreover, logs generated by honeynets
router & firewall are also collected by Splunk in order to have a centralized log management
system for our honeynet.
The aim of the developed honeynet is not only to deceive the attacker but also to collect as
much information as possible about his tools, systems, motives and actions. Thus, in every
honeypot in our honeynet, we have installed a local instance of snort running in IDS mode to
monitor its network traffic and alert for any already known attacks. In addition, we have also
installed p0f17, a powerful passive fingerprinting tool, in every honeypot to collect as many
information as possible about the adversary’s system, without producing any traffic that will
allow an attacker to identify our honeypot.
On our first honeypot, webserver, we try to create a deception of the original webserver that
is located in the DMZ network. Since the original webserver is running a Wordpress website
we decided to use “Wordpot”18, a honeypot emulating a Wordpress installation. In addition,
as the original webserver is an Ubuntu Server that allows SSH connections, we have also
installed the medium interaction SSH honeypot Kippo that we have discussed in Chapter 3 to
monitor any SSH attempts done by the adversary.
Srv01, is also a Linux machine that tries to detect different types of attacks focusing popular
systems and services. On srv01, we have installed three different honeypots “Shockpot”19,
Elastichoney20 and Crowrie21. Shockpot is a web based honeypot that focuses on detecting
attacks that target the commonly exploited bash vulnerability “Shellshock” (CVE-2014-6271)
while Elastichoney, is detecting attacks that target an Elasticsearch installation. Crowrie is an
SSH honeypot based on Kippo that supports some extended features against its predecessor
such as SFTP, SSH tunnelling, the execution of exec commands and more.
13 https://threatstream.github.io/mhn/ 14 https://github.com/rep/hpfeeds 15 https://www.splunk.com/ 16 https://github.com/threatstream/mhn-splunk 17 http://lcamtuf.coredump.cx/p0f3/ 18 http://brindi.si/g/projects/wordpot.html 19 https://github.com/threatstream/shockpot 20 https://github.com/jordan-wright/elastichoney 21 https://github.com/micheloosterhof/cowrie
31
On srv02 we have installed on of the most popular low interaction honeypots “Dionaea”.
Dionaea, is a unique honeypot as unlike most low interaction honeypots it aims to capture
previously unknown attacks and payloads by emulating a number of commonly attacked
services (FTP, HTTP, SMB, MySQL and more) regardless of the operating system it is running
on. Dionaea is highly configurable and able to listen to more than a single IP address. It is also
capable to integrate with various tools such as p0f, fail2ban etc., perform connections to
malicious systems to collect malware and interact with external services such as virustotal’s
web API.
Finally, our last honeypot srv03, is emulating an industrial control system (ICS) using Conpot22
and Kippo. Conpot is a low interactive honeypot that emulates a number of services
commonly seen in industrial control systems (Modbus, HTTP, SNMP). Each service emulated
by Conpot can be configured both on its response content and as well as on its response time
to increase its deceptive capabilities and delay the attacker. Its HTTP service provides a
webpage that if customized is able to display a very realistic ICS administration webpage.
Kippo, is once again used due to the amount and the significance of the information that can
be acquired through an established SSH session.
All the above honeypots have been deployed and are monitored using the MHN server located
in the management network. In order for the honeypots to be able to communicate with the
MHN server so that they can acquire their deployment scrips and send their alerts using the
hpfeeds protocol; the necessary rules have been configured on the honeynet’s firewall.
22 http://conpot.org/
32
6. Evaluation
In order to evaluate our system, we compare it with a default Snort installation (Figure 4) that
operates as an Intrusion Prevention System. Both systems use the same signature database,
and only differentiate to each other on the way they handle their high severity rules (“DROP”
& “SDROP”). As described on the previous chapters our system will add a permanent
redirection rule each time one of these rules gets triggered and drop the packet while the
conventional IPS will only drop the malicious packet. For the purpose of the evaluation of our
mechanism, in addition to the network presented in the previous chapter (Figure 3), our
evaluation DMZ network (Figures 4 &5) includes one more system running a number of
outdated vulnerable services, metasploitable23.
DMZ Network: 10.10.1.0/24
Management Network: 10.10.10.0/24
IDS
Switch 10.10.1.0/24
Internet
Webserver10.10.1.4
VMnet4
VMnet8
VMnet1
Switch 10.10.10.0/24
Metasploitable10.10.1.5
Figure 4: Evaluation Network (Conventional IPS)
We use three of the most popular reconnaissance and vulnerability assessment tools to
initially scan our network:
nmap24, a network and port scanner
Nikto225, a powerful web-application vulnerability scanner
and OpenVas26, an open-source vulnerability scanner.
After the initial scans we try to gain access to the systems in the DMZ network by attempting
to exploit any vulnerability found. For the exploitation step, we use Armitage27, a graphical
user interface (GUI) for the metasploit framework.
23 https://sourceforge.net/projects/metasploitable/ 24 https://nmap.org/ 25 https://cirt.net/Nikto2 26 http://www.openvas.org/ 27 http://www.fastandeasyhacking.com/
33
DMZ Network: 10.10.1.0/24
HoneyNet: 10.10.1.0/24
Management Network: 10.10.10.0/24
IDS
Switch 10.10.1.0/24
pfSense
Internet
172.16.1.0/30
Switch 10.10.1.0/24
Webserver10.10.1.4
webserver 10.10.1.4
VMnet4
VMnet8
VMnet5
VMnet3
VMnet1
srv0310.10.1.7
srv0210.10.1.6
srv0110.10.1.5
Switch 10.10.10.0/24
mhnsrv10.10.10.9
Honeypots
webserver: Wordpot, kippo, snort, p0fsrv01: Shockpot, elastichoney, cowrie, snort, p0fsrv02: Dionaea, snort, p0fsrv03: Conpot, kippo, snort, p0f
Metasploitable10.10.1.5
Figure 5: Evaluation network (Proposed Solution)
6.1 Internal Scan
We initially perform an internal scan of the protected machines for reference, from a system
lying in the DMZ network (VMnet4). A default nmap scan of the Webserver and
Metasploitable lasted approximately 30 seconds each and revealed two open ports on
Webserver and 23 open ports on Metasploitable that are displayed on Table 1 and Figure 6. A
scan using Nikto on the Webserver lasted 27 seconds and reported 16 findings while on the
Metasploitable it lasted 34 seconds reporting 29 findings. Finally, the OpenVas scanner using
the “Fast and Full” scan profile, reported 3 Vulnerabilities on our Webserver, of which only
one has been classified as Medium (regarding its Severity) while the rest have been classified
as Low. On our Metasploitable server, OpenVas reported in total 60 vulnerabilities of which
18 were marked as “High”, 37 as “Medium” and 5 as “Low”.
34
Table 1: Nmap Internal Scan
Port Service System
22/tcp SSH 10.10.1.4
80/tcp HTTP 10.10.1.4
21/tcp FTP 10.10.1.5
22/tcp SSH 10.10.1.5
23/tcp telnet 10.10.1.5
25/tcp smtp 10.10.1.5
53/tcp DNS 10.10.1.5
80/tcp HTTP 10.10.1.5
111/tcp rpcbind 10.10.1.5
139/tcp netbios-ssn 10.10.1.5
445/tcp microsoft-ds 10.10.1.5
512/tcp exec 10.10.1.5
513/tcp login 10.10.1.5
514/tcp rshell 10.10.1.5
1099/tcp rmiregistry 10.10.1.5
1524/tcp ingreslock 10.10.1.5
2049/tcp Nfs 10.10.1.5
2121/tcp ccproxy-ftp 10.10.1.5
3306/tcp mysql 10.10.1.5
5432/tcp postgresql 10.10.1.5
5900/tcp Vnc 10.10.1.5
6000/tcp X11 10.10.1.5
6667/tcp Irc 10.10.1.5
8009/tcp ajp13 10.10.1.5
8180/tcp unknown 10.10.1.5
Figure 6: Findings Reported (Internal Scan)
2
16
1
23
29
55
0
10
20
30
40
50
60
nmap Nikto OpenVas (Medium & High only)
Webserver Metasploitable
35
6.2 Conventional IPS
The same nmap scan used for the internal scan but with our systems protected by a
conventional intrusion prevention system, revealed only one port on the Webserver and 19
ports on the Metasploitable machine (Table 2 & Figure 7). The IPS, generated in total 14 alerts
and managed to block some of the probes targeting popular services such as SSH, mysql, vnc
etc. but allowed probes to any other port. Snort has been surprisingly effective against Nikto
as it blocked every probe for the protected websites and as a result, Nikto returned 0 findings
and generated 43 alerts on the IPS (Figure 7). Findings from OpenVas have been significantly
reduced as well (Figure 7). On the Webserver, OpenVAS reported only 1 finding with Low
Severity while on Metasploitable it reported only 17 vulnerabilities of which only 4 where
classified with High and 11 with Medium Severity. During its scan, OpenVas generated a big
number of alerts (14315) that resulted in a significant decrease in BASE’s performance.
Table 2: Nmap scan (Conventional IPS)
Port Service System
80/tcp HTTP 10.10.1.4
21/tcp FTP 10.10.1.5
23/tcp telnet 10.10.1.5
25/tcp smtp 10.10.1.5
53/tcp DNS 10.10.1.5
80/tcp HTTP 10.10.1.5
111/tcp rpcbind 10.10.1.5
139/tcp netbios-ssn 10.10.1.5
445/tcp microsoft-ds 10.10.1.5
512/tcp exec 10.10.1.5
513/tcp login 10.10.1.5
1099/tcp rmiregistry 10.10.1.5
1524/tcp ingreslock 10.10.1.5
2049/tcp Nfs 10.10.1.5
2121/tcp ccproxy-ftp 10.10.1.5
6000/tcp X11 10.10.1.5
6667/tcp Irc 10.10.1.5
8009/tcp ajp13 10.10.1.5
8180/tcp unknown 10.10.1.5
36
Figure 7: Findings Reported (Conventional IPS)
6.3 Proposed System
With our system in place, scan results appear more complicated than the previous ones. The
network scan using nmap, returned more hosts than just the Webserver and Metasploitable
as the adversary was redirected to the honeynet where we have deployed two additional
honeypots (Table 3 & Figure 8). Nmap returned two open ports on the Webserver honeypot,
three open ports on srv01 that has the same IP address with Metasploitable, eight open ports
on srv02 and two open ports on srv03. As the adversary is being redirected to the honeynet
soon after the scan starts, there are only 4 alerts generated by the IPS.
Nikto had a similar behaviour with the one observed on the scan performed using a traditional
IPS as it gets immediately blocked by the IPS and halts. However, a second run will be executed
normally as it will be completely redirected on the honeynet. During the first run, the IPS
generated only 21 alerts and 0 on its second run, as the honeypot interface is not being
monitored. Nikto, on its second run reported 9 findings on the Webserver and srv01, and 6
findings on srv03 (Figure 8).
Last but not least, OpenVas showed even more interesting results (Figure 8) as it was
immediately redirected to the honeynet by the IPS, generating just a single alert. Its findings,
consisted of two high, seven medium and one low severity vulnerabilities in Webserver, 11
high, two medium and two low vulnerabilities in srv01, one high and one low vulnerability in
srv02, and one high, one medium and one low vulnerability in srv03.
10
1
19
0
15
0
2
4
6
8
10
12
14
16
18
20
nmap Nikto OpenVas (Medium & High only)
Webserver Metasploitable
37
Table 3: Nmap Scan Proposed System
Port Service System
22/tcp SSH 10.10.1.4
80/tcp HTTP 10.10.1.4
22/tcp SSH 10.10.1.5
80/tcp HTTP 10.10.1.5
9200/tcp wap-wsp 10.10.1.5
21/tcp FTP 10.10.1.6
42/tcp nameserver 10.10.1.6
135/tcp msrpc 10.10.1.6
445/tcp microsoft-ds 10.10.1.6
1433/tcp ms-sql-s 10.10.1.6
3306/tcp mysql 10.10.1.6
5060/tcp sip 10.10.1.6
5061/tcp sip-tls 10.10.1.6
22/tcp SSH 10.10.1.7
80/tcp HTTP 10.10.1.7
Figure 8: Findings Reported (Proposed System)
The above scans produced in total 39.504 alerts on the MHN server. All the logs collected by
our centralised log server (Splunk) contained significant information to identify some of the
tools used, the attacks attempted and the most commonly attacked systems and services
(Figure 9). P0f identified that nmap was used to perform a port scan, Kippo and Crowrie
provided some of the top usernames and passwords used during the scans (Figure 10) and
2
9 9
3
9
13
8
0
1
2
6
2
0
2
4
6
8
10
12
14
nmap Nikto OpenVas (Medium & High only)
Webserver srv01 srv02 srv03
38
snort reported some of the exploits used by OpenVas and Armitage. Elastichoney provided
also information28 that can link to the tool used for its scan, Nikto (Figure 11).
Figure 9: Top Honeypots and Ports attacked
Figure 10: Top Usernames and Passwords used in Kippo & Crowrie Honeypots
Figure 11: Elastichoney Top Attackers & Payloads
As there has not been a successfully established session with our Kippo & Crowrie honeypots,
even though some of the username-password pairs guessed by OpenVAS were successful, the
information they provided was limited as they were unable to provide any further information
regarding the attacker’s motives.
28 The domain cirt.net seen at the Top Attackers reported by Elastichoney, indicates that Nikto has been used to scan the honeypot.
39
6.4 Exploitation
For the exploitation step, we used Armitage’s automatic exploitation option “Hail Mary”
where every possible exploit for the services identified on each host is used. Using the same
technique, we scanned both our network protected by a conventional IPS and by our
proposed system.
On the first case, Armitage detected both of the systems placed in the DMZ network
(Webserver & Metasploitable) and despite the fact that the IPS blocked a big number of its
probes, it managed to return four remote access shells using three different exploits on our
vulnerable system, Metasploitable. During Armitage’s scans, the IPS produced 346 alerts as it
detected both some of the discovery and the exploitation probes.
Using our proposed solution, Armitage failed to obtain access to any of the four systems
located in the honeynet. As our honeynet consists of low and medium interaction honeypots,
the emulated services where not vulnerable to Armitage’s exploits. The IPS, produced only
three alerts and detected Armitage’s scans early during its reconnaissance steps. As a result,
our IPS performed the redirection before the attack moves to its exploitation phase ensuring
that any malicious packet will be forwarded to the honeynet.
6.5 Network Performance
Finally, we evaluate the network performance of our mechanism using the open source
network bandwidth measuring tool iperf329. We simulate a file upload from a client located in
VMnet8 (the Internet) to our webserver located in the DMZ network and we perform the
following four tests:
1. Using a conventional IPS.
2. Using the proposed mechanism and a legitimate client.
3. Using the proposed mechanism and a malicious client.
4. Using the proposed mechanism and a malicious client attempting to perform
a file upload after an intrusion attempt has been detected.
Each test is performed over a five-minute period in which we measure the network bandwidth
every five seconds (Figure 12). Both the proposed mechanism (M2) and the conventional IPS
(M1) had an average bandwidth of 245 Mbits/sec for legitimate traffic. After the first 55
seconds of our third test (M3), we manually triggered an alert in order to observe how the
connection will be affected when the adversary is switched to the honeynet. As expected, the
connection lost its state and was dropped until the end of the test. Finally, we run our fourth
test (M4) in which we simulate a second attempt from the attacker to upload a file to the
webserver. Since the attacker has already been redirected to the honeynet, the new
connection is now made to the honeypot. Despite the fact that the attacker’s traffic in now
passing through one more network hop (the honeynet’s firewall) there is a noticeable increase
in the network bandwidth as it is no longer inspected by the IPS. It should be noted though
29 https://iperf.fr/
40
that honeynet’s performance may also be affected if a separate IPS is installed to control
honeynet’s traffic to the external network VMnet8.
Figure 12: Network Performance
0
100
200
300
400
500
600
700
8005
15
25
35
45
55
65
75
85
95
10
5
11
5
12
5
13
5
14
5
15
5
16
5
17
5
18
5
19
5
20
5
21
5
22
5
23
5
24
5
25
5
26
5
27
5
28
5
29
5
Mb
its/
sec
time in seconds
M1 (Avg: 245 Mbits/sec) M2 (Avg: 245 Mbits/sec)
M3 (Avg: 48 Mbits/sec) M4 (Avg: 665Mbits/sec)
41
7. Conclusion
On chapters 1 and 2, we have discussed thoroughly how common network security
mechanisms fail to successfully prevent sophisticated attacks. However, in Chapter 6, we
experienced a fail of one of the most popular intrusion detection & prevention systems against
a noisy and not so skilful adversary. While the IPS managed to identify and block some of the
adversary’s intrusive actions, it failed to protect the vulnerable system located in the DMZ
network. It can be argued, that a better intrusion signature database or configuration of the
IPS could have prevented the adversary’s access to the vulnerable machine, however, this
solution is limited by the security analyst’s knowledge and skills and would fail again against
previously unknown attacks.
Moreover, blocking a malicious packet or an adversary, as seen in the case of Nikto’s scans,
will alert the adversaries that a security mechanism is blocking their probes. As discussed both
in Chapter’s 2 & 3, this information can be exploited by the attackers to perform a denial of
service attack by spoofing their IP addresses or to confuse the security analysts and hide their
intrusive actions by producing a big number of false positives alerts. In addition, adversaries
may alter their attacks to evade the IPS and successfully exploit the protected systems.
Most of the security mechanisms, especially the ones relying on intrusion detection
signatures, will prevent an attack on its exploitation phase. As a result, the security mechanism
will fail on every previously unknown attack. On the other hand, the system proposed in this
dissertation has shown its effectiveness to previously unknown attacks even if it was relying
on the same intrusion detection signatures with a conventional security mechanism.
Our mechanism, relies and acts on the detection of the intrusion on its early phase preventing
any further escalation of the attack on the production systems. Unlike blocking mechanisms,
the proposed system, does not reveal itself to the adversaries by using honeypots to
successfully deceive them. Furthermore, compared the conventional IPS used for evaluation
our system, our prevention mechanism produced a significantly low amount of alerts that did
not reduced our systems performance and could be easily managed in time by the security
analysts. On the other hand, the honeypots used, produced a big number of alerts that
contained more information about the attacker’s tools and techniques compared to the ones
produced by the normal installation of snort.
Unfortunately, our mechanism relies on the correct classification of the attack by an intrusion
detection system, and as a result, it remains vulnerable to bad configurations that can result
in huge amount of false positive events. A false positive alert on our mechanism will result in
denying legitimate users access to the original systems and redirecting them honeynet.
However, in that case it will still, provide the security administrator with enough information
to fine-tune the intrusion detection system.
42
7.1 Future Work
While during our evaluation the proposed security mechanism has successfully defended the
network protected, it is yet unclear how it will respond if installed in a real environment and
further research should be made before installing such mechanisms in a production
environment.
The number of false positive alerts that may be produced by the IDS may introduce significant
problems to its implementation, as legitimate and possibly confidential data may be stored in
the honeynet. The proposed system, highly relies on the security analysts to resolve any issues
created from false positive alerts. Some future work could include, an automated mechanism
that will monitor both the IDS and the honeynet and will unblock any blocked IP address that
have not displayed any further intrusive activity on the honeynet in a predefined amount of
time.
For the purpose of this project, we present our mechanism in a honeynet consisting of
medium and low interaction honeypots. As a result, the deception that could be created is
highly limited by the currently available honeypot solutions and their implementations. It
would be interesting to evaluate our mechanism by performing a similar with the one
described on Heckman’s [53] experiment using a high interaction honeynet against skilled
adversaries.
Finally, as our system does not forbid its collaboration with other systems it would also be
interesting its integration with other security mechanisms discussed in the previous chapters
such as Honeycomb or HoneyAnalyzer or its implementation over an anomaly based IDS.
v
References
[1] PWC, “INFORMATION SECURITY BREACHES SURVEY 2015. Technical report,” 2015.
[2] Detica, “The Cost of Cyber Crime: A Detica Report in Partnership with the Office of Cyber
Security and Information Assurance in the Cabinet Office,” 2011. [Online]. Available:
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/60943/the-
cost-of-cyber-crime-full-report.pdf.
[3] A. Garg, J. Curtis and H. Halper, “Quantifying the financial impact of IT security breaches,”
Information Management & Computer Security, vol. 11, no. 2, pp. 74-83, 2003.
[4] S. Barish, “Enterprise Intrusion Analysis, Part One,” 31 March 2009. [Online]. Available:
http://www.symantec.com/connect/articles/enterprise-intrusion-analysis-part-one.
[Accessed 7 February 2016].
[5] EY, “Cyber threat intelligence - how to get ahead of cybercrime,” 11 2014. [Online]. Available:
http://www.ey.com/Publication/vwLUAssets/EY-cyber-threat-intelligence-how-to-get-ahead-
of-cybercrime/$FILE/EY-cyber-threat-intelligence-how-to-get-ahead-of-cybercrime.pdf.
[Accessed 14 07 2016].
[6] SANS Institute, “Who's Using Cyberthreat Intelligence and How?,” 02 2015. [Online].
Available: https://www.sans.org/reading-room/whitepapers/analyst/cyberthreat-
intelligence-how-35767. [Accessed 14 07 2016].
[7] iSIGHTPARTNERS, “What is Cyber Threat Intelligence and why do I need it?,” 2014. [Online].
Available: https://www.isightpartners.com/wp-
content/uploads/2014/07/iSIGHT_Partners_What_Is_20-20_Clarity_Brief1.pdf. [Accessed 14
07 2016].
[8] Defense Advanced Research Projects Agency (DARPA), “Active Cyber Defense (ACD),”
[Online]. Available: http://www.darpa.mil/program/active-cyber-defense. [Accessed 17 07
2016].
[9] J. P. Farwell and R. Rohozinski, “The New Reality of Cyber War,” Survival, vol. 54, no. 4, pp.
107-120, 2012.
[10] BCS, “Active defence,” 1 2013. [Online]. Available:
http://www.bcs.org/content/conWebDoc/49685. [Accessed 17 7 2016].
[11] O. A. Hathaway, “The Drawbacks and Dangers of Active Defense,” in Cyber Conflict (CyCon
2014), 2014 6th International Conference On, Tallinn, 2014.
[12] EY, “Enhancing your security operations with Active Defense,” 2015. [Online]. Available:
http://www.ey.com/GL/en/Services/Advisory/EY-cybersecurity-enhancing-your-security-
operations-with-active-defense. [Accessed 17 07 2016].
vi
[13] R. S. Dewar, “The “triptych of cyber security”: A classification of active cyber defence,” in
Cyber Conflict (CyCon 2014), 2014 6th International Conference On. IEEE, Tallinn, 2014.
[14] SANS Institute, “Implementing Active Defense Systems on Private Networks,” 2013. [Online].
Available: https://www.sans.org/reading-room/whitepapers/detection/implementing-active-
defense-systems-private-networks-34312. [Accessed 17 07 2016].
[15] K. E. Heckman, M. J. Walsh, F. J. Stech, T. A. O’Boyle, S. R. DiCato and A. F. Herber, “Active
cyber defense with denial and deception: A cyber-wargame experiment,” Computers &
Security, vol. 37, pp. 72-77, September 2013.
[16] J. P. Anderson, “Computer security threat monitoring and surveillance. Technical report,”
James P. Anderson Company, Pennsylvania, April 1980.
[17] D. E. Denning, “An intrusion-detection model,” IEEE Transactions on Software Engineering,
Vols. SE-13, no. 2, pp. 222-232, 1987.
[18] K. Scarfone and P. Mell, “Guide to intrusion detection and prevention systems (IDPS). NIST
Special Publication 800-94,” February 2007.
[19] G. C. Tjhai, M. Papadaki, S. M. Furnell and N. L. Clarke, “Investigating the problem of IDS false
alarms: An experimental study using Snort.,” the Proceedings of The Ifip Tc 11 23rd
International Information Security Conference, vol. 278, pp. 253-267, 2008.
[20] S. E. Smaha, “Haystack: an intrusion detection system,” in Aerospace Computer Security
Applications Conference, 1988., Fourth (pp. 37-44). IEEE, Orlando, FL, 1988.
[21] T. F. Lunt, A. Tamaru, F. Gilham, R. Jagannathan, C. Jalali and P. G. Neumann, “A REAL-TIME
INTRUSION-DETECTION EXPERT SYSTEM (IDES),” Computer Science Laboratory, SRI
International, February 1992.
[22] D. Anderson, T. Frivold and A. Valdes, “Next-generation Intrusion Detection Expert System
(NIDES) A Summary,” Computer Science Laboratory, SRI International, May 1995.
[23] A. Patcha and J.-M. Park , “An overview of anomaly detection techniques: Existing solutions
and latest technological trends,” Computer Networks, vol. 51, no. 12, p. 3448–3470, August,
2007.
[24] G. F. Lyon , “Firewall/IDS Evasion and Spoofing,” in Nmap Network Scanning: The Official
Nmap Project Guide to Network Discovery and Security Scanning, Sunnyvale, CA:
Insecure.Com LLC, 2008, pp. 399-403.
[25] T.-H. Cheng, Y. D. Lin, Y. C. Lai and P. C. Lin, “Evasion techniques: Sneaking through your
intrusion detection/prevention systems.,” Communications Surveys & Tutorials, IEEE, vol. 14,
no. 4, pp. 1011-1020, 2012.
[26] R. Koch, “Towards Next-Generation Intrusion Detection,” in 3rd International Conference on
Cyber Conflict (ICCC), Tallinn, Estonia, 2011.
vii
[27] T. Smith, “Next Generation Intrusion Prevention System (NGIPS) Test Report,” NSS Labs, Inc.,
2015. [Online]. Available: http://www.fortinet.com/sites/default/files/analystreports/Next-
Gen-Intrusion-Prevention-System-Test-Report.pdf. [Accessed 7 2 2016].
[28] “Next-Generation Firewall Overview,” Palo Alto Networks, [Online]. Available:
https://www.paloaltonetworks.com/content/dam/paloaltonetworks-
com/en_US/assets/pdf/datasheets/firewall-features-overview/firewall-features-
overview.pdf. [Accessed 7 2 2016].
[29] S. Clifford, “Stalking the Wily Hacker,” Communications of the ACM, vol. 31, no. 5, pp. 484-
497, May 1988.
[30] B. Cheswick, “An Evening with Berferd in which a cracker is Lured, Endured, and Studied.,” in
Winter USENIX Conference, San Francisco, 1992.
[31] “Deception Toolkit,” [Online]. Available: http://www.all.net/dtk/. [Accessed 30 07 2016].
[32] L. Spitzner, Honeypots: Tracking Hackers, Addison Wesley, 2002.
[33] “Project Artillery,” Binary Defense, [Online]. Available:
https://www.binarydefense.com/project-artillery/. [Accessed 30 07 2016].
[34] N. Provos, “Honeyd: A Virtual Honeypot Daemon,” in 10th DFN-CERT Workshop, Hamburg,
Germany, 2003.
[35] “SPECTER Intrusion Detection System,” NETSEC, [Online]. Available:
http://www.specter.com/default50.htm. [Accessed 30 07 2016].
[36] S. Innes and V. Craig, “Honeypots: How do you know when you are inside one?,” Australian
Digital Forensics Conference, p. 28, 2006.
[37] D. Sysman, G. Evron and I. Sher, “Breaking Honeypots for Fun and Profit,” in BLACKHAT, Las
Vegas, NV, 2015.
[38] H. Artail, H. Safa, M. Sraj, I. Kuwatly and Z. Al-Masri, “A hybrid honeypot framework for
improving intrusion detection systems in protecting organizational networks,” Computers &
Security, vol. 25, no. 4, pp. 274-288, 2006.
[39] D. Dagon, X. Qin, G. Gu, W. Lee, J. Grizzard, J. Levine and H. Owen, “HoneyStat: LocalWorm
Detection Using Honeypots,” in Recent Advances in Intrusion Detection: 7th International
Symposium, Springer Berlin Heidelber, 2004 Sept, pp. 39-58.
[40] A. Prathapani, L. Santhanam and D. P. Agrawal, “Intelligent honeypot agent for blackhole
attack detection in wireless mesh networks.,” Mobile Adhoc and Sensor Systems, 2009. MASS
'09. IEEE 6th International Conference on, pp. 753-758, 2009.
[41] L. Spitzner, “Honeypots: Catching the insider threat,” Computer Security Applications
Conference, 2003. Proceedings. 19th Annual, pp. 170-179, 2003.
[42] C. Kreibich and J. Crowcroft, “Honeycomb: creating intrusion detection signatures using
honeypots,” ACM SIGCOMM Computer Communication, vol. 34, no. 1, pp. 51-56, 2004.
viii
[43] U. Thakar, S. Varma and A. Ramani, “HoneyAnalyzer–analysis and extraction of intrusion
detection patterns & signatures using honeypot.,” in Proceedings of the Second International
Conference on Innovations in Information Technology, 2005.
[44] M. Nassar, S. Niccolini, R. State and T. Ewald, “Holistic VoIP intrusion detection and
prevention system,” in Proceedings of the 1st international conference on Principles, systems
and applications of IP telecommunications (IPTComm '07)., New York, NY, USA, 2007.
[45] R. K. Singh and T. Prof. Ramanujam, “Intrusion Detection System Using Advanced
Honeypots,” International Journal of Computer Science and Information Security (IJCSIS), vol.
2, no. 1, June 2009.
[46] B. Khosravifar and J. Bentahar, “An Experience Improving Intrusion Detection Systems False
Alarm Ratio by Using Honeypot,” in 22nd International Conference on Advanced Information
Networking and Applications, Okinawa, 2008.
[47] K. G. Anagnostakis, S. Sidiroglou, P. Akritidis, K. Xinidis, E. Markatos and A. D. Keromytis,
“Detecting Targeted Attacks Using Shadow Honeypots,” in Usenix Security Symposium,
Baltimore, Maryland, August 2005.
[48] N. Weiler, “Honeypots for distributed denial-of-service attacks,” Enabling Technologies:
Infrastructure for Collaborative Enterprises, 2002. WET ICE 2002. Proceedings. Eleventh IEEE
International Workshops on, pp. 109-114, 2002.
[49] The Snort Project, “SNORT Users Manual,” 18 March 2016. [Online]. Available:
https://www.snort.org/documents/1. [Accessed 04 06 2016].
[50] J. Whitsitt, “The Bait and Switch Honeypot,” Violating Networks, [Online]. Available:
http://baitnswitch.sourceforge.net/. [Accessed 25 07 2016].
[51] “Snort Mailing List,” [Online]. Available: http://seclists.org/snort/. [Accessed 12 08 16].
[52] M. G. Marsh, “Policy Routing With Linux,” 2001. [Online]. Available:
http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html. [Accessed 12 08 2016].
[53] K. E. Heckman, M. J. Walsh, F. J. Stech, T. A. O’Boyle, S. R. DiCato and A. F. Herber, “Active
cyber defense with denial and deception: A cyber-wargame experiment,” Computers &
Security, vol. 37, pp. 72-77, 2013.
[54] E. Casey, “Investigating sophisticated security breaches,” Commun. ACM, vol. 49, no. 2, pp.
48-55, 2006.
ix
Appendix A: Installation Guide
Step 1: Virtual Network Configuration
Our mechanism requires at least four virtual networks that can be configured through
VMware’s virtual network editor as shown in Figure B - 1.
Figure A - 1: Virtual Network Configuration
The networks presented in Figure B – 1 are the same with the ones described in Chapter 5.2
with VMnet1 being the management network, VMnet3 the Honeynet, VM4 the DMZ network,
VMnet5 the network shared with the IDS and pfSense and VMnet8 the public network.
VMnet4 and VMnet3 as described in Chapter 5 should be the same, however, VMware’s
Virtual network editor does not allow two VMnets to be in the same address space. As a result,
they have to be configured in different subnets. In practice, as they are not managed by
VMware but by the main gateway and honeynet’s firewall both networks use the same
address space. VMnet8 can also be changed depending on the setup and can also be replaced
by a bridged interface.
x
Step 2: The Main Gateway (IPS)
Our main gateway is based on a clean Ubuntu Server 14.04.4 LTS installation. The virtual
machine requires 4 network interfaces each one connected to VMnet1, VMnet5, VMnet4 and
VMnet8. While Webmin is not required, it will assist in the configuration of the firewall router.
The router set up is a basic Webmin installation with “loose” firewall rules that allow full
access from the wan interface (VMnet8) to the Lan Interfaces (VMnet4 & VMnet5).
For the modified Snort set-up, we need to begin with a default snort installation similar to the
one described by Noah Dietrich in his tutorial1. However, in our case we require Snort to be
configured in IPS mode and to monitor a single interface, thus we are going to use DAQ’s
NFQUEUE module. If snort is acting as a bridge between two interfaces, then it will not be able
to redirect the malicious packets to a different interface.
NFQUEUE requires libnetfilter_queue2 library to be installed on our system.
# sudo apt-get install libnetfilter-queue1 libnetfilter-queue-
dev
DAQ has now to be recompiled and re-installed in our system using the following command:
# ./configure --enable-nfq-module=yes
# make & make install
Once installed we should get the following output:
Build AFPacket DAQ module.. : yes
Build Dump DAQ module...... : yes
Build IPFW DAQ module...... : yes
Build IPQ DAQ module....... : no
Build NFQ DAQ module....... : yes
Build PCAP DAQ module...... : yes
1 https://s3.amazonaws.com/snort-org-site/production/document_files/files/000/000/090/original/Snort_2.9.8.x_on_Ubuntu_12-14-15.pdf 2 http://www.netfilter.org/projects/libnetfilter_queue/
xi
After successfully re-installing DAQ we need to add the necessary iptables rules that will push the network packets of the LAN interface (eth0) in the NFQUEUE with the following commands: # iptables -A FORWARD -i eth0 -j NFQUEUE --queue-num 1
# iptables -A FORWARD -o eth0 -j NFQUEUE --queue-num 1
After a packet is pushed in the NFQUEUE no further iptables rules will be processed for the same packet. Thus, it will be better not to add these rules to the stored iptables rule-list but to append them on every system restart. In our implementation we modify the snort.conf file that is located in /etc/init/ directory as follows. description "Snort NIDS Service"
stop on runlevel [!2345]
start on runlevel [2345]
script
exec /usr/local/bin/snort -q -c /etc/snort/snort.conf -
Q -D
end script
post-start script
/sbin/iptables -A FORWARD -i eth0 -j NFQUEUE --queue-
num 1
/sbin/iptables -A FORWARD -o eth0 -j NFQUEUE --queue-
num 1
end script
post-stop script
/sbin/iptables -D FORWARD -i eth0 -j NFQUEUE --queue-
num 1
/sbin/iptables -D FORWARD -o eth0 -j NFQUEUE --queue-
num 1
end script
Finally, we configure snort to operate in IPS mode and use DAQ’s NFQUEUE module through snort’s main configuration file located in /etc/snort. We modify lines 159-162 of snort.conf file as follows: config daq: nfq
config daq_dir: /usr/local/lib/daq
config daq_mode: inline
config daq_var: queue=1
Now we should be able to run snort in IPS mode monitoring a single interface (eth0) using DAQ’s NFQUEUE module. In order to modify snort to redirect each adversary to the honeynet we need to use policy routing. Initially we create a new policy routing table named “blocked”. # echo 200 blocked >> /etc/iproute2/rt_tables
Then we populate the new routing table using the following command:
# ip route add default via 172.16.1.2 dev eth1 table blocked
xii
Where 172.16.1.2 is the IP address of the honeynet firewall / gateway and eth1 the interface connected to VMnet5. To make this route persistent on every system reboot, we modify the /etc/network/interfaces configuration file as bellow, so that the above route will be added to the routing table when the interface eth1 is up.
/etc/network/interfaces:
# This file describes the network interfaces available on your
system
# and how to activate them. For more information, see
interfaces(5).
# The loopback network interface
auto lo wan0 eth0 eth1 mng0
iface lo inet loopback
# WAN network interface
iface wan0 inet dhcp
# LAN network interface
iface eth0 inet static
address 10.10.1.1
netmask 255.255.255.0
broadcast 10.10.1.255
network 10.10.1.0
post-up iptables-restore < /etc/iptables.up.rules
iface eth1 inet static
address 172.16.1.1
netmask 255.255.255.252
broadcast 172.16.1.3
network 172.16.1.0
post-up ip route add default via 172.16.1.2 dev eth1
table blocked
# Management network interface
iface mng0 inet dhcp
Finally, we replace Snort’s detect.c file located in the src folder of snort’s source code with the one provided in Appendix B and we re-compile and re-install snort. Snort will now add a policy routing rule for the source IP address of every packet that triggers a “DROP” or “SDROP” rule.
xiii
Step 3: The Honeynet
The honeynet’s gateway is a pfSense virtual machine with three interfaces. Its WAN interface
is connected to VMnet5 and its IP address is dynamically assigned by the Main Gateway’s
DHCP service where a static mapping has been configured. The other two interfaces are for
the Honeynet and Management network and thus they are connected to VMnet3 and VMnet1
respectively. Just like the Main Gateway, it has a “loose” firewall configuration that will allow
any incoming traffic to the Honeynet from the WAN interface. However, firewall rules should
be added to restrict Honeynet’s access to the management interface of pfSense, to the
Management network and to the Main Gateway. A firewall rule is also added only allow traffic
from the Honeynet to the MHN server. If desired, further firewall rules can be added to restrict
honeynet’s access to external IP addresses or a pfSense Snort package can be installed to
prevent attacks from the Honeynet to external systems.
Each system in the honeynet should be configured based on the attacks that the organization
wants to capture and the risk the security administrators are willing to take. In our case we
used the Modern Honey Network to manage and deploy our honeypots where the MHN
server’s deployment script can be found in MHN’s github repository3. Using MHN server’s web
interface, and honeypot deployment scripts we install the rest of the honeypots on our
systems (Figure A – 2).
Figure A - 2: Honeypot Deployment using MHN server
Finally, we install Splunk Hunk4 on the same system the MHN server is running to analyse
MHN’s logs. MHN provides an application5 for Splunk with many preconfigured dashboards
for almost every honeypot currently supported by MHN. In order for MHN to integrate with
3 https://github.com/threatstream/mhn 4 http://www.splunk.com/en_us/products/hunk.html 5 https://github.com/threatstream/mhn-splunk
xiv
Splunk the hpfeeds-logger has to be installed with the following commands using the scripts
provided in MHN’s directory.
# cd /opt/mhn/scripts/
# sudo ./install_hpfeeds-logger-splunk.sh
The hpfeeds-logger will create a Splunk-readable log file in the log directory “/var/log/“ named “mhn-splunk.log”. Splunk can be configured to read this log file through its configuration page accessible through “Settings > Data inputs” (Figure A – 3).
Figure A - 3: Splunk's Data Input Configuration
Since Splunk is running on the same system with the MHN server we add the mhn_splunk.log
file as a Local Input and we assign it to the MHN application “mhn-splunk”.
Currently, there is no dashboard available for the Crowrie Honeypot, thus we need to alter
the MHN Splunk application to include the events produced by Crowrie on every search string
used to display Kippo’s events. The example bellow is an updated search string for the top SSH
usernames captured by Kippo or Cowrie honeypots.
“source="*mhn-splunk.log*" type=kippo.sessions OR
type=cowrie.sessions ssh_username=* | top ssh_username |
fields ssh_username, count”
Appendix B: Snort’s Modified “detect.c”
/* $Id$ */
/*
** Copyright (C) 1998-2002 Martin Roesch <[email protected]>
** Copyright (C) 2014-2015 Cisco and/or its affiliates. All rights reserved.
** Copyright (C) 2002-2013 Sourcefire, Inc.
** Dan Roelker <[email protected]>
** Marc Norton <[email protected]>
**
** This program is free software; you can redistribute it and/or modify
** it under the terms of the GNU General Public License Version 2 as
** published by the Free Software Foundation. You may not use, modify or
** distribute this program under any other version of the GNU General
** Public License.
**
** This program is distributed in the hope that it will be useful,
** but WITHOUT ANY WARRANTY; without even the implied warranty of
** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
** GNU General Public License for more details.
**
** You should have received a copy of the GNU General Public License
** along with this program; if not, write to the Free Software
** Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-
1301, USA.
**
** NOTES
** 5.7.02: Added interface for new detection engine. (Norton/Roelker)
** Modified by Apostolos Machas for Honeynet Redirection
*/
#define FASTPKT
/* I N C L U D E S **********************************************/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <string.h>
#include <stdlib.h>
#include "snort.h"
#include "detect.h"
#include "plugbase.h"
#include "snort_debug.h"
#include "util.h"
#include "mstring.h"
#include "tag.h"
#include "pcrm.h"
#include "fpcreate.h"
#include "fpdetect.h"
#include "sfthreshold.h"
#include "event_wrapper.h"
#include "event_queue.h"
#include "obfuscation.h"
#include "profiler.h"
#include "session_api.h"
#include "session_common.h"
#include "stream_api.h"
#include "active.h"
#include "signature.h"
#include "ipv6_port.h"
#include "ppm.h"
#include "sf_types.h"
#include "active.h"
#include "detection_util.h"
#include "preprocids.h"
#if defined(FEAT_OPEN_APPID)
#include "sp_appid.h"
#include "appIdApi.h"
#endif /* defined(FEAT_OPEN_APPID) */
#ifdef PORTLISTS
#include "sfutil/sfportobject.h"
#endif
#ifdef PERF_PROFILING
PreprocStats detectPerfStats;
#endif
#ifdef TARGET_BASED
#include "target-based/sftarget_protocol_reference.h"
#endif
#include "sfPolicy.h"
/* #define ITERATIVE_ENGINE */
OptTreeNode *otn_tmp = NULL; /* OptTreeNode temp ptr */
int do_detect;
int do_detect_content;
uint16_t event_id;
static char check_tags_flag;
static int CheckTagging(Packet *);
#ifdef PERF_PROFILING
PreprocStats eventqPerfStats;
#endif
static inline int preprocHandlesProto( Packet *p, PreprocEvalFuncNode *ppn )
{
return ( ( p->proto_bits & ppn->proto_mask ) || ( ppn->proto_mask ==
PROTO_BIT__ALL ) );
}
static inline bool processDecoderAlertsActionQ( Packet *p )
{
// with policy selected, process any decoder alerts and queued actions
DecodePolicySpecific(p);
// actions are queued only for IDS case
sfActionQueueExecAll(decoderActionQ);
return true;
}
static void DispatchPreprocessors( Packet *p, tSfPolicyId policy_id,
SnortPolicy *policy )
{
SessionControlBlock *scb = NULL;
PreprocEvalFuncNode *ppn;
PreprocEnableMask pps_enabled_foo;
bool alerts_processed = false;
// No expected sessions yet.
p->expectedSession = NULL;
// until we are in a Session context dispatch preprocs from the policy
list if there is one
p->cur_pp = policy->preproc_eval_funcs;
if( p->cur_pp == NULL )
{
alerts_processed = processDecoderAlertsActionQ( p );
LogMessage("WARNING: No preprocessors configured for policy %d.\n",
policy_id);
return;
}
pps_enabled_foo = policy->pp_enabled[ p->dp ] | policy->pp_enabled[ p-
>sp ];
EnablePreprocessors( p, pps_enabled_foo );
do {
ppn = p->cur_pp;
p->cur_pp = ppn->next;
// if packet has no data and we are up to APP preprocs then get out
if( p->dsize == 0 && ppn->priority >= PRIORITY_APPLICATION )
break;
if ( preprocHandlesProto( p, ppn ) && IsPreprocessorEnabled( p, ppn-
>preproc_bit ) )
ppn->func( p, ppn->context );
if( !alerts_processed && ( p->ips_os_selected || ppn->preproc_id ==
PP_FW_RULE_ENGINE ) )
alerts_processed = processDecoderAlertsActionQ( p );
if( scb == NULL && p->ssnptr != NULL )
scb = ( SessionControlBlock * ) p->ssnptr;
// if we now have session, update enabled pps if changed by previous
preproc
if( scb != NULL && pps_enabled_foo != scb->enabled_pps )
{
EnablePreprocessors( p, scb->enabled_pps );
pps_enabled_foo = scb->enabled_pps;
}
} while ( ( p->cur_pp != NULL ) && !( p->packet_flags & PKT_PASS_RULE )
);
// queued decoder alerts are processed after the selection of the
// IPS rule config for the flow, if not yet done then process them now
if( !alerts_processed )
alerts_processed = processDecoderAlertsActionQ( p );
if( p->dsize == 0 )
DisableDetect( p );
}
int Preprocess(Packet * p)
{
int retval = 0;
tSfPolicyId policy_id = getNapRuntimePolicy();
SnortPolicy *policy = snort_conf->targeted_policies[policy_id];
#ifdef PPM_MGR
uint64_t pktcnt=0;
#endif
PROFILE_VARS;
if (policy == NULL)
return -1;
#ifdef PPM_MGR
/* Begin Packet Performance Monitoring */
if( PPM_PKTS_ENABLED() )
{
pktcnt = PPM_INC_PKT_CNT();
PPM_GET_TIME();
PPM_INIT_PKT_TIMER();
#ifdef DEBUG
if( PPM_DEBUG_PKTS() )
{
/* for debugging, info gathering, so don't worry about
* (unsigned) casting of pktcnt, were not likely to debug
* 4G packets
*/
LogMessage("PPM: Process-BeginPkt[%u] caplen=%u\n",
(unsigned)pktcnt,p->pkth->caplen);
}
#endif
}
#endif
// If the packet has errors, we won't analyze it.
if ( p->error_flags )
{
// process any decoder alerts now that policy has been selected...
DecodePolicySpecific(p);
//actions are queued only for IDS case
sfActionQueueExecAll(decoderActionQ);
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
"Packet errors = 0x%x, ignoring traffic!\n", p->error_flags););
if ( p->error_flags & PKT_ERR_BAD_TTL )
pc.bad_ttl++;
else
pc.invalid_checksums++;
}
else
{
/* Not a completely ideal place for this since any entries added on
the
* PacketCallback -> ProcessPacket -> Preprocess trail will get
* obliterated - right now there isn't anything adding entries
there.
* Really need it here for stream5 clean exit, since all of the
* flushed, reassembled packets are going to be injected directly
into
* this function and there may be enough that the obfuscation entry
* table will overflow if we don't reset it. Putting it here does
* have the advantage of fewer entries per logging cycle */
obApi->resetObfuscationEntries();
do_detect = do_detect_content = !snort_conf->disable_all_policies;
/*
** Reset the appropriate application-layer protocol fields
*/
ClearHttpBuffers();
p->alt_dsize = 0;
DetectReset(p->data, p->dsize);
// ok, dispatch all preprocs enabled for this packet/session
DispatchPreprocessors( p, policy_id, policy );
if ( do_detect )
Detect(p);
}
check_tags_flag = 1;
PREPROC_PROFILE_START(eventqPerfStats);
retval = SnortEventqLog(snort_conf->event_queue, p);
SnortEventqReset();
PREPROC_PROFILE_END(eventqPerfStats);
/* Check for normally closed session */
if( session_api )
session_api->check_session_closed(p);
/*
** By checking tagging here, we make sure that we log the
** tagged packet whether it generates an alert or not.
*/
if (IPH_IS_VALID(p))
CheckTagging(p);
otn_tmp = NULL;
/*
** If we found events in this packet, let's flush
** the stream to make sure that we didn't miss any
** attacks before this packet.
*/
if(retval && IsTCP(p) && stream_api)
stream_api->alert_flush_stream(p);
#ifdef PPM_MGR
if( PPM_PKTS_ENABLED() )
{
PPM_GET_TIME();
PPM_TOTAL_PKT_TIME();
PPM_ACCUM_PKT_TIME();
#ifdef DEBUG
if( PPM_DEBUG_PKTS() )
{
LogMessage("PPM: Pkt[%u] Used= ",(unsigned)pktcnt);
PPM_PRINT_PKT_TIME("%g usecs\n");
LogMessage("PPM: Process-EndPkt[%u]\n\n",(unsigned)pktcnt);
}
#endif
PPM_PKT_LOG(p);
}
if( PPM_RULES_ENABLED() )
{
PPM_RULE_LOG(pktcnt, p);
}
if( PPM_PKTS_ENABLED() )
{
PPM_END_PKT_TIMER();
}
#endif
return retval;
}
/*
** NAME
** CheckTagging::
*/
/**
** This is where we check to see if we tag the packet. We only do
** this if we've alerted on a non-pass rule and the packet is not
** rebuilt.
**
** We don't log rebuilt packets because the output plugins log the
** individual packets of a rebuilt stream, so we don't want to dup
** tagged packets for rebuilt streams.
**
** @return integer
*/
static int CheckTagging(Packet *p)
{
Event event;
if(check_tags_flag == 1 && !(p->packet_flags & PKT_REBUILT_STREAM))
{
void* listhead = NULL;
DEBUG_WRAP(DebugMessage(DEBUG_FLOW, "calling CheckTagList\n"););
if(CheckTagList(p, &event, &listhead))
{
DEBUG_WRAP(DebugMessage(DEBUG_FLOW, "Matching tag node found, "
"calling log functions\n"););
/* if we find a match, we want to send the packet to the
* logging mechanism
*/
CallLogFuncs(p, "Tagged Packet", listhead, &event);
}
}
return 0;
}
#if defined(FEAT_OPEN_APPID)
static void updateEventAppName (Packet *p, OptTreeNode *otn, Event *event)
{
const char *appName;
AppIdOptionData *app_data = (AppIdOptionData*)otn-
>ds_list[PLUGIN_APPID];
if (app_data && (app_data->matched_appid) && (appName =
appIdApi.getApplicationName(app_data->matched_appid)))
memcpy(event->app_name, appName, sizeof(event->app_name));
else if (p->ssnptr)
{
//log most specific appid when rule didn't have any appId
int16_t serviceProtoId, clientProtoId, payloadProtoId, miscProtoId,
pickedProtoId;
stream_api->get_application_id(p->ssnptr, &serviceProtoId,
&clientProtoId, &payloadProtoId, &miscProtoId);
if ((p->packet_flags & PKT_FROM_CLIENT))
{
if (!(pickedProtoId = payloadProtoId) && !(pickedProtoId =
miscProtoId) && !(pickedProtoId = clientProtoId))
pickedProtoId = serviceProtoId;
}
else
{
if (!(pickedProtoId = payloadProtoId) && !(pickedProtoId =
miscProtoId) && !(pickedProtoId = serviceProtoId))
pickedProtoId = clientProtoId;
}
if ((pickedProtoId) && (appName =
appIdApi.getApplicationName(pickedProtoId)))
{
memcpy(event->app_name, appName, sizeof(event->app_name));
}
else
{
event->app_name[0] = 0;
}
}
else
{
event->app_name[0] = 0;
}
}
#endif /* defined(FEAT_OPEN_APPID) */
void CallLogFuncs(Packet *p, const char *message, ListHead *head, Event
*event)
{
OutputFuncNode *idx = NULL;
if (event->sig_generator != GENERATOR_TAG)
{
event->ref_time.tv_sec = p->pkth->ts.tv_sec;
event->ref_time.tv_usec = p->pkth->ts.tv_usec;
}
/* set the event number */
event->event_id = event_id | ScEventLogId();
check_tags_flag = 0;
pc.log_pkts++;
if ( head == NULL || head->LogList == NULL )
{
CallLogPlugins(p, message, event);
return;
}
idx = head->LogList;
while ( idx != NULL )
{
idx->func(p, message, idx->arg, event);
idx = idx->next;
}
}
void CallLogPlugins(Packet * p, const char *message, Event *event)
{
OutputFuncNode *idx = LogList;
while ( idx != NULL )
{
idx->func(p, message, idx->arg, event);
idx = idx->next;
}
}
/* Call the output functions that are directly attached to the signature */
void CallSigOutputFuncs(Packet *p, OptTreeNode *otn, Event *event)
{
OutputFuncNode *idx = NULL;
idx = otn->outputFuncs;
while(idx)
{
idx->func(p, otn->sigInfo.message, idx->arg, event);
idx = idx->next;
}
}
void CallAlertFuncs(Packet * p, const char *message, ListHead * head, Event
*event)
{
OutputFuncNode *idx = NULL;
event->ref_time.tv_sec = p->pkth->ts.tv_sec;
event->ref_time.tv_usec = p->pkth->ts.tv_usec;
/* set the event number */
event->event_id = event_id | ScEventLogId();
/* set the event reference info */
event->event_reference = event->event_id;
pc.total_alert_pkts++;
if ( event->sig_generator != GENERATOR_SPP_REPUTATION )
{
/* Don't include IP Reputation events in count */
pc.alert_pkts++;
}
if ( head == NULL || head->AlertList == NULL )
{
CallAlertPlugins(p, message, event);
return;
}
idx = head->AlertList;
while ( idx != NULL )
{
idx->func(p, message, idx->arg, event);
idx = idx->next;
}
}
void CallAlertPlugins(Packet * p, const char *message, Event *event)
{
OutputFuncNode *idx = AlertList;
while ( idx != NULL )
{
idx->func(p, message, idx->arg, event);
idx = idx->next;
}
}
/***************************************************************************
*
*
* Function: Detect(Packet *)
*
* Purpose: Apply the rules lists to the current packet
*
* Arguments: p => ptr to the decoded packet struct
*
* Returns: 1 == detection event
* 0 == no detection
*
***************************************************************************/
int Detect(Packet * p)
{
int detected = 0;
PROFILE_VARS;
if ((p == NULL) || !IPH_IS_VALID(p))
{
return 0;
}
if (!snort_conf->ip_proto_array[GET_IPH_PROTO(p)])
{
#ifdef GRE
switch (p->outer_family)
{
case AF_INET:
if (!snort_conf->ip_proto_array[p->outer_ip4h.ip_proto])
return 0;
break;
case AF_INET6:
if (!snort_conf->ip_proto_array[p->outer_ip6h.next])
return 0;
break;
default:
return 0;
}
#else
return 0;
#endif /* GRE */
}
if (p->packet_flags & PKT_PASS_RULE)
{
/* If we've already seen a pass rule on this,
* no need to continue do inspection.
*/
return 0;
}
#ifdef PPM_MGR
/*
* Packet Performance Monitoring
* (see if preprocessing took too long)
*/
if( PPM_PKTS_ENABLED() )
{
PPM_GET_TIME();
PPM_PACKET_TEST();
if( PPM_PACKET_ABORT_FLAG() )
return 0;
}
#endif
/*
** This is where we short circuit so
** that we can do IP checks.
*/
PREPROC_PROFILE_START(detectPerfStats);
detected = fpEvalPacket(p);
PREPROC_PROFILE_END(detectPerfStats);
return detected;
}
void TriggerResponses(Packet * p, OptTreeNode * otn)
{
RspFpList *idx;
idx = otn->rsp_func;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"Triggering responses %p\n",
idx););
while(idx != NULL)
{
idx->func(p, idx->params);
idx = idx->next;
}
}
int CheckAddrPort(
sfip_var_t *rule_addr,
PortObject * po,
Packet *p,
uint32_t flags, int mode)
{
sfaddr_t* pkt_addr; /* packet IP address */
u_short pkt_port; /* packet port */
int global_except_addr_flag = 0; /* global exception flag is set */
int any_port_flag = 0; /* any port flag set */
int except_port_flag = 0; /* port exception flag set */
int ip_match = 0; /* flag to indicate addr match made */
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "CheckAddrPort: "););
/* set up the packet particulars */
if(mode & CHECK_SRC_IP)
{
pkt_addr = GET_SRC_IP(p);
pkt_port = p->sp;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"SRC "););
if(mode & INVERSE)
{
global_except_addr_flag = flags & EXCEPT_DST_IP;
any_port_flag = flags & ANY_DST_PORT;
except_port_flag = flags & EXCEPT_DST_PORT;
}
else
{
global_except_addr_flag = flags & EXCEPT_SRC_IP;
any_port_flag = flags & ANY_SRC_PORT;
except_port_flag = flags & EXCEPT_SRC_PORT;
}
}
else
{
pkt_addr = GET_DST_IP(p);
pkt_port = p->dp;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "DST "););
if(mode & INVERSE)
{
global_except_addr_flag = flags & EXCEPT_SRC_IP;
any_port_flag = flags & ANY_SRC_PORT;
except_port_flag = flags & EXCEPT_SRC_PORT;
}
else
{
global_except_addr_flag = flags & EXCEPT_DST_IP;
any_port_flag = flags & ANY_DST_PORT;
except_port_flag = flags & EXCEPT_DST_PORT;
}
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "addr %lx, port %d ", pkt_addr,
pkt_port););
if(!rule_addr)
goto bail;
if(!(global_except_addr_flag)) /*modeled after Check{Src,Dst}IP
function*/
{
if(sfvar_ip_in(rule_addr, pkt_addr))
ip_match = 1;
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", global exception flag
set"););
/* global exception flag is up, we can't match on *any*
* of the source addresses
*/
if(sfvar_ip_in(rule_addr, pkt_addr))
return 0;
ip_match=1;
}
bail:
if(!ip_match)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", no address match, "
"packet rejected\n"););
return 0;
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", addresses accepted"););
/* if the any port flag is up, we're all done (success) */
if(any_port_flag)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", any port match, "
"packet accepted\n"););
return 1;
}
#ifdef TARGET_BASED
if (!(mode & (CHECK_SRC_PORT | CHECK_DST_PORT)))
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckAddrPort..."
"target-based-protocol=%d,ignoring ports\n",
GetProtocolReference(p)););
return 1;
}
else
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckAddrPort..."
"target-based-protocol=%d,not ignoring ports\n",
GetProtocolReference(p)););
}
#endif /* TARGET_BASED */
/* check the packet port against the rule port */
if( !PortObjectHasPort(po,pkt_port) )
{
/* if the exception flag isn't up, fail */
if(!except_port_flag)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", port mismatch, "
"packet rejected\n"););
return 0;
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", port mismatch
exception"););
}
else
{
/* if the exception flag is up, fail */
if(except_port_flag)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
", port match exception, packet
rejected\n"););
return 0;
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", ports match"););
}
/* ports and address match */
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, ", packet accepted!\n"););
return 1;
}
/***************************************************************************
*
*
* Function: DumpList(IpAddrNode*)
*
* Purpose: print out the chain lists by header block node group
*
* Arguments: node => the head node
*
* Returns: void function
*
***************************************************************************/
void DumpList(IpAddrNode *idx, int negated)
{
DEBUG_WRAP(int i=0;);
if(!idx)
return;
while(idx != NULL)
{
DEBUG_WRAP(DebugMessage(DEBUG_RULES,
"[%d] %s",
i++, sfip_ntoa(&idx->ip->addr)););
if(negated)
{
DEBUG_WRAP(DebugMessage(DEBUG_RULES,
" (EXCEPTION_FLAG Active)\n"););
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_RULES, "\n"););
}
idx = idx->next;
}
}
/***************************************************************************
*
*
* Function: DumpChain(RuleTreeNode *, char *, char *)
*
* Purpose: Iterate over RTNs calling DumpList on each
*
* Arguments: rtn_idx => the RTN index pointer
* rulename => the name of the rule the list belongs
to
* listname => the name of the list being printed out
*
* Returns: void function
*
***************************************************************************/
void DumpChain(RuleTreeNode * rtn_head, char *rulename, char *listname)
{
// XXX Not yet implemented - Rule chain dumping
}
#define CHECK_ADDR_SRC_ARGS(x) (x)->src_portobject
#define CHECK_ADDR_DST_ARGS(x) (x)->dst_portobject
int CheckBidirectional(Packet *p, struct _RuleTreeNode *rtn_idx,
RuleFpList *fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "Checking bidirectional
rule...\n"););
if(CheckAddrPort(rtn_idx->sip, CHECK_ADDR_SRC_ARGS(rtn_idx), p,
rtn_idx->flags, CHECK_SRC_IP | (check_ports ?
CHECK_SRC_PORT : 0)))
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " Src->Src check
passed\n"););
if(! CheckAddrPort(rtn_idx->dip, CHECK_ADDR_DST_ARGS(rtn_idx), p,
rtn_idx->flags, CHECK_DST_IP | (check_ports ?
CHECK_DST_PORT : 0)))
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" Dst->Dst check failed,"
" checking inverse combination\n"););
if(CheckAddrPort(rtn_idx->dip, CHECK_ADDR_DST_ARGS(rtn_idx), p,
rtn_idx->flags, (CHECK_SRC_IP | INVERSE |
(check_ports ? CHECK_SRC_PORT : 0))))
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" Inverse Dst->Src check passed\n"););
if(!CheckAddrPort(rtn_idx->sip,
CHECK_ADDR_SRC_ARGS(rtn_idx), p,
rtn_idx->flags, (CHECK_DST_IP | INVERSE |
(check_ports ? CHECK_DST_PORT : 0))))
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" Inverse Src->Dst check failed\n"););
return 0;
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "Inverse addr/port
match\n"););
}
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " Inverse Dst->Src
check failed,"
" trying next rule\n"););
return 0;
}
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "dest IP/port match\n"););
}
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" Src->Src check failed, trying inverse
test\n"););
if(CheckAddrPort(rtn_idx->dip, CHECK_ADDR_DST_ARGS(rtn_idx), p,
rtn_idx->flags, CHECK_SRC_IP | INVERSE |
(check_ports ? CHECK_SRC_PORT : 0)))
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" Dst->Src check passed\n"););
if(!CheckAddrPort(rtn_idx->sip, CHECK_ADDR_SRC_ARGS(rtn_idx), p,
rtn_idx->flags, CHECK_DST_IP | INVERSE |
(check_ports ? CHECK_DST_PORT : 0)))
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" Src->Dst check failed\n"););
return 0;
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
"Inverse addr/port match\n"););
}
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," Inverse test failed, "
"testing next rule...\n"););
return 0;
}
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," Bidirectional success!\n"););
return 1;
}
/***************************************************************************
*
*
* Function: CheckSrcIp(Packet *, struct _RuleTreeNode *, RuleFpList *)
*
* Purpose: Test the source IP and see if it equals the SIP of the packet
*
* Arguments: p => ptr to the decoded packet data structure
* rtn_idx => ptr to the current rule data struct
* fp_list => ptr to the current function pointer node
*
* Returns: 0 on failure (no match), 1 on success (match)
*
***************************************************************************/
int CheckSrcIP(Packet * p, struct _RuleTreeNode * rtn_idx, RuleFpList *
fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"CheckSrcIPEqual: "););
if(!(rtn_idx->flags & EXCEPT_SRC_IP))
{
if( sfvar_ip_in(rtn_idx->sip, GET_SRC_IP(p)) )
{
// XXX NOT YET IMPLEMENTED - debugging in Snort6
#if 0
#ifdef DEBUG_MSGS
sfaddr_t ip;
if(idx->addr_flags & EXCEPT_IP) {
DebugMessage(DEBUG_DETECT, " SIP exception match\n");
}
else
{
DebugMessage(DEBUG_DETECT, " SIP match\n");
}
ip = *iph_ret_src(p); /* necessary due to
referencing/dereferencing */
DebugMessage(DEBUG_DETECT, "Rule: %s Packet: %s\n",
inet_ntoa(idx->ip_addr), inet_ntoa(ip));
#endif /* DEBUG */
#endif
/* the packet matches this test, proceed to the next test */
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
}
else
{
/* global exception flag is up, we can't match on *any*
* of the source addresses
*/
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," global exception flag,
\n"););
if( sfvar_ip_in(rtn_idx->sip, GET_SRC_IP(p)) ) return 0;
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," Mismatch on SIP\n"););
return 0;
/* return 0 on a failed test */
return 0;
}
/***************************************************************************
*
*
* Function: CheckDstIp(Packet *, struct _RuleTreeNode *, RuleFpList *)
*
* Purpose: Test the dest IP and see if it equals the DIP of the packet
*
* Arguments: p => ptr to the decoded packet data structure
* rtn_idx => ptr to the current rule data struct
* fp_list => ptr to the current function pointer node
*
* Returns: 0 on failure (no match), 1 on success (match)
*
***************************************************************************/
int CheckDstIP(Packet *p, struct _RuleTreeNode *rtn_idx, RuleFpList
*fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, "CheckDstIPEqual: ");)
if(!(rtn_idx->flags & EXCEPT_DST_IP))
{
if( sfvar_ip_in(rtn_idx->dip, GET_DST_IP(p)) )
{
// #ifdef DEBUG_MSGS
// XXX idx's equivalent is lost inside of sfvar_ip_in
// DebugMessage(DEBUG_DETECT, "Rule: %s Packet: ",
// inet_ntoa(idx->ip_addr));
// DebugMessage(DEBUG_DETECT, "%s\n", sfip_ntoa(iph_ret_dst(p)));
// #endif
/* the packet matches this test, proceed to the next test */
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
}
else
{
/* global exception flag is up, we can't match on *any*
* of the source addresses */
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," global exception flag,
\n"););
if( sfvar_ip_in(rtn_idx->dip, GET_DST_IP(p)) ) return 0;
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
return 0;
}
int CheckSrcPortEqual(Packet *p, struct _RuleTreeNode *rtn_idx,
RuleFpList *fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"CheckSrcPortEqual: "););
#ifdef TARGET_BASED
/* Check if attributes provided match earlier */
if (check_ports == 0)
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckSrcPortEq..."
"target-based-protocol=%d,ignoring ports\n",
GetProtocolReference(p)););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckSrcPortEq..."
"target-based-protocol=%d,not ignoring ports\n",
GetProtocolReference(p)););
}
#endif /* TARGET_BASED */
if( PortObjectHasPort(rtn_idx->src_portobject,p->sp) )
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " SP match!\n"););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " SP mismatch!\n"););
}
return 0;
}
int CheckSrcPortNotEq(Packet *p, struct _RuleTreeNode *rtn_idx,
RuleFpList *fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"CheckSrcPortNotEq: "););
#ifdef TARGET_BASED
/* Check if attributes provided match earlier */
if (check_ports == 0)
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckSrcPortNotEq..."
"target-based-protocol=%d,ignoring ports\n",
GetProtocolReference(p)););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckSrcPortNotEq..."
"target-based-protocol=%d,not ignoring ports\n",
GetProtocolReference(p)););
}
#endif /* TARGET_BASED */
if( !PortObjectHasPort(rtn_idx->src_portobject,p->sp) )
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " !SP match!\n"););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " !SP mismatch!\n"););
}
return 0;
}
int CheckDstPortEqual(Packet *p, struct _RuleTreeNode *rtn_idx,
RuleFpList *fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"CheckDstPortEqual: "););
#ifdef TARGET_BASED
/* Check if attributes provided match earlier */
if (check_ports == 0)
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckDstPortEq..."
"target-based-protocol=%d,ignoring ports\n",
GetProtocolReference(p)););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckDstPortEq..."
"target-based-protocol=%d,not ignoring ports\n",
GetProtocolReference(p)););
}
#endif /* TARGET_BASED */
if( PortObjectHasPort(rtn_idx->dst_portobject,p->dp) )
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " DP match!\n"););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," DP mismatch!\n"););
}
return 0;
}
int CheckDstPortNotEq(Packet *p, struct _RuleTreeNode *rtn_idx,
RuleFpList *fp_list, int check_ports)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,"CheckDstPortNotEq: "););
#ifdef TARGET_BASED
/* Check if attributes provided match earlier */
if (check_ports == 0)
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckDstPortNotEq..."
"target-based-protocol=%d,ignoring ports\n",
GetProtocolReference(p)););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(
DebugMessage(DEBUG_ATTRIBUTE, "detect.c: CheckDstPortNotEq..."
"target-based-protocol=%d,not ignoring ports\n",
GetProtocolReference(p)););
}
#endif /* TARGET_BASED */
if( !PortObjectHasPort(rtn_idx->dst_portobject,p->dp) )
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " !DP match!\n"););
return fp_list->next->RuleHeadFunc(p, rtn_idx, fp_list->next,
check_ports);
}
else
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," !DP mismatch!\n"););
}
return 0;
}
int RuleListEnd(Packet *p, struct _RuleTreeNode *rtn_idx,
RuleFpList *fp_list, int check_ports)
{
return 1;
}
int OptListEnd(void *option_data, Packet *p)
{
return DETECTION_OPTION_MATCH;
}
/* Rule Match Action Functions */
int PassAction(void)
{
pc.pass_pkts++;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," => Pass rule,
returning...\n"););
return 1;
}
int ActivateAction(Packet * p, OptTreeNode * otn, RuleTreeNode * rtn, Event
* event)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Activating and generating alert! \"%s\"\n",
otn->sigInfo.message););
#if defined(FEAT_OPEN_APPID)
updateEventAppName (p, otn, event);
#endif /* defined(FEAT_OPEN_APPID) */
CallAlertFuncs(p, otn->sigInfo.message, rtn->listhead, event);
if (otn->OTN_activation_ptr == NULL)
{
LogMessage("WARNING: an activation rule with no "
"dynamic rules matched.\n");
return 0;
}
otn->OTN_activation_ptr->active_flag = 1;
otn->OTN_activation_ptr->countdown =
otn->OTN_activation_ptr->activation_counter;
otn->RTN_activation_ptr->active_flag = 1;
otn->RTN_activation_ptr->countdown +=
otn->OTN_activation_ptr->activation_counter;
snort_conf->active_dynamic_nodes++;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," => Finishing activation
packet!\n"););
CallLogFuncs(p, otn->sigInfo.message, rtn->listhead, event);
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" => Activation packet finished, returning!\n"););
return 1;
}
int AlertAction(Packet * p, OptTreeNode * otn, RuleTreeNode * rtn, Event *
event)
{
if (!rtn)
{
// This function may be called from ppm, which doesn't do an RTN
lookup
rtn = getRuntimeRtnFromOtn(otn);
if (!rtn)
return 0;
}
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Generating alert! \"%s\", policyId %d\n", otn-
>sigInfo.message, getIpsRuntimePolicy()););
#if defined(FEAT_OPEN_APPID)
updateEventAppName (p, otn, event);
#endif /* defined(FEAT_OPEN_APPID) */
/* Call OptTreeNode specific output functions */
if(otn->outputFuncs)
CallSigOutputFuncs(p, otn, event);
if (ScAlertPacketCount())
print_packet_count();
CallAlertFuncs(p, otn->sigInfo.message, rtn->listhead, event);
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " => Finishing alert
packet!\n"););
CallLogFuncs(p, otn->sigInfo.message, rtn->listhead, event);
/*
if(p->ssnptr != NULL && stream_api)
{
if(stream_api->alert_flush_stream(p) == 0)
{
CallLogFuncs(p, otn->sigInfo.message, otn->rtn->listhead,
event);
}
}
else
{
CallLogFuncs(p, otn->sigInfo.message, otn->rtn->listhead, event);
}
*/
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," => Alert packet finished,
returning!\n"););
return 1;
}
int DropAction(Packet * p, OptTreeNode * otn, RuleTreeNode * rtn, Event *
event)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Adding Redirect rules! \"%s\"\n",
otn->sigInfo.message););
addRedirectRules(p);
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Generating Alert and dropping! \"%s\"\n",
otn->sigInfo.message););
if(stream_api && !stream_api->alert_inline_midstream_drops())
{
if(session_api->get_session_flags(p->ssnptr) & SSNFLAG_MIDSTREAM)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Alert Came From Midstream Session Silently Drop! "
"\"%s\"\n", otn->sigInfo.message););
Active_DropSession(p);
return 1;
}
}
/*
** Set packet flag so output plugins will know we dropped the
** packet we just logged.
*/
Active_DropSession(p);
#if defined(FEAT_OPEN_APPID)
updateEventAppName (p, otn, event);
#endif /* defined(FEAT_OPEN_APPID) */
CallAlertFuncs(p, otn->sigInfo.message, rtn->listhead, event);
CallLogFuncs(p, otn->sigInfo.message, rtn->listhead, event);
return 1;
}
int SDropAction(Packet * p, OptTreeNode * otn, Event * event)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Adding Redirect rules! \"%s\"\n",
otn->sigInfo.message););
addRedirectRules(p);
DEBUG_WRAP(DebugMessage(DEBUG_DETECT,
" <!!> Dropping without Alerting! \"%s\"\n",
otn->sigInfo.message););
// Let's silently drop the packet
Active_DropSession(p);
return 1;
}
int DynamicAction(Packet * p, OptTreeNode * otn, RuleTreeNode * rtn, Event *
event)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " => Logging packet data and"
" adjusting dynamic counts (%d/%d)...\n",
rtn->countdown, otn->countdown););
CallLogFuncs(p, otn->sigInfo.message, rtn->listhead, event);
otn->countdown--;
if( otn->countdown <= 0 )
{
otn->active_flag = 0;
snort_conf->active_dynamic_nodes--;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " <!!> Shutting down dynamic
OTN node\n"););
}
rtn->countdown--;
if( rtn->countdown <= 0 )
{
rtn->active_flag = 0;
DEBUG_WRAP(DebugMessage(DEBUG_DETECT, " <!!> Shutting down dynamic
RTN node\n"););
}
return 1;
}
int LogAction(Packet * p, OptTreeNode * otn, RuleTreeNode * rtn, Event *
event)
{
DEBUG_WRAP(DebugMessage(DEBUG_DETECT," => Logging packet data and
returning...\n"););
CallLogFuncs(p, otn->sigInfo.message, rtn->listhead, event);
#ifdef BENCHMARK
printf(" <!!> Check count = %d\n", check_count);
check_count = 0;
printf(" **** cmpcount: %d **** \n", cmpcount);
#endif
return 1;
}
/* end of rule action functions */
/*Adds the ip rule for the malicious source IP*/
void addRedirectRules(Packet * p)
{
char command[256];
snprintf(command, sizeof(command), "/bin/ip rule add from %s lookup
blocked", sfip_to_str(GET_SRC_IP(p)));
system(command);
}
![ISG-600 0.37 470 0.49 790 ü]fiEñ (kWh) ISG-400 29 …...ISG-600 0.37 470 0.49 790 ü]fiEñ (kWh) ISG-400 29 ISG-600 49 DAITOËtff± 2020 TEL (022) 253 -7445 TEL (047) 395- 3335 TEL](https://img.pdfslide.us/doc/110x75/5e5d97d3470c0964465f340b/isg-600-037-470-049-790-fie-kwh-isg-400-29-isg-600-037-470-049-790.jpg)
