การใช้งาน error_log() ของ PHP ในการบันทึกค่าต่างๆ

ในการเฝ้าระวังระบบที่เป็น PHP Web Application บางครั้งก็ต้องการเก็บค่าบางอย่างลง Log file ทำไงดี ? อาจจะใช้วิธี สร้างไฟล์ไว้ในพื้นที่ ที่ web user สามารถเขียนได้ แล้วก็จัดการเอง ด้วย function พวก fopen(), fwrite(), fclose(); เช่น $fp = fopen(‘/var/log/mylog.txt’, ‘a’); fwrite($fp, ‘20121207:some text’); fclose($fp); เป็นต้น ซึ่ง ก็พอจะทำได้ แต่ต้องคำนึงถึงเรื่อง permission ในการเขียน และพวกสิทธิต่างๆ ใน PHP เราสามารถบันทึกสิ่งต่างๆลงไปในไฟล์ System Log ได้เลย โดยใช้ฟังก์ชั่น error_log นอกจากนั้น ยังสามารถเลือกให้เป็นการส่ง email แทนการเขียน log ลงไฟล์ก็ได้ หรือ จะเลือกเขียนลงไฟล์อื่นที่แยกไปจาก System Log ก็ได้ การใช้งาน error_log(message, message_type, destination, options) message: เป็นข้อความที่ต้องการบันทึก message_type: ใช้ค่า 0,1,3,4 ซึ่งมีความหมายดังนี้ 0: เป็นค่า Default ซึ่งเขียนลงไปใน System Log (ตามที่ระบุในค่า error_log ของ PHP ในไฟล์ php.ini) 1: เลือกให้ส่ง message ในรูปแบบ email ไปยัง destination โดยใช้ Header ของ email ตาม options 3: เลือกให้เขียน message ลงในไฟล์ที่กำหนดใน destination (ไม่ใช่ system log) โดยจะต้องเขียน newline ต่อท้ายบรรทัดเอง 4:  เลือกให้เขียนลงไปใน SAPI (จากการทดสอบบน apache บน Ubuntu พบว่า เขียนลงที่เดียวกับ System Log) destination: หาก message_type=1 ให้ระบบ email address ที่ต้องการส่งถึง, หาก message_type=3 ให้ระบุตำแหน่งของไฟล์ที่ต้องการเขียน options: ในกรณี message_type=1 สามารถระบุ header ของ email ได้ ลองเขียน PHP ตามนี้ ลงในไฟล์ test-error_log.php <?php #ini_set(‘error_log’,’/var/log/myother.log’); echo ‘error_log = ‘ . ini_get(‘error_log’) . “\n”; error_log(“This is error_log #0”, 0); error_log(“This is error_log #1”, 1, “username.s@yourdomain.com”, “Subject: Message Type #1\n”); error_log(“This is error_log #3”, 3, “/var/log/mytest.log”); error_log(“This is error_log #4”, 4); ?> แล้วใช้คำสั่ง php  test-error_log.php ผลที่ออกมานั้น ถ้า 1. ใน php.ini ไม่ได้ระบุว่า error_log เขียนไปที่ไหน (error_log=) ก็จะแสดงผลออกมาทาง stderr error_log = This is error_log #0 This is error_log #4 จะมี email ส่งถึงตัวเรา มี Subject

Read More »

กิจกรรม CoP PSU sysadmin KM1 “การทำงานกับ PSU Passport”

