Network Working Group Z. Czirkos Internet-Draft G. Hosszu Expires: March 4, 2008 BME EET Sept 2007 The Komondor Peer to Peer Security System draft-czirkos-komondor-p2p-security-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Czirkos & Hosszu Expires March 4, 2008 [Page 1] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 Abstract This memo presents Komondor, an experimental peer-to-peer security system. Komondor is a network intrusion detection system. Hosts running this software organize themselves automatically in an overlay network, where they share information about intrusion attempts they detect. This way the security of all participants is increased, as they are able to prepare for some of the attacks in advance. The overlay created is a peer-to-peer network, which is completely decentralized. This communication model ensures stability, and by using this the system remains operational over an unstable network. Czirkos & Hosszu Expires March 4, 2008 [Page 2] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Structure of the Overlay . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. The Structure . . . . . . . . . . . . . . . . . . . . . . 5 2.3. The Lookup Procedure . . . . . . . . . . . . . . . . . . . 6 3. Intrusion Detection . . . . . . . . . . . . . . . . . . . . . 7 3.1. Description of an Intrusion Attempt . . . . . . . . . . . 7 3.2. Analysis of Reports . . . . . . . . . . . . . . . . . . . 8 3.3. Report Example . . . . . . . . . . . . . . . . . . . . . . 8 4. Centralized Logging . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 11 5.1. Transport Protocol . . . . . . . . . . . . . . . . . . . . 11 5.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Reliable Communication . . . . . . . . . . . . . . . . . . 12 5.4. Hashing Algorithm . . . . . . . . . . . . . . . . . . . . 12 5.5. Message Details . . . . . . . . . . . . . . . . . . . . . 14 5.5.1. Acknowledgement Message . . . . . . . . . . . . . . . 14 5.5.2. Ping Message . . . . . . . . . . . . . . . . . . . . . 14 5.5.3. Quit Message . . . . . . . . . . . . . . . . . . . . . 15 5.5.4. Findnode Message . . . . . . . . . . . . . . . . . . . 15 5.5.5. Peer Message . . . . . . . . . . . . . . . . . . . . . 15 5.5.6. Attack Message . . . . . . . . . . . . . . . . . . . . 16 5.5.7. Protection Message . . . . . . . . . . . . . . . . . . 17 5.5.8. Announce Message . . . . . . . . . . . . . . . . . . . 17 5.5.9. Statistics Message . . . . . . . . . . . . . . . . . . 18 6. Configuration Parameters of the Komondor System . . . . . . . 20 6.1. Replication Factor . . . . . . . . . . . . . . . . . . . . 20 6.2. Intrusion Detection and Protection . . . . . . . . . . . . 20 6.3. Timing of Intrusion Detection . . . . . . . . . . . . . . 20 6.4. Protection Methods . . . . . . . . . . . . . . . . . . . . 21 6.5. Overview of Configuration Parameters . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Implementation Details . . . . . . . . . . . . . . . . . . . . 23 8.1. Communication over UDP . . . . . . . . . . . . . . . . . . 23 8.2. Kademlia Binary Tree . . . . . . . . . . . . . . . . . . . 23 8.3. Usage of the Overlay . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Czirkos & Hosszu Expires March 4, 2008 [Page 3] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 1. Introduction This memo describes Komondor, a peer-to-peer based collaborative security system [2]. Komondor is a host security software, which is able to detect network-sized intrusion attempts. Hosts running this software share information about detected intrusion attempts, for example by exchanging suspicious IP addresses. This way the security of all entities is increased, as they are able to prepare for the attacks in advance. The heterogenity of hosts in such a network also increases security, as different operating system and software versions are vulnerable to different kinds of attacks. Komondor entities organize themselves into a peer-to-peer network, where every entity is responsible for collecting and analyzing data. This network model has no central server, and therefore it can remain operational on the unstable network. A centralized model would be completely unfeasible for such an application, as an intruder attacking the central server would shut down the intrusion detection network completely. The Komondor system implements a Distributed Hash Table (DHT). In the overlay network, every Komondor entity (node) is assigned a unique identifier, a nodeID, which is a 32-bit number. The source IP address of every attacker identified is hashed with a hash function similar to SHA-1, which also results in a 32-bit number. Every node stores reports, which have a hash value close to its identifier. This way reports of the same attacker are collected by a single node, so it is able to analyze them to detect network-size attacks. If an IP address becomes suspicious, the entity collecting and analyzing its data issues a broadcast message in the overlay, alerting every other nodes. This way they can prepare their protection systems in advance, expecting the same attacker. Czirkos & Hosszu Expires March 4, 2008 [Page 4] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 2. The Structure of the Overlay 2.1. Overview The Komondor intrusion detection system is built over an overlay network, which is similar to Kademlia [1]. Kademlia is a distributed hash table (DHT), which is using the XOR metric. In the DHT, every node has a unique identifier, which is a 32-bit number for Komondor. Information to be stored must be in a key/value format. Here the key is the IP address of the attacker, and the value is a report of an intrusion attempt detected. When storing information in the overlay, a node uses a hash function to generate a 32-bit number from the key. (Note that this number is the same size as the node identifiers.) The report is then sent to the node which has its identifier closest to the hashed value. The distance is calculated using the XOR function. There is no routing defined in the overlay network. It is merely used to let nodes discover each other, e.g. to find out the IP address and port number of the participators. Once the destination of the message is known, the reports of intrusion attempts detected can be sent directly to it. 2.2. The Structure This section describes the structure of the Komondor overlay network, which is very similar to Kademlia. When joining the overlay, every node chooses a random 32-bit nodeID, which will essentially be its address in the application level network. The purpose of the overlay is to help nodes find out the Internet address of each other in logarithmically many steps. Nodes in Kademlia are leaves of a binary tree. Each node's position is determined by the shortest unique prefix in its nodeID. For any given node, the tree is divided into successively smaller subtrees, which do not contain the node. For node 0011, these subtrees are prefixed by the numbers 1, 01, 000 and 0010. These prefixes can be acquired by leaving the first n bits of the address untouched, then inverting the following bit. The tallest common subtree for node 0011 is 0xxx, therefore the neighbouring subtree is 1xxx. The second smallest is 00xx, therefore the neighbouring subtree is 01xx, and so on. Nodes in the overlay are required to know at least one node in each subtree they belong to. If this is achieved, every node can be Czirkos & Hosszu Expires March 4, 2008 [Page 5] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 located by knowing its nodeID. Distance between two nodes (or a hashed value and an identifier) is calculated using the XOR function. Note that this effectively describes the binary tree representation of the system presented above, as a larger number will indicate a shortest common prefix of nodeID's. Every node should maintain a list of other nodes in the overlay it is aware of. For the system to be scalable, these list is handled using the binary tree. Every subtree is assigned a fixed length list of nodes. The members of such a list are IP address, port number, nodeID triplets. Kademlia calls these lists k-buckets, and refers to their maximum size as k [1]. Nodes of a Komondor system can quit unexpectedly, because of having network errors or being under heavy attack. Therefore the system- wide configuration parameter k must be chosen big enough to ensure that not too many nodes leave the network, before all k-buckets of another one become empty (i.e. they contain only dead connection information). For the highest subtrees, which contain the closest nodes for a given node, these lists will be usually empty, as no appropriate nodes exist. K-buckets are to be propagated by two means. First, peer messages can contain addresses of other nodes in the overlay. Second, when a node receives a message, the source address and port can also be remembered. 2.3. The Lookup Procedure To find the IP address and port number of a participator with a specific nodeID, a node should initiate a recursive lookup procedure. Every node manages its own lookup procedures. Such a procedure consists of successive find node messages. It is started with sending a find node message to the closest node to the destination. The distances between the desired nodeID and the known IDs are calculated using the XOR function. As every node has greater knowledge of its surroundings, the reply will contain peer messages with addresses of nodes even closer. Then the initiator can issue another find node message. A lookup is complete, when the k closest nodes to the destination address have been queried. As the Internet address of the destination is known at this point, more reports about the same attacker can easily be sent at once. Czirkos & Hosszu Expires March 4, 2008 [Page 6] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 3. Intrusion Detection This section describes the intrusion detection used by a Komondor overlay. The detection scenario can be summarized as follows. When a member of the overlay detects a suspicious event, it notes the IP address of the intruder. This IP address is hashed using the hash function used by all nodes. The result is a 32-bit number, which is treated as a nodeID, and looked up in the overlay. The report about the detected event is the sent to the specific node by an attack message. The same hash function is used by all nodes, so report about the same attacker will be collected by a single node, no matter which nodes the events were detected by. The collector node is then able to summarize and analyze the reports. If the reports indicate an intrusion attempt, the collector initiates a broadcast message among nodes, which is called a protection message. This message contains the IP address of the attacker, against which nodes should take their own protective steps. Nodes are free to use their own means of intrusion detection and protection. One example for this is to monitor system log files for detection, and to configure a firewall for protection. Mandatory tasks for nodes is to report suspicious events, and to forward broadcast messages, as described by the Komondor protocol. 3.1. Description of an Intrusion Attempt Suspicious events detected do not necessarily indicate a real intrusion attempt. The common example for this is a mistyped password during an authentication. Every event which is reported should be therefore assigned a number, which denotes its importance. The parameters in a report are therefore: IP address: The IP address of the attacker. Importance: The weight of the event, which is a number between 0 and 100. Event type: The name of the event. For statistical purposes. Detector: The host name of the node which detected the event. For statistical purposes. Czirkos & Hosszu Expires March 4, 2008 [Page 7] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 3.2. Analysis of Reports Every node is responsible for collecting and analyzing reports received. Each report is to be remembered for one hour. Records older than one hour are to be deleted. An index should be calculated for every IP address which is suspected to be an attacker. This index is a summation of importance values seen in the reports, which are decreased with time. The importance of one report is: importance = reported importance * (3600s - report age), where the age of the report is the time that has elapsed since the report was received by the collector. Reports are expected to be received in a few seconds, so the current protocol does not require nodes to timestamp their reports. These decreased importance values are then summed up. The index should be recalculated every minute, or when a new report is received for an IP address. If the sum of these increases above 100, the collector node must initiate a broadcast message, signalling other nodes to prepare their protection against the attacker. The protection message contains the IP address of the attacker. Each protection message is valid for twenty minutes. After that period, if the index for an attacker is still above 100, the collector node should initiate another broadcast. As the importance values of each reports are summed up, nodes are free to summarize more events in a short time, of the same type and same attacker, in a single report. This reduces the network traffic induced. The short time interval should not exceed ten seconds, however, as that would possibly degrade detection efficiency. Nodes are also allowed to analyze their own reports, and initiate a protection broadcast message, if required. In either case, the reports must always be sent to the collector. 3.3. Report Example The importance indices for events can be freely chosen, when implementing and configuring a Komondor node. The specific value can be estimated by keeping the the 100-point limit in mind. For example, a failure of a user name and password type authentication can be assigned the importance of 40 points. This will allow users to mistype their password twice, and only the third failure will initiate the protection. The event type for this can be ssh_password_failed, for example. Czirkos & Hosszu Expires March 4, 2008 [Page 8] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 Events which indicate an attack on their own can be assigned an importance of more than 100 points. For example, an Internet worm attack can have the type slammer_worm, and importance 120. Czirkos & Hosszu Expires March 4, 2008 [Page 9] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 4. Centralized Logging The Komondor system supports logging statistical data about detected intrusion attempts. Reports about the same attacker are always collected by a single node in the system. When the attack seems to be over, that is to say, the last report about the specific attacker times out, the collector node is allowed to send a summary about the attack types and detectors of the event. This procedure is not a vital part of the workings of the system. The logging works in a centralized way. The node collecting statistical data (apart from the fact that it is a completely functional Komondor node) is assigned the application level network address 0x00000001, instead of the normal randomly choosen address used by other nodes. There can be only one logging node in a Komondor overlay. Nodes in the system use the normal lookup procedure with address 0x00000001 to find out the IP address of the logging node. The statistical report of the intrusion attempt contains the following data: IP address: The IP address of the attacker. Interval: The time interval of the intrusion attempt, from the first to the last event detected. Event types: The list of all event types detected. Detectors: The host names of all nodes which detected the specific attacker. Protection: If the protection was successful for some node. Most of this information is valuable only to the network administrator who configured the Komondor nodes on his network, as the name of event types, and host names are assigned by him. The last parameter named "protection" will show if the protection against the attacker was successful for some node. The availability of this information depends on the means of th protection. For example, a firewall can be configured to log dropped packets, and that way the node will know if it is still under attack. This enables network administrators to determine the efficiency of the system. Czirkos & Hosszu Expires March 4, 2008 [Page 10] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 5. Protocol Specification The protocol described here is used between two Komondor entities. 5.1. Transport Protocol Komondor nodes must use UDP for communication. Currently, nodes are free to choose any port number. However, they must use the same port number for incoming and outgoing messages. This allows the k-buckets to be propagated by checking the remote address and port number of messages. For example, if a node receives a message with remote address 192.0.2.92:1705, it can send its reply to this address as destination. 5.2. Message Format The protocol is based on set of codes which are composed of eight bits (an octet), and uses the ASCII character set. Messages are essentially text lines, which consist of a node identifier, a message identifier, a command and optional parameters. Each message is prefixed by the nodeID of the sender. This identifier is expressed as a minimum of one, a maximum of eight hexadecimal digits, representing the 32-bit identifier. This is used to assign nodeID's to socket addresses, and to detect if a node is restarted. The second prefix of the message is also a 32-bit hexadecimal number in ASCII code. This is a random number which should be unique for each different message sent. As UDP does not guarantee message delivery, this number is used to implement a reliable communication channel. Each message is encapsulated in its own UDP packet (datagram), so there is no delimiter used between them. The BNF representation for the message is: message ::= [parameters] nodeID ::= { } messageID ::= { } Czirkos & Hosszu Expires March 4, 2008 [Page 11] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 command ::= { } SPACE ::= ' ' parameters ::= { } 5.3. Reliable Communication As UDP does not guarantee reliable message delivery, each message contains a messageID mentioned above. This message identifier is a 32-bit random number. When a node receives a message, it must reply with an acknowledge, unless the messageID is zero. The parameter of the acknowledgement is the messageID of the message which it acknowledges. The own messageID of the acknowledgement must be zero to prevent infinite loops. Unacknowledged messages should be resent to their destination. If there is no reply from the node, the connection is to be considered dead. Packet loss of acknowledgement messages can result in message duplicates. For this reason, every node should maintain a list of recently seen messages, to prevent processing it more than once. This list of seen messages should contain the messageID's received in the last minute. 5.4. Hashing Algorithm Komondor uses a modified version of SHA-1 algorithm, which processes ASCII strings with a maximum length of 64 bytes. The IP addresses of attackers are hashed as strings with the algorithm presented below. This is a C language implementation of the SHA-1 algorithm used by Komondor. It can be used for little-endian machines. uint32 is assumed to be a 32-bit unsigned integer type. #define S(x,n) (((x) << (n)) | (((x) & 0xFFFFFFFF) >> (32 - (n)))) IDENTIFIER p2p_hash_string (const char *string) { /* rotating left an uint32 */ uint32 w[80]; uint32 h0, h1, h2, h3, h4; uint32 a, b, c, d, e; int i; h0 = 0x67452301; Czirkos & Hosszu Expires March 4, 2008 [Page 12] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 h1 = 0xEFCDAB89; h2 = 0x98BADCFE; h3 = 0x10325476; h4 = 0xC3D2E1F0; /* copy 64bytes max to w, rest filled with 0 */ memset (w, sizeof(w), 0); strncpy ((char *)w, string, 64); /* Extend the sixteen 32-bit words (64 bytes) into eighty 32-bit words */ for (i=16; i<80; i++) w[i] = S(w[i-3] ^ w[i-8] ^ w[i-14] ^ w[i-16],1); /* Initialize hash value */ a = h0; b = h1; c = h2; d = h3; e = h4; /* Main loop */ for (i=0; i<80; i++) { uint32 temp, f, k; if (i <= 19) { f = (b & c) | ((~b) & d); k = 0x5A827999; } else if (i >= 20 && i<= 39) { f = b ^ c ^ d; k = 0x6ED9EBA1; } else if (i >= 40 && i<= 59) { f = (b & c) | (b & d) | (c & d); k = 0x8F1BBCDC; } else { /* i >= 60 */ f = b ^ c ^ d; k = 0xCA62C1D6; } temp = S(a,5) + f + e + k + w[i]; e = d; d = c; c = S(b,30); b = a; a = temp; } Czirkos & Hosszu Expires March 4, 2008 [Page 13] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 /* Add this chunk's hash to result so far */ h0 = h0 + a; h1 = h1 + b; h2 = h2 + c; h3 = h3 + d; h4 = h4 + e; /* Komondor uses 32bit identifiers, so we xor the five 32-bit */ return h0 ^ h1 ^ h2 ^ h3 ^ h4; } 5.5. Message Details This section lists all messages which must be or should be implemented by Komondor entities. Every subsection describes a message and its parameters. The parameters are usually encoded as ASCII strings, and they are fixed in order. 5.5.1. Acknowledgement Message Command: ack Parameters: This message should be the first immediate answer to any message received. The purpose of this is to implement reliable communication over UDP. The parameter should contain the messageID of the message received, which is acknowledged by this line. One exception for sending acknowledgements is when the messageID received is zero (0). Also, the messageID of the acknowledgement message should be zero to prevent infinite loops. Example: 78ae56cd 0 ack 12983efa Node 78ae56cd acknowledges message 12983efa. 5.5.2. Ping Message Command: ping Parameters: none This message tests if a connection is alive. The reply is the acknowledgement message described in the section above. Note that Czirkos & Hosszu Expires March 4, 2008 [Page 14] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 every message with a messageID other than zero generater an acknowledgement, not only the ping command. 5.5.3. Quit Message Command: quit Parameters: none This message informs its destination node, that the source node is intending to leave the overlay. The receiver should delete the connection from its k-buckets. 5.5.4. Findnode Message Command: findnode Parameters: identifier This message requests the destination to send the list of other nodes which it is aware of. The destination should reply with a peer message, containing connection information to other nodes. Those nodes must be closest ones to the identifier in XOR space, which the destination is aware of. The list is essentially a k-bucket, or information about nodes from several k-buckets, if the bucket in question did not contain at least k nodes [1]. Example: 78ae56cd 39fa9912 findnode 98be1f7d Node 78ae56cd queries one of its neighbors about other nodes, which have identifiers close to 98be1f7d. The neighbor will answer this request with a peer message, containing k-bucket. 5.5.5. Peer Message Command: peer Parameters: { ipaddress:port } This message contains the Internet address of one or more nodes. It is a reply to a findnode message. The IP address is to be expressed in dot notation as decimal numbers (for example 192.0.2.4). The port number must also be a decimal number. Example: 78ae56cd 2795aef5 peer 192.0.2.4:1232 192.0.2.9:1892 Node 78ae56cd informs the receiver of the message about other nodes, reachable at 192.0.2.4:1232 and 192.0.2.9:1892. Czirkos & Hosszu Expires March 4, 2008 [Page 15] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 5.5.6. Attack Message Command: attack Parameters: This message is a report of an intrusion attempt detected. The parameters have their meanings as follows: ip: first one, most important is the IP address of the attacker in dot notation, 192.0.2.107 for example. importance: the second parameter represents the importance of the event, and is a decimal number. hostname: The third is the name of the host which detected the attack (a string of any printable characters except space). rulename: This is the name of the attack type (also printable, non- whitespace characters). protected: This should be 1, if the protection is already active against this attacker, 0 otherwise. The third, fourth and fifth parameters serve statistical purposes only. The receiver of this message is a node selected by the DHT to collect information about the specific attacker. It should sum up the indexes of each event reported, and if the total is greater than 100, initiate a broadcast procedure to inform entities in the overlay about an undergoing attack. The last parameter allows the collector node to estimate the effectiveness of the system. Komondor entities are allowed to send information about more events in a single message. In this case, the importance indexes must be summed up. If there are different rule names, they must be separated by the comma (,) character. As the importance of each detection decreases with time, multiple events are only allowed to be sent in one message, if the interval between their detection is not longer than 10 seconds. Example: 78ae56cd 9efc56e1 attack 192.0.2.107 40 jutas ssh_invalid_password 0 Czirkos & Hosszu Expires March 4, 2008 [Page 16] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 Node 78ae56cd with host name jutas detected an intrusion attempt from 192.0.2.107. The event detected was an invalid password in an ssh session, and the severity of it is 40 points. Protection against the attacker at 192.0.2.107 was inactive at the time of the detection. Note that detection can be still possible with an active protection, for example by checking firewall log files. 5.5.7. Protection Message Command: protect Parameters: When a suspicious IP address reaches the 100 point limit, it is considered an attacker. The Komondor entity collecting the reports belonging to the IP address must initiate a broadcast message in the overlay, informing other entities about the possibility of further intrusion attempts. The broadcast is initiated by sending the protection message to all its known neighbours. Every node receiving a protection message must check if it has recently (in one minute) received a protection message regarding the same attacker. If not, it must forward the message to all its known neighbours. The node collecting reports and initiating the broadcast message must also check if the points of the attacker did not decrease below the limit of 100 points in ten minutes. If this is the case, the broadcast must be resent. Therefore the nodes of the overlay are periodically informed about possible attackers, in every ten minutes. Example: 78ae56cd 57ab9ef1 protect 192.0.2.107 Node 78ae56cd collected enough reports about events from 192.0.2.107, and it is now considered an attacker. 5.5.8. Announce Message Command: announce Parameters: { attacker,index } Implementing this message is optional, but recommended. The purpose of this is to enable the central logging entity to monitor the state of the overlay, and the information that is stored in the hash table. Each entity should send an announce message to the logging server periodically. The first parameter of the message is its nodeID as hexadecimal digits, and the second one is its name (a string of Czirkos & Hosszu Expires March 4, 2008 [Page 17] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 printable, non-whitespace characters). Example: 78ae56cd 1731eacb announce 78ae56cd buda 192.0.2.107,45 5.5.9. Statistics Message Command: stat Parameters: This message is sent from a data collector entity to the central logging server, when the reports of the attack become outdated. It is not mandatory, but recommended behaviour, as the statistics provide useful information about attackers and the usefulness of the entire overlay. Parameters of this message are: First detection: the time of the first detection in Unix time format (seconds since 1970-01-01 00:00:00 UTC), expressed as a decimal number. Last detection: the time of the last event detected, in Unix time format. Attacker: the IP address of the attacker, in dot notation (192.0.2.107). Detectors: a comma separated list of names of hosts which detected this attacker. Rules: a comma separated list of types of attacks, which were detected from this attacker. Importance: the maximum event importance index which was calculated. Success: a 0 or 1 value indicating if the protection was successful, that is, an event was detected when the protection was already active. For example, the node detected further activity from the attacker by examining the firewall log files. Example: 78ae56cd 1731eacb stat 1183394505 1183475323 192.0.2.107 nemere,buda sshd_invalid_password,sshd_unknown_user 290 1 Node 78ae56cd sends statistics about attacker at 192.0.2.107. The first event was detected at 1183394505, and the last one at 1183475323. Nodes with host name nemere and buda were the ones who detected this attacker, and the types of the events were invalid passwords and Czirkos & Hosszu Expires March 4, 2008 [Page 18] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 unknown user names sent to the ssh service. The maximum importance points of the attack at the full interval was 290. The protection was successful against the attacker for at least one of the detector hosts: it was already aware of this attacker when it detected some activity from it. Czirkos & Hosszu Expires March 4, 2008 [Page 19] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 6. Configuration Parameters of the Komondor System 6.1. Replication Factor The replication factor is defined in Section 2.2, and is referred to as k, the size of k-buckets in the Kademlia overlay. It has two important effects on the workings of the overlay. As the size of the k-buckets, it determines the number of nodes a specific node is aware of, in every subtree of the overlay. The number must be high enough to maintain the stability of the overlay, as nodes under attack can even disappear from the network. It also determines, who many nodes an attack message is to be sent to, that is to say, reports of intrusion attempts detected are replicated at different nodes of the overlay. Increasing replication increases network traffic, but makes the overlay and detection more reliable. A recommended value is between 3 and 5 for smaller networks. The original Kademlia paper chooses 20, which should be enough for an overlay with tens of thousands of nodes [1]. 6.2. Intrusion Detection and Protection Currently, Komondor implementations are encouraged to use their own ways of intrusion detection and protection. This is unlikely to change in the future, as it would limit the portability of the system, and collaboration of Komondor nodes running on different platforms. This is why the names of attack types in the attack messages serve informational and statistical purposes only (see Section 5.5.9 and Section 5.5.6.) The parameters having direct effect on the workings of an overlay are the event importance indexes in messages. As different platforms have different vulnerabilities, this is not operating system independent, either. Implementations are currently advised to set the importance indexes assigned to different events reasonably. A suspicious IP address collecting 100 points is considered an attacker by Komondor entities. Therefore, a failed login should be assigned 40 points for example, allowing for two mistyped passwords before the protection mechanisms would become active at the third failed attempt. 6.3. Timing of Intrusion Detection Reports of intrusion attempts detected are sent to Komondor entities chosen using their nodeID's. Received reports are collected, and the importance is calculated. Importance points should decrease linearly, according to the formula described in Section 3.2. The Czirkos & Hosszu Expires March 4, 2008 [Page 20] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 time the importance of each report decreases to zero is also a configuration parameter of the detection. Increasing this interval increases the sensitivity of intrusion detection, but also increases the possibility of false alarms. 6.4. Protection Methods Possible methods for protection are platform-dependent. The current protocol specification enables Komondor implementations to exchange information about IP addresses belonging to possible attackers. One possible way of protection against them is using the firewall of the host running the Komondor entity. However, implementations are free to use any other method. Suspicious IP addresses, which collect 100 points, are treated as attackers. If a Komondor entity collected enough intrusion attempt reports about an attacker, and the sum of the indexes reach the 100 point limit, the entity is required to broadcast a protection message using the overlay, as described in Section 5.5.7. This message should be resent every 10 minutes, until the collected points drop below the limit. 6.5. Overview of Configuration Parameters The following table gives an overview of configuration parameters used in a Komondor overlay. It also shows their recommended values. Replication factor (k) 3 Protection limit 100 Protection message resend 10 minutes Attack report lifetime 20 minutes Interval to remember 1 minute seen messageID's Interval between detected 10 seconds events which can be sent in one message The first four parameters directly affect the behavior of the overlay and the intrusion detection. The recommended practice is to have these parameters be adjustable through a configuration file. Czirkos & Hosszu Expires March 4, 2008 [Page 21] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 7. Security Considerations The current version of the Komondor protocol does not describe authentication among nodes. A misbehaving Komondor node does not cause a possibility of information leak for the hosts of the overlay. It may, however, present false attack reports. This might cause denial of service to the IP addresses which are reported as attackers. Another harm a misbehaving Komondor node can do is that is simply ignores attack reports it receives, thereby not alerting other nodes about possible dangers. This problem can be solved by using replication. Czirkos & Hosszu Expires March 4, 2008 [Page 22] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 8. Implementation Details This section contains useful information which can be used when implementing the Komondor system. 8.1. Communication over UDP The current implementation of the Komondor system identifies nodes by their IP address:port numbers and nodeID's. Nodes are required to use the same port number with their outgoing messages, as the port number they are receiving UDP packets at. That is to say, a node which is reachable at UDP address 192.0.2.99:2001, must send its messages with source address 192.0.2.99:2001. This can easily be implemented by using the same socket and file descriptor for sending and receiving packets, on any operating system using the BSD sockets interface. 8.2. Kademlia Binary Tree As described in Section 2.2, the Kademlia overlay organizes nodes to a binary tree. This is not a real topology, but rather a reasonable way for each node to store information about other nodes it is aware of. Every node is required to have detailed knowledge about its surroundings in the DHT address space. More specifically, every node maintains a list of other nodes for every successively smaller subtree of the overlay, which it does not reside in. The size of these lists, the k-buckets, is fixed, and it is referred to as k. As it is described in the original paper [1], the most reasonable way to implement this is using a binary tree of lists for storing connection data. The program starts off with one single list, and as it gains knowledge about other nodes, the single list is split into multiple lists, arranged in the binary tree. Kademlia advises the k-buckets to be sorted by the time the nodes were last seen. This is unnecessary for Komondor, when implementing an intrusion detection system over the DHT. 8.3. Usage of the Overlay The Komondor overlay is best used on a local area network, as it is unlikely for the same intruder to attack hosts at different locations, due to the big number of Internet addresses. Czirkos & Hosszu Expires March 4, 2008 [Page 23] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 9. References [1] Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer information system based on the xor metric", . [2] Czirkos, Z., "Komondor Security System - the home page of a sample implementation with dynamic monitoring of the overlay", . [3] Czirkos, Z., Hosszu, G., and F. Kovacs, "E-Collaboration Enhanced Host Security", Encyclopedia of E-Collaboration, edited by Ned Kock, Information Science Reference, Hershey, USA, 2007, ISBN: 978-1-59904-000-4. [4] Czirkos, Z. and G. Hosszu, "Peer-to-Peer Methods for Operating System Security", Encyclopedia of Networked and Virtual Organizations, edited by Goran D. Putnik and Maria Manuela Cunha, Information Science Reference, Hershey, USA, 2007, ISBN: 978-1-59904-885-7. Czirkos & Hosszu Expires March 4, 2008 [Page 24] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 Authors' Addresses Zoltan Czirkos BME EET Goldmann Gy. ter 3. Budapest H-1111 Hungary Phone: +36 1 463 4034 Email: czirkos@nimrud.eet.bme.hu Gabor Hosszu BME EET Goldmann Gy. ter 3. Budapest H-1111 Hungary Phone: +36 1 463 2724 Email: hosszu@nimrud.eet.bme.hu Czirkos & Hosszu Expires March 4, 2008 [Page 25] Internet-Draft The Komondor Peer to Peer Security System Sept 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Czirkos & Hosszu Expires March 4, 2008 [Page 26]