Detecting Anomaly Traffic using Flow Data in the Real VoIP Network Hyeongu Son, Youngseok Lee {hgson, lee}@cnu.ac.kr Chungnam National University Korea 2010. 07. 19.(Mon.) Thank you for chairman My name is Hyeongu Son. Recently, many VoIP applications are deployed and VoIP users are increasing because of free or cheap call charge. Since the VoIP services are popular, a lot of VoIP anomaly traffic have been deployed Today, my talk is Detecting Anomaly Traffic using Flow Data in the real VoIP network.

Introduction Current trend Most of all VoIP applications Over 5 millions (about 20% of all phone users) in Korea In 2009, over 27 millions in the U.S.A. Most of all VoIP applications SIP : for call connection RTP : In order to transmit voice traffic Various anomaly traffic in the Internet Worm, DoS, DDoS etc. Degrade bit/packet rate, increase packet transmit delay, etc. VoIP anomaly traffic Terminate / cancel calls between VoIP users Degrade voice quality Last year, members of VoIP applications are over 5 millions in Korea. Also, it was expected that users of VoIP applications in the U.S.A are over 27 millions. Most of all VoIP applications in Korea provided from those service providers use SIP for call connection and RTP to transmit voice traffic. Nowadays, various anomaly traffic such as Worm, DDos is exposed in the Internet. The anomaly traffic can be caused degradation of packet transmission rate and growth of packet transmission delay. In addition, anomaly traffic for interfering VoIP services directly, have been deployed. This anomaly traffic can be occurred the mentioned problem as well as degradation of voice quality and termination and cancellation calls between users. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Motivation Current SIP/RTP-based VoIP services Provide minimal security function related with authentication The packet is not encrypted Possible to be sniffed and forged by an attacker Proposed security protocol SRTP, TLS, IPSec, etc. Current SIP/RTP-based VoIP services in Korea provide minimal security function related with authentication. However, because the VoIP packet is not encrypted, it is possible to be sniffed and forged the packet by an attacker. For preventing these problems by the attacker, the security protocols such as SRTP, TLS and IPSec have been proposed, but these protocols have not been fully implemented in most of all commercial VoIP applications. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Contribution Propose three VoIP anomaly traffic detection methods For monitoring VoIP traffic : employ IPFIX Define new IPFIX templates for monitoring SIP and RTP traffic To monitor wireless LAN traffic at wireless access router Add 802.11 MAC header information Propose VoIP-related anomaly traffic detection methods CANCEL DoS anomaly traffic detection BYE DoS anomaly traffic detection RTP flooding traffic detection In this paper, we proposed these anomaly traffic detecting method using flow-data. In order to use flow-level traffic measurement, we use IPFIX which is proposed by IETF IPFIX working group. Based on this measurement, we propose 2 new IPFIX templates for monitoring SIP and RTP traffic. In addition, we add on some IPFIX fields for observing 802.11 wireless LAN traffic. Based on this monitored results, we proposed three VoIP anomaly traffic detection methods. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

IPFIX IPFIX IP Flow Information eXport Based on Cisco NetFlow v9 Flexible and easily extensible template architecture Support IPv4 traffic as well as IPv6, VoIP and MPLS Reliable transport protocols Default IPFIX flow transport protocol UDP For reliability Support SCTP and TCP In this paper, we use IPFIX based on cisco netflow v9 for standard flow-level traffic measurement. This method provides flexible and extensible template architecture so it can be easy to support various kinds of protocols such as IPv6, MPLS and VoIP. In addition, this method supports reliable transport protocols such as SCTP and TCP when IPFIX message is transmitted to a collector. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

(2 options Data Records) Example of IPFIX flow IPFIX Header Template FlowSet (1 Template) Data FlowSet (3 Flow Data Reords) Options Template FlowSet (1 Template) Option Data FlowSet (2 options Data Records) Ver = 10 Message Length SRC IPv4 Addr DST IPv4 Addr Src port Pkt # Bytes # 168.188.46.122 168.188.130.185 211.35.68.95 63.128.36.152 80 22 5009 748 5344385 388934 Export Timestamp Sequence Number FlowSet ID = 256 Length = 92 Source ID FlowSet ID = 1 Length = 24 Template ID 257 Opt Scope Length = 4 168.188.46.122 Option Length = 8 Source ID=TBD FlowSet ID = 0 Length = 28 bytes 211.35.68.95 80 Scope 1 Field Length = 4 TOTAL_EXP_PKTS _SENT=41 Template ID 256 Field Count = 5 IPV4_SRC_ADDR = 27 Field Length = 4 5009 Field Length = 2 TOTAL_FLOWS_EXP=42 IPV4_DST_ADDR = 28 Field Length = 4 5344385 Field Length = 2 Padding L4_SRC_PORT= 7 Field Length = 4 168.188.130.185 IPFIX flow consists of 5 section such as IPFIX header, template set, data set, option template set and option data template set Each flow entry includes data records according to the define flow template which while will be sent to the flow collector before the flow data is exported. In this figure, we can see that source IP address, destination IP address, port numbers, packet count and byte count. IN_PKTS = 2 Field Length = 4 63.128.36.152 Line Card ID IPFIX msg Export Flow IN_BYTES = 1 Field Length = 4 22 Line Card 1 Line Card 2 345 690 10201 20402 748 388934 FlowSet ID = 257 Length = 20 1 345 10201 2 Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02 6 690 20402

