Este conteúdo não está disponível no idioma selecionado.
Chapter 8. Securing network services
Red Hat Enterprise Linux supports many different types of network servers. Their network services can expose the system security to risks of various types of attacks, such as denial of service attacks (DoS), distributed denial of service attacks (DDoS), script vulnerability attacks, and buffer overflow attacks.
To increase the system security against attacks, it is important to monitor active network services that you use. For example, when a network service is running on a machine, its daemon listens for connections on network ports, and this can reduce the security. To limit exposure to attacks over the network, all services that are unused should be turned off.
8.1. Securing the rpcbind service
				The rpcbind service is a dynamic port-assignment daemon for remote procedure calls (RPC) services such as Network Information Service (NIS) and Network File System (NFS). Because it has weak authentication mechanisms and can assign a wide range of ports for the services it controls, it is important to secure rpcbind.
			
				You can secure rpcbind by restricting access to all networks and defining specific exceptions using firewall rules on the server.
			
- 
							The rpcbindservice is required onNFSv3servers.
- 
							The rpcbindservice is not required onNFSv4.
Prerequisites
- 
						The rpcbindpackage is installed.
- 
						The firewalldpackage is installed and the service is running.
Procedure
- Add firewall rules, for example: - Limit TCP connection and accept packages only from the - 192.168.0.0/24host via the- 111port:- firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop' - # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Limit TCP connection and accept packages only from local host via the - 111port:- firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept' - # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Limit UDP connection and accept packages only from the - 192.168.0.0/24host via the- 111port:- firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop' - # firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - To make the firewall settings permanent, use the - --permanentoption when adding firewall rules.
 
- Reload the firewall to apply the new rules: - firewall-cmd --reload - # firewall-cmd --reload- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
Verification
- List the firewall rules: - firewall-cmd --list-rich-rule - # firewall-cmd --list-rich-rule rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
8.2. Securing the rpc.mountd service
				The rpc.mountd daemon implements the server side of the NFS mount protocol. The NFS mount protocol is used by NFS version 3 (RFC 1813).
			
				You can secure the rpc.mountd service by adding firewall rules to the server. You can restrict access to all networks and define specific exceptions using firewall rules.
			
Prerequisites
- 
						The rpc.mountdpackage is installed.
- 
						The firewalldpackage is installed and the service is running.
Procedure
- Add firewall rules to the server, for example: - Accept - mountdconnections from the- 192.168.0.0/24host:- firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop' - # firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Accept - mountdconnections from the local host:- firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept' - # firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - To make the firewall settings permanent, use the - --permanentoption when adding firewall rules.
 
- Reload the firewall to apply the new rules: - firewall-cmd --reload - # firewall-cmd --reload- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
Verification
- List the firewall rules: - firewall-cmd --list-rich-rule - # firewall-cmd --list-rich-rule rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop rule family="ipv4" source address="127.0.0.1" service name="mountd" accept- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
8.3. Securing the NFS service
				You can secure Network File System version 4 (NFSv4) by authenticating and encrypting all file system operations using Kerberos. When using NFSv4 with Network Address Translation (NAT) or a firewall, you can turn off the delegations by modifying the /etc/default/nfs file. Delegation is a technique by which the server delegates the management of a file to a client. In contrast, NFSv3 do not use Kerberos for locking and mounting files.
			
				The NFS service sends the traffic using TCP in all versions of NFS. The service supports Kerberos user and group authentication, as part of the RPCSEC_GSS kernel module.
			
				NFS allows remote hosts to mount file systems over a network and interact with those file systems as if they are mounted locally. You can merge the resources on centralized servers and additionally customize NFS mount options in the /etc/nfsmount.conf file when sharing the file systems.
			
8.3.1. Export options for securing an NFS server
					The NFS server determines a list structure of directories and hosts about which file systems to export to which hosts in the /etc/exports file.
				
					You can use the following export options on the /etc/exports file:
				
