If you are familiar with the history of UNIX you will most probably find out that it was developed as a private research project by Ken Thompson at Bell Laboratories in 1969 to use an idle PDP-7. It was designed for convenience, rather than security in mind, and for that reason, though many years have passed on the development of UNIX, it is quite impossible to make a system truly secure. But there are processes we can perform to make our system less vulnerable. Though the details of these process are beyond the scope of this paper, we would like to give an overview and try to introduce some security related tools widely available. 4.1 General Overview Considering all the conditions we could think of, we like to propose the following points to be considered before drawing a security policy: Security and Convenience Trade-off Security and Trust Trade-off Cost Responsibility Trusting Remote Hosts Periodic Tests 4.1.1 Security and Convenience Trade-off While reading the CERT (Computer Emergency Response Team) advisory for setting a secure system we are quite annoyed to find out that it recommended to turn off a lot of user privileges, no offense to CERT's effort, though. While the risks were and are true in sense it will make a resourceful system quite meaningless but it will certainly provide a more secure system. So, there is always a need of making a trade-off line between convenience and security. You have to decide how much convenience you want to give your users by risking the security issue. So, it is put nicely by the writers of the Unix System Administration Handbook in a frequency and time like equation: Security = 1/Convenience So, summary of this section is that you are one to draw the trade-off line between security and convenience. 4.1.2 Security and Trust Trade-off This little section is more or less similar to the previous one. Since the purpose of security is to protect valuable information, software as well as hardware, it is necessary to measure the depth of your information available on your system. By measuring how important they can be to anyone or to yourself, how they are necessary for remote users or local users, how determined your users or remote users can be to gain unprivileged authority, should be considered. If sensitive information gives no realistic purposes to anyone then there is no necessity of providing so voluntarily. For example encrypted password fields do not serve any purposes except authentication programs and authentication programs are designed to run as extra privileges which have special permissions required to access those encrypted password fields from special files. So, there is no realistic purpose of serving those fields in voluntary basis. Beside this kind of things you have to consider on the networks that trust you thus giving your users access to their system. 4.1.3 Cost It is not realistic to secure a single host by monitoring with a lot of hosts or monitoring a system running a bunch of programs even at the cost of system performance degradation. Depending on the sensitiveness of the information you want to put on line, it is recommended to run a single or few similar kind of monitoring tools which runs like daemons only to be invoked at the time of requests. If it require few hosts to monitor a single host you might consider of putting that single host off-line. 4.1.4 Responsibility It is strongly expected to make the users (or yourself) understand the responsibility they bear upon agreeing to use your system. An educated community of users might be the best security tool one system could expect. Contrasting to the educated community of users uneducated community of users are a security risk to the system but it is up to you to make necessary default setups to give even the newest users a comfortable environment. But you should consider a guideline to educate your new users by providing them necessary information step by step. 4.1.5 Trusting Remote Hosts If you are required to enable remote access to your system, you are strongly recommended to consider the trust you give to the remote hosts your users can use to login to your system. If the hosts that your users use are unsecured, than it is quite obvious that you are unsecuring your system unintentionally. However, remote hosts are also giving you a trust which you have to keep. 4.1.6 Periodic Tests Periodic tests are necessary to check the security options or to upgrade your monitoring tools. There is also a necessity of making yourself up to date to system vulnerabilities that are always published by your vendor. During these testing it would, most probably but not necessarily, require you to run patches or most of the time, upgrade your applications. General practical settings are discussed in details in Appendix 10 . Please refer to them. 4.2 Few Tools Here we are going to introduce you two simple tools among tons of tools available. These two tools are not necessarily the most important or reliable tools we can imagine of but they provide us necessary options we are concerned of: COPS John 4.2.1 COPS COPS (Computer Oracle and Password System) is a collection of programs that do the following checking in a system: File, directory, device permissions and modes Poor Passwords(though we will disable it later) The contents of system startup files(/etc/rc*) and crontab files Existence of root-SUID files, their permissions Writability of users home directories and startup files While FreeBSD comes equipped with a lot of daily monitoring tools it is recommended for the average users also. You should make it available in a stripped off version for the users so that they can check their own files. We will demonstrate it in Appendix 10. Another nice feature of COPS is that it only reports the wrong configurations without bothering to fix them thus providing you a lot of opportunities to deal with those warned files. And what's more it does not require a super privilege(though for better performance it is required to run as root) to run. 4.2.2 John john is a password cracking program written by john the ripper. It is similar in operation with Crack (developed by Alec D.E. Muffet) but faster and there is broader control over rule settings, restoration in different platforms etc. The package is available from http://www.freebsd.org. It will give you an option of testing weak passwords in your system before others can do it. While you can argue that password shadowing will make it unnecessary, there are always possibilities of reading the shadow password files. One more thing is recommended to do is to change your password program so that it does not accept all lower or all upper case letters or without a non-alphabet char. We will provide necessary instructions later in Appendix 10 .

this page is maintained by:
jchakma@yahoo.com