INCIDENCE RESPONSE NOVEL APPROACH TO SECURITY

Formulating an incidence response plan, methodology and responding to incidents based on Technical criteria

ABSTRACT

This paper proposes a hybrid honeypot implementation that can be used in an organisation providing e-commerce to customers worldwide. A fictitious organisation called Kor-Tech is used as a case study. The architecture is such that low interaction honeypots are installed in different subnets of the network system which further communicates with high interaction honeypot through the use of a honeywall. Logging of intruder activity is possible through the use of an Intrusion Detection System (IDS) and the paper focuses on the technical analysis of this implementation as compared to conventional systems where only a single honeypot system is used (either low or high interaction) based on technical criteria.

Introduction

Kor-Tech Industries is a world renowned electronic company with major competitors like Sony and Panasonic. The organisation is involved in a lot of research into future technologies for its electronic products like Plasma televisions and 4G mobile phones and also provides online purchase services for its customers. The need for a totally secured network architecture that can mitigate attacks is relevant for the company to keep providing services to customers and remain in business.

Kor-Tech is vulnerable to threats from the Internet, such threats can include:-

• Network attacks:- Internet worms, Denial of service
• Application attacks:- SQL injection attack, malware
• Intellectual property infringement:- technology theft, patent, copyright
• Physical attack:- vandalism, sabotage
• Social engineering

The basic solution for detecting attacks is to configure an IDS (Intrusion detection System) that will trigger alerts when there is likelihood of a threat; it can be used to monitor network traffic, thereby detecting if a system is being targeted (Artail et al 2006). However, IDS adopts centralised protection where a single system monitors traffic flow; this leads to a single point of failure. An intruder who gains access to the centralised IDS system can control the entire network. This limitation led to the evolution of distributed IDS (Artail et al 2006) which decentralised monitoring activity, making for robustness. However, IDS systems in general have the limitation of false positives or noise which leads to more consumption of logging resources as well as greater analysis time. One way to get early warnings of new vulnerabilities is to monitor computer systems on a network that we expect to be broken into through the use of a honeypot.

The solution of using a honeypot is better for many reasons; false positives are reduced thus implying better management of logging system resources, they can handle IP traffic such as IPV6, which is not always recognised by IDSs and they have the ability to accumulate and aggregate information for on-going attacks in a much simpler way than an IDS can (Forte 2009).

A honeypot is a closely monitored network decoy serving several purposes: it can distract adversaries from more valuable machines on a network, provide early warnings about new attack and exploitation trends, or allow in-depth examination of adversaries during and after exploitation (Provos, 2003). It is a security resource whose value lies in being probed, attacked or compromised (Spitzner, 2002). It is not the solution but a tool used to welcome attacks. There are basically two types of honeypots, production and research honeypots (Artail et al, 2006). Production honeypots are used in organisations to mitigate attacks and vulnerabilities on the network, while research honeypots only seek to gain knowledge of the hackers’ community (Artail et al, 2006). The information gathered can be used in developing antivirus applications and creating security policies.

Another way of classifying honeypots is based on the level of interaction. These include, low interaction and High interaction honeypots.

Low-interaction Honeypot & High-interaction Honeypot

Low-interaction honeypots only simulate/emulate some services like UNIX telnet service or Micrsoft IIS (Piller and Wolfgarten, 2004). Installed tools are used to emulate operating systems and services which then interact with the attackers and malicious code. This kind of honeypot has a small chance of being compromised and is ideal for production networks, when there are no available personnel to administer a honeynet or when the risk of a high-interaction honeypot is not acceptable. Typical use of low-interaction honeypots include: port scan identification, generation of attack signatures, trend analysis and malware collection (Antonio et al 2007). Examples include Specter, Honeyd and KFSensor.

High interaction honeypots on the other hand provide a platform for interaction by the attacker with the real operating system where there is no emulation or restriction. This provides a vast amount of information about the attacker’s modus operandi, tools and level of knowledge (Piller and Wolfgarten, 2004). A comparison of the features of both low and high-interaction honeypots is shown in the table below:-

Table I: Comparison of Low & High-interaction honeypots

According to Piller and Wolfgarten (2004),a low interaction honeypot has the advantage of simplicity in installation, maintenance and the risk involved is minimal. This further dictates lower cost and limited logging activity. For a large organisation like Kor-Tech, the priority is not cost or maintenance, but security. Because such a large organisation is liable to diverse threats of different signatures, a robust detection system needs to be put in place to handle such vulnerabilities and help develop policy for new threats. Therefore a low-interaction honeypot will not be recommended as the best and only security implementation.

