SIEM in practice: make friends with Prelude + Cisco IPS and identify the operation of HeartBleed through correlation
Good day to all!
The SIEM theme itself has been popular lately. In view of the complex complexity of these systems, the issues associated with their use are deep and voluminous. There are quite a lot of articles (on Habré and not only) on SIEM. However, overwhelmingly, they touch upon the topic from the point of view of theory, methodology, and general principles for constructing processes. But there areabsolutely no catastrophically few articles describing the practical aspects of the application / configuration of these systems. This article describes how to practice making friends IPS and SIEM using the example of Cisco IPS and Prelude, as well as an example of a correlation rule that allows you to identify the successful operation of the HeartBleed vulnerability that has been painful in recent days.
So, we implemented IPS in Inline , what next?
Obviously, the next step is to somehow ensure that the IPS catches, in what quantity, who is attacked from and where.
To be more specific:
To solve such problems, you need to choose a convenient and at the same time functional tool.
')
There are many ways to collect and process events from IPS.
From the regular event viewers from Cisco sensors there are such options:
This tool, the principle of action of which can be described as "in the forehead." Each sensor has its own local repository of events. Of course, you can only see in it what was detected directly on a specific sensor.
Any grouping / aggregation of events on any grounds is not provided. The maximum that you can afford is to filter the displayed events by a number of criteria (signature severity, sample time, show / not show system sensor events). The listing itself is as follows:
Actually, it makes sense to use this functionality either for debug (when transmitting events to external systems), or when a single sensor is used in an organization (although, even for such a situation, the solution, to put it mildly, is not the most convenient).
The next “native” alternative to the previous tool is IME. This is a free solution from Cisco that allows configuration and monitoring of events for up to 10 IPS sensors. In terms of configuration, it is worth noting that here we are talking about a common console for devices, i.e. There is no possibility to create configuration policies (with the exception of three parameters related to the Global Correlation, Reputation Filtering and Network Participation functions).
As for the collection of events, the situation is already much better here: alerts from various sensors are collected in a common database.
Collecting events from both IPS applins / modules and IOS-IPS routers are supported. There is the possibility of grouping and filtering events for various reasons. In each event, you can “fail” to view more detailed information:
Another useful feature of IME is the ability to notify via email about events received from IPS. There are only two criteria for selecting alerts: Attack Severity Rating and RiskRating.
Although IME is a fairly functional tool, it is not without some limitations. One of the major drawbacks is that IME is not a client-server system, but in essence is a regular application using the MySQL database. In previous versions, IME was not even supported on server and x64-bit operating systems. Also restrictions are the maximum number of supported devices (no more than 10) and the number of events processed per second (100 EPS).
CSM is positioned as a full-fledged Enterprise solution designed for centralized management of various devices (IPS, ASA / PIX, IOS routers, etc.). The number of devices that can be controlled depends on the purchased license. The control itself is already carried out on the basis of policies: a reference set of settings can be made, which can later be replicated.
In terms of collecting, storing and displaying events, CSM is very similar to IME:
Here, as in IME, it is possible to group / aggregate and filter the displayed events by various criteria. In addition to IPS events, the CSM also has the ability to track events from ASA / FWSM / PIX firewalls.
In each alert, you can also “fail” to view more detailed information:
Although CSM is positioned as an Enterprise solution, in contrast to the same IME, it does not know how to build alerts with IOS-IPS (but at the same time knows how to configure them through policies). Also, CSM does not know how to e-mail alerts about events captured by IPS.
The solutions described above are good each in its own way. But, from the point of view of gathering events, they are quite narrowly focused: apart from events from IPS (and from firewalls, in the case of CSM), we cannot see anything more in them.
Quite often in my practice, colleagues from neighboring departments have questions:
In such cases it becomes necessary to check events from routers, switches, logs from unix / windows, logs of specific systems, antiviruses, mail gateways, etc. In fact, this list is endless.
Moreover, we can compare all this among themselves according to some criteria (to make a correlation), get additional information about the hosts participating in the event on the go: what kind of resource is vulnerable or not, which ports are open, etc.
This is where SIEM systems come to the rescue. All of the above, they are able to do, and with due diligence - also automated.
One of these systems is a little-known beast in Runet, named Prelude. About him and will be discussed.
Why precisely about him?
At the heart of Prelude is the IDMEF format, which predetermines the fields in the received messages. In addition to the predefined fields, you can also create your own, with a given name and format (additional data), where you can write everything that does not fit into the standard fields. Based on the data recorded in different fields, filtering, aggregation and correlation of events can be carried out.
In a simplified version, the system architecture can be represented as follows:
Manager - is the core of the system. Responsible for receiving already normalized (steamed) events from LML agents, a correlation module, third-party systems or subordinate managers (available in the commercial version). Received messages are written to the database. Also responsible for email alerts.
LML is a system agent and main event provider. Receives logs from various systems (via a local file or via syslog on a UDP port). The resulting logs are parsed / normalized based on a set of rules consisting of regular expressions. Normalized events are given by the Manager. LML can work either locally (on the same server as Manager) or remotely.
Correlator - correlation module. Connects to the Manager as an agent. Correlates incoming events to the Manager based on plug-ins implemented as Python scripts.
DataBase is the database itself, where all events processed by the system are stored.
3 rd Party Systems are third-party systems with IDMEF support that allow you to connect them directly to the Manager.
Prewikka - the main interface of the system, implemented on the Web. Designed to display processed events, their aggregation / filtering, display statistics, etc.
It looks like this:
Events are displayed in a table, the columns of which contain information about / about:
The number of IDMEF fields displayed depends on the type of event and its processing rule. Some fields can be indexed, i.e. contain multiple values. For example, there may be two fields of userid.name, in one of which the value samaccountname will be written, and in the second - the SID of the same account. And, for example, in the case of an event from the system of checking the integrity of files in the information about the source and target, neither the address, nor the port, nor the protocol will be displayed - these fields will be occupied with information about the modified file, checksums and other additional information.
In any event, you can "fail" to view more detailed information:
Before connecting IPS to our system as a source, you need to understand how you can get the alerts stored in it from the IPS.
There are two methods for transmitting events from Cisco sensors (and one half-method for IOS-IPS) to external systems:
1) Via SNMP Trap , which is sent by the sensor itself upon the signature or system event triggering.
The traps sent by the sensor are as follows:
2) Through the SDEE standard. In this case, the IPS-sensor works as a Web-server, and external systems independently connect to it and pick up new alerts. This method is used in CSM and IME products. In Cisco, the SDEE standard uses the CIDEE extension, which describes additional fields.
You can view the SDEE-alerts in “pure form” through the browser, scoring https: // <sensor-ip-address> / cgi-bin / sdee-server in the address bar (you will need to be authenticated).
The alerts themselves look like this:
A little ahead, it is worth noting that the use of SDEE has its pros and cons. The data received via SDEE contains more information about the alert compared to the SNMP trap. For example, here there is information about the actions taken by the sensor. But to export data via SDEE to SIEM, a special connector is required (in the Prelude it is only in the commercial version).
3) Via syslog (only for IOS-IPS). For completeness, it is also worth noting some features of IOS-IPS. They also support SDEE, but do not know how to send alerts via SNMP. Unlike its “elder” brothers, IOS-IPS is able to write information about alerts in the local syslog-storage of the router. Syslog router in turn can be transferred to an external server. However, the data that is written to the syslog is extremely scarce:
For iOS 12.x :
Not even the name of the signature. Only her SingatureID and SubsibgnatureID.
For iOS 15.x :
But through SDEE the same alerts will be presented already in the “normal” form, i.e. with detailed information:
To implement the conceived version of OSS, only the version with SNMP traps is suitable.
The connection scheme will look like this:
You must first install and configure the Prelude itself. How to do this has already been described here .
In addition to Prewikka and prelude-manager, we will need prelude-lml and prelude-correlator .
Also, additional information can be found on the official website Prelude .
To process the snmp traps, you will need to configure the snmptrapd daemons and rsyslogd (or equivalent).
The main task is to take snmp-traps and write them to a file.
You can do this, for example:
snmptrapd.conf
rsyslog.conf
The next step is to make our sensor send snmp-traps every time the signatures are triggered, as well as in case of errors on the sensor itself. To do this, globally enable SNMP Traps and specify the target server and community where to send them:
In addition, it is necessary for all RiskRating ranges (we do not want to lose sight of anything) to assign the “Request SNMP Trap” action via the Event Action Override:
After these settings, when an IPS is triggered, events should start to appear in our log / var / log / snmptrapd :
Here 10.0.0.1 is the address of the IPS-SENSOR-01 sensor, 192.168.0.1 is the address of the prelude-server server where Prelude and snmptrapd are actually installed.
Now you need to configure the part where all the “magic” of turning the SNMP-Trap received from the sensor into an event that will be conveniently presented in the graphical interface occurs. The prelude-lml module is responsible for this. It must be installed on the same server where SNMP traps go and is registered as an agent in prelude-manager.
Setting it up is done in several stages.
1) We define the format (and, if necessary, the encoding) of the source log. This is done in the prelude-lml.conf file :
With this setting, we specify in advance how the time format of the events entering the log looks, the name and address of the analyzer (in this case, the address of the server itself), the name and number of the process that received the log.
Later, with the immediate analysis of the event, all these values ​​can be redefined. If an event cannot be parsed by a set of rules, the values ​​determined at this stage will remain.
2) We indicate which of the incoming events which set of rules for the analysis of the log to apply. This is done in the file pcre.rules and looks like this for our example:
3) You must create the specified set of rules: cisco-ips.rules . In fact, this item deserves to devote a separate article to it. In order not to increase the volume of the article twice, I will simply list the main points:
Example: by default, we assign the severity level value to “informational” to all events. Further, if there is a different Attack Severity Rating value in the alert sent by the sensor, we rewrite our attribute. This allows you to bind, in general, to any parameter and write events to the database as we please. What level of criticality the SIEM should assign to incoming events (with or without corrective actions) is a more methodological question. With the help of the rules you can implement any convenient / favorite option.
The following set of rules was developed experimentally:
This rule set contains the following principle:
Those. Log processing according to the rule comes from the top down. But some of the rules are with chained keys ; silent; they do not participate in this processing until they are explicitly given a link from the subordinate rule ( using the optgoto key).
For IOS-IPS, you can also redirect the logs to our server and similarly apply this set of rules:
After all the above manipulations, we get the following result:
Triggers from all IPS sensors appear in the console. The screenshot above shows the grouping by source and destination addresses. Here there are both events from IPS-modules and applains, and from routers with IOS-IPS enabled (in the screenshot this is not seen due to the “obfuscation” technologies). We can group / filter by all values ​​that were determined during processing by our set of rules.
Accordingly, in any event, you can "fail" and see the details:
The final touch in the setup will be the part that distinguishes the event viewing systems from the SIEM: correlation.
For an example of setting the correlation rule, take the vulnerability that has become painful in recent days in the OpenSSL library - HeartBleed .
Cisco has a signature that allows you to catch an attempt to exploit this vulnerability: tools.cisco.com/security/center/viewIpsSignature.x?signatureId=4187&signatureSubId=0
The signature number is 4187.0, called the “OpenSSL Information Disclosure”.
By itself, the triggering of this signature will not yet mean that the vulnerability was exploited, because IPS does not know if the attacked host is vulnerable or not. But this question may well be answered by SIEM.
The general principle of the correlation rule is as follows: if the above event from IPS arrives at the SIEM, then SIEM itself checks for the HeartBleed vulnerability on the target host. In case the host is vulnerable, a separate correlation event will be created.
The rule itself looks like this:
: gist.github.com/sh1n0b1/10100394 . . /etc/prelude-correlator/heartbleed.py
IPS- 4187. -, Prelude , : -> , IPS- ( heartbleed) -> IPS -> -> .. Event Action Filter.
, :
Event Action Filter, IPS , Prelude. () – .
, Cisco 4187.0 :
, , . , '^OpenSSL Information Disclosure$|^Other security event$'. , Cisco IPS. IPS , .
web-. – , , .
– . «» python- ( — ). : ( / ), ip «», NAT- ..
SDEE.
Since OSS- Prelude, IPS Prelude SNMP ( IPS-/) syslog ( IOS-IPS). , 4- , SDEE. IPS . SDEE-, Prelude.
PreludePro:
, «» .
, .
!
_____
, :
CSM User Guide www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/4-6/user/guide/CSMUserGuide.html
IME Notification Example: www.cisco.com/c/en/us/support/docs/security/ips-4200-series-sensors/111659-ips-email-ime-config.html
IOS IPS events via IME: www.cisco.com/c/en/us/support/docs/security/intrusion-prevention-system/113576-ptn-113576.html
Prelude OSS official page www.prelude-ids.org
Prewikka: is-systems.org/siem/interface
The SIEM theme itself has been popular lately. In view of the complex complexity of these systems, the issues associated with their use are deep and voluminous. There are quite a lot of articles (on Habré and not only) on SIEM. However, overwhelmingly, they touch upon the topic from the point of view of theory, methodology, and general principles for constructing processes. But there are
1. Introduction / statement of the problem
So, we implemented IPS in Inline , what next?
Obviously, the next step is to somehow ensure that the IPS catches, in what quantity, who is attacked from and where.
To be more specific:
- You need to maintain a set of active signatures that is relevant to the protected hosts.
- For effective operation of IPS-sensors, you need to constantly “keep abreast of the pulse”: you need to constantly adapt the sensor to specific networks and traffic. This is achieved by setting up rules with exceptions.
- Among the many alerts received from IPS, it is necessary to highlight the really important and critical ones.
- For critical alerts, it is also necessary to ensure the correct set of aggressive actions (blocking traffic, resetting sessions, banning IP, etc.) taken by the sensor, as well as notifying the administrator about them.
- The state of the sensor itself also needs to be monitored (scanning engine load, update errors, license expiration dates, etc.).
To solve such problems, you need to choose a convenient and at the same time functional tool.
')
2. “Regular” means of viewing IPS events
There are many ways to collect and process events from IPS.
From the regular event viewers from Cisco sensors there are such options:
2.1 Viewing events locally on the sensor
This tool, the principle of action of which can be described as "in the forehead." Each sensor has its own local repository of events. Of course, you can only see in it what was detected directly on a specific sensor.
Any grouping / aggregation of events on any grounds is not provided. The maximum that you can afford is to filter the displayed events by a number of criteria (signature severity, sample time, show / not show system sensor events). The listing itself is as follows:
Actually, it makes sense to use this functionality either for debug (when transmitting events to external systems), or when a single sensor is used in an organization (although, even for such a situation, the solution, to put it mildly, is not the most convenient).
2.2 Cisco IPS Manager Express
The next “native” alternative to the previous tool is IME. This is a free solution from Cisco that allows configuration and monitoring of events for up to 10 IPS sensors. In terms of configuration, it is worth noting that here we are talking about a common console for devices, i.e. There is no possibility to create configuration policies (with the exception of three parameters related to the Global Correlation, Reputation Filtering and Network Participation functions).
As for the collection of events, the situation is already much better here: alerts from various sensors are collected in a common database.
Collecting events from both IPS applins / modules and IOS-IPS routers are supported. There is the possibility of grouping and filtering events for various reasons. In each event, you can “fail” to view more detailed information:
Another useful feature of IME is the ability to notify via email about events received from IPS. There are only two criteria for selecting alerts: Attack Severity Rating and RiskRating.
Although IME is a fairly functional tool, it is not without some limitations. One of the major drawbacks is that IME is not a client-server system, but in essence is a regular application using the MySQL database. In previous versions, IME was not even supported on server and x64-bit operating systems. Also restrictions are the maximum number of supported devices (no more than 10) and the number of events processed per second (100 EPS).
2.3 Cisco Security Manager
CSM is positioned as a full-fledged Enterprise solution designed for centralized management of various devices (IPS, ASA / PIX, IOS routers, etc.). The number of devices that can be controlled depends on the purchased license. The control itself is already carried out on the basis of policies: a reference set of settings can be made, which can later be replicated.
In terms of collecting, storing and displaying events, CSM is very similar to IME:
Here, as in IME, it is possible to group / aggregate and filter the displayed events by various criteria. In addition to IPS events, the CSM also has the ability to track events from ASA / FWSM / PIX firewalls.
In each alert, you can also “fail” to view more detailed information:
Although CSM is positioned as an Enterprise solution, in contrast to the same IME, it does not know how to build alerts with IOS-IPS (but at the same time knows how to configure them through policies). Also, CSM does not know how to e-mail alerts about events captured by IPS.
CS-MARSThere was still such a CS-MARS system , but this project has been closed for quite some time, therefore it is mentioned only as a historical reference.
3. SIEM
The solutions described above are good each in its own way. But, from the point of view of gathering events, they are quite narrowly focused: apart from events from IPS (and from firewalls, in the case of CSM), we cannot see anything more in them.
Quite often in my practice, colleagues from neighboring departments have questions:
- We have here <channel load increased | service stopped responding | system drove off | something happened> do not know what is the reason?
- And you (at IB) didn’t notice anything suspicious there?
- etc
In such cases it becomes necessary to check events from routers, switches, logs from unix / windows, logs of specific systems, antiviruses, mail gateways, etc. In fact, this list is endless.
Moreover, we can compare all this among themselves according to some criteria (to make a correlation), get additional information about the hosts participating in the event on the go: what kind of resource is vulnerable or not, which ports are open, etc.
This is where SIEM systems come to the rescue. All of the above, they are able to do, and with due diligence - also automated.
One of these systems is a little-known beast in Runet, named Prelude. About him and will be discussed.
Why precisely about him?
- I like him.
- It works (and for quite some time).
- He has an OSS version.
- It has native compatibility with other OSS systems .
- If desired, you can connect any source that writes the log.
- You can assemble your own “Swiss knife” from it for your own tasks of identifying, investigating and reacting to incidents.
- The correlation module is implemented as plug-in scripts in Python, which means flexibility in the fullest sense of the word. A full programming language provides opportunities for writing any correlation rules.
- There is a convenient interface Prewikka.
At the heart of Prelude is the IDMEF format, which predetermines the fields in the received messages. In addition to the predefined fields, you can also create your own, with a given name and format (additional data), where you can write everything that does not fit into the standard fields. Based on the data recorded in different fields, filtering, aggregation and correlation of events can be carried out.
3.1 Prelude Architecture
In a simplified version, the system architecture can be represented as follows:
Manager - is the core of the system. Responsible for receiving already normalized (steamed) events from LML agents, a correlation module, third-party systems or subordinate managers (available in the commercial version). Received messages are written to the database. Also responsible for email alerts.
LML is a system agent and main event provider. Receives logs from various systems (via a local file or via syslog on a UDP port). The resulting logs are parsed / normalized based on a set of rules consisting of regular expressions. Normalized events are given by the Manager. LML can work either locally (on the same server as Manager) or remotely.
Correlator - correlation module. Connects to the Manager as an agent. Correlates incoming events to the Manager based on plug-ins implemented as Python scripts.
DataBase is the database itself, where all events processed by the system are stored.
3 rd Party Systems are third-party systems with IDMEF support that allow you to connect them directly to the Manager.
Prewikka - the main interface of the system, implemented on the Web. Designed to display processed events, their aggregation / filtering, display statistics, etc.
It looks like this:
Events are displayed in a table, the columns of which contain information about / about:
- Classifications of alerts (Classification) that contain fields with the name of the event, a sign of its (not) successful completion, id-events (signature number, CVE vulnerability number, etc.), event criticality, etc.
- source / target (Source / Target) containing fields with ip-address, mac-address (if it was present in the event), initial user name, process, file, etc.
- analyzer (Analyzer - event source) containing fields with ip-address, analyzer class, etc.
The number of IDMEF fields displayed depends on the type of event and its processing rule. Some fields can be indexed, i.e. contain multiple values. For example, there may be two fields of userid.name, in one of which the value samaccountname will be written, and in the second - the SID of the same account. And, for example, in the case of an event from the system of checking the integrity of files in the information about the source and target, neither the address, nor the port, nor the protocol will be displayed - these fields will be occupied with information about the modified file, checksums and other additional information.
In any event, you can "fail" to view more detailed information:
4. How to pick up events from the sensors?
Before connecting IPS to our system as a source, you need to understand how you can get the alerts stored in it from the IPS.
There are two methods for transmitting events from Cisco sensors (and one half-method for IOS-IPS) to external systems:
1) Via SNMP Trap , which is sent by the sensor itself upon the signature or system event triggering.
The traps sent by the sensor are as follows:
#012iso.3.6.1.2.1.1.3.0 15:1:47:08.58#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393729640#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 0A 0B 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 0A 07 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "Heartbleed"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "OpenSSL Information Disclosure"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 4187#011iso.3.6.1.4.1.9.9.383.1.2.6.0 0#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S785"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.14.0 "iBCRX+m57XRkOtzSnz0MSIw/CJWscqWUKqhEjadJYMWue6yLZAgTFpc8+LuL#012H/4o5rulPzbm1D9tQZ2tnoY/qfwSZ3H1VE2Wt2/rwUHcjVaKjGue9I0FdGZN#012JgpdbIcOOiBxB0T0JJ0qsqAzTMO37pf6GNOcByoHVgcgubBM2x148331MWSP#012O4hROt/p8Zpk8ZmNBIfUwy4yA0ByxPANY4e+ixHoPOe0aJGk1GUthnyAhKn8#012ztzv/kfCXHyPH5X7DBXTTXYZN+Xv6vnWYJV3tojoaOIpv6shRYLjeg84qeO5#012vY3P0uXwcYSCj1YY4rdgQpQvL8PkOxYDAgAEDgAAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "FgMCANwBAADYAwJTQ1uQnZtyC7wMvCuSqEiXz705BMwWCoUDkJ93BDPU3gAA#012ZsAUwArAIsAhADkAOACIAIfAD8AFADUAhMASwAjAHMAbABYAE8ANwAMACsAT#012wAnAH8AeADMAMgCaAJkARQBEwA7ABAAvAJYAQcARwAfADMACAAUABAAVABIA#012CQAUABEACAAGAAMA/wEAAEkACwAEAwABAgAKADQAMgAOAA0AGQALAAwAGAAJ#012AAoAFgAXAAgABgAHABQAFQAEAAUAEgATAAEAAgADAA8AEAARACMAAAAPAAEB#012GAMCAAMBQAAYAwIAAwFAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:51716"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:443"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes: context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 70#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 70#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "high" 2) Through the SDEE standard. In this case, the IPS-sensor works as a Web-server, and external systems independently connect to it and pick up new alerts. This method is used in CSM and IME products. In Cisco, the SDEE standard uses the CIDEE extension, which describes additional fields.
You can view the SDEE-alerts in “pure form” through the browser, scoring https: // <sensor-ip-address> / cgi-bin / sdee-server in the address bar (you will need to be authenticated).
The alerts themselves look like this:
<sd:evIdsAlert eventId="6821065810849" vendor="Cisco" severity="informational" cid:alarmTraits="2147483648"> <sd:originator> <sd:hostId>IPS-SENSOR-01</sd:hostId> <cid:appName>sensorApp</cid:appName> <cid:appInstanceId>27106</cid:appInstanceId> </sd:originator> <sd:time offset="240" timeZone="GMT+04:00">1392668796044445000</sd:time> <sd:signature description="TCP Drop - Segment out state order" id="1330" cid:version="S642" cid:type="anomaly" cid:created="20050304"> <cid:subsigId>17</cid:subsigId> <cid:sigDetails>TCP segment is out of state order</cid:sigDetails> </sd:signature> <sd:interfaceGroup>vsx</sd:interfaceGroup> <sd:vlan>302</sd:vlan> <sd:participants> <sd:attacker> <sd:addr cid:locality="Inside">192.168.0.1</sd:addr> <sd:port>443</sd:port> </sd:attacker> <sd:target> <sd:addr cid:locality="AS_Inside">10.10.10.1</sd:addr> <sd:port>24479</sd:port> <cid:os idSource="learned" type="windows-nt-2k-xp" relevance="relevant" /> </sd:target> </sd:participants> <sd:actions> <cid:snmpTrapRequested>true</cid:snmpTrapRequested> </sd:actions> <cid:riskRatingValue targetValueRating="medium" attackRelevanceRating="relevant">25</cid:riskRatingValue> <cid:threatRatingValue>25</cid:threatRatingValue> <cid:interface>ge0_3</cid:interface> <cid:protocol>tcp</cid:protocol> </sd:evIdsAlert> A little ahead, it is worth noting that the use of SDEE has its pros and cons. The data received via SDEE contains more information about the alert compared to the SNMP trap. For example, here there is information about the actions taken by the sensor. But to export data via SDEE to SIEM, a special connector is required (in the Prelude it is only in the commercial version).
3) Via syslog (only for IOS-IPS). For completeness, it is also worth noting some features of IOS-IPS. They also support SDEE, but do not know how to send alerts via SNMP. Unlike its “elder” brothers, IOS-IPS is able to write information about alerts in the local syslog-storage of the router. Syslog router in turn can be transferred to an external server. However, the data that is written to the syslog is extremely scarce:
For iOS 12.x :
Aug 20 14:21:35 MSK: %IPS-4-SIGNATURE: Sig:15002 Subsig:1 Sev:50 [192.168.1.1:1066 -> 10.10.10.1:5938] RiskRating:30 Not even the name of the signature. Only her SingatureID and SubsibgnatureID.
For iOS 15.x :
Mar 3 11:15:24 MSK: %IPS-4-SIGNATURE: Sig:11020 Subsig:0 Sev:25 BitTorrent Client Activity [192.168.1.1:62809 -> 10.10.10.1:6881] VRF:NONE RiskRating:25 But through SDEE the same alerts will be presented already in the “normal” form, i.e. with detailed information:
<sd:evIdsAlert eventId="139779925140" vendor="Cisco" severity="informational"> <sd:originator> <sd:hostId>IOS-IPS-ROUTER</sd:hostId> </sd:originator> <sd:time offset="0" timeZone="UTC">1397799251079951920</sd:time> <sd:signature description="Jabber Activity" id="11204" version="S588"> <cid:subsigId>0</cid:subsigId> <cid:sigDetails>jabber:</cid:sigDetails> </sd:signature> <cid:protocol>tcp</cid:protocol> <cid:riskRatingValue>25</cid:riskRatingValue> <sd:participants> <sd:attacker> <sd:addr>192.168.1.1</sd:addr> <sd:port>61208</sd:port> </sd:attacker> <sd:target> <sd:addr>10.10.10.1</sd:addr> <sd:port>5222</sd:port> </sd:target> <sd:vrf_name>NONE</sd:vrf_name> </sd:participants> <sd:actions /> <cid:interface>Fa0/1</cid:interface> <cid:vrf_name>NONE</cid:vrf_name> </sd:evIdsAlert> 5. Customization
To implement the conceived version of OSS, only the version with SNMP traps is suitable.
The connection scheme will look like this:
- IPS catches the attack and sends SNMP-Trap about it. (IOS-IPS immediately sends a log to rsyslogd).
- We accept SNMP-Trap and transmit to syslog.
- rsyslogd writes the resulting trap to the file.
- LML parses the log, normalizes it, pulls values ​​from the fields of interest to us and writes them into the appropriate IDMEF fields (mapping).
- The normalized event is passed to the Manager, which it writes to the database. After this event becomes available for viewing through Prewikka.
- Incoming events from IPS can also be sent to the correlation module (this stage will be discussed separately).
5.1 Preparation
You must first install and configure the Prelude itself. How to do this has already been described here .
In addition to Prewikka and prelude-manager, we will need prelude-lml and prelude-correlator .
Also, additional information can be found on the official website Prelude .
To process the snmp traps, you will need to configure the snmptrapd daemons and rsyslogd (or equivalent).
The main task is to take snmp-traps and write them to a file.
You can do this, for example:
snmptrapd.conf
donotlogtraps no printeventnumbers yes ignoreauthfailure yes authCommunity log,execute public traphandle default /usr/sbin/snmptthandler rsyslog.conf
if $programname == 'snmptrapd' \ then /var/log/snmptrapd & ~ 5.2 Setting on the sensor side
The next step is to make our sensor send snmp-traps every time the signatures are triggered, as well as in case of errors on the sensor itself. To do this, globally enable SNMP Traps and specify the target server and community where to send them:
In addition, it is necessary for all RiskRating ranges (we do not want to lose sight of anything) to assign the “Request SNMP Trap” action via the Event Action Override:
After these settings, when an IPS is triggered, events should start to appear in our log / var / log / snmptrapd :
Apr 18 16:01:59 prelude-server snmptrapd[11106]: 2014-04-18 16:01:59 10.0.0.1 [UDP: [10.0.0.1]:60457->[192.168.0.1]]:#012iso.3.6.1.2.1.1.3.0 24:12:04:52.86#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393753725#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 13 16 01 3B 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 13 12 01 3B 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "[ \\x26=?.]/etc/passwd[ \\x26=?]"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "Unix Password File Access Attempt"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 3201#011iso.3.6.1.4.1.9.9.383.1.2.6.0 1#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S238"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "R0VUIC9uZXdzL2luZGV4LnBocD9FTEVNRU5UX0lEPS4uLy4uLy4uLy4uLy4u#012Ly4uLy4uLy4uLy4uL2V0Yy9wYXNzd2QgSFRUUC8xLjENCkhvc3Q6IA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:22238"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:80"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes: context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 65#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 65#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "medium" Here 10.0.0.1 is the address of the IPS-SENSOR-01 sensor, 192.168.0.1 is the address of the prelude-server server where Prelude and snmptrapd are actually installed.
5.3 Configuring LML
Now you need to configure the part where all the “magic” of turning the SNMP-Trap received from the sensor into an event that will be conveniently presented in the graphical interface occurs. The prelude-lml module is responsible for this. It must be installed on the same server where SNMP traps go and is registered as an agent in prelude-manager.
Setting it up is done in several stages.
1) We define the format (and, if necessary, the encoding) of the source log. This is done in the prelude-lml.conf file :
[format=Cisco-IPS] time-format = "%b %d %H:%M:%S" prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])?: )?" file = /var/log/snmptrapd With this setting, we specify in advance how the time format of the events entering the log looks, the name and address of the analyzer (in this case, the address of the server itself), the name and number of the process that received the log.
Later, with the immediate analysis of the event, all these values ​​can be redefined. If an event cannot be parsed by a set of rules, the values ​​determined at this stage will remain.
2) We indicate which of the incoming events which set of rules for the analysis of the log to apply. This is done in the file pcre.rules and looks like this for our example:
regex=snmptrapd; include = cisco-ips.rules; 3) You must create the specified set of rules: cisco-ips.rules . In fact, this item deserves to devote a separate article to it. In order not to increase the volume of the article twice, I will simply list the main points:
- the rule set consists of a sequence of regular expressions;
- we can influence the order of their processing, as well as create "sub-rules" of various nesting;
- in each rule we can “pull out” the necessary value as a variable from the log and enter it in the corresponding IDMEF-field. This process is called mapping;
- “Sub-rules” can be called as an option, which allows changing values ​​in events depending on their composition.
Example: by default, we assign the severity level value to “informational” to all events. Further, if there is a different Attack Severity Rating value in the alert sent by the sensor, we rewrite our attribute. This allows you to bind, in general, to any parameter and write events to the database as we please. What level of criticality the SIEM should assign to incoming events (with or without corrective actions) is a more methodological question. With the help of the rules you can implement any convenient / favorite option.
The following set of rules was developed experimentally:
cisco-ips.rules
##### # Copyright (C) 2013 Vladimir Lapshin <vmlapshin at gmail dot com> # Copyright (C) 2013 lei_wulong # # This file is part of the Prelude-LML program. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; see the file COPYING. If not, write to # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. # ##### #<<ALERT<< #SIG POOL: 5000-5039 regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.4(?:\.0)? "(.+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.5(?:\.0)?; \ id=5000; \ classification.text=$1; \ assessment.impact.description=This event was generated by the Cisco IPS; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).meaning=ips_id; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.[23]\.1(?:\.0)? "(info|low|medium|high)(rmational)?"; \ id=5001; \ assessment.impact.severity=$1; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.(?:17(?:\.0)? "osIdSource=\\+?"(\S+?)\\+?" osRelevance=\\+?"(\S+?)\\+?" osType=\\+?"(\S+?)\\+?)?" (?:0\.0\.0\.0 \[)?([\w:]+?|\d+?\.\d+?\.\d+?\.\d+?)(?:\])?(?::([\d\,]+?))?"; \ id=5002; \ target(0).node.address(0).category=ipv4-addr; \ target(0).node.address(0).address=$4; \ target(0).service.port=$5; \ target(0).service.portlist=$5; \ additional_data(0).type=string; \ additional_data(0).meaning=osIdSource:; \ additional_data(0).data=$1; \ additional_data(1).type=string; \ additional_data(1).meaning=osRelevance:; \ additional_data(1).data=$2; \ additional_data(2).type=string; \ additional_data(2).meaning=osType:; \ additional_data(2).data=$3; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.5(?:\.0)? (\d+).011iso.3.6.1.4.1.9.9.383.1.2.6(?:\.0)? (\d+); \ id=5003; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).meaning=ips_id; \ classification.reference(0).name=$1.$2; \ classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$1&signatureSubId=$2; \ additional_data(>>).type=string; \ additional_data(-1).meaning=Cisco Signature Template:; \ additional_data(-1).data=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$1&signatureSubId=$2; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.13(?:\.0)? (\d+); \ id=5004; \ target(0).node.address(0).vlan_name=$1; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.16(?:\.0)? "(?:0\.0\.0\.0 \[)?([\w:]+?|\d+?\.\d+?\.\d+?\.\d+?)(?:\])?(?::(\d+?))?"; \ id=5005; \ source(0).node.address(0).category=ipv4-addr; \ source(0).node.address(0).address=$1; \ source(0).service.port=$2; chained; silent; #ANOMALY DETECTION regex=011iso.3.6.1.4.1.9.9.383.1.2.16(?:\.0)? "[\d\.\:]+"\#011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.21(?:\.0)? ".\s+adExtraData: numDestIps=\d+\S currentThreshold=\d+\S protocol=\d+; \ id=5006; \ target(0).node.address(0).category=ipv4-addr; \ target(0).node.address(0).address=0.0.0.0; \ target(0).service.port=0; \ target(0).service.portlist=0; \ additional_data(0).type=string; \ additional_data(0).meaning=osIdSource:; \ additional_data(0).data=unknown; \ additional_data(1).type=string; \ additional_data(1).meaning=osRelevance:; \ additional_data(1).data=unknown; \ additional_data(2).type=string; \ additional_data(2).meaning=osType:; \ additional_data(2).data=unknown; chained; silent; regex=\[UDP: \[([^\]]+)\]:\d+->\[[^\]]+\]\]:.012iso\.3\.6\.1\.2\.1\.1\.3\.0 \d?\d?\d?:?\d\d:\d\d:\d\d\.\d\d.011iso\.3\.6\.1\.6\.3\.1\.1\.4\.1\.0 iso\.3\.6\.1\.4\.1\.9\.9\.383\.0\.1.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.1 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.2 "[\d\w\s]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.3 "[\d\w\s]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.4 "(\S+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.1 "(info|low|medium|high)(?:rmational)?".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.2 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.3 "([^"]+)"#011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.4 "([^"]+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.5 (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.6 (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.7 "[^"]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.12 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.13 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.16 "([^"]+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.21 "\.\s+adExtraData: numDestIps=(\d+). currentThreshold=(\d+). protocol=(\d+) . ".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.25 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.26 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.27 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.42 \d+; \ id=5030; \ revision=1; \ classification.text=$5; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).name=$6.$7; \ classification.reference(0).meaning=ips_id; \ classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$6&signatureSubId=$7; \ assessment.impact.severity=$3; \ assessment.impact.type=other; \ assessment.impact.description=$4; \ source(0).node.address(0).category=ipv4-addr; \ source(0).node.address(0).address=$8; \ target(0).node.address(0).category=ipv4-addr; \ target(0).node.address(0).address=0.0.0.0; \ analyzer(0).node.address(0).address=$1; \ analyzer(0).node.name=$2; \ analyzer(0).manufacturer=Cisco; \ analyzer(0).class=IPS; \ analyzer(0).name=Cisco IPS; \ last; #>>ALERT>> #<<ERROR<< #SIG POOL: 5040-5079 regex=011iso.3.6.1.4.1.9.9.383.1.3.1 "(\w+)"; \ id=5040; \ classification.text=IPS $1 message; \ classification.reference(0).origin=vendor-specific; \ additional_data(0).type=string; \ additional_data(0).meaning=$1:; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 1#; \ id=5041; \ classification.reference(0).name=errAuthenticationTokenExpired; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 2#; \ id=5042; \ classification.reference(0).name=errConfigCollision; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 3#; \ id=5043; \ classification.reference(0).name=errInUse; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 4#; \ id=5044; \ classification.reference(0).name=errInvalidDocument; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 5#; \ id=5045; \ classification.reference(0).name=errLimitExceeded; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 6#; \ id=5046; \ classification.reference(0).name=errNotAvailable; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 7#; \ id=5047; \ classification.reference(0).name=errNotFound; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 8#; \ id=5048; \ classification.reference(0).name=errNotSupported; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 9#; \ id=5049; \ classification.reference(0).name=errPermissionDenied; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 10#; \ id=5050; \ classification.reference(0).name=errSyslog; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 11#; \ id=5051; \ classification.reference(0).name=errSystemError; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 12#; \ id=5052; \ classification.reference(0).name=errTransport; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 13#; \ id=5053; \ classification.reference(0).name=errUnacceptableValue; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 14#; \ id=5054; \ classification.reference(0).name=errUnclassified; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.2 15#; \ id=5055; \ classification.reference(0).name=errWarning; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.3 "(A global correlation update failed: Receive HTTP response failed \[\S+\].012Messages, like this one, in the category - Reputation update failure - were logged \d+ times in the last \d+ seconds\.|No installable auto update package found on server|SNMP could not get statistical value\.|error getting config)"; \ id=5070; \ assessment.impact.severity=info; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.3 "(autoUpdate successfully selected a package \S+ from the cisco\.com locator service, however, package download failed: .+|AutoUpdate exception: Receive HTTP response failed \[\S+\])"; \ id=5071; \ assessment.impact.severity=low; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.3\.3 "(Target system does not have a valid license to process the config with the version \S+)"; \ id=5072; \ assessment.impact.severity=med; chained; silent; #>>ERROR>> #<<MESSAGE TYPE<< #SIG POOL: 5080-5089 optgoto=5000-5006; regex=011iso\.3\.6\.1\.6\.3\.1\.1\.4\.1\.0 iso\.3\.6\.1\.4\.1\.9\.9\.383\.0\.1; \ id=5080; \ classification.text=IPS alert message; \ assessment.impact.description=This event was generated by the Cisco IPS; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).meaning=ips_id; \ assessment.impact.severity=high; chained; silent; optgoto=5040-5055; optgoto=5070-5072; regex=011iso\.3\.6\.1\.6\.3\.1\.1\.4\.1\.0 iso\.3\.6\.1\.4\.1\.9\.9\.383\.0\.2; \ id=5081; \ classification.text=IPS system message; \ assessment.impact.description=This event was generated by the Cisco IPS; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).meaning=ips_id; \ assessment.impact.severity=high; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.1(?:\.0)? (\d+); \ id=5082; chained; silent; regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.4(?:\.0)? "([\w\d-]+)"; \ id=5083; \ analyzer(0).node.name=$1; \ analyzer(0).name=Cisco IPS; \ analyzer(0).manufacturer=Cisco; \ analyzer(0).class=IPS; chained; silent; ### TURN OFF FLOOD ### regex=.012iso\.3\.6\.1\.2\.1\.1\.3\.0 (\S+).011iso\.3\.6\.1\.6\.3\.1\.1\.4\.1\.0 iso.3\.6\.1\.4\.1\.9\.9\.138\.2\.0\.1(?:\.0)?.011iso\.3\.6\.1\.4\.1\.9\.9\.138\.1\.3\.3\.1\.3(?:\.0)? (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.138\.1\.3\.3\.1\.4(?:\.0)? (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.138\.1\.3\.3\.1\.5(?:\.0)? (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.138\.1\.3\.3\.1\.6(?:\.0)? (\d+); silent; last; #>>MESSAGE TYPE>> #<<MAIN RULE<< #SIG POOL: 5090-5099 optgoto=5080-5083; regex=snmptrapd\[\d+\]: \d+-\d+-\d+ \d+:\d+:\d+ \d+.\d+.\d+.\d+ \[UDP: \[(\d+\.\d+\.\d+\.\d+)]:\d+->\[(\d+.\d+.\d+.\d+)\]\]:; \ classification.text=snmp unknown message; \ classification.reference(0).origin=vendor-specific; \ id=5090; \ revision=1; \ assessment.impact.severity=high; \ assessment.impact.type=other; \ assessment.impact.description=This event was generated by snmptrapd; \ source(0).node.address(0).address=$1; \ analyzer(0).node.address(0).address=$2; \ last; #>>MAIN RULE>> #EOF This rule set contains the following principle:
- The incoming log first falls under the general signature of the IPS event: rule 5090;
- optionally, the message type is checked - error / system message / alert: rules from 5080 to 5089;
- if the received message relates to an error, we define its type: rules from 5040 to 5079;
- if the received message is a signature triggering, pull out all that we are interested in: rules from 5000 to 5039;
Those. Log processing according to the rule comes from the top down. But some of the rules are with chained keys ; silent; they do not participate in this processing until they are explicitly given a link from the subordinate rule ( using the optgoto key).
For IOS-IPS, you can also redirect the logs to our server and similarly apply this set of rules:
cisco-ios-ips.rules
# # Copyright (C) 2013 lei_wulong # # This file is part of the Prelude-LML program. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; see the file COPYING. If not, write to # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. # ##### ##RULES FOR CISCO IOS-IPS### ## id pool = [580-599] regex=Subsig\:\d+\s+Sev\:25; \ id=580; \ assessment.impact.severity=info; \ silent regex=Subsig\:\d+\s+Sev\:50; \ id=581; \ assessment.impact.severity=low; \ silent regex=Subsig\:\d+\s+Sev\:75; \ id=582; \ assessment.impact.severity=medium; \ silent regex=Subsig\:\d+\s+Sev\:100; \ id=583; \ assessment.impact.severity=high; \ silent ### For IOS 12.4(11)### regex=(\d+\.\d+\.\d+\.\d+)\s+\d+\:\s+(.+?)\:.+?\%IPS-4-SIGNATURE\: Sig\:(\d+)\s+Subsig\:(\d+)\s+Sev\:(\d+)\s+\[([\d\.]+)\:(\d+)\s+\-\>\s+([\d\.]+)\:(\d+)\]\s+RiskRating\:(\d+); \ classification.text=$3.$4; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).meaning=cisco_id; \ classification.reference(0).name=$3.$4; \ classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$3&signatureSubId=$4; \ id=584; \ revision=2; \ analyzer(0).name=Cisco IPS; \ analyzer(0).manufacturer=Cisco; \ analyzer(0).class=IPS; \ analyzer(0).node.address(0).address=$1; \ analyzer(0).node.name=$2; \ assessment.impact.type=other; \ source(0).node.address(0).category=ipv4-addr; \ source(0).node.address(0).address=$6; \ target(0).node.address(0).category=ipv4-addr; \ target(0).node.address(0).address=$8; \ source(0).service.port=$7; \ target(0).service.port=$9; \ additional_data(0).type=integer; \ additional_data(0).meaning=Signature Severity; \ additional_data(0).data=$5; \ additional_data(1).type=integer; \ additional_data(1).meaning=Risk Rating; \ additional_data(1).data=$10; \ ###FOR IOS 15.1 ### regex=(\d+\.\d+\.\d+\.\d+)\s+\d+\:\s+(.+?)\:.+?\%IPS-4-SIGNATURE\: Sig\:(\d+)\s+Subsig\:(\d+)\s+Sev\:(\d+)\s+(.+?)\s+\[([\d\.]+)\:(\d+)\s+\-\>\s+([\d\.]+)\:(\d+)\]\s+VRF\:(.+?)\s+RiskRating\:(\d+); \ classification.text=$6; \ classification.reference(0).origin=vendor-specific; \ classification.reference(0).meaning=cisco_id; \ classification.reference(0).name=$3.$4; \ classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$3&signatureSubId=$4; \ id=585; \ revision=2; \ analyzer(0).name=Cisco IPS; \ analyzer(0).manufacturer=Cisco; \ analyzer(0).class=IPS; \ analyzer(0).node.address(0).address=$1; \ analyzer(0).node.name=$2; \ assessment.impact.type=other; \ source(0).node.address(0).category=ipv4-addr; \ source(0).node.address(0).address=$7; \ target(0).node.address(0).category=ipv4-addr; \ target(0).node.address(0).address=$9; \ source(0).service.port=$8; \ target(0).service.port=$10; \ additional_data(0).type=integer; \ additional_data(0).meaning=Signature Severity; \ additional_data(0).data=$5; \ additional_data(1).type=integer; \ additional_data(1).meaning=Risk Rating; \ additional_data(1).data=$12; \ additional_data(2).type=string; \ additional_data(2).meaning=VRF; \ additional_data(2).data=$11; \ last; After all the above manipulations, we get the following result:
Triggers from all IPS sensors appear in the console. The screenshot above shows the grouping by source and destination addresses. Here there are both events from IPS-modules and applains, and from routers with IOS-IPS enabled (in the screenshot this is not seen due to the “obfuscation” technologies). We can group / filter by all values ​​that were determined during processing by our set of rules.
Accordingly, in any event, you can "fail" and see the details:
6. Heart bleed correlation
The final touch in the setup will be the part that distinguishes the event viewing systems from the SIEM: correlation.
For an example of setting the correlation rule, take the vulnerability that has become painful in recent days in the OpenSSL library - HeartBleed .
Cisco has a signature that allows you to catch an attempt to exploit this vulnerability: tools.cisco.com/security/center/viewIpsSignature.x?signatureId=4187&signatureSubId=0
The signature number is 4187.0, called the “OpenSSL Information Disclosure”.
By itself, the triggering of this signature will not yet mean that the vulnerability was exploited, because IPS does not know if the attacked host is vulnerable or not. But this question may well be answered by SIEM.
The general principle of the correlation rule is as follows: if the above event from IPS arrives at the SIEM, then SIEM itself checks for the HeartBleed vulnerability on the target host. In case the host is vulnerable, a separate correlation event will be created.
The rule itself looks like this:
# # Copyright (C) 2014 Vladimir Lapshin <vmlapshin at gmail dot com> # Copyright (C) 2014 lei_wulong # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; see the file COPYING. If not, write to # the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. # import re from PreludeCorrelator.pluginmanager import Plugin from PreludeCorrelator.context import Context import time import subprocess localtime = time.localtime() timestamp = time.strftime('%d %b %H:%M:%S', localtime) print str(timestamp) + ' HeartBleed plugin (correlator) INFO: Starting...' class heartbleed(Plugin): def run(self, idmef): if not idmef.match('alert.classification.text', re.compile('^OpenSSL Information Disclosure$|^Other security event$')): return addr = idmef.Get('alert.target(*).node.address(*).address') if not addr: return port = idmef.Get('alert.target(0).service.port') if not port: port='443' script = str('python2.6 /etc/prelude-correlator/heartbleed.py ') + str(addr).strip('[\'\']') + str(' -p ') + str(port) print script PIPE = subprocess.PIPE p = subprocess.Popen(script, shell=True, stdin=PIPE, stdout=PIPE, stderr=subprocess.STDOUT, close_fds=True) while True: s = p.stdout.readline() if not s: break if re.findall('server is vulnerable', s): ctx = Context(("HEART_BLEED", addr), update=True, idmef=idmef) ctx.Set("alert.classification.text", "HeartBleed vulnerability detected") ctx.Set("alert.correlation_alert.name", "HeartBleed vulnerability detected") ctx.Set("alert.assessment.impact.severity", "high") ctx.Set("alert.classification.reference(0).origin", "vendor-specific") ctx.Set("alert.classification.reference(0).name", "CVE-2014-0160") ctx.alert() ctx.destroy() print 'Vulnerable!' return : gist.github.com/sh1n0b1/10100394 . . /etc/prelude-correlator/heartbleed.py
IPS- 4187. -, Prelude , : -> , IPS- ( heartbleed) -> IPS -> -> .. Event Action Filter.
, :
if idmef.match("alert.source(0).node.address(0).address", re.compile("0\.0\.0\.0")) # <- Prelude-Correlator addr return Event Action Filter, IPS , Prelude. () – .
, Cisco 4187.0 :
, , . , '^OpenSSL Information Disclosure$|^Other security event$'. , Cisco IPS. IPS , .
web-. – , , .
– . «» python- ( — ). : ( / ), ip «», NAT- ..
7.
SDEE.
Since OSS- Prelude, IPS Prelude SNMP ( IPS-/) syslog ( IOS-IPS). , 4- , SDEE. IPS . SDEE-, Prelude.
PreludePro:
- ;
- Manager-;
- additional Prewikka ( LDAP, web- );
- (log-management, , ..)
, «» .
, .
!
_____
, :
CSM User Guide www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/4-6/user/guide/CSMUserGuide.html
IME Notification Example: www.cisco.com/c/en/us/support/docs/security/ips-4200-series-sensors/111659-ips-email-ime-config.html
IOS IPS events via IME: www.cisco.com/c/en/us/support/docs/security/intrusion-prevention-system/113576-ptn-113576.html
Prelude OSS official page www.prelude-ids.org
Prewikka: is-systems.org/siem/interface
Source: https://habr.com/ru/post/220449/
All Articles