System Monitoring – Page 3

JMeter #01: การสร้าง Load Test เบื้องต้น

February 10, 2017 14:34

Apache JMeter เป็น Open Source Software ที่พัฒนาด้วย Java 100% ออกแบบมาใช้สำหรับการทดสอบโหลดของพฤติกรรมการใช้งาน และวัดประสิทธิภาพ เดิมใช้เพื่อทดสอบ Web Application แต่ปัจจุบันสามารถใช้งานทดสอบได้หลากหลายขึ้นด้วย อ่านเพิ่มเติม: http://jmeter.apache.org/index.html บทความที่เกี่ยวข้อง: https://sysadmin.psu.ac.th/?s=jmeter ในการใช้งานทั่วไปเบื้องต้น สามารถอ่านได้จาก การติดตั้งโปรแกรมตรวจสอบประสิทธิภาพ Server : Apache JMeter บนเครื่อง Windows การวัดประสิทธิภาพ (Performance Test) [1] แบ่งออกเป็น Performance Testing Load Testing Stress Testing ในที่นี้จะใช้ JMeter ในการทำ Load Testing โดยจะทดสอบ Web Application ตามเป้าหมายต่อไปนี้ ทดสอบกับ Web Page ที่ตั้งไว้ ซึ่งประกอบด้วยภาพจำนวนมาก จำนวน Connection ต่อวินาที ในระดับต่างๆ ในแต่ระดับ จะมีหยุดรอ 10 วินาที ก่อนจะยกระดับที่สูงขึ้น ขั้นตอนการใช้งาน JMeter สร้าง Load Testing เนื่องจากการทดสอบจะยิงไปที่ Web Page เดียวกันตลอด จึงสร้าง HTTP Request Default เพื่อให้ง่ายต่อการเปลี่ยนแปลง โดยคลิกขวาที่ Test Pane เลือก Add > Config Element > HTTP Request Default ใน HTTP Request Default กรอก Server Name or IP Port Number Path ตามต้องการ เช่น ต้องการทดสอบ http://192.168.107.107:80/wordpress/?p=4 คลิกขวาที่ Test Plan เลือก Add > Threads (Users) > Thread Group กรอก Name และ Number of Threads (users) ในตัวอย่างนี้ ตั้งค่า Number of Threads (users) เป็น 10 และ Ramp-Up Period (in seconds) เป็น 1 เพราะต้องการให้ทดสอบระบบว่า เมื่อ มีผู้ใช้ใช้งานพร้อมกัน 10 คนในวินาทีเดียวกันนั้น ระบบจะตอบสนองอย่างไร คลิกขวาที่ Thread Group นี้ (ตอนนี้จะเปลี่ยนชื่อจาก Thread Group เป็น 10 แล้ว) แล้วเลือก Add > Sampler > Http Request ในส่วนนี้ ไม่ต้องแก้ไขอะไร โดย JMeter จะไปเอาค่าที่ตั้งไว้ใน HTTP Request Default ข้างต้นมาใช้ ต่อไป เป็นส่วนของการแสดงผล คลิกขวาที่ Test Plan เลือก Add > Listener > Summary Report ต่อไป ใส่ Timer เพื่อให้ระบบ หยุดพักการทดสอบ เมื่อทำแต่ละ Thread Group เสร็จ เป็นเวลา 10 วินาที ก่อนจะเริ่ม Thread Group ต่อไป คลิกขวาที่ Test Plan เลือก Add > Timer

Juju #02 – วิธีติดตั้ง WordPress

December 2, 2016 14:54