กิจกรรม CoP PSU sysadmin KM1 “การทำงานกับ PSU Passport” วันที่ 21 ธ.ค. 55 เวลา 09.30 – 14.00 น. มีอาหารเที่ยงเลี้ยงด้วย พบกันที่ห้อง 102 ศูนย์คอมพิวเตอร์ ม.อ. หาดใหญ่ครับ กำหนดการ เวลา 09.30 – 10.00 น. ลงทะเบียนและรับประทานอาหารว่าง เวลา 10.00 – 12.00 น. แลกเปลี่ยนเรียนรู้ หัวข้อ “การทำงานกับ PSU Passport” เวลา 12.00 – 13.00 น. รับประทานอาหารเที่ยงร่วมกัน เวลา 13.00 – 14.00 น. ตอบปัญหาและข้อซักถาม นำเสนอโดย คุณจตุพร ชูช่วย แอดมินทีมเซิร์ฟเวอร์ ศูนย์คอมพิวเตอร์ ม.อ. หาดใหญ่ รอบนี่้ผมคิดว่า คุยกันไม่ต้องเร่งรีบมาก ในช่วงแรก แล้วเบรคพักเที่ยง ทานข้าวด้วยกัน แล้วถ้ายังมีคำถามไว้ในช่วงบ่ายอีก 1 ชั่วโมงครับ (ดูรายชื่อผู้ที่แจ้งเข้าร่วม) หัวข้อที่จะเล่าและตอบคำถาม 1. โครงสร้างของระบบ PSU Passport 2. การนำเข้าข้อมูลเพื่อสร้าง Account บน PSU Passport 3. บริการของระบบ PSU Passport (ldap/ldaps,web service,ระบบเปลี่ยนรหัสผ่าน) 4. สิทธิการเข้าถึงชั้นความลับของ PSU Passport (ระบบความปลอดภัยของข้อมูล) 5. ข้อกำหนดใช้บริการ PSU Passport (พรบ. คอม 50) 6. ระบบจัดการข้อมูลบน PSU Passport (AdsAdmin) 7. การออก Account ในกลุ่มอื่น ๆ (Guest,VIP,LAB) 8. ตัวอย่างการเข้าใช้งานบน Application ต่าง ๆ (LDAP,Web Service) 9. ระบบลงทะเบียน Server Authen ในอนาคต 10. แนวทางการเผยแพร่ความรู้ในอนาคต 11. ตอบคำถามกวนใจใคร ช่วง ตอบคำถามกวนใจใคร เช่น ผู้ใช้: อยากให้ศูนย์คอมฯมี database view ของ PSU Passport เพื่อให้คณะคอนเนคเข้ามาได้ แอดมินศูนย์: – ข้อมูลอะไรครับ หากเฉพาะ user/password ก็ใข้ passport ได้อยู่แล้ว ? – หากเป็นข้อมูลบุคลากรให้ติดต่อการเจ้าหน้าที่มหาวิทยาลัยเพื่อขอสิทธิ์เข้าถึงข้อมูลครับ – และหากเป็นข้อมูลนักศึกษาให้ติดต่อทะเบียนกลางเพื่อขอสิทธิ์เข้าถึงข้อมูล ครับ ผู้ใช้: ถ้าให้ 0com เป็นตัวกลาง ประสานงานให้ แบบ one stop service ได้มั้ยครับ แบบว่าไม่ต้องไปติดต่อหลายที่ แอดมินศูนย์: ไม่ได้ครับ เพราะเราไม่ใช่เจ้าของข้อมูล เป็นแค่ที่เก็บ ต้องขอเจ้าของครับ ผู้ใช้: สามารถทำให้ antivirus แต่ละค่าย สามารถ update อัตโนมัติได้โดยไม่ต้อง authen psu passport ได้ไหม เพราะโดยปกติเครื่องคอมขึ้นมา โปรแกรม antivirus จะทำการ update ให้อัตโนมัติ เครื่องคอมผู้ใช้ ถ้าไม่ได้ authen psu passport ผ่านหน้าเว็บทันที จะขึ้น โปรแกรม antivirus จะเตือน update failed ผู้ใช้: ไม่แน่ใจว่า ตอนนี้ ศูนย์คอมเปิดเป็น web service

Read More »

Mail Clustering with Cyrus Murder

