Boris Lorenz wrote:
Hi,
On 01-Oct-01 Laurie Brown wrote:
Hi,
I'm using SuSE 6.4, running sendmail 8.9.3-105, on an internet-facing server.
[SNIP]
The IP address 202.99.48.42 is in the apnic range of addresses.
the URL placed in the body (?) of this mail (www.okoo.net) also resolves to 202.99.48.42, whis seems to be a combined nameserver and mail hub . The net 202.99.48.0 - 202.99.48.255 belongs to a Chinese ISP with the name Beijing Chang Jie Communication, and the IP in question is owned by:
[SNIP] Thanks. I'll block that whole subnet at the firewall... [SNIP]
The email seemed to come from a valid email address. The valid email address is in /etc/mail/virtuser on the server. The "From:" part is a direct copy of the description string from /etc/passwd which directly relates to the account pointed to for that email address in /etc/mail/virtuser on the server.
Hmm... The description in /etc/passwd may contain the name and/or job description of the user. If you write mail via console, the description will always be attached to the From: line (like "From: Boris Lorenz
).
I have never used that account at CLI to send email, it has no shell access to the server. Mail to and from the username concerned is done remotely using POP3 and the relevant ISP's server as a relay.
The email was relayed using the mail server in question, on which these files and account reside, but the incoming IP address does not match the DNS record for that domain/machine.
If you refer to the mail logs of the incident printed below I cannot see where there's a non-matching IP; it says relay=[202.99.48.42], which is correct given the mail header shown above.
I think we're at cross-purposes here: I regularly receive emails from other people with full headers and so on. What is different about this one is that it has no headers other than those from my own server, it appears to come from my own email address yet has an IP address which is nothing to do with me. Further, the subject of the email contained the very string from the /etc/passwd file which relates to the POP box on the server, not the username. The only link between the pop box and the username is the virtuser db. If the mail had followed the usual route, it would have headers and such like, even with a spoofed email address (which often happens).
How did they map the email address to the /etc/mail/virtuser file to find the POP account, and then how did they extract the right decription string from /etc/passwd as the mail subject? The POP accounts, BTW, have a shell of /etc/passwd and nothing else, but there are no signs of an attempted login anyway.
? "They" did not map anything IMO. If you use the virtusertable which maps incoming mail addresses to different local/remote accounts, it will be used automagically anytime by sendmail as soon as mail arrives.
Sure, but how in this case? It appears that the email originated on my own box, not from outside. I have never received an email where the subject come from my own /etc/passwd file for a non-privileged user with no shell access. How can a remote IP send me an email which appears to come from my own email address, using my own sendmail server, pulling the description text from the /etc/passwd file of an account which is only linked to my email adress via the virtuser db? I have relaying and suchlike blocked/allowed using the access db. I am confused!
Btw., there are large databases of email addresses from all over the world, who can be bought/leased by direct marketeers (read: spammers) to have a good basis for sending around their ads. It's not uncommon to get on these lists.
I know! I'm on enough of them! Thank goodness for the access db file! [SNIP]
Well... The whole thing reeks of spam, with a non-Western ISO code. There are some ways for an attacker (particularly via .forward files) to get hold of
No .forward files are in place... The /home/username directory is empty.
files like /etc/passwd or /etc/shadow, but such mails would not show up on the account which had been used to illegally obtain the passwd or shadow, at least this would not be plausible since the admin (you) would be informed right away that there's something wrong.
Nothing found, no evidence whatsoever.
Do you have any other logs/IDS to back up the incident?
Nothing shows, I've been through the lot. Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com PGP key at http://pgpkeys.mit.edu:11371 ---------------------------------------------------------------------