Zachary Uram wrote:
>
> On Thu, 7 Jun 2001, Paul D. Robertson wrote:
> >
> > It really isn't that big of a deal, there are already enough trojaned
> > Win9x clients out there that even using real addresses doesn't make it
> > easy to stop them.
>
> Hi Paul,
Zachary,
Since you sent this to the list and I've got some strong opinions in
this area I'm going to risk poor list etiquette, jump in here, and
offer my $0.02 worth :)
> So is DDoS attacks biggest security threat out there?
> It seems to be a big problem. Especially for e-commerce and data
> warehousing/management systems where uptime = $$.
While the DDOS attacks are very visible and interrupt operations,
I don't believe they're the biggest security threat. They are
however, a side effect of it.
Those zombies are running on privately owned computers that are under
the complete control of the person or persons who broke into them or
at least under the control of the code they managed to place on
those computers. That, to me, is much more significant then the
present DDOS manifestations of the problem. If there are thousands of
zombies, there are thousands of compromised computers and potentially
thousands of compromised email accounts, private data, and all manner
of resources on and accessed from those computers.
> So no one has developed effective countermeasures against
> arbitrary DDoS attacks? I guess if there was a large enough
> concerted attack that some group could even overload an entire
> ISP or an Internet backbone? Do we need laws to give law
> enforcement/ISPs more power to solve this.
I may be mistaken but I believe the telephone network is able
to trace calls relatively quickly compared to the Internet.
This might be because of its circuit switched nature, because
of the signaling support that stresses management over
privacy, or a combination of both. For the attacks to be
traced quickly, similar functionality would be required in
the Internet.
However, that doesn't rid us of the problem that the source of
the damaging packets are compromised machines. Those machines
could have been compromised weeks or months before and the attacks
can be triggered by a post to a newsgroup, an IRC channel, or a
packet from a long string of other compromised machines. Without a
very large history of traffic, some stupidity on the part of the
initiators, and/or quite a bit of luck, law enforcement is limited
in what it can do to catch the actual perpetrators. (I don't think
I'm giving away anything here with the advent of viruses that
morph from newsgroups, IRC BOTS, three tier DDOS networks, and the
sophisticated remote control trojans that are circulating.)
And besides, while providing the capability to trace hundreds of
zombies certainly improves the situation, it isn't something
that any provider of services is likely going to want to have to
do on a regular basis. Even after they trace the source, they
still have to get them turned off. It all adds up to a time
consuming chore.
That leaves us with fixing the compromised computers.
Sure, a vendor can create a "secure OS". But personally, I don't
believe a secure OS will sell in the mass market. Then some other
vendor will step in to provide ease of use, freedom, and functionality
that started the personal computer industry in the first place.
Don't want the OS to run hostile code? Then you either design
the device so the code won't run on it (i.e. a ROM based browser
terminal or game console) or restrict unsigned code on general
purpose platforms. A lot of commercial software developers, server
manufacturers, and bandwidth providers may like the these solutions
as the former returns us to a terminal/mainframe environment and the
latter will cut down on free software competition. Of course, we lose
the present ability to download utilities, cutting edge applications,
and other useful programs at will as we've been accustomed on
our general purpose computers. Will people willingly give that
up?
ISP filters that do more than prevent spoofed packets would have
similar effects on functionality. Networks were made to communicate.
Let them do that. Fix the problem...the compromised computers
and/or the people making those computers communicate in destructive
ways.
We can continue to add firewalls, file integrity checkers,
discretionary access controls, privileged accounts, etc.
to consumer computers but they're starting to look an awful
lot like those glass room computers of yesteryear with their
need for trained system administrators. Joe User, who wants
to browse the web, download music, and get email at the
push of the button after a plug-n-play installation, does
not want this and will not buy it. Well, maybe they'll buy
it but the vast majority won't maintain it.
Of course, desktops aren't the only ones being compromised.
We've seen compromised servers at Microsoft leak source code.
We've seen compromised servers at an ISP lead to compromised
servers at Sourceforge and Apache. We see daily web defacements
and each one is a potential DDOS zombie or exposure of whatever
data and access is on that web server.
Secure the server? In most cases the vendor did secure it...
with patches that weren't installed which resulted in the
break-in. In other cases, one insecure sever led to the compromise
of others. Guarantee the security of code before its release? After
years of examination, security bugs are still announced for
oft examined, and security minded code like Kerberos and OpenBSD.
We've got to stop expecting virtual memory, multi-tasking, world-wide
networked, general purpose computers to be toys or simple consumer
devices.
We either have a simple, less functional, more secure device or
we accept the complexity and resultant need for maintenance
and training of a more complex, more functional, general purpose
device.
Marketing hype and a GUI doesn't make something that has 25 manuals,
thousands of configuration options, and 20,000,000 lines of code as
simple as a VCR.
What might this mean?
http://falcon.jmu.edu/~flynngn/whatnext.htm
--
Gary Flynn
Security Engineer - Technical Services
James Madison University
Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/info-security/engineering/runsafe.shtml
S/MIME Cryptographic Signature
