15 9 月

自安裝WordPress(非使用套件)在Synology群暉 NAS的資料夾使用者權限與整體安全性設定

IT人生

0  comments

前言

作為一個不稱職的MIS,除了燒香保佑辦公室同事的電腦都乖乖地之外,最重要的莫非就是希望公司的Server也都可以乖乖的運作,每次更新(其實沒事最好不要亂更新啦,除非真的是很嚴重的security issue)都順順利利,可以跑很久都無病無痛. 在許多server中, 最容易被攻擊的非web server莫屬了,輕則首頁被竄改變成跳板, 重則在上面運行的商城平台的客戶資料外洩. 所以每次處理Web server總是戰戰兢兢. 一路走來, 從自己灌Linux server, 到國外的共享主機, 到有broker管理的虛擬主機cloudways, cloudways 還有這次要說的使用NAS當作網頁主機.

Synology有自帶Wordpress的套件, 也可以使用預設的來安裝, 但是那應該是為了配合NAS系統所做的修改版, 程式需要升級的時候也只能等wordpress的套件出來後才能做升級,對於系統安全性總是會慢了一步, 尤其是用作線上交易的網站.

這次要兜建的的網站就是未來要用作網路商城的網站, 自然安全性上就必須多加注意, 所以這邊就是以群暉的NAS主機當作Web Server, 安裝wordpress時的資料夾以及使用者權限的設定. 其他一些關於安全性的議題, 不見得僅能適用在NAS主機, 也同樣的使用在其他安裝wordpress的網站上.

Synology NAS的相關資訊

系統端的網頁程式使用群組為http, 若無則要新增 http

For better flexibility and security, Web Station uses the http user group to execute tasks. Therefore, to control the access permissions for your web pages, please change the http group’s access permissions for each corresponding folder and file. For example, if you want to make sample.htm file in the web shared folder accessible via Web Station, you’ll need to make sure the http group has proper read/write permissions for the web shared folder as well as the sample.htm file.

資料夾權限

WordPress官方的建議預設值

Typically, all files should be owned by your user (ftp) account on your web server, and should be writable by that account. On shared hosts, files should never be owned by the webserver process itself (sometimes this is www, or apache, or nobody user).

Any file that needs write access from WordPress should be owned or group-owned by the user account used by WordPress (which may be different than the server account)

Some plugins require the /wp-content/ folder be made writeable, but in such cases they will let you know during installation. In some cases, this may require assigning 755 permissions. The same is true for /wp-content/cache/ and maybe /wp-content/uploads/

All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.

/

The root WordPress directory: all files should be writable only by your user account, except .htaccess if you want WordPress to automatically generate rewrite rules for you.

/wp-admin/

The WordPress administration area: all files should be writable only by your user account.

/wp-includes/

The bulk of WordPress application logic: all files should be writable only by your user account.

/wp-content/

User-supplied content: intended to be writable by your user account and the web server process.

Within /wp-content/ you will find:

/wp-content/themes/

Theme files. If you want to use the built-in theme editor, all files need to be writable by the web server process. If you do not want to use the built-in theme editor, all files can be writable only by your user account.

/wp-content/plugins/

Plugin files: all files should be writable only by your user account.

Other directories that may be present with /wp-content/ should be documented by whichever plugin or theme requires them. Permissions may vary.

 

Default Permissions (umask 022)

644 -rw-r--r--  /home/user/wp-config.php
644 -rw-r--r--  /home/user/cgi-bin/.htaccess
644 -rw-r--r--  /home/user/cgi-bin/php.ini
755 -rwxr-xr-x  /home/user/cgi-bin/php.cgi
755 -rwxr-xr-x  /home/user/cgi-bin/php5.cgi

Secured Permissions

600 -rw------- /home/user/wp-config.php
604 -rw----r-- /home/user/cgi-bin/.htaccess
600 -rw------- /home/user/cgi-bin/php.ini
711 -rwx--x--x /home/user/cgi-bin/php.cgi
100 ---x------ /home/user/cgi-bin/php5.cgi

WordPress官方的強化建議

Securing wp-admin

Adding server-side password protection (such as BasicAuth) to /wp-admin/ adds a second layer of protection around your blog’s admin area, the login screen, and your files. This forces an attacker or bot to attack this second layer of protection instead of your actual admin files. Many WordPress attacks are carried out autonomously by malicious software bots.

Simply securing the wp-admin/ directory might also break some WordPress functionality, such as the AJAX handler at wp-admin/admin-ajax.php. See the Resources section for more documentation on how to password protect your wp-admin/ directory properly.

The most common attacks against a WordPress blog usually fall into two categories.

  1. Sending specially-crafted HTTP requests to your server with specific exploit payloads for specific vulnerabilities. These include old/outdated plugins and software.
  2. Attempting to gain access to your blog by using “brute-force” password guessing.

