Signature-free intrusion detection

Abstract

An apparatus and method are disclosed for detecting intrusions in Voice over Internet Protocol systems, without the use of an attack signature database. In particular, the illustrative embodiment is based on the observation that some 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. A finite-state machine is maintained for each session/node/protocol combination, and any illegal state or state transition—which might be the result of a malicious attack—is flagged as a potential intrusion.

Claims

1. A method comprising: receiving, by an intrusion detection system, a first signal that indicates that a first communications protocol at a first node is in a state p, wherein the first communications protocol includes one or more states; maintaining, by the intrusion detection system, a first finite-state machine that is associated with the first node, wherein the first finite-state machine includes one or more states, each state of the first finite-state machine corresponding to a respective allowed state of the first communications protocol, wherein the intrusion detection system updates a current state f of the first finite-state machine in response to messages received by and transmitted by the first node, and wherein the current state f of the first finite-state machine corresponds to one of the respective allowed states of the first communications protocol; and generating, by the intrusion detection system, a second signal that generates an intrusion alert when the current state f of the first finite-state machine is incompatible with the state p.

2. The method of claim 1, wherein the second signal is generated without any attempt to match an attack signature.

3. The method of claim 1, further comprising blocking, by the intrusion detection system, a subsequent message from reaching its destination in response to the generation of the second signal.

4. The method of claim 1, wherein the intrusion detection system comprises the first node.

5. The method of claim 1, further comprising: maintaining, by the intrusion detection system, a second finite-state machine that is associated with a second node, wherein the second finite-state machine includes one or more states, each state of the second finite-state machine corresponding to a respective allowed state of the second communications protocol, wherein the intrusion detection system updates a current state of the second finite-state machine in response to messages received by and transmitted by the second node, and wherein the current state of the second finite-state machine corresponds to one of the respective allowed states of the second communications protocol; and generating, by the intrusion detection system, a third signal that indicates a possible intrusion at the second node when the current state of the second finite-state machine is incompatible with a state of the second communications protocol.

6. The method of claim 5, wherein the third signal is generated without any attempt to match an attack signature.

7. The method of claim 5, further comprising blocking, by the intrusion detection system, a subsequent message from reaching its destination in response to the generation of the third signal.

8. The method of claim 5, wherein a change in the state of the second communications protocol is engendered by one of a message transmitted by the second node or a message directed to the second node.

9. A method comprising: receiving, by an intrusion detection system, a first signal that indicates that a communications protocol at a node has transitioned from a state p.sub.1 to a state p.sub.2; maintaining, by the intrusion detection system, a finite-state machine that is associated with the node and that represents the communications protocol, each state of the finite-state machine corresponding to a respective allowed state of the communications protocol, wherein the intrusion detection system updates a current state f of the finite-state machine as necessary in response to messages received by and transmitted by the node, and wherein the current state f of the finite-state machine corresponds to one of the respective allowed states of the communications protocol; and when the state p.sub.2 is incompatible with the current state f generating, by the intrusion detection system, a second signal that generates an intrusion alert at the node.

10. The method of claim 9, wherein the second signal is generated without any attempt to match an attack signature.

11. The method of claim 9, further comprising blocking, by the intrusion detection system, a subsequent message from reaching its destination in response to the generation of the second signal.

12. The method of claim 9, wherein the intrusion detection system comprises the node.

13. The method of claim 9, wherein the transition from the state p.sub.1 to the state p.sub.2 is engendered by a message transmitted by the node.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 depicts a schematic diagram of a telecommunications system in accordance with the prior art.

(2) FIG. 2 depicts a schematic diagram of the salient elements of internal network 101, as shown in FIG. 1, in accordance with the prior art.

(3) FIG. 3 depicts a telecommunications system in accordance with the illustrative embodiment of the present invention.

(4) FIG. 4 depicts a schematic diagram of the salient elements of intrusion-detection system (IDS) 320, as shown in FIG. 3, in accordance with the illustrative embodiment of the present invention.

(5) FIG. 5 depicts a schematic diagram of the salient contents of memory 403, as shown in FIG. 4, in accordance with the illustrative embodiment of the present invention.

(6) FIG. 6 depicts a schematic diagram of the salient contents of data block 502-i, as shown in FIG. 5, in accordance with the illustrative embodiment of the present invention.

(7) FIG. 7 depicts a schematic diagram of the salient contents of data sub-block 605-i-j, as shown in FIG. 6, in accordance with the illustrative embodiment of the present invention.

(8) FIG. 8 depicts illustrative finite-state machine 707-i-j-k, as shown in FIG. 7, in accordance with the illustrative embodiment of the present invention.

(9) FIG. 9 depicts a portion of illustrative global finite-state machine 606-i, as shown in FIG. 6, in accordance with the illustrative embodiment of the present invention.

