topic Re: smtp accept request in Operating System - OpenVMS

smtp accept request

Ron Kaledas — Wed, 18 Aug 2010 14:46:22 GMT

I have a couple of systems that are producing the following opcom message every minute or so, filling up the operator.log...I'm not sure what this message is telling me, or where to look to stop it! I'm not sure if this is some configuration issue on the vms side or something on the email server side (I think that's what that ip address is, an email server - but not the one I'm configured to use in smtp config.) I don't really have access to the email server side of things.
I don't have any users on one of the systems (it's a test system) and I'm pretty sure no one is sending or receiving email other than me. There is a tcpip$smtp_recv_run.log file created every time one of these opcom messages comes in, but it doesn't have anything unusual in it. (I can post it here if needed.)

The port shown changes every time, and this comes out about (but not exactly) every minute. No other opcom messages (that would be related) come out at the same time.

%%%%%%%%%%% OPCOM 18-AUG-2010 11:28:27.72 %%%%%%%%%%%
Message from user INTERnet on HNATST
INTERnet ACP SMTP Accept Request from Host: 10.252.19.122 Port: 3351

Any hints as to what I should look at - assuming it's something I need to fix on the vms side?

Thanks,
Ron

Re: smtp accept request

Steven Schweda — Wed, 18 Aug 2010 16:32:59 GMT

Almost always interesting:

TCPIP SHOW VERSION

> INTERnet ACP SMTP Accept Request [...]

It is what it says. Someone (at Host:
10.252.19.122) is trying to send e-mail to
someone at this system.

> There is a tcpip$smtp_recv_run.log file
> created every time one of these opcom
> messages comes in, but it doesn't have
> anything unusual in it.

Define "unusual". Defining (/system)
TCPIP$SMTP_RECV_TRACE = 1 might add some
interest. I do that here, and it shows
things like the "MAIL From:" and "RCPT To:",
which might offer some hints as to who's
trying to do what to whom.

> (I can post it here if needed.)

With my weak psychic powers, it's hard to say
what might be useful.

When those .LOG files hit ;32767, you may
need to intervene.

Re: smtp accept request

Steven Schweda — Wed, 18 Aug 2010 16:36:05 GMT

Of course, if you just want the noise to
stop, and your influence with the sender is
slight, then you could add:

Bad-Clients: 10.252.19.122

to "SYS$SPECIFIC:[TCPIP$SMTP]SMTP.CONFIG".

Re: smtp accept request

Hoff — Wed, 18 Aug 2010 17:33:25 GMT

Reading a kilometer or three beyond the details that were included, this could well be an infected Windows box sending out spam; I've met a few bits of malware over the years that sought out open SMTP relays, and that found and used (insecurely-configured) VMS boxes.

Re: smtp accept request

Ron Kaledas — Wed, 18 Aug 2010 17:49:43 GMT

I've since found out it was some type of "network monitor" that they are "trying out"! (at least that's what they say is running on the machine at that ip address.)

Wonder why it's trying to send email, or how it's "monitoring" via smtp, but...

anyway, this is tcpip v5.6 eco 5, fwiw.

I did turn on the tcpip trace and debug logicals earlier, attached is the recv_run log from that time.

I did already hit the 32767 limit, hoping to avoid having to worry about that again...

the "bad clients" idea sounds like it might work for me - any negative effects I should be concerned about in doing that? i.e. what does it do, on my end and his?

and Hoff, didn't know what to include without making the problem description overly lengthy...figured to get the discussion rolling and go from there.

Ron

Re: smtp accept request

Jim_McKinney — Wed, 18 Aug 2010 17:59:44 GMT

> it was some type of "network monitor"

Many organizations run port scanning software to see which systems are listening on which ports (and therefore may be vulnerable to attack). On well known ports (as is SMTP's 25) they'll often engage in a conversation with that well known application - with SMTP, for example, not to prove they can send mail, but to determine which of the other features of SMTP might be active as some are potentially revealing with respect to the OS or users of the system. Often the folks who engage in this sort of scanning come calling later telling you that there are risks that require mitigation... :)

Re: smtp accept request

Hoff — Wed, 18 Aug 2010 18:31:34 GMT

And yet other folks intercept the scans and return, um, creatively formatted data. :-)

Though an entirely more serious note, these sort of network tools are a neglected area of security; they're potentially juicy targets, too.

Re: smtp accept request

Steven Schweda — Wed, 18 Aug 2010 18:45:37 GMT