The ultimate implementation of this “second layer” password protection is to require an HTTPS SSL encrypted connection for administration, so that all communication and sensitive data is encrypted. See Administration Over SSL.

Securing wp-includes

A second layer of protection can be added where scripts are generally not intended to be accessed by any user. One way to do that is to block those scripts using mod_rewrite in the .htaccess file. Note: to ensure the code below is not overwritten by WordPress, place it outside the # BEGIN WordPress and # END WordPress tags in the .htaccess file. WordPress can overwrite anything between these tags.

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>


# BEGIN WordPress

Note that this won’t work well on Multisite, as RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] would prevent the ms-files.php file from generating images. Omitting that line will allow the code to work, but offers less security.

Securing wp-config.php

You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder.

Note: Some people assert that moving wp-config.php has minimal security benefits and, if not done carefully, may actually introduce serious vulnerabilities. Others disagree.

Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).

If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it:

<files wp-config.php>
order allow,deny
deny from all
</files>

Disable File Editing

The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files. This is often the first tool an attacker will use if able to login, since it allows code execution. WordPress has a constant to disable editing from Dashboard. Placing this line in wp-config.php is equivalent to removing the ‘edit_themes’, ‘edit_plugins’ and ‘edit_files’ capabilities of all users:

define('DISALLOW_FILE_EDIT', true);

This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks.

 

變更owner:group 指令

所有檔案的擁有者與群組設定為 admin(或自設的使用者名稱):http

資料夾權限設定為 755, 檔案權限為 644

chown admin(或自設的使用者名稱):http -R *
find . -type d -exec chmod 755 {} \; # Change directory permissions rwxr-xr-x
find . -type f -exec chmod 644 {} \; # Change file permissions rw-r–r–
chmod 600 wp-config.php
chmod 664 .htaccess

其他安全性議題

Vulnerabilities in WordPress

Updating WordPress

Web Server Vulnerabilities

Updating host server packages and apache, PHP

密碼

使用強化的密碼, 以及增加2步驟驗證

資料庫安全性

不要使用root作為連接資料庫的帳號,並且要設定root的密碼. 每一個資料庫使用不同的帳號密碼作連接

使用SSL

 

安裝硬體防火牆/防火牆Plugin

不使用預設的安裝名稱設定

  1. Rename the administrative account: When creating an administrative account, avoid easily guessed terms such as admin or webmaster as usernames because they are typically subject to attacks first. On an existing WordPress install you may rename the existing account in the MySQL command-line client with a command like UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin';, or by using a MySQL frontend like phpMyAdmin.
  2. Change the table_prefix: Many published WordPress-specific SQL-injection attacks make the assumption that the table_prefix is wp_, the default. Changing this can block at least some SQL injection attacks.

詳細記錄Server一切活動作後續分析

Logs are your best friend when it comes to understanding what is happening with your website, especially if you’re trying to perform forensics. Contrary to popular beliefs, logs allow you to see what was done and by who and when. Unfortunately the logs will not tell you who, username, logged in, but it will allow you to identify the IP and time and more importantly, the actions the attacker might have taken. You will be able to see any of these attacks via the logs – Cross Site Scripting (XSS), Remote File Inclusion (RFI), Local File Inclusion (LFI) and Directory Traversal attempts. You will also be able to see brute force attempts. There are various examples and tutorials available to help guide you through the process of parsing and analyzing your raw logs.

If you get more comfortable with your logs you’ll be able to see things like, when the theme and plugin editors are being used, when someone updates your widgets and when posts and pages are added. All key elements when doing forensic work on your web server. The are a few WordPress Security plugins that assist you with this as well, like the Sucuri Auditing tool or the Audit Trail plugin.

There are two key open-source solutions you’ll want on your web server from a security perspective, this is a layered approach to security.

OSSEC can run on any NIX distribution and will also run on Windows. When configured correctly its very powerful. The idea is correlate and aggregate all the logs. You have to be sure to configure it to capture all access_logs and error_logs and if you have multiple websites on the server account for that. You’ll also want to be sure to filter out the noise. By default you’ll see a lot of noise and you’ll want to configure it to be really effective.

最終的設定

 

參考網址

Hardening WordPress

https://www.synology.com/en-global/knowledgebase/DSM/help/WebStation/application_webserv_general/

Two Step Authentication

OSSEC For Website Security: Part I

 

 

 

About the author 

Jason Huang

從事留學遊學策略規劃工作多年的教育觀察者, 對學習永遠抱持熱忱,

You may also like

紀錄一下第一次學習Flask並Deploy到Heroku遇到的坑

安裝 Mattermost 後使用Mysql 5.7 搜尋中文搜尋不到的解決方法

MySQL won’t start – error: su: warning: cannot change directory to /nonexistent: No such file or directory

Leave a Reply

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!