Awesome... Might also be a "nice feature" to maintain country subnet lists... so I could subscribe to "Ban China"... now if only we could get down to a municipal level... I'm dying for a "Ban North York" option...
...bloody North Yorkers... -----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]
