Unit 6 - Intrusion Detection & Prevention Systems

Transcription

1 Unit 6 - & Prevention s Rich Macfarlane This unit introduces and Prevention systems. This includes fundamental concepts, techniques, the active responses which Prevention can add, Network-based and host-based systems, and centralised monitoring and management of these systems. 6.1 Introduction Threats to an organisation traditionally came from untrusted external networks, but a large percentage of intrusions are now sourced from inside the organisation, as illustrated in Figure 1. Security, implemented with Perimeter Firewalls and VPNs can only mitigate threats originating in external networks. If threats come from inside the trusted network, then supplementary defences must be put in place in order to assist the system administrator identify these malicious activities. and Prevention s () are examples of these detection security controls. Network firewalls typically only inspect traffic up to Layer 5, and sometimes to some extent Layer 7 the application layer. They generally do not deeply inspect the application layer data however, and so struggle to defend against application layer threats such as malicious software. The firewall sees the traffic as valid traffic and may not detect the malicious application data content. Data & Identity Theft Corporate access access Web access Fraud & Extortion Assets Denial-of-Service (DoS) Users Data Theft s Sabotage Valid Traffic Destructive Attacks Data Access Abuse Malicious Employees Ex-employees Network/Organisational perimeter Hacktivists/ Terrorists? Figure 1 Threats to the Organsisation Malicious S/W: Worms, Viruses, Trojans, Rootkits Cyber Espionage/ Warfare s s, can be defined as activities, or events, which are malicious in nature, trying to upset normal operations, or gain unauthorised entry to systems. These events are deliberately trying to cause harm to a system. In the context of, these intrusions include both attacks on systems, which are successful, as well as unsuccessful attacks. Attacks which do not succeed in causing harm to the system are still important to the system administrator, to develop a comprehensive understanding of activities in the network. s in the context of, can also describe misuse and abuse from inside users, including malicious activities and organisational policy breaches. Policy breaches could be as simple as unauthorised web use, Network Security & Prevention s - Rich Macfarlane 1

2 such as downloading music or the use of Instant Messenger (IM) applications from within the organisations network. s (IDS) s (IDS) can help a system administrator keep track of the state of the trusted network, by monitoring events in a host system or network, and analysing them for signs of intrusions. Various IDS sensors can be placed around the network to monitor the network traffic and host systems, and look out for malicious activities. These, act a bit like the sensors of a burglar alarm system, when one is activated it sets off an alarm. This can indicate where the intrusion is in the building, but does not actually stop the burglars from making off with the loot. Similarly, the sensors of an IDS system raise an alarm, sometimes called an alert, when an intrusion is detected. Importantly, although the sensor raises an alarm it does not stop the attack or policy breach from proceeding. These alerts can be configured, by the system administrator, to do different things for different levels of intrusion. For example, log an alert locally on the sensor, log to a central or console, or even /page the system administrator directly. IDS is like a Burglar Alarm IPS is like a Guard Dog Prevention Figure 2 IDS & IPS Prevention s (IPS) An extension to the IDS is the Prevention (IPS), which also detects an intrusion in the same manner that IDS do. The main difference being, that an IPS can also generate an active response to the attack, stopping it before it succeeds in harming the system. For example, the IPS may automatically drop the offending packet, and terminate and the connection to the attackers machine. This can be compared to having an alarm system and a guard dog on the premises. The alarm sensors would detect the intrusion and raise the alarm, and the guard dog would attempt to prevent the burglars from stealing anything. Another possible IPS response would be to change or clean the intrusion data, such as altering the offending network packets so they cannot do any harm; perhaps removing an attachment to prevent a known piece of malware propagating. The IPS could also request changes to the security implemented in the network or host system, to prevent the attack in future, for example requesting the reconfiguration of a perimeter screening router, or changing a host s firewall policy. Network Security & Prevention s - Rich Macfarlane 2

3 The term and Prevention s () will be used throughout the chapter, to describe the combined technologies, and common functionalities. History of and Prevention s Prevention is a fairly new technology which is still evolving, where has been around since the 1980 s and has evolved significantly over this time. In the early 1980 s it was identified, in a paper by James Anderson Computer Security Threat Monitoring and Surveillance, that malicious events could be identified by analysing systems audit logs. This introduced the first ever host-based IDS, and the concept of an IDS for the very first time. In the mid-1980 s, Dr. Dorothy Denning at SRI International, created the first IDS system which analysed audit trails on mainframe computers the Expert (IDES). She published the seminal paper on IDS, An Model in 1986, which laid the foundations for almost all of the work on IDS which has followed. At the same time the Haystack system, which compared audit data with pre-defined patterns, was being developed. The Haystack name came from the comparison of the task of audit data analysis, to looking for a needle in a haystack. The first Network was developed by Todd Herberlein in It was called Network Security Monitor (NSM) and was deployed at government installations in the USA. It was different from the IDES and Haystack, as it analysed network traffic rather than system logs. NSM, along with the Haystack system, were the first commercial IDS products. History Network Flight Recorder (NFR) Marcus Ranum RealSecure Network IDS Device ISS Cisco Purchase Okena s StormWatch IPS Computer Security Threat Monitoring Paper James Anderson Expert (IDES) Dr. Dorothy Denning SRI International Haystack Lawrence Livermore Labs Network Security Monitor (NSM) 1 st Network IDS Todd Heberlein NetRanger 1 st Commercial IDS Device WheelGroup Cisco Purchase Wheel Group and NetRanger Security Device Snort Network IDS Martin Roesch/ Sourcefire Cisco Purchase Sourcefire IPS Internet < 1000 systems The Morris Worm 1 st Internet Attack Internet > 100,000 systems Commercialisation of the Internet Figure 3 & Prevention History Internet > 400 million systems In the early 1990 s, the Automated Security Measurement (ASIM) was developed to monitor network traffic on the US Air Force s network. The development team responsible for this formed a company, The WheelGroup, and their product NetRanger, was the first commercial Network hardware device. Around the same time, Marcus Ranum, who developed the first commercial Network Security & Prevention s - Rich Macfarlane 3

