| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 358.1 | Contact Multinet; Assess Threat and Value | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Mar 20 1997 16:43 | 22 |
|
This is (apparently) a failed access initiated via a telnet connection.
Whether this is an innocent login failure or probe, or if this is a
serious security threat requires more context.
Your customer will need to contact Multinet and determine how to decode
the Multinet-generated "CE63DAE0:0581" field. This field *probably*
contains an IP address, or potentially an Ethernet/802.3 address. And
possibly some other information. Stuff useful in tracking the source...
(UCX logs information around login failures, as well.)
Network activity can be difficult to track, and hosts and remote users
can potentially easy to spoof -- consider a network monitoring tool...
There are several different approaches to network monitoring, and there
are various tools available.
Also consider network segmentation and firewalls -- if this system is
a "target" for users at the site, or if this system is connected to the
Internet, seriously consider placing a firewall between this system and
the "threat".
|
| 358.2 | | AUSS::GARSON | DECcharity Program Office | Thu Mar 20 1997 20:54 | 4 |
| re .0
It's probably an IP address and port number (both in hex) but only
Multinet can tell you.
|
| 358.3 | 1st portion is IP address but 2nd ??? | TAINO::RFONSECA | | Fri Mar 21 1997 15:29 | 9 |
| Spoke with the TCP guy and in fact the first part of the number is the
hex representation of the system/PC IP address. The second part which
seems to be the port # is what we don't know how to translate. Is
there a TPC/IP guru out there that might assist in this translation ?
Will try to find a TCP conference and cross post it there.
Thanks for the replies...
|
| 358.4 | Probably A Dead End... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Fri Mar 21 1997 16:34 | 23 |
|
telnet ports -- if memory serves -- wander around. (The port
concept is roughly akin to a DECnet task number.) Again, talk
to Multinet, it's their ASCII text string -- they've generated
it and have then passed it into the OpenVMS auditing support.
With what you have been provided, it would appear that you can
track to the remote system. Depending on auditing on the remote
system -- and on the normal users found on of the remote system
-- you may or may not be able to track this further.
IP, as a rule, does not pass the originating username information
along with the connection. (Where DECnet does pass this information
along with the connection...)
In general, it's not likely that you will be able to track this
sort of IP probe back to the originating user without use of some
network monitoring tools and/or without access to accounting logs
on the remote system. (Assuming you cannot identify the user
uniquely based on the originating system, on the time that the
probe(s) occured, on the auditing on the remote system (if any),
and on other activity that may have originated from that system.)
|
| 358.5 | | AUSS::GARSON | DECcharity Program Office | Sun Mar 23 1997 22:13 | 9 |
| re .3
The port number for an inbound connection is roughly equivalent to the
DECnet object number and identifies the service wanted.
The port number on the initiating node is essentially meaningless. If
that node is a multi-user machine and runs decent IP software,
you *might* be able to identify the originating user from the port number.
If that node is a single-user machine then ignore the port number.
|