When possible stick with vendors that you have a relationship with.
For office machines, I have standardized on Allied Telesys network cards. Older machines, up to Optiplex 7010, use Allied Telesis AT-2916SX/LC network cards. Newer machines should use AT-2911SX/LC cards.
It is Linux Team policy to patch systems once a month. The machines are patched after normal work hours on "Patch Thursday", the fourth Thursday of the month.
Tools are available to facilitate the process of supporting software updates. On systems that are involved with the software update process, these tools are located in directory /usr/local/sbin. For easy recognition, all of the tool file names begin with "repo". The following is a list of the available tools along with their purpose. They are listed in the order that they would generally be used.
Several host computer systems are involved with the repo update process. To download all of the updated Red Hat RPMS, requires one Red Hat system for each distribution. Virtual machines running on the infrastructure server are used for this purpose. Each virtual machines is registered to RHN, and can therefor download RPMS from the satellite with the reposync command. ReposyncWrapper.pl is a wrapper around reposync to simplify the process. The following is a list of the machines involved:
Computer systems must meet minimum security standards to be allowed on our networks. Specific security requirements vary by network.
Certify is a toolset for managing system security. It includes scripts for hardening and checking system security, as well as scripts for detecting and tracking disk drives. Cron files are provided to automate recurring tasks.
Certify is intended for environments where security is routinely audited.
Certify is not an all encompassing security configuration tool. Unlike tools which override operating system settings, certify manages security posture. Certify attempts to make sure vendor supplied tools are properly implemented.
It contains two primary Python scripts, "harden.py" & "check.py", for managing security settings. Harden applies security settings, while check reports on security findings.
The original driving force for developing certify was an interest in simplifying the process of system certification. Before certify the system certification process took hours for each machine.
If you have certify in a yum repository, install as follows:
yum install certify
or
yum upgrade certify
If you do not access to a yum repository, get a copy of the latest rpm and use localinstall as follows.
yum --localinstall certify
or
yum --localupdate certify
Warning, be sure to change the password entry in /root/.my.cnf.certify to match the MySQL user, "diskscan", account password.
./harden.py -h
usage: harden.py [-h] [-i] [-l] [--logfile LOGFILE]
If no arguments, all security options will be performed
optional arguments:| -h, --help | show this help message and exit |
| -i, --interactive | interactive mode (default: False) |
| -l, --log | |
| --logfile LOGFILE | log file name (default: /var/log/certify) |
./check.py -h usage: check.py [-h] [-i] [-c] [-l] [--logfile LOGFILE]
If no arguments, all security tests will be performed
optional arguments:| -h, --help | |
| -i, --interactive | interactive mode (default: False) |
| -c, --check | md5 check (default: False) |
| -l, --log | xcreate log (default: False) |
| --logfile LOGFILE | log file name (default: /var/log/certify) |
Red Hat's documentation is not clear on what belongs in the bridge interface configuration file and what belongs in the hardware interface configuration file. The following table shows a before and after view of a bridged network configuration. The changes apply to the hypervisor, not the client.
| ifcfg-eth1 | ................ | ifcfg-eth1 | ifcfg-br0 |
|---|---|---|---|
| DEVICE=eth1 | DEVICE=eth1 | DEVICE=br0 | |
| BOOTPROTO=static | BOOTPROTO=none | BOOTPROTO=static | |
| TYPE=Ethernet | TYPE=Ethernet | TYPE=Bridge | |
| ONBOOT=yes | ONBOOT=yes | ONBOOT=yes | |
| DEFAULT=yes | DEFAULT=yes | HWADDR=00:25:90:0B:9E:EF | HWADDR=00:25:90:0B:9E:EF |
| IPADDR=2.40.52.186 | IPADDR=2.40.52.186 | ||
| PREFIX=24 | PREFIX=24 | ||
| GATEWAY=2.40.52.254 | GATEWAY=2.40.52.254 | ||
| DNS1=2.15.15.15 | DNS1=2.15.15.15 | ||
| SEARCH=mydomain.com | SEARCH=mydomain.com | ||
| NM_CONTROLLED=yes | NM_CONTROLLED=no | NM_CONTROLLED=no | |
| BRIDGE=br0 | DELAY=0 |
| / | 20GB |
| /boot | 500MB |
| swap | Memory size or double memory size depending on application |
| /tmp | 20GB |
| /var | 10GB |
| /var/log | 10GB |
| /var/log/audit | 10GB |
| /var/tmp | 10GB |
| /home | System dependent, just make sure to leave room for Filesystem growth |
| /opt | Optional depending on system use case |
IPA server uses a number of network ports to communicate with its services. These ports must be open and available for IPA to work. Note, this does not apply to IPA Clients
| Service | Ports | Type |
|---|---|---|
| HTTP/HTTPS | 80, 443 | TCP |
| LDAP/LDAPS | 389, 636 | TCP |
| Kerberos | 88, 464 | TCP and UDP |
| DNS | 53 | TCP and UDP |
| NTP | 123 | UDP |
On RHEL 7 systems run the following firewall-cmd command do open all the required ports.
[root@server ]# firewall-cmd --permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,464/tcp,53/tcp,88/udp,464/udp,53/udp,123/udp}
[root@server ]# firewall-cmd --reload
On RHEL 5 & 6 use iptables.
Update /etc/ntp.conf file to reference the IPA servers.
Add DNS entries for your host to the IPA server before installing the client. Technically this is not necessary, but I think it is easier than figuring out which ipa-client-install options to use.
Update /etc/resolv.conf file to reference the IPA servers, and modify the search path to start with the "IPA domain".
Install ipa-client rpm if not already installed, then execute the following command. Note, you might want to backup the /etc/krb5.conf file. That way if something goes south you can quickly return to a working system.
For automatic home directory creation, install the oddjob-mkhomedir rpm and add the --mkhomedir option as shown. Note you can use the mkhomedir option even if you plan to use a shared home directory configuration. A home directory is only created if it does not already exist.
[root@server ]# ipa-client-install --mkhomedir
This section is more background than procedure, but serves as a good reminder of what to expect when a machine becomes a member of an IPA domain. The IPA servers have an established trust relationship with the Active Directory servers, so it is not necessary for a user to have a local account on a Linux machine, they can authenticate using their AD credentials. Access to Linux machines is controlled by AD group membership. The AD group "ad_users_external" has been setup to provide minimal Linux system access. Anyone desiring access to a Linux system should be a member of this group. Restricting access to a subset of Windows users will require the creation of a AD group specifically for that host or hosts.
Access control is based upon a combination of an external Windows security group and a IPA POSIX group. It is the POSIX group that really determines access. Windows groups are added to the POSIX group to gain access.
The home directory for a user originating from an external domain is handled differently. A sub-directory to "/home" is created for the external domain. For example, if your windows domain is "mybusiness.com" and your IPA domain is "ipa.mybusiness.com", the default home directory location for the mybusiness.com domain is /home/mybusiness.com/. If oddjob_mkhomedir is enabled, the home directory will be created automatically.
The purpose of this policy is to ensure local firewall consistency.
This goes hand-in-hand with our Software Standard policy. It is substantially more difficult to install, manage and monitor custom installations.
The default Red Hat firewall is firewalld.
The default Red Hat firewall is iptables
This article is about obtaining NPE (Non Person Entity) PKI certificates, such as Apache certificates.
It is a good idea to create a openssl.conf file unique to each entity that you will be managing. This is because certificates expire, and re-using an existing configuration file is easier and less prone to error. This is particularly true when the entity is known by multiple names and/or addresses.
The first step is to make a copy of an existing openssl.conf file and make the following modifications:
If the host or service is known by more than one domain name or IP address, add an alt_names entry to the [ v3_req ] section as shown.
subjectAltName = @alt_names
Then add an [ alt_names ] section as shown.
[ alt_names ]
DNS.1 = first domain name
DNS.2 = secound domain name
IP.1 = first IP address
IP.2 = secound IP address
Give the configuration file a name that will associate it with the host or service it pertains to.
openssl genrsa -out hostname.com.key 2048
openssl req -new -key hostname.com.key -outform PEM -out hostname.com.csr -config hostname.com.cnf
When you receive your signed cert, make sure that the key modulus and certificate modulus match.
openssl -x509 -modulus -noout -in hostname.com.crt
openssl -rsa -modulus -noout -in hostname.com.key
In order for your OS or application to trust the PKI hierarchy you need to download and install the CA chain.
/etc/pki/ca-trust/source/anchors
/bin/ln -fns /usr/lib64/pkcs11/p11-kit-trust.so \ /etc/alternatives/libnssckbi.so.x86_64