On 11/26/2010 9:26 AM, Christian Pena wrote:
We have seen similar things on our network. I never setup the HMRs on the access side of the Acme thinking they would cause a substantial increase in CPU usage. Anyone have any luck in doing this on a production network?
Thanks,
Chris
As an FYI, that is a sipvicious scan against your machine. I've seen something to the tune of an 1800% increase in these scans beginning on Halloween of this year (www.infiltrated.net/voipabuse/logs/) and I try to keep track of what is going on. As long as your devices are on the 'net, you will see the debris. Not much you can do other than try blocking either entire netblocks or individual hosts. While I've had honeypots up tracking what it is these guys do, it is becoming increasingly difficult due to the mass amounts of scans. I have a theory that about one or two dozen groups have created a distributed SIP scanning method as when I see one attacker plop up from one netblock, about 1/2 dozen follow suit immediately after. My view is that they're sending multiple scans out in the event that if one is detected and blocked, the others will pick up and continue on. Attacker1 --> scans --> 100-200 Attacker2 --> scans --> 100-200 Attacker1 is detected and blocked when it reaches say extension 150 Attacker3 pops up and scans 151 - 200 I see these come through now with some pretty specific targets that make little sense at first, but when I parse out and analyze the logs, I come to what I concluded above. For those who've read about the VoIP Abuse Project or perhaps have heard the TUC conference I was on, there is a lot more sophistication going on right now. As a test, I changed the passwords of about 100 honeypot accounts I have on the net, within 2-3 hours, they had re-established connections to try to place calls through. From what I see, two distinct attacks: 1st, enumeration (someone tries to find an account) 2nd, when an account is found a completely different host sends calls. The individual's IP SENDING the call NEVER (ever, ever, ever) is on any bruteforcing log. I truly believe the individual sending the calls or at least trying to is an actual person and not some script. I base this on the fact of the timing parameters involved with dial plan tinkering. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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