ISIS - IP Spoofing Interruption System
Masters Project Report
by
Derrick Erickson
University of Colorado at Colorado Springs
Colorado Springs, CO
derickso@uccs.edu
1
Overview
This section will give a brief overview of ISIS, which includes the problem, my proposed solution,
and the reasoning behind it.
1.1
The Problem
The problem ISIS is designed to prevent is IP spoofing. IP spoofing is a method used in a denial of
service (DoS) attack or distributed denial of service (DDoS) attack. IP spoofing is when one machine
masquerades as another machine or host on a network. This allows the attacking host to be able to shift
the blame on the spoofed machine, and allows the host to hide its presence on the network. Another
reason IP spoofing is used is to masquerade as a host to get access to resources that have been specially
designated only for the target machine. This gives the attacker access to resources not normally
available to them.
1.1.1
Threat Model
The threat model for ISIS is a network like the ones in Figures 1 and 2. This kind of firewalled
network is the environment in which DoS/DDoS attacks can happen. For example one of the host
computers on the internal network could be compromised, which could have happened from malware
being installed or visiting a hacked website. Unknown to the other hosts on the network or even the
network administrator a DoS/DDoS attack could be launched from the corrupted host to a target host
out on the public network (internet). This network will then show up as the source for a DoS/DDoS
attack, and could be investigated by an ISP. Even though the source network is not a malicious one it
could be blacklisted because malicious traffic is coming from it, and by being blacklisted user may not be
able to get access to any services it hosts. From within the network the corrupted host can send
malicious traffic while pretending to be an uncorrupted host, so this type of attack is IP spoofing. This
will cause the spoofed host to be marked as the malicious host while the malicious host gets to continue
sending malicious traffic in disguise. This is the kind of attacks ISIS aims to help fight against, and by
recording and temporarily blocking traffic from the malicious host we can limit its impact.
Figure 1: A 2 layer firewall Architecture [12].
Figure 2: A private network with a firewalled host [11].
1.2
1.2.1
ISIS
Reason for ISIS
ISIS is being designed for many reasons, and one of which is to defend against IP spoofing
attacks. IP spoofing attacks are one form, of many, of DoS/DDoS attacks that are used by malicious
entities to attack victims. I focused on IP spoofing in particular because it is still a problem that needs a
viable solution. Most defenses against IP spoofing are disjoint from one another, and only protect
against one method of attack. These defenses will be covered in Section 3. Another reason ISIS is being
designed is to limit the range of attacks a malicious entity can use against its target. In reducing the
number of ways an attack can happen we can limit the effective fighting power of the attacker.
1.2.2 Proposed Solution
The proposed solution to IP Spoofing is ISIS. ISIS is a system that combines some facets of
traditional IP spoofing defenses, and extends their functionality and coverage to block IP spoofing
traffic. The design and implementation will be explained in further detail in Section 4.
2
Related Research
This section will give an overview of several relevant research papers and give a discussion on the
deficiencies of the proposed solutions in the papers.
2.1
Related Research
Overview- In “A Practical IP Spoofing Defense through Route-Based Filtering” [8], the authors
design a system called Clouseau. Clouseau is a system that uses route-based filtering and interface
tables to determine the source of a packet, and makes decisions based upon the source. This approach
also makes use of marking packets, and random TCP drops to trigger a learning process in Clouseau. The
learning process in Clouseau is what is used to dynamically update routing table entries when routes
have changed or unexpected packets have arrived.
Deficiencies- In “A Practical IP Spoofing Defense through Route-Based Filtering” [8], it relies
heavily on route-based filtering which can be costly in overhead. Also since Clouseau is a learning
process the authors noted that congestion can sometimes trigger a heavy filtering effect which hurts
legitimate traffic. Another problem noted by the authors is that the routing tables need to store an
immense amount of data to be precise, but newer routers have some ways to reduce this memory
footprint. One aspect I saw a problem with is if an attacker knows the route to its target, and discovers
the filtering points they could possibly route their way around the filters.
Overview- In “On the state of IP spoofing defense” [9], is a paper that analyzes many different
types of IP spoofing defenses. They range from router-based, end-host-based, active, passive, et cetera.
It goes into depth about each method of defense and talks about why IP spoofing is still considered a
major problem today.
Deficiencies- In “On the state of IP spoofing defense” [9], talks all about the deficiencies of
existing defenses from various contexts. It mentions how end-host based filtering is too late of a place
to detect/filter spoofed packets, while router-based filtering requires a wide-spread adoption to be
effective. Active filtering versus passive filtering is another aspect mentioned which comes down to
computational overhead, and false positives. This paper pretty proves that there is no one solution that
will solve the IP spoofing problem.
Overview- In “Controlling IP Spoofing based DDoS Attacks through Inter-Domain Packet Filters”
[10], uses BGP route filters instead of AS route filters used in [8]. This architecture is designed to not
function using global knowledge like route-based filters do, but instead rely upon BGP updates. This
method also relies upon ASes and their feasible path constraints that they enforce based upon their
routing policies. This helps the system limit the number of paths a valid packet can take, and makes it
easier to mark a spoofed packet because it does not flow along a feasible path.
Deficiencies- In “Controlling IP Spoofing based DDoS Attacks through Inter-Domain Packet Filters”
[10], has most of its issues stem from rapid changes in the network or path topology. If packets are sent
while an update is flowing through the network it can lead their system to drop packets, but they state
that this interruption would also interrupt the constant flow of packets a DDoS attack uses. Another
weakness is that if an attacker is on the same best path as the host it is masquerading as it will be hard
to detect whether the traffic has been spoofed.
Overview- In “Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed
Detection, and Adaptive Feedback.” The authors took a look at worms that propagate slowly from host
to host. Their goal was to use collaboration to improve the effectiveness of IDS and their detection of
the slow moving worms.
Deficiencies- In “Towards Autonomic Enterprise Security: Self-Defending Platforms, Distributed
Detection, and Adaptive Feedback.” The authors found that it was hard to distinguish between the slow
moving worm’s traffic and normal traffic. By using collaboration they were able to increase the effect,
but without it their false positive rates were higher.
Overview- SNORT is a lightweight IDS system developed for UNIX/Linux and windows systems. It
functions using a configuration file and command line options to determine its behavior. SNORT has
three modes of operation: packet sniffing, packet logging, and NIDS mode. This gives it the ability to
function however the user sees fit. Users even have the option of writing their own rules to integrate
into snort. [16]
Deficiencies- SNORT is a very big project that is still growing and developing, which means it will
get more complex. With more complexity in a project it can become very hard to integrate new
features if they are not related functionally. By this I mean that if the functionality is not IP packet level
inspection, but instead a higher level architecture management function then it may be hard to easily
integrate it into SNORT. Also SNORT is a SPOF software system, so if SNORT goes down all of its
functionality goes down as well.
3
Existing Defenses
This section will give an overview of a few of the known methods to fight against IP spoofing
attacks. This section is not an in-depth discussion of each individual topic, but instead a basic
introduction of each defense mechanism. This section will also cover the deficiencies of existing
defenses to help solidify the reason why extra effort is needed to prevent IP spoofing attacks.
3.1
Defenses
There are many different methods of defense to use when dealing with IP spoofed packets in a
network.
3.1.1
Blacklisting
Overview- This is a compiled list of hosts that have been marked as malicious or attackers, and
the list is constantly updated to retain accuracy. Blacklisting is marking an IP source address as a
malicious host, and blocks any traffic from that host.
Deficiencies- Since blacklisting marks hosts or IPs as malicious it can be detrimental to legitimate
traffic. This is because any legitimate host that has been spoofed will have its IP blacklisted. This will
block its traffic even though the malicious traffic did not come from the legitimate host, which lets the
malicious host do even more damage.
Another drawback to blacklisting is that a blacklist must be updated consistently to be effective,
and requires constant attention to be updated in a timely matter. Also since the IP is spoofed it is easy
for a malicious user to dance around the blacklist by switching IPs very quickly. By using blacklisting
against IP spoofing it would be more counter-productive than helpful.
3.1.2
Packet Filtering
Overview- There is two types of filtering used when dealing with spoofed packets, and they are
Ingress and Egress filtering. Each type of filtering is used to prevent a specific version of a spoofed
packet. For defensive purposes it is best to employ both Ingress and Egress filtering to prevent the
propagation of spoofed packets. Packet dropping is also another means of filtering packets based upon
certain criteria.
Deficiencies- Packet filtering is used to block packets based upon their formats, headers, or
other key indicators. This can be broken down into many forms which each have their own benefits,
and risks.
3.1.2.1 Ingress
Overview- Ingress filtering is a filtering mechanism that is used to fight against IP source address
spoofing. It is usually implemented via a ‘good neighbor’ policy, and can also be implemented by
enabling reverse path forwarding. This helps routers, and ISPs determine the true source of a packet.
Deficiencies- Ingress filtering relies upon a good neighbor policy, and tracking of what
connections the network has to other networks. Ingress filtering is only applied to incoming traffic,
which means that it has no defense to prevent bad traffic leaving the network. This is hard to take care
of because not all networks can be sure of what other network address blocks are valid, and which
address blocks are not. Since this is not always possible it becomes a less effective solution to IP
spoofing prevention, and is used to ensure the source address comes from the specified network.
3.1.2.2 Egress
Overview- Egress filtering is a filtering mechanism that is used to fight against IP spoofed
outgoing traffic. It is usually implemented via firewall/router rules on packets. This is done through a
strict policy that regulates ports, protocols, and uses proxies.
Deficiencies- Egress filtering is used to ensure that only good/legitimate traffic exits out through
the firewall or router. Egress filtering only works on traffic leaving the network, so by coupling it with
ingress filtering the weaknesses of both filtering methods can be covered. This is done by employing a
policy against specific IP formats, which requires analyzing IP packet formats to determine malicious
signatures. Since this is signature reliant if a malicious attacker changes the signature slightly then it can
bypass this filter, and continue to cause havoc on the network. This means that the filters must be
updated in a timely manner to ensure the effectiveness of the egress filter.
Another drawback to egress filtering is that if a new packet format is introduced it may be
unintentionally filtered out because of an existing filter that blocks its IP format. Also it could be
possible for an attacker to mimic the packet format of legitimate traffic to get through, but could
eventually be blocked. By blocking the similar format could lead to legitimate traffic getting blocked
also.
Another way around egress filtering could be tunneling through the firewall to bypass the
defensive measures, which renders any filtering completely invalid. This is normally done to get around
the blocking of certain protocols e.g. remote desktop protocol (RDP), and there are many FAQs on the
internet to learn how to do this. In theory a malicious user could tunnel out to an infected/malicious
host that would take any traffic sent to it, and forward it off to a target on the network.
3.1.2.3 Packet Dropping
Overview- Packet dropping is a filtering mechanism used against IP packets. Much like egress
filtering where packets are not allowed to go through the firewall or router based upon certain criteria,
but packet dropping can be used against incoming traffic as well as outgoing traffic.
Deficiencies- Packet dropping is similar to ingress and egress filtering except that it can be
applied to both incoming and outgoing traffic. This helps cover the weaknesses of ingress and egress
filtering, which both of them are one-way filtering methods. Since it can be a combination of ingress
and egress filtering it will inherit the weaknesses and strengths of both systems. This means requiring
constant updates to malicious signatures to be effective, and knowing which address blocks are valid.
3.1.2.4 Unified Threat Management (UTM)
Overview- A UTM is an all-in-one device that is a hardware-based firewall/IDS/VPN/content
filtering/et cetera in one device. This device serves to take disjoint defenses, and create a unified
defense. This helps make the setup as well as deployment of the defense easier than configuring, and
integrating multiple separate defenses to work with each other.
Deficiencies- Since this is an all-in-one defenses it can be a single point of failure (SPOF), which is
devastating to the security/functionality of a network if it breaks. Since it is also an all-in-one device if it
is corrupted then it can also be just as devastating as if the hardware itself fails. Another aspect to be
aware of is that if the traffic load of the network is too heavy than the UTM may not be able to keep up
with the network load, and latency could occur.
4
Proposed System
With the previous discussion of the need for configuration management systems as well as the
discussion of currently available configuration management systems and their deficiencies in mind a
new configuration management system is proposed in order to address these needs and deficiencies.
The following subsections will detail a high level overview of proposed solution and technologies.
4.1
Overview
ISIS is a system being designed to cope with the problems of IP spoofing attacks, and seeks to do
this by combining some existing defenses coupled with other preventive measures. ISIS is also designed
to be flexible for customization, scalability, and easy to deploy. This system is to be deployed where an
entry/exit point of a network is located. ISIS will function like an advanced egress filter because it will be
designed to prevent any IP spoofing traffic to leave the network it manages.
4.2
ISIS Deployment and Implementation Assumptions
ISIS would be deployed as an application that would be installed onto a host that is capable of
supporting ISIS, and its components. Any recent existing Linux/Unix distribution with Perl, MySQL
database, iptables, and ipsec installed should be capable of running ISIS. The hosts that ISIS needs to be
installed on should be a host that is at an entry/exit point on a network, and this is because ISIS uses
firewall rules to help prevent IP spoofing attacks. If ISIS is not on a host that traffic passes through then
it will not be capable of capturing packets, marking malicious hosts, and recording pertinent
information. For ISIS to work it must have the key technologies listed in Section 4.3.
4.3
Key Technologies
Like any system it is comprised of many different technologies that work together to form a
working system. This section will describe the different technologies used in ISIS, and their
uses/applications.
4.3.1
Firewall
For securing networks from outside attackers, sometimes even insider attacks, firewalls are
used. They are a primary defense against attacks, and are configurable to defend against a variety of
attacks. Aside from preventing attacks they can be used to limit the functionality of systems within a
network to behavior that is allowed e.g. blocking Wireshark, port snoopers, insecure protocols, etc.
4.3.1.1 IPChains/IPtables
IPchains is a standard means of creating a firewall on Linux machines. It is used to cope with the
issues of previous firewall configuration tools in previous versions of Linux [5], which is now part of
kernel 2.1.102 or higher. IPchains will be the firewall of choice for ISIS because it will be designed as
Linux application that will configure firewall rules on demand, so just use the standard.
IPtables is the replacement for IPchains, and IPtables was used in place of IPchains, but the
reason for firewalls rules has not changed. IPtables obsoletes IPchains, and that is why this is being
corrected.
4.3.2
IPSec
IPSec is the successor to ISO’s Network Layer Security Protocol (NLSP), and is meant for
encrypting the end-to-end path of packets in a network [6]. Whether a packet goes from host-to-host,
network-to-network, or network-to-host it is designed to protect the data flow [6]. IPSec provides
confidentiality, authentication of packet origin, and integrity of the packet, which is needed for securing
data from attackers.
4.3.3
MYSQL Database
MYSQL is an open source database that is among one of the most popular in use, and is very
extensible. Also MYSQL runs on numerous operating platforms, is usable by many different coding
languages, and is rather easy to use. Since it is very flexible and open source its applications are
numerous, which is why companies like Facebook, Google, Adobe, Alcatel Lucent, and Zappos use it [7].
4.4
High Level Design
ISIS
System
Spoofed traffic
Internet
Router
Spoofed traffic
ISIS session
ISIS spoofing report
Victim
Legitimate users to spoof
ISIS session
ISIS Storage
ISIS session
Attacker
Figure 3 High Level System Design of ISIS
This section will give a high level overview of ISIS, its components, and its method of blocking
specifically IP spoofing attacks. ISIS is a system that is a combination of IP spoofing defenses, and some
other outside methods to block this type of attack. Figure 3 shows the layout of a network node that
employs ISIS. ISIS would be integrated with the firewall system, which is shown in Figure 3. In Figure 3
we have an attacker who will try and spoof the traffic of the other legitimate users to attack the victim.
ISIS starts sessions with each host in its network, and will analyze the traffic they send, and if any
spoofing is detected it will drop the offending packets. After detecting a repeat offender ISIS will send a
spoofing report to its associated database with the offender’s information. In this scenario it is the job
of ISIS to prevent the spoofed traffic from leaving the firewalled network and into the internet. Figure 4
shows the components of ISIS and their interactions, but it does not show every step taken by ISIS on
traffic analysis. The interactions between components will be discussed in Sections 4.3.3 to 4.3.6.
ISIS System Components
Temporary storage for malicious host tracking
and Blacklist
(Hash table)
ISIS records a malicious host entry if detected
Internal traffic leaving internal
network.
ISIS Application
Scans passing traffic for violations
External network traffic entering
internal network.
Forwarding only
Non-dropped,
Non-spoofed
Packets.
ISIS secure IPSec session
with internal host
Internal network connection
External network connection
Forwarding only non-dropped,
non-spoofed packets.
Egress filter/packet dropping filter
(Firewall settings)
Malicious host record submitted by ISIS
After 3-strike rule has enforced
Ingress filter/ packet dropping filter
(Firewall settings)
Long-term storage solution for malicious host records
(Database)
Figure 4 ISIS system components, and component interactions.
4.4.1
Framework
ISIS combines firewalls, secure IP communication, and a database to form its system. The
premise behind ISIS is to sit at the router/firewall level or even a network node, and filter out IP spoofed
packets within its region of control. By having each firewall/router node control and prevent spoofed
traffic in its own controlled area will make it less likely that spoofed traffic will propagate through the
network. This should lend itself nicely to a distributed or even local network because each ISIS
application runs locally on each network node. ISIS is not intended to be a one man army against
DoS/DDoS attacks, but used in conjunction with other methods of DoS prevention. Since ISIS can be
deployed at many different levels of a network, as long as they are entry/exit points of a network, the
ISIS nodes can all read any information they record. This helps when systems all work together and
collaborate to reduce the chances of misinformation being inserted into the shared database. Another
work dealing with collaboration was done by Intel where they watched the spread of slow propagating
worms, and found that when many systems collaborated their ability to detect was higher than any
single IDs could achieve [15]. Since ISIS can be part of a larger framework of different defenses it can
collaborate by sharing the data it stores with other defense mechanisms and visa versa.
4.4.2
Reasoning for ISIS and Scope
ISIS is designed for many reasons to combat IP spoofing, and this is because most IP spoofing
defenses are built by throwing different methods together. ISIS is designed to be many of those
defenses in one application for ease of use, and consolidation. One problem with most IP spoofing
systems is that it takes a combination of different methods to reduce IP spoofing traffic. Many of these
defenses are sparse, and may take time to configure them to interact well with each other. ISIS aims to
remedy this situation by combining many common defenses together into one easy to use package. This
will help in easing the burden on whoever has to configure the network system. The second problem
that is seen by some of these defensive techniques is that each as a standalone defense has their
deficiencies. ISIS combines these techniques together and leverages their strengths to help cope with
each technique’s weakness as well as extend their functionality. This helps in preventing IP spoofing
traffic by closing some spoofing loopholes by having increased coverage.
ISIS’s core process is to prevent IP spoofing traffic from reaching its target, and although it may
not stop all traffic it will deflect the attack traffic. Many DoS and DDoS attacks rely upon constant
streams of traffic to overwhelm or interrupt a target or its operation. ISIS will help mitigate this problem
by interrupting the attacker’s streams of traffic by blocking any spoofed packets. Since ISIS employs a
multiple strikes before blocking a MAC address this will allow some traffic through, but if an attacker
gets the specified amount of strikes any further traffic is blocked for a specified amount of time. In
order for an attacker to continue sending packets they must wait until the specified amount of time
passes, or configure their system to have a new MAC address. Both of the previously mentioned
methods will interrupt the attacker’s stream of packets thus making their attack less effective or even
invalid.
Since many DoS and DDoS attacks use bot-nets to launch their attacks it is still common that
they use IP spoofing to hide the locations of their zombie hosts [9]. This gives the attacker a way in
which to hide themselves or bot-net from being found. ISIS will actively store any data of marked hosts
in a database for later analysis. This stored data can come from one or more ISIS nodes depending upon
who deployed the ISIS nodes e.g. an ISP. By having the data of what host were sending spoofed traffic,
the MAC and source IP of the spoofing host, when the host was detected sending spoofed traffic, and
which ISIS node it was detected by can hopefully give an ISP or other enforcing agent the capability to
track down the hosts.
ISIS aims to only deal with IP spoofed packets, and the hosts that send them. The scope is
limited to preventing outgoing DoS/DDoS attacks on a host in a public network. ISIS does not stop
attacks on a LAN, but tries to limit ARP/MAC spoofing.
4.4.2.1 ISIS versus UTM
ISIS is designed to be an all-in-one system just like a UTM is, but there are some differences
between the two. A UTM is a hardware based solution to unifying different network defenses, while ISIS
aims to be an all-in-one software solution. This is important because a hardware solution can be costly
to acquire, and may be affordable for only big businesses that can afford it. By implementing software
based solution this opens up the availability of an all-in-one network defense as a lower cost alternative
to a UTM. Another reason that ISIS differs from a UTM is that it is designed solely for IP spoofing
defenses, and can be integrated into an existing system. If a UTM is used then it becomes the entire
defensive system, which means that any other systems/defenses that were setup are now rendered
useless.
4.4.3
Design Principles
ISIS is designed to be a system that is easily configurable, easily updatable, and easily integrated
into existing defensive systems. These principles are enforced to make sure that a modular and
cohesive system is in place. This is because a system that is modular will be easier to expand upon in the
future. Since ISIS is designed to be only one part of a defensive system it needs to be designed such that
it can function independently, or as part of a system. Some examples of these principles are given in
Sections 4.3.4-4.3.7.
4.4.4
ISIS Configuration
ISIS has a configuration setup that will allow the user to change settings used within the ISIS
system. This will is a flat (text) file, isis.conf, which has a specific format to configure ISIS settings.
Settings such as: database storage/user/password to be used, entry retention time, and others are set in
the isis.conf file. See Appendix 8.1 for an example of an isis.conf file.
4.4.5
ISIS Firewall
The firewall that ISIS will employ is to help filter malicious formatted packets, and it will be a
combination of ingress and egress filters as well as packet dropping for the preferred method of
discarding packets. The reason that packets will just be dropped instead of returning a NACK or bad
format response to the sender is so the attacker cannot key off the fact that its packets are being
denied. This will help in hopefully slowing down the response time or time in between attack packets or
even the time between switching the packet’s source IP.
Ingress and egress filtering are used to prevent hosts from inside the firewall to pretend they
are outside of the firewall and vice versa. This is to prevent basic efforts to compromise or masquerade
as a host in a secure area. Recommendations were used form RFC 2827, which is the RFC for
ingress/egress filtering [13], and also some firewall rules were recommended from [14] as well.
ISIS employs iptables as its firewall defense, and this is due to the test system being a
Linux/UNIX based OS. When configuring ISIS’s rules for iptables filtering it actually produces its own
chain for appending rules to. This is to prevent ISIS from cluttering up any existing chains that could be
defined by another system that uses iptables rules. This also makes it easier for ISIS to exit cleanly, so
that way the user does not have to clean up when ISIS is stopped from executing. Some examples of ISIS
firewall rules are given in the base rule set in the Isis.pl file in Appendix 8.3
4.4.6
ISIS Blacklist
ISIS will use a blacklist in its system, but not to blacklist IPs. It will instead blacklist MAC
addresses that have been identified as sending spoofed traffic. The blacklist will be kept relatively fresh
by keeping the records of offenders for a set amount of time, but the records will be archived in the
database for reference.
Two flexible hash tables in memory are used to record both blacklisted MACs as well as MACs
that have sent offending traffic, but have not reached the maximum number of strikes yet. When a
MAC that has sent offending traffic is in the warning list it is not yet blacklisted, but pending further
offenses it will be banned. The warning list will be flushed every time a status update is issued by ISIS.
This is to make sure that the warning list does not grow out of control, and cause a memory issue. Also
the warning list is flushed at every update interval is because if a host does not reach the maximum
number of strikes in that interval then it is safe to clear it out. This assumption was made because
DoS/DDoS attacks rely on consistent traffic to take a host down, and if they do not get blacklisted within
a reasonable window then they are not sending enough traffic to trigger a response.
To find an offender each new host that sends traffic through ISIS will be subjected to a stateful
packet filter. This will in return give ISIS the MAC associated with an IP packet, which ISIS uses to log
data. The data that will be logged is each offending packet, and we can see the different sources IPs
that are associated with a particular MAC address. ISIS will implement a multiple strike rule before
blacklisting a particular MAC address, but it also puts a time limit between MAC and IP source pairings.
This time limit is for mobile networks where the possibility of signal/connection loss can result in having
to request a new source IP in quick succession. This component of ISIS is vulnerable to MAC spoofing,
but section 6.5 will cover possible methods of defense against it since I was unable to implement it.
4.4.7
ISIS IPSec
ISIS will use IPSec for the purpose of preventing MAC spoofing for the blacklisting method used
by ISIS. By using IPSec ISIS will initiate a secure communication channel with each host that sends traffic
through it. This will generate key pairing used to encrypt and decrypt any traffic from each host, and
make it difficult for an attacker to sniff packets for hosts to masquerade as. By doing this even if an
attacker can manually steal a MAC from a host and masquerade as it, but each MAC has an
encryption/decryption key(s) associated with it. Since each MAC will have a key associated with it the
attacker cannot send traffic if they do not possess the proper key(s), which results in ISIS dropping the
packets. Also if an attacker is to send traffic it must register a secure communication channel with ISIS,
which means its MAC is recorded. Since a hosts MAC is recorded, and ISIS keeps track of how many IPs
are associated to a MAC address the attacker is limited to multiple attempts/attacks before they must
change their MAC and re-register with ISIS. Hopefully this time to register and small amount of attacks
will lengthen the time between attacks to lessen network load created from DOS attacks. The reason
for choosing an encryption/decryption key pair communication channel is because it offers
confidentiality, authentication of packet origin, and integrity of the packet. This method is also chosen
because some tests have found that it is one of the better methods of preventing MAC spoofing [9].
One downside to this approach is that it is infeasible to apply encryption to all packets, so it should only
be applied to packets that follow attack formats/patterns. The approach that will be tried is by sending
a challenge to the incoming traffic host, and determining whether to drop/forward a packet upon host’s
challenge answer. This method of a challenge response nonce was not verified, so see Section 6.5 for
details on why.
4.4.8 ISIS Database
The database used by ISIS is for long-term storage of packet data for future analysis by ISPs or IT
security teams. The data that will be recorded will be time, date, MAC address, spoofed IP addresses,
and ISIS node (if applicable). The ISIS node is an optional indicator that can be assigned for each
network NODE where ISIS is running if a multi-layered or DMZed type network structure is deployed.
The database will most likely not be used for short-term storage of MAC and IP pairings, but instead
that section is implemented with a flexible hash table in memory. The database where the spoofed
packet information will be held can be a centralized database or separate databases depending upon
the configuration chosen during setup. The database that is supplied in the isis.conf file will point to the
database that ISIS will store its long-term data to as long as the host that ISIS is deployed on can reach
the database via the network. For ISIS to communicate with the database it needs to be a MySQL
database in this environment. See Section 4.5.2 for basics on setting up this database.
4.4.8.1 Table Structure in ISIS Database
This section describes the table structure used in the database that stores ISIS logs. It consists of
a table of the packet data logged by ISIS. The MAC Address in the Packet Data Table for each unique
packet. This is to allow each Mac address to have all marked packets associated with it, and to simplify
the structure. This structure is designed for ease of use, and to be already sorted. By being already
sorted the analyzer will not have to create complex SQL statements to pull data for a particular MAC
address from the table, and can instead just add a WHERE clause in the SQL statement. This is to
prevent overly complex SQL statements, and overhead of joining many tables. The structure is given in
Figure 5.
Packet number (Primary key)
MAC Address
IP address
Date/Time
ISIS Node
DATA packet
Figure 5: ISIS database table configuration, the Packet Data Table.
4.5
ISIS Setup
This section will discuss the setup of ISIS, the testing infrastructure, and the host machines used in
the testing environment. The testing used 4 types of machines which are described in Sections 4.5.14.5.4. The attack and user stations were set up using minimum requirements, so see the Fedora 15
distribution requirements at fedoraproject.org. The network sniffing machines were created using
BackTrack 5R1 with minimum requirements, so see www.backtrack-linux.org for details.
4.5.1
Attack Machines
The attack machines are two Linux Fedora Core 15 2.6.38.6-26.rc1.fc15.x86_64 machines. They
are installed with a dosscript.pl file I have created, which is included in Appendix 8.2. The machines
were also installed with Nemesis a packet generator script that is utilized by dosscript.pl, and its version
is nemesis-1.4beta3. This script required the installation of an older version of libnet, and its version is
libnet-1.0.2a. Both packages are tar.gz files, which can be found on various repositories on the internet,
but both required a few extra steps to get them installed. Those steps are as follows, and are performed
in the following order:
1. Un-tar libnet tar file “tar –xvf libnet-1.0.2a.tar.gz”
2. Move into libnet directory “cd Libnet-1.0.2a”
3. Run configuration file “./configure”
4. Edit the Makefile “vi Makefile”
5. Change MAN_PREFIX in Makefile to “MAN_PREFIX = /usr/share/doc/”
6. Save and quit editing Makefile
7. Run the make command “make”
8. Run the make install command “make install”
9. Installation of libnet is complete
10. Un-tar nemesis tar file “tar –xvf nemesis-1.4beta3.tar.gz”
11. Move into the nemesis directory “cd nemesis-1.4beta3“
12. Run configuration file “./configure”
13. Edit this file “vi /usr/include/libnet/libnet-headers.h”
14. Find this section of code:
#if (!__GLIBC__)
struct ether_addr
{
u_char ether_addr_octet[6];
};
#endif
15. Comment out the #if and #endif statements, so it looks like this:
//#if (!__GLIBC__)
struct ether_addr
{
u_char ether_addr_octet[6];
};
//#endif
16. Save and quit editing the file
17. Run the make command “make”
18. Run the make install command “make install”
19. Now nemesis is installed on the system.
20. Finally install nmap “yum install nmap”
Now the attacker host is ready to use the dosscript.pl to generate spoofed packets, and attack a
victim host. See the help file for dosscript.pl (dosscript.pl help), and for nemesis (man nemesis) to see
usage of the scripts.
4.5.2
ISIS Machine
The ISIS machine is also a Fedora Core 15 2.6.38.6-26.rc1.fc15.x86_64 machine, but has mysql
installed, Isis.pl, and iptables. See Isis.pl for usage on how to run and use ISIS, and to communicate with
the MySQL database the Isis.pl requires perl-DBD-MySQL package to be installed. This package can be
installed from the command “yum install perl-DBD-MySQL”. This machine hosts the database ISIS, and
functions as the ISIS node. This host is where all traffic will be going through to get to the target host.
No other special configurations required except for the technologies listed in Section 4.3. This setup
assumes you already have setup a mysql database, and have knowledge of how to use one. If not then
see
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch34_:_Basic_MySQL_Config
uration for a handy guide to setting it up.
4.5.3
User Machines
The user machines are just all base configured Fedora 15 machines, and 3 of them were used in
the testing environment. Just like the attacker machines they are Fedora Core 15 2.6.38.626.rc1.fc15.x86_64 machines. No special configuration was required for these machines.
4.5.4 Traffic Sniffing Machines
The traffic sniffing machines are BackTrack 5R1 machines, and were just base installs. They were
used to scan network traffic using Wireshark, and make sure what packets were seen on both sides of
the ISIS firewall. No special configuration was required for these machines.
5
Evaluation and Results
This section will discuss the results of the testing of ISIS, and its components. It will cover the
evaluation mechanisms and their results as well.
5.1
Components
5.1.1
Testing Environment
The testing environment consisted of 8 Virtual Machines (VMs), with one host on a public
network (victim host), one host acting as the gateway (ISIS host), and 6 VMs on an internal private
network. This environment is setup to have two malicious hosts within the internal network send
DoS/DDoS traffic to the host on the public network. While the malicious hosts are sending DoS/DDoS
traffic to the target host the other machines in the internal private network will be sending legitimate
traffic requests to the victim host. One host on the internal private network will monitor the traffic on
the private network using Wireshark to monitor the packets being sent, but during testing it was found
that the internal host does not capture all traffic. The victim host will also be running Wireshark to
capture the packets that get from the internal private network to itself. By comparing the packet
captures from the public network against what ISIS blocks we should see which packets ISIS blocked. By
analyzing which packets ISIS blocked we can determine if it was spoofed or legitimate traffic that got
through.
5.1.1.1 Test Types
The following sub-sections will detail the types of tests performed against ISIS, and their
individual results.
5.1.1.1.1 Improper source IP Test
This test is where the attackers generate packets with source IP addresses that are not within
the private network. The purpose of this test is to make sure ISIS is capable of determining the correct
private network IP addresses it manages.
5.1.1.1.1.1 Results
This test was implemented using ICMP packets, and using source addresses from within the
private network, and randomly generated IP source addresses. ISIS was able to stop 100% of all spoofed
packets with source addresses that were not within the private network from reaching the victim host.
However it was unable to stop any of the spoofed packets using the private network as the source
address from reaching the victim host. This is due to the MAC spoofing mechanism mentioned in
Section 4.4.7 not being implemented. ISIS did mark the offending packets in the random source address
case, but not in the private network source address case.
5.1.1.1.2 TCP Flag Test
This test is where attackers will submit TCP packets with weird flag settings to try and interrupt
TCP flows. This will make sure ISIS is capable of dropping these offending packets, and marking them.
5.1.1.1.2.1 Results
This test was implemented using TCP packets with weird flag settings used in TCP attacks. ISIS
stopped 100% of all flagged TCP packets from reaching the victim host, but these results may have been
skewed due to the bad implementation of TCP in the packet generator that was used.
5.1.1.1.3 ICMP Flood Test
This test is where the attacker will send ICMP packets at a faster rate than 1/second. This will
test if ISIS will rate limit the ICMP packets, and also mark the sender as an offender.
5.1.1.1.3.1 Results
This test was implemented using ICMP flooding from the attacking host to the victim host.
During this test ISIS did mark that the offending packets are exceeding the limit allowed. One issue was
that it only marked the replying host as the offender, so there may have been an issue with the iptables
rules, or even how it logs data at the kernel level. Section 5.1.2 will go over this iptables logging
phenomena.
5.1.1.1.4 TCP Reset Attack
This test is where the attacker will send out TCP packets with reset flags set at a rate faster than
2/second. ISIS should prevent these packets from exceeding 2/second, and mark the sender as an
offender.
5.1.1.1.4.1 Results
Unable to modify TCP packets to send more than 2/second, so could not verify this test. Also
unable to verify due to limited capability of packet generator when producing TCP packets. Although
the packets were malformed ISIS still did mark and block the TCP packets.
5.1.2 ISIS Stateful Packet Filter
The stateful packet filter has been proven to intercept, record, and update the firewall rules
dynamically to adjust for hosts that send offending traffic. Section 5.1.2 will go further into depth about
how the MAC address blocking functionality works. Using the settings pulled from the isis.conf file ISIS
will passively log offending packets, and take action on the logged packets at every update period. This
is one drawback that is discussed in Section 6.3. During every update period ISIS will examine the logged
packets, then update the warning list, and finally take any offenders from the warninglist that have
surpassed the number of strikes then adds them to the blacklist. This blacklist contains both the time
the blacklisting rule was created, and the rule that is applied for this MAC. The time is used to compare
if the time limit for blacklisting has expired for this particular MAC address. The rule used to blacklist
the MAC is kept, so that the same rule is only removed from the iptables. This is to prevent flushing,
and re-creating the entire iptable chain repeatedly. Figure 6 shows the output during an update period
from ISIS.
Figure 6: ISIS update period output.
5.1.2.1 ISIS Results
ISIS is verified by inspecting the packet captures of the private and public networks then comparing
them to verify if it successfully blocked spoofed traffic. Upon inspecting the two packet captures it was
determined that ISIS, and its rules it was found that ISIS blocked most of the spoofed packets. This was
covered in Section 5.1.1. When comparing the packet logging on the ISIS host, and the wireshark
capture on the victim host it was noticed that the two hosts did not have their clocks synched. When
comparing the two capture files the times are approximately 2 hours and 20 minutes apart, so that is
taken into consideration in the analysis. The following sections will discuss the overall impact ISIS had
against spoofed, and the issues seen during the testing.
5.1.2.1.1 ISIS Iptables Logging Phenomena
During the course of the testing it was seen that a logging issue was occurring. The issue was
that the kernel level logging of IP packets was not always recording the MAC addresses from the packet.
This led to some issues when ISIS was running, and trying to setup temporary MAC blocking rules in
iptables. Upon further research it was discovered that this logging issue is not new in iptables. The
solution to correct it would to modify the iptables C functions and code, and then recompile the entire
kernel. Since this is not an easy task I did not research any further into the logging issue.
The other logging issue is that since iptables is divided up into three separate tables for filtering
it does special logging for each. Since each table has its own set of rules it can cause logging to act
differently than expected, and this was discovered after further research. Iptables filtering will not
implement some rules on all filters because they are only applicable to the INPUT/FORWARD tables or
the FORWARD/OUTPUT tables. There are no rules that apply to all the filtering tables at the same time.
This led to some misunderstanding of iptables rules, and may have caused some of the logging issues.
5.1.2.1.2 ICMP Flooding Issue
During the course of the ICMP flooding test it was discovered that ISIS was marking any packets
that exceeded the limit of 1/second as offending, but the offender was instead the victim host. This was
a surprise, and may have been caused by an iptables entry that is not correctly implemented. ISIS is
capable of detecting, limiting, and marking these flood attacks, but some adjustment is needed to
perfect this functionality.
5.1.2.1.3 TCP Packet Generator Issue
While doing the TCP tests it was discovered that the packet generator actually had a bug when
creating TCP packets. The bug is severe enough to cause a core dump, and does generate a mangled
TCP packet. This may have skewed the testing results some, but during the setup of the testing
environment it was the only packet generator I could find and get working. The packet generator is old,
but was still useful in testing ISIS.
5.1.2.1.4 ISIS Overall Evaluation
After all the testing of ISIS I came to the conclusion that despite that ISIS is a proof of concept
system in its infancy it does demonstrate the ability to analyze traffic, capture packets, store packet data
for long-term, and initiate temporary MAC blocking rules with minimal human interaction and setup.
This unified system of IP spoofing defense is easily implemented using only a configuration file, a perl
script, and a database. The only objective ISIS did not achieve is the prevention of MAC spoofing within
the system to improve the IP spoofing prevention functionality, but still has some improvements that
need to be made before it is ready to be implemented on a bigger scale.
5.1.3
MAC Blocking
The MAC blocking is done through rule in an iptables chain. This rule is temporary, and will last
for the blacklist time period that is specified in the isis.conf file. By blacklisting the MAC we can achieve
blocking any packets from an offending host, and thus disabling the IP spoofing DoS/DDoS attack. This
functionality was verified when looking at the public network packet captures, and seeing that a
particular MAC address does not show up for the block time set by ISIS. Figure 7 shows a temporary
MAC rule in the iptables rules.
Figure 7: Temporary MAC rule in iptables.
5.1.4 Database
The database has the table structure given in Figure 5, and follows that structure when inserting
packet data. A single table was chosen because a simple WHERE clause inside of a SELECT statement
can easily narrow down the results returned from the packetdata table. Having a single giant table
helped simplify the database design, and also the unnecessary overhead of JOIN clauses in the SELECT
statements. The only purpose of the database is for long-term storage of packet data for later analysis,
so by correctly storing the packet data it is seen that the database functionality has been verified. Table
1 shows some sample data from the evaluation of ISIS that was captured.
mysql> select * from packetdata;
+--------+----------------+-----------------+---------------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| pktnum | macaddr
| ip
| timestamp
| isisnode | packetinfo
|
+--------+----------------+-----------------+---------------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1 | 00:00:00:00:00:00 | SRC=127.0.0.1 | 2011-10-28 08:52:49 |
1 | Oct 28 08:52:49 isis kernel: [194102.815582] IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=25530 SEQ=447
Oct 28 08:52:49 isis kernel: [194102.8156 |
| 2 |00: 00:00:00:00:00 | SRC=127.0.0.1 | 2011-10-28 08:57:20 |
1 | Oct 28 08:57:20 isis kernel: [194373.401574] IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=25530 SEQ=718
Oct 28 08:57:20 isis kernel: [194373.4016 |
| 3 |00: 50:56:aa:00:23 | SRC=0.0.0.0 | 2011-10-28 08:57:42 |
1 | Oct 28 08:57:42 isis kernel: [194394.775084] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:aa:00:23:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Oct 28 08:57:50 isis kernel: [194402.763088] I |
| 4 |00: 50:56:aa:00:26 | SRC=192.168.1.3 | 2011-10-28 08:58:51 |
1 | Oct 28 08:58:51 isis kernel: [194463.820853] IN=eth1 OUT= MAC=00:50:56:aa:00:42:00:50:56:aa:00:26:08:00
SRC=192.168.1.3 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=5357 SEQ=1
Oct 28 08:58:52 isis kernel: [194464.8 |
| 5 |00: 00:00:00:00:00 | SRC=127.0.0.1 | 2011-10-28 08:58:53 |
1 | Oct 28 08:58:53 isis kernel: [194466.259527] IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=25530 SEQ=811
Oct 28 08:58:53 isis kernel: [194466.2595 |
| 6 |00: 50:56:aa:00:24 | SRC=0.0.0.0 | 2011-10-28 08:58:55 |
1 | Oct 28 08:58:55 isis kernel: [194467.685992] IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:aa:00:24:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Oct 28 08:59:01 isis kernel: [194473.620165] I |
+--------+----------------+-----------------+---------------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
6 rows in set (0.00 sec)
Table 1: Sample packet data stored by ISIS in the database.
6
Future Improvements
Due to some limitations encountered during setup and testing as well as other methodologies there
are improvements that can be made to ISIS. The following sections will cover what changes and/or
improvements ISIS could have.
6.1
Testing
In testing ISIS it is imperative that IP spoofing DoS/DDoS attacks are interrupted, and recorded
since that is the main goal of ISIS. One improvement that could have been made in the testing of ISIS is
the number of different types of IP spoofed Dos/DDoS attacks that could have been launched. Due to
time and size constraints some attacks were not feasible. This could be remedied by changing the setup
of the test, but details surrounding that are given in Section 6.2.
One example of a test setup change would be not using BT as the target hosts’s OS because BT
has many settings made to it, so that way it is undetectable on a network, if desired, and also rejects
many types of traffic. Some of the traffic rejected is telnet/ssh sessions, ftp/sftp sessions, and any
variant that relies on the previous protocols. This limited the types of attacks that could be employed,
and tested.
Another issue in testing was that the packet generator I found was rather old, and not
completely functional. This also was a source of limited testing of DoS/DDoS attacks. Since it is hard to
legally find hacking software this issue is hard to overcome without special permission, or special
resources. BT is mainly used as a penetration testing platform, and not a DoS/DDoS creating/launching
platform.
6.2
Setup
The biggest issue with setup came from the configuration of test machines, and the test
environment. The problem with the test environment is that some settings were not configured
properly, which lead to the final verification having to be done on a small scale. The environment
consisted of 8 VMs was setup by a local IT department then configured by me. In dealing with the setup
and configuration of the network many obstacles were faced and had to be overcome. Some of the
obstacles were due to VMs that were not configured properly, VM resources not requested properly,
VMs not being on the same network host, and network maintenance issues. The issues were mostly
caused by factors that neither me nor the It department could prevent, but the others were caused
mostly by miscommunication between both parties.
Due to the setup issues the final verification of some functionality was limited in scope, and size.
This leads to pointing out that the setup is small and could be improved upon in a future test. It may be
worth noting that something like Amazon EC2 or another cloud service could have been used, but this
does not fit well with the testing scenario planned for ISIS. The reason why the testing scenario would
not work is due to the fact that Amazon strictly polices activity in their cloud environment, and sets
limits on the type/amount of traffic that can be sent. Since the ISIS test amounts to a DoS/DDoS attack
this could cause some serious issues, and trigger Amazon to disconnect or shutdown my testing
environment.
6.3
Design
The biggest design issue I found when implementing ISIS is the language I chose to write its
functionality in. I chose the Perl language for some of its capabilities, and cross-platform stability. Since
I implemented and designed ISIS on a Linux distribution it could have been coded in shell script or even
converted into a Daemon (system process).
When coding in Perl I found a few adjustments that could be made to make it more non-intrusive,
and more passive. Although ISIS is designed to be passive I noticed there are a few times where having
a command line interface would be handy. This is not necessarily the best option, but also giving it the
ability to have a command line driven interface for users who wish to be more involved. The command
line interface would be useful because the user could access the commands ISIS uses in a more direct
fashion instead of having to run the program again with different options. The best example of this is
when ISIS is stopped, and the user needs to re-run the program with the cleanup option to clear out the
changes that ISIS made on the system.
Another Design improvement could be porting the code from Perl into a Daemon, so that way the
passive management of resources, tracking lists, et cetera could be handled by the OS itself. This would
leave any burden of resource management to the OS instead of having to code it into the script. Also
this allows a more time-sensitive update as opposed to waiting every update period to take action.
6.4
Integration/Setup Issues
While integrating ISIS into an existing system I found it to be a mostly painless effort, but I did
notice a few steps that could have been made easier. Since Perl was my language of choice it was easy
to integrate because most standard Linux/Unix distributions come with Perl already installed. The major
issue I had was trying to get the packet generator scripts installed. This was due to the fact that I was
unable to find any really up to date versions of common packet generators. I had to dig through
numerous sites, redirects, and old libraries to find the proper packages to install and setup. Section 4.4
talked about these difficulties, and this is where a lot of improvements could be made to simplify this
process.
The only other improvement in the integration section would be to install ISIS on an existing system
not configured with ISIS to see how it would interact with the host system or include an ISIS configured
host(s) into a network with many exit/entry points. By doing this we could better observe the behavior
between ISIS and non-ISIS systems. This could help open up more possibilities for improvement or even
verify ISIS’s functionality.
6.5
Unverified Functionality
One function that was not verified within ISIS was a challenge response that was going to be issued
by IPSec. The original reason for this challenge response was to prevent MAC address spoofing by using
a nonce encrypted with a session key. This would only be able to be answered by the legitimate host,
and not by a spoofed host. While trying to implement it I came across an issue where this could be
circumvented by just re-directing the challenge to the original host intercept the reply, and forward it
back to the ISIS host e.g. A Man-In-The-Middle (MITM) attack. Since my method had a MITM weakness I
decided against trying to implement it. So in order to prevent MAC spoofing I researched a few other
ways that could be integrated into ISIS.
One is static ARP entries within a network, but this would only work for networks with small
numbers of hosts. This is due to the fact that updating the ARP entries would be a daunting task if a
huge number of hosts are on a network, and that it is a manual process.
The next method would be using VLANs which are good at preventing MAC spoofing because each
VLAN area has hosts associated with it, so MAC addresses of hosts can be grouped together. This would
allow easier tracing of source MACs, and help prevent snooping of local broadcast domains. The only
downside of this is that it is also a manual process, so it would have to be setup before ISIS is installed.
Another method is trying to use iptables counterpart arptables, and see what possible types of
prevention can be done from there. This would be another stateful packet filter, but it only focuses on
MAC addresses. Just like how iptables functionality was automated it is also possible for arptables
functionality to be automated.
7
References
[1] CISCO IP spoofing overview 2011
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-4/104_ipspoofing.html
[2] Ingress Filtering 2011
http://en.wikipedia.org/wiki/Ingress_filtering
[3] Egress filtering 2011
http://en.wikipedia.org/wiki/Egress_filtering
[4] 1 2 3 Networks, Network Diagram 2011
http://www.123networks.com/network_setup.html
[5] IP Chains How-to 2011
http://tldp.org/HOWTO/IPCHAINS-HOWTO-1.html
[6] IPSec 2011
http://en.wikipedia.org/wiki/Ipsec
[7] MYSQL 2011
http://www.mysql.com/
[8] Mirkovic, J., N. Jevtic and P. Reiher, “A Practical IP Spoofing Defense Through Route-Based
Filtering.” University of Delaware CIS Department Technical Report CIS-TR-2006-332.
[9] Ehrenkranz, T. and Li, J. 2009. “On the state of IP spoofing defense.” ACM Trans. Internet
Technol. 9, 2, Article 6 (May 2009), 29 pages. DOI = 10.1145/1516539.1516541
http://doi.acm.org/10.1145/1516539.1516541
[10] Zhenhai Duan, Xin Yuan, Jaideep Chandrashekar, “Controlling IP Spoofing through Interdomain
Packet Filters,” IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1,
JANUARY-MARCH 2008.
[11] Firewalls
http://www.vicomsoft.com/learning-center/firewalls/
[12] Are two firewalls better than one?
http://www.bestinternetsecurity.net/53/are-two-firewalls-better-than-one.html
[13]“RFC 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source
Address Spoofing” P. Ferguson, Cisco Systems, Inc.; D. Senie, Amaranth Networks Inc. May 2000
https://www1.ietf.org/rfc/rfc2827.txt
[14]Linux Home Networking Linux Firewalls Using IPtables
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewal
ls_Using_iptables
[15]Agosta, J.M.; Chandrashekar, J.; Dash, D.H.; Dave, M.; Durham, D.; Khosravi, H.; Li, H.; Purcell, S.;
Rungta, S.; Sahita, R.; Savagaonkar, U.; Schooler, E. "Towards Autonomic Enterprise Security:
Self-Defending Platforms, Distributed Detection, and Adaptive Feedback." Intel Technology
Journal. http://www.intel.com/technoloyg/itj/2006/v10i4/4-security/
1-abstract.htm (November 2006).
[16] Snort, www.snort.org
8
Appendices
8.1 Isis.conf
An example of an isis.conf configuration file
# This is the isis configuration file that will help isis
# determine its behavior in response to certain triggers.
# This file contains information that the user can specify
# to customize isis to their needs.
# Isis node number if multiple ISIS hosts exist, default 1
IsisNode:1
# The internal network facing ethernet device.
InternalNetDevice:eth1
# The external network facing ethernet device.
ExternalNetDevice:eth0
# The internal network to ensure proper ingress/egress
#filtering on.
InternalNetwork:192.168.1.0/24
# The time, in seconds, to keep a blacklisted MAC address
# from sending traffic.
BlacklistTime:360
# If a MAC address has been marked as sending an offending
# packet, but has not reached the blacklist limit. Then
# after the time between status updates time it will be removed
# from the marked MAC list. Must be a factor of BlacklistTime.
StatusInterval:30
# The number of times a MAC address sends offending packets
# before it gets blacklisted.
NumStrikes:3
# Flag to determine whether or not to use a database for long
# term sotrage. Is either TRUE or FALSE.
UseDatabase:TRUE
# The database that isis will use to store network information.
# If not provided then isis will not store network data for
# long-term analysis.
Database:isis:localhost:1186
#Database:
# Database user
DbUser:isis
# Database password
DbPass:osiris