Locking The Barn Door
Article 3/2000
The recent attacks on Internet sites by hackers have raised a lot of concern in the industry. VOS systems are not as vulnerable to virus attacks as are Unix or Windows systems. However, VOS is vulnerable to denial-of-service attacks or hackers' attempts to break in.
There's not a lot anyone can do about denial-of-service. This is an industry-wide problem. I do recommend, however, that anyone concerned about these issues visit the SANS website http://www.sans.org/ and subscribe to the e-newsletter. The following statement is from their site:
"The SANS (System Administration, Networking, and Security) Institute is a cooperative research and education organization through which more than 96,000 system administrators, security professionals, and network administrators share the lessons they are learning and find solutions for challenges they face."
Their newsletter and service is excellent.
On the other hand, there are a lot of things that you can do to foil hackers and protect your site. Here's a partial list of recommendations:
1) Remove any login banner that identifies your site by name or company name. If a hacker doesn't see anything to make the site interesting or challenging, he may not bother. However, if he sees "XYZ Bank" or "XYZ Retailer" before he even tries anything, he may consider it an invitation to hack.
2) Replace the login banner with something legal-sounding, like:
"This is a secure computer system. Any attempt to access this computer without proper authorization will be prosecuted to the full extent of the law."
The login banner is modified by editing (master_disk)>system>login_screen_image .
3) Remove the system name and VOS version display from the prelogin banner. This will change the line
System/32, VOS Release 13.3.3, Module %drx#m1
into something that doesn't give away the computer name and operating system name.
This can be changed by changing the system error_codes.text file (m$login_banner) so that it doesn't use substitution fields.
4) Similarly, the line
Please login 18:01:54
can be modified (you don't want to give a hacker the commands that he needs). Change error_codes.text file (m$please_login) to something different and misleading. Note that this may affect some automated scripts that your users may be using.
5) Remove all unnecessary prelogin commands. "help" at prelogin will normally show:
Internal Commands:
display_current_module (prelogin)
list_modules (prelogin) display_date_time (prelogin)
list_systems (prelogin)
display_line (prelogin)
login (prelogin) If there are other commands shown, remove them.
6) Remove all the universal users: Install, Guest, User, Stratus_CAC and Stratus_FE. There is nothing special about these IDs, except that everyone knows them. Give Stratus a different non-obvious ID and unique password for CAC access.
7) Turn on security_admin. Watch your security logs for violations.
8) If you want real-time notification of a security problem, use the notify_security_violation command in your start_up.cm .
9) Turn on password controls. At the minimum this will lock out someone who is repeatedly trying to login with an invalid password. We recommend:
login_admin
-delay_prelogins: yes
-password_exp_time: 90
-min_password_len: 8
-max_access_attempts: 5
-max_bad_logins: 5
-password_grace_time: 15
-password_format: any
This enforces a minimum password length of 8 characters, and gives each user 5 tries before they are locked out.
Note: Be sure to tell all your users to change their passwords in advance of turning this control on.
We also recommend:
set_password_security
-num_hours_between_changes: 24
-req_alpha_numeric: yes
-req_change_first_login: yes
10) Consider using logout_admin which will logoff users whose terminals are idle. An unattended terminal is an open invitation to a malicious employee to wreak havoc in your name.
11) FTP sites: We recommend two changes here:
a) For FTP-only users, i.e. those users who are not allowed to login but only do FTP, make sure that the start_up.cm in their home_dir contains only the command
!logout -no_hold
This will immediately force them off if they try to do a VOS-level login.
b) There is a new parameter on the ftpd command, " -security_check_file ", which allows you to set ACLs/DACLs on a file which becomes the template against which FTP users are compared. If the FTP user has access to the file, s/he is allowed to do FTP sessions. If not, not.
12) Change the default ports for FTP and telnet from 21 and 23 to something known only to your authorized users.
13) Review the security log daily.
Lastly, invest in a good security package. This will help you tighten controls even further. It will also give you a comprehensive set of auditing reports and tools.
| 
