My suggestion for a name would be OTRBL. Or OLTLRLBL.com but that's too long...
Short for "One List, Two List, Red List, Blue List"... for the dads (or moms out there)... thanks, I'll be here all night. -----Original Message----- From: Matthew Gamble [mailto:[email protected]] Sent: September-01-10 10:24 PM To: Chuck Mariotti Cc: Bruce N; asterisk Mailing Subject: Re: [on-asterisk] Crowd sourcing rules for blocking hacking attempts? Chuck, I actually already worked that into "version 1" of my reporting interface, here's an example using HTTP GET's secured by HTTP auth to report 1.1.1.1: http://<reporting server>/report/IP/1.1.1.1 http://<reporting server>/report/IP/1.1.1.1/{proto} (SSH, SIP, HTTP, SMTP, IMAP, etc -will need a full list) http://<reporting server>/report/IP/1.1.1.1{port#} (just send numeric port #) When getting a list of "bad IP's" the GET URL's would look like: http://<reporting server>/download/all http://<reporting server>//download/proto/{Proto} http://<reporting server>//download/port/{Port} http://<reporting server>//download/new/{Date added} http://<reporting server>/download/score/{score above x} I think that's a pretty simple interface that will let anyone use this with almost any system / firewall / app. I've also spec'd out a neat way to do real time distribution of the rules, but I'm saving that for version 2 :-) I've got a domain setup for this project and will be sending out an announcement once I have something setup. On Wed, Sep 1, 2010 at 10:17 PM, Chuck Mariotti <[email protected]> wrote: > This is very interesting... > > Matthew, > > If I might make a suggestion (aka scope creep)... It might be an interesting > idea to step this out further than the initial intention and make it a > broader framework in terms of data capture and subscription. Assuming this > problem is happening for other technologies/protocols, maybe it is a good > idea to step things back a bit to be applicable to other technologies > should/when the need arises. Ex. If there is a similar attack on another > protocol... so you could push data in for a specific protocol and also pull > IP's out based on protocol or port or both. > > Since I run pfSense... 'subscribing' to the banned IP list would be helpful > if I could subscribe/import it on my firewall rather than on a per Asterisk > server basis. Others would want per asterisk server I assume. > > I would also assume that such a system should be able to automatically notify > the ARIN contacts of a IP or Subnet submitted into the system. Some tracking > key allowing them to clear the lock... either a "give me an hour" unlock, or > an "It's been fixed". > > It might also be interesting to have an account in the system, that I > would submit "suggested bans" into, also maintain 'suggested > whitelists' and a private "my bans" and "my whitelist"... Allowing me > to pull a comprehensive list from the system and apply it to all > applicable devices (say I have multiple firewalls, different > locations, etc...) > > Of course, I would think that a discussion about abuse of the system would > have to be thought through (ala SpamCop, SpamHaus, etc...). > > Similarly, maybe it shouldn't just be IPs (IPv6), maybe email addresses, > phone numbers, etc... > > Ahh, scope creep... the end of simple ideas. Please accept my apologizes... > > Regards, > > Chuck > > -----Original Message----- > From: Matthew Gamble [mailto:[email protected]] > Sent: September-01-10 8:21 PM > To: Bruce N; asterisk Mailing > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