ในบทความนี้ จะแสดงวิธีการใช้ Juju เพื่อติดตั้ง WordPress พร้อมแสดงวิธีการเฝ้าระวังด้วย Nagios และ การ Scale Out เริ่มต้นจากคลิกที่ รูปเครื่องหมายบวก (+) สีเขียว ในช่องค้นหา พิมพ์คำว่า “wordpress” แล้วคลิก Enter จะปรากฏผลการค้นหา สิ่งนี้เรียกว่า Charm ซึ่งเป็น Image ของระบบปฏิบัติการ พร้อมทั้งการ Setup สิ่งที่เราต้องการมาให้เลย ในภาพให้คลิกที่คำว่า WordPress ด้านซ้ายมือ จากนั้น คลิก Add to canvas ต่อไป ทำซ้ำ โดยการค้นหาสิ่งต่อไปนี้ haproxy, mysql, nagios แล้วจัดระเบียบให้สวยงามตามต้องการ จากนั้น ลากเส้นเชื่อมโยงความสัมพันธ์กัน Juju จะสร้างการเชื่อมต่อต่างๆให้เองอัตโนมัติ ในภาพ จะเป็นการตั้งค่าให้ haproxy ทำหน้าที่เป็น Load Balance ให้ WordPress ซึ่งจะเกิดขึ้นอีกหลายเครื่องในอนาคต และ WordPress ก็จะเชื่อมต่อกับ MySQL นอกจากนั้น ก็มี Nagios ที่จะเฝ้าระวัง WordPress และ MySQL เมื่อลากเส้นเชื่อมโยงเสร็จแล้ว คลิก Commit Changes ด้านขวามือล่าง จากนั้นคลิกปุ่ม Deploy หลังจากนั้น Juju จะไปเรียก Image มาติดตั้ง และสร้างความสัมพันธ์ของระบบที่เราออกแบบไว้ เมื่อเสร็จแล้วจะได้ผลดังภาพ ต่อไปคลิกที่ haproxy แล้วคลิกคำว่า Expose เพื่อบอกให้ระบบนี้สามารถเข้าถึงจากภายนอกได้ ใน Expose ให้เลือก On ระบบจะแสดง IP Address ให้ ในที่นี้คือ 10.107.107.215 ซึ่งจะเข้าถึงโดยใช้ TCP Port 80 ที่ Nagios ก็เช่นกัน ให้ Expose เป็น On แล้วจะเข้าถึงได้จาก IP 10.107.107.95 จากนั้น คลิก Commit Changes ที่ IP Address 10.107.107.215 ก็จะพบการเริ่มต้นใช้งาน wordpress ทันที เริ่มจาก เลือกภาษา แล้วคลิก Continue จากนั้น ตั้ง Site Title, Username ที่จะเข้าใช้, Password, email address แล้วคลิก Install WordPress แค่นี้ก็ใช้ wordpress ได้แล้ว ที่ Nagios ก็จะสามารถใช้งานได้ที่ IP 10.107.107.95 (วิธีการเข้าใช้งาน มี Username/Password ที่กำหนดไว้แล้ว) ใน Nagios คลิก Service เพื่อเฝ้ารายละเอียดของ Service ต่างๆ ใน Nagios คลิกที่ Map เพื่อดูผังการเชื่อมต่อ เมื่อมีการใช้งานมากขึ้น ก็สามารถเพิ่มเครื่อง WordPress เพื่อให้รองรับการเชื่อมต่อจำนวนมากขึ้นได้ โดยใน Juju คลิกที่ WordPress แล้วคลิก Scale จากนั้นให้เพิ่มเครื่องไปอีก 1 เครื่อง แล้วคลิก Confirm จากนั้นคลิก Commit Changes รอสักครู่ ก็จะพบว่า ใน Nagios ก็จะเพิ่มเครื่องใหม่ในการเฝ้าระวังให้เองอัตโนมัติด้วย จะง่ายไปไหน?

การตั้งค่า MaxRequestWorkers บน Apache ให้เหมาะสมกับจำนวนผู้ใช้

August 15, 2016 16:29