4 firewall, created a commercial IDS called the Network Flight Recorder (NFR). By the late 1990 s popularity, and so revenues, started to increase for IDS. In 1997, the security market leader, Internet Security s (ISS) released RealSecure, a Network IDS, with limited IPS functionality, being able to stop some network traffic based on matching signatures. The following year Cisco, realising the importance of the growing IDS market, purchased the WheelGroup and rebranded their NetRanger product. Cisco also incorporated IDS functionality into the software on some of their routers. During this time some of the Haystack development team had created the Centrax Corporation company, and released the entrax host-based IDS for Windows. The open source Network IDS Snort arrived in 1999, developed by Martin Roesch, and has become the one of the most widely deployed IDS worldwide. He also created the Sourcefire company which provides a commercial version of Snort and several highly rated appliances running software based on Snort. In 1999, Okena s created one of the first IPS s called StormWatch. This was acquired by Cisco in 2003, and lead to the creation of the Cisco 4200 series network devices. Cisco have gone on to incorporate into their PIX/ASA security devices, and more recently were early adopters of running on switches. Over the last ten years several of the large security companies have made failed bids for Sourcefire and its Snort-based offerings. In July of 2013, Cisco succeeded, reportedly paying over $2.5 for the company. From a press release it seems that Cisco will attempt to integrate the Snort engine into their IPS offerings including built in ASA appliance IPS provision Cisco intends to utilize the Snort engine and signature set as part of the ASA integrated IPS offers. This is in-line with the architectural evolution that was already planned as part of the Cisco platform evolution and is consistent with Cisco's commitment to growing the Snort open source community and Snort usage across the industry. Reasons for and Prevention s and Prevention s are primarily used to detect malicious activities on a system, such as when an intruder has compromised a public facing web in a company DMZ, or reconnaissance activities on a part of the trusted network, from a remote attacker on the Internet. The can then report these activities to the system administrator, who can possibly take actions to prevent the incident happening again. This reporting may be directly from the sensors to administrators, but more common is logging to a central system, with security event monitoring and analysis of the logs after the event. If an IPS is being used the intrusion could also be blocked automatically as well as being logged, for later analysis. monitoring can also act as a deterrent to employees, who might otherwise be tempted to violate aspects of the organisational security policy. For example, by running peer to peer file sharing software, or Instant Messaging (IM) applications. Internal and external users are also less likely to attempt to access unauthorised systems, or perform network scans if they know the organisation is using, the same way a burglar may be put off trying to break into a house if there is known to be an alarm installed. can also provide a measure of quality control on the security measures in place around an organisation. It could identify short comings with the current security policy, or its implementation. For example, a worm may be detected scanning the network from an end user machine which has been compromised because its virus software is not up to date. Or a network-based could identify an Network Security & Prevention s - Rich Macfarlane 4

5 intrusion which the firewall allowed through, due to a badly configured firewall policy. This is part of the auditing phase of the security life cycle. 6.2 is the process of monitoring, analysing and auditing activities on computer systems or networks, to identify malicious events, or policy breaches. This was historically the job of the IDS, but all perform. IPS technologies are an extension of the functionality of IDSs. In addition to detection and reporting of suspicious events, IPS can attempt to respond directly to attacks or misuse. All log information relating to suspicious activities which they detect. The logs are written locally on the sensor itself, and possibly also to a central logging (e.g. syslog ), or centralised security management system. These logs can be used to investigate the events in question, validating the intrusions, and also to correlate the events reported by this sensor and from others in the organisation. Sensor Logs Alerts Query or Network Activities Alerts/Events Monitoring/ Management Console Logs Prevention Logging Server Rules & Policies Administrator Mobile SMS, Figure 4 Common Functions can also inform system administrators directly about important detected security events. Detected activities can also be sent to a centralised monitoring console, to alert the system in real time. Alerting the system administrator can be done through various methods, including: the user interface of the itself, by , SMS, by pager, through Simple Network Management Protocol (SNMP) messages, or syslog messages. Typically, the alert itself would not contain all the information concerning the activity in question. The system administrator may need to investigate further, and possibly react to the alert. The administrator may have to query the sensor, and pull details from the sensors logs to get the full information. Network Security & Prevention s - Rich Macfarlane 5

