smtp accept request

[Ron Kaledas]

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

[Steven Schweda]

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.

[Steven Schweda]

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".

[Hoff]

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.

[Ron Kaledas]

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

[Jim_McKinney]

> 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... :)

[Hoff]

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.

[Steven Schweda]

> 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).)

[Steven Schweda]

> 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.

[Joseph Huber_1]

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 :-)