Project

General

Profile

Feature #1007 ยป enhanced-alerting.rst

RFC sent to ML - Eric Leblond, 10/25/2013 05:56 AM

 
1
============================
2
EAF: Extensible Alert Format
3
============================
4

    
5
Principle
6
=========
7

    
8
Current alert system does only provide poor information. For example, in case of
9
stream matching we don't output properly the stream. Or in case of a match giving
10
some meaningful information there is no output of what was matched.
11

    
12
To solve these problems, a solution is to define a new alert format that can
13
contain an arbitrary number of information and be extensible.
14

    
15
A good candidate is to use JSON for that. We can output the basic
16
alert fields and adds information from the matching module. For example,
17
http_user_agent could ouput the user agent in case of a match or
18
a pcre match could return the string matched.
19

    
20
In the case of binary content, we can use base64 encoding to protect
21
the string.
22

    
23
An example alert could looks like ::
24

    
25
 { 
26
   "timestamp": "2013...", "srcip":"::1", "dstip":"::2", "proto":"tcp",
27
   "sid":"121213", "msg":"rhooo sexy",
28
   "stream": {
29
            "encoding":"base64",
30
            "content":"3294928492DUH29UE29294892849284"
31
                  },
32
   "pcre": { "match": "efjehfeuh"},
33
   "http_user_agent" { "value": "WGET"}
34
 }
35

    
36
Maybe sig can contains information about weither we want to log or not
37
the extended fields. Maybe we can add a content modifier like ''nolog''
38
when there is no interest on the value match in the field.
39

    
40
Luajit
41
------
42

    
43
Luajit should be able to export a key value dictionnary to be added into the
44
alert message.
45

    
46

    
47
Implementation
48
==============
49
Algorithm
50
---------
51

    
52
Update Match and MAtchApp function in signature to update the
53
Packet structure if a match occur.
54

    
55
This requires an update of the packet structure to contain
56
matches. We can use a field named matches. The Match function
57
can then add information inside the field.
58

    
59
We will need inside of this field:
60

    
61
- sid: needed to output the matches during the alert (which got sid info)
62
- A key - type - value storage able to store an arbitrary number of values
63

    
64
It seems a good idea to use JSON for the key type value storage as this
65
will be the main output.
66

    
67
So we can have a linked list of structure containing a sid and a json_t
68
object.
69

    
70
If there is no match on sig we need to clean the matches structure for
71
sid that did not match. When outputing alert, we get the Matches 
72
corresponding to the sig ID and we delete and clean the element once
73
logging is done.
74

    
75
Details
76
-------
77

    
78
Getting a json object may be interesting even more complex thing can be handled.
79
One other advantage is that a direct use of jansson will allow us to to benefit
80
from allocation system.
81

    
82
In the case of implementation of queueing system for alerting, the json_t object
83
can be simply passed as a pointer to the generated alert message.
84

    
85
Performances
86
============
87

    
88
This trigger some allocations that are unnecessary if there is no match at the end
89
So it should only be used for final matching. 
90

    
91

    
92

    
    (1-1/1)