V2W security - defense mechanisms against SIP DDoS flood

Transcription

1 V2W security - defense mechanisms against SIP DDoS flood Jan Staněk [email protected] Research & Development center(rdc) for Mobile Applications Czech Technical University in Prague Technická 2, Prague 6, Czech Republic October 2010 Abstract In this report we focus on the possibilities of defense against DDoS flood attacks targeting a SIP server. For simulation of such attacks, we will use SIPp-DD, a SIP DDoS simulation tool which we developed in previous part of the project. As we have already showed in previous work, it is quite simple to defend against a DoS flood(using thresholding and source IP address blocking approach) but for DDoS flood the situation is much more complicated. Since we cannot use the source blocking approach (because computing the threshold for distributed attack is impossible in general and the addresses can be spoofed), we have done some survey of known solutions and designed our own solutions. We have also implemented some of our ideas in form of testing prototypes. 1 Introduction The problem of defense against DDoS flood attacks is very complicated and there is no general solution. There are some ways how to protect against these attacks but none of these are ideal. The biggest problem is that the DDoS flood attack usually congests the whole service capability of the server (sometimes even the whole network around the server) and there is no capacity left for the legitimate users. When we have a good detection mechanism, we can mark the source addresses of the attackers and block them, therefore mitigating the attack. However there is still the problem of address spoofing. If the source addresses are spoofed, we cannot block them because they are usually continuously changing and we might even unintentionally block the addresses of legitimate users. Flooding SIP server is different from general DDoS floods because it is not necessary to generate millions of messages. As we have showed in the previous part of this project, a few thousand SIP messages are enough to effectively congest a SIP server. Therefore we can expect the attacker to use only the necessary amount of messages instead of producing an overwhelming general flood because it will be effective (the SIP service 1

2 will be disturbed) and much cheaper in terms of resources. Considering this situation, if we design an application that will preprocess the SIP messages and decide whether or not to send them to the SIP server, we might be able to stop the attack. The principle seems to be easy, but the realization has some catches which we will address later in this report. 2 Related work We did a survey in the IEEE Xplore and ACM digital library and found out, that the problematics of DDoS attacks against SIP protocol was addressed in a few papers already. Nassar et. al. [1] used a fake VoIP environment as a honeypot, published its address openly on the Internet and lured the attackers to it. From the list of attackers trying to target the honeypot they created a blacklist for their actual SIP environment. Fiedler et. al. [2] proposed a very complex modular solution which counts on using information from all the layers (starting at eth layer). Ha et. al. [3] were aiming specifically at DDoS attacks and provided a detection system based upon SIP payload analysis and classification metrics using information about the caller and callee credentials and addresses. Akbar and Farooq [4] experimented with usage of evolutionary algorithms for flooding attacks detection. 3 SIP DDoS flood attack As we already stated in the introduction, we will not try to find a solution for blocking a general DDoS flood attack because it is a very complicated problem and numerous big security teams are already trying to find solution to it. Instead, we will focus on the specific problem of SIP DDoS flood attacks since it is quite simple to disturb the SIP service this way, even with very limited resources. First it is important to understand the difference between the general flood and SIP flood attack. We use the simplified term SIP DDoS flood attack for a DDoS flood attack using SIP messages and having an attack rate of a few thousand SIP requests per second or less. To design a defense solution against a SIP DDoS flood we have to first understand the principle and impact of the attack. A typical SIP server works in a standard way - it gets SIP messages on its input (requests) and generates SIP messages on its output (responses). SIP servers nowadays are typically using parallel processing of requests and it is no problem for them to handle hundreds of requests per second. Because SIP is only the initiation protocol and it is most often used only at the beginning and end of the session, there is no real need for fine grained optimization (even if you have a company with ten thousand employees, a common SIP server with the capability to process say 500 requests per second is enough because the possibility that more than 500 employees will start or end a call in precisely the same second is very low). This, however, can be easily exploited by an attacker since generating a few thousand requests per second is not a big deal. 2

