Severe problems.

[ircman]

I have several problems regarding apache and exim with Da.

First problem:
Due to a problem with phpbb this machine was hacked and some scripts where run. One of those scripts is still executed by cron.
/var/log/cron:
Jun 10 16:56:00 cobra CROND[1940]: (apache) CMD (/usr/local/directadmin/customapache/curl-7.12.2/src/macos/src/.psy/y2kupdate >/dev/null 2>&1)

I already remove the whole dir etc. but cron is still executing this command and I have no idea where to look.

Second problem:
All email send to root@hostname and apache@hostname (also regarding cron) are forwarded to a customer email account with a totally different domain.

Third problem:
arround 35% of my customers get an error 550 authentication error when sending email via mail.domain as smtp server. And I do not see any error messages in the log files of exim.

Fourth problem:
When making a user backup, Da does not check how much space is left on the harddisk. So 2 days ago while making a backup DA crashed with diskspace 100% used.

 

[nobaloney]

First problem...

Generally, once a system has been hacked, you can never trust it again; it should be rebuilt.

Some of us are good at finding hacks and may choose to fix them rather than rebuild, but I'm usually unwilling to accept that route.

Now to be more specific, how do you know if the cronjob is being executed or not? If the programs it calls are being executed or not?

/var/log/cron only shows what cron runs, not what happens as a result of that run.

email output is generally sent to the user that's running the cron job. So you have to find out where the cronjob resides.

Perhaps that's why your root email is redirected.

And...

if you delete a file (even a directory of files) as root, while the file is open, it's not actually deleted from the server until it's closed. The only way to make sure a file added as a result of a hack is closed, is to reboot the server. Have you done that?

Now on to the second problem:

This is mot likely part of the hack. So you really haven't found all of it.

The third problem:

If you don't see anything in the exim log files yet they're getting an error it's reasonably likely their ISP(s) is (are) blocking port 25 email or redirecting it to their own servers. Most ISPs do that now.

The fourth problem:

I haven't tested for this; you might want to write to DA support staff.

Jeff

 

[ircman]

First problem...

Well i have rebooted the server and cron still executes a file that does not exist (several files). I have scanned the whole machine for strange files etc. but I did not find anything.
The strange thing is that the files listed below are still trying to execute, but generate an error on apache@domain because it cannot locate the file to execute in the cron.

/var/log/cron:

Jun 11 16:30:00 cobra CROND[11479]: (apache) CMD (/home/dnrh/domains/dnrhardware.nl/public_html/modules/PNphpBB2/files/.bitz//iWanZ.botchk)

Jun 11 16:30:00 cobra CROND[11485]: (apache) CMD (/usr/local/directadmin/customapache/curl-7.12.2/src/macos/src/.stelk//Were^Wolf.botchk)

Jun 11 16:30:00 cobra CROND[11489]: (apache) CMD (/usr/local/directadmin/customapache/curl-7.12.2/src/macos/src/.psy/y2kupdate >/dev/null 2>&1)

Cron generates a lot of email for root@ and apache@ cos the files where executed as user apache.

And the customer who is receiving the root@ and apache@ email did not execute those programs.

Third problem:

Well it is strange because the users did not have any problems before the server rebooted (due to the full diskspace of the backup problem). The user receiving apache@ and root@ only received these mails yesterday and the day before. And I know for sure that their ISP is not blocking/redirecting port 25 traffic.

Tnx for your help so far

 

[ballyn]

The cronjobs are probably in apache's crontab... as root:

crontab -e -u apache

No idea why those messages would be forwarded to a different domain, though. You'd have to get into the exim logs and the domainowner/forwarder stuff.

 

[nobaloney]

I thought I'd add that if a server is compromised by a rogue Linux Kernel Module then it's possible anything can run without you seeing it, as the Kernel itself is then compromised.

I'm not saying that's what's happened, only that if it did happen this could be one of the symptoms.

Jeff

 

[ircman]

Well most of the problems are now solved.

Only the question why a normal user did receive all the root@ and apache@ mails is not clear to me.

But I have fixed the rest of the problems after a few hours work .


Tnxx for the great help!.