I went to this meeting (but don't expect me to drive to San Jose during rush hour again....). It was mostly a summary of things known, useful to people who were just learning about DDOS. Here is my summary and interpretation of what caught my attention - if any of this is in error, please let me know. Overall, a disheartening prospect for the near future: There are no good tools to find either master or slave programs via net scanning. The on-host tool for Solaris works sometimes. An IDS system probably can catch the traces and even spot the infected machines, depending on the system. Extensive logging on routers can help, too. A good tool would be an enormous help if one could be developed. The worst aspect is the attacker is so many levels removed from the attack, it is very difficult to find him/her/them, and even harder to collect enough evidence to prosecute. So we are left with trying to find the compromised machines. With encryption in packets, variations in ports and protocols, and different types of master and client programs, finding useful characteristics to detect their presence is not easy. The best short term prospect seems to be education, primarily of ISPs. There are quite a few people and groups working on this, but there is also quite a bit of inertia to overcome. If we can establish a standard of practice, that puts pressure on ISPs to meet minimum standards just to avoid being found liable for future attacks they could have prevented. An attack on a system to compromise it can be begun and completed within 4 seconds, completely automated. Almost all compromised machines were attacked using known holes for which patches have been available. Based on his experience, one person said 10-15% of systems on the internet can be compromised this way. We can make it more difficult for attackers by patching our systems to current levels, but the voices of experience say many or most sites will not do this until they have to. One person stated that M$ patches are used by less than 2% of people who have M$ operating systems. An analogy was made to epidemiology - there are pools of water everywhere that breed disease-carrying mosquitos. If each person cleans up their own pool, the overall risk is enormously reduced; you don't have to persuade anyone else to cooperate. It is a start. Root access is not necessary to run the client processes, nor is a root kit. One of the methods is to create the client process and log out, leaving it running but without any files to betray its presence. If the process can be loaded into the Solaris kernel, it can be very difficult to find since few people have the knowledge to monitor the interior workings of the kernel. Commands between the various levels of the DDOS can be on the original ports of 31335, 27665, 27444, but they can also be imbedded in icmp reply packets or other normal traffic. The clients can test different spoofed IP addresses to determine which ones will work, and use those during an attack. If it has to use an IP address valid for its local subnet, participating in an attack may make it easy to find, but there is a nearly limitless supply of new hosts to subvert. It is so easy to create new clients that losing some is not important. The easiest thing to do is block spoofed IP addresses - this can save all sorts of grief. Many companies already do this for their internal systems at the firewall or border routers. But some ISPs claim that this creates too much load on the routers and don't want to do it. But which is more expensive, buying more powerful routers or losing your network for a few days? Recommendation: urge your ISP to filter outbound traffic, or think seriously about switching to another ISP. Several people suggested creating a blacklist similar to ORBS to blackhole all packets from domains that don't use rudimentary security precautions. There are many testimonials for ORBS as a cure for spam problems, so this could help. This would make finding the slave/client hosts easier, but do little for the masters, and less to stop the attackers. When under attack, a site can fairly easily determine the source of the packets hitting them, but to find any involved hosts beyond that requires the cooperation of several ISPs since this is DistributedDOS. Recommendation: set up a procedure with your ISP in advance to deal with this. It is not easy to do at 3 am. Urge them to do the same with other ISPs, or think seriously about switching to another ISP. This month I watched an attack in progress for seven (7) hours, coming from another ISP in the USA, and the security people there refused to communicate with me via phone or email, at the time or any time since, and I did try several times. With that attitude, I don't expect them to fix anything unless under severe legal or financial duress. For the long term (5-10 years), there are some possibilities that depend on better identification and authentication of hosts. Several people agreed that nothing much will happen until some major companies get hit, then they will agitate for whatever it takes to fix the internet to be safer for commerce and business communication. Even if it requires moving to IPsec6. Neil At 23:48 01/16/00 -0500, David Kennedy CISSP wrote: >The purpose of this message is to solicit participation in birds of a >feather (BOF) session to discuss the Distributed Denial of Service (DDOS) >problem. > >WHO: Everyone interested in aggressively addressing a category of attack >threatening Internet-connected systems. > >WHAT: We (ICSA.net ) are offering to put together at least two BOF's to >discuss DDOS attacks in the trin00, TFN, TNF2K, TFNTK, stacheldraht...family. > >WHEN & WHERE: The first BOF session will be Tuesday January 18, 2000 from >7 to 9 pm at Hyatt Saint Claire Hotel, Ballroom Lobby Level. Refreshments >will be served. This BOF session coincides with the RSA conference but >the BOF is located across the street from the Convention Center and is >open to all interested parties. > >The second BOF will coincide with the North American Network Operator's >Group conference (Feb 6-8, 2000 at the Doubletree Hotel, San Jose >CA). The date and precise location of the BOF are being determined. > >WHY: The goals are two-fold initially, awareness of the problem and see if >the collection of smarts at a BOF can suggest effective ways of dealing >with these attacks other than "hoping" the clue-challenged secure their >systems before the trojans are installed. > >relevant URL's: >http://www.rsasecurity.com/rsa2000/main.html >http://www.nanog.org/mtg-0002/ > >Tentative Agenda: > >Introduciton: >The Problem: > Technical Review of Attack tools > Trends/ Implications/ Characteristics > >Possble Mitigations: > Scanning for Master / Slaves > ISP Egress /Ingress Filtering > Potential Protocol Changes HIP > Open discussion > Next Steps > >Noteworthy Participants: > > Dave Dittrich > Steve Crocker > Paul Krumviede > Bob Moskowitz > Jon McCown > >Organizations that will participate include: > > MCI > ISS > Bindview > Security Focus > Secure Computing Corp Intrusion Services > IT Security Services > > >-- >Regards, > >Dave Kennedy CISSP >Director of Research Services, ICSA.net http://www.icsa.net >Protect what you connect. >Look both ways before crossing the Net.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:58:38 PDT