- ro
- Exports the NFS volume as read-only.
- rw
- 
								Allows read and write requests on the NFS volume. Use this option cautiously because allowing write access increases the risk of attacks. If your scenario requires mounting the directories with the rwoption, make sure they are not writable for all users to reduce possible risks.
- root_squash
- 
								Maps requests from uid/gid0 to the anonymousuid/gid. This does not apply to any otheruidsorgidsthat might be equally sensitive, such as thebinuser or thestaffgroup.
- no_root_squash
- 
								Turns off root squashing. By default, NFS shares change the rootuser to thenobodyuser, which is an unprivileged user account. This changes the owner of all therootcreated files tonobody, which prevents the uploading of programs with thesetuidbit set. When using theno_root_squashoption, remote root users can change any file on the shared file system and leave applications infected by trojans for other users.
- secure
- 
								Restricts exports to reserved ports. By default, the server allows client communication only through reserved ports. However, it is easy for anyone to become a rootuser on a client on many networks, so it is rarely safe for the server to assume that communication through a reserved port is privileged. Therefore the restriction to reserved ports is of limited value; it is better to rely on Kerberos, firewalls, and restriction of exports to particular clients.
						Extra spaces in the syntax of the /etc/exports file can lead to major changes in the configuration.
					
						In the following example, the /tmp/nfs/ directory is shared with the bob.example.com host and has read and write permissions.
					
/tmp/nfs/ bob.example.com(rw)
/tmp/nfs/     bob.example.com(rw)
						The following example is the same as the previous one but shares the same directory to the bob.example.com host with read-only permissions and shares it to the world with read and write permissions due to a single space character after the hostname.
					
/tmp/nfs/ bob.example.com (rw)
/tmp/nfs/     bob.example.com (rw)
						You can check the shared directories on your system by entering the showmount -e <hostname> command.
					
Additionally, consider the following best practices when exporting an NFS server:
- Exporting home directories is a risk because some applications store passwords in plain text or in a weakly encrypted format. You can reduce the risk by reviewing and improving the application code.
- Some users do not set passwords on SSH keys which again leads to risks with home directories. You can reduce these risks by enforcing the use of passwords or using Kerberos.
- 
							Restrict the NFS exports only to required clients. Use the showmount -ecommand on the NFS server to review what the server is exporting. Do not export anything that is not specifically required.
- Do not allow unnecessary users to log in to a server to reduce the risk of attacks. You can periodically check who and what can access the server.
Export an entire file system because exporting a subdirectory of a file system is not secure. An attacker might access the unexported part of a partially-exported file system.
8.3.2. Mount options for securing an NFS client
					You can pass the following options to the mount command to increase the security of NFS-based clients:
				
- nosuid
- 
								Use the nosuidoption to disable theset-user-identifierorset-group-identifierbits. This prevents remote users from gaining higher privileges by running asetuidprogram and you can use this option opposite tosetuidoption.
- noexec
- 
								Use the noexecoption to disable all executable files on the client. Use this to prevent users from accidentally executing files placed in the shared file system.
- nodev
- 
								Use the nodevoption to prevent the client’s processing of device files as a hardware device.
- resvport
- 
								Use the resvportoption to restrict communication to a reserved port and you can use a privileged source port to communicate with the server. The reserved ports are reserved for privileged users and processes such as therootuser.
- sec
- 
								Use the secoption on the NFS server to choose the RPCGSS security flavor for accessing files on the mount point. Valid security flavors arenone,sys,krb5,krb5i, andkrb5p.
						The MIT Kerberos libraries provided by the krb5-libs package do not support the Data Encryption Standard (DES) algorithm in new deployments. DES is deprecated and disabled by default in Kerberos libraries because of security and compatibility reasons. Use newer and more secure algorithms instead of DES, unless your environment requires DES for compatibility reasons.
					
8.3.3. Securing NFS with firewall
To secure the firewall on an NFS server, keep only the required ports open. Do not use the NFS connection port numbers for any other service.
Prerequisites
- 
							The nfs-utilspackage is installed.
- 
							The firewalldpackage is installed and running.
Procedure
- 
							On NFSv4, the firewall must open TCP port 2049.
