randulo wrote: > On Thu, Mar 26, 2009 at 2:38 PM, SIP <s...@arcdiv.com> wrote: > >> And so, in answer to your question, I don't think there ARE necessarily >> steps that can be taken right now to ensure that there's a rational >> approach to the resolution of such an issue of fraud. Barring some sort >> of major legal precedent, it's going to be anyone's guess how the >> verdict comes out in the end. >> > > Hence the need for all of us, everywhere to step up measures to > prevent as much as possible, the unlawful use of a system. Maybe some > kind of (optional modular) monitor or engine could be built for the > asterisk platform to at least send alerts when it deduces suspicious > activity? > > r > >
There are generally two approaches to this. Neither is necessarily 'correct,' but one is considerably less unwise. The first approach is the current approach: build software with little thought to how it will be secured, opting for all the work of securing the product once it's been implemented to come down to a requirement for the deployer to both know and, more importantly, understand good security practices. This has a value for enthusiasts because many of them will be running the service just in a home network or test environment, and it lets them get things up and running without worrying about all the little issues that might get in the way of a quickly-deployed system. It's essentially like choosing 'install everything' on a linux install and opting to have no firewall. It's wonderfully easy to deploy and there are no weird rules getting in the way of using the system immediately. It's also a really REALLY (I can't stress how strongly enough) bad idea if you're building a product that is deployed by more than just enthusiasts and will ever be in any remote way tied to someone's finances (including, but not limited to, telephone access charges, bandwidth fees, etc). The second approach is to build the product to be as secure as it can possibly be right out of the box, and require those deploying it to essentially remove levels of security in order to get things working in a particular environment. This also requires a certain knowledge of security practices, and it relies on those deploying the product to understand that the errors they may be seeing on deployment are likely to do with security feature X or Y. This takes time and a lot of work, because every component of the system has to be hardened and tested to ensure a seamless security model throughout without worries about incompatibilities in the basic security model between modules of a complex system. It also makes the system harder to deploy out of the box because it requires tailoring for the specific environment not just to handle a different user base, but also simply to work. I think there's a lot of push back on this sort of model for something like Asterisk because people feel that security should be this nebulous thing that exists 'somewhere else.' But in reality, security starts with the software itself and works outward. Just as you can't build a stable house on an unstable foundation, any weak link in the security chain is an invitation to disrupt the entire system with an exploit. And the weak link in MANY systems when it comes to security is the knowledge of the person deploying it. I believe a certain level of high grade security should certainly be built into Asterisk, and that it should have an overall security model, as well as documentation discussing the security of the system and the parameters that accompany it. Not only would this alleviate the concerns of many people deploying, but it would be excellent marketing. Have you seen the number of cars that advertise their side-impact air bags, safety rating, and other such features? Nothing will keep a person from killing himself in a car if he chooses not to wear a seatbelt and drive unsafely in heavy traffic. But if he's in a car without seatbelts? Or with a horrible crash test rating? Chances are he may end up getting hurt anyway. Even if he makes sure he drives carefully. -- Neil Fusillo CEO Infinideas, inc. http://www.ideasip.com _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users