Related Work Related Work Features Drawback Using Hellinger Distance[8] VoIP anomaly traffic detection using Hellinger Distance Detection of anomaly traffic in this method is used packet count, so it is difficult to detect anomaly traffic having 1 or 2 packet(s) State machine[11] VoIP anomaly detection method using Extended Finite State Machine It needs to maintain status information of VoIP packets SIPFIX[10] SIP traffic monitoring method involved application-layer inspection and information in SDP This method is presented only the possibility of applying it to detect DoS anomaly traffic SIP Anomalies Detection Simulation[14] Simulation of SIP anomaly traffic detection The results were presented at non-real VoIP network For detecting VoIP anomaly traffic, various detection methods have been proposed. We will introduce some detection methods and explain their weaknesses briefly. First one is flooding anomaly traffic detection method using Hellinger distance. This method used packet count to calculate Hellinger distance. However, it is difficult to anomaly traffic having 1 or 2 packet(s). Second one is VoIP anomaly traffic detection using extended finite state machine. This method needs to maintain status information of VoIP packets, so it is possible to increase overhead of detection system overhead such as memory consumption. For monitoring SIP traffic, it is proposed to involve application-layer inspection and information of SDP. This method is called SIPFIX. However, this method is presented only the possibility of applying it to detect VoIP DoS anomaly traffic. In this paper, we propose VoIP anomaly traffic detection method in commercial VoIP network. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

VoIP Anomaly Traffic in Real VoIP Network VoIP traffic in real VoIP network Security : only provide authentication CANCEL DoS anomaly traffic Do not need authentication key provided from proxy server BYE DoS anomaly traffic Need authentication key which is the same as the key in INVITE Possible to get the key from unencrypted INVITE message by sniffing RTP flooding Do not need authentication key in a RTP packet INVITE / Registeration etc. Need authentication key Difficult to obtain authentication key in real VoIP network Before sending anomaly traffic, attacker have to get authentication key Most of all VoIP applications in Korea only provide an authentication security function, but packet encryption is not supported. So, an attacker easily obtain header information of VoIP packet through sniffing it. In this paper, we generate three anomaly traffic – CANCEL/BYE DoS and RTP flooding anomaly traffic. CANCEL traffic do not need authentication key in SIP header. So attacker can generate CANCEL anomaly traffic using sniffed information from unencrypted SIP message. In the contrast, BYE message have to need authentication key for call termination. Because the authentication key in BYE message is the same as the key in INVITE message, the attacker easily generate BYE DoS anomaly traffic through obtaining user information and the authentication key from unencrypted INVITE and OK message, RTP flooding traffic generation is easy because RTP packet is also not encrypted, so the attacker can send RTP flooding traffic which is similar with normal RTP traffic. However, it is difficult to generate INVITE and Registeration anomaly traffic because the attacker can not know the authentication key before generating these anomaly traffic. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

CANCEL DoS Anomaly Traffic attacker CANCEL Traffic does not use authentication field CANCEL Wireless access router Internet INVITE CNU Network INVITE Request Terminated VoIP Node 1 Proxy server Router We generate CANCEL DoS anomaly traffic through sniffing VoIP traffic in wireless network. (click)From INVITE message, we generate fake CANCEL message, then send to proxy server. Proxy server regard as normal cancel state because fields of this CANCEL traffic are the same as normal CANCEL traffic. After that, proxy server send request terminated to VoIP node 1 for informing normal termination of the calls. The call of VoIP node 1 is canceled by the attack VoIP Node 2 Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

