Best Practice for OS, FW, and SELinux - Assignment Example

Best Practice for OS, FW and SELinux Best Practice for OS, FW and SELinux Question Best Practice for Operating Systems Organizations have a duty to ensure that the operating systems under use are in a position to protect the sensitive data contained in them. One way to attain this is adoption of certain best practices. This question discusses given best practices that will help in the protection of the operating systems plus the data stored therein. Running Software Updates It is necessary protecting the operating system with software updates. The updates will create patches for newer or the existing vulnerabilities and aid in the protection against malicious attacks and software flaws. In Windows Server r 12, windows update is set to run automatically or manually to help accomplish this. If prompted, this operation will let the update procedures to run (Minasi, 2014). In CentOS, the update option provides a means to upgrade any system software to the most recent version using one operation. Similarly, “yum update” command will be appropriate in case of a need to update an entire system (Membrey, Verhoeven & Angenendt, 2009). The yum package that comes with CentOS entails scripts for performing system-wide updates on daily basis. Users would need to enter the command su -c /sbin/chkconfig --level 345 yum on; /sbin/service yum start. This command should be followed by the root password in case a need arises to activate the daily automatic update. Back Up Files It is necessary that users create copies of computer files for use in cases where the original files diminish through ways like computer crash or theft (IBM, 2013). Accidents are inevitable. Therefore, it is crucial that users regularly store work documents within a backed up network server. Use of Updated Antivirus Software Use of the updated antivirus software lets the operating systems to detect and isolate new viruses before they perform potential damages within the computer systems (Hailperin, 2007). Password Protection Safety of the operating system will be easier to attain if certain password protection mechanisms are put in place. Examples of such mechanisms include regular change of passwords, users stopping the habit of sharing passwords or login ID (s) and the administrator of the operating system under use ensuring that the systems are accessed only after users have supplied matching combinations of the login credentials, automatic disabling of user accounts in case of login attempts that go past six. In case of the highly vulnerable environments, it would be appropriate using Kerberos. Kerberos will employ strong encryption coupled with complex ticket granting algorithm in authenticating users on a network and to permit streams of data over IP networks. This approach will fit environments like colleges where the implementation of other security mechanisms has remained to be a challenge. Question 2 Best Practices for Firewalls Organizations will often need firewalls to protect the confidential information from unauthorized and malicious users. Even as organizations use different access control features embedded in firewall systems to attain system security, they have to follow certain best practices so as to realize the full potential of the firewall systems. Some of the best practices are discussed here below: Verification of Firewall Change against Change Requests and Compliance Policies The operation of firewalls revolves around identifying problems, fixing the problems and installation of new system. While we install new firewall rules aimed at solving problems or supporting new business units and products, there is a tendency to forget that the firewall system also forms part of the physical implementations of the enterprise-wide security policies (Santana, 2014). For this reason, there would be a need to review every rule to establish whether it complies with corporate security policy. Firewall Reviews Firewall reviews form part of the crucial aspects of maintenance of the rule base associated with firewall systems. The network or computer services are never static and so the rule base should never be considered static. There is a need to review the way to enforce traffic on firewalls as long as the compliance standards and the corporate policies evolve. This would be a good opportunity to clear all redundant rules that are already replaced by the newly introduced rules and to get rid of rules that are associated with services that are no longer used within the organization. Install Every Access Rule with Minimal Access Rights Firewall rules constitute three fields namely service, source and destination. In order to make sure that there are sufficient open ports for all individuals to gain access to the systems they require, it is normal to assign a wide scope of objects in at least one of those fields. In allowing several IP addresses to gain access to a large group’s network in the name of ensuring business continuity, we make the rules to be excessively permissive thus introducing insecurity. For instance, a rule whose service field bears something like “ANY” will end up opening 65,535 ports and this will certainly contrast a firewall administrator’s efforts to minimize the number of attack vectors for hackers. IPTables refers to a rule-based firewall that is pre-installed in numerous Linux Operating Systems. By default, it will always run without rules. It is necessary to save the IPTables rulesset using the command #service iptables save considering that system reboot will often end up restarting the IPTables service making the existing rules to be reset or flushed out. The stated command will by default save TPTables rulesets inside the /etc/sysconfig/iptables file then rules will be restored or applied in the event that the IPTables flushes out. Users should restart the Iptables service after any new port is opened. This move can be accomplished using the command # service iptables restart and is helpful in ensuring that the service is updated before making the system permissive to connections associated with the opened ports. Question 3 SELinux End systems are better placed if they are capable of enforcing the separation of information based on the integrity and confidentiality requirements so as to attain system security. Fortunately, the introduction of SELinux provided a means to attain this separation. The arrival of this end system does not however mean that the security mechanisms that are in place can never be bypassed. This gives the implication that end users still have the duty to follow certain best practices to exploit the full capabilities of SELinux. Configuration Issues It is possible setting the SELINUX variable to enforcing, permissive or disabled. Out of these three possible options, the enforcing options leaves the SELinux code enabled and also causes the code to enforce and audit the access denials (Jang, 2011). The enforcing option prevents operations from moving past the initial denial. Whenever a user creates a new policy package, it would be appropriate for him to make sure that the created package is loaded into the kernel. The user can achieve this by executing the command semodule -i myapp.pp. The command modifies the policy that is already stored inside the machine. The policy module will then be loaded with the other policies. Booting Mode Users should avoid booting the machine using non SELinux kernel because it can lead to mislabeling of file systems. In case a need arises to establish whether there are issues with file system labeling, a user will need to check out for an error message encompassing file_t. In case the labeling issues arise, creation of the flag file /.autorelabel followed by system reboot would be an appropriate measure. system-config-selinux can also help in attaining this. In addition the restorcon/fix- files commands could also be employed while relabeling files. Users wishing to turn SELinux off at boot would need to get to the file /etc/setlinux/config then set SELINUX=disabled. Another option would be the addition of setlinux=0 in the kernel boot parameters though this option poses the challenge that any file created under this condition will lack SELinux context information. Policy Rules Policy rules normally constitute explicit permissions like the domains a user have to possess prior to performing given actions with the particular targets like file reading and execution or connect and bind operations in case of the network ports. A policy for use in defining the domain transition should constitute a labeling file, an interface file as well as a rule file. The three files should be compiled together in combination with the SELinux tools in order to produce an individual policy file. The final policy file is then loaded inside the kernel to make it active. Whether generated from the user-friendly SELinux management tools or handwritten, the policy should be tested using the permissive mode first during which violations are to be logged though permitted. Users could resort to audit2allow tool as a means to produce further rules that expand the policy to permit every legitimate activity associated with the application that is being confined. Architecture Users would need to use architectures like flask that offer a mechanism to enforce the isolation of information using the integrity and confidentiality requirements. This move permits the addressing of threats of tampering plus bypassing of the application security mechanisms whilst enabling the confinement of the damage that could be brought about by flawed or malicious applications. A successful implementation of a security mechanism inside a system will offer flexible support for different ranges of security policies. It is through such a mechanism that users will find it possible configuring the system to comply with different ranges of security requirements. Back Up It would be necessary to perform regular back up of files from SELinux file system. This can be attained through the use of tar command. In addition, the Bacula program offers support for the xattr extensions during the use of SELinux and can aid in backing up SELinux file systems. SELinux enhances local security by bettering the isolation between the involved processes and offering security policies that are more fine-grained. In a case like Fedora 14 system, individuals who find themselves in the circle of multi-user machines should not neglect SELinux based on the more flexible policies that it offers alongside the additional barriers that it introduces amidst users thus introducing a means of production against malicious users. End users charged with the operation of different server environments would also need to embrace SELinux to limit the effect of the security vulnerabilities that are found in server environments. Supposing an attacker is in a position to gain the privileges of a root or a local user, SELinux might only permit him or her to disable one specific service. In case of a home-based need, there will never be a security gain from SELinux considering that the user will be capable of doing everything remotely after authentication. In view of this, it will never be worthwhile for the home-based users to go through the hassle of enabling SELinux. References Hailperin, M. (2007). Operating systems and middleware: Supporting controlled interaction. Boston (Massachusetts: Thomson Course Technology. Ibm, R. (2013). Ibm systems director 6.3 best practices. S.l.: Vervante. Jang, M. H. (2011). Security strategies in Linux platforms and applications. Sudbury, MA: Jones & Bartlett Learning. Membrey, P., Verhoeven, T., & Angenendt, R. (2009). The definitive guide to CentOS. Berkeley, Calif: Apress. Minasi, M. (2014). Mastering Windows server 2012 R2. Santana, G. A. A. (2014). Data center virtualization fundamentals. Indianapolis, IN: Cisco Press. Read More