6 Reports can also be generated by the system, or a central monitoring and management system. These typically summarise the important, detected, activities, possibly highlighting potentially dangerous events. Typically systems now come with a range of predefined reports which can be created with minimal configuration. Alert Types The ability of the Sensors to correctly detect malicious activities is crucial to the effectiveness of the system as a whole. Table 1 defines the fours alert types which is the terminology typically used in the description of events generated by. Describing the alert types in this way can be confusing, but to simplify it can be thought of as: Positive/Negative means the alert has been raised/not raised, and TRUE/FALSE if this was correctly/incorrectly generated. A FALSE Positive can be defined as an alert which has been incorrectly raised, as there was in fact no intrusion or malicious activity. This could be due to an IDS detection signature, which is too general in its definition, or to some abnormal network traffic, which does not match an expected profile. A real world example of a false positive would be the neighbours burglar alarm going off during the night due to the wind, or a university fire alarm being set off by the dust produced by some workmen. Table 1 Alert Types Attack Not an Attack Alert was Generated - Positive TRUE Positive. Attack occurs, and correctly alarm is raised/attack stopped. FALSE Positive. No Attack occurs, and alarm is raised in error. Alert was not Generated- Negative FALSE Negative. Attack occurs, but incorrectly, no alarm is raised. TRUE Negative. No Attack occurs, and correctly no alarm is raised. The accuracy of detection can be measured using the two sets of alerts generated; using the ratio of TRUE Positives vs FALSE Positives. The types of event detected and the accuracy of the alerts vary between systems. Some systems can use a variety of detection methods and correlate the alerts at a central point in the network, which can lead to more accurate detection of intrusions, but this comes with more complicated setup and tuning which can be expensive. However, will always need tuning to create an acceptable detection accuracy, i.e. keep the number of TRUE Positives high, and the number of FALSE Positives as low as possible. If more false positives are being generated than the security monitoring team can deal with important events may be missed. More important assets may have to take priority, and some events may have to be ignored. Other tuning and customisation, concerning usability and effectiveness, can also be done. s can have their detection and prevention actions tailored to different types or individual threats. For example, if a worm was detected, propagating itself via the network, the traffic could be blocked immediately, but for the detection of an employee breaking the organisations usage policy, by chatting to friends using an Instant Messenger application, logging the event may be all that is necessary. Methods Each sensor uses a specific method of performing the process. Sensors can be categorised by the method of intrusion detection they use. The main types of detection method are: Signature-Based Network Security & Prevention s - Rich Macfarlane 6

7 Anomaly-Based Policy-Based Signature-Based Signature-based, also known as Misuse-based, or Knowledge-based is the most commonly used method of intrusion detection. A signature is a pattern which can be matched against activities which the is monitoring. Signature-based detection is the simplest type, as it compares a list of known signatures against an activity happening on the network or host system. For example, in a network a list of string signatures would be compared with the content of the packets flowing through the Sensor. If a signature matches the content of a packet, an alert would be generated. Signature-based detection is very effective at identifying known attacks, but has real problems detecting new threats. Its signature database has to be updated regularly, or these new attacks will not be detected. This updating of signatures is similar to the regular antivirus updates that are done on computers connected to the Internet, to keep the antivirus application up to date. Another issue is malicious activities over multiple events. An intruder could create a version of a known intrusion, but one which spreads itself out over time. The only way for the to identify this attack would be to cache session information and analyse it all together. Examples of signatures could be: The transferring of files via Instant Messenger File Transfer, which is a breach of the organisations Security Policy. Hex strings known to identify malware propagating on the network (shown in Figure 5). or Network Activities 77 8E 4A BA BA 5A E BA 5A E BA 5A E E 4A BA BA 5A E B3 DA 67 3E Prevention Sensor Logs Alerts Signatures Figure 5 Signature-Based IDPD Sensor Anomaly-Based This method, sometimes known as Behaviour-based, detects an intrusion based on abnormal activities on a system, or on the network. The sensor compares the activities currently occurring, against what is thought to be normal. A normal, or baseline profile is created by monitoring the behaviour of elements, over a period of time. This is known as a learning or training period. The types of behaviour used to create profiles could be: Network Security & Prevention s - Rich Macfarlane 7

8 User behaviour CPU usage Type and number of system processes Number of network connections Network traffic types For example, in a user access network segment, the percentage of web traffic might be, on average, between 22% and 28% on weekday mornings. The Sensor can use statistical methods, to compare the actual percentage of web traffic with the baseline profile. If the percentage of web traffic is not within the bounds of the profile, an alert would be generated. This network-based profile example is illustrated in Figure 6. The main benefit of this anomaly-based system is that it can be effective at detecting new attacks. There are thousands of attacks, which are constantly being enhanced, as well as completely new attacks being created daily to exploit newly discovered vulnerabilities. For example a host system within the network is infected with a new type of Virus, and it starts to send s to every person in the users address book. An anomalybased sensor on the host might pick up the abnormal increase in CPU usage and an anomaly-based sensor on the network segment would pick up the sudden increase in traffic, which would be different to the normal profile. or Network Activities DNS DNS DNS DNS DNS DNS DNS Web Web Traffic 22-28% 4-9% ARP 8-12% DNS 3-6% Prevention Sensor Logs Alerts Network Traffic Profile Figure 6 Anomaly-Based Sensor There are problems with anomaly-based systems which have led to their limited use. It is difficult to create certain types of profiles accurately. For example, periodic activities such as weekly or monthly backups may not be included in the profiles. This would then lead to a very high rate of FALSE Positives being generated when these events occur. Anomaly-based systems typically generate a lot more FALSE Positives, and are generally significantly harder to tune than signature-based systems, especially in environments which have volatile network activity or host systems. For example, general use student network segments on a university campus. When the initial profiles are defined, it is done over a number of days, or even weeks. During this time intrusions may be inadvertently included in the profiles, which would lead to these attacks not being Network Security & Prevention s - Rich Macfarlane 8

