s2s does not rate limit outgoing connections

[rma-x]

On my jabber server I observed bots that came in via c2s to cause well over 10,000 outgoing s2s attempts per minute to a single nearby jabber server that was refusing connections at the time. At three log lines per attempt, this caused massive log file bloat.

Similarly, attempts to establish connections to a more distant server that immediately ended in a stream error repeated at rates up to about 2500 per minute.

I think the number of outgoing connections attempts per remote server should be rate limited like it is the case for connections from other services to the router.

[TerrorBite]

Also having this issue.

From my lethargiclion.net Jabber server, I attempted to add a contact we'll call user@example.org. The SRV records on example.org point to the Google Talk servers (since his example.org domain has Google Apps, and he used to use his Google Talk account to federate to XMPP; the SRV records remain).

This wouldn't be a problem except that lethargiclion.net is also a Google Apps domain, so Google Talk considers the lethargiclion.net domain as belonging to itself, and took exception to being contacted by my jabber server. It terminated the connection with Stream error (lethargiclion.net is a Google Apps Domain with Talk service enabled.) My Jabber server immediately retried, and continued to retry endlessly, filling the s2s.log with entries.

This is of course not limited to the scenario shown above, as any stream error will cause outgoing connections to occur at a high rate.

This bug allows a potential DoS attack against jabberd2 servers, as malicious users could create an account and add a crafted contact that would result in stream errors returning to s2s, potentially resulting in disk space exhaustion on the jabberd2 server due to log file growth. Given the high rate of connection retries it could also potentially be used as a vector to attack other servers, if the conditions are correct. Other risks also exist.

Rate limiting of outgoing connections and a limit on the number of retries needs to be implemented.

[smokku]

This is of course not limited to the scenario shown above, as any stream error will cause outgoing connections to occur at a high rate.

This statement is not true. Only recoverable stream errors cause a connection retry. Unrecoverable connection errors mark server as unreachable. See https://github.com/jabberd2/jabberd2/blob/master/s2s/out.c#L1508

What is the exact stream error kind Google server is tearing the connection with?

[TerrorBite]

Wed Jun 11 09:21:31 2014 [notice] [10] [74.125.129.125, port=5269] outgoing connection for 'example.org'
Wed Jun 11 09:21:31 2014 [notice] [10] [74.125.129.125, port=5269] sending dialback auth request for route 'lethargiclion.net/example.org'
Wed Jun 11 09:21:31 2014 [notice] [10] [74.125.129.125, port=5269] error: Stream error (lethargiclion.net is a Google Apps Domain with Talk service enabled.)
Wed Jun 11 09:21:31 2014 [notice] [10] [74.125.129.125, port=5269] disconnect, packets: 0

(actual domain replaced with example.org)

Apologies for the stream error assumption. However, I am not sure this error counts as recoverable.

---

Edit: Just had a look at the code, does this mean Google is abusing the sxe->specific field?

[smokku]

Doh. I investigated a bit more. The real issue is that in https://github.com/jabberd2/jabberd2/blob/master/sx/io.c#L100 we are pulling <text> element of stream error to sxe->specific, not <defined-condition> element, thus matching it for defined conditions fail.

Looks like the whole _sx_gen_error() usage needs complete revamp.