PHP security practices that must be known to system administrators

The security practice of PHP, which must be known by system administrators, is an open source server scripting language and widely used. The Apacheweb server provides the convenience of accessing files and content through HTTP or HTTPS. Improper configuration of the server-side scripting language can cause various problems. Therefore, be careful when using PHP. Below are 25 best practices for PHP Security, which can be securely configured by system administrators. Examples provided for PHP Security Tips: PHP security practices that must be known by system administrators
PHP is an open-source server scripting language and is widely used. Apache web server provides the convenience of accessing files and content through HTTP or HTTPS. Improper configuration of the server-side scripting language can cause various problems. Therefore, be careful when using PHP. Below are 25 best practices for PHP Security, which can be securely configured by system administrators.
Sample environment provided for PHP Security Tips

? File root directory (DocumentRoot):/var/www/html
? Default Web server: Apache (you can use Lighttpd or Nginx to replace Apache)
? Default PHP configuration file:/etc/php. ini
? Default PHP loading module configuration Directory:/etc/php. d/
? Our example php security Configuration File:/etc/php. d/security. ini (you need to use a text editor to create this file)
? Operating system: RHEL/CentOS/Fedora Linux (related commands should be compatible with any other Linux release such as Debian/Ubuntu or other Unix-like operating systems such as OpenBSD/FreeBSD/HP-UX ).
? Default php server TCP/UDP port: None

