Patent Application
20090070875
The present invention relates to telecommunications in general, and, more particularly, to network security.
An intrusion is when an unauthorized user (e.g., a “hacker,” etc.) attempts to break into or misuse (e.g., steal confidential data, etc.) a computer system. An intrusion-detection system (IDS) monitors messages (e.g., packets, etc.) incoming to a computer system and outgoing from the computer system, and based on these messages tries to determine whether an intrusion is being attempted. An intrusion-detection system might conclude that an intrusion attempt is in progress when an atypical or suspicious sequence of messages occurs, or when a sequence of messages matches a known attack signature.
Each computer system 204-n, where n ∈ 1,2, . . . ,N, might be a personal computer, a server, a laptop computer, a personal digital assistant (PDA) with wireless local-area network communication capability, etc.
An incoming message that is directed to computer system 204-n, where n ∈ 1,2, . . . ,N, first passes through firewall 215, which inspects the message and decides whether to block the message from reaching its destination or to let the message through based on rules in a rule set. Examples of rules include: block all messages from domain badguys.com; block all messages except those of a certain protocol type; etc.
If firewall 215 lets the incoming message through, then intrusion-detection system (IDS) 220 subsequently receives the message and inspects it. Intrusion-detection system (IDS) 220 provides an additional layer of security by detecting intrusion attempts that comprise one or more messages that are allowed through firewall 215. For example, firewall 215 might restrict external access to a web server in internal network 101 to port 80, but without an intrusion-detection system, it might be possible to attack the web server itself via legitimate traffic through port 80 due to bugs in the web server software (e.g., ColdFusion, Apache, etc.). As an analogy, firewall 215 acts as a “fence” around internal network 101. A fence provides security but does not have the ability to detect when someone is trying to break in (e.g., by digging an underground tunnel, etc.). Intrusion-detection system (IDS) 220 typically can recognize some break-in attempts that firewall 215 cannot detect, and therefore it is advantageous to deploy intrusion-detection system (IDS) 220 in addition to firewall 215 for added security.
When intrusion-detection system (IDS) 220 relies on an attack signature database, it is essential to keep the database up-to-date. In particular, over time malicious users often discover new techniques to exploit vulnerabilities and attack systems, and in response security experts formulate new attack signatures to guard against these techniques. As in the case of antivirus software, the owner of intrusion-detection system (IDS) 220 typically has two options to ensure that the attack signature database is regularly updated with new attack signatures: either subscribe to an automated update service provided by the vendor of intrusion-detection system (IDS) 220, or manually check for new attack signatures and retrieve and install them. In either case, the efficacy of intrusion-detection system (IDS) 220 depends on the owner's diligence—in the former option, the owner must periodically pay subscription fees in a timely fashion, and in the latter option, the owner must check for new updates with great frequency—as well as some combination of time, effort, and money.
Voice over Internet Protocol (VoIP) systems transmit voice traffic over packet-switched Internet Protocol (IP) data networks in lieu of circuit-switched telephony networks (e.g., the Public Switched Telephone Network, etc.). Typically, Voice over Internet Protocol systems are based one of two main protocols: H323 and Session Initiation Protocol (SIP). In both types of systems, VoIP user agents at the calling and called telecommunications terminals (e.g., hardphones, softphones, etc.) send and receive packets that contain encoded voice signals in accordance with the Real-time Transport Protocol (RTP). In addition, a VoIP gateway might employ a media management protocol such as the Media Gateway Control Protocol (MGCP) or MEGACO/H.248 in order to translate traffic transparently between an IP-based network and a non-IP-based network (e.g., between a PSTN phone and an IP phone, etc.).
A key benefit of VoIP is that it enables the convergence of voice and data networks. By migrating voice traffic to data networks, however, the voice network becomes vulnerable to intrusions and other attacks (e.g., denial-of-service attacks, authentication attacks, etc.) that compromise privacy, quality of service, and accurate billing. Moreover, due to characteristics of Voice over Internet Protocol systems, some intrusion-detection systems of the prior art provide inadequate security against intrusions that employ VoIP packets (i.e., VoIP-based intrusions).
The present invention enables the detection of intrusions in Voice over Internet Protocol (VoIP) systems, without the use of an attack signature database. In particular, the illustrative embodiment is based on two observations. The first observation is that various VoIP-related protocols (e.g., the Session Initiation Protocol [SIP], etc.) are simple enough to be represented by a finite-state machine (FSM) of compact size, thereby avoiding the disadvantages inherent in signature-based intrusion-detection systems. The second observation is that there exist intrusions that might not be detectable locally by the individual finite-state machines (FSMs), but that can be detected with a global (or distributed) view of all the finite-state machines (FSMs) involved in a particular session.
The illustrative embodiment maintains a finite-state machine (FSM) for each session/node/protocol combination representing the allowed (or “legal”) states and state transitions for the protocol at that node in that session, as well as a “global” finite-state machine (FSM) for the entire session that enforces constraints on the individual finite-state machines (FSMs) and is capable of detecting intrusions even when each of the individual session/node/protocol finite-state machine (FSMs) are in legal states.
The illustrative embodiment comprises: generating a signal that indicates a potential intrusion when a protocol fails to enter a first state at a first node within δ seconds of said protocol entering a second state at a second node, wherein δ is a positive real number.
For the purposes of this specification, the following terms and their inflected forms are defined as follows:
Network 305 is capable of transporting messages between a source (e.g., one of VoIP nodes 310-1 through 310-4, from IDS 320, etc.) and destination (e.g., one of VoIP nodes 310-1 through 310-4, from IDS 320, etc.) in well-known fashion. As will be appreciated by those skilled in the art, network 305 is depicted in
Each VoIP node 310-i, where i is an integer between 1 and 4 inclusive, is one of a VoIP-capable terminal, server, gateway, etc. that is capable of transmitting and receiving messages in accordance with one or more Voice-over-IP protocols (e.g., Session Initiation Protocol [SIP], Real-time Transport Protocol [RTP], etc.), in well-known fashion. In accordance with the illustrative embodiment, each VoIP node 310-i is programmed to notify intrusion-detection system (IDS) 320 of any protocol state transitions at VoIP node 310-i. For example, when there is a change in the state of the Session Initiation Protocol (SIP) at VoIP node 310-i, VoIP node 310-i might transmit a SIP message that is ignored by other VoIP nodes but that indicates to IDS 320 of the protocol state change.
It will be clear to those skilled in the art, after reading this disclosure, how to make and use VoIP nodes 310 in accordance with the illustrative embodiment. As will be appreciated by those skilled in the art, there are a variety of alternative techniques that might be employed for notifying IDS 320 of protocol state transitions at VoIP nodes 310, and it will be clear to those skilled in the art, after reading this disclosure, how to make and use VoIP nodes 310 that employ such techniques.
Intrusion-detection system (IDS) 320 is capable of: monitoring messages transported over network 305 (i.e., “packet sniffing”) in well-known fashion; of being programmed to block messages in accordance with one or more specified policies, after an intrusion has been detected; and of executing the tasks described below and with respect to
As will be appreciated by those skilled in the art, although the illustrative embodiment employs a single centralized intrusion-detection system (IDS) 320, some other embodiments of the present invention might employ a plurality of intrusion-detection systems in a distributed manner (for example, an IDS embedded at every VoIP node), and it will be clear to those skilled in the art, after reading this disclosure, how to make and use such embodiments.
Receiver 401 receives signals from network 305 and forwards the information encoded in the signals to processor 402, in well-known fashion. It will be clear to those skilled in the art, after reading this disclosure, how to make and use receiver 401.
Processor 402 is a general-purpose processor that is capable of receiving information from receiver 401, of executing instructions stored in memory 403 (including, in particular, instructions corresponding to the tasks of
Memory 403 stores data and executable instructions, as is well-known in the art, and might be any combination of random-access memory (RAM), flash memory, disk drive memory, etc. It will be clear to those skilled in the art, after reading this disclosure, how to make and use memory 403.
Transmitter 404 receives information from processor 402 and transmits signals that encode this information to network 305, in well-known fashion. It will be clear to those skilled in the art, after reading this disclosure, how to make and use transmitter 404.
As will be appreciated by those skilled in the art, the fact that data sub-block 605-i-j comprises three finite-state machines 770 is merely illustrative, and there might be a fewer number or greater number of finite-state machines 770 corresponding to respective protocols at VoIP node 310-j in session i.
As shown in
As will be appreciated by those skilled in the art, although in the illustrative finite-state machine (FSM) 707-i-j-k of
State 901 represents a composite of the states of: a calling node's FSM 707 (state 804), a server's FSM 707 (state xxx), and a called node's FSM 707 (yyy). In accordance with the illustrative embodiment, state 901 enforces a constraint on these three nodes' FSMs that these FSMs must concurrently be in the indicated respected states, within a specified concurrency time limit (two seconds in this case). In other words, once one of these nodes' FSM 707 reaches its indicated state, then the other two nodes' respective FSMs 707 must also reach their indicated states within two seconds. If this currency constraint is not satisfied, then an alert indicating a potential intrusion is generated, as described in detail below and with respect to
Similarly, state 902 represents a composite of the states of the calling node's FSM (state 805), the server's FSM (state zzz), and the called node's FSM (state www), and indicates a concurrency constraint of three seconds on these states.
The arc from the start state to state 901 represents a state transition that occurs automatically upon initial execution of global finite-state machine (FSM) 606-i, as is typical in the art.
The arc from state 901 to state 902 represents a state transition that occurs when a first SIP_INVITE message is sent from the calling node to the server, a second SIP_INVITE message is sent from the server to the called node, and a SIP_INVITE_ACK message is sent back from the called node to the server.
As will be appreciated by those skilled in the art, the particular composite states, state transitions, and concurrency constraints of
At task 1010, intrusion-detection system (IDS) 320 checks whether a new session i has been initiated. If so, execution proceeds to task 1020, otherwise execution continues back at task 1010 again.
At task 1020, intrusion-detection system (IDS) 320 spawns a first thread for detecting illegal “local” protocol states or transitions in session i, as described in detail below and with respect to
At task 1030, intrusion-detection system (IDS) 320 spawns a second thread for detecting illegal “global” protocol states or transitions in session i, as described in detail below and with respect to
At task 1040, intrusion-detection system (IDS) 320 spawns a third thread for processing alerts that are generated by the first and second threads. As will be appreciated by those skilled in the art, the particular measures taken at task 1040 will depend on the programmed policies of the particular implementation, and might include simple logging of the alert, blocking subsequent messages accordingly from reaching their destinations, “locking down” one or more nodes participating in session i, etc. As will be appreciated by those skilled in the art, in the case of blocking subsequent messages, in some embodiments of the present invention intrusion-detection system (IDS) 320 might actively participate in the blocking of messages, while in some other embodiments intrusion-detection system (IDS) 320 might instruct some other entity (e.g., a firewall, a security appliance, etc.) to block messages. In any case, it will be clear to those skilled in the art, after reading this disclosure, how to program intrusion-detection system (IDS) 320 to carry out such blocking, and/or any other measures, at task 1040.
At task 1050, intrusion-detection system (IDS) 320 spawns a fourth thread for detecting when session i has terminated, and in response, terminating the first three threads, and finally itself. It will be clear to those skilled in the art, after reading this disclosure, how to program intrusion-detection system (IDS) 320 to perform task 1050.
After task 1050 is completed, execution of the method of
At task 1110, the thread initializes FSMs 707-i-x-y, for all nodes x and protocols y in session i, to their start states, in well-known fashion.
At task 1120, the thread checks if a message M sent to or from a node 310-j in session i has been observed. If so, then execution branches to task 1160, otherwise execution branches to task 1130.
At task 1130, the thread checks whether the current state of a protocol k at a node 310-j in session i has changed. If so, then execution branches to task 1140, otherwise execution branches back to task 1120.
At task 1140, the thread checks whether the state change at node 310-j is incompatible with finite-state machine (FSM) 707-i-j-k (e.g., a transition from state 801 of
At task 1150, the thread updates the current state of finite-state machine (FSM) 707-i-j-k accordingly via token 800. After task 1150, execution continues back at task 1120.
At task 1160, the thread determines the protocol k of message M, in well-known fashion. After task 1160, execution continues at task 1170.
At task 1170, the thread checks whether message M is incompatible with finite-state machine (FSM) 707-i-j-k. If so, execution branches to task 1190, otherwise execution branches to task 1175.
At task 1175, the thread checks whether message M is incompatible with some other finite-state machine (FSM) 707-i-x-k for another node 310-x in session i (x≠j). If so, execution branches to task 1190, otherwise execution branches to task 1180.
At task 1180, the thread updates the current states of finite-state machines (FSMs) 707-i-y-k for each node 310-y in session i. After task 1180, execution continues back at task 1120.
At task 1190, the thread generates an alert that indicates a potential intrusion. In some embodiments of the present invention the alert might specify a particular node 310 as the likely target (or “victim”) of the potential intrusion (e.g., the node associated with the FSM 707 incompatibility, etc.), while in some other embodiments the alert might not specify any particular node. After task 1190, execution continues at task 1120.
At task 1210, the thread initializes global finite-state machine (FSM) 606-i to its start state.
At task 1215, the thread sets δ:=∞.
At task 1220, the thread checks whether a message M belonging to session i has been observed. If so, then execution proceeds to task 1230, otherwise execution continues back at task 1220.
At task 1230, the thread checks whether message M is incompatible with global finite-state machine (FSM) 606-i. If so, then execution continues at task 1290, otherwise execution proceeds to task 1240.
At task 1240, the thread checks whether message M matches the label of a state transition of global finite-state machine (FSM) 606-i from its current state to a new state S. If so, then execution proceeds to task 1250, otherwise execution continues back at task 1220.
At task 1250, the thread branches based on whether δ is finite. If it is, then execution continues at task 1270, otherwise execution proceeds to task 1260.
At task 1260, the thread sets the value of δ to the time limit specified by state S, and starts a real-time countdown of δ to zero.
At task 1270, the thread branches based on whether δ equals zero. If so, then execution proceeds to task 1280, otherwise execution continues back at task 1220.
At task 1280, the thread checks whether global finite-state machine (FSM) 606-i has reached state S. If not, then execution proceeds to task 1290, otherwise execution continues back at task 1215.
At task 1290, the thread generates an alert that indicates a potential intrusion, as described above at task 1190. After task 1290, execution continues back at task 1215.
As will be appreciated by those skilled in the art, although the illustrative embodiment has been disclosed in the context of Voice over Internet Protocol (VoIP) systems, it will be clear to those skilled in the art, after reading this disclosure, how to make and use embodiments of the present invention for other types of systems and for other types of protocols having finite-state machine (FSM) representations.
It is to be understood that the disclosure teaches just one example of the illustrative embodiment and that many variations of the invention can easily be devised by those skilled in the art after reading this disclosure and that the scope of the present invention is to be determined by the following claims.
