sendmail and spam HP-UX 11.0

[Fred Martin_1]

One day nearly all of our inboxes started getting blasted by spam, even inboxes for non-login accounts (bin,sys etc).

Also, user names for people that only use email internally are also getting spam. Not sure how these names got out of here. People who rarely use email, with names like "gte" are now getting spam from the outside.

I've attached my sendmail.cf file, in case there is a hole there. Have a look. I have attempted, correctly I hope, to set it up so that relaying is shut off, except for one network, the addressing we use internally. The only changes I have made to the file are noted at the top.

Any help would be appreciated.

[Fred Martin_1]

Actually I should say that I -think- the spam is coming from the outide. The sender addresses are forged I'm sure; some of the email claims to be from our own users which is a common ploy. How can I really tell who is the actual sender?

[Steven E. Protter]

For even more on this fun topic, visit http://www.sendmail.org

They have a really good book on sendmail that works just fine on HP boxes. You should use the instructions above to re-route root email to a regular user account. You don't want root user openning a something bad as superuser.

Steve

[Fred Martin_1]

I am posting to this topic again, as I still have the issue and would like to hear more for people.

It is obvious to me now that someone has access to my password file, alias file or at least the contents of /var/mail or /home - on a regular basis.

I created a new user. The guy has never logged in, never used mail. No one even knows his login name, and he is getting spam already within a few days.

Through my firewall I allow email. I allow telnet for certain logins only and review login report daily. I allow traffic such as ftp and http, if initiated from the inside. And I serve web pages from a web server inside.

Mail logs only show spam being delivered to nearly everybody inside; no relaying going on. Mail headers only show mail being delivered from (mostly) forged "From" addresses, to internal users. No outbound spam, no relays. No errors in mail log.

I am at a loss as to how I discover how it is that my user list is immediately available in this way, even before outlook users are aware of the logins, etc.

I am running NAV on all internal PC hosts. I don't have any indication that a virus inside is passing the list to a spam generator.

Stumped.

[Christopher Caldwell]

Post a reasonable snip (10 or so entries) of your mail.log that shows the spam.

[Shannon Petry]

