Monitoring Systems: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
(6 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
=== IDS - Intrusion Detection Systems === |
|||
*[http://www.informatik.hu-berlin.de/~edel Stephan Edel] |
|||
*Anne Walther |
|||
*presentation date: 01/04/2005 |
|||
== |
== Motivation == |
||
* Protective measures like firewalle reduce the attack risk, but cannot totally eliminate it |
|||
*Intrusion Detection with [[http://www.snort.org Snort]] |
|||
** e.g. bogus packer headers can lead to an attack not being detected |
|||
* |
|||
* are principally "burglar alarms" |
|||
* |
|||
* are employed for automated attack detection -> by monitoring accordance with provided security guidelines / rules |
|||
* possible statements produced by an analysis are e.g.: |
|||
** accordance with security guidelines |
|||
** violation of security guidelines |
|||
** suspective behaviour |
|||
* about attackers: |
|||
** from the outside |
|||
** from the inside: according to a study by the FBI, the larger part of network attacks originates from its inside (Insiders know more about a systems architecture, protective measures etc.) |
|||
** types: vandalism / espionage / just for fun / find security flaws in cooperation with the host |
|||
* maybe a better name would be "Signature Compare System" or "Signature Compare Automaton" |
|||
== timing behaviour == |
|||
* Realtime IDS - reports suspected intrusions which are proceeding (e.g. by network packet analysis) |
|||
* Standard IDS - reports sucessful attacks (e.g. by logfile analysis) |
|||
== architectures == |
|||
'''HIDS - host-based IDS''' |
|||
* receive their audit files from a host |
|||
* use e.g. log files |
|||
* system manipulations can be detected using checksums |
|||
* by these mechanisms, attacks can only be detected when they already have occured -> forensic use |
|||
* examples: |
|||
** sXid - monitors SUID/GUID files |
|||
** Tripwire - monitors file integrity (employing a database and hash functions to detect changes) |
|||
logcheck - logfile analysis by provided strings which are classified as |
|||
security relevant: denied / failed; security violations: login root refused |
|||
'''NIDS - network-based IDS''' |
|||
* analyzes network data |
|||
* NIDS come in different flavours: |
|||
** sensor-based system: has a network interface to "`sniff"' on the traffic |
|||
** agent-based system: agents are installed on the monitored systems to catch the packets (from the different of the TCP/IP stack) and send them to a centralised unit for analyis. |
|||
* Position: |
|||
** between "outside world" and firewall, but before the internal network -> interesting to get an overview, but not a good choice on the long run because too much data is collected (..every portscan is recorded) |
|||
** behind firewall, inside the local network -> can be used as a controlling device, unusal activities from local hosts are also reported |
|||
** between 2 firewalls -> does not have to react on every single portscan, can be used to monitor inbound as well as outbound traffic |
|||
** multiple sensors -> are useful in larger networks, collected data can be sent to a central analysis unit |
|||
'''hybrid forms''' |
|||
* combinations of HIDS and NIDS |
|||
* by partial data analyis on each host the central analysis unit can be relieved of some load |
|||
== analysis techniques == |
|||
'''misuse detection''' |
|||
* works similar to virus scanners |
|||
* detection by known signatures |
|||
* pattern matching -> incoming pattern is compared to known attack patterns from a database |
|||
* signs of an attack: |
|||
** malformed network packets (big / small / characteristic sub-strings in packet data) |
|||
** unusual protocols |
|||
** access to certain ports |
|||
* Disadvantage: only known attack methods can be detected. An up-to-date attack database is essential! |
|||
''State Transition'' |
|||
* another misuse detection technique |
|||
* every state represents a state of the system / each transition is an action |
|||
* state-transition diagram for every attack pattern |
|||
* when system activity occurs, the analysis unit can change the state of the state automaton |
|||
* (+) probability and proceeding of an attack can be modelled / some prediction can be made on the attackers next actions |
|||
* (+) an attack is modelled on a very abstract basis / attack variants can be modelled with small additional automatons |
|||
* (+) coordinated and slowed attacks can be detected! |
|||
* next stage of development: colored Petri nets |
|||
'''Anomaly Detection''' |
|||
* is not based on a static dataset |
|||
* assumption: every behaviour that is not normal is an attack / suspective behaviour |
|||
* the system has to "learn" for severeal weeks what normal behaviour means |
|||
* this must be done while the systems integrity is certainz |
|||
* an IDS may register e.g. |
|||
** protocols |
|||
** ports |
|||
** attributes of system critical files (rights / users / size / modification date etc.) |
|||
* when the learing phase is completed, learned behaviour is considered normal, everything else as anomalous. |
|||
''Quantitative Analysis'' |
|||
* Treshold Detection: |
|||
** system and user activities are represented by counters: |
|||
** exceeding a treshold is reported as possible attack |
|||
** simple example: system log in, threshold of 3 -> 3 failed logins - user account is blocked |
|||
* extension: heuristical treshold analyis |
|||
** treshold is not fixed, but adjusted dynamically |
|||
** in our example: the treshold is computed from the users past login activities |
|||
* integrity checking |
|||
** changes to system objects that may not be changed (data, programs, hardware) are monitored |
|||
''Statistical Analysis'' |
|||
* IDS keeps statistical profiles on each users normal behaviour |
|||
* security alert is defined as strong deviation from this normal behaviour |
|||
* (+) attackers using a "hijacked" account can be detected |
|||
* (+) previously unknown patterns and methods of attack can be recognized |
|||
* (-) bad real-time behaviour: all actions must have already happend to see if they are normal |
|||
* (-) may pose too many restrictions on users |
|||
* (-) may simplify "social monitoring" ("`..user X sends emails after lunch break"') |
|||
''rule-based systems'' |
|||
* operation similar to statistical systems (rules are defined instead of statistics) |
|||
* rules may be user-defined or derived from data analyis |
|||
* special subclass: Time-Based-Indictive IDS |
|||
** monitors sequence of system operations |
|||
** an anomaly is detected if order of events is not correct |
|||
''neuronal networks'' |
|||
* network is trained on "clean" data |
|||
* learning ability makes neuronal networks wells suited for anomaly detection |
|||
* (-) does not report type of attack |
|||
* solution: one network for each type of attack (e.g. SYN-flooding) |
|||
'''Strict Anomaly Detection (Burglar Alarm / Passive Traps)''' |
|||
* assumption: everything that is not explicitely permitted is an attack |
|||
* employs pattern matching |
|||
* normal system behaviour provided in a database |
|||
* every deviant system behaviour is reported as an attack |
|||
* (+) fewer patterns must be saved in the database |
|||
* (+) updates to the database are only needed when the system is changed |
Latest revision as of 04:13, 11 February 2005
IDS - Intrusion Detection Systems
Motivation
- Protective measures like firewalle reduce the attack risk, but cannot totally eliminate it
- e.g. bogus packer headers can lead to an attack not being detected
- are principally "burglar alarms"
- are employed for automated attack detection -> by monitoring accordance with provided security guidelines / rules
- possible statements produced by an analysis are e.g.:
- accordance with security guidelines
- violation of security guidelines
- suspective behaviour
- about attackers:
- from the outside
- from the inside: according to a study by the FBI, the larger part of network attacks originates from its inside (Insiders know more about a systems architecture, protective measures etc.)
- types: vandalism / espionage / just for fun / find security flaws in cooperation with the host
- maybe a better name would be "Signature Compare System" or "Signature Compare Automaton"
timing behaviour
- Realtime IDS - reports suspected intrusions which are proceeding (e.g. by network packet analysis)
- Standard IDS - reports sucessful attacks (e.g. by logfile analysis)
architectures
HIDS - host-based IDS
- receive their audit files from a host
- use e.g. log files
- system manipulations can be detected using checksums
- by these mechanisms, attacks can only be detected when they already have occured -> forensic use
- examples:
- sXid - monitors SUID/GUID files
- Tripwire - monitors file integrity (employing a database and hash functions to detect changes)
logcheck - logfile analysis by provided strings which are classified as security relevant: denied / failed; security violations: login root refused
NIDS - network-based IDS
- analyzes network data
- NIDS come in different flavours:
- sensor-based system: has a network interface to "`sniff"' on the traffic
- agent-based system: agents are installed on the monitored systems to catch the packets (from the different of the TCP/IP stack) and send them to a centralised unit for analyis.
- Position:
- between "outside world" and firewall, but before the internal network -> interesting to get an overview, but not a good choice on the long run because too much data is collected (..every portscan is recorded)
- behind firewall, inside the local network -> can be used as a controlling device, unusal activities from local hosts are also reported
- between 2 firewalls -> does not have to react on every single portscan, can be used to monitor inbound as well as outbound traffic
- multiple sensors -> are useful in larger networks, collected data can be sent to a central analysis unit
hybrid forms
- combinations of HIDS and NIDS
- by partial data analyis on each host the central analysis unit can be relieved of some load
analysis techniques
misuse detection
- works similar to virus scanners
- detection by known signatures
- pattern matching -> incoming pattern is compared to known attack patterns from a database
- signs of an attack:
- malformed network packets (big / small / characteristic sub-strings in packet data)
- unusual protocols
- access to certain ports
- Disadvantage: only known attack methods can be detected. An up-to-date attack database is essential!
State Transition
- another misuse detection technique
- every state represents a state of the system / each transition is an action
- state-transition diagram for every attack pattern
- when system activity occurs, the analysis unit can change the state of the state automaton
- (+) probability and proceeding of an attack can be modelled / some prediction can be made on the attackers next actions
- (+) an attack is modelled on a very abstract basis / attack variants can be modelled with small additional automatons
- (+) coordinated and slowed attacks can be detected!
- next stage of development: colored Petri nets
Anomaly Detection
- is not based on a static dataset
- assumption: every behaviour that is not normal is an attack / suspective behaviour
- the system has to "learn" for severeal weeks what normal behaviour means
- this must be done while the systems integrity is certainz
- an IDS may register e.g.
- protocols
- ports
- attributes of system critical files (rights / users / size / modification date etc.)
- when the learing phase is completed, learned behaviour is considered normal, everything else as anomalous.
Quantitative Analysis
- Treshold Detection:
- system and user activities are represented by counters:
- exceeding a treshold is reported as possible attack
- simple example: system log in, threshold of 3 -> 3 failed logins - user account is blocked
- extension: heuristical treshold analyis
- treshold is not fixed, but adjusted dynamically
- in our example: the treshold is computed from the users past login activities
- integrity checking
- changes to system objects that may not be changed (data, programs, hardware) are monitored
Statistical Analysis
- IDS keeps statistical profiles on each users normal behaviour
- security alert is defined as strong deviation from this normal behaviour
- (+) attackers using a "hijacked" account can be detected
- (+) previously unknown patterns and methods of attack can be recognized
- (-) bad real-time behaviour: all actions must have already happend to see if they are normal
- (-) may pose too many restrictions on users
- (-) may simplify "social monitoring" ("`..user X sends emails after lunch break"')
rule-based systems
- operation similar to statistical systems (rules are defined instead of statistics)
- rules may be user-defined or derived from data analyis
- special subclass: Time-Based-Indictive IDS
- monitors sequence of system operations
- an anomaly is detected if order of events is not correct
neuronal networks
- network is trained on "clean" data
- learning ability makes neuronal networks wells suited for anomaly detection
- (-) does not report type of attack
- solution: one network for each type of attack (e.g. SYN-flooding)
Strict Anomaly Detection (Burglar Alarm / Passive Traps)
- assumption: everything that is not explicitely permitted is an attack
- employs pattern matching
- normal system behaviour provided in a database
- every deviant system behaviour is reported as an attack
- (+) fewer patterns must be saved in the database
- (+) updates to the database are only needed when the system is changed