2010/9/20 VoIP Abuse Project <voipabuse at infiltrated.net>
Leandro Dardini wrote:
Hello, I find a blacklist too heavy to manage and unable to catch the fast emerging bruteforcers. As freelancer I suggest to my clients (all on Linux with Asterisk) the install of the fail2ban software.
The working of fail2ban software is really simple: it reads the messages generated by the application and if one user try to authenticate with wrong credentials more than X times in the unit of time, then triggers an insert into iptables to not get more packets from him for a long time (adjustable).
Leandro
Understood on fail2ban however, I can use fail2ban against you and have your own servers block their upstream. Fail2Ban "fails" when you're in a managed PBX arena and your clients are connecting from all over the place. When you have thousands of customers and some are connecting from all over the place, fiddling with Softphones, settings in Snom, Polycom, etc., you will quickly learn that Fail2Ban outright fails.
While a blacklist CAN be cumbersome, this isn't like spam where there are millions of hosts attempting this per day. At maximum, I've seen about 15-20 hosts attacking one PBX. It will take me about 20-30 minutes to whip up a python or shell script to parse them out and upload them. I already have my honeypot writing to DB, all I have to do is re-write to gzip and send the full logs.
The hard part is writing an informative email someone will likely never read (abuse departments). Last thing I want to hear is "you're not playing fair" when their clients complain.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT
"It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett
227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
I am sorry, but I really don't understand how fail2ban can be used against me. The only drawback of fail2ban is when inside a large private organization using NAT and exiting on Internet with a single (or small pool of) IP, some evil colleagues can send a bunch of wrong REGISTER requests and trigger fail2ban to filter the IP preventing legitimate users from within the same organization to access your service. This can happen once, then the good sysadmin of the organization will snoop the traffic and catch the evil colleagues. Leandro
Leandro Dardini wrote:
I am sorry, but I really don't understand how fail2ban can be used against me.
It's a simple/easy DOS attack. If someone can send packets with a spoofed source address, they can cause you to filter your upstream or your client. For the upstream providers with static IPs, that should be easy to fix with a whitelist. I don't believe that knowing your customers' dynamic IPs is a realistic attack. My experience with repeated attempts to crack SIP is that it only happens to us if we have simple registration names (IE, registration name is the extension number). We've gone away from that completely and I can't recall the last time we saw someone try to brute force one of our accounts. I see registration attempts against sequential numbers (301, 302, 303.....) but since the accounts simply don't exist, there's really little harm. -- Carlos Alvarez TelEvolve 602-889-3003
Carlos Alvarez wrote:
Leandro Dardini wrote:
I am sorry, but I really don't understand how fail2ban can be used against me.
It's a simple/easy DOS attack. If someone can send packets with a spoofed source address, they can cause you to filter your upstream or your client. For the upstream providers with static IPs, that should be easy to fix with a whitelist. I don't believe that knowing your customers' dynamic IPs is a realistic attack.
My experience with repeated attempts to crack SIP is that it only happens to us if we have simple registration names (IE, registration name is the extension number). We've gone away from that completely and I can't recall the last time we saw someone try to brute force one of our accounts. I see registration attempts against sequential numbers (301, 302, 303.....) but since the accounts simply don't exist, there's really little harm.
All one has to do is an nslookup and hit the field for fail2ban, e.g.: Username "place an IP address RIGHT_HERE"@registrar Care to see stupidity? [2010-09-20 01:16:17] WARNING[8395] chan_sip.c: Bad request protocol THE TEXT FILE IN THE RAR FOR THE PASSWORD!!!@208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:17] WARNING[8395] chan_sip.c: Bad request protocol THE TEXT FILE IN THE RAR FOR THE PASSWORD!!!!@208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:17] NOTICE[8395] chan_sip.c: Registration from '"READ THE TEXT FILE IN THE RAR FOR THE PASSWORD!!!!"<sip:READ THE TEXT FILE IN THE RAR FOR THE PASSWORD!!!!@208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL [2010-09-20 01:16:17] WARNING[8395] chan_sip.c: Bad request protocol THE TEXT FILE IN THE RAR FOR THE PASSWORD!!!!@208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:17] WARNING[8395] chan_sip.c: Bad request protocol THE TXT IN THE RAR FOR THE PASSWORD!!!!!!!!!@208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:17] NOTICE[8395] chan_sip.c: Registration from '"READ THE TXT IN THE RAR FOR THE PASSWORD!!!!!!!!!"<sip:READ THE TXT IN THE RAR FOR THE PASSWORD!!!!!!!!!@208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL [2010-09-20 01:16:17] WARNING[8395] chan_sip.c: Bad request protocol THE TXT IN THE RAR FOR THE PASSWORD!!!!!!!!!@208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:23] WARNING[8395] chan_sip.c: Bad request protocol PASSWORD IS IN THE FILE at 208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:23] NOTICE[8395] chan_sip.c: Registration from '"THE PASSWORD IS IN THE FILE"<sip:THE PASSWORD IS IN THE FILE at 208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL [2010-09-20 01:16:23] WARNING[8395] chan_sip.c: Bad request protocol PASSWORD IS IN THE FILE at 208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:24] WARNING[8395] chan_sip.c: Bad request protocol PASSWORD IS IN THE RAR at 208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:24] NOTICE[8395] chan_sip.c: Registration from '"THE PASSWORD IS IN THE RAR"<sip:THE PASSWORD IS IN THE RAR at 208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL [2010-09-20 01:16:24] WARNING[8395] chan_sip.c: Bad request protocol PASSWORD IS IN THE RAR at 208.50.xx.xxx SIP/2.0 [2010-09-20 01:16:24] NOTICE[8395] chan_sip.c: Registration from '"this-is-a-password"<sip:this-is-a-password at 208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL [2010-09-20 01:16:24] NOTICE[8395] chan_sip.c: Registration from '"this-is-a-stupid-password"<sip:this-is-a-stupid-password at 208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL Fail2Ban separates on fields, e.g., awk '{print $X}' # awk '/[assword]/{print $15}' TodaysLogs|sort -u - 1 '7182b14a1230885704b1002c09bc4774 at 208.50.xx.xxx'. '79dfff0f0359dea6360a52270266be12 at 208.50.xx.xxx'. '7fd16dc55ce9bd2173b95b5d38a2c301 at 208.50.xx.xxx'. does for got host=dynamic IN Inside at 208.50.xx.xxx>' INSIDE!!!@208.50.xx.xxx>' match ME.TXT at 208.50.xx.xxx>' mokey at 208.50.xx.xxx>' packet. "PASSWORD PASSWORD!!!!!!!!!@208.50.xx.xxx PASSWORD!!!!!!!!!"<sip:READ READ Response) seconds SIP/2.0 supposed Text TEXT THE TXT up. use Normally, in Asterisk, my configuration should print an invalid address on the 11th field: # awk '/[assword]/{print $11}' TodaysLogs|sort -u - / )@208.50.xx.xxx>' .38 Bank at 208.50.xx.xxx>' but [By] Ca at 208.50.xx.xxx>' CALLED chapparal at 208.50.xx.xxx>' context daddy?@208.50.xx.xxx>' Day DJP at l@@208.50.xx.xxx>' Door at 208.50.xx.xxx>' Dude at 208.50.xx.xxx>' enjoy at 208.50.xx.xxx>' expected. FILE for freeliz.ru at 208.50.xx.xxx>' future hardNloud.co.nr at 208.50.xx.xxx>' Head at 208.50.xx.xxx>' Hidin'@208.50.xx.xxx>' image In IN Inside INSIDE Inside at 208.50.xx.xxx INSIDE!!!@208.50.xx.xxx Inside"<sip:Read INSIDE!!!"<sip:READ job Know at 208.50.xx.xxx>' ME.TXT at 208.50.xx.xxx ME.TXT"<sip:READ (missing mokey at 208.50.xx.xxx mokey"<sip:i Muzik at 208.50.xx.xxx>' -N- Need NEEDED at 208.50.xx.xxx>' nj at 208.50.xx.xxx>' nYoy at 208.50.xx.xxx>' One other party Pass at 208.50.xx.xxx>' password "PASSWORD Password at 208.50.xx.xxx>' peer qualify: .rar at 208.50.xx.xxx>' .RAR!!!@208.50.xx.xxx>' RAR at 208.50.xx.xxx>' READ reply RTP rund at 208.50.xx.xxx>' SIP/2.0 Spot at 208.50.xx.xxx>' THE thejukejointmp3.net at 208.50.xx.xxx>' to tonight at 208.50.xx.xxx>' tummut at 208.50.xx.xxx>' UffePuff at 208.50.xx.xxx>' Upon useeeeeee at 208.50.xx.xxx>' useless at 208.50.xx.xxx>' vrijemp3.biz at 208.50.xx.xxx>' Warez-BB.org at 208.50.xx.xxx>' Weed at 208.50.xx.xxx>' westpark at 208.50.xx.xxx>' So no thank you on fail2ban. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
On Mon, 20 Sep 2010, J. Oquendo wrote:
Fail2Ban separates on fields, e.g., awk '{print $X}'
# awk '/[assword]/{print $15}' TodaysLogs|sort -u # awk '/[assword]/{print $11}' TodaysLogs|sort -u
Did you read the docs? http://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Filters
[2010-09-20 01:16:24] NOTICE[8395] chan_sip.c: Registration from '"this-is-a-stupid-password"<sip:this-is-a-stupid-password at 208.50.xx.xxx>' failed for '69.72.242.170' - Device does not match ACL
failregex = Registration from '.+?' failed for '<HOST>' Done. Needs real-world testing/tweaking but I'm pretty sure your argument that it is too hard to match a failure in fail2ban is silly. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On 9/20/10 9:38 AM, Leandro Dardini wrote:
I am sorry, but I really don't understand how fail2ban can be used against me. The only drawback of fail2ban is when inside a large private organization using NAT and exiting on Internet with a single (or small pool of) IP, some evil colleagues can send a bunch of wrong REGISTER requests and trigger fail2ban to filter the IP preventing legitimate users from within the same organization to access your service. This can happen once, then the good sysadmin of the organization will snoop the traffic and catch the evil colleagues.
In most cases SIP transactions are UDP, hence trivially spoofed. An attacker can generate failed registration/authentication attempts spoofed from your customer or peer IPs. Fail2ban will then lock out your legitimate traffic. It can also cause issues where a single misconfigured phone or device can cause an entire NAT site to be blocked. Fail2ban can be a useful tool but should be used with caution in this application. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Mon, Sep 20, 2010 at 2:19 PM, Jay Hennigan <jay at west.net> wrote: [snip]
In most cases SIP transactions are UDP, hence trivially spoofed. ?An attacker can generate failed registration/authentication attempts spoofed from your customer or peer IPs. ?Fail2ban will then lock out your legitimate traffic. [snip]
It is probably trivial to recognize a brute force attack from a single IP, as these are most prevalent, and we at least have not heard of other possible attacks such as spoofed SIP to trigger firewalls. That may become more of an issue later, if fail2ban installations become popular, or become a default included by some vendor. It might be useful to think about possible deprecation of the use of UDP for registration, or at least the requiring of a firm bidirectional acknowledgement with nonce (as in an authenticated request/acknowledgement), before a registration "attempt" can be regarded to fail or succeed. An attacker may spoof the source IP of single packet UDP registration requests for an entirely different reason -- a blast/scatter attack. In this scenario, an attacker may blast from 1000 source addresses, 900 of those could be spoofed third party innocent IPs. It wouldnn't be trivial to determine which IP address belongs to the attacker. It is still a a brute force attack, but you don't know which IP's the real attacker. All fake source IPs may appear to send similar number of requests as the real sources, in a similar pattern. Distribution pattern can conceal which nodes are the "true source" addresses, while the vast majority of the addresses are fake (truly originating from a few malicious nodes). How do you reliably build a blacklist, if the source of communication can be arbitrarily forged by an adversary, and you cannot detect that? Someone might spoof one of your source IPs for the sole purpose of attempting to get you blacklisted. It may be a bit paranoid to expect this will happen often, but it should be anticipated. There needs to be a way to determine if the IP is spoofed or not, within the protocol itself, before you can have a truly reliable blacklist, without possibly a lot of noise and false listings. -- -J
On 09/20/2010 08:47 PM, James Hess wrote:
It might be useful to think about possible deprecation of the use of UDP for registration, or at least the requiring of a firm bidirectional acknowledgement with nonce (as in an authenticated request/acknowledgement), before a registration "attempt" can be regarded to fail or succeed.
"Firm bidirectional acknowledgment" is already required in an authenticated REGISTER sequence: 1. ---------- REGISTER ----------> 2. <-------- 401 challenge ------- 4. ------- REGISTER + digest ----> 5. <---------- 200 OK ------------ Unless this happens, an attempt cannot be regarded to "succeed." -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Mon, Sep 20, 2010 at 8:09 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 09/20/2010 08:47 PM, James Hess wrote:
It might be useful to think about possible deprecation of the use of UDP ?for registration, or at least ?the requiring of a firm bidirectional acknowledgement with nonce ?(as in an authenticated request/acknowledgement), before a registration ?"attempt" ?can be regarded to fail or succeed.
"Firm bidirectional acknowledgment" is already required in an authenticated REGISTER sequence:
Yes, I think the problem is with authentication failures, not successes. Implementations might flag a failure at step 1, before any round trip has occured. The 'spoofer' may simply reply with a bogus digest. Either way, afaict, the spoofer never needs to see the challenge to submit a register what will produce an authentication failure (may even be intended to produce an auth failure as part of the distraction). The implementation that received the spoof message sees REGISTER + (incorrect digest) which doesn't reveal that the attacker never saw the challenge. -- -J
On 09/20/2010 03:19 PM, Jay Hennigan wrote:
In most cases SIP transactions are UDP, hence trivially spoofed.
I would not say "trivially." Yes, the individual messages that make up the transaction can be spoofed, but not the transaction as a whole; there is an elaborate state machine whose demands must be satisfied for this to take place. If encumbered by any type of authentication, it won't. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
participants (7)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
carlos＠televolve.com -
jay＠west.net -
ldardini＠gmail.com -
mysidia＠gmail.com -
sil＠infiltrated.net