and here is a snippet from the linux newsletter (which sadly will be
discontinued) from itworld.
[quote]
Whew. Now that we've gotten the background out of the way, here's the
worst thing about the situation: it's completely preventable. If you
follow paranoid procedures when setting up your machine, you would have
stopped this worm at several points and either avoid becoming infected
at all, or at least keep yourself from becoming part of the P2P network.
Let's take a look at generic security practices that could keep this
worm in check:
ServerTokens
Many worms check the Daemon's banner before attempting an exploit
in order to choose the best attack available. If you set the
Apache 'ServerTokens' configuration variable to 'ProductOnly'
then it will only broadcast 'Apache' and not the version and
installed modules. (For more info about this configuration
setting, see [6].)
SSLv2 Support
Most, if not all, Web browsers support SSLv3 now. This particular
vulnerability is in the SSLv2 code. If you'd turned off SSLv2,
you'd be safe even with buggy OpenSSL libraries.
Upgrades
You need to keep abreast of the security-related patches for your
system. Your distro may even have tools to automate this, such as
up2date on a Red Hat machine or 'apt-get update && apt-get upgrade'
in cron on a Debian machine. Upgrading buggy software means you're
not running buggy software. Hard to exploit something that isn't
broken....
Minimal Software Installations
The worm requires gcc to compile the .bugtraq.c file. If you
didn't install gcc, then the worm will fail before even if it
managed to break into your web server. Just as you'd turn off
a daemon you aren't using, why keep software installed that
you don't need? It only gives an attacker another tool that
can make the cracking easier.
Restrictive File Permissions
If you need to have gcc on your machine, put it in a special
group that can only be used by developers:
# groupadd devel
# chgrp devel `which gcc`
# chmod 750 `which gcc`
If you restrict the groups allowed to run your software, then
meta users like 'apache' and 'www-data' won't be able to use them.
Restrictive Mount Permissions
This worm uploads a file to /tmp, compiles it, and runs it. If
you mount /tmp with the 'noexec' flag (and 'nosuid' would be good
too) then even if the worm got this far, it wouldn't be able to
run the executable.
Paranoid Kernel Networking ACLs
If you've created rules that permit just the network traffic
you expect, then the P2P packets on UDP port 2002 would be
blocked. You should create rules that detail both inbound
(to prevent folks from contacting you) and outbound (to
prevent cracker processes on your machine from connecting
out) connections. You may only need outbound UDP 53 to
your DNS server, for example, and all other UDP packets
could be blocked. This would prevent you from being part of
the cracked P2P network, even if the exploit had gotten this
far.
So if you took these steps, which are not specific to this worm, you
would have been protected from this worm at multiple stages. Proactive
security would have saved the day.
[6] http://www.hackinglinuxexposed.com/articles/20020312.html
[/quote]
ciao!
Dennison Uy wrote:
>
> This is about a week old, but no one has posted it so far and someone
> posted it in another group so I'm just forwarding it.
> This only concerns those running Linux Apache with mod_ssl installed.
>
> Den
>
<snip>
--
"Programming, an artform that fights back."
=============================
Anuerin G. Diaz
Design Engineer
Millennium Software, Incorporated
2305 B West Tower, Philippines Stocks Exchange Center,
Exchange Road, Ortigas Center, Pasig City
Tel# 637-4634 loc. 75
Fax# 637-4679
Registered Linux User #246176
=============================
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