- On NFSv3, open four additional ports with - 2049:- rpcbindservice assigns the NFS ports dynamically, which might cause problems when creating firewall rules. To simplify this process, use the- /etc/nfs.conffile to specify which ports to use:- 
											Set TCP and UDP port for mountd(rpc.mountd) in the[mountd]section inport=<value>format.
- 
											Set TCP and UDP port for statd(rpc.statd) in the[statd]section inport=<value>format.
 
- 
											Set TCP and UDP port for 
- Set the TCP and UDP port for the NFS lock manager ( - nlockmgr) in the- /etc/nfs.conffile:- 
											Set TCP port for nlockmgr(rpc.statd) in the[lockd]section inport=valueformat. Alternatively, you can use thenlm_tcpportoption in the/etc/modprobe.d/lockd.conffile.
- 
											Set UDP port for nlockmgr(rpc.statd) in the[lockd]section inudp-port=valueformat. Alternatively, you can use thenlm_udpportoption in the/etc/modprobe.d/lockd.conffile.
 
- 
											Set TCP port for 
 
Verification
- List the active ports and RPC programs on the NFS server: - rpcinfo -p - $ rpcinfo -p- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
8.4. Securing the FTP service
You can use the File Transfer Protocol (FTP) to transfer files over a network. Because all FTP transactions with the server, including user authentication, are unencrypted, make sure it is configured securely.
Red Hat Enterprise Linux provides two FTP servers:
- Red Hat Content Accelerator (tux)
- A kernel-space web server with FTP capabilities.
- Very Secure FTP Daemon (vsftpd)
- A standalone, security-oriented implementation of the FTP service.
				The following security guidelines are for setting up the vsftpd FTP service.
			
8.4.1. Securing the FTP greeting banner
When a user connects to the FTP service, FTP shows a greeting banner, which by default includes version information. Attackers might use this information to identify weaknesses in the system. You can hide this information by changing the default banner.
					You can define a custom banner by editing the /etc/banners/ftp.msg file to either directly include a single-line message, or to refer to a separate file, which can contain a multi-line message.
				
Procedure
- To define a single line message, add the following option to the - /etc/vsftpd/vsftpd.conffile:- ftpd_banner=Hello, all activity on ftp.example.com is logged. - ftpd_banner=Hello, all activity on ftp.example.com is logged.- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- To define a message in a separate file: - Create a - .msgfile which contains the banner message, for example- /etc/banners/ftp.msg:- ######### Hello, all activity on ftp.example.com is logged. ######### - ######### Hello, all activity on ftp.example.com is logged. #########- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - To simplify the management of multiple banners, place all banners into the - /etc/banners/directory.
- Add the path to the banner file to the - banner_fileoption in the- /etc/vsftpd/vsftpd.conffile:- banner_file=/etc/banners/ftp.msg - banner_file=/etc/banners/ftp.msg- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
Verification
- Display the modified banner: - ftp localhost - $ ftp localhost Trying ::1… Connected to localhost (::1). Hello, all activity on ftp.example.com is logged.- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
8.4.2. Preventing anonymous access and uploads in FTP
					By default, installing the vsftpd package creates the /var/ftp/ directory and a directory tree for anonymous users with read-only permissions on the directories. Because anonymous users can access the data, do not store sensitive data in these directories.
				
					To increase the security of the system, you can configure the FTP server to allow anonymous users to upload files to a specific directory and prevent anonymous users from reading data. In the following procedure, the anonymous user must be able to upload files in the directory owned by the root user but not change it.
				
Procedure
- Create a write-only directory in the - /var/ftp/pub/directory:- mkdir /var/ftp/pub/upload chmod 730 /var/ftp/pub/upload ls -ld /var/ftp/pub/upload - # mkdir /var/ftp/pub/upload # chmod 730 /var/ftp/pub/upload # ls -ld /var/ftp/pub/upload drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Add the following lines to the - /etc/vsftpd/vsftpd.conffile:- anon_upload_enable=YES anonymous_enable=YES - anon_upload_enable=YES anonymous_enable=YES- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
							Optional: If your system has SELinux enabled and enforcing, enable SELinux boolean attributes allow_ftpd_anon_writeandallow_ftpd_full_access.