ปัญหาของ PSU Webmail ในช่วง 9-15 สิงหาคม 2559 ที่ผ่านมา คือ เมื่อเริ่มเข้าสู่เวลาราชการ ในวันทำการ พบว่า มีการตอบสนองที่ช้า บางครั้งต้องรอถึง 15-20 วินาที หรือ ผู้ใช้บางท่านแจ้งว่า Timeout ไปเลย หรือไม่ก็ใช้งานไปสักพัก ถูกดีดกลับมาหน้า Login ใหม่ แต่เมื่อพ้นเวลาราชการ พบว่าการตอบสนองก็เร็วขึ้นดังเดิม รวมถึงในช่วงวันหยุดก็เร็วอย่างที่ควรเป็น ขอบคุณทาง NetAdmin ที่ทำระบบตรวจสอบไว้ที่หน้า Data Center เพื่อตรวจจับความเร็วในการตอบสนองบริการ PSU Webmail ด้วย SmokePing ผลที่ได้เป็นดังภาพ จะเห็นว่า มีความหน่วงในการตอบสนอง เฉพาะในวันเวลาราชการเท่านั้น … ทำไม ??? ทำการตรวจสอบด้วยคำสั่ง ps aux |grep apache| wc -l เพื่อดูว่า มีจำนวน Apache อยู่กี่ Process พบว่า ในช่วงเวลาที่ระบบหน่วง มี Process เกือบคงที่ที่ 150 แต่ในช่วงที่ระบบทำงานได้เร็ว มีจำนวนประมาณ 50 process จากการศึกษา พบว่า Apache2 ที่ใช้ MPM Prefork นั้น จะจำกัดค่า MaxRequestWorkers ไว้ โดยหากไม่กำหนดค่าใดๆจะตั้งไว้ที่ 256 แต่เมื่อตรวจสอบในไฟล์ /etc/apache2/mods-enabled/mpm_prefork.conf พบว่า <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxRequestWorkers 150 MaxConnectionsPerChild 0 </IfModule> ทำให้เพดานของจำนวน Process ไปจำกัดที่ 150 ดังที่ตรวจสอบเบื้องต้น เมื่อมีผู้ใช้มากขึ้นกว่าเดิม จึงทำให้ Process ไม่เพียงพอต่อความต้องการ เป็นผลให้เกิดการหน่วงขึ้น จึงทำการแก้ไข MaxRequestWorkers เป็น 256 แล้ว Restart Apache ผลทำให้ จำนวน Apache Process ขึ้นไปถึง 200 Process และการตอบสนองเร็วขึ้นตามที่ควรเป็นดังภาพ (หลังเวลา 14:45) ทั้งนี้ การกำหนดจำนวน MaxRequestWorkers นั้น ต้องสัมพันธ์กับ RAM ของ Server ด้วย โดยมีสูตรคร่าวๆ คือ จำนวน RAM ในหน่วย MB หารด้วยขนาดของ Apache Process โดยเฉลี่ย เช่น มี RAM 4GB = 4 x 1024 = 4096 ขนาดเฉลี่ย Apache Process = 20 ดังนั้น MaxRequestWorkers = 4096/20 = 204 แต่จริงๆแล้ว ควรเผื่อ Memory ไว้ให้ OS และอื่นๆด้วย (อาจจะไม่เต็ม 4096) หากขยับค่า MaxRequestWorkers แล้วยังพบว่า จำนวน Process ยังขึ้นไปเต็มเพดานอยู่ ควรพิจารณาเพิ่ม Memory ด้วย ประมาณนี้ครับ UPDATE: ผลการปรับแก้ไข ทำให้ เวลาในการตอบสนอง จากที่หน่วง 10 วินาที เหลือ เพียง 50 มิลลิวินาที ดังภาพ

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

August 1, 2016 15:24

