Get 30% off ITprotv.com with:
or You can use promo code: OSCAROGANDO2
Follow me on Twitter:
A signature is a set of rules that an IDS and an IPS use to detect typical intrusive activity, such as DoS attacks. You can easily install signatures using IDS and IPS management software such as Cisco IDM. Sensors enable you to modify existing signatures and define new ones.
As sensors scan network packets, they use signatures to detect known attacks and respond with predefined actions. A malicious packet flow has a specific type of activity and signature, and an IDS or IPS sensor examines the data flow using many different signatures. When an IDS or IPS sensor matches a signature with a data flow, the sensor takes action, such as logging the event or sending an alarm to IDS or IPS management software, such as the Cisco SDM.
Signature-based IDS/IPS: A signature-based approach is usually the starting point of an effective intrusion detection architecture. A signature-based IDS or IPS sensor looks for specific, predefined patterns (signatures) in network traffic.
It compares the network traffic to a database of known attacks, and triggers an alarm or prevents communication if a match is found. The signature can be based on a single packet or a sequence of packets.
New attacks that do not match a signature do not result in detection. For this reason, the signature database needs to be constantly updated. Why it is important to keep your HIPS and NIPS uptodate.
Anomaly-based IDS/IPS: Anomaly-based (or profile-based) signatures typically look for network traffic that deviates from what is seen “normally.”
The biggest issue with this methodology is that you first must define what normal is. If during the learning phase your network is the victim of an attack (or some other anomalous event takes place) and you fail to identify it, the anomaly-based IPS will interpret that malicious traffic as normal, and no alarm will be triggered the next time this same attack takes place.
Some systems have hard-coded definitions of normal traffic patterns.
6.2.c Trigger actions/responses (drop, reset, block, alert, monitor/log, shun)
For IDS and IPS:
Alerts: Generationof a loggable message upon detection of potentially malicious traffic flows. How alerts are used is dependent on the size and complexity of the deployment. Alerts should always be stored in a database so records can be reviewed later for forensic analysis.
Monitor: An IDS mayreact to suspicious events by concentrating more resources on traffic that is associated with a particular host or between a pair of hosts. For example, it may include a packet capture in the data that is logged
IPS technology only:
Drop: Packets that are determined to have suspicious payload may be dropped by the sensor, preventing the payload from reaching the destination.
Reset: When a suspicious payload is detected with a TCP connection, the sensor may inject TCP resets to cause the offending TCP connection to be terminated.
Block: A reset only functions with TCP. Attacks may be carried out using other protocols, such as UDP and ICMP. Also, it is possible for an attacking system and a compromised host to break the normal rules of TCP and ignore the TCP reset to counter the IPS reaction. Additional protection can be provided by blocking further traffic. A block may be implemented for a particular session, or between a particular pair of hosts, or for all traffic that is associated with a single host.
Shun: Some IPSs have the ability to request that blocking be performed by other devices in the network. In some deployments, this dynamic blocking between security zones within a network is controlled by the SIEM. This action is often referred to as shunning. The term originates from the Cisco ASA security appliance command that is used to initiate the requested block.
Blacklisting: Youcan blacklist (deny traffic to and from) specific IP addresses that might pose a danger to your network. To help you build blacklists, the IPS can dynamically download, at configurable intervals, a collection of IP addresses that have been determined by the Cisco Collective Security Intelligence team (Talos, talosintel.com) to have a poor reputation.