ฉัตรชัย จันทร์พริ้ม – Page 2

update fail2ban after DNS query attack

December 11, 2013 15:10

หลังจากทิ้งไว้นานกว่า 1 ปี ในที่สุดการโจมตีในลักษณะของการ DOS attack สำหรับ DNS Server ก็กลับมาอีกรอบ วันนี้ (2013-12-11) คุณ สงกรานต์ก็ post ข้อความในกลุ่ม PSU Sysadmin บน facebook ว่า DNS Server หลายๆเครื่องที่อยู่ภายในเครือข่ายของ PSU มี traffic เกิดขึ้นมากผิดปกติ และมากกว่าตัว DNS Server หลักของมหาวิทยาลัยเอง {ns1,ns2}.psu.ac.th ซึ่งตัว DNS Server ทั้งสองโดยทั่วไปแล้ว เนื่องจากเป็นเซิร์ฟเวอร์ที่ให้บริการเป็นหลักให้กับเครื่องคอมพิวเตอร์ทั้งหมดภายในมหาวิทยาลัย ก็ควรที่จะมี traffic สูงกว่า DNS Server ตัวอื่นๆ แต่เมื่อเครื่อง DNS Server อื่นๆมี traffic สูงกว่า ก็พอที่จะบอกได้คร่าวๆล่ะว่า มีเหตุการณ์ผิดปกติเกิดขึ้นแน่ๆ ในจำนวน server เหล่านั้น มีเครื่องเซิร์ฟเวอร์ที่ผมดูแลอยู่ด้วย เป็นเครื่องที่ใช้สำหรับสอน นศ. ในรายวิชา Linux Server Admin. ซึ่งหัวข้อหนึ่งที่นศ.จะต้องเรียน ก็คือการติดตั้งและให้บริการ Name Service ซึ่งเครื่องเซิร์เวอร์เครื่องนี้ นอกจากจะใช้เป็นตัวอย่างในการ setup แล้ว ยังทำหน้าที่เป็น 2nd DNS ให้กับ domain ของ นศ. ทั้งหมดด้วย (นศ. มี domain ของตัวเองคนละ 1 domain) logfile ที่เกิดจากการ query มีขนาดมากกว่า 2GB จากการเก็บ log ของการ query ในช่วงเวลาประมาณ 3 วันครึ่ง (เริ่ม 2013-12-08 16:25 จนถึง 2013-12-11 12:40) เมื่อเทียบกับ log ปกติมีขนาดประมาณ 1-2 MB สำหรับการเก็บ log ในช่วง 1 สัปดาห์ หรือถ้าเทียบในแง่ของจำนวนของการ query ในช่วง 3 วันที่ผ่านมามีการ query ประมาณ 18 ล้านครั้ง เมื่อเทียบกับการ query ปกติประมาณ 15,000 ครั้งต่อสัปดาห์ การโจมติมาจากใหนบ้าง? 7778377 95.211.115.114 3870621 93.170.4.34 2596494 94.198.114.135 2581297 95.211.216.168 331584 199.59.161.6 53137 216.246.109.162 47351 205.251.194.32 46793 205.251.193.79 41119 156.154.166.38 39572 156.154.166.37 39501 54.230.130.116 36855 205.251.198.179 34079 42.112.16.162 31690 134.255.243.100 28662 205.251.197.226 27481 212.118.48.20 23435 204.188.252.146 20565 82.221.105.131 20477 89.184.81.131 19036 95.141.37.197 17404 72.20.56.200 14156 206.72.192.13 11510 82.221.105.139 10387 5.135.14.245 ตัวเลขในคอลัมน์แรกคือจำนวนครั้งที่มีการ query และในคอลัมน์ที่สองเป็น ip address query อะไรบ้าง? ถ้าดูข้อมูลคร่าวๆก็จะได้ 08-Dec-2013 06:58:54.295 client 192.99.1.168#9118: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85) 08-Dec-2013 06:58:54.296 client 192.99.1.168#19072: view

Check previous running script using process id

May 1, 2013 15:14