9 detected when the system was up and running. Administrators would have to remove these manually from the profiles. s also have to recreate these profiles periodically, to keep them current, and this type of profile is known as a static profile. Another way of stopping the profiles from becoming inaccurate over time, is to use dynamic profiles. These change gradually with changing patterns of activities, over time. These are at risk from a clever attacker who could drip-feed malicious activities into the system, and increase the amount gradually, which would be incorporated into the dynamic profiles. Anomaly-based detection is an example of a closed security model, in that it allows only behaviour that is classed as normal, and raises an alarm if it doesn t recognise activities. This is the opposite of the signaturebased system, were all activities are implicitly allowed, except the known bad activities. Signature-based detection is an example of an open security model, which is generally regarded as a poor substitute for a closed model. Unfortunately, due to the number of FALSE Positives generated, they are less common than signature-based detection systems. Signature-Based (Misuse ) This attempts to model attacks on a system as specific patterns, and then monitors for occurrences of these. Its main disadvantage is that it struggles to detect new attacks. Known Viruses/Worms External hack (scripted) Sensor New Viruses/Worms Anomaly-Based This assumes that abnormal behaviour by a user can be correlated with an intrusion. Its advantage is that it can typically react to new attacks, but can often struggle to detect variants of known attacks, and can generate a lot of FALSE Positives. Another problem is that the intruder can evade detection by mimicking the behaviour of the user. Denial-of-Service Fraud External hack (human) Data Theft Figure 7 & Attacks Mitigated Stateful Protocol Analysis-Based Stateful Protocol Analysis is sometimes included in the definition of Signature-Based, but it is separated here to explain the detail. This type of detection is based around the standards for Protocols, as defined by the Protocol Vendors, or by accepted definitions of the protocols. The techniques used are similar to those in Stateful firewalls, which have Application Protocol Inspection functionality. This consists of, the tracking of connections, checking that protocols are being used in the standard way. Checking only the allowed commands are being used, and in the correct order, based on the protocols current state. The can perform a similar task, comparing current Application, Transport and Network layer protocol activity on the network, or system, with standard behaviour profiles for the protocols, supplied by their vendors. For example, if a protocol command was issued twice and the standard behaviour did not allow this, an alert would be generated (a sign of a possible DoS attack). Individual commands and parameters can also be validated, checking for type, and bounds checking values, to identify protocol misuse such as in buffer overflow attacks. Network Security & Prevention s - Rich Macfarlane 9

10 The problem with protocol analysis-based detection is the amount of resources needed to do the complex analysis, and to keep track of all the connections and their states. This is similar to Application Inspection Firewalls, in that the more inspection that is done, the slower the process is. Also, these systems cannot detect attacks if the intrusions are within the bounds of the protocol standard definitions. Policy-Based Policy-based systems compare the activities being monitored with network security policy rules. If the activities being monitored are outside the rules of the policy, an alert can be generated. The security policy rules have to be created before the sensor can be implemented. This may require detailed research and investigation into the organisation and their network, and can be a difficult and time consuming task. This type of is normally implemented using a hybrid system of signature and anomaly-based techniques, such as the Policy-based detection available in some Cisco IPS Sensors. can combine detection methods, to provide broad detection capabilities. Combining signature-based detection with stateful protocol analysis is common in many sensors. In Network it is now common to also incorporate some anomaly-based detection to analyse network protocols. For example, a stateful engine may parse traffic for connections, which are then analysed for anomalies as well as compared against signatures. Prevention Preventions s (IPS) have grown out of IDS, and include all the characteristics of IDS, but take things a step further by including Prevention. They can be distinguished from IDS by one important feature: they attempt to respond to the intrusion and stop the attack happening, rather than just monitoring and reporting the attack. An IPS is regarded as an IDS, allowing the monitoring for possible attacks, but with additional capabilities to respond to the attack while it is occurring; preventing its success. Response In the event of malicious or unauthorised activity being detected, actions may be taken to correct or block the offending events. These counter-measures are known as an intrusion response. A response from an can be passive, active or a hybrid of the two. An active response takes action on the intrusion directly, hopefully stopping the malicious event which has been detected. A passive response logs the details of the possible intrusion and can also report this to an administrator (same as IDS response). A hybrid response would stop the intrusion, and also log and possibly notify an administrator. Responses for different types of are detailed in the next section. 6.3 & Prevention Types are categorised as either, Host-Based s (HIDS), s (NIDS) or a Hybrid of the two systems. This is based on the source of the activities being monitored and audited. Both Host-based, and Network-based, IDS and IPS are shown in Figure 8 below. Network-based systems monitor network traffic on network segments for malicious network activity. Examples are shown in Figure 8, on the DMZ, and both outside and inside the perimeter firewall. Host-based monitor a single host for suspicious events on that host only, typically via audit data from the host OS. For example, running on user host machines, or on DMZ s; as illustrated on the figure. Network Security & Prevention s - Rich Macfarlane 10

11 Untrusted Internet Eve (NIDS) Trusted Internal Network Prevention HIDS Prevention (NIPS) DMZ HIDS FTP (NIDS) Bob Host-based (HIDS) Web Prevention Host-Based Prevention (HIPS) Figure 8 Host-based and Network-based IDS Network-based is a bit like keeping and analysing data about unusual post and parcels passing through the postal system, and reporting to the authorities about suspicious post to certain addresses. If someone receives malicious mail, the data can be searched to analyse the problem mail, and try to prevent it being delivered to the customer again. Network-based Prevention is more like x-raying parcels at a sorting office; looking for malicious packages. If any are found, they can be opened and the problem object can be removed, or the parcel can be destroyed. A lot like the x-ray machines at airports scanning luggage for problem items, such as sharp objects, which can then be removed. Network Security & Prevention s - Rich Macfarlane 11

12 Host-based is like someone, vetting your mail for you at your office, and reporting possible misue of the organisations mail system, or non work related mail. Host-based Prevention would be like somebody opening and vetting your mail, checking for malicious content, so the bad mail never reaches you. Prevention Untrusted Internet Eve (NIDS) Trusted Internal Network Prevention HIDS N Monitors Subnet Prevention (NIPS) DMZ HIDS Bob Host-based (HIDS) FTP Web (NIDS) Prevention H Monitors Host Only Host-Based Prevention (HIPS) Figure 9 Host-Based & Coverage As shown in the figure, network-based systems can monitor network traffic on entire network segments for malicious network activity, and host-based systems are restricted to the scope of a single system. 6.4 s (N) Components monitor and react to intrusions on a network segment, monitoring traffic to and from all hosts on that network segment. The components of a N system typically include network-based Sensors, and a central Monitoring and Management. The Sensors are normally implemented as standalone network appliances, as hardware add-ons to another network devices (such as firewalls or routers), or as software installed on network devices or hardened host systems. The network appliance sensor would be composed of specialised hardware and software, optimised for processes. The software could be installed on hosts which met the specifications of the software. Network Security & Prevention s - Rich Macfarlane 12