There is a very good third party product, which is not free. PerlMX (I think it's now called "activestate") is a plugin to Sendmail which is absolutely awsome. It allows you to setup rules for everything.

http://www.activestate.com/

Regards,
Shannon

[Fred Martin_1]

Attached is about 20 lines, I took the liberty of grouping the lines by sendmail ID number.

Note the non-deliverable mail - I have some users aliased to a non-existent user 'nomail' because they are no-mail accounts.

Spam is still sent to them, then bounced back and fails at the other end because the return address is bogus. Then my server gets that return.

Of interest I think, some of the mail is being sent to fully qualified addressees - and some to unqualified local users. See ID number LAA05028.

[Steven E. Protter]

/etc/aliases should be updated to provide proper mail routing. Make sure root mail goes to a regular user.

The way things should work is that mail won't be accepted or relayed for users not specifically laid out in /etc/aliases. That is how it works with Red Hat. I'm more an HP-Ux guy, but accepting mail for an entire domain is not an option based on the volume spammers flood us with nowadays.

You can add some spam rejection logic for specific senders that will bounce messages. On the sendmail.org link is a cookbook to getting the spam sender blacklist and rejecting all mail on that blacklist.


You need to look at the headers for some of your message senders and start blocking their mail. If necessary, trace the hop path and block the IP addresses actually relaying the mail.

Its fun reading and you see mail with from sender at aol or yahoo actually doing smtp relay off their cable modem. Block the cable modem and the mail stops coming. A report to the ISP can also help.

In /etc/mail/access

Fred@fouryourmarriage.net 550 Spam reject. We charge $500/spam message.

This is a hast databse. You can put domains or IP addresses in there. I'll attach a script that lets you rebuild hast databases as well.

in sendmail.mc there are directives that let you open up or close mail by ip address.

Here they are.
DAEMON_OPTIONS(`Port=smtp,Addr=66.92.143.197, Name=MTA')

This explicitly allows mail for the domain I have sitting on the above IP address to come in. Any non-listed IP addresse buzz, thank you for playing all the mail gets bounced.

buildmail attachment is a linux script that rebuilds the hash db, and generates a sendmail.cf file that takes all these directives into account.

It can be adapted to HP-UX, I've gotten it to work.

Then standard configuration on the HP-UX sendmail.cf generator script(prior post) does not allow relay.

If you take time and track where the mail is actually coming from, you can cut these guys off. If they send a million messages at your HP-UX box, they get a million messages back. Coolness.

The mail messages should contain good header data. Just because it seems to be forged doesn't mean there is useful data out there.

Red Hat has a doc that shows how to integrate the spam blacklist directives into sendmail.mc I think it can provide a starting point for HP-UX

P

[Jordan Bean]

Whether or not superuser access has been compromised, please review the following.

Look for .forward files that invoke harvesting scripts.

The spammer may be harvesting user names on a regular basis. Check the cron log (/var/adm/cron/log) for suspicious activity. Do restrict who can use cron by editing the cron.allow/deny and at.allow/deny files in the same location. Also, obliterate all unauthorized crontab files in /var/spool/cron/crontabs.

Have you changed the root password and restricted the account to console login only? (Make sure /etc/securetty only has the word "console" in it.)

Make sure no one else can su to the root account by defining SU_ROOT_GROUP=adm (or any group of users for whom you will authorize such access). (Think about using sudo.)

If you're using SSH, you should consider restricting root access there too... If root access is desired through SSH, then make sure that it doesn't have an unauthorized public key defined. Also, change the passwords on all other keys.

Have a close look at your FTP service... Disable anonymous access unless you need it and also remove any suspicious SITE EXEC scripts. Check the xferlog for all activity.

If the box isn't necessarily protected by a firewall, then do check for unwanted network services in /etc/inetd.conf that may return user lists upon connection.

The spammer, if clever, may also have setup bootup harvesters if root access was compromised. So check /etc/inittab and /etc/rc.log.

There's much more to worry about, but let's start here.

[Fred Martin_1]

I will check those things. It may take a while but I will post here again with any findings. Meantime if anyone else wants to comment I'd appreciate it.

[Christopher Caldwell]

Looks like you're being "explored". Remote SMTP is trying varying addresses that don't work. Sometimes the addresses do work. They're probably using some kind of dictionary.

To fix this problem, there's a few things you can do:

Use virtusertable with a terminating
@mydomain.com error:nouser No such user

This technique will outright reject any mail delivered to your system that doesn't have a valid recipient.

Consider using sendmail 8.11 or >. Use the RBL rulesets to limit spam.

Make sure the spam rulesets are in effect.

Consider rejecting mail from hosts or senders with domains that won't resolve (should be a temp failure).

Consider rejecting mail delivered to your host via SMTP that doesn't have a fully qualified recipient.

If you need help with particular implementations, let us know.

[Steven E. Protter]

Sounds like security is a question.

Get the Bastille security hardening tool and use it.

Of particular interest to you is disabling the ability to validate users via sendmail. That's the hole I'd use if I wanted to get around the other stuff I reocmmended above.

link:
https://payment.ecommerce.hp.com/cgi-bin/swdepot_parser.cgi/cgi/try.pl?productNumber=B6849AA&date=

P

[Jordan Bean]

I forgot to mention disabling the expn and vrfy SMTP commands by setting the privacy options in sendmail.cf this way:

# privacy flags
O PrivacyOptions = authwarnings, novrfy, noexpn, restrictqrun

[Vincent Fleming]

Having similar problems in my home UNIX box email system, I have a couple of suggestions for you.

First off, the use of the access database works pretty well for me... I'm in the US and correspond with no one overseas, so I wrote a simple shell script to eliminate all domains that end in 2 letters (your log showed xxx.xx.br as a source hostname). For example, my access database has these names blocked:

aa
ab
ac
ad
ae

etc. to zx, zy, and zz.

This eliminates 90% of all the spam I get.

My second suggestion is to look into the MAPS database. See the sendmail documentation or search the web for MAPS RBL. The MAPS RBL is a Realtime BlackList... it's updated daily with spammers' addresses. It's free to individuals, and not real expensive for corporations.

Good luck!

Vince