วันนี้ในกลุ่ม sysadmin บน facebook คุยกันเรื่องของ ubuntu mirror ของ PSU แล้วมีประเด็นของการใช้ script สำหรับการ mirror ตัว script ที่ว่านี้ จะเป็น shell script ธรรมดา ที่จะไปเรียกใช้โปรแกรม rsync ที่จะทำหน้าที่ mirror ข้อมูลจาก primary ftp/rsync site ของ ubuntu มาเก็บไว้ที่เครื่อง server ของ PSU ตัว script จะถูกเรียกใช้โดย cron กำหนดไว้ใน crontab และเรียกใช้ 4-6 ครั้งใน 1 วัน (หรือ run ทุกๆ 6 หรือ 4 ชั่วโมง) ระยะเวลาที่ใช้ในการ run script ไม่แน่นอนว่าจะใช้เวลาเท่าไหร่ ขึ้นอยู่กับปริมาณของข้อมูลที่จะต้อง mirror จากต้นทางมายังปลายทาง ถึงแม้ว่าการใช้ rsync จะช่วยให้ transfer เฉพาะไฟล์ ที่มีการเปลี่ยนแปลงไป หลังจากการ mirror ครั้งสุดท้ายมา แต่ในบางครั้งจำนวนของข้อมูลที่เปลี่ยนแปลงไป ก็อาจจะมากกว่าปกติ เช่นในช่วงเวลาที่มีการเปลี่ยน release ซึ่งทำให้มีไฟล์ใหม่ๆ เพิ่มขึ้นเป็นจำนวนมาก ทำให้ จากช่วงปกติ ซึ่งอาจจะใช้เวลาเพียง 1-2 ชม. ในการ mirror และ mirror ทุกๆ 4 ชม. ก็เพียงพอ ในช่วงเวลาของการปรับเปลี่ยน release ถ้าจะ mirror ให้เสร็จ ก็อาจจะใช้เวลาถึง 12 ชม. เป็นต้น จะเกิดอะไรขึ้น ถ้าในการ mirror ครั้งที่แล้ว ยังไม่เสร็จสิ้นสมบูรณ์ แล้วก็ถึงเวลาของการ mirror รอบถัดไป? ถ้าไม่มีการตรวจสอบใดๆเลย กระบวนการของการ mirror ในครั้งถัดมาก็จะเริ่มทำงาน ในขณะที่รอบแรกยังไม่เสร็จ และ ถ้ามีข้อมูลที่ถูกเปลี่ยนแปลงมากจริงๆ ถึงรอบที่ 4-5 ของการ mirror แล้ว … การ mirror ครั้งแรกก็ยังไม่เสร็จเรียบร้อยดี … และพอถึงขั้นนี้แล้ว ระบบจะมีภาระงานสะสมมากขึ้นเรื่อยๆ และระบบเริ่มช้าลง และ จำนวน process ของการ mirror ที่คั้งค้างอยู่ก็จะเพิ่มขึ้นเรื่อยๆ เพราะ process หลังๆ ก็จะไปหน่วงการทำงานของ process แรกๆให้ทำงานช้าลงไปด้วย ครั้งแรกที่ผมเจอปัญหาในลักษณะนี้ process ของการ mirror ที่ run ค้างอยู่ทำให้ load ของระบบสูงกว่า 100 โชคยังดีที่ load ที่สูงขึ้นเกิดจาก i/o ของการเขียน disk ซึ่งยังทำให้สามารถ secure shell เข้าไปได้ สามารถ run คำสั่ง ps auxw เพื่อตรวจสอบได้ ถึงแม้จะช้าอยู่มาก แต่ก็ทำให้ทราบว่าปัญหาเกิดจากอะไร และเอาข้อมูลนั้นมาแก้ไขปัญหาในภายหลังได้ สำหรับปัญหาแบบนี้ วิธีการแก้ไข ก็ไม่ได้ยากอะไร การทำงานของ mirror process ในครั้งหลังที่ถูก start ขึ้นมาด้วย cron ไม่ควรที่จะทำงานต่อ ถ้า process แรกที่ทำงานอยู่ ยังทำงานไม่เสร็จ ควรที่จะปล่อยให้ process แรกทำงานให้เสร็จเท่านั้นเอง ในแง่ของ shell script ก็สามารถทำได้ โดยการใช้ lock file ก่อนที่จะเริ่มต้นทำงาน ก็ตรวจสอบดูก่อนว่า มี lock file อยู่หรือเปล่า ถ้ามี ก็แสดงว่ายังมี process เดิมทำงานอยู่

InnoDB Storage Engine Data Recovery สำหรับ MySQL database

March 31, 2013 01:44

ปัญหาของการลืม password ของ root ของ MySQL ไม่ได้เป็นปัญหาเดียวที่ผมเจอ ในเรื่องของการใช้งาน MySQL Database Server ถึงแม้จะไม่บ่อยนัก แต่ก็บ่อยมากพอที่จะทำให้ ใน 2-3 ครั้งให้หลัง ผม “จำ” วิธีการแก้ปัญหาได้ โดยไม่ต้องพึ่งพา google อีกต่อไป ถ้าจะว่าไป ถ้าปัญหานี้ เกิดขึ้น “บ่อย” กว่าเดิมอีกซักหน่อย ผมก็คง “จำ” root password ได้ (เพราะต้องใช้บ่อยขึ้น) และส่งผลในทางกลับ ทำให้ ไม่ลืม root password และทำให้ปัญหานี้ไม่ใช่ปัญหาอีกต่อไป — ฟังดูย้อนแย้ง ชวนขยักขย่อน หรือเปล่าครับ 🙂 แต่ไม่ว่าอย่างไร … การลืม password ในระดับสร้างความหงุดหงิดรำคาญใจแค่นั้นเอง ความรู้สึกอย่างมากก็คือ “ลืมอีกแล้ว ต้องรีเซ็ทพาสเวิร์ดอีกรอบ งี่เง่าจริงๆ!” แต่มีปัญหาอีกอย่างที่ … ไม่ได้เกิดขึ้นบ่อย … นานๆเกิดที แต่พอเกิดขึ้นมาแล้ว ทำให้ระดับความเครียดของ sysadmin พุ่งขึ้นสูงอย่างฉับพลัน ปัญหาแบบที่ว่า เกิดขึ้น ในลักษณะนี้ ครับ นี่คือข้อความทีี่มีอยู่ในไฟล์ “/var/log/mysql/error.log” InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer… InnoDB: Doing recovery: scanned up to log sequence number 7 3581528990 InnoDB: Error: page 4 log sequence number 7 3581552218 InnoDB: is in the future! Current system log sequence number 7 3581528990. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: for more information. ก่อนที่จะมาถึงที่จุดนี้ อาการของตัว mysql server ก็คือว่า load ของ mysqld ตัว daemon ทำงานอยู่แกว่งอยู่ในช่วง 90-100% อยู่ตลอดเวลา หลังจาก boot เครื่องขึ้นมา และถึงแม้จะไม่มีการใช้งาน mysql server จาก process อื่นๆเลย (ผมทดสอบโดยการ shutdown ตัว web server ซึ่งเป็น client เพียงตัวเดียวที่ใช้งาน mysql server อยู่) ก็ไม่ได้ทำให้ load ของตัว mysqld ลดลง หลังจากลองตรวจสอบจาก system log ของระบบ

Script สำหรับการ reset mysql root’s password

March 30, 2013 02:59