13 These Sensors then send information about suspicious events, or intrusions, back to a central management /database, and monitoring console(s). This centralised system can be used by system administrators to monitor and analyse this data. Responses can be taken, to mitigate the threats based on the type of malicious or unauthorised activity. Various types of Sensors and the central monitoring system can be seen in Figure 10. An example of an network appliance would be a Cisco IPS 4200 series sensor (1) or a Sourcefire FirePOWER device. An example of a hardware module for a network firewall, similar to the one illustrated in Figure 10 at the network perimeter, could be a Cisco ASA with Advanced Inspection and Prevention Security Services Modules (ASA SIP SSM). An example of software implemented on a host could be the open source Snort application software (2), running on a hardened Linux box. Components of a Network system: Network Sensors These monitor the different subnets around the network, and report the detected events. Central Monitoring/Management Console In an organisation there would typically be a central Monitoring Console, where the detected events can be sent, and administrators can monitor and correlate events from all over the network. The communication between the sensor and monitoring console or is almost always encrypted. Sometimes only monitoring is performed, but management would be incorporated in larger implementations, possibly with one or more management consoles. Monitoring and management consoles can analyse the events and logging information coming from the sensors, and can provide correlation functionality. Correlation of events involves matching events from more than one sensor, such as suspicious activities logged from two different sensors from the same source IP Address. events can typically also be correlated with security events from other sources, such as firewall logging. Central Database Server A repository providing storage space for sensors and/or the management console to log to. Sensor Untrusted Internet Eve (NIDS) Sensor Prevention Trusted Internal Network Sensor Prevention (NIPS) DMZ FTP (NIDS) Bob Monitoring/ Management Console Administrator Web Figure 10 Components Network Security & Prevention s - Rich Macfarlane 13

14 Sensor Deployment The Sensors can be used to monitor network traffic at various places around the network. Five recommended places are: Outside the perimeter firewall (or as part of the screening router or perimeter firewall) Sensor can monitor and log all attacks coming from the external Internet. Directly behind perimeter firewalls Can monitor attacks from external Internet, which have breached the perimeter defences, possibly to problems with the perimeter firewall policy. On DMZ networks Sensors can protect the forward facing public s, such as the e-commerce s, and their applications. On backbone network Can monitor large amounts of network traffic crossing the internal network, and can detect attacks or policy breaches carried out by internal users. On critical network segments Sensor can monitor critical services, such as farms, and by doing so concentrate the security efforts on the most important areas of the network. Each sensor, although implemented on a single device, can monitor all the traffic entering or leaving the network segment. If a suite of sensors were to be used around the network, between them they should be able to monitor, and inspect all communications within the network. This is a more scalable solution than using host-based, as new hosts, s, and network devices can be added to the network without the need for any extra Sensors to be installed. The N device, or host with software, can be stripped of any unnecessary services, hardening it against direct attacks. In some situations it can be deployed without a network address, in stealth mode, making it even more difficult for an intruder to find and compromise. Examples of network-based are Snort (2) Real Secure from ISS (3), CyberCop (4), Junipers IDP Series devices, and Cisco such as the IPS 4200 series hardware appliances, IPS hardware modules for routers and firewalls, and Cisco IPS Software running on Cisco Routers (1). Once the appropriate networks to monitor have been chosen, which type of sensor to deploy on each network segment should then be decided on. There are two main types of network-based sensor: Out-of- Line IDS Sensors, or In-line IPS Sensors. Out-of-Line IDS Sensors An out-of-line Sensor, which is sometimes also called a Passive Sensor, works on copies of the network traffic. The sensor is said to work in Promiscuous Mode, as it monitors all the network traffic passed to its network interface, traffic to and from all hosts, not just the traffic addressed to the sensor itself. They work in real time, and can respond to attacks, but cannot stop the attack from proceeding. Figure 11 shows an attack from Eve, such as a spear phishing from the Internet, aimed at infecting Bobs host machine within the trusted network. The attack has successfully evaded detection by the firewall and proceeds towards Bobs host system. A copy of the traffic is sent to the out-of-line IDS Sensor from the switch inside the trusted network. The passive IDS recognises the traffic as an attack and raises the alarm to the system administrator, who can respond to the attack. In this case the firewall policy could be reconfigured to stop future attacks of this type. Meanwhile, the attack has succeeded in reaching Bobs machine, and Bob experiences the attack. Network Security & Prevention s - Rich Macfarlane 14

15 Untrusted Internet Eve (NIDS) 2. Copy of Trafiic 1. Attack Trusted Internal Network 3. Alert 4. Reconfigure Firewall Bob Administrator 2. Attack Succeeds Monitoring/ Management Console Figure 11 Out-of-Line IDS Sensor The out-of line sensor can be connected to the network it is to monitor in several ways. The most popular are via a switch s Mirroring/Spanning Port, or using a Network Tap. A spanning port is a port on a switch which can see all the network traffic crossing the switch. If a dedicated spanning port does not exist, a switch port can usually be configured to receive copies of all the other ports traffic. A network tap is a connection to the network cable itself, which would have to be installed. Deploying Passive Sensors, out-of-line, means there is little or no affect on the throughput of that part of the network. The reason for this is that the Sensor works on copies of the traffic, so it doesn t affect the actual packet flow. Also, if the sensor fails, there would also be no affect on the network. The disadvantage to this offline IDS, is that the out-of-line Sensor monitoring copies of the traffic cannot take any immediate action, so the packets in this attack cannot be stopped. The sensor can respond by alerting a system administrator, or even directly requesting a configuration change to another security device, but this will not stop the attack which is already in progress. This may prevent that particular attacker or this attack in future, but not the current attack. In-Line IPS Sensors An In-line IPS Sensor, which is sometimes also called an Active Sensor, works on the actual network traffic. It is deployed so the traffic flows through the sensor, like a router or firewall. Many firewall devices can now contain IPS sensors, combining the two technologies. IPS In-Line Sensors can respond to attacks immediately, and stop the attack from proceeding any further in the network. This is done by dropping the packets found to contain malicious traffic, or cleaning the packets removing the malicious part before sending them on to their destination. IPS sensors are deployed, much like where firewalls would be deployed, at perimeters of networks or subnets; at the network choke points. Typically, they are positioned between internal networks, or at the network perimeter with the external Internet. An example of a Network IPS, deployed in-line would be an appliance based IPS product. These are deployed in-line with the network flow and so would have to process the appropriate amount of network traffic. Care is needed when selecting and tuning IPS sensors and has to be based on the maximum throughput needs of the network. Network Security & Prevention s - Rich Macfarlane 15

