การตรวจสอบระบบความปลอดภัยของ Linux

จาก Research 2549, สารานุกรมฟรี

การตรวจสอบระบบความปลอดภัยของ Linux
แปลและเรียบเรียงจาก Lori Homsher & Tim Evans, "Linux Security Checklist"
โดย พ.ท.ปรัชญา เฉลิมวัฒน์ <<Back

สารบัญ 1 กล่าวนำ 2 รายการตรวจสอบความปลอดภัย - ส่วนที่ 1 2.1 ดิสก์สำหรับเริ่ม และ กู้ระบบ 2.2 การอุดช่องโหว่ (System Patches) 2.3 ปิดการให้บริการที่ไม่จำเป็น 2.3.1 ตรวจสอบ startup scripts 2.3.2 ตรวจสอบการเชื่อมต่อกับเครือข่าย 2.3.3 ตรวจ startup script ด้วยคำสั่ง chkconfig 2.3.4 ตรวจสอบ init.d สคริปต์ใน Ubuntu 2.4 ตรวจสอบไฟล์สำคัญที่เกี่ยวข้องกับความปลอดภัยของระบบ 2.5 นโยบายการควบคุมรหัสผ่าน 3 รายการตรวจสอบความปลอดภัย - ส่วนที่ 2 3.1 จำกัดการเข้าเป็น root ด้วยการใช้ SUDO 3.2 อนุญาตให้ root เท่านั้นที่จะเข้าถึง CRON ได้ 3.3 ข้อความเตือนผู้เข้าใช้งาน 3.4 Remote Access and SSH Basic Settings 3.5 Host-based Firewall Protection with iptables 4 รายการตรวจสอบความปลอดภัย - ส่วนที่ 3 4.1 Xinetd and inetd.conf 4.2 tcpwrappers 4.3 System Logging 4.4 Backups 4.5 Integrity-checking Software 5 รายการตรวจสอบความปลอดภัย - ส่วนที่ 4 5.1 Apache Security (all *nix) 5.2 Apache Mod_security module 5.3 Xwindow 5.4 LIDS (Linux Intrusion Detection System) 5.5 Selinux (Security Enhanced Linux) 6 รายการตรวจสอบความปลอดภัย - ส่วนที่ 5 6.1 Email Security 6.2 File Sharing 6.3 Encryption 6.4 Anti-Virus Protection 6.5 Bastille Linux 7 เอกสารอ้างอิง

กล่าวนำ

การดูแลระบบความปลอดภัยของระบบปฏิบัติการเป็นเรื่องซับซ้อน มีขั้นตอนในการปฏิบัติค่อนข้าง ยุ่งยาก
ทั้งนี้เนื่องจากระบบปฏิบัติการเปรียบเสมือนผู้ให้บริการการใช้งานทรัพยากรต่าง ๆ ของ
ระบบคอมพิวเตอร์ ดังนั้นจึงเกิดช่องโหว่ที่ทำให้ผู้บุกรุกสามารถเจาะระบบได้อยู่อย่างต่อเนื่อง
ถึงแม้ว่าช่องโหว่เก่า ๆ ที่ถูกค้นพบแล้วได้ถูกปิดไป ก็ยังมีโอกาสที่จะเกิดช่องโหว่ใหม่ขึ้นอีก
เนื่องจากมีการพัฒนาซอฟท์แวร์ที่ให้บริการเพิ่มขึ้นอยู่ตลอดเวลา

เอกสารนี้สรุปรายการตรวจสอบความปลอดภัยของระบบปฏิบัติการ Linux ซึ่งใช้เป็นเครื่องแม่ข่ายกัน
อย่างแพร่หลาย "ระบบปฏิบัติการ" ที่กล่าวถึงในเอกสารฉบับนี้หมายถึง Linux ยกเว้นว่าจะกล่าวระบุ
ถึงระบบปฏิบัติการนั้น ๆ โดยตรง

รายการตรวจสอบนี้สามารถใช้เป็นบรรทัดฐานในการสำรวจ/ปรับแก้ความปลอดภัยของระบบปฏิบัติการ
Linux หรือสามารถใช้เป็นคำแนะนำในการเพิ่มความเข้มแข็งให้กับระบบปฏิบัติการเมื่อติดตั้งระบบใหม่
อย่างไรก็ตาม (เนื่องจากมีระบบปฏิบัติการ Linux ที่หลากหลาย) ค่าการปรับแต่งสำหรับแต่ละ Linux จะ
ไม่ระบบไว้เฉพาะระบบใดระบบหนึ่ง รายละเอียดสำหรับแต่ละระบบปฏิบัติการให้ศึกษาเพิ่มเติมในเอกสาร
อ้างอิง โดยทั่วไปแล้วผู้พัฒนาระบบมักจะสนับสนุนเว็บไซต์ที่เกี่ยวข้องกับความปลอดภัยของระบบ
ตนเอง เช่น

• RedHat มีคำแนะนำเกี่ยวกับความปลอดภัยที่ http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/.
• Gentoo Linux มี Handbook สำหรับความปลอดภัยที่ http://www.gentoo.org/doc/en/security/index.xml
• Debian's มีคำแนะนำและเอกสารที่เกี่ยวข้องกับความปลอดภัยที่ http://www.debian.org/security/

หากท่านเกี่ยวข้องกับการดูแลระบบความปลอดภัยของระบบคอมพิวเตอร์ ผู้เขียนแนะนำให้
สมัครเข้ากลุ่มของเมลลิ่งลิสต์ หรือ RSS เพื่อให้ได้รับข่าวสารเกี่ยวกับการป้องกันระบบจาก
กลุ่มผู้ใช้อยู่ตลอดเวลา ตัวอย่าง เช่น http://security-focus.com/ และ http://www.sans.org

ในการเพิ่มความปลอดภัยให้กับระบบปฏิบัติการนั้นมีขั้นตอนในการปฏิบัติค่อนข้างยุ่งยากและ
สลับซับซ้อน การบริหารระบบปรับปรุงข้อมูล (patch management) และการเพิ่มความแข็งแรง
ให้กับระบบเป็นสิ่งสำคัญที่มิควรมองข้าม นอกจากนั้นผู้ดูแลระบบควรให้ความสนใจเป็นพิเศษ
ในเรื่อง นโยบายความปลอดภัย การบริหารความเปลี่ยนแปลง การตรวจสอบบันทึกของระบบ
วิธีการตรวจสอบระบบที่ดีต้องสอดคล้องกับนโยบายและขั้นตอนการทำงาน ทั้งนี้เพื่อดำรงรักษา
ความปลอดภัยของระบบปฏิบัติการ

