Q: How to Catch a "Blaster?"
f_har...@titan.sfasu.edu
annoying and we would like to catch the culprits. Could
anyone suggest a method to identify the origin of a "blast?"
I've enclosed the DCL and would also enjoy an explanation
of how it works. Thanks in advance for any help forthcoming.
Greg T. Harber Internet: f_har...@titan.sfasu.edu
Dept. of Computer Science Land: P.O. Box 13063 SFASU
Stephen F. Austin State University Nacogdoches, TX 75962
------------------
$!$ blast.com
$!
$ status = 1
$ cr[0,8] = 13
$ bell[0,8] = 7
$ of:=" "
$ null_byte[0,8] = 0 !Set up phone protocol values
$ true_byte[0,8] = 1
$ false_byte[0,8] = 0
$ id_rmt_user[0,8] = 7 !Text = id of remote user, status rtn
$ ring_rmt_user[0,8] = 8 !Text = 1 byte, true if first ring, sts rtn
$ hang_up[0,8] = 9 !Link broken, no status
$ master_busy[0,8] = 10 !When requested to do other functions
$ master_answer[0,8] = 11 !From another master
$ master_reject[0,8] = 12 !From another master
$ slave_exit[0,8] = 13 !Command to slave
$ text[0,8] = 14 !Text >= 1 char frag
$ request_dir[0,8] = 15 !Null returned when done
$ force_third_party[0,8] = 17 !Text is id of 3rd party
$ on_hold[0,8] = 18 !Put target on hold
$ off_hold[0,8] = 19 !Take target off hold
$ !
$ status_0 = "Unknown problem"
$ status_1 = "The operation was completed successfully."
$ status_success = 1
$ status_2 = "Invalid user syntax"
$ status_3 = "Slave could not communicate with user"
$ status_4 = "node::user> missing user name"
$ status_5 = "The slave does not have necessary privileges."
$ status_6 = "The specified Target user does not exist."
$ status_7 = "The Target's terminal cannot be used by PHONE."
$ status_8 = "The Target logged off during the procedure."
$ status_9 = "Target phone off hook (e.g., /NOBROADCAST set)."
$ status_other = "Bad status code."
$ !
$ remote_user = p1
$ if remote_user .eqs. "" then read sys$command remote_user -
/error=error/end=exit/prompt="User to send message to: "
$ remote_user = f$edit(remote_user,"trim,upcase,uncomment")
$ remote_node = f$parse(remote_user,,,"node") - "_"
$ remote_user = remote_user - remote_node
$ if remote_user .eqs. "" then goto exit
$ if remote_node .eqs. "" then remote_node = f$logi("sys$node") - "_"
$ message = "''p2'"
$ if message .eqs. "" then read sys$command message -
/error=error/end=exit/prompt="Message to display:"
$ message = "''cr'''bell'''bell'''f$edit(message,"trim")'''of'''bell'''bell'" + null_byte
$ open/read/write link 'remote_node'"29="
$!
$ write /error=error link id_rmt_user,message,remote_user
$!
$ read link ans /end=error/error=error
$ if f$cvui(0,8,ans) .ne. status_success then goto bad_status
$ write /error=error link ring_rmt_user,message,true_byte
$ read link ans /end=error/error=error
$ if f$cvui(0,8,ans) .eq. status_success then goto exit
$BAD_STATUS:
$ status_code = f$cvui(0,8,ans)
$ if status_code .gt. 9 then status_code = 10
$ status_message = status_'status_code'
$ write sys$output "''f$fao("Bad status received = !2ZB - ",status_code)'''status_message'"
$ERROR:
$ status = $status
$ write sys$output "An error has occured."
$EXIT:
$ if f$logi("link") .nes. "" then -
write link slave_exit,message
$ if f$logi("link") .nes. "" then -
close link
$ exit status
Bob Koehler
In article <1995Apr2...@titan.sfasu.edu>, f_har...@titan.sfasu.edu writes:
>Our site is suffering from a plague of "blast" users. It's
>annoying and we would like to catch the culprits. Could
>anyone suggest a method to identify the origin of a "blast?"
>I've enclosed the DCL and would also enjoy an explanation
>of how it works. Thanks in advance for any help forthcoming.
>
>$ open/read/write link 'remote_node'"29="
>$!
This line makes a connection to DECnet object 29, aka PHONE. The originator
can be found while the connection is in progress via NCP's show known links
command. The connection, however, is likely to be short lived. The security
auditing system can log a network login (if successfull network login auditing
is enabled), which will record both the remote username and the remote node
name.
You might also choose to disable the default PHONE account and password. NCP's
sho object phone will show you what these are. Removing that account will
disable "anonymous" use of phone, but legitimate users can still be given
proxy access to the PHONE object, or they can use explicit access control
(there is an extra step required on the part of the user to access PHONE via
explicit access control, but I've just done it and it works).
If the default PHONE account is disabled, those attempting to blast your system
will likely generate network login failure audit records, if those are enabled.
c.f the DECnet manuals and the guide to system security
------------------------------------------------------------------------------
Bob Koehler |
koe...@bessta.gsfc.nasa.gov | rkoe...@author.gsfc.nasa.gov
Brendan Welch, W1LPG
>>annoying and we would like to catch the culprits. Could
>>anyone suggest a method to identify the origin of a "blast?"
>>I've enclosed the DCL and would also enjoy an explanation
>>of how it works. Thanks in advance for any help forthcoming.
>>
such a file. If such files are prohibited, confront the owner directly.
Another way, if your policies allow, is to cleverly add an innocent-looking
line to such a file, which invokes a .COM file which sends YOU mail
everytime the blast file is invoked (/noself ?). COPY/OVERLAY that file
onto each user's file, naming it the same as his/hers blaster.
--
Brendan Welch, system analyst, UMass/Lowell, W1LPG, wel...@woods.uml.edu
Bart Zorn, TUDelft, +31 15 782894
> annoying and we would like to catch the culprits. Could
> anyone suggest a method to identify the origin of a "blast?"
> I've enclosed the DCL and would also enjoy an explanation
> of how it works. Thanks in advance for any help forthcoming.
>
What this piece of dcl does, is connect to the DECnet PHONE object of the
target system. By default, the PHONE object (number 29) is configured
with a default account (PHONE$SERVER). Whenever a connection is made to this
object, a logfile (NETSERVER.LOG for DECnet Phase IV, NET$SERVER.LOG for
DECnet/OSI) is created in the default directory for this account, which
will contain minimal information regarding the source of the connection
request.
We consider PHONE a toy. Therefore, we disable the PHONE object all together.
MAIL can be used for serious communications.
$ MCR NCP CLEAR OBJECT PHONE ALL
(also issue the DEFINE variant if you want to make it permanent)
or
$ MCR NCL DELETE SESSION CONTROL APPLICATION PHONE
(Use @NET$CONFIGURE if you want to make it permanent)
Regards,
-----------------------------------------------------------------------
Bart Zorn | E-mail: B.Z...@ET.TUDelft.NL
Delft University of Technology | Voice: +31 15 782894
Dpt. of Electrical Engineering | FAX: +31 15 783953
-----------------------------------------------------------------------
Stephen Hoffman
:Our site is suffering from a plague of "blast" users. It's
:annoying and we would like to catch the culprits. Could
:anyone suggest a method to identify the origin of a "blast?"
:I've enclosed the DCL and would also enjoy an explanation
:of how it works. Thanks in advance for any help forthcoming.
You do not mention the version of OpenVMS in use. If it is OpenVMS V6.0
or later, extensive security auditing is available. One can enable all
sorts of auditing.
You will also want to review the computer policies, including policies
around computer mis-use. I'd get the policies in place first, and would
make it quite clear what will happen to users that violate the policies.
You may want to consider the use of the NCP "OUTGOING CONNECT PRIVILEGES"
option on the PHONE object, specifying privileges such as SYSNAM, PRMMBX,
WORLD, OPER, and NETMBX. (These are the privileges with which PHONE is
installed.) This will end the shenanigans originating on the local node,
and will have to be executed on *each* local DECnet node.
NCP> SET OBJ PHONE OUTG CONN PRIV SYSNAM PRMMBX WORLD OPER
NCP> DEF OBJ PHONE OUTG CONN PRIV SYSNAM PRMMBX WORLD OPER
Before doing this, I would also enable auditing for privilege failures
and all network access.
As I've generally found little use for PHONE, I generally shut it off
entirely -- the specification of an invalid password on the PHONE server
username and a different invalid password in the DECnet database entry
for the phone object works nicely.
I've also had some success by equating the symbol "phone$command" in
the system-wide login process (where the phone server login will pick
it up); this can be used to cause a command procedure execution, and
the command procedure can be used to record the local or remote user.
To use this, you'll have to switch the object DECnet executes for an
incoming phone connection from PHONE.EXE to PHONE.COM. And you will
need to write up a small auditing procedure that translates logical
names such as SYS$REM*. (This isn't fool-proof, but it can be used to
catch a few of the unwary.)
Also: please carefully consider the repurcussions for *other* sites
before posting these sorts of full code examples. The procedure
posted "spoofs" at the level of the PHONE protocol.
------------------------------ Opinionative -------------------------------
Stephen Hoffman, NR EMT-I, WEMT, N1THN hof...@xdelta.enet.dec.com
General Info: in...@digital.com OpenVMS Info: openvm...@digital.com
OpenVMS Engineering, Digital Equipment Corporation, Nashua NH
Ronald P. Larkin
> MAIL can be used for serious communications.
However, when the system manager is dialed in from home (1.0 phone lines
available) and a user needs a little handholding ("Now do this. Now do
that.") PHONE or TALK works better than email.
Ron
--
Ron Larkin (r-la...@uiuc.edu)
Illinois Natural History Survey, Champaign IL 61820