3 Process of a SIP DDoS flood is quite simple. The attacker either uses a tool which is able to spoof source IP addresses of the SIP messages (like our testing tool SIPp- DD) or a botnet (a group of computers with different addresses, remotely controlled by the attacker) and this way generates a constant flow of SIP requests with the rate of few thousands requests per second. These requests cannot be blocked by a simple DoS defense (as we have tested and proved in the previous part of the project - see the previous report for more details) and so they are arriving to the target SIP server. If the types of the messages are wisely chosen (SIP messages that have non-trivial processing which requires for example to check the user database are well suited for the attack), they consume all of servers processing capacity (results of our previous tests showed that server running an Asterisk PBX gets to the state of CPU exhaustion, OpenSIPS consumes whole RAM etc.) 4 Design of our defense mechanism The design of our defense mechanism is based upon the simple idea which we stated in the introduction - a preprocessing application for all SIP requests which decides whether or not to forward the request to the SIP server. As we have already explained, the impact of a SIP DDoS flood is caused by resource exhaustion - SIP servers consume all resources in order to process non-trivial SIP requests. Therefore if we create an application which will be able to filter out the bad requests and forward only the legitimate ones to the SIP server, we will have our desired solution. The application must be able to process thousands of SIP messages per second without high resource consumption (or else it will be vulnerable in the same way as the SIP server itself) and must be able to forward the requests to the SIP server transparently (the clients have no idea that there is something like our application, they believe that they are sending their requests directly to the SIP server). Considering the requirements stated for the application, it is obvious that it must not process the payload of SIP requests and must be able to make very quick decisions whether or not the SIP message should be forwarded to the SIP server. When we were thinking about the possibilities of how to achieve these goals we have created two different approaches. At first we have thought that the application must have the capability to decide whether or not to forward the requests to the SIP server and take care of the forwarding process itself but it showed up, that this is not really necessary. An idea of a very simple, yet against some of SIP DDoS floods also very effective, mechanism appeared. Therefore we have created two branches - one branch following the original idea of application with the described capabilities and the other one focusing on evaluation of the simple method using the SIP redirect response message. 4.1 Using the redirection response This section describes the details of our idea of a very simple application which can be used to mitigate some types of SIP DDoS floods. The basic principle of the application 3

4 is the creation of a SIP redirection response. The application itself does not process the SIP request it gets. It only extracts the information about the sender from the message and sends a SIP redirection response to the contact. And that is the whole trick - no validation of the request, no additional processing, no forwarding and yet, it works. How, why and what are the limitations of this approach is described in the following paragraphs SIP redirection First some necessary information about the redirection implementation in SIP. SIP redirection type of response message is an integrated part of the SIP protocol. It is defined as a SIP response message beginning with the 3xx code (where xx are ciphers specifying the details of the redirection response) used to indicate that the target of the requested service has moved. Although this message was not designed for this purpose, we can easily use it to defend against dumb flood attacks. Example of SIP redirection response: SIP/ Moved Permanently Via: SIP/2.0/UDP :59224; branch=z9hg4bk-d8754z-ca4e6863d80b d8754z-; received= ;rport=26596 To: "asterisk"<sip:[email protected]> From: "asterisk"<sip:[email protected]>;tag=0b12fb06 Call-ID: OWFmNDZjM2FlODJjNDM2NGFiNTZhODljZWM4NmMwYmU. CSeq: 1 REGISTER Contact: sip: : Usability and limitation The limitation of this approach is that we expect that the attack will be created using simple bots with no advanced processing logic and without the preparation survey of the targeted SIP environment by an attacker. We know that these limitations are very restrictive but when we investigated the situation more closely, we found out, that the described situation can be in fact very common. We will try to illustrate it using a real life example. Pete, in our example the attacker, which used to be employed in a big company, was fired. He is angry and wants some form of revenge. On the Internet, he founds out, that it is quite simple to disturb a telephony service if it is based upon the VoIP, concretely SIP, using a SIP DDoS flood attack. There is also a nice tool for generation of such attack and a step-by-step manual how to use it. Pete remembers that the company uses VoIP telephony and decides to use the tool for his revenge. He also remembers the address of the server used for providing the VoIP service (since it lit on his phone in work every day, when he was still employed) and so he enters this address, activates the tool and smiles. 4

5 If, however, there was no real SIP server at the publicly known address but there was our simple redirection application and the address of the real SIP server will not be published anywhere (except the generated redirection messages), the attack will have no impact on the VoIP service in the company (we expect that the tool will be using spoofed addresses hence it will not receive any of the redirection responses and cannot target the real SIP server) Architecture The architecture is very simple. We need two servers - one running our application and one running the actual SIP server (of course both can be easily run on the same machine on different ports or using virtualization if we don t have a spare machine). The address and port where our application runs is publicly known and referred to as the location of the SIP server, the actual location of the real SIP server is contained only inside the SIP redirect responses generated by our application. Figure 1: SIP traffic diagram Advantages Easy implementation The implementation is quite easy and if you do not need extra optimization then a few dozen lines of code in any of higher programming languages can do the trick. Blocks dumb DoS floods too DoS floods are blocked in the same way as DDoS floods. Blocks DDoS floods with spoofed sources Probably the biggest advantage - if an attacker uses source IP address spoofing mechanism then the attack is completely blocked because the attacker never gets a response with the redirection information Disadvantages Useless against smart attackers If the attacker does the survey of the VoIP environment before deploying the attack and finds the real address of the SIP server 5