เอกสารฉบับนี้นำเสนอขั้นตอนในการตรวจสอบความปลอดภัยของระบบ เพื่อลดความเสี่ยงต่อ
ระบบปฏิบัติการที่ติดตั้งใหม่ให้มีช่องโหว่ในการที่จะถูกโจมตีให้น้อยที่สุดเท่าที่จะสามารถทำได้
รายการตรวจสอบที่จะกล่าวถึงเป็นมาตรการที่ใช้ลดความเสี่ยงต่อการถูกโจมตีหรือเจาะระบบ

รายการตรวจสอบความปลอดภัย - ส่วนที่ 1

หากท่านเป็นเจ้าหน้าที่ดูแลระบบ หรือเป็นเจ้าของระบบระบบคอมพิวเตอร์ที่ต้องการเพ่ิมความ
ปลอดภัยให้กับระบบของท่านแล้ว ผู้เขียนแนะนำให้ปฏิบัติตามขั้นตอนการตรวจสอบความ
ปลอดภัยของระบบปฏิบัติการในทุกรายการที่จะกล่าวถึง (หมายเหตุ - รายการที่จะกล่าวถึง
เป็นเพียงส่วนหนึ่งของการตรวจสอบที่ผู้เขียนได้เลือกมาเฉพาะในส่วนที่เป็นพื้นฐานสำคัญ
ที่เกี่ยวข้องกับความปลอดภัยของระบบ

ดิสก์สำหรับเริ่ม และ กู้ระบบ

หลังจากติดตั้งระบบปฏิบัติการแล้ว หากเป็นการติดตั้งผ่านเครือข่าย แนะนำให้สร้างแผ่นบู๊ท
เพื่อใช้สำหรับการกู้ระบบ ในกรณีที่ระบบมีปัญหา การสร้างแผ่นบู๊ททำได้ด้วยการใช้คำสั่ง
mkbootdisk ซึ่งจะมีอยู่ในคำสั่งของระบบอยู่แล้ว การใช้งานต้องใส่ค่าตัวแปรให้เหมาะสม

 cd /boot
 mkbootdisk --device /dev/fd0 `uname -r`

หมายเหตุ - คำสั่ง uname -r จะคืนค่าเวอร์ชั่นของเคอร์เนิ่ลของระบบปฏิบัติการที่ใช้งานอยู่
นอกจากแผ่นบู๊ทแล้ว ควรสร้างแผ่นกู้่ระบบ หรือ rescue disk ซึ่งสามารถดาวน์โหลดได้จาก

• ftp://metalab.unc.edu/pub/Linux/system/recovery
• Tomsbtrt, http://www.toms.net/rb
• Knoppix, http://www.knoppix.org

ระบบคอมพิวเตอร์ที่มีซีดีรอมมักจะสามารถตั้งให้บู๊ทจากซีดีรอมได้ Knoppix เป็นระบบปฏิบัติ-
การที่รันบนซีดีรอม สามารถใช้บู๊ทระบบได้เช่นเดียวกับฟล็อปปี้ มีข้อดีคือบู๊ทขึ้นมาเป็นระบบ
ปฏิบัติการที่สมบูรณ์ สามารถใช้งานได้เลย และสามารถใช้เป็นเครื่องมือช่วยในการกู้ระบบได้
ข้อเสียของการรันบนแผ่นซีดี คือความช้า และความต้องการหน่วยความจำในการรันค่อนข้าง
มาก เพื่อใช้สำหรับทำ RAM disk อย่างไรก็ตามข้อดีของการรันระบบปฏิบัติการจากแผ่นซีดี
ก็คือ มีความปลอดภัยสูงเนื่องจากว่าระบบไม่สามารถเปลี่ยนแปลงไฟล์สำคัญที่อยู่บนซีดีรอมได้

การอุดช่องโหว่ (System Patches)

การจัดการระบบซอฟท์แวร์ของระบบปฏิบัติการ Linux อาจใช้ระบบจัดการซอฟท์แวร์
แพ็คเกจเหล่านี้

• rpm (RedHat Package Manager) ซึ่งใช้โดย RedHat, Mandrake, และ SuSe
• apt/dpkg (Debian Package Manager) ใช้ในระบบปฏิบัติการ Ubuntu, Debian
• YUM (Yellowdog Linux Manager) ใช้ในระบบปฏิบัติการ Yellowdog
• หรือ คอมไพล์ใหม่จากซอร์สโค้ด เช่นในระบบปฏิบัติการ Gentoo เป็นต้น

ซอฟท์แวร์แพ็คเกจสามารถติดตั้งเอง หรืออาจใช้ระบบการอัพเดทแบบอัตโนมัติซึ่งมี
ให้เลือกในซอฟท์แวร์สมัยใหม่ให้สามารถปรับปรุงเวอร์ชั่นใหม่ที่ได้รับการแก้ไขช่องโหว่
แล้ว ด้วยการดาวน์โหลดผ่านระบบเครือข่ายอินเทอร์เน็ต ในเซอร์ฟเวอร์ที่เป็น RedHat
สามารถใช้คำสั่ง up2date

 up2date

เพื่อทำการปรับปรุงระบบซอฟท์แวร์ให้ทันสมัย และมีการใช้งานไลบรารี่ที่เหมาะสม รวมถึง
ตรวจสอบความขึ้นต่อกัน (dependencies) ของซอฟท์แวร์และรายงานให้ทราบว่าควรปรับ
ระบบของซอฟท์แวร์ใดบ้าง ข้อมูลเพิ่มเติมสำหรับ (RHN) RedHat Network services ให้ดูที่
https://rhn.redhat.com/rhn/help/quickstart.jsp การให้บริการ RHN โดยทั่วไปแล้ว
จะให้ฟรีเป็นเวลา 90 วันหลังจากติดตั้งระบบ หลังจากนั้นแล้วผู้ใช้ต้องจ่ายค่าบริการ

อย่างไรก็ตามหากระบบปฏิบัติการที่ใช้งานอยู่ค่อนข้างเก่า หรือล้าสมัยทำให้ไม่สามารถ
ปรับปรุงซอฟท์แวร์ให้ทันสมัยได้ ให้สอบถามการให้บริการสำหรับระบบเช่นนี้ได้ที่เว็บไซต์
Fedora Legacy Project ที่ http://www.fedoralegacy.org/ ซึ่งมีการให้บริการแบบจำกัด
สำหรับรายละเอียดที่เกี่ยวข้องกับ rpm ให้ใช้คำสั่ง man ดูเอกสารเพิ่มเติม

 man rpm

นอกจากนั้นยังมีโครงการ The Linux Documentation Project ซึ่งได้รวบรวมบทความ
ที่เรียกว่า HOWTOs ซึ่งรวมถึงการปรับปรุง rpm ให้ทันสมัยได้ที่

• http://www.ibiblio.org/pub/Linux/docs/HOWTO/RPM-HOWTO

ในระบบปฏิบัติการที่พื้นฐานของแพ็คเกจ Debian สามารถใช้คำสั่ง apt-get update เพื่อทำ
การดาวน์โหลด patch หรือซอฟท์แวร์ที่ใหม่ล่าสุดจากเว็บไซต์กลางของผู้พัฒนาซอฟท์แวร์

 apt-get update

ใน Ubuntu หากไม่ได้เป็น root ให้รันด้วยคำสั่ง

 sudo apt-get update

โดยก่อนรันให้ตรวจสอบดูไฟล์ /etc/apt/sources.list ว่าเว็บไซต์ที่จะดาวน์โหลดนั้นมีความ
ถูกต้องหรือไม่ ตัวอย่างไฟล์ sources.list ของผู้เขียน

deb http://th.archive.ubuntu.com/ubuntu/ dapper main restricted
deb-src http://th.archive.ubuntu.com/ubuntu/ dapper main restricted
## Major bug fix updates produced after the final release of the
## distribution.
deb http://th.archive.ubuntu.com/ubuntu/ dapper-updates main restricted
deb-src http://th.archive.ubuntu.com/ubuntu/ dapper-updates main restricted
## Uncomment the following two lines to add software from the 'universe'
## repository.
## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## universe WILL NOT receive any review or updates from the Ubuntu security
## team.
# deb http://th.archive.ubuntu.com/ubuntu/ dapper universe
# deb-src http://th.archive.ubuntu.com/ubuntu/ dapper universe
## Uncomment the following two lines to add software from the 'backports'
## repository.
## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
####added by prachya
#deb http://th.archive.ubuntu.com/ubuntu/ dapper-backports main restricted universe multiverse
#deb-src http://th.archive.ubuntu.com/ubuntu/ dapper-backports main restricted universe multiverse
#deb http://archive.ubuntu.com/ubuntu dapper multiverse
#deb-src http://archive.ubuntu.com/ubuntu dapper multive
deb http://security.ubuntu.com/ubuntu dapper-security main restricted
deb-src http://security.ubuntu.com/ubuntu dapper-security main restricted
# deb http://security.ubuntu.com/ubuntu dapper-security universe
# deb-src http://security.ubuntu.com/ubuntu dapper-security universe
#deb http://www.debian-multimedia.org sarge main
#deb http://www.debian-multimedia.org stable main

ระบบที่ใช้แพ็คเกจ Debian จะทำการปรับปรุง dependency ให้โดยอัตโนมัติ (ในระบบ
rpm จะเพียงแค่รายงานปัญหา) สำหรับการใช้งานคำสั่ง apt ซึ่งใช้ในการดาวน์โหลด
ซอฟท์แวร์ของแพ็คเกจของ Debian ให้ดูเอกสารเพิ่มเติมได้ที่

• http://www.debian.org/doc/manuals/users-guide/ch-iraus.en.html

นอกจากนั้นยังมี mailing lists ที่จะคอยส่งข้อมูลเกี่ยวกับความปลอดภัยของระบบ เช่น
vulnerability notices สำหรับระบบปฏิบัติการต่าง ๆ รวมถึงระบบปฏิบัติการวินโดวส์

• http://thaicert.nectec.or.th/
• http://www.sans.org/newsletters/
• http://www.securityfocus.com/
• http://www.cert.org/

ปิดการให้บริการที่ไม่จำเป็น

การเสริมสร้างความแข็งแรงให้กับระบบปฏบัติการอย่างหนึ่งก็คือ การปิดการให้บริการที่ไม่
จำเป็นต่อการใช้งานของระบบเครือข่ายที่ใช้งานอยู่ โดยทั่วไปแล้ว (เพื่อความง่าย) ระบบ
จะติดตั้งซอฟท์แวร์และการให้บริการบางอย่างที่เป็นพื้นฐานของการใช้งานทั่วไป โดยการ
เลือกซอฟท์แวร์ที่จะติดตั้งมักจะเตรียมไว้ให้สำหรับเครื่องทั่วไป ไม่ได้ระบุหรือเจาะจงว่า
จะติดตั้งการให้บริการต่าง ๆ เป็นราย ๆ ซึ่งทำให้ส่วนมากแล้วจะทำการติดตั้งซอฟท์แวร์และ
การให้บริการที่เครื่องแม่ข่ายไม่จำเป็น

ตรวจสอบ startup scripts

ก่อนอื่นต้องตรวจสอบดูว่าในระบบมีโพรเซสอะไรรันอยู่ด้วยคำสั่ง ps -ef หรือ ps -ax

 ps –ax

ใน RedHat/FC/ES ตรวจสอบสคริปต์เริ่มต้นเมื่อเครื่องเปิด (startup scripts) ด้วยคำสั่ง ls

 ls -l  /etc/rc.d/rc3.d/S* 

หากระบบรันในกราฟฟิกโหมด (X windows) ให้ใช้คำสั่ง

 ls -l  /etc/rc.d/rc5.d/S* 

ใน Ubuntu/Debian สคริปต์จะอยู่ต่างที่กันเล็กน้อย

 ls  /etc/rc?.d

ตรวจสอบดู symbolic link ของสคริปต์ด้วยคำสั่ง

 ls -l  /etc/rc?.d

ซึ่งจะแสดงรายชื่อของไฟล์ทั้งหมด (ของผู้เขียนมีทั้งหมดประมาณ 298 ลิงค์) ให้ตรวจสอบดูว่า
มีสคริปต์ที่ไม่จำเป็นสำหรับการใช้งานของระบบที่กำลังติดตั้งอยู่ไม่ ให้ยกเลิกบริการเหล่านั้นด้วย
การลบลิงค์ที่เกี่ยวข้องออกไปจากระบบ หรือย้ายไปไว้ในไดเร็กทอรี่สำรองอื่น

ตรวจสอบการเชื่อมต่อกับเครือข่าย

ตรวจสอบการเชื่อมต่อกับระบบเครือข่ายด้วยคำสั่ง netstat

 netstat –a 

จะแสดงรายการทั้งหมดของพอร์ตที่ใช้งานในระบบทั้งหมด

prachya@fujitablet:~$ netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 localhost:54985         *:*                     LISTEN
tcp        0      0 localhost:mysql         *:*                     LISTEN
tcp        0      0 *:netbios-ssn           *:*                     LISTEN
tcp        0      0 localhost:ipp           *:*                     LISTEN
tcp        0      0 localhost:37500         *:*                     LISTEN
tcp        0      0 *:microsoft-ds          *:*                     LISTEN
tcp        0      0 localhost:54985         localhost:55025         ESTABLISHED
tcp        0      0 localhost:55025         localhost:54985         ESTABLISHED
tcp6       0      0 *:www                   *:*                     LISTEN
udp        0      0 10.134.40.23:netbios-ns *:*
udp        0      0 *:netbios-ns            *:*
udp        0      0 10.134.40.2:netbios-dgm *:*
udp        0      0 *:netbios-dgm           *:*
Active UNIX domain sockets (servers and established) 
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     STREAM     LISTENING     10254    /tmp/.gdm_socket
unix  2      [ ACC ]     STREAM     LISTENING     10298    /tmp/.X11-unix/X0

ตรวจสอบความจำเป็นในการใช้งานพอร์ตต่าง ๆ และยกเลิกการให้บริการในพอร์ตที่ไม่จำเป็น

ตรวจ startup script ด้วยคำสั่ง chkconfig

ในระบบปฏิบัติการบนพื้นฐานของ RedHat นั้นจะมีคำสั่ง chkconfig เพื่่อใช้ตรวจสอบการ
ติดตั้งซอฟท์แวร์แพ็คเกจที่จะถูกรันตอนเริ่มระบบ

 chkconfig –list 

หากต้องการปิดการให้บริการเช่น vsftpd ให้ใช้คำสั่ง chkconfig เช่นกัน

 chkconfig  vsftpd  off

เมื่อระบบรีบู๊ทการให้บริการของ vsftpd ก็จะไม่ถูกเรียกขึ้นมา หากโพรเซสของซอฟท์แวร์
นั้นยังรันอยู่ให้หยุดด้วยคำสั่ง service

 service  vsftpd  stop

ตรวจสอบ init.d สคริปต์ใน Ubuntu

ใน Ubuntu จะมีสคริปต์เริ่มต้นอยู่ในไดเร็กทอรี่ /etc/init.d ให้ตรวจสอบการเริ่มสคริปต์ที่ไม่
จำเป็นในไดเร็กทอรี่นี้ และยกเลิกด้วยการย้ายสคริปต์ไปไว้ที่อื่น ๆ

 ls  /etc/init.d

ตรวจสอบไฟล์สำคัญที่เกี่ยวข้องกับความปลอดภัยของระบบ

ไฟล์สำคัญที่เกี่ยวข้องกับความปลอดภัยของระบบปฏิบัติการได้แก่ fstab, passwd, group,
และไฟล์ shadow โดยที่ fstab จะเก็บรายการใช้ระบบไฟล์พาร์ติชั่น และดิสก์ ไฟล์ passwd
เก็บรายละเอียดของชื่อผู้ใช้งานระบบ ไฟล์ group เก็บรายการของกลุ่มผู้ใช้งานในระบบ และ
ไฟล์ shadow เก็บรหัสผ่านที่เข้ารหัสแล้วซึ่งไฟล์มีความสำคัญมาก ควรให้ root มีสิทธิในการ
ได้เพียงอย่างเดียวและผู้เดียว ให้ตรวจสอบดูสิทธิและการอนุญาตให้ใช้ไฟล์เหล่านี้เพื่อความ
ปลอดภัย โดยตรวจสอบว่า

• ไฟล์ /etc/fstab ให้มีชื่อผู้ใช้และกลุ่มเป็น root.root และสิทธิการใช้เป็น 0644 (-rw-r--r--)
• ไฟล์ /etc/passwd และ /etc/shadow และ /etc/group มีเจ้าของเป็น root
• ไฟล์ /etc/passwd และ /etc/group มีสิทธิการใช้งานเป็น rw-r--r-- (644)
• ไฟล์ /etc/shadow มีสิทธิการใช้งานให้ root อ่านได้อย่างเดียว r-------- (400)

prachya@fujitablet:~$ ls  -l  /etc/fstab /etc/passwd  /etc/group  /etc/shadow
-rw-r--r-- 1 root root    479 2006-08-06 07:24 /etc/fstab
-rw-r--r-- 1 root root    957 2006-11-10 10:51 /etc/group
-rw-r--r-- 1 root root   1465 2006-11-10 10:51 /etc/passwd
-rw-r----- 1 root shadow  970 2006-11-10 10:51 /etc/shadow

นโยบายการควบคุมรหัสผ่าน

ตรวจสอบดูว่าการกำหนดรหัสผ่านเริ่มต้นสำหรับผู้ใช้งานใหม่นั้นสอดคล้องกับนโยบายการรักษา
ความปลอดภัยขององค์กร ค่าปริยาย (defaults) เหล่านี้จะถูกเก็บไว้ที่ไฟล์ /etc/login.defs ซึ่ง
แนะนำให้ปรับแต่งค่าต่าง ๆ ดังนี้ (รายละเอียดเพิ่มเติมสามารถดูได้ที่ http://www.tin.org)

  PASS_MAX_DAYS 90
  PASS_MIN_DAYS 6
  PASS_MIN_LEN 14
  PASS_WARN_AGE 7

ซึ่งการกำหนดข้างต้นเป็นการตั้งค่าการควบคุมการใช้รหัสผ่าน เช่น อายุของรหัสผ่าน (เวลาที่
ต้องเปลี่ยนรหัสผ่าน), เวลาที่จะเริ่มใช้งานรหัสผ่านได้, ความยาวของรหัสผ่านอย่างน้อย และ
การเตือนให้เปลี่ยนรหัสผ่าน เป็นต้น นโยบายที่ดีควรกำหนดให้มีการเปลี่ยนรหัสผ่านเป็นห้วง ๆ
ทั้งนี้เพื่อเป็นการป้องกันไม่ให้มีการใช้รหัสผ่านโดยไม่ได้รับอนุญาต และหากผู้ใช้ไม่เข้าใช้งาน
ซึ่งเป็นนัยบอกว่าผู้ใช้นั้นไม่มีความจำเป็นต้องใช้งานรหัสผ่านก็จะหมดอายุ

รายการตรวจสอบความปลอดภัย - ส่วนที่ 2

จำกัดการเข้าเป็น root ด้วยการใช้ SUDO

การยอมให้ผู้ใช้งานทั่วไปเข้าเป็น root ง่าย ๆ เป็นการเสี่ยงต่อความปลอดภัยของระบบ คำสั่ง su
ทำให้ผู้ใช้เข้ามีสิทธิล็อกอินเป็น root ของระบบและสามารถรันคำสั่งใด ๆ ของ root ได้ทุกอย่าง
ควรใช้เปลี่ยนวิธีการเข้าเป็น root ด้วยโปรแกรม sudo เพื่ออนุญาตให้ผู้ใช้บางคนเท่านั้นที่มีสิทธิ
ในการรันคำสั่งเสมือนกับเป็น root ซึ่งจะยอมให้รันคำสั่งได้ทีละคำสั่งเท่านั้น จึงทำให้ระบบมีความ
ปลอดภัยยิ่งขึ้น ยกตัวอย่างเช่น หากต้องการแก้ไขไฟล์ /etc/passwd ด้วยคำสั่ง vi ให้ใช้ sudo

 sudo vi /etc/passwd 

เมื่อแก้ไขไฟล์เสร็จแล้วออกจากโปรแกรม vi ก็จะกลับคืนสู่เชลล์ของผู้ใช้ปกติต่อไป ในระบบของ
Ubuntu จะติดตั้งให้ใช้ sudo โดยอัตโนมัติ ส่วนในกลุ่มของ Redhat ให้ดูข้อมูลเพิ่มเติมได้ที่
เว็บไซต์ของ linuxhelp อย่างไรก็ตามเราสามารถ
เข้าเป็น root ได้โดยไม่ต้องใช้คำสั่ง sudo ทุกครั้งที่จะรันคำสั่งด้วยการใช้

 sudo   -i

ผู้ใช้ก็จะกลายเป็น root และสามารถรันคำสั่งได้โดยไม่ต้องมี sudo นำหน้า ถึงแม้จะมีความสะดวก
ในการใช้งานแต่ผู้เขียนไม่แนะนำให้ใช้วิธีนี้ เนื่องจากหากเกิดข้อผิดพลาด แล้วจะทำให้การกู้คืน
ระบบเป็นไปได้ยากกว่าการป้องกันไว้ด้วย sudo

อนุญาตให้ root เท่านั้นที่จะเข้าถึง CRON ได้

โปรแกรม cron เป็นโปรแกรมประเภท daemon ที่คอยเฝ้ารอการให้บริการจากคำขอของผู้ใช้
เพื่อกำหนดให้โปรแกรมรันในเวลาที่ต้องการ ถึงแม้ว่าจะเป็นความสะดวกแต่ก็เป็นการเพิ่มความ
เสี่ยงในการที่ยอมให้ผู้ใช้งานทั่วไปทำเช่นนั้นได้ คำสั่ง crontab ใช้สำหรับสร้างรายการการจัด
ตารางเวลาการรันโปรแกรม ในการเพ่ิมความปลอดภัยให้ระบบควรสร้างไฟล์ cron.deny และ
cron.allow เพื่อใช้ควบคุมการใช้งาน crontab คำสั่งต่อไปนี้จะกำหนดให้ผู้ใช้ root เท่านั้นที่จะ
สามารถใช้ crontab ได้

  cd /etc/
  /bin/rm -f cron.deny at.deny
  echo root >cron.allow
  echo root >at.allow
  /bin/chown root:root cron.allow at.allow
  /bin/chmod 400 cron.allow at.allow

ข้อความเตือนผู้เข้าใช้งาน

หากนโยบายการใช้งานให้มีการเตือนผู้ใช้งานด้วยข้อความ warning banner แล้ว เราสามารถ

policy requires a warning banner, you can easily create one by copying the appropriate banner message to the following files.

           /etc/motd
           /etc/issue
           /etc/issue.net

add 'GreetString=”Authorized Use Only”' to /etc/X11/xdm/kdmrc and make a similar change to gdm.conf Here is a sample banner message: “Authorized Use Only. Transactions may be monitored. By continuing past this point, you expressly consent to this monitoring.”

Remote Access and SSH Basic Settings

Telnet is not recommended for remote access. Secure Shell (SSH) provides encrypted telnet-like access and is considered a secure alternative to telnet. However, older versions of SSH have vulnerabilities and should not be used. To disable SSH version 1 and enhance the overall security of SSH, consider making the following changes to your sshd_config file:

   Protocol 2
   PermitRootLogin no
   PermitEmptyPasswords no
   Banner /etc/issue
   IgnoreRhosts yes
   RhostsAuthentication no
   RhostsRSAAuthentication no
   HostbasedAuthentication no
   LoginGraceTime 1m (or less – default is 2 minutes)
   SyslogFacility AUTH (provides logging under syslog AUTH)
   AllowUser [list of users allowed access]
   DenyUser [list of system accounts and others not allowed]
   MaxStartups 10 (or less – use 1/3 the total number of remote users)

Note: MaxStartups refers to the max number of simultaneous unauthenticated connections. This setting can be helpful against a brute- force script that performs forking. Some folks also suggest running ssh on an alternate port, although others consider this to be ‘security through obscurity’. Regardless of your opinion, it’s very easy to change the port that ssh runs on by simply changing the “Port” setting in the sshd_config file, then stopping and restarting ssh. Running ssh on an alternate port will help you avoid port scanners that are looking for open port 22 and the scripted brute-force attempts on this port. You can block such brute-force ssh attacks with a package like denyhosts (http://denyhosts.sourceforge.net/), which utilizes tcpwrappers (see below). Alternatively, use your iptables firewall (see below) to limit access by IP address or host/domain name. For additional ssh security, you can configure key forwarding. The following link covers the extra functionality of agent key forwarding within ssh: http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

Host-based Firewall Protection with iptables

Many versions of Linux now come with iptables automatically enabled and configured during installation. RedHat creates /etc/sysconfig/iptables, based on the services you answer as ‘allowed’ during installation. Here is a basic sample script, created for a server running ssh (port 22), smtp (port 25), squid proxy (port 3128) and samba (netbios port 137). The server’s IP is 192.168.1.2 and it is part of a class C network. In the example, we want to accept these services and block all others. If the requested service is not accepted by one of the ACCEPT lines, the packet falls through and is logged and rejected.

   # Firewall configuration written by redhat-config-securitylevel
   # Manual customization of this file is not recommended.
   *filter
   :INPUT ACCEPT [0:0]
   :FORWARD ACCEPT [0:0]
   :OUTPUT ACCEPT [0:0]
   :RH-Firewall-1-INPUT - [0:0]
   -A INPUT -j RH-Firewall-1-INPUT
   -A FORWARD -j RH-Firewall-1-INPUT
   -A RH-Firewall-1-INPUT -i lo -j ACCEPT
   -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
   -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
   -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
   -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
   -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --  dport 53 -j ACCEPT
   -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --  dport 53 -j ACCEPT
   -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --  dport 25 -j ACCEPT
   -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --  dport 22 -j ACCEPT
   -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --  dport 3128 -j ACCEPT
   -A RH-Firewall-1-INPUT          -s 192.168.1.0/24 -d 192.168.1.2 --dport  137 -j ACCEPT
   -A RH-Firewall-1-INPUT          -s   192.168.1.2 -d 192.168.1.255 -j ACCEPT
   -A RH-Firewall-1-INPUT          -d   255.255.255.255 -j DROP
   -A RH-Firewall-1-INPUT          -d   192.168.1.255 -j DROP
   -A RH-Firewall-1-INPUT          -j   LOG
   -A RH-Firewall-1-INPUT          -j   REJECT --reject-with icmp-host-prohibited
   COMMIT

รายการตรวจสอบความปลอดภัย - ส่วนที่ 3

Xinetd and inetd.conf

If running the older /etc/inetd.conf file, be sure to disable unnecessary services by removing them (or commenting them out) from the inetd.conf file. For example, to remove telnet access, remove the following line:

   telnet     stream     tcp       nowait     root   /usr/sbin/telnetd      telnetd  -a

On systems running scripts from the xinetd.d directory, disable the services by changing the script from ‘disable = no’ to ‘disable = yes’. A sample xinetd.d script and various ACL settings are included in the tcpwrappers section. You will need to send a HUP signal to the inetd process after modifying the configuration files (kill -HUP processID)

tcpwrappers

TCP Wrappers allows control of services based on hostname and IP addresses. Additionally this tool contains logging and use administration. Tcpwrappers is a daemon that positions itself between detailed inquiries and the requested service, and checks the requestor’s IP against the hosts.allow and hosts.deny files.

In the traditional inetd.conf file, you can run tcpwrappers by calling tcpd (the tcpwrappers daemon) as follows:

   # first comment out the original line:
   #telnet stream tcp                nowait root /usr/sbin/telnetd telnetd    –a
   # then replace it with the modified line:
   telnet stream tcp               nowait root          /usr/sbin/tcpd telnetd    -a

Standard Linuxes don't have tcpwrappers built into xinetd, since xinetd already includes logging and access control features. However, if you want to add this further control you can re-compile xinetd with libwrap support by passing ‘-- with-libwrap’ as an option to the configure script. When xinetd is compiled with libwrap support, all services can use the /etc/hosts.allow and /etc/hosts.deny access control. xinetd can also be configured to use tcpd in the traditional inetd style. This requires the use of the NAMEINARGS flag and the real daemon name must be passed in as server_args. Here is an example for using telnet with tcpd:

   service telnet
   {
             flags            = REUSE NAMEINARGS
             protocol         = tcp
             socket_type      = stream
             wait             = no
             user             = telnetd
             server           = /usr/sbin/tcpd
             server_args      = /usr/sbin/in.telnetd
   }

To use settings within xinetd scripts to control access by IP for specific services, simply change the appropriate xinetd scripts, for example:

   service imap
   {
          socket_type       =  stream
          protocol          =  tcp
          wait              =  no
          user              =  root
          only_from         =  198.72.5.0 localhost
          banner            =  /usr/local/etc/deny_banner
          server            =  /usr/local/sbin/imapd
   }

Here are some other helpful settings: To deny certain IPs or domains:

        no_access = 10.0.5.12 bad.domain.com

To specify limits on connections – total number of ssh connections:

        instances = 10

Maximum number of connections per IP address:

        per_source = 3

To specify allowed access times:

        access_times = 8:00-17:00

System Logging

All Linux systems support system logging, which is important for troubleshooting system and network problems, as well as possible security incidents. Syslog is the daemon that controls logging on Linux systems. Logging configuration is stored in /etc/syslog.conf. This file identifies the level of logging and the location of the log files. Log files should be owned by root user and group, so that they are not available to the casual user. It is recommended that log entries be logged to a centralized log server, preferably over ssh for data confidentiality. Centralized logging protects from deletion of log files and provides another layer in the event the log files are tampered with. This is easily accomplished as follows:

   # send to syslog server
       *.emerg;*.info;*.err                                 @hostname

For more information on syslog.conf settings, view the man page by typing

   ‘man syslog.conf’.

Next Generation syslog is more customizable than syslog and supports digital signatures to prevent log tampering. It is available at: http://freshmeat.net/projects/syslog-ng/

Auditing your log files: Regardless of the software used to create the log files, good security includes the ongoing review of log file entries. This can become very tedious if your only tool is to manually read the logs. Fortunately, there are some very good open- source packages to help:

Logwatch: comes standard with many Linux distributions. Configuration of logwatch is done in the /etc/log.d directory. The script logwatch.conf allows you to set defaults, such as the level of detail, the services to include, and the log file names. Reports can be sent directly to your email and include data such as: firewall rejects, ftp uploads/downloads, disk space usage, sendmail statistics, etc.

Swatch: is an active log file-monitoring tool. Swatch uses regular expressions to find lines of interest. Once swatch finds a line that matches a pattern, it takes an action, such as printing it to the screen, emailing it, or taking a user-defined action.

To use swatch to check logs normally, run:

       swatch --config-file=/etc/swatch.conf --examine=/var/log/messages

To use swatch as a constantly running service that scans lines of a log file as they come in, run:

       swatch --config-file=/etc/swatch.conf --tail-file=/var/log/messages

Don't forget email security when sending your log files via email, which flows in plain text from source to destination mailbox. You may want to encyrpt the logfiles with something like GnuPG before sending them. Visit: www.gnupg.org for more information.

There are dozens of other tools available to analyze and audit syslog messages. The important point to remember is to pick a tool and make sure someone is responsible for log file auditing on a regular basis.

Backups

   There are many non-commercial and commercial backup programs available
   for Linux. We’ll highlight the non-commercial tools here. A google search for
   ‘linux backup software’ should provide you with enough commercial options to
   choose from.
   tar, gzip, bzip2: these tools have been around a long time and they are still a
   viable option for many people. Almost any *nix system will contain tar and gzip,
   so they will rarely require special installation or configuration. However, backing
   up large amounts of data across a network may be slow using these tools.
   To backup a list of directories into a single tar archive, simply run the tar
   command to create the tarball, followed by the gzip command to compress it:
   tar -cvf archive-name.tar dir1 dir2 dir3....
   gzip -9 archive-name.tar
   You may prefer to use bzip2, which is a bit better then gzip at compressing text,
   but it is quite a bit slower.
   You can combine the tar and gzip actions in one command by using tar's -z
   option.
   Rsync: rsync is an ideal way to move data between servers. It is very efficient
   for maintaining large directory trees in synch (not real time), and is relatively
   easy to configure and secure. rsync does not encrypt the data however so you
   should use something like SSH or IPSec if the data is sensitive (SSH is easiest,
   simply use "-e ssh"). Rsync (by Martin Pool) is available at:
   http://freshmeat.net/projects/rsync/
   Amanda: is a client-server based network backup program with support for *nix
   and Windows (via samba). It is available from http://www.amanda.org
   dump: is written specifically for backups. It backs up the entire file system and
   allows multiple levels of backups. The corresponding ‘restore’ command allows
   for restore from a dump backup. For example, to backup /boot file system to
   backup.boot:
   dump 0zf backup.boot /boot
   See ‘man dump’ for a complete list of options.

Integrity-checking Software

   Integrity checking/assurance software monitors the reliability of critical files by
   checking them at regular intervals and notifying the system administrator of any
   changes. This type of software is very useful in identifying unauthorized
   changes to configuration files, log files, services, as well as identifying the
   presence of Trojans, rootkits, and other malicious code.
   There are several integrity-checking packages available. Most Linux distros
   come with a barebones version of a commercial package. Commercial Tripwire
   support is available (for a fee) and can include an excellent management
   console to provide central control for recreating your policy files and
   databases. Aide is an advanced Intrusion Detection system that aims to be a
   free replacement to Tripwire. Samhain is another open-source option.
   http://tripwire.org/
   http://sourceforge.net/projects/aide
   http://sourceforge.net/projects/samhain

รายการตรวจสอบความปลอดภัย - ส่วนที่ 4

Apache Security (all *nix)

   There are entire books dedicated to apache security. We will hit some of the
   high-level suggestions here. Detailed help can be found at
   http://httpd.apache.org/
   First, verify that your apache subdirectories are all owned by root and have a
   mod of 755:
   [user@host xinetd.d]$ ls -l /etc/apache
   drwxr-xr-x 7 root           root         4096 Aug 23 10:24 conf
   drwxr-xr-x 2 root           root         4096 Aug 27 08:44 logs
   (your Apache installation may be located at /usr/local/apache or
   elsewhere if you installed it yourself)
   [user@host xinetd.d]$ ls –l /usr/sbin/*http*
   -rwxr-xr-x 1 root root 259488 Aug 2 05:22 /usr/sbin/httpd
   -rwxr-xr-x 1 root root 270248 Aug 2 05:22
   /usr/sbin/httpd.worker
   Likewise, your httpd binary should be owned by root, with a mod of 511. You
   can create a web documents subdirectory outside the normal Apache filetree
   as your DocumentRoot (/var/www/html in RedHat), which is modifiable by other
   users -- since root never executes any files out of there, and shouldn't be
   creating files in there.
   Server side includes (SSI) create additional risks, since SSI-enabled files can
   execute any CGI script or program under the permissions of the user and group
   apache runs as (as configured in httpd.conf). To disable the ability to run scripts
   and programs from SSI pages, replace “Includes” with “IncludesNOEXEC” in
   the options directive. Users may still use <--#include virtual="..." --> to execute
   CGI scripts if these scripts are in directories designated by a ScriptAlias
   directive.
   Script Aliased CGI: is recommended over non-script aliased CGI. Limiting CGI
   to special directories gives the administrator control over which scripts can be
   run.
   System Settings:
   To prevent users from setting up .htaccess files that can override security
   features, change the server configuration file to include:
   <Directory />
            AllowOverride None
   </Directory>
   To prevent users from accessing the entire filesystem (starting with the root
   directory), add the following to your server configuration file:
   <Directory />
           Order Deny,Allow
           Deny from all
     </Directory>
   To provide access into individual directories, add the following:
     <Directory /usr/users/*/public_html>
           Order Deny,Allow
           Allow from all
     </Directory>
     <Directory /usr/local/httpd>
           Order Deny,Allow
           Allow from all
     </Directory>
   If you are using Apache 1.3 or above, apache recommends that you include the
   following line in your server configuration files:
   UserDir disabled root

Apache Mod_security module

   The mod_security module runs on most versions of Apache, but you will most
   likely be required to install it from source (check with your Linux distribution).
   You can download the latest source code from www.modsecurity.org and
   compile it using apxs or apxs2. Detailed instructions can be found in the
   ModSecurity User Guide or the source code’s INSTALL file.
   Mod_security allows you to enhance the overall security of your apache web
   server by providing additional configuration settings within your httpd.conf file.
   These settings allow you to filter/inspect all traffic, or filter/inspect non-static
   traffic only (DynamicOnly). You can then set the default action for matching
   requests – for example, displaying a standard error page. In addition, you can
   specify allowable ASCII values and set restrictions for file uploads.
   Mod_security also provides much more logging than the default for apache.
   More information can be found at www.modsecurity.org

Xwindow

   X window can be a large security risk considering the many exploits for the
   product and since its data flows unencrypted across networks. A good method
   of configuring access to X servers is to tunnel X window sessions through SSH
   (secure shell). This is referred to as X11 forwarding. SSH provides the
   advantage of adding encryption to tunneled X sessions. A document from
   Stanford University provides a security check to test existing X servers and
   describes the steps involved to connect to an X server via SSH:
   http://www.stanford.edu/services/securecomputing/x-window/

LIDS (Linux Intrusion Detection System)

   LIDS is an enhancement for the Linux kernel written by Xie Huagang and
   Philippe Biondi. It implements several security features that are not in the Linux
   kernel natively. Some of these include: mandatory access controls (MAC), a
   port scan detector, file protection (even from root), and process protection.
   LIDS implements access control lists (ACLs) that will help prevent even those
   with access to the root account from wreaking havoc on a system. These ACLs
   allow LIDS to protect files as well as processes.
   For more information on LIDS: http://www.lids.org/

Selinux (Security Enhanced Linux)

   Developed by the U.S. National Security Agency (NSA), Security-enhanced
   Linux is a research prototype of the Linux® kernel and a number of utilities with
   enhanced security functionality designed simply to demonstrate the value of
   mandatory access controls to the Linux community and how such controls
   could be added to Linux.
   The Security-enhanced Linux kernel enforces mandatory access control
   policies that confine user programs and system servers to the minimum amount
   of privilege they require to do their jobs. When confined in this way, the ability
   of these user programs and system daemons to cause harm when
   compromised (via buffer overflows or misconfigurations, for example) is
   reduced or eliminated. This confinement mechanism operates independently of
   the traditional Linux access control mechanisms. It has no concept of a "root"
   super-user, and does not share the well-known shortcomings of the traditional
   Linux security mechanisms (such as a dependence on setuid/setgid binaries).
   Implementing SE Linux can have unexpected effects on a system, and you
   may find standard daemons won’t run properly, or at all, or logfiles may not be
   writable, or other similar effects that require detailed configuration of SE Linux
   Currently, RedHat Enterprise Linux Version 4 includes an implementation of SE
   Linux.
   For more information on SE Linux: http://www.nsa.gov/selinuX/

รายการตรวจสอบความปลอดภัย - ส่วนที่ 5

Email Security

   Many sys-admins disable the sendmail utility on user workstations, and
   centralize its service on a main mailserver machine. Even in this situation,
   there’s more you can do to increase its security.
   For sendmail, follow the recommended security settings for secure installation:
   http://www.sendmail.org/security/secure-install.html. It is possible to configure
   sendmail to launch when needed, rather than run it as a listening daemon on
   port 25.
   Postfix is a good alternative to sendmail. Information is available at:
   http://www.postfix.org/

File Sharing

   There are many methods of file sharing among Linux systems. Opening up a
   system for file sharing may not be acceptable within your organizational policy.
   We provide information here for those who require this type of access.
   For information on NFS security (for sharing *nix-to-*nix), see:
   http://www.linuxsecurity.com/content/view/117705/49/
   Samba is a software package that offers file sharing between Linux and
   Windows systems. It can be configured to use encrypted password access,
   restriction by user and/or IP address, and file-level permissions can be set.
   Samba is available at: www.samba.org.
   A good article describing the various Samba security modes is available at:
   http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/s1-
   samba-security-modes.html

Encryption

   If the system will be storing confidential data and you need to minimize the risk
   of data exposure, encryption may be an acceptable solution.
   Sourceforge has a web page that attempts to provide a disk encryption
   HOWTO for Linux users. It is available here:
   http://encryptionhowto.sourceforge.net/Encryption-HOWTO.html
   Depending on your needs, openPGP and/or GnuPG may be appropriate.
   These tools will allow you to encrypt emails and attachments, as well as files
   stored on disk. GnuPG is available at: www.gnupg.org and OpenPGP can be
   found at: www.openpgp.org.

Anti-Virus Protection

   There are several anti-virus options available for Linux users and the list
   continues to grow. Here are a few:
   Clamav: www.clamav.net
   f-prot: www.f-prot.com/products/corporate_users/unix/
   Vexira: www.centralcommand.com/linux_server.html

Bastille Linux

   A hardening program for RedHat, SUSE, Debian, Gentoo, and Mandrake
   distributions, Bastille Linux attempts to lock down a Linux server. It walks the
   user through a series of questions and builds a policy based on the answers.
   Bastille Linux was conceived by a group of SANS conference attendees and is
   available at: http://www.bastille-linux.org/

เอกสารอ้างอิง

• Documentation resources
  • Debian Security Information, http://www.debian.org/security/
  • Ibiblio Linux Archive, http://www.ibiblio.org/pub/Linux/
  • Encryption HOWTO. http://encryptionhowto.sourceforge.net/Encryption-HOWTO.html
  • Linux Documentation Project, http://tldp.org/
  • LinuxHelp.net, http://www.linuxhelp.net/guides/
  • Linux Security general information. http://www.linuxsecurity.com/
  • Apache Server Project. http://httpd.apache.org/docs/1.3/misc/security_tips.html
• Friedl, Steve (February 22, 2006). An Illustrated Guide to SSH Agent Forwarding. Retrieved August, 2006 from http://www.unixwiz.net/techtips/ssh-agent-forwarding.html
• Holbrook, John (2004). Step by step installation of a secure Linux web, DNS and mail server. Retrieved August, 2006 from http://www.sans.org/reading_room/whitepapers/linux/1372.php
• McCarty, Bill. (2003). Red Hat Linux Firewalls. RedHat Press.
• Nielsen, Kim (2006). Gentoo Security Handbook. Retrieved August, 2006 from http://www.gentoo.org/doc/en/security/security-handbook.xml
• Stanford University (2004). X Window Security. Retrieved August, 2006 from http://www.stanford.edu/services/securecomputing/x-window/
• Wainwright, Peter. (1999). Professional Apache. Wrox Press.
• RedHat (2002). RedHat Security Guide. Retrieved August, 2006 from: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/
• RedHat (2005). RedHat Enterprise Linux 4 Reference Guide Retrieved August, 2006 from: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/index.html
• Rosenthal, Chip & Haugh, Julianne Frances. Online man pages for login.defs. Retrieved August, 2006 from

http://www.tin.org/bin/man.cgi?section=5&topic=login.defs

• Ziegler, Robert. (2002). Linux Firewalls. New Riders Publishing.