I recently read <Protecting WordPress Installations in an IaaS Environment "from infosec and decided to reinforce the security of the streaking wordpress.
Wordpress is the first choice for building a personal blog by Chinese people. Its position is equivalent to discuz, the first choice for building a forum (in other words, discuz only reports the command execution holes caused by global variables bypassing. Alas, open-source apps all generate getshell honeycomb instead of honey)
Wordpress is famous for its rich plug-ins (plug-in vulnerabilities). Therefore, attackers generally use a fingerprint to identify wordpress (except for quick methods for brute force cracking and social engineering background logon)
I. wpscan-WordPress fingerprint recognition and vulnerability detection tools
The website has been blocked by the mad GFW. You can use the penetration package kali (not wpscan. Only when you understand the attack can you provide the corresponding defense measures)
A. Install
Take ubuntu installation as an example
Apt-get install libcurl4-gnutls-dev libxml2 libxml2-dev libxslt1-dev ruby-dev build-essential
Git clone https://github.com/wpscanteam/wpscan.git
Cd wpscan/
Gem install bundler & bundle install -- without test
B. Basic usage
Enumeration site information: user name, plug-in, style, and other information
Ruby wpscan. rb -- url www.tanjiti.com -- enumerate
View detailed test information
Ruby wpscan. rb -- url www.tanjiti.com -- debug-output -- random-agent> debug. log
(Note: The wpscan default User-Agent is WPScan v2.5.1 (http://wpscan.org), one of the scanner's common sense to use a normal change of ua, to avoid triggering WAF and other defense deployment)
After checking the LOG, we can know how wpscan collects information.
For example, checking response header X-Pingback: http://www.tanjiti.com/xmlrpc.php header (xmlrpc vulnerability)
Check xmlrpc. php (xmlrpc vulnerability)
Check the robots.txt file (sensitive information leakage)
Check readme.html File (sensitive information leakage)
Check/wp-content/debug. log (sensitive information leakage)
Wp-config.php ~ , Wp-config.save, wp-config.old, wp-config.php.swp (sensitive information leakage)
After the fingerprint is identified, the vulnerability information library is used to find the vulnerabilities that can be exploited, such as MSF.
II. MSF-wordpress vulnerability exploitation (vulnerability scanning already used)
Msf> search wordpress
Matching Modules
======================
Name Disclosure Date Rank Description
----------------------------------
Auxiliary/admin/http/wp_custom_contact_forms 2014-08-07 normal WordPress custom-contact-forms Plugin SQL Upload
Auxiliary/dos/http/wordpress_xmlrpc_dos 2014-08-06 normal WordPress XMLRPC DoS
The famous XMLRPC DoS in the past is used as an example (for vulnerability description, refer to [Popular Science] What is DoS attack of billion laughs-WordPress and Drupal?)
Msf> use auxiliary/dos/http/wordpress_xmlrpc_dos
Msf auxiliary (wordpress_xmlrpc_dos)> show options
Module options (auxiliary/dos/http/wordpress_xmlrpc_dos ):
Name Current Setting Required Description
--------------------------------------
Proxies no Use a proxy chain
RHOST yes The target address
RLIMIT 1000 yes Number of requests to send
RPORT 80 yes The target port
TARGETURI/yes The base path to the wordpress application
VHOST no HTTP server virtual host
Msf auxiliary (wordpress_xmlrpc_dos)> set RHOST www.tanjiti.com
RHOST => xxx
Msf auxiliary (wordpress_xmlrpc_dos)> set TARGETURI/
TARGETURI =>/wordpress/
Msf auxiliary (wordpress_xmlrpc_dos)> run
(The emphasis is not on Metasploit. Only when you understand the attack can you provide corresponding defense measures)
III. wordpress protection-use ModSecurity for protection
For more information about installation and rule writing, see [Popular Science] install Apache2 + ModSecurity and custom WAF rules on ubuntu.
Vim/usr/share/modsecurity-crs/activated_rules/MY. conf
(1) add rules to defend against xmlrpc vulnerabilities
SecRule REQUEST_URI "@ endsWith/xmlrpc. php "" deny, tag: 'Web _ ATTACK/WordPress', msg: 'Block WORDPRESS xmlrpc. php', id: 0000003, phase: 2"
Service apache2 restart
Use MSF to send attack packets
Msf auxiliary (wordpress_xmlrpc_dos)> use auxiliary/logs/http/wordpress_pingback_access
Msf auxiliary (wordpress_pingback_access)> show options
Module options (auxiliary/logs/http/wordpress_pingback_access ):
Name Current Setting Required Description
--------------------------------------
Proxies no Use a proxy chain
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port
TARGETURI/yes The path to wordpress installation (e.g./wordpress /)
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host
Msf auxiliary (wordpress_pingback_access)> set RHOSTS www.tanjiti.com
RHOSTS => xxx
Msf auxiliary (wordpress_pingback_access)> set TARGETURI/
TARGETURI =>/wordpress/
Msf auxiliary (wordpress_pingback_access)> run
The interception log is shown as follows:
Message: Warning. String match "/xmlrpc. php" at REQUEST_URI. [file "/usr/share/modsecurity-crs/activa
Ted_rules/MY. conf "] [line" 4 "] [id" 0000003 "] [msg" block wordpress xmlrpc. php "] [tag" WEB_ATTACK/WOR
DPRESS "]
(2) add rules to defend against wpscan default scanning header
SecRule REQUEST_HEADERS: User-Agent "@ contains wpscan" "t: lowercase, deny, tag: 'Web _ ATTACK/WordPress', MS
G: 'Block wp;default useragent', id: 0000004, phase: 1"
Run wpscan again. The interception logs are as follows:
Essage: Warning. String match "wpscan" at REQUEST_HEADERS: User-Agent. [file "/usr/share/modsecurity-
Crs/activated_rules/MY. conf "] [line" 6 "] [id" 0000004 "] [msg" block wp1_default useragent "] [ta
G "WEB_ATTACK/WORDPRESS"]
You can add rules to your website in a targeted manner. Adding white rules will get twice the result with half the effort. The example rules here are just a reference.
IV. wordpress protection-shielding access to sensitive information
Vim/etc/apache2/apache2.conf
<FilesMatch ". (sw [po] | old | save | bak | orig (? : Inal )? | Php (? :~ | _ Bak | x23) $ ">
Require all denied
</FilesMatch>
Service apache2 restart
5. wordpress protection-enable the security header
Vim/etc/apache2/conf-available/security. conf
(1) prevent MIME type obfuscation attacks in IE9, chrome, and safari
Header set X-Content-Type-Options: "nosniff"
(2) prevent clickjacking and allow only resources that comply with the same-origin policy (same as the site) to load those protected resources through frame.
Header set X-Frame-Options: "sameorigin"
(3) Enable xss protection and notify the browser to block the script instead of filter user injection.
Header set X-XSS-Protection "1; mode = block"
Service apache2 restart
VI. wordpress protection-explosion proof of login Port
The general method is to set up a white list of login ports, but now more and more websites use the CDN service, obviously not a good protection solution
Install the Login LockDown plug-in. Search for the wordpress background plug-in management office and set it easily.
Set instance:
If the IP address fails three times in five minutes, the IP address is blocked for 60 minutes.