(10) FIG. 10 depicts a flowchart of the salient tasks of intrusion-detection system (IDS) 320 in accordance with the illustrative embodiment of the present invention.

(11) FIG. 11 depicts a flowchart of the salient tasks of the first thread, which is spawned at task 1020 of FIG. 10, in accordance with the illustrative embodiment of the present invention.

(12) FIG. 12 depicts a flowchart of the salient tasks of the second thread, which is spawned at task 1030 of FIG. 10, in accordance with the illustrative embodiment of the present invention.

DETAILED DESCRIPTION

(13) For the purposes of this specification, the following terms and their inflected forms are defined as follows: The term “node” is defined as an endpoint in a network (e.g., a telecommunications terminal, a gateway, a router, a server, a firewall, an intrusion-detection system, etc.). The term “VoIP node” is defined as a node that is capable of receiving, transmitting, and/or processing Voice-over-Internet Protocol (VoIP) messages.

(14) FIG. 3 depicts telecommunications system 300 in accordance with the illustrative embodiment of the present invention. As shown in FIG. 3, telecommunications system 300 comprises network 305, four Voice-over-IP (VoIP) nodes 310-1 through 310-4, and intrusion-detection system (IDS) 320, interconnected as shown.

(15) 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 FIG. 3 in a conceptual and abstract manner: in some embodiments network 305 might be a wireless network, while in some other embodiments network 305 might be a wired network, while in yet some other embodiments network 305 might comprise both wired and wireless technologies, or might in fact comprise a plurality of constituent networks (for example, a combination of the Public Switched Telephone Network [PSTN], the Internet, and a wireless local-area network). As will be further appreciated by those skilled in the art, the fact that telecommunications system 300 comprises four VoIP nodes is merely illustrative, and in some other embodiments there might be a fewer number or greater number of VoIP nodes 310.

(16) 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.

(17) 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.

(18) 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 FIGS. 10 through 12. A schematic diagram of the salient elements of intrusion-detection system (IDS) 320 is described below and with respect to FIG. 4, and a pictorial representation of the salient data stored at intrusion-detection system (IDS) 320 is described below and with respect to FIGS. 5 through 9.

(19) 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.

(20) FIG. 4 depicts a schematic diagram of the salient elements of intrusion-detection system (IDS) 320 in accordance with the illustrative embodiment of the present invention. As shown in FIG. 4, intrusion-detection system (IDS) 320 comprises receiver 401, processor 402, memory 403, and transmitter 404, interconnected as shown.

(21) 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.

(22) 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 FIG. 7), of reading data from and writing data into memory 403, and of transmitting information to transmitter 404. In some alternative embodiments of the present invention, processor 402 might be a special-purpose processor. In either case, it will be clear to those skilled in the art, after reading this disclosure, how to make and use processor 402.

(23) 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.

(24) 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.

(25) FIG. 5 depicts a schematic diagram of the salient contents of memory 403 in accordance with the illustrative embodiment of the present invention. As shown in FIG. 5, memory 403 comprises a first portion with instructions to be executed by processor 402, and a second data portion. The first portion comprises program 501, which executes the tasks described below and with respect to FIGS. 10 through 12. The second portion comprises three data blocks 502-1 through 502-3 corresponding to three corresponding sessions; the contents of these data blocks is described below and with respect to FIGS. 6 through 9. As will be appreciated by those skilled in the art, the fact that three data blocks 502 are depicted in FIG. 5 is merely illustrative, and there might be a fewer number or greater number of data blocks 502 corresponding to respective sessions.

(26) FIG. 6 depicts a schematic diagram of the salient contents of data block 502-i in accordance with the illustrative embodiment of the present invention. As shown in FIG. 6, data block 502-i comprises data sub-blocks 605-i-1 through 602-i-4, each of which is associated with a respective node 310-i that participates in session i, and global finite-state machine (FSM) 606-i for session i, which is described in detail below and with respect to FIG. 9. As in the case of data blocks 502, it will be appreciated by those skilled in the art that the depiction of four data sub-blocks 605 is merely illustrative, and there might be a fewer number or greater number of data sub-blocks 605 corresponding to respective nodes in session i.

(27) FIG. 7 depicts a schematic diagram of the salient contents of data sub-block 605-i-j in accordance with the illustrative embodiment of the present invention. As shown in FIG. 6, data sub-block 605-i-j comprises finite-state machines (FSMs) 770-i-j-1 through 770-i-j-3, each of which is associated with the state of a respective protocol (e.g., Session Initiation Protocol [SIP], Real-time Transport Protocol [RTP], etc.) at VoIP node 310-j during session i. Each finite-state machine 770-i-j-k represents the possible (or “legal”) states and state transitions for its corresponding protocol, and keeps tracks of the current state of that protocol at VoIP node 310-j during session i. Finite-state machine 770-i-j-k is described in detail below and with respect to FIG. 8.