Allowing anonymous users to read and write in directories might lead to the server becoming a repository for stolen software.
8.4.3. Securing user accounts for FTP
FTP transmits usernames and passwords unencrypted over insecure networks for authentication. You can improve the security of FTP by denying system users access to the server from their user accounts.
Perform as many of the following steps as applicable for your configuration.
Procedure
- Disable all user accounts in the - vsftpdserver, by adding the following line to the- /etc/vsftpd/vsftpd.conffile:- local_enable=NO - local_enable=NO- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
							Disable FTP access for specific accounts or specific groups of accounts, such as the rootuser and users withsudoprivileges, by adding the usernames to the/etc/pam.d/vsftpdPAM configuration file.
- 
							Disable user accounts, by adding the usernames to the /etc/vsftpd/ftpusersfile.
8.5. Securing HTTP servers
8.5.1. Security enhancements in httpd.conf
					You can enhance the security of the Apache HTTP server by configuring security options in the /etc/httpd/conf/httpd.conf file.
				
Always verify that all scripts running on the system work correctly before putting them into production.
					Ensure that only the root user has write permissions to any directory containing scripts or Common Gateway Interfaces (CGI). To change the directory ownership to root with write permissions, enter the following commands:
				
chown root <directory_name> chmod 755 <directory_name>
# chown root <directory_name>
# chmod 755 <directory_name>
					In the /etc/httpd/conf/httpd.conf file, you can configure the following options:
				
- FollowSymLinks
- This directive is enabled by default and follows symbolic links in the directory.
- Indexes
- This directive is enabled by default. Disable this directive to prevent visitors from browsing files on the server.
- UserDir
- 
								This directive is disabled by default because it can confirm the presence of a user account on the system. To activate user directory browsing for all user directories other than /root/, use theUserDir enabledandUserDir disabledroot directives. To add users to the list of disabled accounts, add a space-delimited list of users on theUserDir disabledline.
- ServerTokens
- This directive controls the server response header field which is sent back to clients. You can use the following parameters to customize the information: - ServerTokens Full
- Provides all available information such as web server version number, server operating system details, installed Apache modules, for example: - Apache/2.4.37 (Red Hat Enterprise Linux) MyMod/1.2 - Apache/2.4.37 (Red Hat Enterprise Linux) MyMod/1.2- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ServerTokens Full-Release
- Provides all available information with release versions, for example: - Apache/2.4.37 (Red Hat Enterprise Linux) (Release 41.module+el8.5.0+11772+c8e0c271) - Apache/2.4.37 (Red Hat Enterprise Linux) (Release 41.module+el8.5.0+11772+c8e0c271)- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ServerTokens Prod / ServerTokens ProductOnly
- Provides the web server name, for example: - Apache - Apache- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ServerTokens Major
- Provides the web server major release version, for example: - Apache/2 - Apache/2- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ServerTokens Minor
- Provides the web server minor release version, for example: - Apache/2.4 - Apache/2.4- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ServerTokens Min/- ServerTokens Minimal
- Provides the web server minimal release version, for example: - Apache/2.4.37 - Apache/2.4.37- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ServerTokens OS
- Provides the web server release version and operating system, for example: - Apache/2.4.37 (Red Hat Enterprise Linux) - Apache/2.4.37 (Red Hat Enterprise Linux)- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Use the - ServerTokens Prodoption to reduce the risk of attackers gaining any valuable information about your system.
 
						Do not remove the IncludesNoExec directive. By default, the Server Side Includes (SSI) module cannot execute commands. Changing this can allow an attacker to enter commands on the system.
					
Removing httpd modules
						You can remove the httpd modules to limit the functionality of the HTTP server. To do so, edit configuration files in the /etc/httpd/conf.modules.d/ or /etc/httpd/conf.d/ directory. For example, to remove the proxy module:
					
echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf
echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf8.5.2. Securing the Nginx server configuration
Nginx is a high-performance HTTP and proxy server. You can harden your Nginx configuration with the following configuration options.
Procedure
- To disable version strings, modify the - server_tokensconfiguration option:- server_tokens off; - server_tokens off;- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - This option stops displaying additional details such as server version number. This configuration displays only the server name in all requests served by Nginx, for example: - curl -sI http://localhost | grep Server - $ curl -sI http://localhost | grep Server Server: nginx- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Add extra security headers that mitigate certain known web application vulnerabilities in specific - /etc/nginx/conf files:- For example, the - X-Frame-Optionsheader option denies any page outside of your domain to frame any content served by Nginx, mitigating clickjacking attacks:- add_header X-Frame-Options "SAMEORIGIN"; - add_header X-Frame-Options "SAMEORIGIN";- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- For example, the - x-content-typeheader prevents MIME-type sniffing in certain older browsers:- add_header X-Content-Type-Options nosniff; - add_header X-Content-Type-Options nosniff;- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- For example, the - X-XSS-Protectionheader enables Cross-Site Scripting (XSS) filtering, which prevents browsers from rendering potentially malicious content included in a response by Nginx:- add_header X-XSS-Protection "1; mode=block"; - add_header X-XSS-Protection "1; mode=block";- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- You can limit the services exposed to the public and limit what they do and accept from the visitors, for example: - limit_except GET { allow 192.168.1.0/32; deny all; }- limit_except GET { allow 192.168.1.0/32; deny all; }- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - The snippet will limit access to all methods except - GETand- HEAD.
- You can disable HTTP methods, for example: - Allow GET, PUT, POST; return "405 Method Not Allowed" for all others. - # Allow GET, PUT, POST; return "405 Method Not Allowed" for all others. if ( $request_method !~ ^(GET|PUT|POST)$ ) { return 405; }- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- You can configure SSL to protect the data served by your Nginx web server, consider serving it over HTTPS only. Furthermore, you can generate a secure configuration profile for enabling SSL in your Nginx server using the Mozilla SSL Configuration Generator. The generated configuration ensures that known vulnerable protocols (for example, SSLv2 and SSLv3), ciphers, and hashing algorithms (for example, 3DES and MD5) are disabled. You can also use the SSL Server Test to verify that your configuration meets modern security requirements.
8.6. Securing PostgreSQL by limiting access to authenticated local users
				PostgreSQL is an object-relational database management system (DBMS). In Red Hat Enterprise Linux, PostgreSQL is provided by the postgresql-server package.
			
				You can reduce the risks of attacks by configuring client authentication. The pg_hba.conf configuration file stored in the database cluster’s data directory controls the client authentication. Follow the procedure to configure PostgreSQL for host-based authentication.
			
Procedure
- Install PostgreSQL: - dnf install postgresql-server - # dnf install postgresql-server- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Initialize a database storage area using one of the following options: - Using the - initdbutility:- initdb -D /home/postgresql/db1/ - $ initdb -D /home/postgresql/db1/- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - The - initdbcommand with the- -Doption creates the directory you specify if it does not already exist, for example- /home/postgresql/db1/. This directory then contains all the data stored in the database and also the client authentication configuration file.
- Using the - postgresql-setupscript:- postgresql-setup --initdb - $ postgresql-setup --initdb- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - By default, the script uses the - /var/lib/pgsql/data/directory. This script helps system administrators with basic database cluster administration.
 
- To allow any authenticated local users to access any database with their usernames, modify the following line in the - pg_hba.conffile:- local all all trust - local all all trust- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - This can be problematic when you use layered applications that create database users and no local users. If you do not want to explicitly control all user names on the system, remove the - localline entry from the- pg_hba.conffile.
- Restart the database to apply the changes: - systemctl restart postgresql - # systemctl restart postgresql- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - The previous command updates the database and also verifies the syntax of the configuration file. 
8.7. Securing the Memcached service
Memcached is an open source, high-performance, distributed memory object caching system. It can improve the performance of dynamic web applications by lowering database load.
Memcached is an in-memory key-value store for small chunks of arbitrary data, such as strings and objects, from results of database calls, API calls, or page rendering. Memcached allows assigning memory from underutilized areas to applications that require more memory.
In 2018, vulnerabilities of DDoS amplification attacks by exploiting Memcached servers exposed to the public internet were discovered. These attacks took advantage of Memcached communication using the UDP protocol for transport. The attack was effective because of the high amplification ratio where a request with the size of a few hundred bytes could generate a response of a few megabytes or even hundreds of megabytes in size.
				In most situations, the memcached service does not need to be exposed to the public Internet. Such exposure may have its own security problems, allowing remote attackers to leak or modify information stored in Memcached.
			