When writing code for most of the operations listed in this article, it is assumed that they will be executed by the root user running the bash shell or any other modern shell program:
$ Php-v
Sample output:
PHP 5.3.3 (cli) (built: Oct 24 2011 08:35:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
For demonstration purposes, I will use the following operating systems:
$ Cat/etc/redhat-release
Sample output:
Red Hat Enterprise Linux Server release 6.1 (Santiago)
1st Best Practices: understanding your opponent

PHP-based applications face different types of attacks. I have noticed several different types of attacks:

1. XSS: XSS is a security vulnerability in Web PHP applications. Attackers can exploit this vulnerability to steal user information. You can configure Apache to write a safer PHP script (verify all user input) to avoid XSS attacks.

2. SQL injection attacks: this is a security vulnerability in the database layer of PHP applications. When the user input is incorrectly filtered, the application can execute any SQL statement. You can configure Apache and write security code (verify and convert all user input) to avoid SQL injection attacks. A common practice in PHP is to use a function named mysql_real_escape_string () to convert parameters before sending an SQL query.

3. file upload: this allows visitors to put files on (upload files to) your server. This may cause many security problems, such as deleting your files, deleting databases, and obtaining user details. You can use php to disable file upload or write security code (for example, to verify user input, only PNG or GIF image file types are allowed ).

4. add local and remote files: Attackers can open files from remote servers and execute any PHP code. This allows them to upload files, delete files, and install backdoors. You can configure php to disable remote file execution.

5. eval (): Evaluate the string as PHP code. Attackers often use this function to hide their code and tools on the server itself. You can configure PHP to disable eval ().

6. sea-surf attack (cross-site request forgery, CSRF): This attack forces end users to perform harmful operations on Web applications that have verified their identity. If it is a common user, successful CSRF attacks will compromise the data and operations of end users. However, if the target end user uses the administrator account, the entire Web application may be compromised.


2nd best practices: Find the built-in PHP module



To view a group of compiled PHP modules, enter the following command:
# Php-m


Sample output:



[PHP module]
Apc
Bcmath
Bz2
Calendar
Core
Ctype
Curl
Date
Dom
Ereg
Exif
Fileinfo
Filter
Ftp
Gd
Gettext
Gmp
Hash
Iconv
Imap
Json
Libxml
Mbstring
Memcache
Mysql
Mysqli
Openssl
Pcntl
Pcre
PDO
Pdo_mysql
Pdo_sqlite
Phar
Readline
Reflection
Session
Shmop
SimpleXML
Sockets
SPL
Sqlite3
Standard
Suhosin
Tokenizer
Wddx
Xml
Xmlreader
Xmlrpc
Xmlwriter
Xsl
Zip
Zlib


[Zend module]
Suhosin


I recommend that you use PHP with fewer modules to improve performance and security. For example, you can disable the sqlite3 module by deleting (removing) the configuration file or renaming (or moving) a file named/etc/php. d/sqlite3.ini. the operations are as follows:
# Rm/etc/php. d/sqlite3.ini


Or
# Mv/etc/php. d/sqlite3.ini/etc/php. d/sqlite3.disable


Other compiled modules can only be removed by re-installing PHP with simplified configuration. You can download the php source code from php.net and compile it as follows to support GD, fastcgi, and MySQL:
. /Configure -- with-libdir = lib64 -- with-gd -- with-mysql -- prefix =/usr -- exec-prefix =/usr -- bindir =/usr/bin -- sbindir =/usr /sbin -- sysconfdir =/etc -- datadir =/usr/share -- includedir =/usr/include -- libexecdir =/usr/libexec -- localstatedir =/var -- sharedstatedir =/usr/com -- mandir =/usr/share/man -- infodir =/usr/share/info -- cache-file = .. /config. cache -- with-config-file-path =/etc -- with-config-file-scan-dir =/etc/php. d -- enable-fastcgi -- enable-force-cgi-redirect


See how to compile php and reinstall it on a Unix-like operating system (http://www.php.net/manual/en/install.unix.php) for more information.

3rd best practices: restrict PHP information leakage

To restrict PHP information leakage, disable expose_php. Edit/etc/php. d/secutity. ini and execute the following command:

After expose_php = Off is enabled, expose_php reports to the outside world that PHP is installed on the server, which includes the PHP version in the HTTP header (for example, X-Powered-By: PHP/5.3.3 ). The globally unique identifier of the PHP identifier (GUID, see the sample http://www.php.net /? = PHPE9568F34-D428-11d2-A769-00AA001ACF42) is also displayed, so they are added to the URL of a website that supports PHP, the corresponding identifier is displayed. After expose_php is enabled, you can run the following command to view the PHP version:

$ Curl-I http://www.cyberciti.biz/index.php:

HTTP/1.1 200 OK
X-Powered-By: PHP/5.3.3
Content-type: text/html; charset = UTF-8
Vary: Accept-Encoding, Cookie
X-Vary-Options: Accept-Encoding; list-contains = gzip, Cookie; string-contains = wikiToken; string-contains = wikiLoggedOut; string-contains = wiki_session
Last-Modified: Thu, 03 Nov 2011 22:32:55 GMT
... I also recommend that you execute ServerTokens and ServerSignature commands in httpd. conf to hide Apache versions and other information (http://www.cyberciti.biz/faq/rhel-centos-hide-httpd-version ).

4th best practices: minimize the number of PHP modules that can be loaded (dynamic loading module)

PHP supports Dynamic Extensions ). By default, RHEL loads all the modules in the/etc/php. d/directory. To enable or disable a module, find the configuration file in the/etc/php. d/directory and add comments to the module name. You can also rename or delete the module configuration file. To get the best PHP performance and security, you should only enable the loading modules required by Web applications. For example, to disable the gd loading module, enter the following command:

# Cd/etc/php. d/
# Mv gd. {ini, disable}
#/Sbin/service httpd restart to enable the php module named gd, enter:

# Mv gd. {disable, ini}
#/Sbin/service httpd restart

5th best practices: log all PHP errors

Do not expose PHP error messages to all visitors of the website. Edit/etc/php. d/security. ini and execute the following command:

Display_errors = Off make sure you record all PHP errors to the log file (http://www.cyberciti.biz/tips/php-howto-turn-on-error-log-file.html ):

Log_errors = On
Error_log =/var/log/httpd/php_scripts_error.log 6th best practices: File Upload not allowed

For security reasons, edit/etc/php. d/security. ini and execute the following command:

File_uploads = Off if a user using your application needs to upload files, you just need to set upload_max_filesize (http://www.cyberciti.biz/faq/linux-unix-apache-increase-php-upload-limit/) to enable this feature, which limits the maximum number of files that PHP allows to upload through:

File_uploads = On # The maximum size of files uploaded by users through PHP is 1 MB

Upload_max_filesize = 1 Mbit/s 7th best practices: disable remote code execution

If enabled, allow_url_fopen allows PHP file functions, such as file_get_contents (), include, and require statements, to obtain data from remote locations (such as FTP or websites.

The allow_url_fopen option allows PHP file functions, such as file_get_contents (), include, and require statements, to obtain data from remote locations using FTP or HTTP. Programmers often forget this. when transmitting user data to these functions, they do not perform proper input filtering, which leaves a hidden risk for code injection security vulnerabilities. Many PHP-based Web applications have code injection vulnerabilities caused by enabling allow_url_fopen and poor input filtering. Edit/etc/php. d/security. ini and execute the following command:

Allow_url_fopen = Off for security reasons, I also recommend disabling allow_url_include:

Allow_url_include = Off

8th best practices: enabling SQL security mode

Edit/etc/php. d/security. ini and execute the following command:

If SQL. safe_mode = On is enabled, mysql_connect () and mysql_pconnect () ignore any variables sent to them. Note: You may have to make some changes to your code. After SQL. safe_mode is enabled, third-party open-source applications (such as WorkdPress) and other applications may not run at all. I also recommend that you disable magic_quotes_gpc (http://php.net/manual/en/security.magicquotes.php) for all installed php 5.3.x because its filtering is not effective and not very reliable. Mysql_escape_string () and custom filter functions can play a better role (thanks to Eric Hansen, https://www.facebook.com/EricHansen.SFU ):

Magic_quotes_gpc = Off 9th best practices: control the size of POST requests

As part of the request, when the client (browser or user) needs to send data to the Apache Web server, for example, when uploading a file or submitting a filled form, the http post request method is required. Attackers may attempt to send too many POST requests, consuming a lot of your system resources. You can limit the maximum size of POST requests that PHP will process. Edit/etc/php. d/security. ini and execute the following command:

; Set the actual value here

Post_max_size = 1K1K sets the maximum size of POST request data allowed by the php application. This setting also affects file upload. To upload a large file, the value must be greater than upload_max_filesize. I also recommend that you restrict the availability of Apache Web servers. Edit httpd. conf and run the following command for the root directory/var/www/html:



Order allow, deny
# Add other configurations here ...##

10th best practices: Resource Control (denial of service control)

You can set the maximum execution time of each php script, in seconds. Another recommended option is to set the maximum time that each script may use to parse request data and the maximum memory that the script may consume. Edit/etc/php. d/security. ini and execute the following command:

# Settings, in seconds

Max_execution_time = 30
Max_input_time = 30
Memory_limit = 40 m 11th best practices: install the Suhosin advanced protection system for PHP

From Suhosin project web page (http://www.hardened-php.net/suhosin ):

Suhosin is an advanced protection system for installing PHP. It is designed to protect servers and users from known and unknown defects in PHP applications and PHP cores. Suhosin is divided into two independent parts, which can be used independently or in combination. The first part is a small patch for the PHP core. it implements several low-level protection measures to prevent buffer overflow or format string security vulnerabilities. The second part is the powerful PHP loading module, all other protection measures were implemented.

See how to install and configure suhosin (http://www.cyberciti.biz/faq/rhel-linux-install-suhosin-php-protection/) in Linux ).

12th best practices: disable dangerous PHP functions

PHP has many functions that can be used to break into your server if used improperly. You can use the disable_functions command to disable a series of functions in/etc/php. d/security. ini:

Disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source

13th best practices: PHP Fastcgi/CGI-cgi. force_redirect command

PHP can work with FastCGI. Fascgi reduces the memory resources occupied by Web servers, but it still provides you with the speed and functionality of the entire PHP language. You can configure Apache2 + PHP + FastCGI or cgi, as described here. The configuration command cgi. force_redirect can prevent anyone from directly using the PHP address such as http://www.cyberciti.biz/cgi-bin/php/hackerdir/backdoor.php. Cgi. force_redirect should be enabled for security reasons. Edit/etc/php. d/security. ini and execute the following command:

To enable cgi. force_redirect in a typical * Apache + PHP-CGI/FastCGI * environment for security reasons

Cgi. force_redirect = On 14th best practices: PHP user and user group ID

Mod_fastcgi is a cgi module for Apache Web servers. It can connect to an external FASTCGI server. Make sure that PHP runs as a non-root user. If PHP runs as a root directory or UID below 100, it can access and/or process system files. You must use Apache suEXEC or mod_suPHP to execute php cgi as a non-privileged user. The suEXEC feature allows Apache users to run CGI programs with different user IDs that call Web servers. In this example, my php-cgi runs as a phpcgi user, and Apache runs as an apache User:

# Ps aux | grep php-cgi sample output:

Phpcgi 6012 0.0 0.4 225036 60140? S Nov22 0: 12/usr/bin/php-cgi
Phpcgi 6054 0.0 0.5 229928 62820? S Nov22 0: 11/usr/bin/php-cgi
Phpcgi 6055 0.1 0.4 224944 53260? S Nov22 0: 18/usr/bin/php-cgi
Phpcgi 6085 0.0 0.4 224680 56948? S Nov22 0: 11/usr/bin/php-cgi
Phpcgi 6103 0.0 0.4 224564 57956? S Nov22 0: 11/usr/bin/php-cgi
Phpcgi 6815 0.4 0.5 228556 61220? S/usr/bin/php-cgi
Phpcgi 6821 0.3 0.5 228008 61252? S/usr/bin/php-cgi
Phpcgi 6823 0.3 0.4 225536 58536? S/usr/bin/php-cgi you can use tools such as spawn-fcgi as a phpcgi user (you must first add a phpcgi user to the system) to create remote and local FastCGI processes:

# Spawn-fcgi-a 127.0.0.1-p 9000-u phpcgi-g phpcgi-f/usr/bin/php-cgi now, you can configure Apache, Lighttpd, and Nginx web servers, use php FastCGI running on port 9000 at 127.0.0.1 IP address.

15th best practices: restrict PHP access to file systems

The open_basedir command allows PHP to use fopen () and other functions to access files in which directories. If the file is located outside the path defined by open_basdir, PHP rejects the file. You cannot use symbolic links as a work und. For example, you can only access the/var/www/html Directory,/var/www,/tmp, or/etc directory:

Restrict PHP processes to access files outside a specified directory, such as/var/www/html /.

; Limits the PHP process from accessing files outside
; Of specifically designated directories such as/var/www/html/
Open_basedir = "/var/www/html /"
;------------------------------------
; Multiple dirs example
; Open_basedir = "/home/httpd/vhost/cyberciti. biz/html/:/home/httpd/vhost/nixcraft.com/html/:/home/httpd/vhost/theos.in/html /"
; ------------------------------------ 16th best practices: Session path

Sessions in PHP support a method that includes retaining certain data in subsequent access. This allows you to develop more customized applications and increase the attractiveness of your website. This path is defined in the/etc/php. ini file. all data related to a session will be stored in the file specified by session. save_path. In RHEL/CentOS/Fedora Linux, the default path is as follows:

Session. save_path = "/var/lib/php/session"; sets the temporary directory for storing files when uploading files

Upload_tmp_dir = "/var/lib/php/session" ensure that the path is outside/var/www/html and cannot be read or written by any other system User:

# Ls-Z/var/lib/php/sample output:

Drwxrwx ---. root apache system_u: object_r: httpd_var_run_t: s0 session note: the-Z option of the ls command displays the SELinux security context, such as the file module, user, user group, security context, and file name.

17th best practices: keep PHP, software, and operating system up-to-date

Installing security patches is an important part of maintaining Linux, Apache, PHP, and MySQL servers. Use any of the following tools (if you install PHP through the software package manager) to check all PHP security updates as soon as possible and add them as soon as possible:

# Yum update or

# Apt-get update & apt-get upgrade you can configure Red Hat/CentOS/Fedora Linux to send yum package update notifications by email. Another option is to use the cron job to add all the security updates. In Debian/Ubuntu Linux, you can use apticron to send security notifications.

Note: visit php.net (http://php.net/) frequently to find the latest version of source code installation.

18th best practices: restrict file and directory access

Make sure that you run Apache as a non-root user such as Apache or www. All files and directories should be owned by non-root users (or apache users) and placed under/var/www/html:

# Chown-R apache: apache/var/www/html // var/www/html/is a subdirectory, which can be modified by other users, because the root directory never executes any files or creates files there.

Ensure that the file permission is set to 0444 (read-only) under/var/www/html ):

# Chmod-R 0444/var/www/html/ensure that all directory permissions are set to 0445 under/var/www/html:

# Find/var/www/html/-type d-print0 | xargs-0-I {} chmod 0445 {} supplement to setting proper file permissions

The chown and chmod commands ensure that, under any circumstances, files in the file root directory or file root directory can be written to apache by the Web server user. Note: You need to set the most reasonable permissions for the development model of your website, so you can adjust the chown and chmod commands as needed. In this example, the Apache server runs as an apache user. This can be configured using the User and Group commands in your httpd. conf file. Apache users must have read access to all contents in the root directory of the file, but should not have write access.

Make sure that httpd. conf has the following command to implement restrictive configuration:


Options None
AllowOverride None
Order allow, deny
You only need to grant write access when necessary. Some Web applications such as WordPress and other applications may need to cache directories. You can use the following command to grant access to the buffer Directory:

# Chmod a + w/var/www/html/blog/wp-content/cache
### Block access to all ###
# Echo 'deny from all'>/var/www/html/blog/wp-content/cache/. htaccess 19th best practices: write protection for Apache, PHP, and MySQL configuration files

Use the chattr command to write protection configuration files:

# Chattr + I/etc/php. ini
# Chattr + I/etc/php. d /*
# Chattr + I/etc/my. ini
# Chattr + I/etc/httpd/conf/httpd. conf
# The chattr + I/etc/chattr command can also write a php file or multiple files in the/var/www/html Directory:

# Chattr + I/var/www/html/file1.php
# Chattr + I/var/www/html/20th best practices: Use Linux to safely load modules (such as SELinux)

Linux comes with various security patches that can be used to protect server programs that are improperly configured or compromised. If possible, use SELinux and other Linux security loading modules to restrict the network and other programs. For example, SELinux provides many security policies for Linux kernel and Apache Web servers. To list all Apache SELinux protection variables, enter:

# Getsebool-a | grep httpd sample output:

Allow_httpd_anon_write --> off
Allow_httpd_mod_auth_ntlm_winbind --> off
Allow_httpd_mod_auth_pam --> off
Allow_httpd_sys_script_anon_write --> off
Httpd_builtin_scripting --> on
Httpd_can_check_spam --> off
Httpd_can_network_connect --> off
Httpd_can_network_connect_cobbler --> off
Httpd_can_network_connect_db --> off
Httpd_can_network_memcache --> off
Httpd_can_network_relay --> off
Httpd_can_sendmail --> off
Httpd_dbus_avahi --> on
Httpd_enable_cgi --> on
Httpd_enable_ftp_server --> off
Httpd_enable_homedirs --> off
Httpd_execmem --> off
Httpd_read_user_content --> off
Httpd_setrlimit --> off
Httpd_ssi_exec --> off
Httpd_tmp_exec --> off
Httpd_tty_comm --> on
Httpd_unified --> on
Httpd_use_cifs --> off
Httpd_use_gpg --> off
Httpd_use_nfs --> off to disable Apache cgi support, enter:

# Setsebool-P httpd_enable_cgi off refer to Red Hat SELinux Guide (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html) for more information.

21st best practices: install Mod_security

ModSecurity is an open-source intrusion detection and prevention engine that protects Web applications. You can easily install mod_security in Linux. after installation, you can protect Apache and PHP-based applications from XSS and other attacks:

# Several instances ##
# Files in/etc/cannot be opened

SecFilter/etc/# Block SQL injection attacks

SecFilter "delete [[: space:] + from"
SecFilter "select. + from" 22nd best practices: try to run Apache/PHP in the chroot jail environment

Placing PHP and/or Apache in the chroot jail environment can minimize the damage caused by potential intrusion events because it isolates the Web server into a small part of the file system. You can use the traditional chroot jail environment that comes with Apache. However, we recommend that you use FreeBSD jail, XEN virtualization using the container concept, KVM virtualization, or OpenVZ virtualization.

23rd best practices: use a firewall to restrict outbound connections

Attackers can use tools such as wget to locally download files to your Web server. You can use iptables to prevent apache users' outbound connections. The ipt_owner module tries to compare the characteristics of the locally created data packets with the data packet creator. It is only valid in the OUTPUT chain. In this example, vivek users are allowed to use port 80 to connect to the outside world (this applies to RHN or centos repo access ).

/Sbin/iptables-a output-o eth0-m owner -- uid-owner vivek-p tcp -- dport 80-m state -- state NEW, ESTABLISHED-j ACCEPT is another example, block all apache users' outbound connections (except for outbound connections to our own smtp server) and spam verification API service:

#....
/Sbin/iptables -- new-chain apache_user
/Sbin/iptables -- append OUTPUT-m state -- state ESTABLISHED, RELATED-j ACCEPT
/Sbin/iptables -- append OUTPUT-m owner -- uid-owner apache-j apache_user
# Allow apache user to connec to our smtp server
/Sbin/iptables -- append apache_user-p tcp -- syn-d 192.168.1.100 -- dport 25-j RETURN
# Allow apache user to connec to api server for spam validation
/Sbin/iptables -- append apache_user-p tcp -- syn-d 66.135.58.62 -- dport 80-j RETURN
/Sbin/iptables -- append apache_user-p tcp -- syn-d 66.135.58.61 -- dport 80-j RETURN
/Sbin/iptables -- append apache_user-p tcp -- syn-d 72.233.69.89 -- dport 80-j RETURN
/Sbin/iptables -- append apache_user-p tcp -- syn-d 72.233.69.88 -- dport 80-j RETURN
#########################
# Add more rules here ##
#########################
# No editing below
# Drop everything for apache outgoing connection
/Sbin/iptables -- append apache_user-j REJECT 24th best practices: follow logs and review

Check apache log files:

# Tail-f/var/log/httpd/error_log
# Grep 'login. php'/var/log/httpd/error_log
# Egrep-I "denied | error | warn"/var/log/httpd/error_log check the php log file:

# Tail-f/var/log/httpd/php_scripts_error.log
# Grep "... the etc/passwd "/var/log/httpd/php_scripts_error.log file helps you understand what attacks the server is under, and allows you to check whether necessary security levels are in place. Provides the auditd service for system review. With this service enabled, you can review SELinux events, verification events, file modifications, and account modifications. I also recommend using standard Linux system monitoring tools (http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html) to monitor your Web servers.

25th best practices: run services based on system or virtual machine instances

For large systems installed, we recommend that you use different servers to run databases, static content, and dynamic content.



(: Run services on different servers)

Run different network services on different servers or virtual machine instances. This limits the number of other services that may be compromised. For example, if attackers successfully exploit vulnerabilities in software such as Apache flow, they can access the entire server, including other services running on the same server (such as MySQL and email services ). However, in the preceding example, different content is provided as follows:

1. static. lan. cyberciti. biz: uses lighttpd or nginx servers to provide static assets such as js, css, and images.

2. phpcgi1.lan. cyberciti. biz and phpcgi2.lan. cyberciti. biz: Apache web server. php is used to generate dynamic content.

3. mysql1.lan. cyberciti. biz: MySQL database server.

4. mcache1.lan. cyberciti. biz: the Memcached server is used for MySQL cache systems that are extremely fast. It uses libevent or epoll (Linux runtime environment) to expand to any number of open connections and use non-blocking network input/output.

5. LB01: nginx Web server and reverse proxy server placed in front of Apache Web server. All the connections from the Internet to one of the Web servers are transmitted through the nginx proxy server. the proxy server can process the requests itself or send all or part of the requests to the master Web server. LB01 provides a simple load balancing mechanism.
26th best practices: Other tools

From PHPIDS project web page (https://phpids.org /):

PHPIDS (PHP Intrusion Detection System) is a security layer for PHP-based web applications. it is easy to use, well structured, fast to run, and advanced in technology. IDS cannot clear, purify, or filter any malicious input content. they only identify when attackers attempt to intrude into your website and take appropriate measures based on the measures you want it to take.

You can use PHPIDS to detect malicious users and record any detected attacks for future analysis. Note: I have never used this tool.

From PhpSecInfo project web page (http://phpsec.org/projects/phpsecinfo/index.html ):

PhpSecInfo provides a mechanism corresponding to the phpinfo () function to report security information about the PHP environment and provide suggestions for improvement. It cannot replace security development skills and does not perform any code or application review, but is a practical tool in a multi-level security solution.



: Security information about PHP applications

See Linux security reinforcement highlights (http://www.cyberciti.biz/tips/linux-security.html) to reduce the number of attack paths facing the system.

PHP webshell supplement

You may have encountered PHP scripts or so-called common backdoors, such as c99, c99madshell, and r57. The backdoor php script is actually a hidden script used to bypass all authentication mechanisms and access your server as needed. Attackers install it to access your server and attempt not to be detected. Misuse of PHP scripts (or any other CGI script) usually allows you to add code that is used to drill holes in Web browsers. Attackers can use this security vulnerability to upload backdoor shells, so that attackers can obtain many functions, such:

? Download Files
? Upload files
? Install rootkit
? Configure the spam email server/relay server
? Set proxy server to hide whereabouts
? Control server
? Control database servers
? Steal all information
? Delete all information and databases
? Open TCP/UDP ports and more ports

Key point: how can I find out the PHP backdoor?

You can use the Unix/Linux grep command to search for the c99 or r57 shell:

# Grep-iR 'c99'/var/www/html/
# Grep-iR 'r57 '/var/www/html/
# Find/var/www/html/-name \ *. php-type f-print0 | xargs-0 grep c99
# Grep-RPn "(passthru | shell_exec | system | base64_decode | fopen | fclose | eval)"/var/www/html/conclusion

Your PHP-based server is now reinforced to display dynamic web pages. However, security vulnerabilities are mainly caused by failing to comply with programming rules that are best practices. To meet the security requirements of web applications, you should read more resources, especially PHP programming knowledge, although this is beyond the scope of the work of the system administrator.

Address: http://www.cyberciti.biz/tips/php-security-best-practices-tutorial.html