16 Untrusted Internet Prevention Eve Trusted Internal Network Prevention (NIPS) 1. Attack 2. Packets Dropped 3. Alert Bob Monitoring/ Management Console Administrator Figure 12 In-Line IPS Sensor In Figure 12 an attack is again launched from Eve, but this time an in-line IPS Sensor is in place. The IPS recognises the traffic as an attack and the active IPS can stop the attack getting any further, as it is in-line it drops the malicious packets, and it does not forward them to Bobs host machine. It then also raises the alarm to the system administrator for further analysis, and any manual response needed. Deploying Active Sensors, in-line, means there can be a negative effect on throughput of that part of the network (5). The sensor is in-line with the flow of traffic, as shown in Figure 11, and could be overrun with very high traffic loads. (attackers sometimes do this so they can sneak things past the sensor) If the sensor fails, there would also be an effect on the network, as opposed to the out-of-line solution. This means care has to be taken in the choice of IPS device size and capabilities, so they can cope with the traffic loads in the networks they are to be deployed in. With the Sensor being in-line, the big advantage is the ability to take immediate action, so packets of that specific attack could be stopped, the connection to the attacker could be blocked, or all traffic from the attacker could be blocked. The sensor can also respond by alerting a system administrator. This combination of responses can prevent the current attack, possibly that particular attacker, and possibly this attack/attacker in future. Table 2 In-Line vs Out-of-Line Sensors Out-of-Line IDS Cannot stop the current attack, can only log details, and raise alarm, which may stop future attacks. In-Line IPS Can stop the current attack before it does any harm. No performance impact on the network, as works on copies of the traffic. No performance impact if the sensor fails. Can have performance impact on the network, as traffic flows through the sensor. Can have performance impact if the sensor fails, would have to consider redundancy for this type of sensor. Network Security & Prevention s - Rich Macfarlane 16

17 Capabilities Examples of Malicious Activities and s detected by are list below, and are grouped by TCP/IP layers. Application Layer Application protocols can be monitored by network-based, remote access attacks, client side attacks using payloads such as buffer overflows, password cracking attacks, and malware propagation. Application protocols that typically would be monitored and analysed include: HTTP, DNS, FTP, DHCP, IRC, POP, SMTP, SNMP, SQL database protocols, and various peer to peer protocols. Transport Layer At the transport layer, the TCP and UDP protocols are monitored for reconnaissance attacks, access attacks, and DoS attacks. Examples include TCP or UDP port scans, TCP packet fragmentation attacks, and TCP SYN and ICMP flood attacks. Network Layer Typically, the IP and ICMP protocols are analysed at this layer, for attacks such as reconnaissance attacks, such as ICMP ping sweeps. Prevention Capabilities sensors can provide Prevention Responses to detected attacks. IDS can provide some responses, but not to stop the attack which triggered the response as they are out-of-line. IPS can provide immediate responses, and can stop the attack from progressing, as they are deployed in-line. Possible responses from sensors are listed below: End the current communication session with a potential attacker A passive or active Network- Based sensor can attempt to end the TCP session with the attacker, by sending TCP Reset (RST) packets to both client and involved in the session. The idea is to kill the session before the attack has succeeded, but generally this is not as successful as dropping packets in-line. Reconfigure Other Network Security Devices A passive or active sensor can request changes to the configuration of security settings on other network devices, such as switches, routers, or firewalls. An example would be, reconfiguring a perimeter firewall to block all traffic from the attacker s machine or subnet, or creating a quarantine VLAN for a compromised host machine, so it cannot infect other hosts on its subnet. (A VLAN is a virtual subnet to separate traffic, which can be configured on a switch) In-Line Firewalling In-Line IPS Sensors can block suspicious network traffic, at various levels. Drop all traffic from an attacker or their subnet. If the malicious activity is limited to certain application protocols only these could be blocked. Or if just the one communication session for a certain service was suspicious, then only this might be blocked. Clean Malicious Content An In-Line sensor can alter packets which contain malicious content. For example, a sensor could detect a suspicious attachment, a SQL Injection attack, or a buffer overflow, and remove it from the network traffic. Typically Application Layer data might be sanitised in this way. Throttling Bandwidth In-Line IPS sensors can reduce the amount of bandwidth available to certain protocols if suspicious activities are detected. The sensor could limit the percentage of the bandwidth certain protocols could use. This could be used to mitigate DoS attacks, worm propagation (if worm generated traffic was saturating the network), and policy breaches, such as peer-to-peer applications. Network Security & Prevention s - Rich Macfarlane 17

