[svn-commits] russell: branch group/security_events r195518 - /team/group/security_events/

[SVN commits to the Digium repositories]

Author: russell
Date: Tue May 19 11:43:21 2009
New Revision: 195518

URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=195518
Log:
Add some intro edits from jtodd, and start documenting log file format

Modified:
    team/group/security_events/security_events.txt

Modified: team/group/security_events/security_events.txt
URL: http://svn.asterisk.org/svn-view/asterisk/team/group/security_events/security_events.txt?view=diff&rev=195518&r1=195517&r2=195518
==============================================================================
--- team/group/security_events/security_events.txt (original)
+++ team/group/security_events/security_events.txt Tue May 19 11:43:21 2009
@@ -21,16 +21,26 @@
 --- 1) Introduction ------------------------------------------------------------
 --------------------------------------------------------------------------------
 
-    Attacks on Voice over IP networks are becoming increasingly more common.
-It has become clear that we must do something within Asterisk to help mitigate
+   Attacks on Voice over IP networks are becoming increasingly more common.  It
+has become clear that we must do something within Asterisk to help mitigate
 these attacks.
 
-    Through a number of discussions, we have decided that the best thing that we
-can do within Asterisk is to build a framework which recognizes and reports 
-events that could potentially have security implications.  We can then allow
-these events to be reported in easily interpretable ways so that we can build
-external tools that can apply business rules to these events and decide how to
-act on them.
+   Through a number of discussions with groups of developers in the Asterisk
+community, the general consensus is that the best thing that we can do within
+Asterisk is to build a framework which recognizes and reports events that could
+potentially have security implications.  Each channel driver has a different
+concept of what is an "event", and then each administrator has different
+thresholds of what is a "bad" event and what is a restorative event.  The
+process of acting upon this information is left to an external program to
+correlate and then take action - block traffic, modify dialing rules, etc.  It
+was decided that embedding actions inside of Asterisk was inappropriate, as the
+complexity of construction of such rule sets is difficult and there was no
+agreement on where rules should be enabled or how they should be processed.  The
+addition of a major section of code to handle rule expiration and severity
+interpretation was significant.  As a final determining factor, there are
+external programs and services which already parse log files and act in concert
+with packet filters or external devices to protect or alter network security
+models for IP connected hosts.
 
 --------------------------------------------------------------------------------
 --------------------------------------------------------------------------------
@@ -177,6 +187,22 @@
 --- 4) Security Log File Format ------------------------------------------------
 --------------------------------------------------------------------------------
 
+    The beginning of each line in the log file is the same as it is for other
+logger channels within Asterisk.
+
+    [Feb 11 07:57:03] SECURITY[23736] res_security_log.c: <...>
+
+    The part of the log entry identified by <...> is where the security event
+content will reside.  The security event content will be a comma separated list
+of key value pairs.  The key is the information element type, and the value is a
+quoted string that contains the associated meta data for that information
+element.  Any embedded quotes within the content will be escaped with a
+backslash.
+
+    INFORMATION_ELEMENT_1="IE1 content",INFORMATION_ELEMENT_2="IE2 content",...
+
+
+
 TODO ...
 
 --------------------------------------------------------------------------------