8.7.1. Hardening Memcached against DDoS
To mitigate security risks, perform as many of the following steps as applicable for your configuration.
Procedure
- Configure a firewall in your LAN. If your Memcached server should be accessible only in your local network, do not route external traffic to ports used by the - memcachedservice. For example, remove the default port- 11211from the list of allowed ports:- firewall-cmd --remove-port=11211/udp firewall-cmd --runtime-to-permanent - # firewall-cmd --remove-port=11211/udp # firewall-cmd --runtime-to-permanent- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- If you use a single Memcached server on the same machine as your application, set up - memcachedto listen to localhost traffic only. Modify the- OPTIONSvalue in the- /etc/sysconfig/memcachedfile:- OPTIONS="-l 127.0.0.1,::1" - OPTIONS="-l 127.0.0.1,::1"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Enable Simple Authentication and Security Layer (SASL) authentication: - Modify or add the - /etc/sasl2/memcached.conffile:- sasldb_path: /path.to/memcached.sasldb - sasldb_path: /path.to/memcached.sasldb- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Add an account in the SASL database: - saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb - # saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Ensure that the database is accessible for the - memcacheduser and group:- chown memcached:memcached /path.to/memcached.sasldb - # chown memcached:memcached /path.to/memcached.sasldb- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Enable SASL support in Memcached by adding the - -Svalue to the- OPTIONSparameter in the- /etc/sysconfig/memcachedfile:- OPTIONS="-S" - OPTIONS="-S"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Restart the Memcached server to apply the changes: - systemctl restart memcached - # systemctl restart memcached- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Add the username and password created in the SASL database to the Memcached client configuration of your application.
 
- Encrypt communication between Memcached clients and servers with TLS: - Enable encrypted communication between Memcached clients and servers with TLS by adding the - -Zvalue to the- OPTIONSparameter in the- /etc/sysconfig/memcachedfile:- OPTIONS="-Z" - OPTIONS="-Z"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
									Add the certificate chain file path in the PEM format using the -o ssl_chain_certoption.
- 
									Add a private key file path using the -o ssl_keyoption.
 
8.8. Securing the Postfix service
Postfix is a mail transfer agent (MTA) that uses the Simple Mail Transfer Protocol (SMTP) to deliver electronic messages between other MTAs and to email clients or delivery agents. Although MTAs can encrypt traffic between one another, they might not do so by default. You can also mitigate risks to various attacks by changing setting to more secure values.
8.8.2. Postfix configuration options for limiting DoS attacks
					An attacker can flood the server with traffic, or send information that triggers a crash, causing a denial of service (DoS) attack. You can configure your system to reduce the risk of such attacks by setting limits in the /etc/postfix/main.cf file. You can change the value of the existing directives or you can add new directives with custom values in the <directive> = <value> format.
				
Use the following list of directives for limiting a DoS attack:
- smtpd_client_connection_rate_limit
- 
								Limits the maximum number of connection attempts any client can make to this service per time unit. The default value is 0, which means a client can make as many connections per time unit as Postfix can accept. By default, the directive excludes clients in trusted networks.
- anvil_rate_time_unit
- 
								Defines a time unit to calculate the rate limit. The default value is 60seconds.
- smtpd_client_event_limit_exceptions
- Excludes clients from the connection and rate limit commands. By default, the directive excludes clients in trusted networks.
- smtpd_client_message_rate_limit
- Defines the maximum number of message deliveries from client to request per time unit (regardless of whether or not Postfix actually accepts those messages).
- default_process_limit
- 
								Defines the default maximum number of Postfix child processes that provide a given service. You can ignore this rule for specific services in the master.cffile. By default, the value is100.