BYE DoS Anomaly Traffic BYE Traffic uses authentication field attacker BYE Wireless access router Internet INVITE OK CNU Network INVITE VoIP Node 1 Proxy server Router (Click)For generating BYE DoS anomaly traffic, it is similar with generating CANCEL DoS anomaly traffic. Fake BYE message is made from sniffing INVITE and OK messages. We copy some fields using in BYE message from INVITE and OK message. (click)We send it to proxy server, then the server send to VoIP node 2. After that, call of VoIP node 2 is terminated, and VoIP node 1 does not know that call is terminated. At that time, RTP traffic is only transmitted from VoIP node 1 to proxy server. OK The call of VoIP node 2 is only terminated by the attack VoIP Node 2 : RTP Traffic Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

RTP Flooding Anomaly Traffic : RTP Traffic : RTP Flooding Traffic attacker Wireless access router Internet CNU Network INVITE VoIP Node 1 Proxy server Router (click)RTP flooding traffic is generated through sniffing RTP packet in wireless network. The attacker generates over 1000 packets in short time and send to proxy server. After that, voice communication is caused disconnecting or degrading voice quality. Degradation of voice quality due to the attack between node 1 and node 2 OK VoIP Node 2 Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Detection Architecture Capture packets Analyze packets Flow management Create IPFIX flow Send IPFIX flow Receive IPFIX flow Analyze IPFIX flow DB (Save traffic information) Packets IPFIX flow generation (Router or Switch) IPFIX flow collector IPFIX Flow (TCP/UDP/SCTP) Detect anomaly VoIP traffic using this information Visualization Visualization of detection results This is our VoIP-related anomaly traffic detection architecture. This architecture is consisted of IPFIX flow generator, IPFIX flow collector and visualizer. In the generator, packet is captured and analyzed. The generator create IPFIX flow, then send it to IPFIX flow collector. The collector receives the IPFIX flows from the generator, then analyzes and save traffic measurement results to database. Visualizer represents anomaly traffic detection results. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

RTP first sequence num. = 618 IPFIX Template RTP-related template Monitor RTP header fields Can detect RTP-related anomaly traffic RTP flooding Malformed RTP traffic Default template Monitor default flow information bit and packet rate Classification by port number Difficult to monitor VoIP traffic using this template SIP-related template Monitor SIP header fields Call-ID, SIP message type Voice codec, IP address / port number for transmitting RTP traffic Can detect SIP-related anomaly traffic from this template IPFIX Header Set ID Length Template ID = 262 Field count = 19 Default template RTP first SSRC = 600 Field Length = 4 RTP Jitter = 604 RTP packet loss rate = 606 RTP payload type = 608 Field Length = 2 RTP ave. oneway delay = 616 RTP first sequence num. = 618 RTP last sequence num. = 619 SSRC changed count = 620 RTP Max. sequence num. = 621 RTP Min. sequence num. = 622 Version = 10 Total length Export time Sequence number Source ID Set ID Length Template ID = 260 Field count = 9 Src IPv4 Addr = 8 Field Length = 4 Dst IPv4 Addr = 12 Src port = 7 Field Length = 2 Dst port = 11 Protocol = 4 Field Length = 1 First timestamp = 22 Last timestamp = 21 OctetDeltaCount = 1 PacketDeltaCount = 2 IPFIX Header Set ID Length Template ID = 261 Field count = 14 Default template SIP call-ID = 400 Field Length = 50 SIP MSG type = 412 Field Length = 4 SIP RTP codecs = 403 Field Length = 1 SIP RTP port = 409 Field Length = 2 SIP RTP IPv4 addr = 410 This IPFIX template provides default information of traffic – byte/packet count, IP address, port number and timestamp. Using this template, we can not monitor SIP and RTP traffic because this template does not provide their header information. So we define 2 IPFIX template for monitoring SIP and RTP traffic. (Click)This template SIP-related IPFIX template. This template add on some fields of SIP and SDP over default template. From SIP header, we monitor Call-ID and SIP message type, From SDP, we observe information of voice communication session – IP address, port number and voice codec. (Click)This IPFIX template is for monitoring RTP traffic. This template include RTP header information such as SSRC and sequence number and QoS metrics such as packet loss rate and one-way delay, voice codec Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

IPFIX Fields – 802.11 MAC Header Information 802.11 MAC First Sequence number = 500 Field Length = 2 802.11 MAC Last Sequence number = 501 Source MAC = 56 Fiend Length = 6 Destination MAC = 80 802.11 MAC header analysis Sequence number in 802.11 MAC header Source MAC/ Destination MAC address Not independent template When traffic measurement is performed at wireless access router, add on these fields in each template This IPFIX fields are analyzed 802.11 MAC header. We observe source and destination MAC address, sequence number in 802.11 MAC header. When traffic measurement is performed at wireless access router, add on these fields in each template. When traffic measurement is performed at wireless access router, we can add on these fields in each template for monitoring 802.11 MAC header. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

