Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Computer Science Clay
Active In SP

Posts: 712
Joined: Jan 2009
14-06-2009, 09:10 AM

A Seminar Report On
Submitted by : AJMAL A A

This seminar and presentation report describes how you can protect your system from Intrusion, which is the method of Intrusion prevention and Intrusion detection. The underlying premise of our Intrusion detection system is to describe attack as instance of ontology and its first need is to detect the attack. Fuzzy clustering is one of the techniques of I.D. This model has two phases. First phase uses data mining technique to analyze low-level data string that capture process, system and network states and to detect anomalous behavior. Second phase reasons over instances of anomalous behavior specified according to out ontology. Integrated service checker is another method of network I.D.
Intrusion detection is very important aspects of protecting the cyber infrastructure from terrorist attack or from hackers. Intrusion prevention technique such as firewall, filtering router policies fails to stop much type of attacks. Therefore, no matter how secure you try to make your system. Intrusion still happens and so they must be detected. Intrusion detection systems are becoming an important part of your computer system, and security. An intrusion detection system is used to detect several types of malicious behaviors that can compromise the security and trust of a computer system. This includes network attacks against vulnerable services, data driven attacks on applications, host based attacks such as privilege escalation, unauthorized logins and access to sensitive files, and malware (viruses, trojan horses and worms). An IDS can be composed of several components: Sensors which generate security events, a Console to monitor events and alerts and control the sensors, and a central Engine that records events logged by the sensors in a database and uses a system of rules to generate alerts from security events received. There are several ways to categorize an IDS depending on the type and location of the sensors and the methodology used by the engine to generate alerts. In many simple IDS implementations all three components are combined in a single device or appliance. Intrusion detection can allow for the prevention of certainty, attacks severity relative to different type of attack and vulnerability of components under attack the response may be kill the connection, install filtering rules, and disable user account.
Any set of actions that attempts to compromise the integrity, confidentiality, and availability of resources are that can damage your system and may access the confidential data. Any abuse might have quite different view related to attaching: what is the aim (objective) of attacking? What damages or other consequences or likely to be done? Any intruder can take the advantages of weak point of your system or vulnerabilities exist in targeted (your) system. Intrusion means some one attempting to break or misuse the system.
2.1 Classification
There are two main classes of Intrusion
:2.1.1 Misuse (abuse)
Intrusion is well-defined attacks on known weak points of system. All Intrusion which object is to misuse system resources and break it, are fall in this categories. Misuse intruder can be detected by watching for certain action being performed on certain objects and also by doing the pattern matching on audit trail information .
2.1.2 Anomaly
Intrusions are based on observations of deviation from normal system usage pattern. They can be detected by observing significant deviation from the normal behavior. Anomalous Intrusion is harder to detect. Anomaly or Anomalous may be symptoms of possible Intrusion. Anomaly detection has also been performed through other mechanism such as Neural Network. Systemâ„¢s vulnerabilities involve abnormal use of system therefore security violation could be detected from abnormal pattern of system usage. Normally we think that outside intruders are more dangerous to our systems and affect the system mostly. But it is false. According to report of FBI (Federal Bureau of Investigation) of US, that 80 % of Intrusions and attacks come from within organizations (inside intruder) because: inside known layout of system where is data? What security precautions are taken?
In order to properly response to an asset-attack it must first be detected and then all of its characteristics uncovered and documented. Once the attack or misuse recognized the response can be automatic or manual and can be include termination of connection, or host of response aimed at apprehending the attacker. Any technique such as firewalls, identification, authentication procedures and encryption are not design with any of above security issues. This particular security issues are the province of Intrusion Detection System.
3.1 Types of IDS
For general purpose, the Intrusion Detection System (IDS) has evolved into two major architectures. According to Anomaly or signature, scope:
3.1.1 Network-Based Intrusion Detection System
Network based IDS are best suited for alert generation of intrusion from outside the perimeter of the enterprise. The network based IDS are inserted at various points on LAN and observe packets traffic on the Network information is assembled into packets and transmitted on LAN or Internet. N-B IDS are valuable if they placed just outside the firewalls, thereby altering personal to incoming packets that might circumvent the firewall. Some Network-Based IDS take or allows taking input of Custom signatures taken from userâ„¢s security policy, which permits limited detection security policy violation. This limitation is due to packets traffic information that does not work well today in switched and encrypted environments packets analysis is weak in detecting attacking or misuse originating from authorized Network users. More detail approach is needed to perform damage assessments and to secure information assets from insider misuse and Intrusion Audit Log Analysis, the audit data generated by OS and application provide solution. Network-Based Intrusion Detection Systems (IDS) use raw network packets as the data source. The IDS typically uses a network adapter in promiscuous mode that listens and analyses all traffic in real-time as it travels across the network. A first level filter is usually applied to determine which traffic will be discarded or passed on to an attack recognition module. This first level filter helps performance and accuracy by allowing known un-malicious traffic to be filtered out. An example of this would be if an event for suspicious SNMP get was detected, and a known SNMP management station generated this event. Using Filters SNMP traffic from this machine could be filtered out of the examined traffic. Caution must be taken when using filters as traffic can be spoofed, and mis-configurations can cause more traffic to be filtered than desired. At the attack recognition module, typically on of three methodologies are used for attack signatures; pattern, frequency, or anomaly based detection. Once an attack is detected a response module provides a variety of options to notify, alert, and take action in regards to the attack at hand. Strengths of Networked Based IDS
The network-based IDS has many strengths due to its real-time packet capture and analysis functionality that cannot easily performed with a host-based IDS alone. Below are some its strengths that make network-based IDS clearly a needed component to any security systems and policy.
1. Cost of Ownership
The network-based IDS allow strategic deployment at critical access points to view network traffic destined to numerous systems that need to be protected. It does not require software to be loaded and managed on a variety of hosts as does the host-based IDS. Being fewer detection points are required, it makes the cost of management more effective for an enterprise environment
2. Packet Analysis
The network-based IDS examine all packet headers for signs of malicious and suspicious activity. Many of todayâ„¢s IP based denial of service (DOS) attacks are detected by looking at the packet headers as they travel across a network. For example; a LAND attack is a forged packet that has both source and destination IP addresses and source and destination ports being the same as the target host machine. The forged packet which tells the target to open a connection with itself and can cause target to operate slowly or crash. This type of attack can quickly be identified and responded to by a network-based IDS being it is looking packet stream in real-time. Also, attacks that use fragmented packets like Teardrop can also be detected with packet level analysis. A host- based IDS cannot detect these types of attacks. In addition to looking at the packet headers, a network-based IDS can also investigate the content of the payload looking for specific commands or syntax used with a variety of attacks. Many of these commands are indicative of an attack, whether successful or not. Example: An attacker probing for the new Back Orifice exploit on systems that are not infected with the Back Orifice software can be detected by examining the packet payload. Host-based IDS would not be able to detect these types of payload embedded attacks.
3. Evidence Removal.
The network-based IDS uses live network traffic for its attack detection in real-time and a hacker cannot remove this evidence once captured. This captured data not only has the attack in it but information that may help lead to his/her identification. This captured network traffic may also be needed as evidence leading to prosecution. One problem sometimes experienced with host-based IDS is that hackers understand most of the audit log files and that is usually the first place they go to cover their tracks and remove or damage this information.
4. Real-Time Detection and Response
The network-based IDS detects malicious and suspicious attacks as they are occurring in true real-time and provides faster response and notification to the attack at hand. Example: A hacker initiating a network based denial of service (DOS) based on TCP can be instantly stopped by having the IDS send a TCP reset to terminate the attack before it crashes or damages a targeted host. Many times with host-based IDS, the notification from a particular log or event may be detected after the damage is already done or not at all if the systems has crashed. Having real-time notification allows you to quickly react in a desired fashion. Some may want to allow further penetration so they can gather more information in a surveillance mode while other may opt for immediate termination of the attack.
5. Malicious Intent Detection
A network-based IDS can also be very valuable in determining malicious intent. If a network-based IDS is placed outside of detection Firewall it can detect attacks intended for resources behind the Firewall, although the firewall may be rejecting these attack attempts. A host-based IDS could not show these rejected attacks because they never hit the Host but are important to know the frequency and types of attacks being thrown at your network.
6. Complement and Verification
The network-based IDS can also complement existing components of your implemented security policy. In the case of encryption, the network-based IDS although it may not be able to read all encrypted traffic, it can be used to detect any not encrypted traffic that may be present of on your network. In the case of a Firewall, the network- based IDS can help verify if it is truly keeping out certain types of traffic and addresses that it should be rejecting required components will greatly enhance your resistance to attack. Below is a quick graphical representation that helps represent the independent network and host-based IDS scenarios and the benefit of implementing both a Network and a Host Based Solution.
7. Operating System Independence
The network-based IDS is not dependent on the host operating system for its detection source, as is the host-based IDS solution. All of the log information used with a host- based solution requires the operating system functioning properly and not compromised in any way
3.1.2 Host“based IDS
Host-based IDS placed monitoring Sensors also known as agents on network resources nodes to monitor audit logs that are generated by Network Operating System or application program. Audit logs contain records for events and activities taking place at individual Network resources. Because this Host-Based IDS can detect attacks that cannot be seen by Network-based IDS. Such as Intrusion and misuse and misuse by trusted insider. Host-based system utilize Signature rule base, which is derived from site-specific security policy. Host-Based can overcome the problems associated with N/W based IDS immediately after alarming the security personnel can locate the source provided by site “security policy. Host-based IDS can also verify if any attack was unsuccessful, either because of immediate response to alarm or any other reason but this is not available at packet level. Host-Based IDS can also maintain user login and user logoff action and all activity that generates audit records. Amount of info originating from large no. of sources is time- consuming and slower process is the disadvantage of H/B IDS and also Host-Based audit data analysis time consuming. Rapid detection analysis critical for alert generation and effective countermeasure which interrupt attacks in progress and reduce actual damage. Key difference between Host-based and Network-based IDS is that “ N/W based IDS although run on single host, is responsible for entire network segment, while Host-based IDS is only responsible for host on which it resides. Strengths of Host-Based IDS
Being the Host Based IDS resides on specific Hosts and uses the information provided by the operating system; it adds capabilities not found in the Network Based IDS. Some of the major strengths include:
1. Attack Verification
Being the Host Based IDS uses logs containing events that have actually occurred, it has the advantage of knowing if the actual attack or exploit was successful. This type of detection has been deemed as more accurate and less prone to false positives. Many Network Based attacks can trigger numerous false positives because of normal traffic looking very close to malicious traffic. In addition it is hard for a Network Based IDS to know whether or not an attack was successful or not.
2. System Specific Activity
The Host Based IDS can quickly monitor user and file access activity. Anytime a Login or Logoff procedure is executed it is logged and the host-based IDS can monitor this based on its current policy. In addition it can also monitor various file access and also be notified when specific files are open or closed. This type of system activity cannot be monitored or detected by Network Based IDS being it may not necessarily propagate traffic on the network. Example: Someone walking up to a Keyboard and open a non-shared file. The host-based IDS can also monitor activities that should and can only be executed from an administrator. Anytime user accounts are added, deleted, or modified this information is logged and can be detected as soon as the change is executed. Also if any audit policy changes are made affecting what the systems logs and does not log the Host Based Ids will immediately pick up this activity. A network-based ID also could not detect these types of administrator changes.
3. Encrypted and Switched Environments
Being the host-based IDS software resides on various hosts throughout an enterprise it can overcome some of the challenges faced by network-based IDS. In a purely switched environment it can be challenging to deploy a network- based IDS due to the nature of switched networks having numerous separate collision domains or segments. It is sometimes hard to get the required coverage being the network-based IDS can only reside on segment at a time and numerous ones need to be protected. Traffic mirroring and Span ports on switches have helped but still present challenges getting enough coverage and have limitations. The host-based IDS can provide greater visibility into a purely switched environment by residing on as many critical hosts as needed. As for Encryption, there are certain types of encryption that can also present a challenge to the network-based IDS depending where the encryption resides within the protocol stack it may leave the network IDS blind to certain attacks. The host-based IDS do not have this problem. If the host in question has log-based analysis the encryption will have no impact on what goes in to the log files. Stack-Based IDS allows us to monitor the packets as they traverse the TCP/IP stack, this allows the IDS to examine the packets before the OS or the Application see the packets, but after the TCP/IP stack has decrypted the packets
4. Monitoring Key Components
The host-based IDS gives you the ability to monitor important system components such as key executables, specific DLL â„¢ s and the NT Registry. All of these files could be used to breach security and resulting in systems and network damage. The host- based IDS can alert you when these files are executed or modified. Also items like disk space usage can be monitored and alerted on at certain levels. This can be very helpful in detecting if a hacker is using your server hard drive as a storage facility. These types of internal files cannot be detected with a network-based IDS.
5. Near Real Time Detection and Response
Although a host-based IDS relying on Log Analysis is not true real-time, if implemented correctly it can be extremely close. Near Real-Time . Instead of having a process check the status and content of log files are defined intervals, some of today â„¢ s host-based IDS can detect and respond as soon as the log is written to and compared to the active attack signatures. This near real-time detection can help catch the hacker before he/she has time to do extensive damage and remove evidence of being on the system. 6. Real-Time Detection and Response Stack-Based IDS can examine inbound and outbound packets and determine in real-time if an attack is being executed. If the Stack-Based IDS detections an attack it can then respond in real-time as well.
7. No Additional Hardware
The host-based IDS does not require additional hardware to do intrusion detection. It easily resides on your existing network resources (File Servers, Web Servers, and other shared or critical resources). This can make the host-based IDS more cost effective in some cases. In addition: its not another box on the network that requires addressing, maintenance, and management.
8. Fire cell.
Fire cell is a technology that is part of ISS Stack-Based IDS Server Sensor. Fire cell allows either by pre-configuration, or as a response to an attack, to have specific traffic refused. This is done similar to a firewall in that the Stack-Based IDS examine the packets and if they match a Fire cell rule the packets are dropped. For example if your company policy is for no HTTP servers to be installed on workstations, a Fire cell rule could be implemented that dropped all inbound packets to port 80.
3.1.3 The need for both types
As you can clearly see both network and host-based IDS solutions have unique strengths and benefits over one another and that is why the next generation IDS must evolve to include a tightly integrated host and network component. There are no Silver Bullets when it comes to network security but adding these two required components will greatly enhance your resistance to attack. Below Fig 3.1 is a quick graphical representation that helps represent the independent network and host-based IDS scenarios and the benefit of implementing both a Network and a Host Based Solution
3.2 Implementing an IDS
An implementation of an IDS has all the normal hurdles for implementing a piece of Security Software. These include testing impact to various systems, managing the installed software and the install itself. Implementing a Host Based IDS is fairly standard having similar problems to implementing any other Host Based piece of software. Implementing a Network Based solution has these problems as well as the problem of tapping into the communication flow. Many networks are now being built or upgraded to a switched Infrastructure instead of a Shared Media Infrastructure. This makes tapping into the communication flow an exercise in engineering that must be fully planned out. This document will outline the problems and pros & cons of the various solutions, as well as demonstrating them being used in an E-Commerce and a Perimeter solution
3.3 Characteristics of IDS
It must be able to detect the intruder in your system and legitimate user misusing system resources. It must run continually and fault tolerant. It must resist subversion of intruder and use self-diagnosis to determine if intrusion detection system has been compromised. Every system has different has different usage patterns and defense mechanism should adapt easily to these patterns.
3.4 Security policy and IDS
What is permitted and what is denied on system it must be defined. System must be available for use and data must be available in readable form. IDS must be able to verify the identity of user and user should be able to verify the identity of system. Private data should be known only to owner or chosen few.
There are different methods for Intrusion Detection. Some of the methods adopted are the following:
4.1 Pattern Matching
Pattern matching is based on looking for a fixed sequence of bytes in a single packet. As its name suggests, it is an approach that is fairly rigid but simple to employ. In most cases the pattern is matched against only if the suspect packet is associated with a particular service or, more precisely, destined to/from a particular port. This helps to lessen the amount of inspection done on every packet. However, it tends to make it more difficult for systems to deal with protocols that do not live on well defined ports and, in particular, Trojans, and their associated traffic, which can usually be moved at will The structure of a signature based on the simple pattern-matching approach might be as follows If the packet is IPv4 and TCP and the destination port is 2222 and the payload contains the string foo, fire an alarm. This example of a pattern match, of course, is a very simple one, but the variations from this point are also simplistic. You could include a specific starting point and endpoint for inspection within the packet, for instance or you could specify the TCP flags for packets to be considered. In the end, though, this technique remains the simplest and most primitive building block for intrusion detection
• This is the simplest method to detect intrusions.
• This method allows for direct correlation of an exploit with the pattern; it is highly specific.
• This method reliably alerts on the pattern specified.
• This method is applicable across all protocols.
• This method can lead to high false positive rates if the pattern is not as unique as the signature writer assumed
• Any modification to the attack can lead to missed events (false negatives).
• This method may require multiple signatures to deal with a single vulnerability to be exploited. Multiple tools lead to multiple signatures
• This method is usually limited to inspection of a single packet and, therefore, does not apply well to the stream-based nature of network traffic such as HTTP traffic. This scenario leads to easily implemented evasion techniques
4.2 State full Pattern Matching
A more sophisticated method is state full pattern matching-based analysis. This method of signature development adds to the pattern match the concept that because a network stream comprises more than single atomic packets, matches should be made in context within the state of the stream. This means that systems that perform this type of signature analysis must consider arrival order of packets in a TCP stream and should handle matching patterns across packet boundaries. How does this scenario affect the example that was introduced in the simple pattern-matching discussion? Now instead of looking for the pattern in every packet, the system has to begin to maintain state information on the TCP stream being monitored. To understand the difference, consider the following scenario. Suppose that the attack you are looking for is launched from a client connecting to a server and you have the pattern- match method deployed on the IDS. If the attack is launched so that in any given single TCP packet bound for the target on port 2222 the string foo is present, the alarm fires. If, however, the attacker causes the offending string to be sent such that fo is in the first packet sent to the server and o is in the second, the alarm does not fire. If the state full pattern-matching algorithm is deployed instead, the sensor has stored the fo portion of the string and is able to complete the match when the client forwards the .o
• This method requires only slightly more effort to employ than simple pattern matching.
• This method allows for direct correlation of an exploit with the pattern; it is highly specific.
• This method reliably alerts on the pattern specified.
• This method is applicable across all protocols.
• This method makes evasion slightly more difficult.
• This method can lead to high false positive rates if the pattern is not as unique as the signature writer assumed.
• Any modification to the attack can lead to missed events (false negatives).
• This method may require multiple signatures to deal with a single vulnerability to be exploited. Multiple tools lead to multiple signatures.
4.3 Protocol Decode-Based Analysis
Protocol decode-based signatures are in many ways intelligent extensions to state full pattern matches. This class of signature is implemented by decoding the various elements in the same manner as the client or server in the conversation would. When the elements of the protocol are identified, the IDS applies rules defined by the RFCs to look for violations. In some instances, these violations are found with pattern matches within a specific protocol field, and some require more advanced techniques that account for such variables as the length of a field or the number of arguments. Note that pattern matching and protocol decoding are not mutually exclusive, as some would lead you to believe. For illustration purposes, consider the example of the abc attack. Suppose that the base protocol that the attack is being run over is the fictitious BGS protocol, and more specifically, assume that the attack requires that the illegal argument foo must be passed in the BGS Type field. To further complicate the situation, assume that the Type field is preceded by a field of variable length called BGS Options. The valid list of options are fooh, mooh, tormer, and buildo. Using the simple or the state full pattern-matching algorithm in this case leads to false positives because the option fooh contains the pattern that is being searched for. In addition, because the field lengths are variable, it would be impossible to limit such false positives by specifying search start and stop locations. The only way to be certain that foo is being passed in as the BGS type argument is to fully decode the protocol. Not doing full protocol decodes can also lead to false negatives if the protocol allows for behavior that the pattern-matching algorithms have difficulty dealing with. For example, if the BGS protocol allows every other byte to be a NULL if a value is set in the BGS header, the pattern matchers would fail to see fx00ox00ox00. The protocol decode- enabled analysis engine would strip the NULLS and fire the alarm as expected, assuming that foo was in the Type field.
• This method minimizes the chance for false positives if the protocol is well defined and enforced.
• This method can allow for direct correlation of an exploit.
• This method can be more broad and general to allow catching variations on a theme.
• This method reliably alerts on the violation of the protocol rules as defined.
• This method can lead to high false positive rates if the RFC is ambiguous and allows developers the discretion to interpret and implement as they see fit. These gray area protocol violations are very common.
• This method requires longer development times to properly implement the protocol parser.
4.4 Heuristic-Based Analysis
Heuristic-based signatures use some type of algorithmic logic on which to base their alarm decisions. These algorithms are often statistical evaluations of the type of traffic being presented. A good example of this type of signature is a signature that would be used to detect a port sweep. This signature looks for the presence of a threshold number of unique ports being touched on a particular machine. The signature may further restrict itself through the specification of the types of packets that it is interested in (that is, SYN packets). Additionally, there may be a requirement that all the probes must originate from a single source. Signatures of this type require some threshold manipulations to make them conform to the utilization patterns on the network they are monitoring. This type of signature may be used to look for very complex relationships as well as the simple statistical example given.
Some types of suspicious/malicious activity cannot be detected through any other means.
Algorithms may require tuning or modification in order to better conform to network traffic and limit false positives.
4.5 Anomaly-Based Analysis
Anomaly-based signatures are typically geared to looking for network traffic that deviates from what is seen normally. The biggest problem with this methodology is to first define what normal is. Some systems have hard-coded definitions of normal, and in this case they could be considered heuristic-based systems. Some systems are built to learn normal, but the challenge with these systems is to eliminate the possibility of improperly classifying abnormal behavior as normal. Also, if the traffic pattern that is being learned is assumed to be normal, then the system has to contend with how to differentiate between allowable deviations and those that are not allowed or that represent attack-based traffic. The work in this area has been mostly limited to academia, although there are a few commercial products that claim to use anomaly-based detection methods. A subcategory of this type of detection is the profile-based detection methods. These systems base their alerts on changes in the way that users or systems are interacting on the network. They incur many of the same limitations and problems that the overarching category has in inferring the intent of the change in behavior. Interesting facts can be learned from trending data, and it is possible to detect ongoing attacks based on these algorithms. The information that these systems provide, however, is generally very nonspecific and requires much investigation to put it in the proper context. In some instances, the lines blur between methodologies because most protocol decode analysis engines alert the user to the presence of protocol violations that are not directly related to any known attack but are anomalous (for example, length- based buffer overflow detection). Therefore, in this instance the engine has attributes of an anomaly-based system. In general these systems are being marketed as the panacea for IDS, but systems based on these techniques have been the subject of numerous academic research efforts with results showing limited success, and they are not production proven. The limited success observed in the academic research arena lends credence to the saying If it sounds too good to be true, then it probably is.
• If this method is implemented properly, it can detect unknown attacks.
• This method offers low overhead because new signatures do not have to be developed.
• In general, these systems are not able to give you intrusion data with any granularity. It looks like something terrible may have happened, but the systems cannot say definitively.
• The signal-to-noise ratio is very low in most cases.
• This method is highly dependent on the environment in which the systems learn what normal is.
When Intrusion detection system is applied to the large Internet worked environments or information infrastructures, in such case it has some important limitations
1) IDS detect local intrusion symptoms and can only react locally (e.g. by reconfiguring local boundary controller and hosts). Because attacks may cross many network boundaries, and response local to the target canâ„¢t identify or mitigate the source of attack, which may be several network removed.
2) Even if IDS were capable of communicating with remote boundary counter near attacker, there is no common language for remotely instructing them to block selected traffic. It is also unlikely that Intrusion detection system would know enough about all such device to be able reconfigure them remotely using low level, device-specific commands.
3) If Intrusion is detected or its symptoms is detected in different areas of an inter- networked environment by different Intrusion detection system, the current technologies lacks the infrastructure and protocol for
1. Pooling this information to allow correlation and
2. Developments and promulgation of coordinated uniform response through environment. The technology Intruder Detection and Isolation Protocol (IDIP) overcomes this drawback. This protocol is integrated with some variety of boundary control devices, host and Intrusion detection system for blocking and tracing of Intrusion across Network boundaries.
5.1 IDIP Concept
IDIP is an application layer protocol that coordinates Intrusion tracking and Isolation IDP system are organized into IDIP communities. Each IDIP community is an administrative domain, with intrusion detection and response functions managed by component called Discovery coordinator communities are further organized into IDIP neighborhoods. These neighborhood are collection of components between them Boundary control device are members of multiple IDIP neighborhoods. See Fig 5.1 Objective of IDIP is to share the information necessary to enable intrusion tracking and containment.
• When attack traverse IDIP protected network each IDIP node along the path is responsible for auditory data based system. When intrusion system is detected, then all neighbors are reported.
• Each IDIP node makes local decision as to what type of response is given is depends on the attack type, attack certainty, attacks severity relative to two type of attack and vulnerability of components under attack the response may be kill the connection, install filtering rules, disable user account
Each IDIP nodes send copy of attack report along with local response the Discovery coordinator collect all report gain better over all picture of situation and also issue response directive back to individual nodes to either remove an unnecessary response (e.g. Firewall filtering rule) Or odd response like firewall filtering with alternate attack path .
Host mainly also participate in IDIP system, Host can provide more fine- grained responses. As they can trace Intrusion back to the process and the user initiating Intrusion from local hosts. If intruder-performing attack after hopping through multiple Hosts IDIP- enabled hosts allow the Intrusion to be traced back through these hosts, which is not possible if only boundary controller participate in IDIP system. 5.2 IDIP Application Layer Protocol IDIP is organized into two primary protocol layers: The IDIP application layer and IDIP message layer. The application layer protocol accomplishes intrusion tracking and containment through three major messages type 1.Trace 2.Report 3.Discovery coordinator directive IDIP trace request message is sent, when events sequence is detected that is determined to be sufficient intrusive to response which may be trace and block lutes. This message includes description of event and connection that used by intruder. This information is used by each IDIP node that receive the trace request to determine if the attack passed through node. The description may be need to modified for this protocol supports translation record to end of trace message. In trace message, Blocking can be inserted for limited time or until system administrator reverse the action. For this IDIP monitor the clock to determine when to remove the blocking. An IDIP report is simply copy of trace message that is sent to the Discovery coordinator by each component that receive message. Once the Discovery coordinator has determined an optimal response to sends directive to node thatâ„¢s require altering response. Discovery coordinator directive has two types
1. Undo message- which request that reverse the previously taken action by IDIP,
which may be open service for blocked at firewall.
2. Do message- To take another action like extend duration of blocking rule to support communication between the varied IDIP components require flexible and extensible long.

