30-08-2013, 01:27 PM
Intrusion Detection System Using Advanced Honeypots
Intrusion Detection System.doc (Size: 327 KB / Downloads: 16)
ABSTRACT:
As the number and size of the Network and Internet traffic increase and the need for the intrusion detection grows in step to reduce the overhead required for the intrusion detection and diagnosis, it has made public servers increasingly vulnerable to unauthorized accesses and incursion of intrusions. Hence implementation of an Intrusion Detection System (IDS) distinguishes between the traffic coming from clients and the traffic originated from the attackers, in an attempt to simultaneously mitigate the problems of throughput, latency and security of the network. We then present the results of a series of load and response time in the terms of performance and scalability tests, and suggest a number of potential uses for such a system. The main problem with current intrusion detection systems is high rate of false alarms. Use of honeypots provides effective solution to increase the security and reliability of the network.
INTRODUCTION
We present the design and implementation of a load balancer that distinguishes between the traffic coming from clients and the traffic originated from the attackers. This system is an attempt to simultaneously solve the problems of load balancing and unauthorized intrusion. If, in the process of forwarding requests, the balancer detects traffic as an attack on the server, it is then directed to an alternative server - a type of honeypot. Conventional detection and forensics methodology can then be used to gather information on the intruder who will be unaware that they are not using a “real” server. Thus, the system will not only protect mission critical servers from unauthorized access in a manner transparent to the user, but allow for detailed data to be collected, which can later be used to take appropriate legal action against the incursion of intruders.
NETWORK INTRUSION DETECTION SYSTEMS (NIDS)
Recent years have seen a drastic increase in the popularity of Network Intrusion Detection systems (NIDS). Intrusion Detection Systems (IDS) can be classified into two categories: Network-based Intrusion Detection Systems (NIDS) and Host-based Intrusion Detection Systems (HIDS). Existing products have substantial network monitoring capacity, and have been largely successful at providing accurate reports on unauthorized activity. While these products have gotten fairly good at monitoring and reporting on unusual activity, it has been stated, that the biggest problem with IDS is “intelligently reacting to their output”. If an IDS detects an attack in progress, what action should be taken?
BACKGROUND ON HONEYPOTS
A honeypot is “an information system resource whose value lies in unauthorized or illicit use of that resource”. A Honeypot is defined as “being a security resource whose value lies in being probed or compromised". They can be either host and/or network based, but are more often than not network based as all interaction is typically performed over a network connection. A honeypot's main utility comes from the fact that it simplifies the Intrusion Detection problem of separating “anomalous" from “normal" by having no legitimate purpose, thus any activity on a Honeypot can be immediately defined as anomalous.
The characteristics of Honeypots make them well suited to the monitoring of malcious activity on networks, as well as being a valuable research tool in Computer Security. Honeypot concepts are not particularly new; they can be traced back to early Computer Security papers such as Cliaord Stoll's Stalking the Wily Hacker. However the study of Honeypots has recently been formalized. With this formalization has come a focus on research of attackers' methods and motivations which has led to Honeypots being instrumental in the discovery of new security vulnerabilities.
INTRUSION DETECTION
Internally, the implementation of the IDS portion of Secure Direct is very simple. The IDS process runs as a concurrent TCP server, and listens for client requests on a specified port. When a connection is made, the IDS fork a child process when receives the content of the packet, and then checks it against a database of known attacks. It then returns the result of this check to the load balancer process, which makes the decision on whether to forward the request to the production server cluster, or the Honeypot.
CONCLUSIONS:
In this work, we have described some of the previous efforts to measure IDS, and we have outlined some of the difficulties that have been encountered. We believe that a periodic, comprehensive evaluation of IDSs could be valuable for network managers, information security officers and data managers. However, because both normal and attack traffic are so variable from site to site, and because normal and attack traffic evolve over time.
Solving the problem of high availability and security simultaneously offers the opportunity for more reliability than systems which solve the problems separately, in addition to being easier to implement, and offering increased opportunity for recording and data analysis. The integration of these two technologies, however, is a non-trivial task. A fine balance must be achieved between speed and robustness of IDS features – it is equally bad to have the web server crash because an attack was missed, or drop large amounts of traffic due to an overly through IDS becoming a bottleneck.