ปัจจุบันมีการใช้งาน e-mail มากขึ้น และมีการเก็บข้อมูลต่างๆใน email ไว้เป็นจำนวนมาก ทำให้ Mail Server ของหน่วยงานเดิม อาจจะมีเนื้อที่ไม่เพียงพอต่อการใช้งาน ทำให้ต้องมีการขยายพื้นที่ Mail Server ให้มากขึ้น วิธีการที่นิยมใช้กันคือ ซื้อระบบใหม่ที่มี Harddisk ใหญ่ขึ้น หรือ ต่อกับระบบ Storage ที่ใหญ่ขึ้น (เช่น SAN หรือ Storage Cluster) วิธีการนี้ เรียกว่า Scale-Up ซึ่งเมื่อมีการใช้งานต่อไป แล้วข้อมูลจัดเก็บมากขึ้น ก็ต้องวางแผนในการซื้อระบบที่ใหญ่ขึ้นไปอีก ข้อดี: 1. เป็นวิธีการที่นิยมทำกัน 2.ได้ระบบใหม่ที่มีศักยภาพสูงขึ้นเรื่อยๆ ข้อเสีย: 1. เมื่อจะย้ายระบบใหม่ จะเกิด Downtime เพราะต้องหยุดการทำงานของระบบเดิมทั้งระบบ 2.  ในการย้ายข้อมูล email ซึ่งมีปริมาณมาก ต้องใช้เวลานาน และเสี่ยงต่อข้อมูลที่ไม่เป็นปัจจุบันที่สุดด้วย (ล่าสุดที่ทำการย้ายข้อมูลขนาด 300 GB ซึ่งลักษณะ email ที่ใช้เก็บข้อมูลเป็นไฟล์เล็กๆจำนวนมาก ต้องใช้เวลาถึง 18 ชั่วโมง) 3. และที่หลีกเลี่ยงไม่ได้ ระบบแบบเดิมนี้ เป็น “Single Point of Failure” กล่าวคือ  ถ้าระบบเสียหาย ก็จะกระทบกับผู้ใช้ทั้งหมด   แต่มีอีกแนวทางหนึ่ง เรียกว่าการ Scale-Out คือ การใช้ระบบที่เป็น Mail Cluster แทน เมื่อมีความต้องการขยายพื้นที่ ก็เพียงแต่ซื้อเครื่องใหม่ แล้วเพิ่มเข้าสู่ระบบ Cluster แล้วเริ่มต้นใช้งานต่อเนื่องได้ แนวทาง Scale-Out ทำให้สามารถขยายพื้นที่จัดเก็บได้เรื่อยๆ อย่างต่อเนื่อง ข้อดี: 1.ลดปัญหา Single Point of Failure โดยการกระจายที่จัดเก็บไปใน Server ต่างๆใน Cluster เมื่อเกิดความเสียหากับเครื่องใดเครื่องหนึ่ง ก็จะไม่กระทบกับผู้ใช้ทั้งหมด 2. เมื่อต้องการพื้นที่จัดเก็บเพิ่ม ไม่ต้องหยุดการทำงานทั้งระบบ เพียงเพิ่มเครื่องใหม่เข้าใน Cluster แล้วปรับแต่งค่าเพียงเล็กน้อย ก็สามารถใช้งานได้เลย ข้อเสีย: 1. ระบบมีความซับซ้อนยิ่งขึ้น มีระบบต้องเฝ้าระวังมากขึ้น ในระบบ PSU E-Mail Service ใช้โอเพนซอร์สซอฟต์แวร์ในการบริการ Email คือ cyrus-imapd ซึ่งสามารถสร้างระบบ Mail Cluster ด้วยการติดตั้งแพคเกจที่ชื่อว่า cyrus-murder ได้ Cyrus Murder ประกอบไปด้วย Server 3 ประเภท 1. Backend Servers: ทำหน้าที่เก็บ Mailbox ของผู้ใช้, โดยแต่ละเครื่องจะรายงานรายละเอียดของ Mailbox ที่อยู่บนเครื่องตนเอง ให้ MUPDATE Server ทราบ 2. Frontend Servers: ทำหน้าที่บริการ IMAP/POP ให้กับ Mail Client และ บริการ SMTP เพื่อส่งถึง Mailbox ที่อยู่บน Backend Servers ที่ถูกต้อง โดยอาศัยบริการของ MUPDATE Server เพื่อให้ทราบว่า Mailbox ที่ต้องการติดต่อด้วย อยู่บน Backend Server เครื่องใด 3. MUPDATE Servers: ทำหน้าที่เป็นฐานข้อมูลกลางของ Mailbox ทั้งหมดใน Backend Cluster โดยรับรายงานจาก Backend Servers และบริการตอบ Fronend Servers ว่า Mailbox ที่ต้องการติดต่อด้วย อยู่บน Backend Server เครื่องใด อ่านต่อ: – ระบบ Cyrus Murder ทำงานอย่างไร – วิธีการติดตั้ง