The IDIP uses common Intrusion specification language (CISL) developed by common Intrusion between framework (CIDF).
5.3 Cryptographic Requirements
Basic requirement for IDIP cryptographies are:
1. Minimal impact on IDIP message size, as each IDIP message must fit within one UDP
data gram, which is 64 Kilobytes.
2. Availability on multiple platforms, including salaries, os/2, Linux, Windows NT and
integration of each.
5.4 Software Architecture
To primary objectives for IDIP software architecture is
1. Easy of integration with various components.
2. Flexibility in modifying the generic component behavior.
The underline premise of our intrusion detection model is to describe attacks as instances of an ontology using a semantically rich language like DAML [3]. This ontology capture information attacks such as the system component it affects, the consequences the attacks the mean of attack the location of attacker. Such target “centric ontology has been developed by under conferral, hence our intrusion detection model consist of two phases. The initial phase™s data mining techniques to analyze data stream that capture process, system and network states and detect anomalous behavior and the second or high level phase reasons over data that is representative of the anomaly defined as instance of ontology. We model the quiescent state of a system based on these data streams. Some work as already been done on using system call data and TCP packet information for building anomaly detection models[5][6].This model not only includes stream of system for and network data but also includes low level kernel data such as memory usage, address offsets, MIB data, interrupts .These data stream are provided by the operating system for the process present in the system. One way to build the models from these data streams is to use fuzzy clustering in which dissimilar matrix of object to be cluster as input. The objective function are based on selecting, representative objects from the features set in such a way that total fuzzy dissimilarity within each cluster is minimized.
6.1 Data mining and ID
According to Grossman Data mining as being concerned with uncovering patterns, associations, changes, anomalies and statistically significant structures and event in data Data mining is the process of selecting, exploring and modeling large amount of data to uncovers previously unknown pattern of business advantages.
Data mining technique are used to solved the problem of intrusion detection, because anomaly detector looks for an abnormalities, many of the data mining technique that seek to identify outliers in data become readily applicable.
6.2 Data collection and modeling
The data collected at server level (Apache web server) and at system (operating system) level (LINUX kernel) which is at low level data process system network level process data include number of child process forked by parent process, the amount of time spent by the process in user and system modes, attributes describing memory usage, and attributes describing signal information. The collector network data is comprised of statistical information regenerating the IP, ICMP, UDP, and TCP layers of network protocol stack. This data is inclusive of rates of change for the number of packets received the number of packets received with error and number of packets drop. At the system level we collect information regarding memory, CPU load etc. See Fig 6.1.Here output stream samples are taken from host under observation and preprocessor using data mining technique.
6.3 Principle Component Analysis (PCA)
According to PCA construct new representation of feature set where in the maximally variants dimensions of the data is captured once applying PCA, dimensionality of feature set is reduced while the maximum amount of information and pattern in the data are preserved.
6.4 Fuzzy clustering and Detection
Once the dimensionality of data set is reducing, we use FCMdd algorithm to cluster the data points In clustering approaches membership of data point is the cluster is binary decision, either the data point is a member of cluster or not. In fuzzy clustering the data membership of data point in cluster is fuzzy decision. A data point is considered to be the member of every cluster with given possibility membership value that ranges from 0 to 1. The objective function of the FCMdd algorithm is based on selecting, reprehensive objects from data set in such a way that the total fuzzy dissimilar within each cluster is minimized.
The FCMdd algorithm produces multiple object for cluster for given best data point, if distance from any randomly selected object is only consideration, it might wrongly classify the data point as member or nonmember. To solve this issue we use two-outlier detection. Both take all object of cluster into account. Hence fuzzy clustering with IDS model call for sampling low level kernel data at close intervals and using outlier detection to capture anomalous behavior within those data streams. This initial phase serve as filter to higher-level data reasoning phase which will mitigate the high false positive rate.
7.1 Network Intrusion Detection System
There are several ways to do filtering for NIDS alerts which is needed due to that NIDS produce lot of false positive alerts as it can not have usually no way of knowing if they attack actually succeeded or failed. So additional elements should be added on the top of NIDS system to check the targeted host, which is integrated service checker (ISC) many current NIDS system are unable to test the remote operating system due to which more false positive alerts are produced
7.2 System Layout
Sensors are running on operating system (Red hat LINUX system) and NID element is the short system. Sensors are placed in such a way that it can see all outgoing and incoming traffic from network.
7.3 Data Collection and Analysis
Data collection set up so that it cannot interface with data collected. This is achieved by setting the interface is such mode with operating system that O.S. cannot send any packet. For collecting data fiber link on gigabyte speed is used. However, this short system rule can still lead to false.A possibility, when it records OFF site web traffic and the string is matched for some reason. The checker system is needed especially when it is identified what attacker is looking for and record IP address of the hackers. After that we may see some IP address doing buffer overflow attack again certain ports and services at this point Vulnerability checker is to check hosts which are intruder tried to exploit.NIDS system integrated with automatic checking could be included in our security operations and can be used as basis for follow up. This set up enables the IDS to smarter and reduced number of false positive
At this stage we have study the types of ID and methods of ID. It is appear that using low level kernel data stream to model the quiescent state of the system is a viable Intrusion Detection system like fuzzy clustering appears to be effective for outlier detection within this low level system, process and network data stream. NIDS system Integrated with automatic checking could be included in our security operation and can be used as bases for follow up which shows advantages of automatic checking NIDS system alone is most of times not enough further checks needs to be applied before follow up with system administrator. But for better efficiency, our system must be real time processing which should be achieved in future. In future alerts generated by IDS are sending to oracle database and actual email is generated and information about administrator and local user is added to the e- mail
1. Axelsson, S,Research in Intrusion-Detection Systems: A Survey, 1999
2. Pietraszek, T. and Tanner A.(2005), Data mining and machine learning -
Towards reducing false positives in intrusion detection Information security technical
report [1363-4127] 10(3) pp. 169-183
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion

Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  REDTACTON A SEMINAR REPORT project girl 2 535 25-04-2016, 03:58 PM
Last Post: mkaasees
  DETECTION OF WORMHOLE ATTACK IN MANET seminar ideas 5 1,368 26-08-2015, 12:37 AM
Last Post: Leenas
  Cut Detection in Wireless Sensor Networks pdf project girl 2 1,237 16-07-2015, 09:21 PM
Last Post: Guest
  seminar report on cyber terrorism pdf jaseelati 0 308 23-02-2015, 01:49 PM
Last Post: jaseelati
  web operating system seminar jaseelati 0 308 17-02-2015, 02:20 PM
Last Post: jaseelati
  seminar report on internet of things jaseelati 0 361 29-01-2015, 04:51 PM
Last Post: jaseelati
  analysis on credit card fraud detection methods ppt jaseelati 0 154 22-01-2015, 02:45 PM
Last Post: jaseelati
  nano ic engine seminar report jaseelati 0 299 21-01-2015, 01:43 PM
Last Post: jaseelati
  google glass seminar report pdf jaseelati 0 326 21-01-2015, 01:41 PM
Last Post: jaseelati
  rolltop laptop seminar report jaseelati 0 273 17-01-2015, 03:15 PM
Last Post: jaseelati