High interaction honeypots are able to capture worm payloads or real attacker activity because the level of interaction is robust. Furthermore, exertion of control on the attacker, thereby learning what happens after they gain access is possible. Apart from the fact that there is greater risk due to higher interaction and logging activity is much better, the cost of deployment and maintenance is also weighty. Deployment might involve multiple points of installations thus indicating that money will be invested in memory capacity, large hard disk storage and human labour expertise.

The arguments stated shows that it will be irrational to have security totally dependent on either low-interaction or high-interaction honeypots. Considering the requirements of a large organisation like Kor-Tech with many branches and sub-branches with each requiring security features, total dependence on either low or high interaction honeypot is not ideal. A better approach can be developed that will cover the basic requirements and balance the trade-off between simplicity and robustness.

Proposed hybrid honeypot implementation

The proposed system as described by Artail et al (2006) is “an adaptable honeypot-based intrusion detection system that adjusts to changes in the organizational network based on the dynamic deployment and configuration of low-interaction honeypots (honeyd).” It is termed hybrid because the architecture uses both low and high-interaction honeypots, such that traffic directed to a honeyd is forwarded to a real systems for interaction (honeynet).

Figure II: Proposed system architecture (Artail et al. 2006, pg: 5)

The honeynet comprises three different PCs based on different Operating Systems (OS) so that there is proper load-balancing and also for specific monitoring based on the attacker’s operating system. The honeyd server emulates different systems based on unused IP addresses in the IP address block. Therefore more unused IP addresses imply greater probability of involving an attacker since more virtual systems will be available.

The honeywall bridges the honeyd network and the honeynet. It uses an IDS tool (Snort) to monitor traffic and detect attack signatures.

The honeyd server is configured with multithreaded ability to scan the attacking system using Nmap and gather information like the OS type, open ports etc. One thread stores the information in a database and yet another does the redirection of traffic to the honeynet.

The production systems are placed on a different subnet not visible to the intruder and safe from attack.

Honeypot analysis

Based on technical criteria

From a technical perspective, analysing the features of hybrid honeypot with respect to the requirements of Kor-Tech can be done with the following parameters:-

• Architecture (Centralised or distributed).
• Type (Host, Network, anomaly, signature, reactive, proactive based).
• Properties (Low false positives, scalability, re-configurability, load balancing, intelligence, platform independence).
• Features (Avoiding attacks, eluding intruders, real time etc.).

Low-interaction honeypots like honeyd adopt a centralised kind of protection for a single system at a time. However a more robust protection scheme is needed for protecting the systems in the network of Kor-Tech; therefore a distributed architecture will serve better. This is because large organisations that provide Internet services like Kor-Tech, Google, eBay or Amazon have a network of servers necessary for a fail-over architecture. The hybrid honeypot adopts a distributed architecture such that the entire system composition is shared between the systems in the network. Load balancing, upgrades and troubleshooting will be easily implemented with this architecture.

More so, the type of architecture adopted can also be a major concern. A typical IDS system is good for network-based type of architecture. Honeypots generally (either low or high) according to Higgins (2008) are basically network based; they are placed in front of the firewall in the DMZ (Demilitarized zone). The hybrid honeypot fulfils the criteria of being network based and is also signature-based; because certain kind of known signatures of attacks can be embedded into the honeypot for robustness. Snort as an Intrusion detection System is used and certain attack traffic like DOS (Denial of service) attacks can be programmed into its detection database.

The process of forwarding suspicious traffic once detected to a real system makes it proactive and reactive because warning messages are displayed and data logs are kept.

Similar to low-interaction honeypots, the hybrid implementation will have few false-positives and be scalable. This is because the design is such that each of the low-interaction honeypots forward traffic to a central location. This makes for proper load-balancing, which is lacking in either a single low-interaction or high-interaction honeypot implementation system. In terms of scalability, more honeyd’s can be added to the system to increase the level of protection as the probability is intercepting an attacker increases.

Based on re-configurability, the system readjusts the distribution of operating systems and services that the honeyd emulate so as to reflect the current mix in the production network (Artail et al 2006).

Any operating system can be used for the honeyd server implementation, making it platform independent. Snort is also platform independent as it can be used on both Linux and windows system. The most unique feature of this system is that it diverts malicious traffic from the production hosts to the honeynet for the attacker to properly interact with the system, thus tricking the intruder into thinking that they are interacting with a production host; this avoids attacks and eludes intruders.

