There was a discussion about tools you can use to measure RTP jitter/latency. Ethereal was recommended. I definitely agree.
There was a very interesting post about a real-world attack on a SIP proxy. You don't hear about a lot of real world attacks, so this is pretty significant. Here is a summary, extracted from the list:
I've witnessed within the last few days a brute force attack on SIP REGISTER requests in some type of automated fashion. I'm wondering if others have seen similar issues on their networks who would be interested in sharing any experiences publicly or privately.
A brute-force password attack was launched against a SIP-based PBX in what appeared to be an attempt to guess passwords. Queries were coming in about 10 per second. Extension/identities were incrementing during each attempt, and it appeared that a full range of extensions were cycled over and over with the new password. The User-Agent: string was almost certainly falsified (it reports "Polycom".) I can provide more details to anyone who is interested in the specifics.
I don't know when this problem was discovered in relation to the time that it started. The extension ranges that were being attacked were valid extensions, unknown to anyone other than the administrator of
the system, which was primarily a testbed (leading to an assumption of random scanning for UDP 5060 responses on public IP addresses as the vector for the attacker.) Some brief testing against Asterisk
shows that there are different replies when a valid extension versus an invalid extension is supplied in a REGISTER attempt (no surprise there, since an unknown user will result in an immediate "404" error
upon REGISTER attempt, while a known user but bad nonce during REGISTER will result in a "401" error.) Therefore, it may be the case that the attacker scanned a large number of sequential or random
extensions until a valid range was discovered, then the range was narrowed and password brute-force attacks started once valid SIP identities were established. This is a guess, but it fits the evidence at hand.
While Asterisk was the platform under attack, this is not an Asterisk-specific attack method. The brute-force method used is applicable to any SIP registrar/proxy that accepts and processes such requests. The method by which the attacker may have obtained valid SIP peers (presentities) on Asterisk has been identified, and Asterisk has since been patched (SVN-TRUNK and 1.2 TRUNK) to include a method that allows administrators to obscure SIP response codes on INVITE, SUBSCRIBE, and REGISTER from 404 to 401 in the case of non-existant hosts ("alwaysauthreject" option in sip.conf.) Thanks to Kevin Fleming for quick turnaround on this. While Asterisk does not seem from current evidence to be vulnerable to any particular password attack method, it is the case that previous versions to today are farm-able for valid extensions on which attacks may be attempted.
The attack does not seem to be a "bot" attack, as only one IP address was originating requests, but of course that can quickly change based on the intent of the attacker and their resource availability. Blocking the attack is simply performed with an IP address filter on the router or filter table on the host. However, this is obviously insufficient for larger scale problems where multiple attacking hosts or targets are involved. A more complete solution has been discussed which would involve a dampening system that would slow replies (or ignore requests) for any authentication methods for individual presentities based on frequency of requests for that presentity or frequency of requests from that originating host. Are there comments
on the usefulness or validity of such a dampening system? Has anyone deployed such a system already, and could you speak to the results of such a method?