VoIP FMS: A Comprehensive Voice over IP Fraud Management System User / Developer Guide Authors Yacine Rebahi Roman Busse Mateusz Khalil Isabel Peters Simon Hohberg Tran Quang Thanh
Contents 1 Introduction... 3 2 Background... 3 2.1 Voice over IP (VoIP)... 3 2.2 Fraud in VoIP networks... 3 2.3 Call Data Records (CDRs)... 4 2.4 Geolocation... 4 2.5 XMPP... 5 2.6 VoIP FMS description... 5 3 User Guide... 6 3.1 Quick Start... 6 3.2 Menu... 7 3.3 Alarms... 8 3.4 Users... 10 3.5 Rules... 15 4 Installation Guide... 22 4.1 Requirements... 22 4.2 Installation... 22 4.3 Running SUNSHINE... 22
1 Introduction The current document is a reference guide for the VoIP Fraud Management System (VoIP FMS) that was developed in the context of the SUNSHINE project (where it was referred as CDR analysis ). This document can be seen as a user-guide as well as a reference for users and developers interested in contributing to this framework. 2 Background 2.1 Voice over IP (VoIP) VoIP is a set of technologies enabling voice calls to be carried over the Internet. Contrary to the traditional telephone system - the Public Switched Telephone Network (PSTN) -, the potential driving the use of the VoIP technology is not only the very low cost or free voice calls, but also its ability to converge with other technologies, in particular presence and instant messaging, which in turn will result in new services and applications. Voice-over-IP (VoIP) communication based on the Session Initiation Protocol (SIP) (RFC 3261) has evolved as de-facto standard for voice communication. SIP is an application-layer control protocol that allows users to create, modify, and terminate sessions with one or more participants. It can be used to create two-party, multiparty, or multicast sessions that include Internet telephone calls, multimedia distribution, and multimedia conferences. In SIP, a user is identified through a SIP-URI in the form of user@domain. This address can be resolved to a SIP proxy that is responsible for the user s domain. To identify the actual location of the user in terms of an IP address, the user needs to register his IP address at the SIP registrar responsible for his domain. Thereby, when inviting a user, the caller sends his invitation to the SIP proxy responsible for the user s domain, which checks in the registrar s database the location of the user and forwards the invitation to the callee. The callee can either accept or reject the invitation. The session initiation is then finalized by having the caller acknowledging the reception of the callee s answer. During this message exchange, the caller and callee exchange the addresses at which they would like to receive the media and what kind of media they can accept. After finishing the session establishment, the end systems can exchange data directly without the involvement of the SIP proxy. 2.2 Fraud in VoIP networks Different definitions of fraud are reflected in the literature. However, fraud can simply be seen as any activity that leads to the obtaining of financial advantage or causing of loss by implicit or explicit deception. In traditional telecommunication networks, fraud is already a threat depriving telecom operators from huge amounts of money every year. With the migration from circuit-switched networks to packet-switched networks, it is expected that the related situation will be worse due, partly, to the issues discussed earlier. Potential examples of fraud in VoIP environments include,
Abuse of the flat rate services. Such services are intended for personal use only, some subscribers offer this service to other people family and friends- as well resulting in high usage and high losses to the operator Some access control schemes of the VoIP protocols are still based on the MD5 hash technology which is not robust enough. This could lead to an identity theft The service usage does not match the subscription type. For instance, a customer can subscribe for a residential service which is usually cheaper than a business one and use it for business purposes. Another case is where the customer subscribes for the option that allows it to use its own PBX, and then use this PBX as a dialer for call center purposes. This severely affects the performance of the VoIP provider platform An offender could attack a VoIP telephone with IP methods and change the telephones settings to forward incoming calls to value added services the offender setup before. Each call to the victims telephone will result in costs for the value added service with a gain for the offender. 2.3 Call Data Records (CDRs) Every time a call is placed on a telecommunication network, descriptive information about the call is saved as a Call Data Record (CDR). The number of CDRs generated every day and stored is huge. In addition, at a minimum, each Call Data Record has to include the originating and terminating phone numbers, the date and time of the call and the duration of the call. The CDRs might also include some other kind of data which is not necessary but required for billing, for instance, the identifier of the telephone exchange writing the record, a sequence number identifying the record, the result of the call (whether it was answered, busy, etc), any fault condition encountered, and any facilities used during the call, such as call waiting. An example of CDRs made available by a VoIP provider include the fields: Time - start time of call -; SIP Response Code: 2xx, 3xx, 4xx, 5xx or 6xx; SIP Method: INVITE (mainly); User-name: From URI; To URI; To-Tag; From-Tag; User-Agent; Source IP; RPID: Remote Party ID; and Duration. 2.4 Geolocation In VoIP FMS, geolocation is also utilized to detect fraudulent activities. Here, the location information of the call is generated based on the IP address of the caller in combination with a geolocation database. Geolocation simply enables to determine where the service users are physically located based on their IP addresses as VoIP CDRs often include the IP address of the caller. For example: When the input IP address is 217.159.49.6, the output will be location number 57 (which belongs to Germany). The geolocation database, geolitecity from MaxMind 1, is used in our current implementation. Another important feature that MaxMind offers is the incorporation of open proxies detection. Often, fraudsters use such components to hide their identities and integrating mechanisms to detect such components reveals to be crucial. The location profile is implemented as follows: The first time the user starts using the service, the geolocation of the used IP address is determined and stored together with a timestamp. If over time another IP address was used by the caller, its corresponding geolocation information is not stored except if it differs from the previous one. In this case, a timestamp reflecting the last time the previous 1 http://dev.maxmind.com/geoip/legacy/geolite
location was seen is also stored. The location profile can be used in different ways. In fact, it is impossible for a subscriber to make calls from different places (e.g. different countries) in a short period of time. If this occurs, this means that the same account is being used by two different persons - which might be a fraud indicator. This suspicion is reinforced if one of the persons using the account is behind an open proxy. Also, based on the location profile, we calculate the distance between two consecutive calls made from different locations by using the Spherical law of cosines formula. The location profile can also be used by the rule based system to check whether the location change occurred in a country that is blacklisted which gives a stronger indicator of fraud. It can also be used as input data to more complex techniques such as NN-SOM. 2.5 XMPP The Extensible Messaging and Presence Protocol (XMPP) is a XML-based message-oriented communications protocol. This protocol was introduced in January 1999 with the name Jabber as an open technology for instant messaging and presence. As open, secure, extensible and real-time protocol, XMPP is being used by big companies such as Google, Apple, Skype, and MSN. There are many XMPP implementations. Openfire 2, a Java-based open source XMPP server, is selected in this project as the central component in our event-based system. Other open source XMPP client stacks are also integrated into other components such as Smack (Java), txmpp (C++), xmppy(python). 2.6 VoIP FMS description Our framework has a modular architecture. This permits the incorporation of additional detection, correlation, analysis, and notification tools. Some of the detection algorithms need to be scheduled over sufficiently large time intervals to be able to operate. The profiling-based technique is a particular case of such techniques. In contrast to this, a rule-based technique can be launched on demand. Indeed, the rule engine can be configured to apply a given rule to any new call (or CDR) that is made to suspected destinations. In addition to that, an alarm can be sent (in urgent cases) by email or by another means to the fraud management expert. For these reasons, we decided to implement the CDR analysis framework in an event-based manner, i.e., the components communicate by generating and receiving notifications. An event reflects the occurrence of an item of interest to some of the system components, e.g., the arrival of a new CDR or the creation of a new rule. The event-based architecture is well suited for large scale distributed applications and provides easy integration of autonomous and heterogeneous components. The VoIP FMS is composed from the following components as shown in Figure 2, A fraud management interface. In brief, this interface will enable the administrator to configure the different components of the CDR analysis framework, visualize the detection results as well as the alarms. The Web interface is based on Django 3 which is a high level Python Web framework that encourages rapid development and clean, pragmatic design. The detection techniques and algorithms. The techniques include a rule-engine, call profiling, geolocation profiling, and Neural Networks Self Organizing Map (NN-SOM). The event-based system. The latter is the backbone that coordinates the tasks and links the different components together. This system is based on the XMPP protocol. 2 http://www.igniterealtime.org/projects/openfire/ 3 http://www.djangoproject.com/
Figure 1: CDR analysis architecture 3 User Guide In brief, the management interface will enable the administrator to configure the different components of the VoIP FMS framework, visualize the detection results as well as the alarms. The Web interface is based on Django 4 which is a high level Python Web framework that encourages rapid development and clean, pragmatic design. 3.1 Quick Start To start the Web interface, you can either run our script cd <sunshine_installation_folder_path> python run.py or you start Django manually using cd <sunshine_installation_folder_path> python manage.py runserver After successfully starting Django you can switch to a browser and open the Web page 4 http://www.djangoproject.com/
http://localhost:8000 We provide a simple password-protected single-user authentication mechanism. We strongly recommend employing a different authentication middleware. At least, make sure to change the default password (user: admin password: tran) in WharfWebinterface/wharf/views.py. Figure 2: Log-in menu 3.2 Menu The menu can be found on the webpage s left side, which contains the following menu entries: Alarms Users Rules (expandable) Neural Network Profiling
Figure 1: Menu 3.3 Alarms The first menu point is Alarms. On this site you will see all the alarms which satisfy the user defined filters. The filters specify an interval (start- and end-date), but optionally a user-id may be set, as well. The alarms are sorted and displayed regarding the date in an ascending order. If a user-id needs to be specified, the web interface supports the user with auto-completion. Upon selecting a user the alarm menu is reloaded. Displayed alarms may also be filtered in an additional step concerning their detection component, which may be the Rule System, NN-SOM or Call Profiling. It is possible to select alarms from multiple categories by simply using the <CTRL> Button.
Figure 2: Alarms Overview
3.4 Users In the users menu you can retrieve information about a certain user. The common workflow: 1. Specifying a User 2. Retrieve Information Specifying a user can be achieved using either the search formula or browsing all users. Figure 3: Specific User Selection
Figure 4: All Users View Retrieve information related to the user using the tabs, which are the following: General Information Call Profile Charts Used IP Addresses Location Profile Latest Alarms Tabs General Information In this tab some very basic information about the specified user are provided. Call Profile In this tab you can view all profiles the user has regarding a specific date. This date can be changed on the upper right side. A call profile consists of different types of calls, which are additionally grouped by the day time. If the actual value is an outlier the entry would be colored red, otherwise green. Each entry specifies: Name which consists of a type call and day time Mean of latest long call profile concerning the specified date Standard Deviation of latest call profile concerning the specified date
Actual is the value of the call profile concerning the specified date (for the time being, the profiling module is not open source) Figure 5: Call Profile
Charts The charts tab includes three different charts: Call types chart Number of calls on one day Durations These charts are created with jqplot, which is a plugin for JQuery. The charts base on all calls made by the specified user. Call Types: Relates different type calls with each other Figure 6: Pie Chart Number of calls on each day: On the x-axis there are all days and the y-axis specifies the number of calls. Series for different call types such as morning, afternoon, evening and night calls can be viewed. Figure 7: Series Chart Durations: On the x Axis there are the duration numbers; the y-axis specifies the amount of calls, which took the given duration.
Figure 8: Duration Series Used IP Addresses In the tab Used IP Addresses there is a table, which describes from where the user has made his calls, the number of calls made from this IP and geographic location information attached to the IP address. Figure 9: Used IP Addresses Example Location Profile The location profile view groups all successive user calls having the same location into one location profile entry. Two successive location profile entries describe two different locations, where information can be extracted, such as: Distance of the locations First Call in the location Next Call in a different location Time Elapse (time difference between First and Next Call)
Latest Alarms This tab shows the latest user s alarms. Figure 10: Location Profile Example Figure 11: Latest Alarms Example 3.5 Rules Rules can be created in order to detect fraud. After saving a rule, it will be applied to the CDRs and run by the rule system. Alarms will be raised if there are CDRs satisfying this rule. There are rules containing just a condition you can create. Or also rules that are more complicated and contain some counters. Generic Rule Interface More sophisticated rules can be created in this view by expert users. The user needs to write the rules by himself, nevertheless he is supported by an autocompletion and hint system. Besides that rule syntax validation is performed on the fly (valid syntax is expressed by the green background in the rule field, red otherwise).
In this expert mode, the user is able to specify a rule group, where multiple rules may correspond to the rule group. One rule group consists of at least one rule. Multiple rules aggregated to one rule group can be created by pressing the Add Rule button. Apply the Rule later creates a rule without actually executing the rule system immediately. The rule system periodically performs saved rules automatically. A Cluster is a set of entities violating the specified rule. Entities can be either Destination Country Source Country Source Id Create Cluster enables the user to create a cluster as described before. Where No Cluster means that no cluster is created. Apply Rule for Clusters applies the rule for a specific set of entities only. Clusters (cluster ids or cluster names) can be combined using AND / OR. Examples: using cluster ids: 1 AND 2 OR 3 using cluster names: ClusterA AND ClusterB OR ClusterC using both variant: ClusterA AND 3 OR ClusterC Existing Clusters can be displayed by pressing the View Clusters button.
Figure 12: Expert Mode Normal rule The Fig. 13 shows the first kind of rule. Type in your description of the rule and the alarm text you want to see if a fraud was detected. The condition contains: NOT (!) commas an option (the options can be duration, daily quarter etc. All the fields of the database table for the CDRs) operation (==,!=, >=, &&, etc) value and don't forget to close the comma.
You can add more conditions by clicking on Add more conditions and combine them with AND or OR. Example:!(daily_quarter==1) & (dst_ip==12.12.12.12) Than click on Submit. Figure 13: Normal rule
Counter rule with frequency 1 Click on Or create rule with counter. Figure 14: Rule with counters This kind of rule is a bit complicated. For example, you want an alarm to be raised if a user has made more than 20 premium calls in 2 weeks. You have to enter a counter name, the condition (is_pemium==1), a window size (in this case, 14 days, 0 hours, 0 minutes), the date before the Calls have been made, increase counter with 1 (the standard value), the max result number that is allowed in 14 days (in our case, 20), and the frequency of the event is 1 (could be 2. It will be explained in the next paragraph). Enter the description and the alarm text. Click on Show rules(s) to see how the rule looks like. Some parts of the rule are generated at the backend. 19
Counter rule with frequency 2 Figure 15: counter rule with frequency 2 Let's take the same example with the premium calls. Now you want to check whether there are more than 20 premium calls made by some user in 2 weeks, and this event happened more than twice in 2 Months. This means, in this period of time (60 days) the rule system found more than 20 premium calls in 2 weeks, and after that it found another 20 calls in 2 weeks. Both of the detections were within two months. Alarm will be raised because this is your rule. To create this kind of rule, just select Frequency of the event : 2. Enter a period of time for the second event and the result that is the limit of the counter. When you click on submit, you should see a message if the action was successful. Then you can follow the link to see all the rules you have created until now. Or navigate to menu Rules Show rules. 20
Show rules In the table of rules there is a button Deactivate or activate after each rule. Here you can activate or deactivate your rules, and remove them from the rule system. But the rule will still exist in the Database, in case you want to activate it again. Rule Structure The condition and the action are separated by a comma. Conditions can consist of multiple logical operators, as an or or an and, combining two sub-conditions. The grammar is left associative. The condition keywords are either columns of the calls table from the db or logical functions working on top of these column. The action can either be an other logical function (e.g. a counter) or an alarm text. It is also possible to define more than one (sub)- action for one condition by adding a space character after the first action followed by the second action. An alarm text can reference the calls values by having a $ followed by the column name of the call (a column of the calls table). Note that the implemented functions usable for conditions and actions differ. A Rule can consist of multiple sub-rules (sub-rules reference one rule-id in the db). Sub-rules will be evaluated sequentially. This means the sub-rules follow a fixed order (as can be seen in the second example and why it works). Usable functions can be seen in the gui (with examples) or in the rule-system token.py -> parser.py and operations.py within the rulesystem package rule_parser. Examples of rules In the following, we provide some examples of rules, that can be generated without the need of the gui and show the structure of the Rule-System-internaly used structure. Example 1: The first example is relatively simple and intends to have a first experience on how to create a rule. The following rule creates an alarm with the text The Call with id $id and user $src_id from ip $src_ip to $dst_ip is shorter or equal to two seconds., when the duration of a call is smaller than 2 seconds and the status is 200 (in SIP->OK). '(duration <=2 ) & (status == 200)', 'alarm(the Call with id $id and user $src_id from ip $src_ip to $dst_ip is shorter or equal to two seconds.)' Example 2: The second example shows a more complex rule and consists of 3 sub-rules. The following rule creates an alarm with the text Premium counter for $src_id is over 10, when a user creates more than ten premium number calls within 1hour (3600 seconds). is_premium &!have_counter( $src_id premium ), init_counter( $src_id premium 3600) is_premium == 1, count( $src_id premium 1 timestamp) get_counter( $src_id premium ) > 10 & (is_premium == 1), alarm( Premium counter for $src_id is over 10 ) del counter( src_id premium ) The structure can be explained as follows: the first sub-rule checks for and creates a counter variable for the src_id of the user, when none is present, having a sliding window size of 3600 seconds. The second sub-rule increments the counter by one. While the last subrule resets the counter by deleting it, after incrementing the counter 10 times (it will be new 21
created in the next occurrence of a premium call as the first sub-rule will re-match). To reduce the variable creation, a more efficient restart counter version is also available in the gui function selection. 4 Installation Guide 4.1 Requirements Before starting the installer, please make sure that the following software is installed: Python 2.7 Java JDK 6 or higher MySQL 5.0 or higher 4.2 Installation Note that the installation script needs to be started in administrator mode (sudo). The actual installation can be easily run using: cd <SUNSHINE_INSTALLATION_DIRECTORY> sudo python install.py -i For configuration purposes, please follow the installation procedure, where all necessary parameters are asked. 4.3 Running SUNSHINE After finishing the installation the SUNSHINE system can be run using: cd <SUNSHINE_INSTALLATION_DIRECTORY> python run.py 22