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]