18 Note that blocking attackers based on IP Source Address is not always successful, as an attacker can easily spoof different addresses. Similarly blocking services based on TCP/UDP port numbers can also be evaded easily by using alternative ports or different protocols. 6.5 Host-based s (H) Host-Based sensors reside on a single end user host or, and monitor for malicious activities on that system only. They typically would be used to monitor critical s as well as end user host machines. They can monitor activities in much greater detail than a network based system, identifying the files and processes involved in the malicious events on the actual hosts. Examples of activities monitored are network traffic for that host only, system logs, processes running on the host, system settings, and file accesses. Components Host based sensors are normally implemented as software running on the protected hosts, and are often referred to as Agents. Each agent monitors a single host system for suspicious activities. In an enterprise environment, the sensors would send logging and event data to a central monitoring and management system when suspicious activities are detected, much like the network-based model. In a home, or small office situation they could be installed on stand alone systems. A network with host-based system sensors is shown in Figure 13. Administrator Untrusted Internet Eve Trusted Internal Network Monitoring/ Management Console DMZ HIDS Bob HIDS H Agent Host-based (H) FTP Host-based HIPS H Agent HIPS Web Host-Based Prevention (HIPS) H Agent Prevention Author: Rich Macfarlane Figure 13 Host-Based Components Components of a Host-based system: Software Sensors (or agents) These monitor hosts around the network, analyse the detected events, logging and raising events to the central monitoring system. Network Security & Prevention s - Rich Macfarlane 18

19 Central Monitoring/Management Console In an organisation there would typically be a central Monitoring Machine, where the detected events can be sent, and administrators can monitor and correlate events from different end user hosts and s. Central Database Server A repository for sensors and/or the management console to log to. Sensor Deployment Host-Based can be deployed on: Servers Public facing s in the DMZ segment, such as web s or DNS s, as well as internal s, such as Database s, could be protected with H software. End User Hosts H sensor software can help protect end users from attacks related to the host OS or applications like and web browsers. Host-based Sensors are normally deployed on public facing s, and s or hosts storing sensitive data, but are available to run on most Operating s, so could be installed on every host machine if necessary. Where and how many sensors are deployed would be based on many factors, such as: how important the data on the host is, the different OS s installed on the hosts involved, and the cost of deploying, monitoring and maintaining the sensors. Host-based intrusion detection is better suited to combat internal threats because of its ability to monitor and respond to specific user actions and file accesses on the host machines. Many security computer threats come from within organizations, from many different sources, such as disgruntled employees, downloaded malware, advanced targeted attacks. They also have an advantage over network-based systems, in that they can analyse encrypted data, as the data is decrypted by the time it reaches the host. Attacks can often be hidden from network-based monitoring by encrypting the communications between attack and target systems, such as is often now the case with remote access malware communications. Host-Based Capabilities Sensors can be split into three main types. Those which monitor network traffic, those which monitor host activities after the events have happened through analysis of changes to files and system resources, and those which alter the host architecture and can monitor the activities as they happen. Network traffic Analysis sensors are similar to the network-based sensors, except they would only monitor traffic for the host they are running on, via the hosts NIC rather than the entire subnet. For example, Snort can be set up as a host-based sensor, setting promiscuous mode off, which means only monitoring traffic addressed to and from the host it is running on. Figure 14 shows the two types of H which monitor files and system configurations changes after the event. Integrity Verifiers (SIV), and Log File Monitors (LFM). A SIV creates signatures for important files periodically, so it can check for changes to the files. Typically hash values are created for each file, and then compared to the stored hash value, to check if files have changes. This could detect a Trojan or Rootkit being installed, on a host, in place of an important OS file. A good example would be the Tripwire (6), a file integrity checker system, which analyses file systems. Trip wire is shown in Figure 15; the rear window shows Tripwire Nodes view - showing the sensors on various devices, and the front window shows some of the rules used to monitor a specific. Network Security & Prevention s - Rich Macfarlane 19

20 Integrity Verifier These monitor system files to determine if an intruder has changed them (a rootkit or trojan). A good example of this is Tripwire. It can also watch other key system components, such as the Windows registry and root/ administrator level privileges for changes. 29/05/ : zhp1020.log 04/08/ :00 337,920 zipfldr.dll 21/07/ :00 102,400 ZLhp1020.dll 13/03/ :46 53,248 zlib.dll 21/07/ :00 28,672 zlm.dll Log file monitors (LFM) These monitor log files which are generated by network services, and look for key patterns of change. Swatch is a good example. Figure 14 Host-Based - File Modification & Log File Analysis Host-Based Sensor Figure 15 Tripwire Network Security & Prevention s - Rich Macfarlane 20

21 Other file system monitoring can be done on attributes of files, for characteristics like ownership, file size, and file accesses. Log file analysis can be done by sensors, analysing the information on system events, such as services starting or ending, or the shutting down or restarting of the host machine. Audit logs can be analysed for signs of malicious activity, such as user authentication access attempts, and application configuration changes. The other type of Host-based agent monitors activities as they happen. Analysis of executing code is one method which can stop attacks as they occur. Code could be run in a virtual environment before it is run on the live system, to check it does not perform any malicious activities (a virtual sandbox). Signatures can be used to detect attacks like buffer overflows or other access attacks, before the code is run. The sensor can have profiles, which specify which applications can call other applications or have access to system calls. This type of system is implemented using a shim; a layer of code installed to intercept executing code, and decide whether it should be allowed to run or not. Figure 16 shows this architecture. Cisco Security Agent (CSA ) host-based software can police a policy by allowing or rejecting access to applications and system process calls in this way. Alter Host Internal Architecture These use a Shim, a layer of code installed between other layers of code, to analyse the data passed between the layers of code. An example of this would be Cisco CSA. Host-based Rules & Policies Successful Request File Resources Application Blocked Request Host-Based Shim Applications Operating Resources Network Resources Author: Rich Macfarlane Figure 16 Host-Based - Alter Host Internal Structure A disadvantage of host-based is that it can be easier for an attacker to find and disable than a Networkbased system. Network-based systems can be made to be invisible on the network, were as host-based sensor software is running on every host, and can be attacked directly, or affected if the OS is attacked. They can also be a drain on the performance of the system being monitored, and are limited to the host computers logging and auditing capabilities. HIDS are generally more expensive to deploy and maintain, as they have to be installed, monitored and managed on every host in a network, compared to a single NIDS per network. Network Security & Prevention s - Rich Macfarlane 21