Read More »

การใช้ fail2ban สำหรับการตั้งรับ DNS Brute Force Query Attack

ต่อเนื่องจาก บทความนี้ หลังจากวิธีการใช้งาน blackhole เพื่อให้ bind9 ไม่ตอบกลับ query ที่ client ส่งมา แล้วพบว่าวิธีการนี้ จะมีปัญหากับการโจมตีแบบ DDoS ดังนั้น เราก็ต้องรับมือกับการโจมตีแบบนี้ด้วยเครื่องมืออื่นๆแทน เครื่องมืที่ผมใช้งานแล้วพบว่ามีประโยชน์มากตัวนึง สำหรับการป้องกันการโจมตีแบบอัตโนมัติก็คือ fail2ban ซึ่งบน Debian/Ubuntu สามารถติดตั้งได้ด้วยคำสั่ง $ sudo apt-get install fail2ban ซึ่งจะสร้าง configuration file ของ fail2ban ขึ้นมาอยู่ใน directory /etc/fail2ban configuration ของ fail2ban จะแบ่งเป็นส่วนของการตรวจจับ (โดยการใช้ regular expression) จาก log file ที่กำหนดไว้ (ซึ่งจะอยู่ใน directory /etc/fail2ban/filter.d)  และสามารถ กำหนด action (ซึ่งจะอยู่ใน directory /etc/fail2ban/action.d) ซึ่งใช้ในการ ban  การเข้าใช้งาน service ของ server ของเรา หรือตอบสนองแบบอื่นๆ เช่นส่ง email ไปเตือน admin ได้ มี action ที่ได้กำหนดเอาไว้แล้วหลายรูปแบบ ในที่นี้ ผมจะเลือกใช้ iptables filter สำหรับการ filter query packet ที่จะเข้ามา ซึ่ง config นี้ จะอยู่ในไฟล์ /etc/fail2ban/action.d/iptables.conf ส่วนของการ ตรวจจับ จะมีตัวอย่างของการ เขียน expression เอาไว้แล้วในไฟล์ตัวอย่าง ที่มีอยู่ใน /etc/fail2ban/filter.d ซึ่งสำหรับกรณีนี้ ผมจะสร้างไฟล์ขึ้นมาใหม่ชื่อ named-query-dos.conf โดยจะมีข้อมูลในไฟล์ดังต่อไปนี้ [Definition] failregex = client <HOST>#.+: query: isc.org IN ANY \+ED .+ ignoreregex = โดยบรรทัด failregex จะเป็น regular expression ที่ได้มาจาก logfile /var/log/named/query.log ซึ่งจะมีรูปแบบของการ query ที่แน่นอน นั่นคือ query “isc.org” แบบ ANY และมี flag ของการ query คือ ‘ED’ 28-Nov-2012 11:23:54.063 client 46.160.80.232#25345: query: isc.org IN ANY +ED ส่วน filed ของ วันที่/เวลา จะเปลี่ยนไปเรื่อยๆตามเวลาของการ query ที่เกิดขึ้น หมายเลข ip ของ client จะถูก match กับ <HOST> และส่งกลับไปให้ action ซึ่งจะนำเอาไปใช้ต่อไป ส่วนของ action เราจะใช้ iptables สำหรับการ filter ซึ่งจะมี config กำหนดเอาไว้แล้ว ซึ่งไม่ต้องวเปลี่ยนแปลงอะไร ส่วนของการ config ที่จะต้องเพิ่มขึ้นมาก็คือ ระบุให้ตัว fail2ban รู้ว่าจะต้องเอา config ส่วนนี้ไปใช้ โดยการเพิ่มข้อมูลต่อไปนี้ เข้าไปในไฟล์ /etc/fail2ban/jail.conf [named-query-dos] enaled = true banaction = iptables port = domain,53 protocol = udp filter = named-query-dos logpath  = /var/log/named/query.log bantime 

