SIPCMBeat's Custom SIP Extensions

A key component of our architecture is SIPCMBeat -- a probe that collects SIP traffic and aggregates it into comprehensible events reporting on what SIP users do, mostly for purposes of troubleshooting and security analysis. It is publicly available under terms of a source-available license.

SIPCMBeat is using a custom extension of Elastic Common Schema (ECS) for SIP data. The unified ECS helps to share all kind of cross-application security events. Our extension to the schema defines events such as `a user registered` or `a call has ended` and includes session information such as call length. Such events turn various SIP bits and pieces into events documenting the actual purpose of the SIP messages while absorbing a substantial level of noise: retransmissions, NAT keep-alives, and most importantly recurrent attack patterns.

The rest of this article is concerned with why we prefer our style of SIP extension over the "tunnel-every-bit" approach for SIP announced in Elastic Security 7.10 ECS (November 11, 2020). In nutshell we are extremely concerned about security and chose a very different design for s SIEM system than the database company did. We check every bit before we send it out to make sure that by replicating noise we do not amplify security attacks. The 7.10 approach does the exact opposite in that it attempts to wrap every detail for every SIP message captured in a JSON document.

In summary, sipcmbeat supports TCP and UDP transport layer protocols, while absorbing retransmissions, keep-alives and in-dialog messages, aggregating requests and replies into events and throttling volume attacks.

Security analytics is about finding a needle in a haystack. That's why SIPCMBEAT includes a built-in SIP stack to aggregate SIP messages in comprehensible events: it transforms a lot of noise in information that matters. For example a SIP telephone going on and off once a day generates two REGISTER transactions every minute due to NAT traversal binding refreshes. That's 4 messages * 60 minutes * 24 hours ... 5760 messages a day and about 6kb x 60 minutes * 24 hours ... 8+ MB of PCAP data per single user a day. SIPCMBEAT reduces this to two events: one for SIP telephone logging in, and one for logging out. A similar even though not so drastic reduction can be seen for a SIP call. sipcmbeat generates callstart and callstop events whereas stateless packet-beat would typically report 10 message (INV-407-ACK-INV-100-180-200-ACK-BYE-200). The fewer events sipcmbeat generates the more useful they are: aggregation allows to include data such as call length. In other words, sipcmbeat makes it orders of magnitude easier to find useful information that matters.

The capability to aggregate the actual network messages serves another important purpose of system survivability under volume attacks. Under such conditions monitoring tools that reporting on every single IP packet carrying a SIP message would amplify the attack and contribute to system overload. In fact, it doesn't have to be even a malicious attack: sometimes a gap in server connectivity may cause what is called SIP registration storm,. When every SIP end-device tries to reconnect and many systems get close to collapse. Monitoring systems however should be built in a way that helps to make systems more robust. That's the reason for sipcmbeat's design -- it will help preventing a collapse by skipping recurring data both driven by stack (retransmissions, keep-alives) and by brute-force attack patterns. Especially the latter can be devastating: a usual rate observed today makes 100-150 SIP requests a second -- a simple SIP request alone is half a kilobyte long and induces an answer.

Currently SIPCMBEAT's ECS extension supports the following event types:

  • call-attempt -- a SIP INVITE was received that was responded with a negative answer (other than an authentication failure) or timed out

  • call-start -- a SIP INVITE received a positive answer and established a dialog

  • call-end -- a SIP BYE terminated a call

  • reg-new -- a new SIP contact was registered for an AoR; re-registrations do not trigger an event

  • reg-del -- a SIP contact was unregistered

  • reg-expired -- a SIP contact expired

  • auth-failed -- a SIP request failed to authentication (the initial 401/407 without credentials doesn't count, only the subsequent request does)

An example event looks like this:


{ "@timestamp": "2020-10-08T13:11:25.659Z", "@metadata": { "beat": "sipcmbeat", "type": "_doc", "version": "7.1.0" },"type": "call-end", "sip": { "from": "sip:1001@93.131.247.202:24100", "to": "sip:music@iptel.org", "request": { "method": "INVITE" }, "contact": "sip:1001@93.131.247.202:24100", "sip_reason": "OK", "response": { "last": 200 }, "call_id": "59eb1b05026d5aec192e7be851dcd994@93.131.247.202:24100" }, "user_agent": { "original": "Asterisk PBX 13.5.0" }, "uas": { "original": "BSIP-OEM 0.63.035" }, "host": { "name": "sip0.iptel.org" }, "agent": { "id": "f839018b-ef29-4596-91a2-6fdb0a0c625a", "version": "7.1.0", "type": "sipcmbeat", "ephemeral_id": "9eccd661-00c8-4ecf-a00b-16f4326e7db2", "hostname": "sip0.iptel.org" }, "server": { "ip": "212.79.111.155", "port": 5060 }, "event": { "duration": 1, "call_start": "2020-10-08T13:11:24.073Z" }, "client": { "transport": "udp", "ip": "93.131.247.202", "port": 24100 }, "ecs": { "version": "1.0.0" }, "uri": { "original": "sip:music@iptel.org" }}