- queue_minfree
- 
								Defines the minimum amount of free space required to receive mail in the queue file system. The directive is currently used by the Postfix SMTP server to decide if it accepts any mail at all. By default, the Postfix SMTP server rejects MAIL FROMcommands when the amount of free space is less than 1.5 times themessage_size_limit. To specify a higher minimum free space limit, specify aqueue_minfreevalue that is at least 1.5 times themessage_size_limit. By default, thequeue_minfreevalue is0.
- header_size_limit
- 
								Defines the maximum amount of memory in bytes for storing a message header. If a header is large, it discards the excess header. By default, the value is 102400bytes.
- message_size_limit
- 
								Defines the maximum size of a message including the envelope information in bytes. By default, the value is 10240000bytes.
8.8.3. Configuring Postfix to use SASL
Postfix supports Simple Authentication and Security Layer (SASL) based SMTP Authentication (AUTH). SMTP AUTH is an extension of the Simple Mail Transfer Protocol. Currently, the Postfix SMTP server supports the SASL implementations in the following ways:
- Dovecot SASL
- The Postfix SMTP server can communicate with the Dovecot SASL implementation by using either a UNIX-domain socket or a TCP socket. Use this method if Postfix and Dovecot applications are running on separate machines.
- Cyrus SASL
- When enabled, SMTP clients must authenticate with the SMTP server by using an authentication method supported and accepted by both the server and the client.
Prerequisites
- 
							The dovecotpackage is installed on the system
Procedure
- Set up Dovecot: - Include the following lines in the - /etc/dovecot/conf.d/10-master.conffile:- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - The previous example uses UNIX-domain sockets for communication between Postfix and Dovecot. The example also assumes default Postfix SMTP server settings, which include the mail queue located in the - /var/spool/postfix/directory, and the application running under the- postfixuser and group.
- Optional: Set up Dovecot to listen for Postfix authentication requests through TCP: - service auth { inet_listener { port = <port_number> } }- service auth { inet_listener { port = <port_number> } }- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Specify the method that the email client uses to authenticate with Dovecot by editing the - auth_mechanismsparameter in- /etc/dovecot/conf.d/10-auth.conffile:- auth_mechanisms = plain login - auth_mechanisms = plain login- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - The - auth_mechanismsparameter supports different plain text and non-plain text authentication methods.
 
- Set up Postfix by modifying the - /etc/postfix/main.cffile:- Enable SMTP Authentication on the Postfix SMTP server: - smtpd_sasl_auth_enable = yes - smtpd_sasl_auth_enable = yes- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Enable the use of Dovecot SASL implementation for SMTP Authentication: - smtpd_sasl_type = dovecot - smtpd_sasl_type = dovecot- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Provide the authentication path relative to the Postfix queue directory. Note that the use of a relative path ensures that the configuration works regardless of whether the Postfix server runs in - chrootor not:- smtpd_sasl_path = private/auth - smtpd_sasl_path = private/auth- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - This step uses UNIX-domain sockets for communication between Postfix and Dovecot. - To configure Postfix to look for Dovecot on a different machine in case you use TCP sockets for communication, use configuration values similar to the following: - smtpd_sasl_path = inet: <IP_address> : <port_number> - smtpd_sasl_path = inet: <IP_address> : <port_number>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - In the previous example, replace the - <IP_address>with the IP address of the Dovecot machine and- <port_number>with the port number specified in Dovecot’s- /etc/dovecot/conf.d/10-master.conffile.
- Specify SASL mechanisms that the Postfix SMTP server makes available to clients. Note that you can specify different mechanisms for encrypted and unencrypted sessions. - smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous - smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - The previous directives specify that during unencrypted sessions, no anonymous authentication is allowed and no mechanisms that transmit unencrypted user names or passwords are allowed. For encrypted sessions that use TLS, only non-anonymous authentication mechanisms are allowed.