> the "bad clients" idea sounds like it might
> work for me - any negative effects I should
> be concerned about in doing that? i.e.
> what does it do, on my end and his?

ALP $
%%%%%%%%%%% OPCOM 18-AUG-2010 13:07:24.55 %%%%%%%%%%%
Message from user INTERnet on ALP
INTERnet ACP SMTP Accept Request from Host: 41.140.98.126 Port: 4130

ALP $
%%%%%%%%%%% OPCOM 18-AUG-2010 13:07:34.15 %%%%%%%%%%%
Message from user TCPIP$SMTP on ALP
%TCPIP-W-SMTP_BADCLNT, client IP address 41.140.98.126 matched Bad Clients list

Stops junk e-mail delivery, but doesn't do
much for OPERATOR.LOG. Possibly more useful
in this situation:

TCPIP set service SMTP /reject = host = 10.252.19.122

> I did already hit the 32767 limit, hoping
> to avoid having to worry about that
> again...

I have added a (messy, potentially
embarrassing) piece of DCL to
TCPIP$SMTP_RECV_RUN.COM which does a
purge-and-renumber operation from time to
time. (It may be ugly, but it does seem to
work around here, at least until the latest
TCPIP patch installation overwrites it
(again).)

Re: smtp accept request

Steven Schweda — Wed, 18 Aug 2010 18:55:49 GMT

> Reject-Unbacktranslatable-IP : FALSE

Probably not important here, but for
annoyances which originate in the outside
world, setting this to TRUE can stop
considerable junk.

ALP $
%%%%%%%%%%% OPCOM 18-AUG-2010 09:22:34.94 %%%%%%%%%%%
Message from user INTERnet on ALP
INTERnet ACP SMTP Accept Request from Host: 113.22.236.153 Port: 23708

ALP $
%%%%%%%%%%% OPCOM 18-AUG-2010 09:22:42.27 %%%%%%%%%%%
Message from user TCPIP$SMTP on ALP
%TCPIP-W-SMTP_UNBKTRNSIP, client IP address 113.22.236.153 is not backtranslatable to a host name

Again, doesn't do much for OPERATOR.LOG, but
a valid sender without a working
address-to-name look-up is pretty rare.

Re: smtp accept request

Joseph Huber_1 — Wed, 18 Aug 2010 19:14:36 GMT

If the address 10.252.19.122 is not faked to hide the real address in the public forum, then it is some node inside the local domain (10. is not "the internet", but a private IP address).
So it should be possible to resolve the issue by human interaction - unless the organization is too big to find the people responsible for the systems involved :-)

Re: smtp accept request

Jeremy Begg — Thu, 19 Aug 2010 04:55:16 GMT

Ron,

Why not just turn off the SMTP logging?

$ TCPIP
TCPIP> SET SERVICE SMTP /LOG_OPTION=NOACCEPT
TCPIP> DISABLE SERVICE SMTP
TCPIP> ENABLE SERVICE SMTP
TCPIP> EXIT
$

This will stop the annoying OPCOM messages.

You might also ask your co-workers why their monitoring software is pinging your machine every minute.

Regards,
Jeremy Begg

Re: smtp accept request

Ron Kaledas — Thu, 19 Aug 2010 12:32:43 GMT

Jeremy - because I was only looking at SHOW CONFIG SMTP and forgot about SHOW SERV SMTP!!! D'oh!!

Thanks for the reminder. I will look at doing that, though I will also look at the suggestion for the reject=host=..., which might be the "less-sledge-hammer-ish" approach.

As for the monitoring, that's how this particular package works, I suppose...I don't really have any say at that site, I just have to deal with whatever they're doing.

Re: smtp accept request

Ron Kaledas — Thu, 19 Aug 2010 14:06:25 GMT

Okay, looks like turning off the logging was what I'll do. I did try the reject host idea, but that still logged in opcom - yes, I know I could turn off rejects in the same way as the accepts. But, I wasn't positive that they wouldn't notice being rejected at that host/monitor, so this addresses it without that concern.

Thanks for everyone's help.

Re: smtp accept request

Hoff — Thu, 19 Aug 2010 14:13:38 GMT

I usually tell folks not to connect VMS to the Internet without a firewall, and it looks like your internal network is sufficiently complex that you need to do that, or to VLAN your network.

Check the ratings of the firewalls versus your typical maximum bandwidth; you may be able to operate with a mid-grade firewall.

Or have the IT folks VLAN your stuff.

Or have the probes stopped. VMS mail isn't very secure, so they're not going to prove anything here.