Hello Jason: Making sure things are fairly legit as in being 'fair' will only evolve as time goes on. Respectfully speaking, I don't think a 'but' is necessary here. I think what is necessary here is community support, "Fantastic idea, lets go a head and share our block list".
Within trust sources, resources, clients and partners - the block list will be more than a fair and clean list. There are no *false* positives here in a DDOS. The attacks are fairly consistent and *easy* to track and understand. A legit client will not run hundreds & thousands of random sip registrations. IF a legit clients IP gets banned and it appears to be a a false positive, then technically speaking your client's server has been compromised and it is to both of your mutual protection the IP is banned until the client has taken the necessary steps. Within your firewall, FAIL2BAN,and/or IPTABLES rules -- if you observe and write a script that checks the total number of packets blocked/dropped from a particular IP, and if the total number of packets dropped is over 1 megabyte long in a period of 60 seconds from a specific IP, my records have shown that the IP in question is a crook. It is not rocket science. Now as per the honey pot. Yes, I have a honey pot running. The way I have done this is create a 2nd instance of Asterisk running on the same server, binded to an IP that has *never been used*, but on the same subnet. The same idiots who tried to DDOS my production servers, obviously are also trying every other IP in the same subnet (simple hacking/cracking tools). I allow these guys to connect to my server without password authentication. Once they are connected - you get to see they are trying to place illegal calls. Not trying to be funny here at all: for every instance of a call they are trying to make after they are authenticated, all they hear is the sound of screaming monkeys (literally - tt-monkeys.gsm) ----- exten => _X.,n,Playback(tt-monkeys) Before you actually do that - please be aware of the dial-plan injection vulnerability and filter the _X. data prior. ----- Also for your information, I've observed that the moment I let these guys in and they get a valid honey pot successful registration - the DDOS Brute Force stops. Create a SIP account with a 3 digit random numeric user id (lets say 222) and then make sure the "secret" entry itself is not entered - then anyone trying to register the userid 222 with a random password will be allowed entry. ---- EXAMPLE: [222] username=222 host = dynamic type = friend context = MONKEY (make sure you have a MONKEY context in your extensions.conf) insecure = very allow = ALL qualify = yes call-limit=1 (NOTE, THERE IS NO ENTRY FOR 'secret' after 'username'). ----- Please trust me here, the Brute Force thugs **WILL** try to register a 222 or any random 3 digit numeric userid. That's how the attacks start. They try **ALL** 3 digit based userid type registrations first. The registration attempts of the userid from 101 to 999 takes only a second or two, via the tools they are using. This is what I have done to create my honey pot. I also have SSH, FTP and TELNET services running, and technically speaking these services have almost negligible number of attacks compared to SIP services. From the IPs that have pounded some of my servers with giga bytes of brute force attacks, did not even try one attempt of a SSH attack, which confirms my suspicion that who ever is doing it, is seeking SIP vulnerabilities, weak password protected servers, trixbox type setups where default passwords have not been changed and trying to find SIP servers where the admins have not taken into account best business practices. Kind regards, Reza. -- Toronto based VoIP / Asterisk Trainer, I.T. Consultant and Hosted PBX Solutions Provider. +1-647-476-2067. http://www.linkedin.com/in/seminar On Wed, Sep 1, 2010 at 9:23 PM, Jason Rose <[email protected]> wrote: > I think its a great idea in general, but you need some way of making sure it > is > fairly legit... > > > Does anyone here run a honey pot? With the number of increased attacks its > possible to setup a "dummy" asterisk server with open SIP ports and just wait > for someone to attempt to connect to it... then auto add all of those lists to > the DB.... This wouldnt be too hard to implement! > > Jason > > > > > ________________________________ > From: Matthew Gamble <[email protected]> > To: Bruce N <[email protected]>; asterisk Mailing <[email protected]> > Sent: Wed, September 1, 2010 8:21:15 PM > Subject: Re: [on-asterisk] Crowd sourcing rules for blocking hacking attempts? > > Bruce, > > What I'm proposing (and actually just started writing the code for) is > a system where we allow anyone to sign up (the power of the crowds) > but require a few things: > > 1) Authenticated email address. Not hard to get, but it does stop > random signups > 2) Reports from new accounts are not added to the global list for X > days to monitor the quality of the data they are submitting. > > Further to the above, I'm adding a "score" feature to the output, so > when you request a list of "bad" hosts you would get a file with IP, > last reported date, and "score". The score would be a function of a > few things: > > 1) How well do you trust the reporter(s)? Age of accounts, never > flagged for reporting bad data, etc > 2) How many people reported this IP? 1? It wouldn't be in the > database until a few different sites reported it, etc > 3) Other criteria I'm still writing. > > The third piece of security would be a system for people to "flag" > data as being bad, creating a feedback loop to ensure that if a person > submitted false data that it was quickly removed from the DB. > > Remember that crowd sourced rule systems already work for email > (Cloudmark for example) and with a trust system and good scoring rules > the issue of false positives becomes much less of a risk. > > > On Wed, Sep 1, 2010 at 8:13 PM, Bruce N <[email protected]> wrote: >> Hello Mathew, >> >> Are you suggesting an open system for everyone and anyone to input an IP >> address? Two scenarios: >> >> 1- Allow only people who you trust - >> CONS: >> a- Still can't negate the fact that some authorized >> user may mistakenly put a client's IP in the "BAD" IP table. >> b- Limiting the number of reported "BAD" IPs to the >> number of trusted people which I would like to believe would be very small >> or else it won't be a trusted circle. >> PROS: >> a- Can be MORE or LESS a trusted database - As long >> as no bulk IPs are allowed to be entered and there are restrictions to add >> more than 1 IP per hour let's say. >> >> 2- Allow anyone to sign-up and add "BAD" IPs. >> CONS: >> a- Anyone can sign-up. Even the cracker!!! He can >> put our legit IPs in the database and "BOOM", shutdown service for clients >> for no good reason. I mean an IP that is "BAD" today can be a potential >> customer tomorrow. What would be the rules to remove them when you have a >> whole bunch of people submitting these - specially if this grows really big. >> b- The list will grow so big that it won't be >> possible to handle or it might again block legit users as the attacks are >> usually co-ordinated not from the cracker IP address but rather compromised >> servers and it might literally block a good portion of the USA continental >> as lots of attacks do originate from compromised servers in USA while the >> cracker is enjoying his tea break in Russia. >> >> PROS: >> a- Would be a more complete list of "BAD" IP >> addresses. >> >> These work around will be somehow useful but isnt' it about time that SIP >> becomes more transparent to the common folks (simpler, less ambiguous >> output, and more manageable SIP debug) - as it's becoming more commonplace >> now-a-days? Or maybe pay more attention to it's security feature innately >> like other popular protocols rather than keeping them as an option for the >> user to turn on? As an example, just few years ago, all wireless routers >> were possible to setup without a wireless security (one could literally jump >> from neighbour to neighbour in the whole block) and now any router you take >> out of the box either has a randomly generated wireless password or asks for >> one before setting up the wireless leaving you with no access to neighbours >> hot spot. >> >> -Bruce >> >> >>> Date: Wed, 1 Sep 2010 19:48:54 -0400 >>> From: [email protected] >>> To: [email protected] >>> Subject: [on-asterisk] Crowd sourcing rules for blocking hacking attempts? >>> >>> I've been following the threads over the past weeks about Asterisk >>> hacks being on the rise, and I have to say I've been seeing the same >>> thing in my logs. >>> >>> I'm wondering if there is any community interest in creating a >>> database of known "attack" IP's that we could all update our IPTables >>> or other firewall rules with? I'm thinking we create some interface >>> for people to submit hosts they have blocked and a second interface >>> for people to download a list of "bad hosts" with number of reports. >>> >>> If anyone is interested in working on something like this please let >>> me know. I don't mind hosting / writing / running it, but I would >>> like to know that the community would use it before I invest the time >>> to set it up. >>> >>> Thanks! >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
