mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
20150609-1 选题 RHCSA Series 7-13
This commit is contained in:
DeadFire
parent
48f8b8987b
commit
a6fa2fa8ad
@ -0,0 +1,212 @@
|
||||
RHCSA Series: Using ACLs (Access Control Lists) and Mounting Samba / NFS Shares – Part 7
|
||||
================================================================================
|
||||
In the last article ([RHCSA series Part 6][1]) we started explaining how to set up and configure local system storage using parted and ssm.
|
||||
|
||||
|
||||
|
||||
RHCSA Series:: Configure ACL’s and Mounting NFS / Samba Shares – Part 7
|
||||
|
||||
We also discussed how to create and mount encrypted volumes with a password during system boot. In addition, we warned you to avoid performing critical storage management operations on mounted filesystems. With that in mind we will now review the most used file system formats in Red Hat Enterprise Linux 7 and then proceed to cover the topics of mounting, using, and unmounting both manually and automatically network filesystems (CIFS and NFS), along with the implementation of access control lists for your system.
|
||||
|
||||
#### Prerequisites ####
|
||||
|
||||
Before proceeding further, please make sure you have a Samba server and a NFS server available (note that NFSv2 is no longer supported in RHEL 7).
|
||||
|
||||
During this guide we will use a machine with IP 192.168.0.10 with both services running in it as server, and a RHEL 7 box as client with IP address 192.168.0.18. Later in the article we will tell you which packages you need to install on the client.
|
||||
|
||||
### File System Formats in RHEL 7 ###
|
||||
|
||||
Beginning with RHEL 7, XFS has been introduced as the default file system for all architectures due to its high performance and scalability. It currently supports a maximum filesystem size of 500 TB as per the latest tests performed by Red Hat and its partners for mainstream hardware.
|
||||
|
||||
Also, XFS enables user_xattr (extended user attributes) and acl (POSIX access control lists) as default mount options, unlike ext3 or ext4 (ext2 is considered deprecated as of RHEL 7), which means that you don’t need to specify those options explicitly either on the command line or in /etc/fstab when mounting a XFS filesystem (if you want to disable such options in this last case, you have to explicitly use no_acl and no_user_xattr).
|
||||
|
||||
Keep in mind that the extended user attributes can be assigned to files and directories for storing arbitrary additional information such as the mime type, character set or encoding of a file, whereas the access permissions for user attributes are defined by the regular file permission bits.
|
||||
|
||||
#### Access Control Lists ####
|
||||
|
||||
As every system administrator, either beginner or expert, is well acquainted with regular access permissions on files and directories, which specify certain privileges (read, write, and execute) for the owner, the group, and “the world” (all others). However, feel free to refer to [Part 3 of the RHCSA series][2] if you need to refresh your memory a little bit.
|
||||
|
||||
However, since the standard ugo/rwx set does not allow to configure different permissions for different users, ACLs were introduced in order to define more detailed access rights for files and directories than those specified by regular permissions.
|
||||
|
||||
In fact, ACL-defined permissions are a superset of the permissions specified by the file permission bits. Let’s see how all of this translates is applied in the real world.
|
||||
|
||||
1. There are two types of ACLs: access ACLs, which can be applied to either a specific file or a directory), and default ACLs, which can only be applied to a directory. If files contained therein do not have a ACL set, they inherit the default ACL of their parent directory.
|
||||
|
||||
2. To begin, ACLs can be configured per user, per group, or per an user not in the owning group of a file.
|
||||
|
||||
3. ACLs are set (and removed) using setfacl, with either the -m or -x options, respectively.
|
||||
|
||||
For example, let us create a group named tecmint and add users johndoe and davenull to it:
|
||||
|
||||
# groupadd tecmint
|
||||
# useradd johndoe
|
||||
# useradd davenull
|
||||
# usermod -a -G tecmint johndoe
|
||||
# usermod -a -G tecmint davenull
|
||||
|
||||
And let’s verify that both users belong to supplementary group tecmint:
|
||||
|
||||
# id johndoe
|
||||
# id davenull
|
||||
|
||||
|
||||
|
||||
Verify Users
|
||||
|
||||
Let’s now create a directory called playground within /mnt, and a file named testfile.txt inside. We will set the group owner to tecmint and change its default ugo/rwx permissions to 770 (read, write, and execute permissions granted to both the owner and the group owner of the file):
|
||||
|
||||
# mkdir /mnt/playground
|
||||
# touch /mnt/playground/testfile.txt
|
||||
# chmod 770 /mnt/playground/testfile.txt
|
||||
|
||||
Then switch user to johndoe and davenull, in that order, and write to the file:
|
||||
|
||||
echo "My name is John Doe" > /mnt/playground/testfile.txt
|
||||
echo "My name is Dave Null" >> /mnt/playground/testfile.txt
|
||||
|
||||
So far so good. Now let’s have user gacanepa write to the file – and the write operation will, which was to be expected.
|
||||
|
||||
But what if we actually need user gacanepa (who is not a member of group tecmint) to have write permissions on /mnt/playground/testfile.txt? The first thing that may come to your mind is adding that user account to group tecmint. But that will give him write permissions on ALL files were the write bit is set for the group, and we don’t want that. We only want him to be able to write to /mnt/playground/testfile.txt.
|
||||
|
||||
# touch /mnt/playground/testfile.txt
|
||||
# chown :tecmint /mnt/playground/testfile.txt
|
||||
# chmod 777 /mnt/playground/testfile.txt
|
||||
# su johndoe
|
||||
$ echo "My name is John Doe" > /mnt/playground/testfile.txt
|
||||
$ su davenull
|
||||
$ echo "My name is Dave Null" >> /mnt/playground/testfile.txt
|
||||
$ su gacanepa
|
||||
$ echo "My name is Gabriel Canepa" >> /mnt/playground/testfile.txt
|
||||
|
||||
|
||||
|
||||
Manage User Permissions
|
||||
|
||||
Let’s give user gacanepa read and write access to /mnt/playground/testfile.txt.
|
||||
|
||||
Run as root,
|
||||
|
||||
# setfacl -R -m u:gacanepa:rwx /mnt/playground
|
||||
|
||||
and you’ll have successfully added an ACL that allows gacanepa to write to the test file. Then switch to user gacanepa and try to write to the file again:
|
||||
|
||||
$ echo "My name is Gabriel Canepa" >> /mnt/playground/testfile.txt
|
||||
|
||||
To view the ACLs for a specific file or directory, use getfacl:
|
||||
|
||||
# getfacl /mnt/playground/testfile.txt
|
||||
|
||||
|
||||
|
||||
Check ACLs of Files
|
||||
|
||||
To set a default ACL to a directory (which its contents will inherit unless overwritten otherwise), add d: before the rule and specify a directory instead of a file name:
|
||||
|
||||
# setfacl -m d:o:r /mnt/playground
|
||||
|
||||
The ACL above will allow users not in the owner group to have read access to the future contents of the /mnt/playground directory. Note the difference in the output of getfacl /mnt/playground before and after the change:
|
||||
|
||||
|
||||
|
||||
Set Default ACL in Linux
|
||||
|
||||
[Chapter 20 in the official RHEL 7 Storage Administration Guide][3] provides more ACL examples, and I highly recommend you take a look at it and have it handy as reference.
|
||||
|
||||
#### Mounting NFS Network Shares ####
|
||||
|
||||
To show the list of NFS shares available in your server, you can use the showmount command with the -e option, followed by the machine name or its IP address. This tool is included in the nfs-utils package:
|
||||
|
||||
# yum update && yum install nfs-utils
|
||||
|
||||
Then do:
|
||||
|
||||
# showmount -e 192.168.0.10
|
||||
|
||||
and you will get a list of the available NFS shares on 192.168.0.10:
|
||||
|
||||
|
||||
|
||||
Check Available NFS Shares
|
||||
|
||||
To mount NFS network shares on the local client using the command line on demand, use the following syntax:
|
||||
|
||||
# mount -t nfs -o [options] remote_host:/remote/directory /local/directory
|
||||
|
||||
which, in our case, translates to:
|
||||
|
||||
# mount -t nfs 192.168.0.10:/NFS-SHARE /mnt/nfs
|
||||
|
||||
If you get the following error message: “Job for rpc-statd.service failed. See “systemctl status rpc-statd.service” and “journalctl -xn” for details.”, make sure the rpcbind service is enabled and started in your system first:
|
||||
|
||||
# systemctl enable rpcbind.socket
|
||||
# systemctl restart rpcbind.service
|
||||
|
||||
and then reboot. That should do the trick and you will be able to mount your NFS share as explained earlier. If you need to mount the NFS share automatically on system boot, add a valid entry to the /etc/fstab file:
|
||||
|
||||
remote_host:/remote/directory /local/directory nfs options 0 0
|
||||
|
||||
The variables remote_host, /remote/directory, /local/directory, and options (which is optional) are the same ones used when manually mounting an NFS share from the command line. As per our previous example:
|
||||
|
||||
192.168.0.10:/NFS-SHARE /mnt/nfs nfs defaults 0 0
|
||||
|
||||
#### Mounting CIFS (Samba) Network Shares ####
|
||||
|
||||
Samba represents the tool of choice to make a network share available in a network with *nix and Windows machines. To show the Samba shares that are available, use the smbclient command with the -L flag, followed by the machine name or its IP address. This tool is included in the samba-client package:
|
||||
|
||||
You will be prompted for root’s password in the remote host:
|
||||
|
||||
# smbclient -L 192.168.0.10
|
||||
|
||||
|
||||
|
||||
Check Samba Shares
|
||||
|
||||
To mount Samba network shares on the local client you will need to install first the cifs-utils package:
|
||||
|
||||
# yum update && yum install cifs-utils
|
||||
|
||||
Then use the following syntax on the command line:
|
||||
|
||||
# mount -t cifs -o credentials=/path/to/credentials/file //remote_host/samba_share /local/directory
|
||||
|
||||
which, in our case, translates to:
|
||||
|
||||
# mount -t cifs -o credentials=~/.smbcredentials //192.168.0.10/gacanepa /mnt/samba
|
||||
|
||||
where smbcredentials:
|
||||
|
||||
username=gacanepa
|
||||
password=XXXXXX
|
||||
|
||||
is a hidden file inside root’s home (/root/) with permissions set to 600, so that no one else but the owner of the file can read or write to it.
|
||||
|
||||
Please note that the samba_share is the name of the Samba share as returned by smbclient -L remote_host as shown above.
|
||||
|
||||
Now, if you need the Samba share to be available automatically on system boot, add a valid entry to the /etc/fstab file as follows:
|
||||
|
||||
//remote_host:/samba_share /local/directory cifs options 0 0
|
||||
|
||||
The variables remote_host, /samba_share, /local/directory, and options (which is optional) are the same ones used when manually mounting a Samba share from the command line. Following the definitions given in our previous example:
|
||||
|
||||
//192.168.0.10/gacanepa /mnt/samba cifs credentials=/root/smbcredentials,defaults 0 0
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
In this article we have explained how to set up ACLs in Linux, and discussed how to mount CIFS and NFS network shares in a RHEL 7 client.
|
||||
|
||||
I recommend you to practice these concepts and even mix them (go ahead and try to set ACLs in mounted network shares) until you feel comfortable. If you have questions or comments feel free to use the form below to contact us anytime. Also, feel free to share this article through your social networks.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/rhcsa-exam-configure-acls-and-mount-nfs-samba-shares/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:http://www.tecmint.com/rhcsa-exam-create-format-resize-delete-and-encrypt-partitions-in-linux/
|
||||
[2]:http://www.tecmint.com/rhcsa-exam-manage-users-and-groups/
|
||||
[3]:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-acls.html
|
||||
@ -0,0 +1,215 @@
|
||||
RHCSA Series: Securing SSH, Setting Hostname and Enabling Network Services – Part 8
|
||||
================================================================================
|
||||
As a system administrator you will often have to log on to remote systems to perform a variety of administration tasks using a terminal emulator. You will rarely sit in front of a real (physical) terminal, so you need to set up a way to log on remotely to the machines that you will be asked to manage.
|
||||
|
||||
In fact, that may be the last thing that you will have to do in front of a physical terminal. For security reasons, using Telnet for this purpose is not a good idea, as all traffic goes through the wire in unencrypted, plain text.
|
||||
|
||||
In addition, in this article we will also review how to configure network services to start automatically at boot and learn how to set up network and hostname resolution statically or dynamically.
|
||||
|
||||
|
||||
|
||||
RHCSA: Secure SSH and Enable Network Services – Part 8
|
||||
|
||||
### Installing and Securing SSH Communication ###
|
||||
|
||||
For you to be able to log on remotely to a RHEL 7 box using SSH, you will have to install the openssh, openssh-clients and openssh-servers packages. The following command not only will install the remote login program, but also the secure file transfer tool, as well as the remote file copy utility:
|
||||
|
||||
# yum update && yum install openssh openssh-clients openssh-servers
|
||||
|
||||
Note that it’s a good idea to install the server counterparts as you may want to use the same machine as both client and server at some point or another.
|
||||
|
||||
After installation, there is a couple of basic things that you need to take into account if you want to secure remote access to your SSH server. The following settings should be present in the `/etc/ssh/sshd_config` file.
|
||||
|
||||
1. Change the port where the sshd daemon will listen on from 22 (the default value) to a high port (2000 or greater), but first make sure the chosen port is not being used.
|
||||
|
||||
For example, let’s suppose you choose port 2500. Use [netstat][1] in order to check whether the chosen port is being used or not:
|
||||
|
||||
# netstat -npltu | grep 2500
|
||||
|
||||
If netstat does not return anything, you can safely use port 2500 for sshd, and you should change the Port setting in the configuration file as follows:
|
||||
|
||||
Port 2500
|
||||
|
||||
2. Only allow protocol 2:
|
||||
|
||||
Protocol 2
|
||||
|
||||
3. Configure the authentication timeout to 2 minutes, do not allow root logins, and restrict to a minimum the list of users which are allowed to login via ssh:
|
||||
|
||||
LoginGraceTime 2m
|
||||
PermitRootLogin no
|
||||
AllowUsers gacanepa
|
||||
|
||||
4. If possible, use key-based instead of password authentication:
|
||||
|
||||
PasswordAuthentication no
|
||||
RSAAuthentication yes
|
||||
PubkeyAuthentication yes
|
||||
|
||||
This assumes that you have already created a key pair with your user name on your client machine and copied it to your server as explained here.
|
||||
|
||||
- [Enable SSH Passwordless Login][2]
|
||||
|
||||
### Configuring Networking and Name Resolution ###
|
||||
|
||||
1. Every system administrator should be well acquainted with the following system-wide configuration files:
|
||||
|
||||
- /etc/hosts is used to resolve names <---> IPs in small networks.
|
||||
|
||||
Every line in the `/etc/hosts` file has the following structure:
|
||||
|
||||
IP address - Hostname - FQDN
|
||||
|
||||
For example,
|
||||
|
||||
192.168.0.10 laptop laptop.gabrielcanepa.com.ar
|
||||
|
||||
2. `/etc/resolv.conf` specifies the IP addresses of DNS servers and the search domain, which is used for completing a given query name to a fully qualified domain name when no domain suffix is supplied.
|
||||
|
||||
Under normal circumstances, you don’t need to edit this file as it is managed by the system. However, should you want to change DNS servers, be advised that you need to stick to the following structure in each line:
|
||||
|
||||
nameserver - IP address
|
||||
|
||||
For example,
|
||||
|
||||
nameserver 8.8.8.8
|
||||
|
||||
3. 3. `/etc/host.conf` specifies the methods and the order by which hostnames are resolved within a network. In other words, tells the name resolver which services to use, and in what order.
|
||||
|
||||
Although this file has several options, the most common and basic setup includes a line as follows:
|
||||
|
||||
order bind,hosts
|
||||
|
||||
Which indicates that the resolver should first look in the nameservers specified in `resolv.conf` and then to the `/etc/hosts` file for name resolution.
|
||||
|
||||
4. `/etc/sysconfig/network` contains routing and global host information for all network interfaces. The following values may be used:
|
||||
|
||||
NETWORKING=yes|no
|
||||
HOSTNAME=value
|
||||
|
||||
Where value should be the Fully Qualified Domain Name (FQDN).
|
||||
|
||||
GATEWAY=XXX.XXX.XXX.XXX
|
||||
|
||||
Where XXX.XXX.XXX.XXX is the IP address of the network’s gateway.
|
||||
|
||||
GATEWAYDEV=value
|
||||
|
||||
In a machine with multiple NICs, value is the gateway device, such as enp0s3.
|
||||
|
||||
5. Files inside `/etc/sysconfig/network-scripts` (network adapters configuration files).
|
||||
|
||||
Inside the directory mentioned previously, you will find several plain text files named.
|
||||
|
||||
ifcfg-name
|
||||
|
||||
Where name is the name of the NIC as returned by ip link show:
|
||||
|
||||
|
||||
|
||||
Check Network Link Status
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
|
||||
Network Files
|
||||
|
||||
Other than for the loopback interface, you can expect a similar configuration for your NICs. Note that some variables, if set, will override those present in `/etc/sysconfig/network` for this particular interface. Each line is commented for clarification in this article but in the actual file you should avoid comments:
|
||||
|
||||
HWADDR=08:00:27:4E:59:37 # The MAC address of the NIC
|
||||
TYPE=Ethernet # Type of connection
|
||||
BOOTPROTO=static # This indicates that this NIC has been assigned a static IP. If this variable was set to dhcp, the NIC will be assigned an IP address by a DHCP server and thus the next two lines should not be present in that case.
|
||||
IPADDR=192.168.0.18
|
||||
NETMASK=255.255.255.0
|
||||
GATEWAY=192.168.0.1
|
||||
NM_CONTROLLED=no # Should be added to the Ethernet interface to prevent NetworkManager from changing the file.
|
||||
NAME=enp0s3
|
||||
UUID=14033805-98ef-4049-bc7b-d4bea76ed2eb
|
||||
ONBOOT=yes # The operating system should bring up this NIC during boot
|
||||
|
||||
### Setting Hostnames ###
|
||||
|
||||
In Red Hat Enterprise Linux 7, the hostnamectl command is used to both query and set the system’s hostname.
|
||||
|
||||
To display the current hostname, type:
|
||||
|
||||
# hostnamectl status
|
||||
|
||||
|
||||
|
||||
Check System Hostname
|
||||
|
||||
To change the hostname, use
|
||||
|
||||
# hostnamectl set-hostname [new hostname]
|
||||
|
||||
For example,
|
||||
|
||||
# hostnamectl set-hostname cinderella
|
||||
|
||||
For the changes to take effect you will need to restart the hostnamed daemon (that way you will not have to log off and on again in order to apply the change):
|
||||
|
||||
# systemctl restart systemd-hostnamed
|
||||
|
||||
|
||||
|
||||
Set System Hostname
|
||||
|
||||
In addition, RHEL 7 also includes the nmcli utility that can be used for the same purpose. To display the hostname, run:
|
||||
|
||||
# nmcli general hostname
|
||||
|
||||
and to change it:
|
||||
|
||||
# nmcli general hostname [new hostname]
|
||||
|
||||
For example,
|
||||
|
||||
# nmcli general hostname rhel7
|
||||
|
||||
|
||||
|
||||
Set Hostname Using nmcli Command
|
||||
|
||||
### Starting Network Services on Boot ###
|
||||
|
||||
To wrap up, let us see how we can ensure that network services are started automatically on boot. In simple terms, this is done by creating symlinks to certain files specified in the [Install] section of the service configuration files.
|
||||
|
||||
In the case of firewalld (/usr/lib/systemd/system/firewalld.service):
|
||||
|
||||
[Install]
|
||||
WantedBy=basic.target
|
||||
Alias=dbus-org.fedoraproject.FirewallD1.service
|
||||
|
||||
To enable the service:
|
||||
|
||||
# systemctl enable firewalld
|
||||
|
||||
On the other hand, disabling firewalld entitles removing the symlinks:
|
||||
|
||||
# systemctl disable firewalld
|
||||
|
||||
|
||||
|
||||
Enable Service at System Boot
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
In this article we have summarized how to install and secure connections via SSH to a RHEL server, how to change its name, and finally how to ensure that network services are started on boot. If you notice that a certain service has failed to start properly, you can use systemctl status -l [service] and journalctl -xn to troubleshoot it.
|
||||
|
||||
Feel free to let us know what you think about this article using the comment form below. Questions are also welcome. We look forward to hearing from you!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/rhcsa-series-secure-ssh-set-hostname-enable-network-services-in-rhel-7/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:http://www.tecmint.com/20-netstat-commands-for-linux-network-management/
|
||||
[2]:http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/
|
||||
@ -0,0 +1,176 @@
|
||||
RHCSA Series: Installing, Configuring and Securing a Web and FTP Server – Part 9
|
||||
================================================================================
|
||||
A web server (also known as a HTTP server) is a service that handles content (most commonly web pages, but other types of documents as well) over to a client in a network.
|
||||
|
||||
A FTP server is one of the oldest and most commonly used resources (even to this day) to make files available to clients on a network in cases where no authentication is necessary since FTP uses username and password without encryption.
|
||||
|
||||
The web server available in RHEL 7 is version 2.4 of the Apache HTTP Server. As for the FTP server, we will use the Very Secure Ftp Daemon (aka vsftpd) to establish connections secured by TLS.
|
||||
|
||||
|
||||
|
||||
RHCSA: Installing, Configuring and Securing Apache and FTP – Part 9
|
||||
|
||||
In this article we will explain how to install, configure, and secure a web server and a FTP server in RHEL 7.
|
||||
|
||||
### Installing Apache and FTP Server ###
|
||||
|
||||
In this guide we will use a RHEL 7 server with a static IP address of 192.168.0.18/24. To install Apache and VSFTPD, run the following command:
|
||||
|
||||
# yum update && yum install httpd vsftpd
|
||||
|
||||
When the installation completes, both services will be disabled initially, so we need to start them manually for the time being and enable them to start automatically beginning with the next boot:
|
||||
|
||||
# systemctl start httpd
|
||||
# systemctl enable httpd
|
||||
# systemctl start vsftpd
|
||||
# systemctl enable vsftpd
|
||||
|
||||
In addition, we have to open ports 80 and 21, where the web and ftp daemons are listening, respectively, in order to allow access to those services from the outside:
|
||||
|
||||
# firewall-cmd --zone=public --add-port=80/tcp --permanent
|
||||
# firewall-cmd --zone=public --add-service=ftp --permanent
|
||||
# firewall-cmd --reload
|
||||
|
||||
To confirm that the web server is working properly, fire up your browser and enter the IP of the server. You should see the test page:
|
||||
|
||||
|
||||
|
||||
Confirm Apache Web Server
|
||||
|
||||
As for the ftp server, we will have to configure it further, which we will do in a minute, before confirming that it’s working as expected.
|
||||
|
||||
### Configuring and Securing Apache Web Server ###
|
||||
|
||||
The main configuration file for Apache is located in `/etc/httpd/conf/httpd.conf`, but it may rely on other files present inside `/etc/httpd/conf.d`.
|
||||
|
||||
Although the default configuration should be sufficient for most cases, it’s a good idea to become familiar with all the available options as described in the [official documentation][1].
|
||||
|
||||
As always, make a backup copy of the main configuration file before editing it:
|
||||
|
||||
# cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.$(date +%Y%m%d)
|
||||
|
||||
Then open it with your preferred text editor and look for the following variables:
|
||||
|
||||
- ServerRoot: the directory where the server’s configuration, error, and log files are kept.
|
||||
- Listen: instructs Apache to listen on specific IP address and / or ports.
|
||||
- Include: allows the inclusion of other configuration files, which must exist. Otherwise, the server will fail, as opposed to the IncludeOptional directive, which is silently ignored if the specified configuration files do not exist.
|
||||
- User and Group: the name of the user/group to run the httpd service as.
|
||||
- DocumentRoot: The directory out of which Apache will serve your documents. By default, all requests are taken from this directory, but symbolic links and aliases may be used to point to other locations.
|
||||
- ServerName: this directive sets the hostname (or IP address) and port that the server uses to identify itself.
|
||||
|
||||
The first security measure will consist of creating a dedicated user and group (i.e. tecmint/tecmint) to run the web server as and changing the default port to a higher one (9000 in this case):
|
||||
|
||||
ServerRoot "/etc/httpd"
|
||||
Listen 192.168.0.18:9000
|
||||
User tecmint
|
||||
Group tecmint
|
||||
DocumentRoot "/var/www/html"
|
||||
ServerName 192.168.0.18:9000
|
||||
|
||||
You can test the configuration file with.
|
||||
|
||||
# apachectl configtest
|
||||
|
||||
and if everything is OK, then restart the web server.
|
||||
|
||||
# systemctl restart httpd
|
||||
|
||||
and don’t forget to enable the new port (and disable the old one) in the firewall:
|
||||
|
||||
# firewall-cmd --zone=public --remove-port=80/tcp --permanent
|
||||
# firewall-cmd --zone=public --add-port=9000/tcp --permanent
|
||||
# firewall-cmd --reload
|
||||
|
||||
Note that, due to SELinux policies, you can only use the ports returned by
|
||||
|
||||
# semanage port -l | grep -w '^http_port_t'
|
||||
|
||||
for the web server.
|
||||
|
||||
If you want to use another port (i.e. TCP port 8100), you will have to add it to SELinux port context for the httpd service:
|
||||
|
||||
# semanage port -a -t http_port_t -p tcp 8100
|
||||
|
||||
|
||||
|
||||
Add Apache Port to SELinux Policies
|
||||
|
||||
To further secure your Apache installation, follow these steps:
|
||||
|
||||
1. The user Apache is running as should not have access to a shell:
|
||||
|
||||
# usermod -s /sbin/nologin tecmint
|
||||
|
||||
2. Disable directory listing in order to prevent the browser from displaying the contents of a directory if there is no index.html present in that directory.
|
||||
|
||||
Edit `/etc/httpd/conf/httpd.conf` (and the configuration files for virtual hosts, if any) and make sure that the Options directive, both at the top and at Directory block levels, is set to None:
|
||||
|
||||
Options None
|
||||
|
||||
3. Hide information about the web server and the operating system in HTTP responses. Edit /etc/httpd/conf/httpd.conf as follows:
|
||||
|
||||
ServerTokens Prod
|
||||
ServerSignature Off
|
||||
|
||||
Now you are ready to start serving content from your /var/www/html directory.
|
||||
|
||||
### Configuring and Securing FTP Server ###
|
||||
|
||||
As in the case of Apache, the main configuration file for Vsftpd `(/etc/vsftpd/vsftpd.conf)` is well commented and while the default configuration should suffice for most applications, you should become acquainted with the documentation and the man page `(man vsftpd.conf)` in order to operate the ftp server more efficiently (I can’t emphasize that enough!).
|
||||
|
||||
In our case, these are the directives used:
|
||||
|
||||
anonymous_enable=NO
|
||||
local_enable=YES
|
||||
write_enable=YES
|
||||
local_umask=022
|
||||
dirmessage_enable=YES
|
||||
xferlog_enable=YES
|
||||
connect_from_port_20=YES
|
||||
xferlog_std_format=YES
|
||||
chroot_local_user=YES
|
||||
allow_writeable_chroot=YES
|
||||
listen=NO
|
||||
listen_ipv6=YES
|
||||
pam_service_name=vsftpd
|
||||
userlist_enable=YES
|
||||
tcp_wrappers=YES
|
||||
|
||||
By using `chroot_local_user=YES`, local users will be (by default) placed in a chroot’ed jail in their home directory right after login. This means that local users will not be able to access any files outside their corresponding home directories.
|
||||
|
||||
Finally, to allow ftp to read files in the user’s home directory, set the following SELinux boolean:
|
||||
|
||||
# setsebool -P ftp_home_dir on
|
||||
|
||||
You can now connect to the ftp server using a client such as Filezilla:
|
||||
|
||||
|
||||
|
||||
Check FTP Connection
|
||||
|
||||
Note that the `/var/log/xferlo`g log records downloads and uploads, which concur with the above directory listing:
|
||||
|
||||
|
||||
|
||||
Monitor FTP Download and Upload
|
||||
|
||||
Read Also: [Limit FTP Network Bandwidth Used by Applications in a Linux System with Trickle][2]
|
||||
|
||||
### Summary ###
|
||||
|
||||
In this tutorial we have explained how to set up a web and a ftp server. Due to the vastness of the subject, it is not possible to cover all the aspects of these topics (i.e. virtual web hosts). Thus, I recommend you also check other excellent articles in this website about [Apache][3].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/rhcsa-series-install-and-secure-apache-web-server-and-ftp-in-rhel/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:http://httpd.apache.org/docs/2.4/
|
||||
[2]:http://www.tecmint.com/manage-and-limit-downloadupload-bandwidth-with-trickle-in-linux/
|
||||
[3]:http://www.google.com/cse?cx=partner-pub-2601749019656699:2173448976&ie=UTF-8&q=virtual+hosts&sa=Search&gws_rd=cr&ei=Dy9EVbb0IdHisASnroG4Bw#gsc.tab=0&gsc.q=apache
|
||||
@ -0,0 +1,197 @@
|
||||
RHCSA Series: Yum Package Management, Automating Tasks with Cron and Monitoring System Logs – Part 10
|
||||
================================================================================
|
||||
In this article we will review how to install, update, and remove packages in Red Hat Enterprise Linux 7. We will also cover how to automate tasks using cron, and will finish this guide explaining how to locate and interpret system logs files with the focus of teaching you why all of these are essential skills for every system administrator.
|
||||
|
||||
|
||||
|
||||
RHCSA: Yum Package Management, Cron Job Scheduling and Log Monitoring – Part 10
|
||||
|
||||
### Managing Packages Via Yum ###
|
||||
|
||||
To install a package along with all its dependencies that are not already installed, you will use:
|
||||
|
||||
# yum -y install package_name(s)
|
||||
|
||||
Where package_name(s) represent at least one real package name.
|
||||
|
||||
For example, to install httpd and mlocate (in that order), type.
|
||||
|
||||
# yum -y install httpd mlocate
|
||||
|
||||
**Note**: That the letter y in the example above bypasses the confirmation prompts that yum presents before performing the actual download and installation of the requested programs. You can leave it out if you want.
|
||||
|
||||
By default, yum will install the package with the architecture that matches the OS architecture, unless overridden by appending the package architecture to its name.
|
||||
|
||||
For example, on a 64 bit system, yum install package will install the x86_64 version of package, whereas yum install package.x86 (if available) will install the 32-bit one.
|
||||
|
||||
There will be times when you want to install a package but don’t know its exact name. The search all or search options can search the currently enabled repositories for a certain keyword in the package name and/or in its description as well, respectively.
|
||||
|
||||
For example,
|
||||
|
||||
# yum search log
|
||||
|
||||
will search the installed repositories for packages with the word log in their names and summaries, whereas
|
||||
|
||||
# yum search all log
|
||||
|
||||
will look for the same keyword in the package description and url fields as well.
|
||||
|
||||
Once the search returns a package listing, you may want to display further information about some of them before installing. That is when the info option will come in handy:
|
||||
|
||||
# yum info logwatch
|
||||
|
||||
|
||||
|
||||
Search Package Information
|
||||
|
||||
You can regularly check for updates with the following command:
|
||||
|
||||
# yum check-update
|
||||
|
||||
The above command will return all the installed packages for which an update is available. In the example shown in the image below, only rhel-7-server-rpms has an update available:
|
||||
|
||||
|
||||
|
||||
Check For Package Updates
|
||||
|
||||
You can then update that package alone with,
|
||||
|
||||
# yum update rhel-7-server-rpms
|
||||
|
||||
If there are several packages that can be updated, yum update will update all of them at once.
|
||||
|
||||
Now what happens when you know the name of an executable, such as ps2pdf, but don’t know which package provides it? You can find out with `yum whatprovides “*/[executable]”`:
|
||||
|
||||
# yum whatprovides “*/ps2pdf”
|
||||
|
||||
|
||||
|
||||
Find Package Belongs to Which Package
|
||||
|
||||
Now, when it comes to removing a package, you can do so with yum remove package. Easy, huh? This goes to show that yum is a complete and powerful package manager.
|
||||
|
||||
# yum remove httpd
|
||||
|
||||
Read Also: [20 Yum Commands to Manage RHEL 7 Package Management][1]
|
||||
|
||||
### Good Old Plain RPM ###
|
||||
|
||||
RPM (aka RPM Package Manager, or originally RedHat Package Manager) can also be used to install or update packages when they come in form of standalone `.rpm` packages.
|
||||
|
||||
It is often utilized with the `-Uvh` flags to indicate that it should install the package if it’s not already present or attempt to update it if it’s installed `(-U)`, producing a verbose output `(-v)` and a progress bar with hash marks `(-h)` while the operation is being performed. For example,
|
||||
|
||||
# rpm -Uvh package.rpm
|
||||
|
||||
Another typical use of rpm is to produce a list of currently installed packages with code>rpm -qa (short for query all):
|
||||
|
||||
# rpm -qa
|
||||
|
||||
|
||||
|
||||
Query All RPM Packages
|
||||
|
||||
Read Also: [20 RPM Commands to Install Packages in RHEL 7][2]
|
||||
|
||||
### Scheduling Tasks using Cron ###
|
||||
|
||||
Linux and other Unix-like operating systems include a tool called cron that allows you to schedule tasks (i.e. commands or shell scripts) to run on a periodic basis. Cron checks every minute the /var/spool/cron directory for files which are named after accounts in /etc/passwd.
|
||||
|
||||
When executing commands, any output is mailed to the owner of the crontab (or to the user specified in the MAILTO environment variable in the /etc/crontab, if it exists).
|
||||
|
||||
Crontab files (which are created by typing crontab -e and pressing Enter) have the following format:
|
||||
|
||||
|
||||
|
||||
Crontab Entries
|
||||
|
||||
Thus, if we want to update the local file database (which is used by locate to find files by name or pattern) every second day of the month at 2:15 am, we need to add the following crontab entry:
|
||||
|
||||
15 02 2 * * /bin/updatedb
|
||||
|
||||
The above crontab entry reads, “Run /bin/updatedb on the second day of the month, every month of the year, regardless of the day of the week, at 2:15 am”. As I’m sure you already guessed, the star symbol is used as a wildcard character.
|
||||
|
||||
After adding a cron job, you can see that a file named root was added inside /var/spool/cron, as we mentioned earlier. That file lists all the tasks that the crond daemon should run:
|
||||
|
||||
# ls -l /var/spool/cron
|
||||
|
||||
|
||||
|
||||
Check All Cron Jobs
|
||||
|
||||
In the above image, the current user’s crontab can be displayed either using cat /var/spool/cron/root or,
|
||||
|
||||
# crontab -l
|
||||
|
||||
If you need to run a task on a more fine-grained basis (for example, twice a day or three times each month), cron can also help you to do that.
|
||||
|
||||
For example, to run /my/script on the 1st and 15th of each month and send any output to /dev/null, you can add two crontab entries as follows:
|
||||
|
||||
01 00 1 * * /myscript > /dev/null 2>&1
|
||||
01 00 15 * * /my/script > /dev/null 2>&1
|
||||
|
||||
But in order for the task to be easier to maintain, you can combine both entries into one:
|
||||
|
||||
01 00 1,15 * * /my/script > /dev/null 2>&1
|
||||
|
||||
Following the previous example, we can run /my/other/script at 1:30 am on the first day of the month every three months:
|
||||
|
||||
30 01 1 1,4,7,10 * /my/other/script > /dev/null 2>&1
|
||||
|
||||
But when you have to repeat a certain task every “x” minutes, hours, days, or months, you can divide the right position by the desired frequency. The following crontab entry has the exact same meaning as the previous one:
|
||||
|
||||
30 01 1 */3 * /my/other/script > /dev/null 2>&1
|
||||
|
||||
Or perhaps you need to run a certain job on a fixed frequency or after the system boots, for example. You can use one of the following string instead of the five fields to indicate the exact time when you want your job to run:
|
||||
|
||||
@reboot Run when the system boots.
|
||||
@yearly Run once a year, same as 00 00 1 1 *.
|
||||
@monthly Run once a month, same as 00 00 1 * *.
|
||||
@weekly Run once a week, same as 00 00 * * 0.
|
||||
@daily Run once a day, same as 00 00 * * *.
|
||||
@hourly Run once an hour, same as 00 * * * *.
|
||||
|
||||
Read Also: [11 Commands to Schedule Cron Jobs in RHEL 7][3]
|
||||
|
||||
### Locating and Checking Logs ###
|
||||
|
||||
System logs are located (and rotated) inside the /var/log directory. According to the Linux Filesystem Hierarchy Standard, this directory contains miscellaneous log files, which are written to it or an appropriate subdirectory (such as audit, httpd, or samba in the image below) by the corresponding daemons during system operation:
|
||||
|
||||
# ls /var/log
|
||||
|
||||
|
||||
|
||||
Linux Log Files Location
|
||||
|
||||
Other interesting logs are [dmesg][4] (contains all messages from kernel ring buffer), secure (logs connection attempts that require user authentication), messages (system-wide messages) and wtmp (records of all user logins and logouts).
|
||||
|
||||
Logs are very important in that they allow you to have a glimpse of what is going on at all times in your system, and what has happened in the past. They represent a priceless tool to troubleshoot and monitor a Linux server, and thus are often used with the `tail -f command` to display events, in real time, as they happen and are recorded in a log.
|
||||
|
||||
For example, if you want to display kernel-related events, type the following command:
|
||||
|
||||
# tail -f /var/log/dmesg
|
||||
|
||||
Same if you want to view access to your web server:
|
||||
|
||||
# tail -f /var/log/httpd/access.log
|
||||
|
||||
### Summary ###
|
||||
|
||||
If you know how to efficiently manage packages, schedule tasks, and where to look for information about the current and past operation of your system you can rest assure that you will not run into surprises very often. I hope this article has helped you learn or refresh your knowledge about these basic skills.
|
||||
|
||||
Don’t hesitate to drop us a line using the contact form below if you have any questions or comments.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/yum-package-management-cron-job-scheduling-monitoring-linux-logs/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:http://www.tecmint.com/20-linux-yum-yellowdog-updater-modified-commands-for-package-mangement/
|
||||
[2]:http://www.tecmint.com/20-practical-examples-of-rpm-commands-in-linux/
|
||||
[3]:http://www.tecmint.com/11-cron-scheduling-task-examples-in-linux/
|
||||
[4]:http://www.tecmint.com/dmesg-commands/
|
||||
@ -0,0 +1,191 @@
|
||||
RHCSA Series: Firewall Essentials and Network Traffic Control Using FirewallD and Iptables – Part 11
|
||||
================================================================================
|
||||
In simple words, a firewall is a security system that controls the incoming and outgoing traffic in a network based on a set of predefined rules (such as the packet destination / source or type of traffic, for example).
|
||||
|
||||
|
||||
|
||||
RHCSA: Control Network Traffic with FirewallD and Iptables – Part 11
|
||||
|
||||
In this article we will review the basics of firewalld, the default dynamic firewall daemon in Red Hat Enterprise Linux 7, and iptables service, the legacy firewall service for Linux, with which most system and network administrators are well acquainted, and which is also available in RHEL 7.
|
||||
|
||||
### A Comparison Between FirewallD and Iptables ###
|
||||
|
||||
Under the hood, both firewalld and the iptables service talk to the netfilter framework in the kernel through the same interface, not surprisingly, the iptables command. However, as opposed to the iptables service, firewalld can change the settings during normal system operation without existing connections being lost.
|
||||
|
||||
Firewalld should be installed by default in your RHEL system, though it may not be running. You can verify with the following commands (firewall-config is the user interface configuration tool):
|
||||
|
||||
# yum info firewalld firewall-config
|
||||
|
||||
|
||||
|
||||
Check FirewallD Information
|
||||
|
||||
and,
|
||||
|
||||
# systemctl status -l firewalld.service
|
||||
|
||||
|
||||
|
||||
Check FirewallD Status
|
||||
|
||||
On the other hand, the iptables service is not included by default, but can be installed through.
|
||||
|
||||
# yum update && yum install iptables-services
|
||||
|
||||
Both daemons can be started and enabled to start on boot with the usual systemd commands:
|
||||
|
||||
# systemctl start firewalld.service | iptables-service.service
|
||||
# systemctl enable firewalld.service | iptables-service.service
|
||||
|
||||
Read Also: [Useful Commands to Manage Systemd Services][1]
|
||||
|
||||
As for the configuration files, the iptables service uses `/etc/sysconfig/iptables` (which will not exist if the package is not installed in your system). On a RHEL 7 box used as a cluster node, this file looks as follows:
|
||||
|
||||
|
||||
|
||||
Iptables Firewall Configuration
|
||||
|
||||
Whereas firewalld store its configuration across two directories, `/usr/lib/firewalld` and `/etc/firewalld`:
|
||||
|
||||
# ls /usr/lib/firewalld /etc/firewalld
|
||||
|
||||
|
||||
|
||||
FirewallD Configuration
|
||||
|
||||
We will examine these configuration files further later in this article, after we add a few rules here and there. By now it will suffice to remind you that you can always find more information about both tools with.
|
||||
|
||||
# man firewalld.conf
|
||||
# man firewall-cmd
|
||||
# man iptables
|
||||
|
||||
Other than that, remember to take a look at [Reviewing Essential Commands & System Documentation – Part 1][2] of the current series, where I described several sources where you can get information about the packages installed on your RHEL 7 system.
|
||||
|
||||
### Using Iptables to Control Network Traffic ###
|
||||
|
||||
You may want to refer to [Configure Iptables Firewall – Part 8][3] of the Linux Foundation Certified Engineer (LFCE) series to refresh your memory about iptables internals before proceeding further. Thus, we will be able to jump in right into the examples.
|
||||
|
||||
**Example 1: Allowing both incoming and outgoing web traffic**
|
||||
|
||||
TCP ports 80 and 443 are the default ports used by the Apache web server to handle normal (HTTP) and secure (HTTPS) web traffic. You can allow incoming and outgoing web traffic through both ports on the enp0s3 interface as follows:
|
||||
|
||||
# iptables -A INPUT -i enp0s3 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
|
||||
# iptables -A OUTPUT -o enp0s3 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
|
||||
# iptables -A INPUT -i enp0s3 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
|
||||
# iptables -A OUTPUT -o enp0s3 -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT
|
||||
|
||||
**Example 2: Block all (or some) incoming connections from a specific network**
|
||||
|
||||
There may be times when you need to block all (or some) type of traffic originating from a specific network, say 192.168.1.0/24 for example:
|
||||
|
||||
# iptables -I INPUT -s 192.168.1.0/24 -j DROP
|
||||
|
||||
will drop all packages coming from the 192.168.1.0/24 network, whereas,
|
||||
|
||||
# iptables -A INPUT -s 192.168.1.0/24 --dport 22 -j ACCEPT
|
||||
|
||||
will only allow incoming traffic through port 22.
|
||||
|
||||
**Example 3: Redirect incoming traffic to another destination**
|
||||
|
||||
If you use your RHEL 7 box not only as a software firewall, but also as the actual hardware-based one, so that it sits between two distinct networks, IP forwarding must have been already enabled in your system. If not, you need to edit `/etc/sysctl.conf` and set the value of net.ipv4.ip_forward to 1, as follows:
|
||||
|
||||
net.ipv4.ip_forward = 1
|
||||
|
||||
then save the change, close your text editor and finally run the following command to apply the change:
|
||||
|
||||
# sysctl -p /etc/sysctl.conf
|
||||
|
||||
For example, you may have a printer installed at an internal box with IP 192.168.0.10, with the CUPS service listening on port 631 (both on the print server and on your firewall). In order to forward print requests from clients on the other side of the firewall, you should add the following iptables rule:
|
||||
|
||||
# iptables -t nat -A PREROUTING -i enp0s3 -p tcp --dport 631 -j DNAT --to 192.168.0.10:631
|
||||
|
||||
Please keep in mind that iptables reads its rules sequentially, so make sure the default policies or later rules do not override those outlined in the examples above.
|
||||
|
||||
### Getting Started with FirewallD ###
|
||||
|
||||
One of the changes introduced with firewalld are zones. This concept allows to separate networks into different zones level of trust the user has decided to place on the devices and traffic within that network.
|
||||
|
||||
To list the active zones:
|
||||
|
||||
# firewall-cmd --get-active-zones
|
||||
|
||||
In the example below, the public zone is active, and the enp0s3 interface has been assigned to it automatically. To view all the information about a particular zone:
|
||||
|
||||
# firewall-cmd --zone=public --list-all
|
||||
|
||||
|
||||
|
||||
List all FirewallD Zones
|
||||
|
||||
Since you can read more about zones in the [RHEL 7 Security guide][4], we will only list some specific examples here.
|
||||
|
||||
**Example 4: Allowing services through the firewall**
|
||||
|
||||
To get a list of the supported services, use.
|
||||
|
||||
# firewall-cmd --get-services
|
||||
|
||||
|
||||
|
||||
List All Supported Services
|
||||
|
||||
To allow http and https web traffic through the firewall, effective immediately and on subsequent boots:
|
||||
|
||||
# firewall-cmd --zone=MyZone --add-service=http
|
||||
# firewall-cmd --zone=MyZone --permanent --add-service=http
|
||||
# firewall-cmd --zone=MyZone --add-service=https
|
||||
# firewall-cmd --zone=MyZone --permanent --add-service=https
|
||||
# firewall-cmd --reload
|
||||
|
||||
If code>–zone is omitted, the default zone (you can check with firewall-cmd –get-default-zone) is used.
|
||||
|
||||
To remove the rule, replace the word add with remove in the above commands.
|
||||
|
||||
**Example 5: IP / Port forwarding**
|
||||
|
||||
First off, you need to find out if masquerading is enabled for the desired zone:
|
||||
|
||||
# firewall-cmd --zone=MyZone --query-masquerade
|
||||
|
||||
In the image below, we can see that masquerading is enabled for the external zone, but not for public:
|
||||
|
||||
|
||||
|
||||
Check Masquerading Status
|
||||
|
||||
You can either enable masquerading for public:
|
||||
|
||||
# firewall-cmd --zone=public --add-masquerade
|
||||
|
||||
or use masquerading in external. Here’s what we would do to replicate Example 3 with firewalld:
|
||||
|
||||
# firewall-cmd --zone=external --add-forward-port=port=631:proto=tcp:toport=631:toaddr=192.168.0.10
|
||||
|
||||
And don’t forget to reload the firewall.
|
||||
|
||||
You can find further examples on [Part 9][5] of the RHCSA series, where we explained how to allow or disable the ports that are usually used by a web server and a ftp server, and how to change the corresponding rule when the default port for those services are changed. In addition, you may want to refer to the firewalld wiki for further examples.
|
||||
|
||||
Read Also: [Useful FirewallD Examples to Configure Firewall in RHEL 7][6]
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
In this article we have explained what a firewall is, what are the available services to implement one in RHEL 7, and provided a few examples that can help you get started with this task. If you have any comments, suggestions, or questions, feel free to let us know using the form below. Thank you in advance!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/firewalld-vs-iptables-and-control-network-traffic-in-firewall/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:http://www.tecmint.com/manage-services-using-systemd-and-systemctl-in-linux/
|
||||
[2]:http://www.tecmint.com/rhcsa-exam-reviewing-essential-commands-system-documentation/
|
||||
[3]:http://www.tecmint.com/configure-iptables-firewall/
|
||||
[4]:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html
|
||||
[5]:http://www.tecmint.com/rhcsa-series-install-and-secure-apache-web-server-and-ftp-in-rhel/
|
||||
[6]:http://www.tecmint.com/firewalld-rules-for-centos-7/
|
||||
@ -0,0 +1,142 @@
|
||||
RHCSA Series: Automate RHEL 7 Installations Using ‘Kickstart’ – Part 12
|
||||
================================================================================
|
||||
Linux servers are rarely standalone boxes. Whether it is in a datacenter or in a lab environment, chances are that you have had to install several machines that will interact one with another in some way. If you multiply the time that it takes to install Red Hat Enterprise Linux 7 manually on a single server by the number of boxes that you need to set up, this can lead to a rather lengthy effort that can be avoided through the use of an unattended installation tool known as kickstart.
|
||||
|
||||
In this article we will show what you need to use kickstart utility so that you can forget about babysitting servers during the installation process.
|
||||
|
||||
|
||||
|
||||
RHCSA: Automatic Kickstart Installation of RHEL 7
|
||||
|
||||
#### Introducing Kickstart and Automated Installations ####
|
||||
|
||||
Kickstart is an automated installation method used primarily by Red Hat Enterprise Linux (and other Fedora spin-offs, such as CentOS, Oracle Linux, etc.) to execute unattended operating system installation and configuration. Thus, kickstart installations allow system administrators to have identical systems, as far as installed package groups and system configuration are concerned, while sparing them the hassle of having to manually install each of them.
|
||||
|
||||
### Preparing for a Kickstart Installation ###
|
||||
|
||||
To perform a kickstart installation, we need to follow these steps:
|
||||
|
||||
1. Create a Kickstart file, a plain text file with several predefined configuration options.
|
||||
|
||||
2. Make the Kickstart file available on removable media, a hard drive or a network location. The client will use the rhel-server-7.0-x86_64-boot.iso file, whereas you will need to make the full ISO image (rhel-server-7.0-x86_64-dvd.iso) available from a network resource, such as a HTTP of FTP server (in our present case, we will use another RHEL 7 box with IP 192.168.0.18).
|
||||
|
||||
3. Start the Kickstart installation
|
||||
|
||||
To create a kickstart file, login to your Red Hat Customer Portal account, and use the [Kickstart configuration tool][1] to choose the desired installation options. Read each one of them carefully before scrolling down, and choose what best fits your needs:
|
||||
|
||||
|
||||
|
||||
Kickstart Configuration Tool
|
||||
|
||||
If you specify that the installation should be performed either through HTTP, FTP, or NFS, make sure the firewall on the server allows those services.
|
||||
|
||||
Although you can use the Red Hat online tool to create a kickstart file, you can also create it manually using the following lines as reference. You will notice, for example, that the installation process will be in English, using the latin american keyboard layout and the America/Argentina/San_Luis time zone:
|
||||
|
||||
lang en_US
|
||||
keyboard la-latin1
|
||||
timezone America/Argentina/San_Luis --isUtc
|
||||
rootpw $1$5sOtDvRo$In4KTmX7OmcOW9HUvWtfn0 --iscrypted
|
||||
#platform x86, AMD64, or Intel EM64T
|
||||
text
|
||||
url --url=http://192.168.0.18//kickstart/media
|
||||
bootloader --location=mbr --append="rhgb quiet crashkernel=auto"
|
||||
zerombr
|
||||
clearpart --all --initlabel
|
||||
autopart
|
||||
auth --passalgo=sha512 --useshadow
|
||||
selinux --enforcing
|
||||
firewall --enabled
|
||||
firstboot --disable
|
||||
%packages
|
||||
@base
|
||||
@backup-server
|
||||
@print-server
|
||||
%end
|
||||
|
||||
In the online configuration tool, use 192.168.0.18 for HTTP Server and `/kickstart/tecmint.bin` for HTTP Directory in the Installation section after selecting HTTP as installation source. Finally, click the Download button at the right top corner to download the kickstart file.
|
||||
|
||||
In the kickstart sample file above, you need to pay careful attention to.
|
||||
|
||||
url --url=http://192.168.0.18//kickstart/media
|
||||
|
||||
That directory is where you need to extract the contents of the DVD or ISO installation media. Before doing that, we will mount the ISO installation file in /media/rhel as a loop device:
|
||||
|
||||
# mount -o loop /var/www/html/kickstart/rhel-server-7.0-x86_64-dvd.iso /media/rhel
|
||||
|
||||
|
||||
|
||||
Mount RHEL ISO Image
|
||||
|
||||
Next, copy all the contents of /media/rhel to /var/www/html/kickstart/media:
|
||||
|
||||
# cp -R /media/rhel /var/www/html/kickstart/media
|
||||
|
||||
When you’re done, the directory listing and disk usage of /var/www/html/kickstart/media should look as follows:
|
||||
|
||||
|
||||
|
||||
Kickstart Media Files
|
||||
|
||||
Now we’re ready to kick off the kickstart installation.
|
||||
|
||||
Regardless of how you choose to create the kickstart file, it’s always a good idea to check its syntax before proceeding with the installation. To do that, install the pykickstart package.
|
||||
|
||||
# yum update && yum install pykickstart
|
||||
|
||||
And then use the ksvalidator utility to check the file:
|
||||
|
||||
# ksvalidator /var/www/html/kickstart/tecmint.bin
|
||||
|
||||
If the syntax is correct, you will not get any output, whereas if there’s an error in the file, you will get a warning notice indicating the line where the syntax is not correct or unknown.
|
||||
|
||||
### Performing a Kickstart Installation ###
|
||||
|
||||
To start, boot your client using the rhel-server-7.0-x86_64-boot.iso file. When the initial screen appears, select Install Red Hat Enterprise Linux 7.0 and press the Tab key to append the following stanza and press Enter:
|
||||
|
||||
# inst.ks=http://192.168.0.18/kickstart/tecmint.bin
|
||||
|
||||
|
||||
|
||||
RHEL Kickstart Installation
|
||||
|
||||
Where tecmint.bin is the kickstart file created earlier.
|
||||
|
||||
When you press Enter, the automated installation will begin, and you will see the list of packages that are being installed (the number and the names will differ depending on your choice of programs and package groups):
|
||||
|
||||
|
||||
|
||||
Automatic Kickstart Installation of RHEL 7
|
||||
|
||||
When the automated process ends, you will be prompted to remove the installation media and then you will be able to boot into your newly installed system:
|
||||
|
||||
|
||||
|
||||
RHEL 7 Boot Screen
|
||||
|
||||
Although you can create your kickstart files manually as we mentioned earlier, you should consider using the recommended approach whenever possible. You can either use the online configuration tool, or the anaconda-ks.cfg file that is created by the installation process in root’s home directory.
|
||||
|
||||
This file actually is a kickstart file, so you may want to install the first box manually with all the desired options (maybe modify the logical volumes layout or the file system on top of each one) and then use the resulting anaconda-ks.cfg file to automate the installation of the rest.
|
||||
|
||||
In addition, using the online configuration tool or the anaconda-ks.cfg file to guide future installations will allow you to perform them using an encrypted root password out-of-the-box.
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
Now that you know how to create kickstart files and how to use them to automate the installation of Red Hat Enterprise Linux 7 servers, you can forget about babysitting the installation process. This will give you time to do other things, or perhaps some leisure time if you’re lucky.
|
||||
|
||||
Either way, let us know what you think about this article using the form below. Questions are also welcome!
|
||||
|
||||
Read Also: [Automated Installations of Multiple RHEL/CentOS 7 Distributions using PXE and Kickstart][2]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/automatic-rhel-installations-using-kickstart/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:https://access.redhat.com/labs/kickstartconfig/
|
||||
[2]:http://www.tecmint.com/multiple-centos-installations-using-kickstart/
|
||||
@ -0,0 +1,176 @@
|
||||
RHCSA Series: Mandatory Access Control Essentials with SELinux in RHEL 7 – Part 13
|
||||
================================================================================
|
||||
During this series we have explored in detail at least two access control methods: standard ugo/rwx permissions ([Manage Users and Groups – Part 3][1]) and access control lists ([Configure ACL’s on File Systems – Part 7][2]).
|
||||
|
||||
|
||||
|
||||
RHCSA Exam: SELinux Essentials and Control FileSystem Access
|
||||
|
||||
Although necessary as first level permissions and access control mechanisms, they have some limitations that are addressed by Security Enhanced Linux (aka SELinux for short).
|
||||
|
||||
One of such limitations is that a user can expose a file or directory to a security breach through a poorly elaborated chmod command and thus cause an unexpected propagation of access rights. As a result, any process started by that user can do as it pleases with the files owned by the user, where finally a malicious or otherwise compromised software can achieve root-level access to the entire system.
|
||||
|
||||
With those limitations in mind, the United States National Security Agency (NSA) first devised SELinux, a flexible mandatory access control method, to restrict the ability of processes to access or perform other operations on system objects (such as files, directories, network ports, etc) to the least permission model, which can be modified later as needed. In few words, each element of the system is given only the access required to function.
|
||||
|
||||
In RHEL 7, SELinux is incorporated into the kernel itself and is enabled in Enforcing mode by default. In this article we will explain briefly the basic concepts associated with SELinux and its operation.
|
||||
|
||||
### SELinux Modes ###
|
||||
|
||||
SELinux can operate in three different ways:
|
||||
|
||||
- Enforcing: SELinux denies access based on SELinux policy rules, a set of guidelines that control the security engine.
|
||||
- Permissive: SELinux does not deny access, but denials are logged for actions that would have been denied if running in enforcing mode.
|
||||
- Disabled (self-explanatory).
|
||||
|
||||
The `getenforce` command displays the current mode of SELinux, whereas `setenforce` (followed by a 1 or a 0) is used to change the mode to Enforcing or Permissive, respectively, during the current session only.
|
||||
|
||||
In order to achieve persistence across logouts and reboots, you will need to edit the `/etc/selinux/config` file and set the SELINUX variable to either enforcing, permissive, or disabled:
|
||||
|
||||
# getenforce
|
||||
# setenforce 0
|
||||
# getenforce
|
||||
# setenforce 1
|
||||
# getenforce
|
||||
# cat /etc/selinux/config
|
||||
|
||||
|
||||
|
||||
Set SELinux Mode
|
||||
|
||||
Typically you will use setenforce to toggle between SELinux modes (enforcing to permissive and back) as a first troubleshooting step. If SELinux is currently set to enforcing while you’re experiencing a certain problem, and the same goes away when you set it to permissive, you can be confident you’re looking at a SELinux permissions issue.
|
||||
|
||||
### SELinux Contexts ###
|
||||
|
||||
A SELinux context consists of an access control environment where decisions are made based on SELinux user, role, and type (and optionally a level):
|
||||
|
||||
- A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
|
||||
- The concept of role acts as an intermediary between domains and SELinux users in that it defines which process domains and file types can be accessed. This will shield your system against vulnerability to privilege escalation attacks.
|
||||
- A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.
|
||||
|
||||
Let’s see how all of that works through the following examples.
|
||||
|
||||
**EXAMPLE 1: Changing the default port for the sshd daemon**
|
||||
|
||||
In [Securing SSH – Part 8][3] we explained that changing the default port where sshd listens on is one of the first security measures to secure your server against external attacks. Let’s edit the `/etc/ssh/sshd_config` file and set the port to 9999:
|
||||
|
||||
Port 9999
|
||||
|
||||
Save the changes, and restart sshd:
|
||||
|
||||
# systemctl restart sshd
|
||||
# systemctl status sshd
|
||||
|
||||
|
||||
|
||||
Restart SSH Service
|
||||
|
||||
As you can see, sshd has failed to start. But what happened?
|
||||
|
||||
A quick inspection of `/var/log/audit/audit.log` indicates that sshd has been denied permissions to start on port 9999 (SELinux log messages include the word “AVC” so that they might be easily identified from other messages) because that is a reserved port for the JBoss Management service:
|
||||
|
||||
# cat /var/log/audit/audit.log | grep AVC | tail -1
|
||||
|
||||
|
||||
|
||||
Inspect SSH Logs
|
||||
|
||||
At this point you could disable SELinux (but don’t!) as explained earlier and try to start sshd again, and it should work. However, the semanage utility can tell us what we need to change in order for us to be able to start sshd in whatever port we choose without issues.
|
||||
|
||||
Run,
|
||||
|
||||
# semanage port -l | grep ssh
|
||||
|
||||
to get a list of the ports where SELinux allows sshd to listen on.
|
||||
|
||||
|
||||
|
||||
Semanage Tool
|
||||
|
||||
So let’s change the port in /etc/ssh/sshd_config to Port 9998, add the port to the ssh_port_t context, and then restart the service:
|
||||
|
||||
# semanage port -a -t ssh_port_t -p tcp 9998
|
||||
# systemctl restart sshd
|
||||
# systemctl is-active sshd
|
||||
|
||||
|
||||
|
||||
Semanage Add Port
|
||||
|
||||
As you can see, the service was started successfully this time. This example illustrates the fact that SELinux controls the TCP port number to its own port type internal definitions.
|
||||
|
||||
**EXAMPLE 2: Allowing httpd to send access sendmail**
|
||||
|
||||
This is an example of SELinux managing a process accessing another process. If you were to implement mod_security and mod_evasive along with Apache in your RHEL 7 server, you need to allow httpd to access sendmail in order to send a mail notification in the wake of a (D)DoS attack. In the following command, omit the -P flag if you do not want the change to be persistent across reboots.
|
||||
|
||||
# semanage boolean -1 | grep httpd_can_sendmail
|
||||
# setsebool -P httpd_can_sendmail 1
|
||||
# semanage boolean -1 | grep httpd_can_sendmail
|
||||
|
||||
|
||||
|
||||
Allow Apache to Send Mails
|
||||
|
||||
As you can tell from the above example, SELinux boolean settings (or just booleans) are true / false rules embedded into SELinux policies. You can list all the booleans with `semanage boolean -l`, and alternatively pipe it to grep in order to filter the output.
|
||||
|
||||
**EXAMPLE 3: Serving a static site from a directory other than the default one**
|
||||
|
||||
Suppose you are serving a static website using a different directory than the default one (`/var/www/html`), say /websites (this could be the case if you’re storing your web files in a shared network drive, for example, and need to mount it at /websites).
|
||||
|
||||
a). Create an index.html file inside /websites with the following contents:
|
||||
|
||||
<html>
|
||||
<h2>SELinux test</h2>
|
||||
</html>
|
||||
|
||||
If you do,
|
||||
|
||||
# ls -lZ /websites/index.html
|
||||
|
||||
you will see that the index.html file has been labeled with the default_t SELinux type, which Apache can’t access:
|
||||
|
||||
|
||||
|
||||
Check SELinux File Permission
|
||||
|
||||
b). Change the DocumentRoot directive in `/etc/httpd/conf/httpd.conf` to /websites and don’t forget to update the corresponding Directory block. Then, restart Apache.
|
||||
|
||||
c). Browse to `http://<web server IP address>`, and you should get a 503 Forbidden HTTP response.
|
||||
|
||||
d). Next, change the label of /websites, recursively, to the httpd_sys_content_t type in order to grant Apache read-only access to that directory and its contents:
|
||||
|
||||
# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"
|
||||
|
||||
e). Finally, apply the SELinux policy created in d):
|
||||
|
||||
# restorecon -R -v /websites
|
||||
|
||||
Now restart Apache and browse to `http://<web server IP address>` again and you will see the html file displayed correctly:
|
||||
|
||||
|
||||
|
||||
Verify Apache Page
|
||||
|
||||
### Summary ###
|
||||
|
||||
In this article we have gone through the basics of SELinux. Note that due to the vastness of the subject, a full detailed explanation is not possible in a single article, but we believe that the principles outlined in this guide will help you to move on to more advanced topics should you wish to do so.
|
||||
|
||||
If I may, let me recommend two essential resources to start with: the [NSA SELinux page][4] and the [RHEL 7 SELinux User’s and Administrator’s][5] guide.
|
||||
|
||||
Don’t hesitate to let us know if you have any questions or comments.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.tecmint.com/selinux-essentials-and-control-filesystem-access/
|
||||
|
||||
作者：[Gabriel Cánepa][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.tecmint.com/author/gacanepa/
|
||||
[1]:http://www.tecmint.com/rhcsa-exam-manage-users-and-groups
|
||||
[2]:http://www.tecmint.com/rhcsa-exam-configure-acls-and-mount-nfs-samba-shares/
|
||||
[3]:http://www.tecmint.com/rhcsa-series-secure-ssh-set-hostname-enable-network-services-in-rhel-7/
|
||||
[4]:https://www.nsa.gov/research/selinux/index.shtml
|
||||
[5]:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/part_I-SELinux.html
|
||||
Loading…
Reference in New Issue
Block a user