6 or if the bots creating the attack have advanced logic and are capable to react to the redirection responses, the proposed defense is useless. Need to keep the address of the real SIP server a secret If the address of the real SIP server is publicly known then the attacker will target the server directly. We can mitigate this disadvantage using a pool of addresses for the real SIP server from which the actual address is chosen using some algorithm (of course this will require the addition of this functionality to the redirection application too). Additional work for the client Each client has to contact the redirection application at the beginning and then react to the redirection response. This also introduces a small delay but it should not be observable by a human user Prototype implementation To prove the usability of our idea we have created a prototype implementation. We have not focused on optimization but rather on the simplicity of implementation. Therefore we have used Python as the programming language and Twisted library for SIP message manipulation and networking. The complete source code of our prototype is enclosed in Appendix A. To test our implementation you need to have installed Python + Twisted in version 2.5.x or 2.6.x (we have used version 2.6.6). Looking at the code, it is obvious, that even though the solution is working, it is totally unoptimized. Also some problems occasionally occurred during testing when the SIP traffic was NATted and the information about source port were not inserted in the right place in the SIP Via field. We are aware of these problems and we also know it is not very complicated to get rid of them but we do not want this testing solution to be misused. So, if you want to use the idea, feel free and implement your own version without these artifacts. 4.2 Using a forwarding application with heuristics This section describes the details of our second approach. Even though the previously described defense application using redirection is an interesting solution capable of mitigating many SIP DDoS floods, the problem of smart attackers still remains. To check how easy it is to simulate such smart attack, we have tried to create a smart bot which will be able to react to the redirection responses and forward his attack flow against the real SIP server. As a basis we have used our SIPp-DD tool. Even though it is not usable as a single DDoS flood creator (as we have showed, address spoofing is useless against the redirection application) we managed to create a smart DoS flood. Therefore if we have a botnet, we might easily produce a DDoS flood if we run our properly configured SIPp-DD on the individual bots. Because we showed that smart attackers are a problem, we decided to design a more sophisticated solution. The application described in the following paragraphs is rather a skeleton for creation of a more complex solution than a definitive solution. Thanks 6

7 to its modular design, it is easily extensible and configurable and you might implement and use any heuristics you like. 4.3 Architecture This solution needs two servers - one runs the forwarding application and the second runs the actual SIP server. You can use one machine and virtualization, but since the application itself is expected to consume a fair amount of resources, we cannot recommend that. It is also a good idea to hide the real SIP server inside a private network so it will not be reachable directly from the Internet. This way you can prevent the possibility that the attacker will bypass your application and attack directly the SIP server and can also guarantee that the computers inside the private network will not be accidentally blocked by the forwarding application (this setup expects that the computers inside the private network are trustworthy). As in the previous approach, the address and port where our application runs is publicly known and referred to as the location of the SIP server. Figure 2: SIP traffic diagram Now let us have a closer look at the SIP message processing. The client creates a SIP request and sends it to the forwarding application (which he considers to be the real SIP server). The application receives the message. Then the application checks its actual state. There are two possible states - normal and under attack. If the state is set to normal then the application forwards the request to the SIP server. If the state is set to under attack, heuristics are applied to the received request before it is either forwarded to the SIP server or dropped. Afterwards, the application computes new state according to the counter of received messages in the last time period (the new state is again either normal or under attack ) and the process continues with the next request. The responses from the SIP server are routed directly to the client, the forwarding application does not handle these in any way. We have vaguely mentioned that the application chooses a new state and uses heuristics but we have not described what to imagine under these processes. This is due to the fact that there are several possibilities/configurations for both processes which differ in complexity and usability. We will describe some of the possibilities in the next two sections and also use some of these for our prototype implementation. However, this is 7

