Re: EMERGENCY - need to secure my server against an ongoing SPAMMER

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bob Brennan wrote:
The files in /var/spool/mqueue (and now also /var/spool/mqueue.spam)
begin with either "qf" or "df" (queue file or data file). There should
be one of each for each email. The rest of the filename is made up from
sendmail's queue tag for that message, which also appears in
/var/log/maillog.

I want to see what's in one of the "qf" files for one of the spam emails.


Those are the files I deleted in the last message exchange :-( in
order to stop all queud message from going out.

If you followed the instructions I gave, they'd be in /var/spool/mqueue.spam

Did you delete that directory too? There may have been non-spam messages there too.

Deleting this sort of stuff really is a bad idea because you've lost some evidence of what's happened. So you don't know if a machine your server trusts has been compromised, whether your server is a plain old open relay, or whether your server itself has been compromised or running a spam-vulnerable application. Without the evidence to reassure yourself that it's only vulnerable to spamming and your machine hasn't actually been rooted, you should assume the worst and do as Sam said - reinstall from scratch.

> I did however save the
first and last rejection which contains header information - the bad
new there (too) is that I saved them in a Squirrelmail folder and SM
is now not responding without MySql running, although I didn't realise
there was a dependency there(?).

Having examined the headers I noticed the emails were coming from a
(randomletters)@yahoo account and being sent to (randonletters)@yahoo
and hotmail. The large bulk were in the queue undeliverable but it
looks like at least a few hundred go through.

I need to see the full headers really. The addresses used are probably irrelevant because spammers just forge them anyway. The interesting thing to see is where the mail came from.


Try removing the lock file manually:

# rm /var/lock/subsys/mysqld

This is probably a symptom of the problem rather than being the problem
itself though.


I had already tried that trick - no difference, it just creates a new
file when I try to restart.
The error seems to be:
/usr/libexec/mysqld: Can't find file: './mysql/host.frm' (errno:13)
but I haven't tracked that one down yet

That file should be in /var/lib/mysql/mysql

You might have to recover it from your backups if it's no longer there.

Paul.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux