| Xinetd |
แต่ก่อนอื่นขอพูดถึงภาพรวมของการจัดการกับบริการ (service) ของระบบลีนุกซ์ก่อน กล่าวคือ ระบบปฏิบัติการลีนุกซ์ สามารถแบ่งการจัดการกับบริการต่างๆ ที่ให้บริการอยู่บนระบบได้เป็น 3 กลุ่ม ซึ่งได้แก่
1. บริการที่ถูก start โดย init โดยบริการดังกล่าวจะไม่ใช่บริการที่เกี่ยวข้องกับ TCP/IP ตัวอย่างเช่น การรับการเชื่อมต่อผ่านโมเด็มเข้าสู่ระบบหรือการจัดการกับระบบ X-window เป็นต้น ซึ่งคอนฟิกไฟล์ของ init อยู่ที่ /etc/inittab โดยสามารถใช้คำสั่ง #init q เพื่อการอ่านค่าการเปลี่ยนแปลงที่เกิดขึ้นในไฟล์ดังกล่าวได้
2. บริการที่ถูกควบคุมโดย System V Startup Scripts คือบริการที่ถูกควบคุมโดยสคริปต์ที่อยู่ภายใต้ /etc/rc.d/init.d/ (ประมวลผลภายใต้ run level ต่างๆ) ซึ่งชื่อของบริการ (service หรือ deamon) ส่วนใหญ่มักจะคล้ายกับชื่อของสคริปต์ที่ใช้ในการ start, stop หรือ restart ขณะที่ระบบถูก reboot และสคริปต์ดังกล่าวมักจะลงท้ายด้วยตัวอักษร “d”
3. บริการที่ถูกควบคุมโดย xinetd
Xinetd หรือ eXtended InterNET services daemon เป็นบริการที่ถูกพัฒนาจาก inetd
ซึ่งเดิมการทำงานของ inetd เดิมนั้นช่วยควบคุมการเชื่อมต่อของเครือข่ายที่มายังเครื่องคอมพิวเตอร์ที่ มีการบริการของ inetd ดังกล่าว โดยเริ่มจาก inetd จะถูก start ขึ้นมาเพื่อรอรับการร้องขอใช้บริการต่างๆ ที่อยู่ภายใต้การควบคุมของมันเมื่อระบบของคุณถูกเปิดเพื่อใช้งาน เมื่อมีการร้องขอบริการเข้ามายัง port ที่อยู่ภายใต้การควบคุมของ inetd แล้วละก็ inetd จะทำการเชื่อมต่อการร้องขอดังกล่าวเข้าสู่โปรแกรม tcpd โดยโปรแกรม tcpd จะคอยทำการตวรจสอบการร้องขอบริการ ดังกล่าวกับเงื่อนไขต่างๆ ที่ระบุไว้ใไฟล์ /etc/hosts.allow และ /etc/hosts.deny ถ้าการร้องขอดังกล่าวผ่านเงื่อนไขที่ระบุไว้ก็จะได้รับอนุญาตให้เข้าใช้ บริการของระบบ ซึ่งส่งผลให้บริการที่ถูกร้องขอถูก start ขึ้นเช่นบริการ telnet (port 23) เป็นต้น โดยกลไกการทำงานดังกล่าวถูกเรียกว่า tcp_wrapper ดังรูป
Xinetd มีการจัดเตรียมในส่วนของการควบคุมการเข้าถึงบริการเช่นเดียวกันกับ tcp_wrapper แต่เพิ่มความปลอดภัยให้มากขึ้นเพื่อป้องกันการบุกรุกระบบที่อาจเกิดขึ้นและ ลดความเสี่ยงของการโจมตีแบบ denial of services (Dos) อีกด้วย ขั้นตอนการทำงานของ xinetd ก็เช่นเดียวกับ inetd คือ แทนที่คุณจะต้อง start บริการ (services) ทุกบริการขึ้นมาเพื่อรองรับการเชื่อมต่อขอใช้บริการขณะระบบลีนุกซ์ของคุณถูก เปิดเพื่อ ใช้งาน xinetd จะถูก start ขึ้นมาแทนเพียงโปรเซสเดียวเพื่อรอรับการร้องขอใช้บริการต่างๆ ที่อยู่ภายใต้การควบคุมของมัน เมื่อมีการร้องขอใช้บริการดังกล่าว xinetd ค่อย start โปรเซสที่เกี่ยวข้องขึ้นมาเพื่อให้บริการ
ซึ่งบริการที่อยู่ภายใต้การควบคุมของ xinetd สามารถแบ่งออกได้เป็น 2 กลุ่มใหญ่ๆ ได้แก่
1. บริการกลุ่มที่ถูกเรียกว่า multithreaded ซึ่งบริการเหล่านี้จะถูก xinetd แตก (fork) server process ขึ้นมาใหม่เพื่อรองรับทุกการเชื่อมต่อที่เข้ามาขอใช้บริการ โดย server process ที่ถูกแตกออกมานั้นจะต้องคอยให้บริการการร้องขอนั้นๆ ตลอดการเชื่อมต่อ
2. บริการกลุ่มที่ถูกเรียกว่า single-threaded ซึ่งบริการ กลุ่มนี้ ตัว deamon ของบริการเองจะต้องมีหน้าที่ในการรับผิดชอบทุกการเชื่อมต่อขอใช้บริการเอง โดย xinetd จะหยุดการให้ความช่วยเหลือในการรับการร้องขอใหม่ๆ ให้กับบริการกลุ่มนี้จนกว่าตัว deamon ของบริการดังกล่าวจะตาย บริการที่จะอยู่ในกลุ่มนี้ส่วนใหญ่ คือ บริการที่มีการเชื่อมต่อแบบ datagram นั่นเอง
Note : - xinetd (xinetd-2.3.7-2.i386.rpm) ที่มากับ Redhat Linux ม8.0 จะถูกคอมไพล์มาพร้อมกับ libwrap ซึ่งทำให้ xinetd มีลำดับการทำงานคล้ายกับโปรแกรม inetd ที่กล่าวมาแล้วข้างต้น ทั้งยังได้คุณสมบัติเพิ่มเติมของ xinetd อีกด้วย
ลักษณะสำคัญของ Xinetd ได้แก่
1. การควบคุมการเข้าถึง
- มีการสร้างส่วนของการควบคุมการเข้าถึงเพื่อหยุดการเชื่อมต่อจากผู้ไม่ ประสงค์ดี
- สามารถคอมไพล์ให้รองรับการทำงานของ libwrap ที่ใช้ไฟล์ hosts.allow และ hosts.deny ซึ่งทำให้ xinetd มีประสิทธิภาพมากขึ้น
- จำกัดการเข้าใช้บริการโดยระบุช่วงเวลาของการเข้าถึงระหว่างวันได้
- คุณสามารถเจาะจง ip address ของเครื่องลูกข่ายที่ขอใช้บริการให้กับแต่ละบริการของระบบได้ โดยลักษณะการ ทำงานดังกล่าวทำให้แต่ละเครื่องลูกข่ายที่ขอใช้บริการจะได้รับบริการที่แตก ต่างกันออกไป
2. ป้องกันการโจมตีแบบ Denial of service (DoS)
- ด้วยความสามารถในการควบคุมการเข้าถึงแบบจำกัดจำนวนการเชื่อมต่อเข้าระบบ ทำให้ xinetd สามารถรับมือการโจมตีแบบที่เรียกว่า “port bombs” ได้เป็นอย่างดี
- ถ้าคุณสังเกตเห็นว่ามีโฮสต์ หนึ่งพยายามโจมตีบริการของระบบ คุณสามารถจำกัดการเชื่อมต่อที่เข้ามาอย่างต่อเนื่องจากโฮสต์ดังกล่าวได้
- คุณสามารถจำกัดขนาดของไฟล์ log ที่ถูกสร้างขึ้นจากการขอใช้บริการได้ เพราะฉะนั้นจะไม่ทำให้ระบบถูกโจมตีโดยการทำให้ดิสก์เต็มได้
Note : Denial of service (DOS) เป็นการโจมตีรูปแบบหนึ่งที่นับวันอัตราการโจมตีด้วยวิธีนี้ มีแต่จะเพิ่มสูงขึ้น โดยผู้บุกรุกจะพยายามทำให้ระบบเป้าหมายที่ต้องการจะโจมตีมี traffic เพิ่มสูงขึ้นอย่างมาก จนกระทั่งระบบไม่สามารถรับมือกับจำนวน traffic ที่มากมายขนาดนั้นได้ เป็นเหตุให้ไม่สามารถให้บริการต่างๆ ได้ตามปกติ
3. ขยายขีดความสามารถในการเก็บ log ของบริการ
- สามารถระบุระดับการเก็บ log ในโปรแกรม syslog สำหรับแต่ละบริการได้อย่างอิสระ
- แต่ถ้าคุณไม่ต้องการใช้โปรแกรม syslog ในการเก็บ log ของแต่ละบริการคุณก็สามารถเก็บ log ต่างๆ ลงไฟล์ที่ ต้องการ โดยไฟล์ log ของแต่ละบริการจะเป็นอิสระต่อกัน
- สามารถเก็บ log ของเวลาการเริ่มต้นและจบการเชื่อมต่อของใช้บริการของแต่ละเครื่องลูกข่ายได้ ซึ่งคุณสมบัติดังกล่าวทำให้เรารู้ว่าเครื่องลูกข่ายดังกล่าวขอใช้บริการเป็น ระยะเวลานานเท่าไร
- และสามารถเก็บข้อมูลเพิ่มเติมเกี่ยวกับการพยายามเชื่อมต่อขอบริการแต่ไม่ สามารถติดต่อได้
4. จำกัดโหลดการขอบริการจากคอมพิวเตอร์หรือโฮสต์เครื่องอื่นๆ ในระบบ
- คุณสมบัติการ redirect ของ xinetd ทำให้เรา สามารถ redirect การเชื่อมต่อผ่าน TCP ไปยังโฮสต์อื่นๆ และค่อนข้างมีประโยชน์ในกรณีของการ NAT (network address translation) เมื่อใช้ xinetd และคุณสมบัติการ redirect ในการ redirect บริการไปยังเครื่องอื่นๆ ได้
5. สนับสนุนการทำงานแบบ ipv6
6. เพิ่มในส่วนของการโต้ตอบระหว่างผู้ขอใช้บริการกับเครื่องที่ให้บริการ
- คุณสามารถแสดงแบนเนอร์แบบต่างๆ กันบนแต่ละเครื่องลูกข่ายที่เชื่อมต่อเข้ามาขอใช้บริการทั้งแบบที่ทำการ เชื่อมต่อได้สำเร็จ, เชื่อมต่อไม่สำเร็จ ซึ่งจะทำให้ผู้ขอใช้บริการเข้าใจถึงการเปลี่ยนแปลงที่เกิดขึ้นในระบบ รวมทั้งเข้าใจถึงปัญหาที่เกิดขึ้นขณะเข้าใช้บริการอีกด้วย
การ compile xinetd และการติดตั้ง
ใครที่ต้องการจะ compile xinetd สามารถดาวน์โหลด source code ได้จาก http://www.xinetd.org (สำหรับเวอร์ชันของ xinetd ขณะที่ผู้เขียนทำการเขียนบทความนี้อยู่นั้นเป็น เวอร์ชัน 2.3.11 ซึ่งออกมาช่วงสงกรานต์ที่ผ่านมานี้เอง) หลังจากที่เราดาวน์โหลด source code เรียบร้อยแล้ว เราก็จะเริ่มลงมือ compile เจ้า xinetd กันเลย
อันดับแรกให้ทำการแตก source code ที่ดาวน์โหลด มาซึ่งมักจะดาวน์โหลดมาเป็นไฟล์ .tar.gz การแตก source code นั้นให้ใช้คำสั่ง
$> tar xzpvf xinetd-2.3.11.tar.gz
$> cd xinetd-2.3.11
เมื่อเราทำการแตก source code เรียบร้อยแล้ว ขั้นตอนต่อไปก็เป็นการ compile โปรแกรม สำหรับการ compile xinetd นั้นไม่ค่อยซับซ้อน เหมือนกับการ compile โปรแกรมอื่นๆ ทั่วไป โดยเริ่มจาก
$> ./configuration ตามด้วย option
สำหรับ option ที่เราสามารถระบุได้ในช่วงของการ compile นั้นมีอยู่ด้วยกัน 3 option ได้แก่
- with-libwrap กำหนดไว้เพื่อบอกให้ xinetd นั้น สนับสนุนการทำงานของ tcp wrapper แต่การที่จะกำหนด option นี้ได้นั้นต้องแน่ใจก่อนว่า ที่เครื่องได้มีการลง tcp wrapper และ library ไว้ก่อนแล้ว
- with-loadavg สำหรับ option นี้จะอนุญาตให้ xinetd จัดการกับพารามิเตอร์ max_load ซึ่งมีผลให้ xinetd สามารถยกเลิกการทำงานของบาง service ที่ xinetd ดูแลอยู่ได้ ในกรณีที่เครื่องทำงานหนักเกินไป นอกจากนี้ยังมีส่วนช่วยป้องกัน ในเรื่องของการโจมตีแบบ DOS (Denial of Service) ที่เป็นสาเหตุหนึ่งให้เครื่องเซิร์ฟเวอร์ของเราไม่สามารถทำงานต่อไปได้
- with-inet6 สำหรับองค์กรที่มีการใช้งานระบบเครือข่ายด้วย ip เวอร์ชัน 6 การกำหนด option นี้เพิ่มเติมเข้าไป จะช่วยให้ xinetd สามารถรองรับการทำงานกับระบบดังกล่าวได้
เมื่อเราสั่ง configuration เรียบร้อยแล้วก็ให้รันคำสั่งต่อไปนี้เพื่อทำการติดตั้ง xinetd เข้าไปในระบบ
$> make
$> make install
การควบคุมการทำงานของ xinetd
เราสามารถควบคุมการทำงานของ xinetd ได้โดยการส่งสัญญาณ (signal) ต่างๆ ไปที่ process ของ xinetd เมื่อ xinetd ได้รับสัญญาณที่เราส่งไปแล้ว จะตรวจสอบสัญญาณที่ได้รับและทำงานตามสัญญาณที่เราส่งไปให้
สัญญาณ หรือ Signal ที่มักใช้ในการควบคุม xinetd นั้นมีดังนี้
- SIGUSR2 จะทำให้เกิด hard reconfiguration นั่นหมายความว่า xinetd จะทำการอ่านไฟล์ configuration เข้ามาใหม่ และสั่งให้ xinetd หยุดการทำงานชั่วคราว เป็นเหตุให้ service ต่างๆ ที่ xinetd นั้นดูแลอยู่ไม่สามารถใช้งานได้ หลังจากนั้นจึงค่อยสั่งให้ xinetd ทำงานอีกครั้ง
เรามักใช้ signal SIGUSR2 เพื่อทำการ reload configuration ของ xinetd
- SIGQUIT เป็นการสั่งให้ xinetd หยุดทำงาน
- SIGTERM สั่งให้ service ต่างๆ ที่อยู่ภายใต้การดูแลของ xinetd หยุดทำงานก่อน แล้วจึงค่อยสั่งให้ xinetd หยุดทำงาน
- SIGHUP เป็นการเก็บ (dump) ข้อมูลสถานะการ ทำงานของ xinetd โดยที่ข้อมูลของการทำงานจะถูกเก็บไว้ที่ไฟล์ /var/run/xinetd.dump
- SIGIOT ทำการตรวจสอบความถูกต้องของโครงสร้างข้อมูลที่ xinetd ต้องการใช้ เมื่อตรวจสอบเสร็จสิ้นลง xinetd จะส่งข้อความเพื่อบอกผลของการตรวจสอบว่าสำเร็จเรียบร้อยหรือไม่
วิธีในการส่ง สัญญาณให้กับ xinetd นั้นสามารถทำได้ด้วยคำสั่ง kill หรือ killall สำหรับการใช้คำสั่ง kill นั้นเราจะต้องรู้ค่า process ID ของ xinet เสียก่อน ส่วนคำสั่ง killall นั้นเราสามารถใช้คำสั่งกับชื่อโปรเซสได้โดยตรงเลย
ตัวอย่างการใช้คำสั่ง kill และ killall (สมมติว่า xinetd มี process ID เป็น 11544 )
$> kill -s SIGUSR2 11544
$> killall -s USR2 xinetd
การ configuration xinetd
ปกติไฟล์ configuration หลักของ xinetd จะอยู่ที่ ภายใต้พาธ /etc ในชื่อ xinetd.conf (/etc/xinetd.conf) รูป แบบและวิธีการ config xinetd นั้นไม่ถือว่ายากและสลับซับซ้อน แต่สำหรับคนที่เคยลองจับหรือว่าใช้งาน inetd (เป็นตัวต้นแบบของ xinetd) มาก่อนนั้น อาจจะไม่คุ้นเคยกับรูปแบบที่เปลี่ยนไป แต่ผู้เขียนเชื่อว่ารูปแบบ configuration ของ xinetd ก็ไม่ยากจนเกินไปที่จะเรียนรู้
การตั้งค่า (configuration) ของ xinetd จะแบ่งออกเป็น 2 ส่วนหลักๆ นั่นคือ
1. ส่วนของการตั้งค่าโดยรวม (defaults section) ของ xinetd (หรือไฟล์ /etc/xinetd.conf) มีรูปแบบดังนี้
defaults
{
attribute operator value(s)
...
}
ซึ่งค่าของทุก ๆ คุณสมบัติ (attribute) ในส่วนนี้จะมีผลกับทุกๆ บริการที่อยู่ภายใต้การควบคุมของ xinetd ตัวอย่างเช่น คุณสมบัติที่ชื่อว่า only_from จะมีผลลัพธ์คืออนุญาตให้เครื่องลูกข่ายที่มี ip address ตามที่ระบุต่อไปนี้เท่านั้นที่สามารถเชื่อมต่อเข้ามายังเครื่องเซิร์ฟเวอร์ เครื่องนี้ได้
only_from = 10.27.21.0/16 10.22.21.0/16
จากตัวอย่างส่งผลให้ทุกๆ บริการที่อยู่ภายใต้การควบคุมของ xinetd จะอนุญาตเฉพาะเครื่องลูกข่ายที่มี ip address ดังกล่าวเท่านั้นเข้าใช้บริการของตนเอง แต่อย่างไรก็ตามค่าโดยรวม (default) นี้สามารถถูกแก้ไขได้โดยส่วนของการตั้งค่าของแต่ละบริการเองหากมีการระบุ คุณสมบัติต่างๆ ในส่วนของการตั้งค่าดังกล่าว แต่หากไม่มีการระบุ บริการนั้นๆ ก็จะนำเอาค่าจากการตั้งค่าโดยรวมไปใช้นั่นเอง
ตัวอย่างไฟล์ /etc/xinetd.conf ( Redhat 7.3 )
defaults
{
instances = 60 #จำนวนโปรเซสสูงสุดที่จะให้บริการเดียวกัน ในช่วงเวลาเดียวกัน
log_type = SYSLOG authpriv #เก็บ log โดยใช้โปรแกรม syslog
log_on_success = HOST PID #log ที่เก็บขณะที่เริ่มการให้บริการได้สำเร็จ โดยให้เก็บรายละเอียดของ ip address ของเครื่องที่ขอเชื่อมต่อ และ process id ของการให้บริการนั้น
log_on_failure = HOST #log ที่เก็บเมื่อไม่สามารถเชื่อมต่อเพื่อให้บริการได้ โดยให้เก็บ ip address ของเครื่องที่ขอเชื่อมต่อครั้งนั้นๆ
cps = 25 30 #เมื่อมีการเชื่อมต่อขอใช้บริการเข้ามา 25 การเชื่อมต่อให้ทำการหยุดรับการเชื่อมต่อชั่วคราวเป็นเวลา 30 วินาที
only_from = localhost #อนุญาตให้เฉพาะเครื่องนี้ เท่านั้นที่ขอใช้บริการได้
}
includedir /etc/xinetd.d
Note : อย่างไรก็ตามการตั้งค่าโดยรวมของ xinetd แล้วค่อยเปลี่ยนแปลงค่าคอนฟิกของแต่ละบริการเองนั่นเป็นกระบวนการที่ค่อนข้างเสี่ยง เนื่องจากอาจทำให้เกิดช่องโหว่ของการโจมตีจากผู้ไม่ประสงค์ดี จึงควรใช้หลักการของการปฏิเสธการเชื่อมต่อจากเครื่องลูกข่ายทุกเครื่องก่อนในส่วนของการตั้งค่าโดยรวม และเปิดให้เข้าใช้บริการแต่ละบริการตามความจำเป็น
2. ส่วนของการตั้งค่าของแต่ละบริการ (service) โดยทั่วไปถูกกำหนดให้อยู่ภายใต้พาธ /etc/xinetd.d ซึ่งการตั้งค่าในส่วนนี้จะมีผลทำให้เกิดการเปลี่ยนแปลงการตั้งค่าโดยรวมที่ ถูกระบุมาแล้วในข้อ 1 โดยมีรูปแบบของการตั้งค่าของแต่ละบริการดังนี้
Service service_name
{
attribute operator value(s)
...
}
การตั้งค่าของแต่ละบริการนี้มีรูปแบบเหมือนกับไฟล์ /etc/xinetd.conf แต่ค่าดังกล่าวจะมีผลเฉพาะแต่ละบริการ เท่านั้น (แทนที่ service_name ด้วยชื่อบริการเช่น ftp, rlogin)
ตัวกระทำ (Operator) ที่กล่าวถึงมี 3 ชนิด คือ
- เครื่องหมาย “=” เพื่อระบุค่า (value) ให้กับ คุณสมบัติ (attribute) นั้นๆ
- เครื่องหมาย “+=” เพื่อเพิ่มค่าให้กับคุณสมบัตินั้นๆ โดยเพิ่มจากส่วนของการตั้งค่าโดยรวมในไฟล์ /etc/xinetd. conf
- เครื่องหมาย “-=” เพื่อลบค่าออกจากคุณสมบัตินั้นๆ โดยลบจากส่วนของการตั้งค่าโดยรวมในไฟล์ /etc/xinetd.conf
คุณสมบัติหรือ attribute ที่น่าสนใจและมักมีการใช้งานอยู่บ่อยๆ ในโปรแกรม xinetd ได้แก่
คุณสมบัติ ค่าที่ระบุได้ และความหมาย
flags เพื่อระบุคุณสมบัติเพิ่มเติมของแต่ละบริการ
IDONLY : ระบุว่าจะรับการเชื่อมต่อจากเครื่องลูกข่ายที่มี server id ตามที่ระบุเท่านั้น
NOLIBWRAP : เพื่อระบุว่าไม่ใช้ libwrap library ในการตรวจสอบการขอเข้าใช้บริการกับบริการดังกล่าว
log_type - ปกติ xinetd จะเลือกใช้โปรแกรม syslog เป็นโปรแกรม default ในการเก็บlog การใช้งานระบบโดยสามารถระบุรูปแบบดังนี้
log_type = syslog_facility [syslog_level]
โดยผลลัพธ์ของ log ที่ได้จะถูกส่งไปยังโปรแกรม syslog ตาม facility ที่ระบุโดย ค่าที่เป็นไปได้ ได้แก่
daemon,auth,authpriv, user, local0-7 และ syslog_level คือระดับความสำคัญของเหตุการณ์ที่เกิดขึ้น
ค่าที่ระบุได้ ได้แก่ emerg, alert, crit, err, warning, notice, info, debug
หากไม่มีการระบุ syslog_evel ไว้ log จะถูกเก็บในระดับ info
- แต่เราสามารถเปลี่ยนแปลงการเก็บ log ไปไว้ที่ file ได้ โดยกำหนดตามรูปแบบด้านล่างนี้
log_type = FILE [ชื่อไฟล์ที่ต้องการเก็บ] [max_size [absolute_max_file]
สำหรับพารามิเตอร์ max_size และ absolute_max_file ใช้กำหนดขนาดของ ไฟล์logเพื่อป้องกันฮาร์ดดิสก์เต็ม
max_file : ถ้าขนาดของไฟล์ log มีขนาดเท่ากับ หรือมากกว่าค่า max_file ที่เรากำหนดไว้ จะทำการส่งข้อความไปถึง
โปรแกรม syslog เพื่อเตือนว่าขนาดของไฟล์ใกล้ถึงขนาดที่เราได้กำหนดไว้แล้ว
absolute_max_file : ในกรณีที่ขนาดของไฟล์ log มีขนาดเท่ากับ หรือว่ามากกว่าค่า absolute_max_file xinetd
จะยกเลิกการเก็บ log ของบริการนั้นๆ
เช่น log_type = FILE /var/log/telnet.log 30000 40000
log_on_success ข้อมูล log ที่สามารถเก็บได้ขณะที่ระบบพร้อมให้บริการ (start), เครื่องลูกข่ายขอใช้บริการ หรือผู้ขอใช้บริการเข้าสู่ระบบ (login)
PID : process id ของบริการ
HOST : ip address ของเครื่องลูกข่ายที่ขอใช้บริการ
USERID : user id ของผู้ขอใช้บริการ
EXIT : เวลาที่ผู้ใช้ยกเลิกการใช้บริการ
DURATION : ช่วงเวลาของการขอใช้บริการ
log_on_failure ข้อมูล log ที่สามารถเก็บได้หากระบบไม่สามารถให้บริการ ทั้งสาเหตุที่เกิดจากทรัพยากรของระบบไม่เพียงพอ
หรือเครื่อง ลูกข่ายที่ขอใช้บริการไม่ผ่านเงื่อนไขของการขอเข้าใช้งาน
HOST,USERID เหมือนคุณสมบัติ log_on_success
ATTEMPT : รายละเอียดความพยายามของการขอเข้าใช้บริการ
RECORD : ข้อมูลทุกอย่างที่เป็นไปได้ของเครื่องลูกข่าย
no_access รายชื่อของเครื่องลูกข่ายที่ไม่อนุญาตให้เข้าใช้บริการ
only_from ราย ชื่อของเครื่องลูกข่ายที่มีสิทธิขอเข้าใช้บริการโดยสามารถระบุได้หลายรูปแบบ ได้แก่ แบบ ip address, ชื่อ
เครื่อง, network name (ตรวจสอบจากไฟล์ /etc/network) หรือแบบ domain name ก็ได้ หากไม่ระบุค่าจะถือว่า
ปฏิเสธ การให้เข้าใช้บริการสำหรับทุกเครื่องลูกข่าย (only_from =)
port ระบุพอร์ทที่เกี่ยวข้องกับบริการนั้นๆ และหากมีการระบุไว้ในไฟล์ /etc/services แล้ว พอร์ทที่ถูกระบุในทั้ง 2 ส่วนนี้จะ
ต้องสัมพันธ์กัน
protocol ระบุโปรโตคอลที่เกี่ยวข้องกับบริการ และจะต้องมีชื่อโปรโตคอลนั้นๆ ปรากฏในไฟล์ /etc/protocols
server ระบุไฟล์โปรแกรมของบริการนั้นๆ เช่น /usr/sbin/in.ftpd
server_args พารามิเตอร์หรือออปชันที่ต้องระบุให้กับคุณสมบัติ server เพื่อใช้ในการ start บริการ
socket_type สัมพันธ์กับโปรโตคอลกล่าวคือ หากระบุว่า stream จะสัมพันธ์กับ tcp/ip, ระบุว่า dgram สัมพันธ์กับ UDP เป็นต้น
type Xinetd สามารถควบคุมบริการได้ 3 ประเภท
1. RPC : สำหรับบริการที่ระบุไว้ในไฟล์ /etc/rpc (ยังอยู่ในขั้นของการพัฒนา)
2. INTERNAL : สำหรับบริการที่อยู่ภายใต้การควบคุมของ xinetd โดยตรง เช่น echo, time, daytime, chargen,
discard
3. UNLISED : สำหรับบริการที่ถูกระบุไม่อยู่ทั้งในไฟล์ /etc/services และไฟล์ /etc/rpc
cps ไว้สำหรับจำกัดจำนวนการเชื่อมต่อ โดยพารามิเตอร์ตัวแรกเพื่อระบุจำนวนการเชื่อมต่อที่สามารถรองรับได้ และ
พารามิเตอร์ตัวที่ 2 เพื่อระบุช่วงเวลาที่จะหยุดรับการเชื่อมต่อขอใช้บริการไว้ชั่วคราวก่อนที่จะ รับการเชื่อมต่ออีกครั้ง
หน่วย เป็นวินาที เช่น
cps = 30 60 คือ เมื่อมีการเชื่อมต่อขอใช้บริการเข้ามา 30 การเชื่อมต่อให้ทำการหยุดรับการเชื่อมต่อชั่วคราวเป็นเวลา
60 วินาที เป็นต้น
instances ระบุจำนวนโปรเซสสูงสุดที่จะให้บริการเดียวกัน ในช่วงเวลาเดียวกัน
max_load ระบุโหลดที่มากที่สุดที่แต่ละ 1 server process จะสามารถรองรับได้ หากมากกว่าที่ระบุไว้จะไม่รับการร้องขอบริการที่
เข้ามาใหม่
per_source ระบุจำนวนการ เชื่อมต่อขอใช้บริการที่มากที่สุดที่ยอมรับได้ของแต่ละบริการ จากเครื่องลูกข่าย (ip address) เดียวกัน
access_time ระบุช่วงเวลาของการให้บริการระหว่างวัน โดยมีรูปแบบ ชั่วโมง:นาที (เริ่มให้บริการ) - ชั่วโมง:นาที (หยุดให้บริการ)
access-time = 9:00-18:00 เพื่อให้สามารถเข้าใช้บริการได้ตั้งแต่เวลา 9 นาฬิกา ถึง 18 นาฬิกาของแต่ละวัน
Note : คุณสมบัติ log_type มีความเกี่ยวข้องกับโปรแกรม syslodเป็นอย่างมากจึงควรอย่างยิ่งที่ผู้ดูแลระบบจะเข้าใจการตั้งค่าและการทำงานของโปรแกรม syslog โดยสามารถศึกษาได้จากคำสั่ง man syslogd, man syslog.conf เพื่อทราบถึงค่า facility และค่า syslog_levelที่ควรระบุ
ตัวอย่างไฟล์ภายใต้พาธ /etc/xinetd.d ของบริการที่ชื่อว่า telnet คือไฟล์ /etc/xinetd.d/telnet ซึ่งมีรูปแบบดังต่อไปนี้
# default: on
# description: The telnet server serves telnet sessions; it uses
# unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_success += DURATION EXIT
log_on_failure += USERID RECORD
log_type = FILE /var/log/telnet
access_times = 7:00-12:30 13:30-21:00
only_from = 10.27.21.0
}
ตัวอย่างไฟล์ /var/log/telnet
03/4/25@01:11:13: START: telnet pid=3042 from=160.2.249.212
03/4/25@01:11:33: START: telnet pid=3044 from=160.2.249.212
03/4/25@01:12:47: START: telnet pid=3087 from=160.2.249.212
03/4/25@01:14:05: START: telnet pid=3106 from=160.2.249.212
03/4/25@01:14:23: START: telnet pid=3147 from=160.2.249.212
03/4/25@01:16:20: START: telnet pid=3207 from=160.2.249.212
03/4/25@01:16:47: START: telnet pid=3293 from=160.2.249.212
03/4/25@01:16:54: EXIT: telnet status=0 pid=3293 duration=7(sec)
03/4/25@02:14:40: START: telnet pid=3387 from=160.2.249.212
03/4/27@00:44:57: START: telnet pid=5533 from=160.2.249.212
03/4/27@00:51:36: START: telnet pid=5649 from=160.2.249.212
03/4/27@02:38:49: EXIT: telnet signal=9 pid=5649 duration=6433(sec)
03/4/27@02:38:49: EXIT: telnet signal=9 pid=5533 duration=6832(sec)
คุณสมบัติ (attribute) redirect ของ xinetd ที่ช่วยในการปรับเปลี่ยนการเชื่อมต่อ บริการไปยังคอมพิวเตอร์เครื่องอื่นๆ
Xinetd สามารถรองรับการทำงานในลักษณะของ transparent proxy โดยใช้คุณสมบัติที่เรียกว่า redirect หรือการปรับเปลี่ยนการเชื่อมต่อ ให้คุณสามารถส่งการร้องขอบริการไปยังโฮสต์เครื่องอื่น ในพอร์ทที่ต้องการได้ยกตัวอย่างเช่น
ไปยังเครื่อง pepsi ผ่านคูณ สมบัติ redirect
จากรูป เครื่องลูกข่ายร้องขอใช้บริการ telnet มายังเครื่อง cola ซึ่งเป็นที่ทราบกันว่าให้บริการ telnet และการบริการ telnet ดังกล่าวอยู่ภายใต้การควบคุมของโปรแกรม xinetd แต่การตั้งค่าของบริการ telnet (ไฟล์ /etc/xinetd.d/telnet) ได้ระบุให้เครื่องลูกข่ายทุกเครื่องที่ขอใช้บริการ telnet มายังเครื่อง cola ถูกปรับเปลี่ยน (redirect) ไปใช้บริการยังเครื่อง pepsi แทน ซึ่งเปรียบเสมือนว่าเครื่องลูกข่ายขอใช้บริการ telnet ที่เครื่อง cola แต่การประมวลผลการให้บริการ telnet นี้แท้จริงถูกควบคุมโดยเครื่อง pepsi นั่นเอง แต่หากสังเกตโดยใช้คำสั่ง
#netstat -a
และสังเกตคำว่า telnet ทั้งที่เครื่องลูกข่าย และเครื่อง cola เองจะเห็นว่าการเชื่อมต่อระหว่างทั้ง 2 เครื่องนี้ยังคงอยู่ตามหลักการของ transparent proxy นั่นเอง ตัวอย่างไฟล์ /etc/xinetd.d/telnet ที่ระบุคุณสมบัติ redirect คือ
คุณสมบัติ คำอธิบาย
disable = no ค่า no คือให้ xinetd ทำการ start deamon ของโปรแกรม telnet ขึ้นมาให้บริการได้หากมีการร้องขอ ค่า yes จะ
ให้ผลตรงกันข้ามคือ xinetd จะไม่ start โปรแกรม telnet ขึ้นมาให้เมื่อมีการร้องขอ
Note สามารถเปลี่ยนค่าคุณสมบัตินี้โดยใช้คำสั่ง
#chkconfig telnet on ส่งผลให้ disable = no หรือ
#chkcondif telnet off ส่งผลให้ disable = yes
user = root เพื่อระบุเจ้าของโปรเซส ในกรณีนี้คือ root
server = ไฟล์โปรแกรมที่จะต้องใช้เพื่อ start บริการขึ้นมาเมื่อมีการร้องขอ อยู่ที่
/usr/sbin/in.telnetd ไฟล์ /usr/sbin/in.telnetd /usr/sbin/in.telnetd
only_from = & nbsp; อนุญาตให้เครื่องลูกข่ายที่มี ip address อยู่ใน network 10.27.21.0 สามารถเข้าใช้บริการได้เท่านั้น
10.27.21.0
log_type = & nbsp; ให้เก็บเป็นไฟล์ /var/log/telnet แยกออกมาจากส่วนของโปรแกรม syslog (ซึ่งปกติโปรแกรม syslog จะเก็บ
FILE /var/log/telnet log ต่างๆ ไว้ที่ไฟล์ /var/log/messages)
log_on_success += ให้เก็บ log การเชื่อมต่อเพิ่มเติมในเรื่องของระยะเวลาการเชื่อมต่อ และรายละเอียดเมื่อออกจากบริการ ส่วน ip
DURATION EXIT address ของเครื่องที่ทำการเชื่อมต่อ และ process id ของการให้บริการ telnet ครั้งนั้นๆ ได้มาจากคุณสมบัติที่
ระบุไว้ ในไฟล์ /etc/xinetd.conf นั่นเอง
access_times = บริการ telnet จะเปิดให้เข้าใช้บริการเฉพาะช่วงเวลา 7:00-12:30 และ 13:00-21:00 ของวันเท่านั้น
7:00-12:30 13:30-21:00
#default: on
#description: The telnet server serves telnet sessions; it uses
#unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_success += USERID DURATION EXIT
log_on_failure += USERID RECORD
log_type = FILE /var/log/telnet
redirect = pepsi 23
}
ให้ผลลัพธ์คือ
>>telnet cola
Trying 192.168.1.1...
Connected to cola.
Escape character is ‘^]’.
Red Hat Linux release 7.2 (Enigma)
Kernel 2.4.7-10 on an i586
login:wrn
Password:
Last login: Sat May 3 17:58:13 from 192.168.1.2
[wrn@pepsi wrn]$
จะสังเกตเห็นได้ว่าในตอนแรกการเชื่อมต่อพยายามจะเชื่อมต่อกับเครื่อง cola แต่ผลลัพธ์ที่ได้คือเครื่องลูกข่ายได้รับบริการ telnet จากเครื่อง pepsi นั่นเอง
คุณสมบัติ (attribute) bind ของ xinetd ที่ช่วยในการกำหนดการเชื่อมต่อ
คุณสมบัติ ที่เรียกว่า bind ของ xinetd นี้ช่วยในการเชื่อมต่อหรือผูกบริการใดบริการหนึ่งเข้ากับ ip adress เฉพาะบนเครื่องที่ต้องการให้บริการ คุณสมบัตินี้จะมีประโยชน์ก็ต่อ เมื่อคอมพิวเตอร์เครื่องนั้นๆ มีอุปกรณ์เชื่อต่อระบบเครือข่าย (network interfaces) มากกว่า 2 อุปกรณ์ ตัวอย่างเช่น เครื่องคอมพิวเตอร์ที่เป็นทั้งส่วนหนึ่งของเครือข่ายภายในและเชื่อมต่อกับ เครือข่ายภายนอก นั่นเอง
กรณีตัวอย่างของการให้บริการที่จำเป็นต้องใช้คุณสมบัติ bind เช่น บริษัทที่ต้องการให้เครื่องคอมพิวเตอร์ของตนหนึ่งเครื่องให้บริการ ftp แก่ทั้งพนักงานภายในองค์กรและให้บริการ ftp แก่ลูกค้าภายนอกองค์กร แนวทางก็คือจะต้องระบุการให้บริการ ftp ที่แยกออกจากกัน 2 ส่วน คือบริการแรกรองรับการ ftp จากพนักงานภายในเท่านั้น และบริการที่2 คือบริการ ftp จากลูกค้าภายนอก ซึ่งโปรแกรม xinetd สามารถระบุและวิเคราะห์ความแตกต่างระหว่างบริการ ftp 2 ส่วนนี้โดยใช้คุณสมบัติ id เพื่อระบุบริการให้เจาะจงลงไป (หากคุณไม่ได้ระบุคุณสมบัติ id ให้กับบริการใดๆ ค่าของ id ที่จะถูกระบุโดยอัตโนมัติคือ ชื่อของบริการนั้นๆ และส่งผลให้ไม่สามารถใช้คุณสมบัติ bind ได้)
จากรูปแสดงการให้บริการ ftp ภายใต้การควบคุมของ xinetd ตามกรณีตัวอย่างที่กล่าวมาข้างต้นคือเครื่องserverที่ให้บริการ ftp ทั้งในส่วนของภายในผ่านอุปกรณ์เชื่อมต่อที่มี ip address = 192.168.1.1 และให้บริการ ftp แก่ลูกค้าภายนอกองค์กรผ่านอุปกรณ์เชื่อมต่อที่มี ip address = 77.66.55.44 โดยมีตัวอย่างไฟล์ /etc/xinetd.c/ftp คือ
service ftp
{
id = ftp-public
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
instances = 4
nice = 10
only_from = 0.0.0.0/0 # อนุญาตเครื่องลูกข่ายทุกเครื่องให้เข้ามาขอใช้บริการ
bind = 77.66.55.44 # ip address สำหรับการเชื่อมต่อจากภายนอกองค์กร
}
service ftp
{
id = ftp-internal
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24 #อนุญาตเฉพาะเครื่องลูกข่ายภายใน องค์กรเท่านั้น
bind = 192.168.1.1 #IP address สำหรับการเชื่อมต่อภายในองค์กร
}
ซึ่งการระบุคุณสมบัติ bind นี้ xinetd จะเรียกใช้โปรเซส ของบริการ (ftp-public,ftp-internal) โดยดูจากปลายทางที่เครื่องลูกข่ายต้องการติดต่อ และนี่คือตัวอย่างไฟล์ log ของบริการ ftp
03/4/17@16:47:46: START: ftp-public pid=26861 from=77.66.55.33
03/4/17@16:47:46: EXIT: ftp-public status=0 pid=26861
duration=30(sec)
03/4/17@16:48:19: START: ftp-internal pid=26864 from=192.168.1.2
03/4/17@16:48:19: EXIT: ftp-internal status=0 pid=26864 duration=15(sec)
ซึ่งเป็น log ที่ได้มาจากการใช้คำสั่ง #ftp 77.66.55.33 จากเครื่องลูกข่ายภายนอกองค์กรและจากคำสั่ง #ftp 192.168.1.1 จากเครื่อง 192.168.1.2 นั่นเอง
นี่เป็นเพียงส่วนหนึ่งของความสามารถของ xinetd เท่านั้นเพราะฉะนั้นหากคุณต้องการคุณสมบัติที่เหมาะสมกับระบบของคุณ อาจต้องทำการศึกษารายละเอียดเพิ่มเติมก่อนทำการเปลี่ยนแปลงใดๆ
Key Link :
http://www.linuxfocus.org/English/November2000/article175.shtml
http://www.xinetd.org/
http://www.redhat.com/
Thanks : www.opensource.co.th
ไม่มีความคิดเห็น:
แสดงความคิดเห็น