22 Host-Base Prevention Capabilities Responses to malicious activities by host-based s: Stop Code Executing Code Analysis techniques can stop malicious code from running, stopping attacks like malicious software or unauthorised applications which breach the organisations security policy. Block Network Traffic If a network analysis system is installed, the same prevention capabilities as network-based IPS can be used. Stop File Activities If a code analysis or file system monitoring sensor is being used, files can be protected from inappropriate file accesses. Kill/Restart Suspicious Process Table 3 is a summary of the differences between Network-based systems and Host-based systems. Table 3 vs Host-Based Can monitor an entire network segment, analysing traffic to and from all hosts (broad scope). More scalable, and cheaper to implement, due to single sensor monitoring many hosts. Easier to implement. Better at detecting external attacks. Operating independent. Cannot examine contents of encrypted traffic. Cannot assess whether an attack is successful or not. Host-Based Monitors a single host (narrow scope). Less scalable, and more expensive to implement, as one sensor per host needed. More complex to implement. Better at detecting internal attacks. Operating dependent. Encrypted traffic is decrypted on host, so H can monitor it. Can monitor, or stop, attacks on the host as they take effect. 6.6 Hybrid s Hybrid intrusion detection and prevention systems offer management, and alert notification from both network and host-based intrusion detection sensors. A Hybrid system might be used in an enterprise solution, and would provide the best from both types of system. Using a mix of vendors and network and host-based sensor agents can provide a comprehensive solution, with the host-based agents providing another chance to catch an intrusion if the network based sensors miss an event. A hybrid solution is shown below. Network Security & Prevention s - Rich Macfarlane 22

23 Administrator Untrusted Internet Eve Trusted Internal Network Monitoring/ Management Console Prevention Prevention HIDS DMZ Prevention HIDS Bob Host-based Prevention Host-based FTP Web Host-Based Prevention Prevention Author: Rich Macfarlane Figure 17 Hybrid 6.7 Alert Monitoring and Event Management Alerts and logging data can be sent to a central, and/or console, where the system administrator can monitor, validate, analyse and respond to the intrusion alerts raised. Events can be monitored in real time, by an administrator via a monitoring console(s), and a range of associated data would also typically be logged and used later to validate the security events, for deeper analysis, and to produce reports. Sensor Logging Servers Logs Logs Alerts Archived Data or Network Activities Alerts/Events Prevention Monitoring/ Management Consoles Administrator Rules & Policies Reports data can be sent to the central s or console in-band, over the production network, or in larger organisations a separate security out-of-band (OOB) management network may be used. A less expensive Network Security & Prevention s - Rich Macfarlane 23

24 solution that a separate network is to use the existing network, but creating a virtual LAN (VLAN) to segregate security traffic. Depending on the number of sensors in use around the network, more than one central and console may well be needed. For example, Cisco recommends 25 or less sensors per management console, but the numbers will depend on how many alerts the sensors are producing. If they are badly tuned, they could be producing a lot of unnecessary false positives, which would tend to consume more resources than necessary. Untrusted Internet Eve Administrator Network-based Admin Server & Monitoring Console DMZ HIDS Bob HIDS Host-based (HIDS) Web FTP Host-based (HIDS) Figure 18 Central IDSP Monitoring Some sensors may also produce a large amount of alerts due to their location, such as the out-of-line IDS sensor in front of the firewall shown in Figure 18, and may need a separate monitoring console of their own. The reduction of FALSE Positives, by analysing the logs to help tune sensors, is another way the system administrator would use the monitoring and analysis system. Parsing and analysing the logs can be done with command line tools such as the Unix/Linux grep tool (7), which is fantastic for parsing text files, using pattern matching regular expressions. Many utilities with easy to use GUI front end can also be used to analyse the logs, such as general purpose tools like Splunk (8) or products created specifically for analysing sensor data, such as Cisco MARS, or ACID which can be used as a monitoring and analysis console for a variety of IDS Sensors. An example of a fully functional central monitoring system is the Cisco Monitoring, Analysis and Response (MARS) (9). This is a network appliance based system which can receive security events from a variety of devices and hosts, from various vendors. It can then correlate events to isolate attacks, and suggest response actions. Network Security & Prevention s - Rich Macfarlane 24

25 Administrator Figure 19 Cisco MARS Cisco MARS also has an extensive range of reporting capabilities, including the following standard reports. A report is shown in the front window in Figure Hour Alarm Metrics 30 Day Alarm Metrics 30 Day Details: Alarm Destinations 30 Day Details: Alarm Source/Destination pairs 30 Day Details: Alarm Sources 30 Day Details: Alarms 30 Day Details: Alarms by Hour/Day 30 Day Details: Top 50 Alarms 30 Day Details: Top 50 Alarm Destinations 30 Day Details: Top 50 Alarm Source/Destination pairs 30 Day Details: Top 50 Alarm Sources 30 Day Alarm Summary Detailed Alarms By Sensor A central monitoring and analysis can easily be set up for open source sensors such as Snort, using a variety of products. An easy and cost effective solution is using a mysql database, and a free console application such as Analysis Console for Databases (ACID) (10) or Basic Analysis and Security Engine (BASE). These are free to download, web-based front end monitoring Network Security & Prevention s - Rich Macfarlane 25