Other types of honeypots have to collect data and perform correlations, computations, and analysis before making judgments about the user’s activity. But the hybrid system is very fast in identifying intruders due to the fact that any attempted interaction with the honeyd is suspicious and takes immediate actions. It therefore meets the requirement of eluding attackers and is real-time.

Based on types of likely attack

A common attack the Kor-Tech network is liable to is Denial of Service (DoS) or Distributed DoS (DDoS). A denial of service (DoS) attack is commonly characterised as an incident in which a user or organisation is deprived of the service of a resource they would normally expect to have. Typically, the loss of service is the inability of a particular network service, such as e-mail, to be available or the temporary loss of all network connectivity and services (Weiler 2002). In this case, Kor-Tech runs a website where thousands of customers perform online transactions; therefore a DOS attack can take Kor-Tech out of service. Stein (2002) defines a Distributed DoS attack as one that uses many computers to launch a coordinated attack against one or more targets. Both DoS and distributed DoS have similar characteristics of preventing legitimate users from accessing network resources by flooding the network with useless traffic. Such attacks are done by exploiting software bugs like in Microsoft Internet Information Server (IIS), ICMP_ECHO_REQUEST packets from spoofed IP addresses which causes congestion (also called smurf DOS).

The hybrid honeypot can be used to detect DOS attacks based on known signature patterns. A typical DOS pattern is shown below:-

Figure III: DOS pattern (Weiler 2002)

Based on a known attack signature, the IDS tool snort can be used in detecting an attack. According to Dietrich (2000) a typical implementation rule using snort to detect DDoS attack is shown below:-

alert tcp $HOME_NET 20432 -> $EXTERNAL_NET any (msg:”DDOS shaft client login to handler”; flow:from_server,established; content:”login|3A|”; reference:arachnids,254; reference:url,security.royans.net/info/posts/bugtraq_ddos3.shtml; classtype:attempted-dos; sid:230; rev:3;)

alert udp $EXTERNAL_NET any -> $HOME_NET 18753 (msg:”DDOS shaft handler to agent”; content:”alive tijgu”; reference:arachnids,255; classtype:attempted-dos; sid:239; rev:4;)

alert udp $EXTERNAL_NET any -> $HOME_NET 20433 (msg:”DDOS shaft agent to handler”; content:”alive”; reference:arachnids,256; classtype:attempted-dos; sid:240; rev:5;)

alert tcp $HOME_NET any <> $EXTERNAL_NET any (msg:”DDOS shaft synflood”; flow:stateless; flags:S,12; seq:674711609; reference:arachnids,253; reference:cve,2000-0138; classtype:attempted-dos; sid:241; rev:6;)

Considering the shaft distributed denial of service tool, the rules listed above will alert if there is a distributed DOS attack. The attacker uses a telnet program from the client to access a handler. The handler then automates the activities of an agent system to perform the attack. Thus the rule must cover the process of the shaft getting to the handler, handler to the agent and then flooding the system. TCP protocol is used for telnet to the client while UDP for agent to handler and vice versa communication.

More to that, the hybrid honeypot traps the intruder and records the compromise. These records help in taking legal action against the attacker (Weiler 2002) and in the process learn the methods, tactics and motives of the hacker and plan for zero day attacks with unknown signatures.

Riden (2006) argues that attacks from botnets can be reasonably logged using the snort IDS. Thus Kor-Tech intrusion detection team can work towards further mitigating attacks based on the information gathered from log files.

A worm is a self-replicating program (Panko 2004) and can be marshalled on the internet to take control of servers. The hybrid honeypot can be used to detect and mitigate the propagation of worms in a network as shown in the graph below:-

Figure IV: Impact of honeypots on worm propagation (Provos 2003, p.10)

Provos (2003) proposes the implementation of a hybrid system in detection of worms where network worm traffic is detected, compared with known signatures and blocked if malicious. The impact of this implementation is shown in the figure above where the propagating impact of the worm is curtailed with the inclusion of the hybrid honeypot.

This method is also used to understand how spammers operate and identify new spam (Provos 2003, p11), by utilising honeyd’s GRE tunnelling capabilities and emulating open proxy and open relay services which spammers typically use in forwarding mails. A typical implementation as explained by Antonio et al (2007) is shown below.

Figure V: Honeypot-based spam control

A spammer will try to use one of the honeypots emulating the services of an open proxy to send emails believing that they are genuine. Analysis can then be carried out on the spammer’s modus operandi.

