Hi Marios On 25/06/12 20:36, Marios Makassikis wrote:
> Seeing your solution ( glad you solved your problem by the way :) ), it looks > like someone is bruteforcing your server. Which implies that the first > step prior > to attempting to authenticate is to establish a connection. I'm > surprised PF doesn't > catch it though. > Even if the attacker is using the exact same packets, I recall reading > that PF tracks > connections by looking at source and destination transport addresses, > but also ISNs. > (Of course, you shouldn't take my word for it, as I couldn't find any > source that backs > this up.) > In that case, it would mean your server is using weak ISNs and using > modulate state > instead of keep state would help mitigate the issue, as new states > would be created > for each connection and you can effectively do some rate limiting. > > There's also the possibility that your software keeps the connection > open upon a failed > auth, instead of closing after a predefined number of attempts. If > that's the case, I'd send > a bug report to the developers. There are no connections to close ... It's SIP --> UDP .. The attacker can always use the same packet header. Think there is no way to solve that at Layer 3 or 4, You have to look at the content. Regards Matthias -- Matthias Cramer, Erachfeldstrasse 1b, CH-8180 Bülach, Switzerland http://www.freestone.net GnuPG 1024D/2D208250 = DBC6 65B6 7083 1029 781E 3959 B62F DF1C 2D20 8250 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