Read More »

ตั้งรับและตอบโต้การโจมตี DNS Brute Force Query Attack

ต่อเนื่องจาก บทความนี้ หลังจากรู้แล้วว่า DNS Server ของเราถูกโจมตีล่ะนะ ทีนี้จะตอบโต้อย่างไรดี? ถ้าหากการโจมตีมันไม่ได้เป็น distribution คือตรวจสอบแล้วมาจาก host เพียงตัวเดียวหรือไม่กี่ตัว ก็สามารถตอบโต้แบบง่ายๆได้ โดยใช้ความสามารถของ bind9 เอง bind9 จะมี option ที่จะสามารถ block การ query จาก client ได้ โดยสามารถระบุเป็น ip เดี่ยวๆ หรือเป็น block ของ ip network โดยการเพิ่มเป็น blackhole ใน named.conf.options แบบนี้ครับ สมมติ options config เดิมของ bind9 คือ options {     directory “/var/cache/bind”;     forward only;     forwarders {          192.100.77.2;          192.100.77.5;     };     auth-nxdomain no;    # conform to RFC1035     listen-on-v6 { any; }; }; เราสามารถเพิ่ม include “/etc/bind/blackhole.list”; เข้าไปก่อน บรรทัด “};” ซึ่งเป็นบรรทัดล่างสุดของ options เป็น options {     directory “/var/cache/bind”;     forward only;     forwarders {          192.100.77.2;          192.100.77.5;     };     auth-nxdomain no;    # conform to RFC1035     listen-on-v6 { any; }; include “/etc/bind/blackhole.list”; }; โดยข้อมูลในไฟล์ /etc/bind/blackhole.list จะมีข้อมูลดังนี้ blackhole {     174.127.92.85;     31.210.155.237;     178.32.76.101;    … }; ซึ่งวิธีการนี้ ทำให้เราสามารถแก้ไขเฉพาะไฟล์ blackhole.list โดยไม่ต้องไปแก้ไข named.conf.options เมื่อมีการโจมตีโดยใช้ ip address ใหม่เกิดขึ้น อย่างไรก็ตาม ผมพบว่า วิธีการนี้ ไม่ค่อยได้ผลสักเท่าไหร่ ถ้าการโจมตีเป็นแบบ DoS หรือ DDoS เพราะ ผู้ที่โจมตี ไม่ได้สนใจข้อมูลที่ DNS Server ของเราจะส่งกลับไป เพียงแต่ต้องการทำให้ Server ทำงานหนักขึ้นเท่านั้น การระบุ blackhole list จะทำให้ DNS Server ส่งคำตอบกลับไปยัง client ที่ query มาว่า REFUSED แต่ก็จะยังมีการตอบกลับ และมีการบันทึกการ query ลงสู่ record อยู่ นอกจากนี้ ถ้าเป็น DDoS ซึ่งจะมี client ที่มี ip address ใหม่ๆ โจมตีเข้ามาเรื่อยๆ การแก้ไขไฟล์ blackhole.list เพื่อให้ทันสมัยอยู่เสมอ ก็แทบที่จะทำให้วิธีการนี้ ใช้ป้องกันจริงๆไม่ได้ ซึ่งก็จะขอเสนอเป็นบทความต่อไปครับ การใช้ fail2ban เพื่อป้องกันการโจมตีแบบ

Read More »