Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Zombie plague sweeps the internet

In comp.os.linux.advocacy, bbgruff
<bbgruff@xxxxxxxxxxx>
 wrote
on Thu, 04 Sep 2008 23:40:12 +0100
<6ib6e9Fps1jcU1@xxxxxxxxxxxxxxxxxx>:
> Oh dear - I do hope that you Linux loonies aren't responsible for this....

We are.  Or hasn't that occurred to anyone?

The logic is as follows.

[1] Linux is a competitor to Windows.

[2] Therefore, Linux is a *threat* to Windows.

[3] Therefore, anyone who threatens Windows (e.g., by compromising
    systems upon which it is installed) is doing so because of
    Linux.

[4] Therefore, it's Linux's fault.

[5] Therefore, anyone using Linux is at fault.

Next. ;-)

(Yeah, the logic's similar to Hans Reiser's conviction,
and probably about as valid -- in other words, not very.
But that's never deterred the Wintrools before...)

>
> "The summer saw a surge in the number of hijacked home PCs or "zombies", say
> security experts"
>
> "The Shadowserver Foundation, which tracks zombie numbers worldwide, said it
> had seen at least a threefold increase in the last three months"
>
> Ah!  .... but wait!
> We got the BBC to highlight the real culprits, remember?
> It goes on:-
>
> "The vast majority of machines in these botnets will be PCs running a version
> of Microsoft *Windows* "!
>
> - so maybe you guys are off the hook?

Not likely.  After all, one good compromised IIS/6 or Apache
server on an OC-768 connection blows the world to hell....or
at least a small corner thereof.

And Apache does have occasional security vulnerabilities, though
compared to IE they're rather rare.  The best Google can do is
identify an issue with a WebLogic plugin.

https://support.bea.com/application_content/product_portlets/securityadvisories/2793.html

One can also look at

http://httpd.apache.org/security/vulnerabilities_22.html
http://httpd.apache.org/security/vulnerabilities_20.html
http://httpd.apache.org/security/vulnerabilities_13.html
(2.3 and 2.4 are either somewhere else or haven't been created yet).

http://tomcat.apache.org/security-jk.html
lists security vulnerabilities related to the Tomcat JK connector.

> ... - or are you?  After all, it's A Well Known Fact that only 3 people in the
> world use Linux (me, you, and Linus), so it's small consolation that we
> only "contribute" between 0 and 3 machines to this, is it?
>
> (Somebody tell me where they get the 450,000 from?  It that actually "active
> at any one time", I wonder?)
>
> http://news.bbc.co.uk/1/hi/technology/7596676.stm
>   

If a zombot is throwing things on its uplink, it's limited
by the bandwidth available thereto; this is typically
128kb per subscription, on the consumer level.

Zombots can also spam to multiple accounts (comma-delimited
list in the To: field, after all), so the bandwidth is
shifted upwind.  Assuming it's not, though, the zombot
can only post 1 message every 2 seconds or so, assuming
a 20kB message.

This also gives us an estimated attack bandwidth (zombots
*cannot* shift *this* upwind if they attack directly);
the maximum possible is 450,000 * 128 kb/s  = 57.6 Gb/s.
That will definitely soak up one OC-768 (39.81312 Gb/s)
and part of a second, but that's about it -- though it
depends on how brain-dead the server is; if each request
pegs the CPU for a second those 450,000 requests will take
more than 5 days to process, even though they'll take a
few milliseconds to generate.

Any good webserver will be distributed anyway.

As for active...good question.  My admittedly very limited
understanding of zombots is that, once created, they try to
attach to a server for further instructions; this server is
by necessity either high-bandwidth or widely distributed.
Once the zombot gets its marching orders, it probably spins
off a thread to bombard the target, becoming unavailable
for a certain duration until it decides to stop.

-- 
#191, ewill3@xxxxxxxxxxxxx
Useless C/C++ Programming Idea #104392:
for(int i = 0; i < 1000000; i++) sleep(0);
** Posted from http://www.teranews.com **

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index