สำหรับ admin ของ Linux Server โดยทั่วไปแล้ว มักจะหลีกไม่พ้นที่จะต้อง ติดตั้ง database server สักครั้งนึง เพราะว่า สำหรับ application โดยส่วนใหญ่แล้ว โดยเฉพาะ web application ในปัจจุบัน มักจะต้องการใช้ database server เป็น backend สำหรับการเก็บข้อมูล และบน Linux ส่วนใหญ่ก็จะหนีไม่พ้นการใช้งาน MySQL เป็น Server … เพราะเป็นตัวที่มีคนใช้กันมากที่สุด และรองรับโดยหลายๆ framework ของ Web App ทั้งหลาย แน่นอน ตอนที่ติดตั้งครั้งแรก ตัวซอฟต์แวร์ที่ใช้ในการติดตั้ง ก็ถาม root password ของ MySQL สำหรับการ กำหนดสิทธิในการใช้งาน สำหรับคนที่ใช้งาน database server มานานระดับหนึ่ง ก็จะรู้ว่า password ที่จะใช้สำหรับ root ของ MySQL นั้น ไม่จำเป็นจะต้องเป็นตัวเดียวกับ root password ของระบบ … และ ไม่ควรที่จะเป็นตัวเดียวกัน … สำหรับคนที่ไม่รู้ในเรื่องนี้ ก็มักจะต้อง “เรียนรู้” ด้วยความยากลำบากในทีหลัง … ผมรู้สิน่า ผม “จ่าย” ค่าเล่าเรียนเรื่องนี้ด้วยราคาที่ “แพง” พอสมควรเชียวล่ะ หลังจากที่รู้แล้วว่า มัน “จะต้อง” ไม่ใช่ password เดียวกันกับ password ที่สำคัญของระบบ ปัญหาที่จะตามมาก็คือว่า เราก็อาจจะตั้ง password ของ root ของ MySQL แบบง่ายๆ เช่น “1234”, “abcd” อะไรทำนองนี้ เพราะว่า ในแง่ของการให้บริการ MySQL server ก็มักจะให้บริการกับ “client” ท่อยู่บนเครื่องเดียวกัน ไม่ได้ให้บริการผ่าน network ไปให้เครื่องอื่นๆ หรือ ถ้าจำเป้นจะต้องให้บริการ ก้ให้บริการกับ server ที่อยู่ใน cluster เดียวกัน จะมีเฉพาะ admin ด้วยกันที่จะรู้ว่ามี mysql ให้บริการอยู่บนเครื่องนี้ แน่นอน ความคิดเช่นนี้ ก็มักจะนำบทเรียน “ราคาแพง” บทที่สอง เกี่ยวกับ root password ของ mysql มาให้ อีกเหมือนกัน และมันมักจะพ่วงมากับ “phpmyadmin” ที่จะทำให้ ตัว mysql server ซึ่งเคยเข้าใจว่า “ไม่สามารถเข้าถึงจาก server อื่นๆได้” กลับเข้าถึงได้ง่ายๆ ผ่าน “web” และเมื่อเจอกับ bot ที่โจมตีแบบอัตโนมัติ หายนะ … ก็มาเยือนได้ง่ายๆ เหมือนกัน นั่นก็จะเป็นบทเรียนราคาแพงอีกบทนึงเช่นกัน ข้อสรุปของผม หลังจากได้บทเรียนอย่างนั้นมาก็คือ password ของ root ไม่ว่าจะเป็นของระบบเอง หรือ จะเป็นของ database “จะต้อง” เป็นคนละตัวกัน _และ_ จะต้องมีระดับของความปลอดภัยสูงใกล้ๆกัน ได้ password ที่ secure มา … ก็ดี … แต่ปัญหาของ password ที่ secure ก็คือ จำยาก … สำหรับ root’s password ของระบบ ที่ยังมีการใช้งานค่อนข้างบ่อย ก็จะมีโอกาสที่จะลืมได้น้อยกว่า … วิธีการที่จะทำให้ ไม่ลืม และยังมี password ที่ secure ก็มีแน่ๆ แต่นั่นไม่ใช่สิ่งที่ผมอยากจะพูดถึงในบันทึกนี้ (อันที่จริงก็เขียนเอาไว้ที่อื่นแล้วด้วย) ที่จะมาแก้ปัญหาในบันทึกนี้ ก็คือ

เปลี่ยน uptime timestamp ในคำสั่ง dmesg ให้เป็น date/time timestamp

March 26, 2013 03:55

เคยใหมครับ เมื่อใช้คำสั่ง dmesg เพื่อที่จะดู kernel message แล้วสงสัยว่า เวลาที่แสดงในเครื่องหมาย square bracket ที่อยู่ด้านหน้าของ message น่ะมันเป็นเวลาเท่าไหร่กันแน่? อาจจะไม่บ่อยนัก แต่ผมก็เคยมีปัญหานั้น ถ้าใช้คำสั่ง dmesg บน command line เราอาจจะเห็น message ประมาณนี้ [ 10.738140] udev[228]: starting version 164 [ 12.840798] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9 [ 12.842168] PCI: setting IRQ 9 as level-triggered [ 12.843002] pci 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 9 (level, low) -> IRQ 9 [ 12.856454] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 12.911121] vboxguest: major 0, IRQ 9, I/O port d020, MMIO at 00000000f0400000 (size 0x400000) [ 12.912531] vboxguest: Successfully loaded version 3.2.10_OSE (interface 0x00010004) [ 13.165633] piix4_smbus 0000:00:07.0: SMBus base address uninitialized – upgrade BIOS or use force_addr=0xaddr [ 13.233473] parport_pc 00:05: reported by Plug and Play ACPI [ 13.314410] ACPI: AC Adapter [AC] (on-line) [ 13.318154] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [ 13.345820] ACPI: Power Button [PWRF] [ 13.376871] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input4 [ 13.420217] ACPI: Sleep Button [SLPF] [ 13.455000] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5 [ 15.017345] Intel ICH 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 5 (level, low) -> IRQ 5 [ 15.019308] Intel ICH 0000:00:05.0: setting latency timer to 64 [ 15.344130] intel8x0_measure_ac97_clock: measured 54439 usecs (10177 samples) [ 15.346177]