Practical UNIX Security - Assignment Example

?Running Head: UNIX Security UNIX Security Unix is the operating system which was foremost developed in 1960s and is under regular development since that time. Operating system can be understood as the group of programs responsible for making the computer work (Peek Jerry, 2002). It is a multi-user, stable, multi tasking system for severs, laptops and desktops. Unix systems are also equipped with graphical user interface in the same way as Microsoft Windows, which gives an easy to use atmosphere. However, knowledge of unix is essential for operating Unix systems as it is not covered by a graphical program, for instance, in telnet session. There are various versions of Unix available however they are slightly different. The most admired varieties of Unix are GNU/Linux, Sun Solaris and MacOS X (Rosen Kenneth H., 2006). UNIX security is the way of protecting a UNIX or any other Unix-like operating system (Ross Seth T., 2000). A safe atmosphere cannot be obtained by just designing conception of these operating systems but by observant administrative and user practices. LDAP that is Lightweight Directory Access Protocol is nothing but an application protocol used for editing and reading directories over an internet protocol network (Morimoto Rand, 2008). Directory here refers to the set of organized records, for instance, a telephone directory is organized in an alphabetical record of people and organizations with the address and contact number in every record. LDAP not only stores information about persons but is also used to find encryption certificates, printers, pointers and other various services on a network. It also facilitates single signon where a single password for an operator is shared among various services. The LDAP is most suitable for any type of directory in cases where in-frequent updates and quick lookups are the requirements. As it is a protocol, LDAP does not describe how programs work on server side as well as on the client side. It defines the language used as communication for client programs to speak to servers. On the side of client, a client may be having an address book, an email program, or it can be a printer browser. The server may use only LDAP or may have various other ways for data exchange and LDAP could just an add-on method. Suppose if someone has an email program it may or may not supports LDAP. Most of the LDAP clients have option of reading from a server only. Apart from this, search abilities are also different for different users. Few of the clients have option of updating or writing information however LDAP does not provide security or encryption so additional protection like encrypted SSL connection becomes imperative (Ciampa Mark, 2008). LDAP offers number of features which is difficult to understand at a glance. Below given are some of the features of LDAP. Remote Communications: Sometimes Remote communication can be or sometimes it cannot be a security issue (Negus Christopher, 2009). If unlimited access is provided to non-sensitive LDAP records then the security of data becomes doubtful. In such situation one possibly become susceptible to do’s and don’t do’s assault through cruel LDAP query loads. However it is not that important but still it should be taken care of. You may choose to operate using simple clear text passwords and without using any additional security if you are sure that all the LDAP communications will occur inside trusted network only. However in such cases it becomes easier to scrutinize sensitive data or to sniff traffic or obtain passwords sent in clear. The risk of sniffing, snooping, man in the middle and other various risks increase when a communication takes place across a non reliable network. The increasing emphasis on monitoring (cn=monitor) and run-time configuration (RTC) may make it a rule that LDAP browsers develop into the remote consoles to administers LDAP server (Kopper Karl, 2005). This traffic is highly sensitive by its nature. The next step depends upon the answer to the question that do we need to protect password only or we need to protect password as well as data. Passwords: Securing password within DITS or configuration files must not be confused with securing password during communication (Loney, 2005). Even if the password secured within the DIT or configuration file is in hash method for example {SSHA}, it can be sniffed or snooped depending upon the weakness for these terms. It is possible because when a password is sent to the server from a client it is sent in clear hashed at server and compare with stored contents. When an entry is requested by the client and it is sent in hash form for example a user password {CRYPT} is sent, it will be sent in hash form (stored) form (Jeff Horwitz, 2002). On the other hand, when access is required for that same entry the client send the confirmation password in clear text. And if the user logins successfully with that password then snooper can practically easily believe the clear text password is correct. When a hashed password is sent in snoop able data flow there are possibilities of becoming them weak to dictionary attack which is a dictionary in which attackers run a list of password through hashing algorithm till an equivalent is found (Jamsa Kris A., 2002). Depending upon the implementation, adding of one or more than one octets to a password before hashing and removing it before comparison is called as using Salt. Salt can be used to improve the security of hash password drastically (Konheim Alan G., 2007). It is advisable until and unless there is a good reason for not using salted form of password, it should always be used. Data: To keep a data, starting off from an LDAP server, snoop proof the only option available is encryption. You need to encrypt the complete data stream with SSL/TLS (with SASL or without SASL) or Kerebros (SASL). The disadvantage of this approach is that the encryption is CPU exhaustive process and if performance or resource usage is a main concern then the selection of mass encryption methods present within the TLS/SSL set becomes very essential (Oppliger Rolf, 2009). The mix and match communication is possible. It is considered satisfactory to use easy cleartext password for common remote LDAP access however extra security is needed when operating definite classes of users. So far, we have discussed only about gaining access to data. Now, let’s take a look at the changes and modifications of data. The OpenLDAP gives two potentials to produce audit information (Gift Noah, 2008). The overlay accesslog and overlay auditlog both give quality to record changes to underlying DIT and accesslog even is capable of logging binds and search/read access as well as it saves earlier contents of attributes or entries (Sobell Mark G., 2006). Local Access: Local access can be defined as any event that takes place inside the server cluster (Donar Tim, 2002) or LDAP server or via secured remote access like provide by ssh, and it includes locally issued commands and config files. Config Files: Mainly there are two elements to be taken into consideration here which are- Ownership and permissions and the other one is password. Ownership and permissions: By default latest LDAP systems operate with less privilege group/user accounts. OpenLDAP performs excellently with its slapd.conf (Long Johnny, 2005) which may enclose several highly sensitive data. OpenLDAP loads with core permissions, to assign privileged ports, before dipping down promptly to its low operational privileges. Before doing this OpenLDAP make sure that slapd.conf is possessed by ldap:ldap, or the user:group under which it is running, and has permission of 0600. This helps in preventing the nastiest limits of accidental disclosure. Passwords: Passwords appearing in the slapd.d directories and config files are likely to be more sensitive like rootpw (Mann Scott, 2000). They can be considered to be removed completely once DIT is established or at least they can be store as hashed values in order to avoid trivial disclosure. Unluckily, usage of include file in order to store the highly sensitive data with tight permission, like root read-only, and that can be used with other various systems give no benefit as OpenLDAP already dropped to its normal operational privilege prior to assembling slapd.conf. OpenLDAP is already having an excellent file permission modification mechanism thus this gasp is superfluous. Commands: In the past LDAP was run with the help of a local interface. It was reasonable to believe that in-server traffic was not snooped by making cleartext password protection for the most administrative services. However with the growing emphasis on monitoring and run-time configuration may imply that remote LDAP browsers turn into the standard for the LDAP system administration. In this situation access to all these services will pass on high sensitive data which needs to be protected with the help of data security techniques like TLS/SSL. As in a DIT everything is stored by RTC (Pierre Bovet Daniel, 2006), it is important to consider the use of powerful characteristics of overlay accesslog as a tool to produce audit record of changes to the DIT. DIT: DIT security is defined by the LDAP Security model and it is applied entirely through the use of olcAcess attribute while using run-time configuration or as the access to directive of slapd.conf. Replication: The LDAP system has low security obligation if a normal client access it. However, it may not be possible for the replication of that similar DIT. At some point or the other throughout the replication cycle data get exposed to the communication network. It is certain that a number of this information is sensitive. Replication communications (Burleson Donald K., 2002) connections value separate consideration. One can give mixed TLS/SSL and other insecure and secure connections in single server. Access Control Lists (ACL) Implementation Solutions Security is concern for every system that stores sensitive information like identity data. It is the security policy that defines the requirement of implementing Access Control Lists (ACL) (H. Rosen Kenneth, 2006) in order to control access to data. Although a large amount of LDAP depots and other related database systems have built in support for this type of functionality. The scene of administering these lists across a huge number of various depots can promptly turn into a daunting task if the infrastructure has developed and includes more than a pair of depots. To ensure that norms are advanced on all systems and that the norms are consistent to a single guideline which defines the norms for accessing each and every system is tricky in a multi-server atmosphere. Certainly, problem is greatly worse if one chooses to use some middleware system that is intended for accessing various depots and presenting data from all of these in diverse ways. LDAP Proxy and Virtual Directory Server (Minasi Mark, 2007), both are inclusive of a powerful Access Control List plug-in which is capable of giving exceptionally fine-grained management over the access that it donates to specific data inside the backend depots. This system gives you an option of defining ACLs, controlling approvals right down to the exact features that one would want to avoid or allow a user to have entry to. There are various number of very essential benefits associated in permitting a middleware element to handle ACL that one is wishing to implement for his data layer. The first and probably the most noticeable is that one can centralize his security guidelines in such a manner that the rules for all the systems can be define at a place. The second obvious feature is that in the same manner all your backend data systems can be centralized. This implies that one need not to calculate how to implement an Access Control List for all different system that one is using, as an Access Control List for database system will be employ in a completely different way to an Access Control List set for a particular LDAP server. In addition to this the guidelines can be applied by using information from various depots. For example it is likely to form a guideline defining whether users validated on one LDAP server can access specific data stored on an entirely different LDAP server. This is probably the extreme powerful level of admin that one can imagine by considering the creation of a security guideline across a collection of data systems. Access Control List gives easy configuration and dominant technique of winning control over the protection of a variety of data elements within the infrastructure, despite of the complication of relationships between identities and systems. Auditing Features The LDAP gives extensive account policies and password and also make possible audit of local-based and LDAP based accounts on a Trusted Mode. Integration of LDAP with Trusted Mode allows login of accounts saved in LDAP directory to local host as well as facilitates audit to be done on Trusted Mode. In order to make use of these security aspects one should facilitate an audit subsystem in Trusted Mode of local host. Below given are some points describing the auditing limitations and features. Auditing of local-based as well as LDAP-based accounts is feasible. Auditing is deactivated, by default, for every LDAP based accounts. On the other hand you can utilize the audusr command (Pace Birkholz Erik, 2003) to change the auditing banner for each LDAP-based account. One can build up a preliminary setting for auditing flag for those LDAP-based accounts which are still unknown to system. One can organize this flag in such a way that whenever an account is documented to system for first time, the auditing get disabled or enabled immediately for that particular account. This flag generally is termed as the initial_ts_auditing parameter in the /etc/opt/ldapux/ldapux_client.conf file. To control Trusted Mode elements for each and every account on every host is very important. Trusted Mode elements are not saved in an LDAP directory server for LDAP-based accounts. For instance, if one enables auditing on the host x for an individual account, it will not facilitate auditing on the host y. For LDAP based accounts Audit IDs (Osborne Mark, 2006) are matchless on every system. The Audit IDs are never matched across hosts operating in the Trusted Mode. When the name is changed for an LDAP based account, a fresh audit ID gets created on every host that account is recently using. The initial_ts_auditing flag described in the/etc/opt/ldapux/ldapux_client.conf file will get reset to its default value. Whenever an account gets deleted from LDAP, audit details for that particular account do not get deleted from local system. If the same account is re-used the audit details from the old account will be used again. However one can manually delete the entry from the trusted mode database by deleting the proper file under the  /tcb/files/auth/... directory, where "..." denotes the directory name dependent on first character of an account name. To show details about LDAP based accounts one can use audisp command. On the other hand if LDAP based account has never been log in to the system (via telnet, rlogin, and so on), the audisp -u  command will show the message like "audisp: all specified users names are invalid." Brute-forcing Passwords Even lacking the capability to sniff connection it is still potential to use an open LDAPS/LDAP port through attempting to the brute-force account credentials. Active Directory’s LDAP server can support various simultaneous connection attempts. Permitting public access to service allowing high speed brute forcing is the sole feature that militates against exposing LDAP, whether SSL protected (Powers Shelley, 2003) or not, to the public internet. Require strong passwords: The system is not that secure and is as weak as the weakest password on an account, which can be easily guessed or known. By using strong passwords throughout the board for every user one can prevent it successfully from guessing attack. Select username different from email address: If the email address of a firm or an enterprise users are extensively well-known then in such situation it becomes easy to guess associated login accounts. This can be prevented or can be made difficult by choosing different windows account name than that of email addresses. Only doing this will not shun guessing of Administrator account, until and unless Administrator account is also changed to some other different name. Enable account lockout: It has been advised that security account lockout should be activated with number of attempts that is much more higher than any faulty user would ever trip up but should be sufficient low to prevent brute force attack (Garfinkel Simson, 2003), may be 1000 would be rational. However there is a disadvantage to it as account lockout activated denial of service attack by allowing outsiders to choose accounts to get blocked. This can be very harmful and is totally dependent on account. One should have a plan to treat with essential accounts being locked out prior to making this service accessible to the outside. CONCLUSION The Lightweight Directory Access Protocol (LDAP) helps in editing and reading directories on an internet protocol network and offers various features. The LDAP is safe when we talk about security and does not require additional security until and unless unlimited access is provided to non-sensitive LDAP data. It is absolutely safe if all the communication occurs inside the trusted network. To keep a data snoop proof which is starting off from an LDAP server encryption can be done. The usage of cleartext password is sufficient safe for common remote LDAP access however one needs to be more careful about security if he is operating definite classes of users. The overlay accesslog and overlay auditlog of OpenLDAP both facilitate record changes to underlying DIT and accesslog even log binds and search/read access. Another benefit associated to LDAP is that most of the LDAP depots and various other related database system have already built in support for Access Control List functionality. The LDAP also provides extensive password and account policies as well as make possible audit of LDAP and local based accounts on Trusted Mode. Active Directory’s LDAP server can support various simultaneous connection attempts. Permitting public access to service allowing high speed brute forcing is the sole feature that militates against exposing LDAP, whether SSL protected (Powers Shelley, 2003) or not, to the public internet. Reference: Ciampa Mark (2008). Security+ Guide to Network Security Fundamentals. 3rd ed. London: Cengage Learning. 354. Burleson Donald K. (2002). Oracle9i UNIX administration handbook. London: McGraw-Hill Professional. 43. Donar Tim (2002). Tru64 UNIX-Oracle9i cluster quick reference. Boston: Digital Press. 85. Gift Noah, Jones Jeremy M (2008). Python for Unix and Linux system administration. Chicago: O'Reilly Germany. 24. Garfinkel Simson, Spafford Gene, Schwartz Alan (2003). Practical UNIX and Internet security. 3rd ed. London: O'Reilly Media. 95. H. Rosen Kenneth, Douglas A. Host, Rachel Klee (2006). UNIX: the complete reference. Boston: McGraw-Hill Professional. 57. Jerry Peek, Todino Grace, Strang John (2002). Learning the UNIX operating system. 5th ed. Chicago: O'Reilly Media, Inc. 43. Jeff Horwitz (2002). Unix system management: primer plus. London: Sams Publishing. 65. Jamsa Kris A., Klander Lars (2002). Hacker proof: the ultimate guide to network security. 2nd ed. Boston: Cengage Learning. 38. Kopper Karl (2005). The Linux Enterprise Cluster: build a highly available cluster with commodity hardware and free software. London: No Starch Press. 84. Konheim Alan G (2007). Computer security and cryptography. Chicago: Wiley-Interscience. 95. Loney (2005). Oracle Database 10G Dba Handbook. chicago: Tata McGraw-Hill. 64. Long Johnny, Ed Skoudis (2005). Google hacking for penetration testers. Boston: Syngress. 91. Morimoto Rand (2008). Microsoft Exchange server 2003 unleashed. London: Sams Publishing. 52. Mann Scott, Ellen L. Mitchell (2000). Linux system security: an administrator's guide to open source security tools. Boston: Prentice Hall PTR. 29. Minasi Mark, John Paul Mueller (2007). Mastering Windows Vista Business: Ultimate, Business, and Enterprise, . 13th ed. London: John Wiley and Sons. 41. Negus Christopher (2009). MAC OS X UNIX Toolbox: 1000+ Commands for the Mac OS X. Boston: John Wiley and Sons. 98. Oppliger Rolf (2009). SSL and TLS: theory and practice. Chicago: Artech House. 29. Osborne Mark (2006). Summitt Paul M, How to Cheat at Managing Information Security. London: Syngress. 87. Pierre Bovet Daniel, Marco Cesati (2006). Understanding the Linux Kernel. 3rd ed. Boston: O'Reilly Media, Inc. 78. Pace Birkholz Erik (2003). Special ops: host and network security for Microsoft, UNIX, and Oracle. chicago: Syngress. 64. Powers Shelley, Jerry Peek (2003). UNIX power tools. 3rd ed. London: O'Reilly Media, Inc. 35. Rosen Kenneth H., Host Douglas A., Klee Rachel (2006). UNIX: the complete reference. 2nd ed. Boston: McGraw-Hill Professional. 48. Ross Seth T. (2000). UNIX system security tools. london: McGraw-Hill. 50. Sobell Mark G., Seebach Peter (2006). A practical guide to Unix for Mac OS X users. london: Prentice Hall PTR. 52. Read More