[lug] Attempted hack from 126.96.36.199
nate at natetech.com
Tue Apr 23 00:55:34 MDT 2002
On Mon, 2002-04-22 at 22:04, Daniel Webb wrote:
> The exploit was known, but
> without buying Redhat's update service, there was no practical way for me
> to know about it. I searched their errata site and filed a bug report
> because it was not there. Needless to say that gave me a bad taste in my
> mouth regarding Redhat. The UnixOps guys that helped me track down the
> problem said that basically everyone on the CU campus running Redhat has
> been hacked at one time or another.
Your first lesson in finding alternate, accurate information sources. A
very useful life-long tool, in the computer profession.
There are PLENTY of free resources which would have informed you of
RedHat updates available as they were released, and you should look for
them and use them.
There are also plenty of free resources that perform automated updates
for RedHat systems, or you can always subscribe to KRUD (since someone
will point that out anyway) and have a great RedHat distro that's
patched and has lots of neat-o toys packaged in also.
> No doubt I can still be hacked, but at least it won't be from a six month
> old remote exploit that was long ago fixed.
RedHat also gives anyone one free subscription to their RedHat Network
service now for one machine. You do have to register, but I haven't
seen them selling the list to spammers or anything like that.
They have modified their server and client code to "lock out" the free
subscribers when server load is extra heavy, thus not affecting their
paying customers adversely and the non-paying customers typically only
have to wait a few hours before they can try again successfully to get
Works pretty well.
I personally like the command-line tools for up2date when I've used
it... much cleaner (and more apt-like? GRIN) than the GUI.
For those who want to try it out... on a text console...
up2date --configure (the defaults are sane - anything other than the
kernel that has a packet update, do it... I've successfully updated
kernels with it also, and haven't had problems but you're using the
generic RH kernel which may or may not apply to your situation)
Oh... and if you have GPG package checks and signing turned on it asks
you to import and verify the GPG key and import it into your local
public keyring on the last step the first time up -- then it uses it
from there automatically each time.
The real power of the system is the web interface and the fact that the
system uses https to talk to the servers and get packages... most
firewall rulebases are already set up to allow outbound https from just
about any machine on a private network, and the web interface is
fascinating... click on your machine to see hardware information,
packages installed, errata that apply to your particular install, or
even schedule an automated update for later on. rhnsd is the daemon
that once in a while (I think configurable, but default is an hour or
two?) goes out with https and queries the RH Network servers to see if
you've scheduled anything like package updates. If you have, it fires
them off locally... all client-pull stuff. RH is also working on
proxies specifically built to proxy RHN for large organizations.
Worth checking into if you waste a lot of time patching a lot of RH
Nate Duehr, nate at natetech.com
More information about the LUG