8 by no means a final list of possibilities and you are encouraged to develop your own new methods. We will be glad if you share your results with us then State decision algorithm Flood attacks are generally easily detectable since they are composed of huge amounts of messages whose purpose is to congest target service. SIP DDoS floods do not differ in this characteristic and thanks to the fact that SIP is used mainly for initiation and termination of sessions only, it is very unusual that high amounts of messages are processed in a time period. Therefore it should not be a problem to define an absolute top threshold of SIP messages processed by a SIP server per time period in any SIP environment which corresponds to the common traffic. Choice of concrete values for the threshold and time period may vary according to the individual needs of the concrete SIP environment. After we have setup the threshold and time period, the process of state decision is quite straightforward. We use one counter and increase it per every received request. The counter is periodically zeroed with every passed time period. Two checks are periodically done. First check is whether the counter exceeds the threshold. It is done after each received request and if the counter exceeds the threshold then the application changes state from normal to under attack. The second check is done at the beginning of every time period before the counter is zeroed. If the actual value of the counter is higher than the threshold, the application remains in the under attack state. If the actual value of the counter is lesser than the threshold and the application was in the under attack state, it changes its state to normal. Otherwise it remains in the normal state. There are a few possible improvements of this decision mechanism. We can use a varying time period which will reflect the actual situation (shorter under attack, longer otherwise...absolute or proportional relative changes etc.). We can use a varying threshold which will reflect the actual load. We can introduce some analysis over a longer time (including more time periods) and use its results for changing the mentioned parameters. However, we must keep in mind, that very long time period can lead to late detection of an attack which might affect the processing capabilities of the SIP server and very short time periods might exhaust the resources of the server running our application. A good recommendation is to do some analysis of the logs of SIP traffic in your network and setup the threshold and time period according to these and after that start experimenting with varying values. A notable improvement might be using more counters for different types of SIP requests. This will introduce some additional load on the server running the application, but the overall results might be better since the floods are generally uniform (using only one type of request) and only a few types of SIP requests are suitable for a flood. This might also mitigate the problems if you use some SIP messages for additional services (like SIP INFO for additional data transfer) and these messages will make your threshold too high. 8

9 4.3.2 Heuristics The heuristics will be used in the application only when there is a suspicion that the attack is in progress. The purpose of the heuristics is to decide whether the message should be forwarded to the SIP server or dropped. There are numerous ways how to acquire this decision. The ones we considered are Access lists The access lists may be based either upon IP address of the client or upon provided credentials. We might use classic whitelist, graylist or blacklist. A better option might be a combination of whitelist and list containing logs of usage in the last few days. There are numerous possibilities and none is generally the best...it depends on the concrete SIP environment. Message type control Since the SIP DDoS floods will be often uniform in the type of the message it might be useful to block only that type of the message and let the rest come through. This might be a problem if the message type used is INVITE but might be very useful if the message is REGISTER - already registered clients will be fine and may continue using the service without problems. Message payload control We can suppose that the messages used in a SIP DDoS flood will have common pattern. Either it might be only a duplication of the exactly same message or there might be a part generated randomly - these patterns can be tracked and used as blocking patterns for attack messages. Using this approach might be a bit complicated since we must keep in mind not to make the process too costly otherwise our application can become the congested one and the service will be disrupted even though the SIP server will not be harmed. A good idea for future research will be using neural networks to monitor the SIP traffic and automatically learn what is legitimate and what is not. Using CAMNEP to learn these patterns might be also very useful once we acquire a stable legitimate SIP flow. 4.4 Prototype implementation Creating the prototype implementation, we have again focused mainly on proving the usability of the idea and not on optimization. We have used Python as in our first application and libdnet library for access to low level network services. We have used the dpkt library for easier packet header manipulation. You also has to have a zope interface module installed for the application to work properly. The complete source code of our prototype is enclosed in Appendix B. In our prototype we have implemented only the basic skeleton described in the previous part - one counter for all the message types and a preprepared whitelist. Implementation of other proposed variants should not be hard, but it will be time consuming. The same stands for optimization - using C++ as the programming language for example might speed up the application quite notably, but again, it will be a very time-consuming labor and it is not in the scope of this part of the project. 9

10 5 Combined solution - the double sifter We have presented two different approaches to defense against SIP DDoS floods and proved their usability. Once we finished the prototypes we thought about the combination of both approaches. The idea of their combination is presented in the following picture. Figure 3: SIP traffic diagram As you can see, the combined solution is only serialization of both principles. At first, the client contacts the first application and gets the redirection message. This step will filter out all messages with spoofed sources, which is very useful because this way, the second application does not have to process them. The client then follows the redirection and contacts the second application, which applies its processing and the message is finally forwarded to the SIP server. This solution might look a bit ping-pong like, since the message is sent, resent and forwarded, but the tests show that the delay introduced by this additional processing is not notable and the results in terms of blocking a SIP DDoS flood are satisfiable. 6 Conclusion We have developed two new approaches of the defense mechanisms against SIP DDoS flood attacks. Advantages and disadvantages of both approaches were analyzed and summarized and a prototype implementation was done for both approaches to prove its practical usability. Next to the basic prototype implementations we have also offered some possible improvements and extensions that can be implemented in the future. We have also combined the approaches and created a more robust defense solution. 10

