Re: Announce: BOF on Distributed DoS, San Jose 1/18/00

[Neil Ratzlaff <neil.ratzlaff () ucop edu>]

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.