UPDATE: The following feature has been implemented accurately in kxd (kang's shxd-0.3.6 fork) and mhxd (merged hxd by rorschach, a merger of shxd, kxd, and hxd). Synapse Hotline X Daemon Devin Teske Request for Comments: 1 Devin Teske Category: Informational shxd September 2001 Guidelines for Transactions Spam and DoS Protection Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo specifies guidelines for implementors and users of the Synapse Hotline X Daemon (shxd) to bring about improvements in how the server handles protocol transactions. We show how to configure "volatility ratings" on transactions from the hotline protocol to cut likelihood of spam or Denial of Service (DoS) attacks. This allows for a more secure daemon and more pleasing experience. These guidelines do not require any protocol changes; they only provide recommendations for how Transaction Flood Protection (TFP) should be implemented and configured in the server efficiently. Acknowledgements This memo is the result of discussions on hotline servers around the world. I thank everyone for their input. 1. Introduction Currently, hotline servers (if configured) only protect against chat spamming. Said protection is based on configuration options limiting the number of lines of chat that are allowed in a certain amount of time. If the client sends more than the configured limit, the user is banned for thirty minutes. There are several ways around this and also several other types of attacks that are not guarded against by simple anti-chat-spam efforts. To accurately supress these efforts, you must first accurately define them. There are three main categories of efforts: Advertisement (spam), Rapid Event Flood (annoyance), and Denial of Service (attack). The third effort includes all transactions. Any single transaction sent to the server in mass quantity regardless of simplicity can be dangerous (ex. ping -f). The solution is to create a system that logs all transactions from a client and considering all of them as potentially dangerous. 2. Summary of Recommendations It is in theory the server's responsibility to protect the user from spam. The server-client relationship is synonomous with the father- son relationship where the father protects the son from danger. Implementing this relationship in hotline to protect the client from unsolicited data being sent to it would not be necessary if it were not a constant pool of people advertising crap on other servers with faceless drones systematically messaging every person. There is also a growing number of hacker tools being created to add even more automated annoyances to the hotline environment. I server side implementation of total transaction flood protection would make it nearly impossible to use a DoS via Hotline Transactions and more difficult to create a contigous annoyance. In total making the effect worth far less than the effort to produce it. 3. Implementing Transaction Flood Protection (TFP) over hotline These ideals would allow it to be possible to add TFP to most any application with predefined protocol transactions. The simplest way to add TFP to an application would be to create a library of tools that implement it. TFP will work by the developer adding to a header a list of volatility ratings for each transaction. Volatility ratings will be 8 bit unsigned integers used to track how strict to be on a transaction. A more volatile transaction (higher volatility rating) will be allowed less times than a transaction with a lower volatility rating. TFP libraries will include functions for doing all the work. When the application using TFP recieves a new connection a call should be made to tfp_accept passing a unique pointer to the function. TFP will keep track of a user after it has disconnected to see if they are connection spamming (rapidly connecting and disconnecting). If the user is allowed to connect, the function returns 0. When a transaction is recieved, the application should make a call to tfp_add passing the unique pointer representing the connection and the transaction recieved. The function then adds the volatility rating of the transaction to a property of the connection. If the total rating of all transactions within the past 5 seconds (configurable) is greater than the configured limit then the function returns non-zero. Otherwise if the total rating is less than the limit the function returns 0. When a client disconnects from the server, the application should make a call to the tfp_close function. The function frees the memory used by the client (40 bits) and adds the client information to a log. The information includes the clients IP address, login offense and expiration time-stamp. The average amount of time it takes someone to ban a person on hotline is 5 seconds. The attacker may be on a lagged line doing a connection spam. If so we will ignore them if they are doing less than a connection every 5 seconds because the admin will have enough time to kill them on login. We want to make sure that the user is not having connection problems or is not a localhost testing the server connection. So we will draw the line at 3 connection spams. Each time the person logs in, if the login time is within 10 seconds (twice the allowed limit to encapsulate lagged connections) of the logout time we increment the login offense. If the login effense exceeds 3 then we ban the person for a configured amount of time. All these numbers are configureable. Each time tfp_accept is called, expired connection spam threats are removed from the list. 4. Conclusion This is not designed to elimate all possible attacks completely or spams. It is designed to make the effect of the attack on the victim's side minimalized by making a punishment. This also tries to make it so that the effect on the victim is so minimal given the effort to produce it is not worth it. Thus, making it a natural deterrent against spam and attacks.