To properly set the permissions of /etc/http/conf, run the command:
$ sudo chmod 0750 /etc/http/conf
Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or alter the server's configuration files.
Ensure that the permissions on the web server log directory is set to 700:
$ sudo chmod 700 /var/log/httpd/This is its default setting.
A major tool in exploring the web site use, attempted use, unusual conditions, and problems are the access and error logs. In the event of a security incident, these logs can provide the SA and the web manager with valuable information. To ensure the integrity of the log files and protect the SA and the web manager from a conflict of interest related to the maintenance of these files, only the members of the Auditors group will be granted permissions to move, copy, and delete these files in the course of their duties related to the archiving of these files.
To properly set the permissions of /etc/http/conf.d/*, run the command:
$ sudo chmod 0640 /etc/http/conf.d/*
Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or to alter the server's configuration files.
To properly set the permissions of /etc/http/conf/*, run the command:
$ sudo chmod 0640 /etc/http/conf/*
Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or to alter the server's configuration files.
To properly set the permissions of /etc/http/conf.modules.d/*, run the command:
$ sudo chmod 0640 /etc/http/conf.modules.d/*
Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or to alter the server's configuration files.
All httpd logs must be owned by root user and group. By default,
the path for httpd logs is /var/log/httpd/
To properly set the owner of /var/log/httpd, run the command:
$ sudo chown root /var/log/httpdTo properly set the owner of
/var/log/httpd/*, run the command:
$ sudo chown root /var/log/httpd/*
A major tool in exploring the web site use, attempted use, unusual conditions, and problems are the access and error logs. In the event of a security incident, these logs can provide the SA and the web administrator with valuable information. Because of the information that is captured in the logs, it is critical that only authorized individuals have access to the logs.
Web content directories should not be shared anonymously over remote filesystems such as nfs and smb. Remove the shares from the applicable directories.
Sharing web content is a security risk when a web server is involved. Users accessing the share anonymously could experience privileged access to the content of such directories. Network sharable directories expose those directories and their contents to unnecessary access. Any unnecessary exposure increases the risk that someone could exploit that access and either compromises the web content or cause web server performance problems.
Install anti-virus software on the system and set it to automatically scan new files that are introduced to the web server.
Remote web authors should not be able to upload files to the Document Root directory structure without virus checking and checking for malicious or mobile code. A remote web user, whose agency has a Memorandum of Agreement (MOA) with the hosting agency and has submitted a DoD form 2875 (System Authorization Access Request (SAAR)) or an equivalent document, will be allowed to post files to a temporary location on the server. All posted files to this temporary location will be scanned for viruses and content checked for malicious or mobile code. Only files free of viruses and malicious or mobile code will be posted to the appropriate DocumentRoot directory.
The cache module allows httpd to cache data, optimizing access to
frequently accessed content. However, it introduces potential security flaws
such as the possibility of circumventing Allow and
Deny directives.
If this functionality is
unnecessary, comment out the module:
#LoadModule cache_module modules/mod_cache.soIf caching is required, it should not be enabled for any limited-access content.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
The cgi module allows HTML to interact with the CGI web programming language.
If this functionality is unnecessary, comment out the module:
#LoadModule cgi_module modules/mod_cgi.soIf the web server requires the use of CGI, enable mod_cgi.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
Every DocumentRoot that is configured should have an index.html file that exists. Add an index.html file to every configured DocumentRoot.
The goal is to completely control the web users experience in navigating any portion of the web document root directories. Ensuring all web content directories have at least the equivalent of an index.html file is a significant factor to accomplish this end. Also, enumeration techniques, such as URL parameter manipulation, rely upon being able to obtain information about the web server's directory structure by locating directories with default pages. This practice helps ensure that the anonymous web user will not obtain directory browsing information or an error message that reveals the server type and version.
By default, iptables blocks access to the ports used by the web server. To configure iptables to allow port 80 traffic, one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain:
-A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPTTo configure iptables to allow port 443 traffic, one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain:
-A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
Failure to comply with DoD ports, protocols, and services (PPS) requirements can result in compromise of enclave boundary protections and/or functionality of the AIS.
LogFormat should be enabled and set to the following in /etc/httpd/conf/httpd.conf:
LogFormat "a %A %h %H %l %m %s %t %u %U \"%{Referer}i\" \"%{User-Agent}i\"" combined
The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems. The LogFormat directive defines the format and information to be included in the access log entries.
The MaxKeepAliveRequests directive should be set and configured to $var_max_keepalive_requests or greater by setting the following in /etc/httpd/conf/httpd.conf:
MaxKeepAliveRequests $var_max_keepalive_requests
Resource exhaustion can occur when an unlimited number of concurrent requests are allowed on a web site, facilitating a denial of service attack. Mitigating this kind of attack will include limiting the number of concurrent HTTP/HTTPS requests per IP address and may include, where feasible, limiting parameter values associated with keepalive, (i.e., a parameter used to limit the amount of time a connection may be inactive).
If the mod_perl module is installed, enable Perl Taint checking in /etc/httpd/conf/httpd.conf. To enable Perl Taint checking, add or uncomment the following to /etc/httpd/conf.d/perl.conf:
PerlSwitches -T
PERL (Practical Extraction and Report Language) is an interpreted language
optimized for scanning arbitrary text files, extracting information from those
text files, and printing reports based on that information. The language is
often used in shell scripting and is intended to be practical, easy to use, and
efficient means of generating interactive web pages for the user. Unfortunately,
many widely available freeware PERL programs (scripts) are extremely insecure.
This is most readily accomplished by a malicious user substituting input to a
PERL script during a POST or a GET operation.
Consequently, the founders of
PERL have developed a mechanism named TAINT that protects the system from
malicious input sent from outside the program. When the data is tainted, it
cannot be used in programs or functions such as eval(), system(), exec(), pipes,
or popen(). The script will exit with a warning message.
Ensure that the SSH server service is enabled.
The sshd service can be enabled with the following command:
$ sudo systemctl enable sshd.service
Logging into a web server remotely using an unencrypted protocol or service
when performing updates and maintenance is a major risk. Data, such as user
account, is transmitted in plaintext and can easily be compromised. When
performing remote administrative tasks, a protocol or service that encrypts the
communication channel must be used.
An alternative to remote administration of
the web server is to perform web server administration locally at the console.
Local administration at the console implies physical access to the server.
Configure permissions for each instance of Alias, ScriptAlias, and ScriptAliasMatch that exist.
$ sudo find DIR -type d -exec chmod 755 {} \;
$ sudo find DIR -type f -exec chmod 555 {} \;
Where DIR matches the paths from Alias,
ScriptAlias, and ScriptAliasMatch.
Excessive permissions for the anonymous web user account are one of the most common faults contributing to the compromise of a web server. If this user is able to upload and execute files on the web server, the organization or owner of the server will no longer have control of the asset.
Disable old SSL and TLS version and enable the latest TLS encryption by setting the following in /etc/httpd/conf.modules.d/ssl.conf:
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1Make sure to also set SSLEngine to on in /etc/httpd/conf.modules.d/ssl.conf like the following:
SSLEngine on
Transport Layer Security (TLS) encryption is a required security setting for a private web server. Encryption of private information is essential to ensuring data confidentiality. If private information is not encrypted, it can be intercepted and easily read by an unauthorized party. A web server must use a FIPS 140-2 approved TLS version, and all non-FIPS-approved SSL versions must be disabled.
Configure the web site to use a valid organizationally defined certificate. For DoD, this is a DoD server certificate issued by the DoD CA.
This check verifies that DoD is a hosted web site's CA. The certificate is actually a DoD-issued server certificate used by the organization being reviewed. This is used to verify the authenticity of the web site to the user. If the certificate is not for the server (Certificate belongs to), if the certificate is not issued by DoD (Certificate was issued by), or if the current date is not included in the valid date (Certificate is valid from), then there is no assurance that the use of the certificate is valid. The entire purpose of using a certificate is, therefore, compromised.
The auth_digest module provides encrypted authentication sessions. If this functionality is unnecessary, comment out the related module:
#LoadModule auth_digest_module modules/mod_auth_digest.so
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
If any directories that contain dynamic scripts can be accessed via FTP by any group or user that does not require access, remove permissions to such directories that allow anonymous access. Also, ensure that any such access employs an encrypted connection.
The directories containing the CGI scripts, such as PERL, must not be accessible to anonymous users via FTP. This applies to all directories that contain scripts that can dynamically produce web pages in an interactive manner (i.e., scripts based upon user-provided input). Such scripts contain information that could be used to compromise a web service, access system resources, or deface a web site.
For each <Directory> instance, remove the following:
FollowSymLinksIf symbolic links are allowed, the following can be added for each <Directory> instance:
Options SymLinksIfOwnerMatchDisable
A symbolic link allows a file or a directory to be referenced using a symbolic name raising a potential hazard if symbolic linkage is made to a sensitive area. When web scripts are executed and symbolic links are allowed, the web user could be allowed to access locations on the web server that are outside the scope of the web document root or home directory.
Users must not be allowed to access the shell programs.
Shell programs might execute shell escapes and could then perform unauthorized activities that could damage the security posture of the web server. A shell is a program that serves as the basic interface between the user and the operating system. In this regard, there are shells that are security risks in the context of a web server and shells that are unauthorized.
ErrorLog should be enabled and set to the following in /etc/httpd/conf/httpd.conf:
ErrorLog "logs/error_log"
The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems.
The log_config_module should exist and be configured in the /etc/httpd/conf/httpd.conf file by adding the following module to configure logging:
log_config_module
A major tool in exploring the web site use, attempted use, unusual conditions, and problems are reported in the access and error logs. In the event of a security incident, these logs can provide the SA and the web manager with valuable information. Without these log files, SAs and web managers are seriously hindered in their efforts to respond appropriately to suspicious or criminal actions targeted at the web site.
LogLevel should be enabled and set to $var_httpd_loglevel. Add or edit the following in /etc/httpd/conf/httpd.conf:
LogLevel $var_httpd_loglevel
The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems. While the ErrorLog directive configures the error log file name, the LogLevel directive is used to configure the severity level for the error logs. The log level values are the standard syslog levels: emerg, alert, crit, error, warn, notice, info and debug.
CustomLog should be enabled and set to the following in /etc/httpd/conf/httpd.conf:
CustomLog "logs/access_log" combined
The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems. The CustomLog directive specifies the log file, syslog facility, or piped logging utility.
Use only secure encrypted logons and connections for uploading files to the web site.
Logging in to a web server via an unencrypted protocol or service, to upload documents to the web site, is a risk if proper encryption is not utilized to protect the data being transmitted. An encrypted protocol or service must be used for remote access to web administration tasks.
Normally, a service account is established for the web server. This is because a privileged account is not desirable and the server is designed to run for long uninterrupted periods of time. The SA or Web Manager will need password access to the web server to restart the service in the event or an emergency as the web server is not to restart automatically after an unscheduled interruption.
If the password is not entrusted to an SA or web manager the ability to ensure the availability of the web server is compromised.
Set AllowOverride to none for each instant of <Directory>.
CGI scripts represents one of the most common and exploitable means of compromising a web server. By definition, CGI are executable by the operating system of the host server. While access control is provided via the web service, the execution of CGI programs is not otherwise limited unless the SA or Web Manager takes specific measures. CGI programs can access and alter data files, launch other programs and use the network. CGI programs can be written in any available programming language. C, PERL, PHP, Javascript, VBScript and shell (sh, ksh, bash) are popular choices.
Install the security module:
The mod_security package can be installed with the following command:
$ sudo yum install mod_security
mod_security provides an additional level of protection for the web server by enabling the administrator to implement content access policies and filters at the application layer.
Install the mod_ssl module:
The mod_ssl package can be installed with the following command:
$ sudo yum install mod_ssl
mod_ssl provides encryption capabilities for the httpd Web server. Unencrypted content is transmitted in plain text which could be passively monitored and accessed by unauthorized parties.
The ldap module provides HTTP authentication via an LDAP directory. If its functionality is unnecessary, comment out the related modules:
#LoadModule ldap_module modules/mod_ldap.so #LoadModule authnz_ldap_module modules/mod_authnz_ldap.soIf LDAP is to be used, SSL encryption should be used as well.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
Web server methods are defined in section 9 of RFC 2616 (
http://www.ietf.org/rfc/rfc2616.txt).
If a web server does not require the implementation of all available methods,
they should be disabled.
Note: GET and POST are the most common methods. A majority of the others
are limited to the WebDAV protocol.
<Directory /var/www/html>
# ...
# Only allow specific methods (this command is case-sensitive!)
<LimitExcept GET POST>
Order allow,deny
</LimitExcept>
# ...
</Directory>
Minimizing the number of available methods to the web client reduces risk by limiting the capabilities allowed by the web server.
.java and .jpp files should not exist and should be removed from the web server.
From the source code in a .java or a .jpp file, the Java compiler produces a binary file with an extension of .class. The .java or .jpp file would, therefore, reveal sensitive information regarding an application's logic and permissions to resources on the server. By contrast, the .class file, because it is intended to be machine independent, is referred to as bytecode. Bytecodes are run by the Java Virtual Machine (JVM), or the Java Runtime Environment (JRE), via a browser configured to permit Java code.
The mime_magic module provides a second layer of MIME support that in most configurations is likely extraneous. If its functionality is unnecessary, comment out the related module:
#LoadModule mime_magic_module modules/mod_mime_magic.so
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
The mod_rewrite module is very powerful and can protect against certain classes of web attacks. However, it is also very complex and has a significant history of vulnerabilities itself. If its functionality is unnecessary, comment out the related module:
#LoadModule rewrite_module modules/mod_rewrite.so
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
To minimize exposure of private assets to unnecesarry risk by attackers, public web servers must be isolated from internal systems. Logically relocate public web servers to be isolated from internal systems. In addition, ensure the public web server does not have trusted connections with assets outside the confines of the demilitarizez done (DMZ) other than application and/or database servers that are a part of the same system as the web server.
Public web servers are by nature more vulnerabile to attack from publically based sources, such as the public Internet. Once compromised, a public server might be used as a base for further attack on private resources, unless additional layers of protection are implemented. Public web servers must be located in a DoD DMZ Extension, if hosted on the NIPRNet, with carefully controlled access. Failure to isolate resources in this way increase risk that private assets are exposed to attacks from public sources. An improperly located public web server is a potential threat to the entire network.
The presence of a compiler on a production server facilitates the malicious user's task of creating custom versions of programs and installing Trojan Horses or viruses.
An attacker's code could be uploaded and compiled on the server under attack.
Private web servers, which host sites that serve controlled access data, must be protected from outside threats in addition to insider threats. Isolate the private web server from the public DMZ and separate it from the internal general population LAN.
Insider threat may be accidental or intentional but, in either case, can cause a disruption in service of the web server. To protect the private web server from these threats, it must be located on a separate controlled access subnet and must not be part of the public DMZ that houses the public web servers. it also cannot be located inside the enclave as part of the local general population LAN.
The proxy module provides proxying support, allowing httpd to forward requests and serve as a gateway for other servers. If its functionality is unnecessary, comment out the module:
#LoadModule proxy_module modules/mod_proxy.soIf proxy support is needed, load mod_proxy and the appropriate proxy protocol handler module (one of mod_proxy_http, mod_proxy_ftp, or mod_proxy_connect). Additionally, make certain that a server is secure before enabling proxying, as open proxy servers are a security risk. mod_proxy_balancer enables load balancing, but requires that mod status be enabled.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
Copies of backup files will not execute on the server, but they can be read by the anonymous user if special precautions are not taken.
Such backup copies contain the same sensitive information as the actual scripts being executed and, as such, are useful to malicious users. Techniques and systems exist today that search web servers for such files and are able to exploit the information contained in them. Backup copies of files are automatically created by some text editors such such as emacs and VIM. Editors may write a backup file with an extension ~ added to the name of the original file. The edit plus editor will create a .bak file. Of course, this would imply the presence and use of development tools on the web server, which is a finding under WG130. Having backup scripts on the web server provides one more opportunity for malicious persons to view these scripts and use the information found in them.
Remove any robots.txt files that may exist with any web content. Other methods must be employed if there is information on the web site that needs protection from search engines and public view. Inspect all instances of DocumentRoot and Alias and remove any robots.txt file.
$ sudo rm -f path/to/robots.txt
Search engines are constantly at work on the Internet. Search engines are
augmented by agents, often referred to as spiders or bots, which endeavor to
capture and catalog web-site content. In turn, these search engines make the
content they obtain and catalog available to any public web user.
To request
that a well behaved search engine not crawl and catalog a site, the web site may
contain a file called robots.txt. This file contains directories and files that
the web server SA desires not be crawled or cataloged, but this file can also be
used, by an attacker or poorly coded search engine, as a directory and file
index to a site. This information may be used to reduce an attacker's time
searching and traversing the web site to find files that might be relevant. If
information on the web site needs to be protected from search engines and public
view, other methods must be used.
SSLVerifyClient should be set and configured to require by setting the following in /etc/httpd/conf/httpd.conf:
SSLVerifyClient require
Web sites requiring authentication within the DoD must utilize PKI as an authentication mechanism for web users. Information systems residing behind web servers requiring authorization based on individual identity must use the identity provided by certificate-based authentication to support access control decisions.
All accessible web directories should be configured with similarly restrictive settings. The Options directive should be limited to necessary functionality and the AllowOverride directive should be used only if needed. The Order and Deny access control tags should be used to deny access by default, allowing access only where necessary.
Directories accessible from a web client should be configured with the least amount of access possible in order to avoid unauthorized access to restricted content or server information.
The httpd root directory should always have the most restrictive configuration enabled.
<Directory / > Options None AllowOverride None Order allow,deny </Directory>
The Web Server's root directory content should be protected from unauthorized access by web clients.
The default configuration for the web (/var/www/html) Directory allows directory
indexing (Indexes) and the following of symbolic links (FollowSymLinks).
Neither of these is recommended.
The /var/www/html directory hierarchy should not be viewable via the web, and
symlinks should only be followed if the owner of the symlink also owns the linked file.
Ensure that this policy is adhered to by altering the related section of the configuration:
<Directory "/var/www/html"> # ... Options SymLinksIfOwnerMatch # ... </Directory>
Access to the web server's directory hierarchy could allow access to unauthorized files by web clients. Following symbolic links could also allow such access.
The status module provides real-time access to statistics on the internal operation of the web server. This may constitute an unnecessary information leak and should be disabled unless necessary. To do so, comment out the related module:
#LoadModule status_module modules/mod_status.soIf there is a critical need for this module, ensure that access to the status page is properly restricted to a limited set of hosts in the status handler configuration.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
The info module creates a web page illustrating the configuration of the web server. This can create an unnecessary security leak and should be disabled. If its functionality is unnecessary, comment out the module:
#LoadModule info_module modules/mod_info.soIf there is a critical need for this module, use the Location directive to provide an access control list to restrict access to the information.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
Server Side Includes provide a method of dynamically generating web pages through the insertion of server-side code. However, the technology is also deprecated and introduces significant security concerns. If this functionality is unnecessary, comment out the related module:
#LoadModule include_module modules/mod_include.soIf there is a critical need for Server Side Includes, they should be enabled with the option IncludesNoExec to prevent arbitrary code execution. Additionally, user supplied data should be encoded to prevent cross-site scripting vulnerabilities.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
ServerSignature Off restricts httpd from displaying server version number
on error pages.
Add or correct the following directive in /etc/httpd/conf/httpd.conf:
ServerSignature Off
Information disclosed to clients about the configuration of the web server and system could be used to plan an attack on the given system. This information disclosure should be restricted to a minimum.
ServerTokens Prod restricts information in page headers, returning only the word "Apache."
Add or correct the following directive in /etc/httpd/conf/httpd.conf:
ServerTokens Prod
Information disclosed to clients about the configuration of the web server and system could be used to plan an attack on the given system. This information disclosure should be restricted to a minimum.
The speling module attempts to find a document match by allowing one misspelling in an otherwise failed request. If this functionality is unnecessary, comment out the module:
#LoadModule speling_module modules/mod_speling.soThis functionality weakens server security by making site enumeration easier.
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
WebDAV is an extension of the HTTP protocol that provides distributed and collaborative access to web content. If its functionality is unnecessary, comment out the related modules:
#LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.soIf there is a critical need for WebDAV, extra care should be taken in its configuration. Since DAV access allows remote clients to manipulate server files, any location on the server that is DAV enabled should be protected by access controls.
Minimizing the number of loadable modules available to the web server, reduces risk by limiting the capabilities allowed by the web server.
The httpd package can be removed with the following command:
$ sudo yum erase httpd
If there is no need to make the web server software available, removing it provides a safeguard against its activation.
The nginx package can be removed with the following command:
$ sudo yum erase nginx
If there is no need to make the web server software available, removing it provides a safeguard against its activation.
The DocumentRoot directory is used for storing web content and data. Ensure that the DocumentRoot directory exists on a separate logical volume at installation time, or migrate it using LVM.
Application partitioning enables an additional security measure by securing user traffic under one security context, while managing system and application files under another. Web content is can be to an anonymous web user. For such an account to have access to system files of any type is a major security risk that is avoidable and desirable. Failure to partition the system files from the web site documents increases risk of attack via directory traversal, or impede web site availability due to drive space exhaustion.
By default, the SELinux boolean httpd_anon_write is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_anon_write SELinux boolean, run the following command:
$ sudo setsebool -P httpd_anon_write off
By default, the SELinux boolean httpd_builtin_scripting is enabled.
This setting should be disabled if httpd is not running php
or some similary scripting language.
To disable the httpd_builtin_scripting SELinux boolean, run the following command:
$ sudo setsebool -P httpd_builtin_scripting off
By default, the SELinux boolean httpd_can_check_spam is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_check_spam SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_check_spam off
By default, the SELinux boolean httpd_can_connect_ftp is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_connect_ftp SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_connect_ftp off
By default, the SELinux boolean httpd_can_connect_ldap is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_connect_ldap SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_connect_ldap off
By default, the SELinux boolean httpd_can_connect_mythtv is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_connect_mythtv SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_connect_mythtv off
By default, the SELinux boolean httpd_can_connect_zabbix is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_connect_zabbix SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_connect_zabbix off
By default, the SELinux boolean httpd_can_network_connect is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_network_connect SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_network_connect off
By default, the SELinux boolean httpd_can_network_connect_cobbler is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_network_connect_cobbler SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_network_connect_cobbler off
By default, the SELinux boolean httpd_can_network_connect_db is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_network_connect_db SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_network_connect_db off
By default, the SELinux boolean httpd_can_network_memcache is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_network_memcache SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_network_memcache off
By default, the SELinux boolean httpd_can_network_relay is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_network_relay SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_network_relay off
By default, the SELinux boolean httpd_can_sendmail is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_can_sendmail SELinux boolean, run the following command:
$ sudo setsebool -P httpd_can_sendmail off
By default, the SELinux boolean httpd_dbus_avahi is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_dbus_avahi SELinux boolean, run the following command:
$ sudo setsebool -P httpd_dbus_avahi off
By default, the SELinux boolean httpd_dbus_sssd is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_dbus_sssd SELinux boolean, run the following command:
$ sudo setsebool -P httpd_dbus_sssd off
By default, the SELinux boolean httpd_dontaudit_search_dirs is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_dontaudit_search_dirs SELinux boolean, run the following command:
$ sudo setsebool -P httpd_dontaudit_search_dirs off
By default, the SELinux boolean httpd_enable_cgi is enabled.
This setting should be disabled unless httpd is used with CGI
scripting.
To disable the httpd_enable_cgi SELinux boolean, run the following command:
$ sudo setsebool -P httpd_enable_cgi off
By default, the SELinux boolean httpd_enable_ftp_server is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_enable_ftp_server SELinux boolean, run the following command:
$ sudo setsebool -P httpd_enable_ftp_server off
By default, the SELinux boolean httpd_enable_homedirs is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_enable_homedirs SELinux boolean, run the following command:
$ sudo setsebool -P httpd_enable_homedirs off
By default, the SELinux boolean httpd_execmem is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_execmem SELinux boolean, run the following command:
$ sudo setsebool -P httpd_execmem off
By default, the SELinux boolean httpd_graceful_shutdown is enabled.
If this setting is disabled, it should be enabled.
To enable the httpd_graceful_shutdown SELinux boolean, run the following command:
$ sudo setsebool -P httpd_graceful_shutdown on
By default, the SELinux boolean httpd_manage_ipa is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_manage_ipa SELinux boolean, run the following command:
$ sudo setsebool -P httpd_manage_ipa off
By default, the SELinux boolean httpd_mod_auth_ntlm_winbind is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_mod_auth_ntlm_winbind SELinux boolean, run the following command:
$ sudo setsebool -P httpd_mod_auth_ntlm_winbind off
By default, the SELinux boolean httpd_mod_auth_pam is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_mod_auth_pam SELinux boolean, run the following command:
$ sudo setsebool -P httpd_mod_auth_pam off
By default, the SELinux boolean httpd_read_user_content is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_read_user_content SELinux boolean, run the following command:
$ sudo setsebool -P httpd_read_user_content off
By default, the SELinux boolean httpd_run_ipa is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_run_ipa SELinux boolean, run the following command:
$ sudo setsebool -P httpd_run_ipa off
By default, the SELinux boolean httpd_run_preupgrade is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_run_preupgrade SELinux boolean, run the following command:
$ sudo setsebool -P httpd_run_preupgrade off
By default, the SELinux boolean httpd_run_stickshift is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_run_stickshift SELinux boolean, run the following command:
$ sudo setsebool -P httpd_run_stickshift off
By default, the SELinux boolean httpd_serve_cobbler_files is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_serve_cobbler_files SELinux boolean, run the following command:
$ sudo setsebool -P httpd_serve_cobbler_files off
By default, the SELinux boolean httpd_setrlimit is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_setrlimit SELinux boolean, run the following command:
$ sudo setsebool -P httpd_setrlimit off
By default, the SELinux boolean httpd_ssi_exec is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_ssi_exec SELinux boolean, run the following command:
$ sudo setsebool -P httpd_ssi_exec off
By default, the SELinux boolean httpd_sys_script_anon_write is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_sys_script_anon_write SELinux boolean, run the following command:
$ sudo setsebool -P httpd_sys_script_anon_write off
By default, the SELinux boolean httpd_tmp_exec is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_tmp_exec SELinux boolean, run the following command:
$ sudo setsebool -P httpd_tmp_exec off
By default, the SELinux boolean httpd_tty_comm is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_tty_comm SELinux boolean, run the following command:
$ sudo setsebool -P httpd_tty_comm off
By default, the SELinux boolean httpd_unified is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_unified SELinux boolean, run the following command:
$ sudo setsebool -P httpd_unified off
By default, the SELinux boolean httpd_use_cifs is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_use_cifs SELinux boolean, run the following command:
$ sudo setsebool -P httpd_use_cifs off
By default, the SELinux boolean httpd_use_fusefs is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_use_fusefs SELinux boolean, run the following command:
$ sudo setsebool -P httpd_use_fusefs off
By default, the SELinux boolean httpd_use_gpg is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_use_gpg SELinux boolean, run the following command:
$ sudo setsebool -P httpd_use_gpg off
By default, the SELinux boolean httpd_use_nfs is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_use_nfs SELinux boolean, run the following command:
$ sudo setsebool -P httpd_use_nfs off
By default, the SELinux boolean httpd_use_openstack is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_use_openstack SELinux boolean, run the following command:
$ sudo setsebool -P httpd_use_openstack off
By default, the SELinux boolean httpd_use_sasl is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_use_sasl SELinux boolean, run the following command:
$ sudo setsebool -P httpd_use_sasl off
By default, the SELinux boolean httpd_verify_dns is disabled.
If this setting is enabled, it should be disabled.
To disable the httpd_verify_dns SELinux boolean, run the following command:
$ sudo setsebool -P httpd_verify_dns off
The httpd service can be disabled with the following command:
$ sudo systemctl mask --now httpd.service
Running web server software provides a network-based avenue of attack, and should be disabled if not needed.