Panic Button, open trouble notification channel: Attack Defender The appropriate place to suggest this solution was at the NANOG meeting on DDOS but I didn't think of it before then so I thought that a posting to bugtraq may float this proposal for public discussion. The term ISP is used below to refer to any network service provider responsible for connecting end user systems or servers to the net. The problem with DDOS: - It is infeasible to secure the entire net. - Scanners for DDOS daemons are being built but still require efforts from uniterested parties to run the scans. Frequency of scanning will be an issue too. - The attackers are often systems that are unattended or neglected as far as security. This makes it even harder to reach someone at the site to stop the attack. - The ones who are motivated to do something about DDOS are the victims not the attack relays. - The ISPs are also greatly motivated to ensure that their services are not disrupted. - The problem with disabling the attack is that the victim has to contact many, many systems to notify them that they have been breached and convince the administrators and take measures agains the attacker software now embedded in their system. As this is an industry wide issue, it is doubtful a single source commercial antidote to all the potential DDOS problems can be found with a single countermeasure. So I propose a collaboration between service providers - an Anti-ddos ISP Coalition to remedy the problem. The key issue I as I see it is one of notification, how do you notify all the attackers that their systems are being detrimental to the net. I suggest that we move the onus of solution to their service providers. It has already been suggested that the ISPs that connect the attacker-relays to the net may be culpable or liable for damages... so they should be willing to expend some effort to resolve the issue. There is already a push to educate about putting in proper address filtering into provider routers, but this is not the full solution because it will only hinder DDOS attacks based on spoofed traffic. At dursec we have been testing DDOS effects for the last 8 months, and we've researched many DDOS techniques that do not require spoofing, so address filters will not be a panacea solution. One of the solutions we've been bandying about is some sort of Emergency Broadcast Network like solution that would facilitate communication during attacks or outages amongst service providers. We would like to propose that an open-source, peer reviewed attack notification system like this be developed. It would work like this: - Each ISP(AS) that has an IP address block allocated to it would maintain a publicly listed attack/outage notification point. - call it the Attack Defender daemon. By my estimate and materials published by Boardwatch there are less than 15,000 ISPs in the world so keeping/distributing a central contact table listing address blocks and contact would be feasible (similar to whois). - Free client software would be distributed to the participating (hopefully all) ISPs customers. This client software would essentially be a red panic button for victims of a DDOS attack. When activated it would use some sort of strong crypto authentication and notify your local service provider's Attack Defender that an attack is in progress. The notice would contain a small description of the attack and a list of attack sources gathered by promiscuous sniffing by the Defender client as well as a contact e-mail for the attack victim. The client could also log traffic stats for future forensic verification/tracing of the attack. Varous levels of automation are possible. -When an ISP customer triggers the Attack Defender panic button, and notifies his service providers' Defender daemon, it will in turn contact/notify the other well-known and publicly listed Defender contact addresses of the ISPs/ASs/Owners of the address blocks that a victim ISP's customer has filed a complaint about attacks coming from their nets. That notification will contain the offending source address(es) and contact info for the victim and their ISPs technical support for subsequent verification. -When the incoming complaints from other Defenders reach some configurable(and likely site dependent) threshold level, the AS's Defender will notify/alarm the attack origin ISPs technical support crew, who would supposedly have contact information for the client nodes that are doing the attacking. They could then notify, with whatever strength of wording (:-) they feel is appropriate, their customers that they must take additional security precautions and hopefully provide assistance. There are numerous inherent DoS opportunities in such a system so great care needs to be taken care beween Defenders to use strong authentication. In addition, guidelines should be drafted so no draconian penalties are imposed on clients that have potentially spurious complaints filed against them. I would suggest that no action be taken until mutliple complaints are filed, and then some sort of attack verification process with the victim be used before attack relays are notified/penalized. Systems that are repeatedly/consistently used as attackers could be filtered/disabled/penalized until approriate security improvements are demonstrated to their ISP - thus providing the motivation for the attack relays to care about the damage they are doing and to spend the effort on better security. -To stop this system from being used as a DoS itself, I would propose that some sort of fine or other financial penalty be imposed for false or improper complaints being filed (like the fines for pulling a fire alarm). Obviously, the coding work of developing such a system is trivial, but the problems are all political and administrative. If this idea is met with positive reception, I would even commit to developing the open source software consortium here - I'm pretty sure we could have it whipped up by next week - but the question really goes back out to the technical planners at service providers: Would they would deploy and take the appropriate measures to make such a system work. The barriers on this are all political not technical. I could start a mailing list to discuss this solution at defenderat_private if there is sufficient interest and I would urge all interested parties to participate. Feedback solicited either here or via mail.... Is this idea feasible? Goofy? Realistic? cheers, --drat_private -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - April 19-21 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD, Max Vision/whitehats.com
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:34:24 PDT