(28) 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.

(29) FIG. 8 depicts an illustrative finite-state machine (FSM) 707-i-j-k in accordance with the illustrative embodiment of the present invention. In particular, finite-state machine 707-i-j-k corresponds to the legal states and state transitions of the Session Initiation Protocol (SIP) at a calling VoIP-capable terminal 310-j during a session i.

(30) As shown in FIG. 8, finite-state machine (FSM) 707-i-j-k comprises nine states 801 through 809, where 801 is the starting state for a SIP session at VoIP-capable terminal 310-i, and token 800, which keeps track of the current state of FSM 707-i-j-k (state 802 in FIG. 8). Each arc (or directed edge) in finite-state machine (FSM) 707-i-j-k indicates a legal transition from a first state to a second state, where the label on the arc indicates a type of message (e.g., SIP_INVITE, SIP_INVITE_ACK, etc.) received or transmitted by node 310-i that engenders the state change.

(31) As will be appreciated by those skilled in the art, although in the illustrative finite-state machine (FSM) 707-i-j-k of FIG. 8 every arc label corresponds to a message received or transmitted by VoIP node 310-j, in some other embodiments of the present invention finite-state machine (FSM) 707-i-j-k might have one or more arc labels that correspond to a message that does not involve VoIP node 310-j at all. Moreover, in some other embodiments of the present invention, finite-state machine (FSM) 707-i-j-k might have one or more arc labels that correspond to a signal other than a protocol-related message (e.g., a remote procedure call, some other kind of message, etc.). In any case, it will be clear to those skilled in the art, after reading this disclosure, how to formulate and use finite-state machines with these various kinds of arc labels.

(32) FIG. 9 depicts a portion of illustrative global finite-state machine (FSM) 606-i in accordance with the illustrative embodiment of the present invention. The portion of global finite-state machine (FSM) 606-i depicted in FIG. 9 comprises a start state, state 901, state 902, an arc from the start state to state 901, and an arc from state 901 to state 902.

(33) 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 FIG. 12.

(34) 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.

(35) 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.

(36) 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.

(37) As will be appreciated by those skilled in the art, the particular composite states, state transitions, and concurrency constraints of FIG. 9 are merely illustrative in nature. As will further be appreciated by those skilled in the art, in some other embodiments of the present invention, global finite-state machine (FSM) 606-i might employ other kinds of constraints in addition to, or in lieu of, the concurrency constraints of the finite-state machine depicted in FIG. 9. For example, a “non-concurrency” constraint might cause an alert to be generated if the specified states of FSMs 707 are in fact reached concurrently (plus or minus the specified time limit). As another example, a constraint might require that at least two of the three specified FSM 707 states be reached concurrently, or might be unrelated to the timing of the FSM 707 states (e.g., enforcing a condition on the number of times that a FSM 707 state is visited, etc.). It will be clear to those skilled in the art, after reading this disclosure, how to make and use embodiments of the present invention that employ such alternative constraints in global finite-state machine (FSM) 606-i.

(38) FIG. 10 depicts a flowchart of the salient tasks of intrusion-detection system (IDS) 320 in accordance with the illustrative embodiment of the present invention. It will be clear to those skilled in the art, after reading this disclosure, which tasks depicted in FIG. 8 can be performed simultaneously or in a different order than that depicted.

(39) 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.

(40) 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 FIG. 11.

(41) 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 FIG. 12.

(42) 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.

(43) 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.

(44) After task 1050 is completed, execution of the method of FIG. 10 continues back at task 1010 for subsequent iterations.

(45) FIG. 11 depicts a flowchart of the salient tasks of the first thread spawned at task 1020, in accordance with the illustrative embodiment of the present invention.

(46) 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.

(47) 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.

(48) 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.

(49) 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 FIG. 8 to state 805 without any intermediate states, etc.). If the state change is incompatible, then execution branches to task 1190, otherwise execution branches to task 1150.

(50) 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.

(51) At task 1160, the thread determines the protocol k of message M, in well-known fashion. After task 1160, execution continues at task 1170.

(52) 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.

(53) 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.

(54) 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.

(55) 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.

(56) FIG. 12 depicts a flowchart of the salient tasks of the second thread spawned at task 1030, in accordance with the illustrative embodiment of the present invention.

(57) At task 1210, the thread initializes global finite-state machine (FSM) 606-i to its start state.

(58) At task 1215, the thread sets δ:=∞.

(59) 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.

(60) 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.

(61) 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.

(62) 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.

(63) 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.

(64) 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.

(65) 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.

(66) 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.

(67) 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.

(68) 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.