ได้รับแจ้งจาก ThaiCERT ว่ามีเว็บไซต์ภายในโดเมนของมหาวิทยาลัย เผยแพร่ Code อันตราย ดังต่อไปนี้ จึงเข้าทำการตรวจสอบในเครื่องเว็บเซิร์ฟเวอร์ดังกล่าว พบการวางไฟล์ Backdoor ไว้ดังที่อธิบายใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #17 แล้ว แต่ที่เห็นผิดปรกติ ก็เป็นใน access.log ของ Apache ซึ่งพบว่า มีการเรียกใช้ xmlrpc.php เป็นจำนวนมาก ดังภาพ จากการตรวจสอบ พบว่า xmlrpc.php เป็นช่องทางให้สามารถเรียกใช้ Function ต่างๆผ่านทาง HTTP และเป็นช่องทางให้ App ต่างๆสามารถติดต่อกับ WordPress ได้ แต่ก็เป็นช่องทางให้เกิดการเดารหัสผ่านจำนวนมากได้เช่นกัน (Brute Force Attack) โดยสามารถทดลอง ส่ง XML ที่มีโครงสร้าตามที่ API กำหนด เช่น wp.getUsersBlogs [1][2][3] สามารถดูจำนวน Blog ที่ User คนนั้นๆเขียนขึ้นมา แต่ ต้องระบุ username/password ซึ่งตรงนี้จะเป็นส่วนที่ทำให้เกิดการ Brute Force ได้ ด้วยคำสั่งต่อไปนี้ เป็นการเดารหัสผ่านไปยัง http://localhost/blog/xmlrpc.php echo “<methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value> <string>admin</string></value></param> <param><value><string>password</string></value></param></params></methodCall>” | POST http://localhost/blog/xmlrpc.php หากสำเร็จ จะได้คำตอบมาอย่างนี้ หากเป็น WordPress รุ่นต่ำกว่า 4.0 เปิดให้ใช้ system.multicall ซึ่งทำให้สามารถเดารหัสผ่านจำนวนมาก ใน 1 Request ทำให้ระบบตรวจจับได้ยาก ดังนั้น หากไม่จำเป็นต้องใช้ xmlrpc.php ก็สมควรปิดการใช้งานที่ระดับ Apache โดยสร้างไฟล์ /etc/apache2/conf-enabled/xmlrpc.conf มีข้อมูลเป็น <FileMatch “xmlrpc\.php$”> Order Deny,Allow Deny from All </FileMatch> จากนั้น Restart Apache ก็สามารถปิดการทำงานได้ Reference [1] http://www.hackingsec.in/2014/08/wordpress-xml-rpc-brute-force-attack.html# [2] http://blog.dewhurstsecurity.com/2012/12/11/introduction-to-the-wordpress-xml-rpc-api.html [3] https://codex.wordpress.org/XML-RPC_WordPress_API

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

July 29, 2016 15:31

ปัจจุบันพบว่า รูปแบบของ Backdoor เปลี่ยนไป จากเดิมเป็น Base64 ซึ่งสามารถตรวจจับได้จาก Pattern ของ eval และ base64_decode ไปเป็น การใช้ eval ร่วมกับการใช้เทคนิคที่เรียกว่า Obfuscate หรือ การทำให้ PHP Code ปรกติ แปลงไปเป็นรูปแบบที่ซับซ้อนยิ่งขึ้น ทำให้การตรวจสอบด้วยเทคนิคเดิมไม่เจอ จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2 แสดงให้เห็นรูปแบบเดิม ดังภาพ จะเปลี่ยนมาเป็นแบบนี้ ดังนั้น อาจจะต้องปรับเปลี่ยนคำสั่งในการค้นหาเป็น find /var/www -name “*.php” -user www-data -type f | xargs grep GLOBAL แต่ก็พบว่า มีการซ่อน base64_decode ในรูปแบบนี้ก็มี ถึงแม้จะเลี่ยงการใช้ base64_decode ตรงๆแต่ก็ยังต้องใช้ eval อยู่ดี ดังนั้น จึงต้องใช้คำสั่งต่อไปนี้ในการค้นหา find /var/www -name “*.php” -user www-data -type f | xargs grep eval > eval.txt ซึ่งอาจจะได้ไฟล์มาจำนวนมาก ทั้งทีใช่และไม่ใช่ Backdoor เก็บไว้ในไฟล์ eval.txt ดังภาพ จึงต้องใช้วิธี แก้ไขไฟล์ eval.txt ดังกล่าว โดยลบบรรทัดที่ไม่ใช่ Backdoor ออก ให้เหลือแต่บรรทัดที่น่าสงสัยว่าจะเป็น Backdoor ไว้ แล้ว Save จากนั้นใช้คำสั่งต่อไปนี้เพื่อเก็บไฟล์ทั้งหมดไว้ก่อน ในไฟล์ suspect.tar.gz cut -d: -f1 eval.txt | xargs tar -zcvf suspect.tar.gz จากนั้น ทำ List ของไฟล์ที่ต้องเข้าตรวจสอบจริงๆ เก็บในไฟล์ชื่อ eval2.txt ด้วยคำสั่ง cut -d: -f1 eval.txt > eval2.txt แล้วจึงแก้ไขไฟล์ หรือ ลบทิ้งต่อไป