CANCEL DoS Anomaly Traffic Detection Source MAC address If SRC. MAC address is different with INVITE SIP messages  attack The possibility of source MAC address spoofing Need sequence number inspection Sequence number Sequence number gap CANCEL traffic (A) Last IP packet having the same 4-tuple before CANCEL traffic(B) Gap = B - A Sequence number gap >= “N”  attack In our CANCEL DoS anomaly traffic detection, we use source MAC address and sequence number in 802.11 MAC header. First, we match source MAC address between searched CANCEL message and INVITE message which has the same Call-ID and 4-tuple information. However, an attacker can transmit anomaly traffic spoofed source MAC address. So after source MAC address step, we calculate sequence number gap between CANCEL traffic and last IP packet of the same flow before the CANCEL traffic. If the gap is over N or the same as N, the searched CANCEL traffic is anomaly. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

BYE DoS Anomaly Traffic Detection In SDP Include IP address and port number for transmitting RTP traffic In order to obtain this information INVITE : source IP address and port number OK : destination IP address and port number Timestamp of RTP traffic In normal state The RTP traffic is not observed after BYE traffic In abnormal state The one-way RTP traffic is observed over constant time after BYE traffic In SDP, there is session information of transmitting RTP traffic. So we extract this information from INVITE and OK message. From INVITE, source IP address and port number are obtained and destination IP address and port number are obtained from OK message. From obtained the information, we search timestamp of RTP traffic. The reason of using the timestamp is that RTP traffic is not existed after BYE traffic in normal state. However, if an attacker generates BYE DoS anomaly traffic, the RTP traffic is observed after BYE traffic. Call of VoIP user received BYE DoS anomaly traffic is terminated. Since another VoIP user does not know the call termination, the one-way RTP traffic is observed in the VoIP network. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