11 References [1] M. Nassar, S. Nicollini, R. State, T. Ewald, Holistic VoIP Intrusion Detection and Prevention System. IPTCOMM, [2] J. Fiedler, T. Kupka, S. Ehlert, T. Magedanz, D. Sisalem, VoIP Defender: Highly Scalable SIP-based Security Architecture. IPTCOMM, [3] DY Ha, HK Kim, KH Ko, ChY Lee, JW Kim, HCh Jeong, Design and Implementation of SIP-aware DDoS Attack Detection System. ICIS, [4] M. A. Akbar and M. Farooq, Application of Evolutionary Algorithms in Detection of SIP based Flooding Attacks. GECCO, July

12 Appendices A Source code of defense application based on SIP redirection #!/usr/bin/env python # simple defense solution against a SIP DDoS flood attack # first import the necessary twisted libs from twisted.internet import reactor from twisted.protocols import sip from twisted.internet.protocol import ServerFactory # general settings # where the application runs(e.g. listens) RECEIVE_HOST = RECEIVE_PORT = 5065 # where is situated the real SIP server SIP_SERVER_HOST = SIP_SERVER_PORT = 5060 # create our own class from an original sipproxy class class SipProxy(sip.Proxy): def init (self): sip.proxy. init (self,host=receive_host,port=receive_port) self.tries=0 # generate a 301 response for every valid SIP request providing the real location # of the SIP server def handle_request(self,message,addr): print message.tostring() print dir(message) if message.method== ACK :return r = self.responsefromrequest(301,message) r.addheader("contact","sip:" + SIP_SERVER_HOST + ":" + str(sip_server_port)) r.creationfinished() self.deliverresponse(r) print r.tostring() print addr self.tries+=1 # just a wrapper for the factory 12

13 class sipfactory(serverfactory): protocol=sipproxy # the main loop of the application - listen and handle the requests reactor.listenudp(receive_port,sipproxy(),receive_host) reactor.run() B Source code of defense application based on SIP message forwarding #!/usr/bin/env python # simple defense solution against a SIP DDoS flood attack import dnet from dpkt import udp from dpkt import ip from threading import Timer import socket # general settings # where the application runs(e.g. listens) RECEIVE_HOST = RECEIVE_PORT = 5065 # where is situated the real SIP server SIP_SERVER_HOST = SIP_SERVER_PORT = 5060 # addresses in the whitelist WHITELIST = # defines for program state NORMAL = 0 ATTACK = 1 # global variables prog_state = NORMAL counter = 0 threshold = 50 time_period = 5.0 running = True # socket initiation receive_socket = socket.socket(socket.af_inet, socket.sock_dgram) receive_socket.bind((receive_host, RECEIVE_PORT)) 13

14 send_socket = dnet.ip() # function that does the periodic check whether or not the amount # of processed SIP messages exceeded the threshold def periodic_check(): global prog_state global threshold global counter if(counter > threshold): prog_state = ATTACK if((prog_state == ATTACK ) and (counter < threshold)): prog_state = NORMAL counter = 0 t = Timer(time_period, periodic_check) t.start() # checks whether the IP address is in the whitelist def is_in_whitelist(check_ip,whitelist): if str(check_ip) in WHITELIST: return True else: return False # creates a packet to be sent using a raw socket def create_packet(payload, maddr): global SIP_SERVER_HOST global SIP_SERVER_PORT # build udp packet u = udp.udp( dport = SIP_SERVER_PORT, sport = maddr[1], data = payload ) u.ulen = len(u) # build ip packet i = ip.ip( dst = dnet.ip_aton(sip_server_host), src = dnet.ip_aton(maddr[0]), data = u, p = ip.ip_proto_udp ) 14

15 i.len = len(i) return str(i) # main loop of the application, repetitively reads from socket # and forwards the messages periodic_check() while running: rdata, raddress = receive_socket.recvfrom(4096) print rdata counter = counter + 1; if(prog_state == NORMAL): send_socket.send(dnet.ip_checksum(create_packet(rdata,raddress))) else: if(is_in_whitelist(raddress,whitelist)): send_socket.send(dnet.ip_checksum(create_packet(rdata,raddress))) 15