RES: [Standards] Proposed XMPP Extension: Best Practices to DiscourageDenial of Service Attacks Against XMPP Servers

Thiago Camargo thiago at jivesoftware.com
Tue Jan 23 18:40:21 UTC 2007


As described in XEP (Best Practices to DiscourageDenial of Service Attacks Against XMPP Servers)...

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".

AND

>>> 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. 

Regards,
Thiago


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 initiated.


-----Mensagem original-----
De: standards-bounces at xmpp.org em nome de Peter Saint-Andre
Enviada: ter 23/1/2007 11:02
Para: XMPP Extension Discussion List
Assunto: Re: [Standards] Proposed XMPP Extension: Best Practices to DiscourageDenial of Service Attacks Against XMPP Servers
 
Kevin Smith wrote:
> On 22 Jan 2007, at 17:55, Peter Saint-Andre wrote:
> 
>> XMPP Extensions Editor wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> Title: Best Practices to Discourage Denial of Service Attacks Against 
>>> XMPP Servers
>>> Abstract: This document recommends a number of practices that can 
>>> help discourage denial of service attacks on XMPP-based networks.
>>> URL: http://www.xmpp.org/extensions/inbox/dos.html
>>
>> Just a little something I wrote up over the weekend. It needs to be 
>> expanded a bit before the XMPP Council decides whether to accept it.
> 
> Within the 'Specific recommendations to follow' of Karma usage - what do 
> people really think of Karma? While I agree that it's desirable to stop 
> people overloading servers, I'm a bit concerned that low karma limits 
> will do more damage than good, and we should think reasonably carefully 
> about recommending levels.

That's true of all the levels (stanza size etc.). Plus we need to define 
"karma" more carefully in the first place -- some servers have rather 
complex formulas for it...

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070123/d46a1cd0/attachment.html>


More information about the Standards mailing list