I have a CentOS box that's been up for about a year. It's not got anything hugely important on it, and had a lot of PHP code that I cannot personally vouch for and is fairly old. I realise this is asking for trouble.

I did the things I'm aware of to harden SSH and restrict access via IPTables etc. Today I've noticed a lot of worrying files in /usr/bin/ and /bin/. Lots of what looks like duplicates of binaries, created over a period of a couple of months at the rate of 20 or so a day:

-rw-r--r-- 1 root root 47024 Aug 7 2011 chage;4e3f01f7
-rw-r--r-- 1 root root 47024 Aug 7 2011 chage;4e3f1007
-rw-r--r-- 1 root root 47024 Aug 8 2011 chage;4e3f1e17
-rw-r--r-- 1 root root 47024 Aug 8 2011 chage;4e3f2c27
-rw-r--r-- 1 root root 47024 Aug 8 2011 chage;4e3f3a38
-rw-r--r-- 1 root root 47024 Aug 8 2011 chage;4e3f4846

The other binaries with similar going on are - newgrp, gpasswd, lastlog, dig, usleep and doexec.

The last file date is 8th August so I don't have any logs going back that far. Is anyone able to help me in understanding what has gone on here?

The file you name are part of the initscripts, shadow-utils and bind-utils packages. Their %{BUILDTIME}s are well before the date you listed. Having duplicates created at the rate of "20 or so a day" sounds like a botched cron job to me. One can encounter "{name};{random_string}" names when RPM isn't able to move the old binary out of the way. Do these binaries incidentally have the immutable bit set?

Ah - this is making sense now, thanks. I did install Linux Environment Security initially, but it caused problems so I deactivated it. So, this would have set the immutable bit for these binaries and yum couldn't auto-update, thus creating these files - is that right?

That might be the case. Luckily LES has an undo function: best use that before you remove it.