ISIS - IP Spoofing Interruption System

Masters Project ReportbyDerrick EricksonUniversity of Colorado at Colorado SpringsColorado Springs, COderickso@uccs.edu

1 OverviewThis section will give a brief overview of ISIS, which includes the problem, my proposed solution,

and the reasoning behind it.

1.1 The ProblemThe 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 ModelThe 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 ISIS

1.2.1 Reason for ISISISIS 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 SolutionThe 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 ResearchThis 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 ResearchOverview- 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 DefensesThis 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 DefensesThere are many different methods of defense to use when dealing with IP spoofed packets in a

network.

3.1.1 BlacklistingOverview- 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 FilteringOverview- 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 IngressOverview- 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 EgressOverview- 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 DroppingOverview- 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 SystemWith 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 OverviewISIS 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 AssumptionsISIS 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 FirewallFor 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/IPtablesIPchains 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 IPSecIPSec 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 DatabaseMYSQL 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

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.

Figure 4 ISIS system components, and component interactions.

4.4.1 FrameworkISIS 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 ScopeISIS 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 UTMISIS 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 PrinciplesISIS 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 ConfigurationISIS 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 FirewallThe 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 BlacklistISIS 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 IPSecISIS 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 DatabaseThe 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 DatabaseThis 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.

Figure 5: ISIS database table configuration, the Packet Data Table.

4.5 ISIS SetupThis 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.1-4.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.

Packet number (Primary key)MAC AddressIP addressDate/TimeISIS Node DATA packet

4.5.1 Attack MachinesThe 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 MachineThe 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_Configuration for a handy guide to setting it up.

4.5.3 User MachinesThe 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.6-26.rc1.fc15.x86_64 machines. No special configuration was required for these machines.

4.5.4 Traffic Sniffing MachinesThe 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 ResultsThis 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 EnvironmentThe 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 TypesThe following sub-sections will detail the types of tests performed against ISIS, and their

individual results.

5.1.1.1.1 Improper source IP TestThis 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 ResultsThis 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 TestThis 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 ResultsThis 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 TestThis 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 ResultsThis 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 AttackThis 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 ResultsUnable 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 FilterThe 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 ResultsISIS 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 PhenomenaDuring 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 IssueDuring 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 IssueWhile 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 EvaluationAfter 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 BlockingThe 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 DatabaseThe 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 ImprovementsDue 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 DesignThe 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 IssuesWhile 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 FunctionalityOne 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_ip-spoofing.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 IPtableshttp://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_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.confAn 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 1IsisNode: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 passwordDbPass:osiris