sendmail - attacked???

[Peter Gillis]

Hi,
ux11.11v1
sendmail 8.11.1 rev 1.6.

I have come across thsees messages in the mail log:
Nov 23 19:22:55 xxxxxx sendmail[12254]: iAN8LeY12254: [xyz.x.xyz.xyz]: HELO/EHLO
attack?
Nov 23 19:22:56 xxxxx sendmail[12254]: iAN8LeY12254: [xyz.x.xyz.xyz]: VRFY : [r
ejected]
Nov 23 19:22:10 xxxxx sendmail[12259]: iAN8MAR12259: ruleset=check_mail, arg1=<
user@SGTAUDITCOMM2>, relay=[xyz.x.xyz.xyz], reject=501 5.1.8 Domain of sender ad
dress user@SGTAUDITCOMM2 does not exist


My question is basically:
have we broken into? Is someone getting a connection but unable to do anything?
Any feedback would be greatly appreciated.
points flying...
Maria

[Michael Tully]

Hi Maria,

Before I get into specifics, is the system in a DMZ, has sendmail running as a server?

If you only need to send mail from the server, there is no need to even have the service running, meaning the sendmail daemon can be switched off.

Someone is attempting by the look of it, to speak through port 25.

Regards
Michael

[Geoff Wild · Accepted solution]

I take it this server is connected to the internet - and not behind a firewall?

I would install:

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6849AA

In particular, the ipfilter component - then block that ip address...

I don't think they are in - but get bastille up and running asap...

Is system trusted? If not, then at the very least install shadow passwords:

http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword

Rgds...Geoff

[Sridhar Bhaskarla]

Hi Maria,

Looks like someone did. I don't think anyone broke into your system though. Make sure it is not run by your corporate security or anyonelse that does auditing of your systems. 'sendmail' has been having issues and if it is not patched to the latest, buffer flows could allow the remote user to gain a root shell.

-Sri

[Steven E. Protter]

To fully answer that question, I'd need to know the answer to a few questions:

1) What is the server location vis a vis the Internet?

2) Does it have exposure via firewall or direct connection?

3) Are here suspicious entries on the /var/adm/syslog/syslog.log file

4) Is the domain displayed in the file a domain hosted anywhere in your organization?

5) Do you have a web server on this box with sendmail scripted cgi forms?

If the answer to these questions is what I expect, there is some possibility that someone has tried a sendmail exploit on you.

The general intention of such an exploit is to use your server to relay spam email, thereby blaming you for the problem.

As it ships, sendmnail is not a secure product. It can be made secure with the use of a macro database and parameters to make it impossible for someone to relay spam.

Most important in this process is to have the /etc/mail/access file completely disallow RELAY from servers that should not, ie outside your organization. It is possible btw that the mail source is an infected computer inside your organization that is allowed to relay.

To start doing sendmail macro database programming a script is needed. I wrote one and here is a link to it:

http://www.hpux.ws/buildmail.hpux.text

To change the access entries, you need to compile a sendmail.cf file that is secure.

If you have sendmail forms you need to secure them. If you do have sendmail cgi forms I will teach you how to secure them.

I have been through this and can help.

SEP

[Michael Tully]

I would not think they have attacked your system, perhaps attempting to. The 'HELO' is an attempt to speak through smtp (port 25). See my example below.

# telnet dev1 smtp
Trying...
Connected to dev1.
Escape character is '^]'.
220 dev1.domain.com.au ESMTP Sendmail 8.9.3 (PHNE_28810)/8.9.3; Wed, 24 Nov 2004 14:39:50 +1100 (EDT)
HELO domain.com.au
250 dev1.metcash.com Hello root@prd1 [xx.xx.xx.xx], pleased to meet you
MAIL FROM: tiger.woods@golf.com
250 tiger.woods@golf.com... Sender ok
RCPT TO: michael.tully@domain.com
550 michael.tully@domain.com... Relaying denied

Maria, Do you really need the sendmail daemon running?

[Peter Gillis]

Thanks for reply.
sendmail is running as a daemon.
We have ipfilter here, and I have configd so that outside our domains cant access. But, we have auditors within our domain and they are seeing just what they can do. I need some help in understanding what is being left in the log.
You mentioned, if we only send mail from this server then we do not need sendmail running. Would that also mean that for eg. root would not receive mail notification of jobs ending on the system, ofr is taht handled different because it is classed as 'local'??
thanks
Maria

[Sridhar Bhaskarla]

Hi Maria,

No problem for the local mails. You don't need to have sendmail running to receive mails due to cronjob failures or EMS notifications that generate on that system itself.

If you are planning to send mails out, you don't need sendmail running as a daemon. However, it is a good idea to keep a cronjob that runs sendmail in delivering mode once say 5 minutes to 'flush' out any mail that is pending in the queue. 'sendmail -q' will do it.

-Sri

[Michael Tully]

Having sendmail turned off does not effect local mail on the system. It will still send mail out to your mail exchange server. To get rid of mail that won't deliver you could use the 'sendmail -q' periodically.
The sendmail man page can tell you a bit more on this.
I have not got sendmail turned on any server, just in case, why ... because we don't need it.

[Steven E. Protter]

The best reference on sendmail configuration is http://www.sendmail.org

If filter needs to block all inbound port 25 connections, so long as this server is not required to accept any outside inbound mail.

If you are on a large network, any of your users could be using a kiddie script to try and relay spam. If the server accepts inbound httpd connections any port, they can be exploited from the outside to attempt to send mail.

The good news is you can enhance the logging level in sendmail.cf

The default log level is 9

I run my servers at level 14

O LogLevel=14


This will get you enhanced output that can help you trace the mail source to an internal or an external exploit user.

I've developed a number of log scanning tools that can analyze the mail.log file and provide you with data on where the problem is coming from.

If you change your sendmail logging level, make sure /var has plenty of space, make the change above and do this:

/sbin/init.d/sendmail stop
/sbin/init.d/sendmail start

If this problem becomes persistant, shut down the sendmail daemon and leave it shut.

Then monitor the log. Port 25 exploit scripts and web sendmail form exploits will both continue to happen, because sendmail can send outbound mail without the daemon running.

If it becomes a crisis, temporarily remove execute permissions on the sendmail binary to stop the issue while you track down the problem.

If you suspect an httpd exploit shut down the httpd server and kill all processes with the name httpd. Temporarily block inbound connnections on port 80 with ipfilter if need be.

A careful analysis of available log files and enhanced sendmail logging can help you track down the problem and plug the whole.

When you have specifics, post the log data and I'll tell you how to deal with the issue. I've lost plenty of sleep over this problem in the Linux world and succesfullly stopped an attack on my sendmail setup on my experimental D320 which is fully exposed to the Internet.

SEP