RES: [Standards] Proposed XMPP Extension: Best Practices to DiscourageDenial of Service Attacks Against XMPP Servers
nickp at bu.edu
Tue Jan 23 19:57:36 UTC 2007
Maybe add bandwidth throttling as another method of limiting resource use.
> As described in XEP (Best Practices to DiscourageDenial of Service Attacks Against XMPP
> Item 4.1:
> I have a doubt about maximum users per IP in a XMPP Server.
> We do have a large number of NAT in front of companies network. And for large companies that uses
> public IM server, this may not be applied. As they have more than 100 users connected ( actually
> it can reach 150 ) to a public IM server, using the same public IP.
> What I suggest is to use 2 levels of deny:
>>>> Limit the "simultaneous connections number".
>>>> Limit the "simultaneous connections number" in a "time period".
> * This will help to prevent fake attacks.
> * And make the defense more effective against "Connections/Disconnections" attacks.
> If you limit just the max simultaneous connections, the attacker can connect and disconnect
> thousand times and still keeping with his attack.
> What I suggest is limit 100 simultaneous users per IP, if the server want to provide some public
> services for companies.
> And another limit of 120 new connections per hour per IP.
> An attacker will need much more than 120 new connections per hour per IP to damage a XMPP server.
> And please remember, that attackers or kind of, don´t use just one IP to do an attack. Actually,
> it uses many IPs as possible to do its attack.
> 4.1 Simultaneous Connections
> A server implementation SHOULD enable a server administrator to limit the number of connections
> that it will from a given IP address at any one time. However, it is also possible to limit the
> number of connections at the TCP layer rather than at the XMPP application layer. It is
> RECOMMENDED for a deployment to set the maximum number of connections per IP address to a number
> between 20 and 50.
> If an entity attempts to connect but the maximum number of connections has been reached, the
> receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated
> with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is
More information about the Standards