CONCLUSION & FUTURE WORK

Low-interaction honeypot like honeyd is implemented on UNIX systems, and the irony lies in the fact that Microsoft Windows is liable to most attacks, not UNIX. A necessary implementation of using honeyd honeypot on Windows-based systems will be necessary.

Wireless honeypot for monitoring and detection attacks are also needed in today’s mobile and internet-wide environment. Wireless hotspots are located in office environments and universities, making them vulnerable and free for all kinds of intruders to exploit. Unlike internet-based honeypots, an attacker detected on a wireless honeypot will surely be a short distance from the antennas and so can be easily captured by the use of CCTV cameras or a good surveillance system (Piller and Wolfgarten, 2004).

A search-engine honeypot to seize attackers using a search engine like Google can be built and can be further used for stopping specific hacking techniques. Other attacks like social engineering can be addressed by training workers and implementing policies necessary to prevent such attacks.

The hybrid honeypot proposed will serve the organisational requirements of Kor-Tech as compared to just having an Intrusion Detection System or an incidence response technical team. With the coming of the IPv6 evolution, honeypots will still find relevance in today’s fast growing network and in the future. Improvements will be necessary by ensuring a robust database of possible attack signatures is available in the Intrusion Detection System and also that the honeyds installed at various points of the network or subnets do not constitute a bottleneck for legitimate users to have delays in accessing network resources.

REFERENCES

• Artail H., Safab H., Sraja M., Kuwatlya I., Al-Masri Z. (2006) A hybrid honeypot framework for improving intrusion detection systems in protecting organizational networks. Computers & Security. [online]. Volume 25(Issue 4), pp. 237-314, Available from: http://www.sciencedirect.com/science?_ob=ArticleURL&_udi =B6V8G-4JWMT1B-3&_user=10&_coverDate=06% 2F30%2F2006&_rdoc=7&_fmt =high&_orig=browse&_origin =browse&_zone=rslt_list_item&_srch=doc-nfo%28%23toc%235870%232006%23999749995 %23625635%23FLA%23display%23Volume%29&_cdi=5870&_sort=d&_docanchor=&_ct=10&_acct= C0000502 21&_version=1&_urlVersion=0&_userid=10&md5=b2d09e7702d217d 845d72f8e539db090&searchtype=a [Accessed 29^th April 2011].
• Dietrich S., Dittrich D., Long N.(2000) An analysis of the “Shaft” distributed denial of service tool. [online]. Available from: http://home.adelphi.edu/~spock/shaft_analysis.txt [Accessed 8^th May 2011].
• Forte D. (2009) Honeynets and Honeypots: Part 1: DeployingHoneypots: Project background and implications[online]. pp 1, 2. Available from: http://infolib.hua.edu.vn/Fulltext/ChuyenDe2009/CD119/22.pdf. [Accessed 29^th April 2011].
• Antonio M., Jessen S.K, Vijaykumar N.L,(2007) Using Low-Interaction Honeypots to Study the Abuse of Open Proxies to Send Spam. [online]. Scirus. Available from: http://www.scirus.com/srsapp/search?q=Using+Low-Interaction+Honeypots+to+ Study +the+Abuse+of+Open+Proxies+to+Send+Spam&t=all&sort=0&g=s [Accessed 8^th May 2011].
• Panko R.R (2004) Corporate Computer and Network Security. Intl edn. New Jersey: Pearson Education Ltd.
• Piller K. WolfgartenS. (2004) Honeypot forensics -No stone unturned or logs, what logs?[online] Available from: ://www.honeypots.net/honeypots/links. [Accessed 30^th April 2011].
• Provos N. (2003) A virtual honeypot Framework. [online] Available from: http://www.honeypots.net/honeypots/links. [Accessed 29^th April 2011].
• Riden J. (2006) Detecting Botnets Using a Low Interaction Honeypot. [online]. Infosec Writers Text Library. Available from: http://www.infosecwriters.com/texts.php?op=display&id=416 [Accessed 8^th May 2011].
• Spitzner L. (2002) Honeypots: tracking hackers. Addison-Wesley.
• Stein L. D. & Stewart J. N. (2002) The World Wide Web Security FAQ : Securing against Denial of Service attacks. [online]. Available from: http://www.w3.org/Security/Faq/wwwsf6.html. [Accessed 6^th May 2011].
• Weiler N. (2002) Honeypots for Distributed Denial of Service Attacks. Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02)[online]. Available from: http://www.honeypots.net/honeypots/links [Accessed 29^th April 2011].