1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
\section{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
these attacks.
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.
\section{Framework Overview}
This section discusses the architecture of the Asterisk modifications being
proposed.
There are two main components that we propose for the initial
implementation of the security framework:
\begin{itemize}
\item Security Event Generation
\item Security Event Logger
\end{itemize}
\subsection{Security Event Generation}
The ast\_event API is used for the generation of security events. That
way, the events are in an easily interpretable format within Asterisk to
make it easy to write modules that do things with them. There are also some
helper data structures and functions to aid Asterisk modules in reporting these
security events with the proper contents.
The next section of this document contains the current list of security events
being proposed. Each security event type has some required pieces of
information and some other optional pieces of information.
Subscribing to security events from within Asterisk can be done by
subscribing to events of type AST\_EVENT\_SECURITY. These events have an
information element, AST\_EVENT\_IE\_SECURITY\_EVENT, which identifies the security
event sub-type (from the list described in the next section). The result of the
information elements in the events contain the required and optional meta data
associated with the event sub-type.
\subsection{Security Event Logger}
In addition to the infrastructure for generating the events, one module that
is a consumer of these events has been implemented.
Asterisk trunk was recently updated to include support for dynamic logger
levels. This module takes advantage of this functionality to create a
custom "security" logger level. Then, when this module is in use, logger.conf
can be configured to put security events into a file:
\begin{verbatim}
security_log => security
\end{verbatim}
The content of this file is a well defined and easily interpretable
format for external scripts to read and act upon. The definition for the format
of the log file is described later in this chapter.
\section{Events to Log}
\begin{verbatim}
(-) required
(+) optional
Invalid Account ID
(-) Local address family/IP address/port/transport
(-) Remote address family/IP address/port/transport
(-) Service (SIP, AMI, IAX2, ...)
(-) System Name
(+) Module
(+) Account ID (username, etc)
(+) Session ID (CallID, etc)
(+) Session timestamp (required if Session ID present)
(-) Event timestamp (sub-second precision)
Failed ACL match
-> everything from invalid account ID
(+) Name of ACL (when we have named ACLs)
Invalid Challenge/Response
-> everything from invalid account ID
(-) Challenge
(-) Response
(-) Expected Response
Invalid Password
-> everything from invalid account ID
Successful Authentication
-> informational event
-> everything from invalid account ID
Invalid formatting of Request
-> everything from invalid account ID
-> account ID optional
(-) Request Type
(+) Request parameters
Session Limit Reached (such as a call limit)
-> everything from invalid account ID
Memory Limit Reached
-> everything from invalid account ID
Maximum Load Average Reached
-> everything from invalid account ID
Request Not Allowed
-> everything from invalid account ID
(-) Request Type
(+) Request parameters
Request Not Supported
-> everything from invalid account ID
(-) Request Type
Authentication Method Not Allowed
-> everything from invalid account ID
(-) Authentication Method attempted
In dialog message from unexpected host
-> everything from invalid account ID
(-) expected host
\end{verbatim}
\section{Security Log File Format}
The beginning of each line in the log file is the same as it is for other
logger levels within Asterisk.
\begin{verbatim}
[Feb 11 07:57:03] SECURITY[23736] res_security_log.c: <...>
\end{verbatim}
The part of the log entry identified by $<$...$>$ is where the security event
content resides. The security event content is 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 are escaped with a
backslash.
\begin{verbatim}
INFORMATION_ELEMENT_1="IE1 content",INFORMATION_ELEMENT_2="IE2 content"
\end{verbatim}
The following table includes potential information elements and what the
associated content looks like:
\begin{verbatim}
IE: SecurityEvent
Content: This is the security event sub-type.
Values: FailedACL, InvalidAccountID, SessionLimit, MemoryLimit, LoadAverageLimit,
RequestNotSupported, RequestNotAllowed, AuthMethodNotAllowed,
ReqBadFormat, UnexpectedAddress, ChallengeResponseFailed,
InvalidPassword
IE: EventVersion
Content: This is a numeric value that indicates when updates are made to the
content of the event.
Values: Monotonically increasing integer, starting at 1
IE: Service
Content: This is the Asterisk service that generated the event.
Values: TEST, SIP, AMI
IE: Module
Content: This is the Asterisk module that generated the event.
Values: chan_sip
IE: AccountID
Content: This is a string used to identify the account associated with the
event. In most cases, this would be a username.
IE: SessionID
Content: This is a string used to identify the session associated with the
event. The format of the session identifier is specific to the
service. In the case of SIP, this would be the Call-ID.
IE: SessionTV
Content: The time that the session associated with the SessionID started.
Values: <seconds>-<microseconds> since epoch
IE: ACLName
Content: This is a string that identifies which named ACL is associated with
this event.
IE: LocalAddress
Content: This is the local address that was contacted for the related event.
Values: <Address Family>/<Transport>/<Address>/<Port>
Examples:
-> IPV4/UDP/192.168.1.1/5060
-> IPV4/TCP/192.168.1.1/5038
IE: RemoteAddress
Content: This is the remote address associated with the event.
Examples:
-> IPV4/UDP/192.168.1.2/5060
-> IPV4/TCP/192.168.1.2/5038
IE: ExpectedAddress
Content: This is the address that was expected to be the remote address.
Examples:
-> IPV4/UDP/192.168.1.2/5060
-> IPV4/TCP/192.168.1.2/5038
IE: EventTV
Content: This is the timestamp of when the event occurred.
Values: <seconds>-<microseconds> since epoch
IE: RequestType
Content: This is a service specific string that represents the invalid request
IE: RequestParams
Content: This is a service specific string that represents relevant parameters
given with a request that was considered invalid.
IE: AuthMethod
Content: This is a service specific string that represents an authentication
method that was used or requested.
IE: Challenge
Content: This is a service specific string that represents the challenge
provided to a user attempting challenge/response authentication.
IE: Response
Content: This is a service specific string that represents the response
received from a user attempting challenge/response authentication.
IE: ExpectedResponse
Content: This is a service specific string that represents the response
that was expected to be received from a user attempting
challenge/response authentication.
\end{verbatim}
|