RTP Flooding Detection SSRC in RTP header SSRC field in RTP header Do not change the value in the same call connection Check ‘SSRC changed count’ If the value of this field > “1” RTP anomaly traffic Sequence number in RTP header Possible to be spoofed SSRC field from normal RTP traffic Compare Max./Min. and the first / last sequence number (Min. Seq. < first Seq.) || (Max. Seq. > last Seq.) No sequence number is wrapped in a RTP flow (Max. Seq. < first Seq.) || (Min. Seq. > last Seq.) Sequence number is wrapped in a RTP flow For detecting RTP flooding traffic, we use SSRC and sequence number of RTP header. First, we check ‘SSRC changed count’ IPFIX field. Because SSRC value is not changed in the same call connection, if the value of this field is over 1, the RTP anomaly traffic is occurred. It is possible to be spoofed SSRC field from normal RTP traffic, so we compare sequence number in a RTP flow for detecting RTP anomaly traffic. For comparing sequence number, we use minimum, maximum, last and first sequence number. Because range of the sequence number in RTP header is 0 ~ 65535, we propose 2 kinds of sequence number comparison whether the sequence number is wrapped or not. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Experiment Environment attacker Wireless access router VoIP Node 1 Phone number 070-8268-7729 CNU Network IPFIX router router HUB Internet WLAN Traffic monitor VoIP anomaly traffic Korea 070 VoIP Service Provider VoIP Node 2 Phone Number: 070-8288-7729 IPFIX flow generator Modified nProbe[28] IPFIX flow collector Modified libipfix[29] Save traffic monitoring results Mysql[30] For experiment in real VoIP network, we used two commercial VoIP phones which number is started 070. We established wireless access router included two wireless LAN cards. One wireless LAN card is used for access point. Another one is used for monitoring traffic. In wireless access router, we installed modified nProbe for monitoring VoIP traffic and generating IPFIX flows. The attacker having two wireless LAN cards established between VoIP Node 1 and wireless access router. One LAN card is used for sniffing VoIP traffic. Another one is used for sending VoIP anomaly traffic to the proxy server in a service provider. Generated IPFIX flows are transmitted to IPFIX collector. For collecting and decoding IPFIX flows, we use modified libipfix. In addition, the IPFIX collector is installed mysql to save monitoring results. In addition, our anomaly traffic detection program is installed at the collector. DB IPFIX Proxy Server IPFIX Collector and VoIP anomaly traffic detector Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Evaluation Results CANCEL DoS Detection BYE DoS RTP Flooding Attack types Total flows Anomaly flows Precision (%) Recall F-Score CANCEL DoS 381 89 100.00 95.50 97.69 BYE DoS 755 118 97.39 94.92 96.13 RTP Flooding 810 103 96.26 98.09 Total 1,946 310 97.72 96.77 97.24 CANCEL DoS Detection Sequence number gap : 5 in this experiment Few CANCEL DoS anomalies are generated over configured sequence number gap BYE DoS Constant time : 1 min. in this paper Sometimes, after normal BYE traffic, few RTP traffic is observed over configured time. RTP Flooding Few normal RTP traffic Be mistaken for anomaly traffic because of wrapping of the sequence number in a RTP flow Overall detection accuracy of proposed our three VoIP anomaly traffic detection is 97.24%. In CANCEL DoS anomaly traffic detection, we set sequence number gap as “5”. So few CANCEL DoS anomalies are not detected because the anomaly traffic is generated over our configured sequence number gap. We configured constant time as 1 minute for detecting BYE DoS anomaly traffic. Sometimes, after normal BYE traffic, few RTP traffic is observed over configured time. Moreover, after BYE DoS anomaly traffic, some RTP traffic is observed in our configured time. In RTP flooding detection, the accuracy is about 98%. The reason of precision is that few normal RTP traffic was mistaken for anomaly traffic because of wrapping of the sequence number in a RTP flow. This table represents evaluation results of our detection method. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Conclusion & Future Work In this paper, we proposed VoIP anomaly traffic detection method using IPFIX in real VoIP network Define new IPFIX templates and add IPFIX fields for monitoring 802.11 traffic CANCEL DoS detection method Source MAC address and sequence number in 802.11 BYE DoS detection method SIP header information and timestamp of RTP traffic RTP flooding method SSRC and sequence number in RTP header Future work Plan to extend our approach to detect other possible VoIP attacks Devise a protection method against comprehensive IP telephony anomalies Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Reference [1] VoIP member count in Korea, http://www.asiae.co.kr/news/view.htm?idxno=2009093011543343825. [2] VoIP member expectation in U.S.A.,http://www.crm2day.com/content/t6 librarynews 1.php?news id=113826. [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, SIP: Session Initiation Protocol, IETF RFC3261, June 2002. [4] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, RTP: A Transport Protocol for Real-time Applications, IETF RFC3550, July 2003. [5] D. Geneiatakis, T. Dagiuklas, G. Kambourakis, C. Lambrinoudakis, S.Gritzalis, K. S. Ehlert, and D. Sisalem, Survey of security vulnerabilities in session initiation protocol, Communications Surveys & Tutorials, IEEE Volume 8, Issue 3, 3rd. Qtr. 2006 Page(s):68 - 81 [6] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol, IETF RFC 5246, Aug. 2008. [7] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, The Secure Real-time Transport Protocol (SRTP), IETF RFC 3711, Mar. 2004. [8] H. Sengar, H. Wang, D. Wijesekera, S. Jajodia, Detecting VoIP Floods Using the Hellinger Distance IEEE Transactions on Parallel and Distributed systems, Vol. 19, No. 6, pp. 794-805, June 2008. [9] J. Quittek, T. Zseby, B. Claise and S. Zander, Requreiements for IP Flow Information Export(IPFIX), IETF RFC3917, October 2004. [10] S. Anderson, S. Niccolini, and D. Hogrefe, SIPFIX: A Scheme for Distributed SIP Monitoring, IEEE IM2009, 2009. [11] H. Sengar, D. Wijesekera, H. Wang, S. Jajodia, VoIP Intrusion Detection Through Interacting Protocol State Machines, IEEE DSN, pp. 393-402, June 2006. [12] F. Guo and T. Chiueh, Sequence Number-Based MAC Address Spoof Detection, in Proceedings of 8th International Symposium on Recent Advances in Intrusion Detection (RAID 2005), September 2005. [13] C. Lee, H. Kim, K. Ko, J. Kim, and H. Jeong, A VoiP Traffic Monitoring System based on NetFlow v9, International Journal of Advanced Technology, vol. 4, March 2009. [14] Y. Ding and G. Su, Intrusion detection system for signal based SIP attacks through timed HCPN, Second International Conference on Availability, Reliability and Security (ARES), 2007. [15] H. Son and Y. Lee, An Anomaly Traffic Detection Method for VoIP Applications using Flow Data, PAM2009 Student Workshop, 2009. [16] L. Deri, nProbe: an Open Source NetFlow Probe for Gigabit Networks, TERENA Networking Conference, May 2003. [17] libipfix Internet Measurement Project: http://ants.fokus/fraunhofer.de/libipfix. [18] MySQL, http://www.mysql.com. Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02

Thank you Q&A Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 2019-05-02