SSH Dictionary Attacks (Brute Force) Protection!

หลาย ๆ คนในที่นี้ ที่ต้องดูแลเครื่อง server และการ remote เข้าไปควบคุมเครื่อง ผ่านทาง Secure Shell (SSH) เป็นเรื่องที่สร้างความสุขให้แก่เราอย่างมาก เนื่องจากไม่ต้องเข้าไปดูหน้าเครื่องก็ได้ แต่ไม่ใช่เราเพียงผู้เดียวที่อยากเข้าไปใช้งาน ผู้ไม่ประสงค์ดี ก็อยากเข้าไปใช้เหมือนกัน โดยความพยายามที่จะเดาชื่อ username และ password (Dictionary Attacks - Brute Force) แต่โชคยังดีที่ server ส่วนใหญ่ที่ดูแลอยู่ มี user ไม่มาก แถม password ก็ไม่ต้องห่วงให้เดาก็ต้องเดานานมาก ๆ หากอยากตรวจสอบความยากง่ายของ password ที่ใช้อยู่ สามารถทดสอบได้ที่ http://www.securitystats.com/tools/password.php

คำถาม ที่ตามมาคือ ก็ password ก็ยากมาก ๆ แล้วนี่ ทำไมต้องกังวลอีก .....

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

มีโปรแกรมหลาย ๆ ตัวที่ทำหน้าที่ตรวจสอบ และปิดกั้น (block) การเข้ามาของผู้ไม่ประสงค์ดี แต่ด้วยการที่เราเป็นสาวก Debian ต้องมองหาอะไรที่ง่ายต่อชีวิต และทรัพย์สินก่อนเป็นอันดับแรก .... และก็เจอ ....

Fail2Ban

ชื่อก็บอกยี่ห้ออยู่แล้วว่า "ผิดมา ตู แบน" เป็นโปรแกรมที่มีอยู่ใน Debian repository (ทั้งใน etch, lenny และ sid แต่เวอร์ชันอาจจะต่างกัน เพราะต่างกรรม ต่างวาระ) การติดตั้งก็แสนจะสะดวก ตามสไตล์ Debian

# aptitude install fail2ban

ติดตั้งเสร็จแล้วครับ เท่านี้ก็ใช้งานได้แล้ว :P ...

คำถาม อ้าวไม่ต้องตั้งค่าอะไรเลยเหรอ....

คำตอบ ไม่ต้องก็ใช้งานได้แล้วครับ แต่จะให้ดีก็สำรวจกันหน่อยดีกว่า ว่ามีอะไรให้เราตั้งได้บ้าง

เข้าไปดูการตั้งค่ากันต่อละกันครับ

/etc/fail2ban/jail.conf เป็นไฟล์ config ที่มากับระบบ หากต้องการแก้ไข

# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

นี่คือข้อดีที่ Debian ทำให้ เนื่องจากหากมีการ update ในอนาคต config อาจถูกเปลี่ยนโดย maintainer ได้ เราก็แก้ที่ local จะได้ไม่ไปยุ่งยากกับ maintainer เขาครับ

# vi /etc/fail2ban/jail.local
...
[DEFAULT]
ignoreip = 127.0.0.1  # เป็น ip ที่จะไม่มีการ Ban โดยเด็ดขาด
bantime = 1440        # เป็นเวลาที่จะ Ban IP ครับ ค่าเริ่มต้น 600 วินาที = 10 นาที
                      # น้อยไปก็เปลี่ยนได้ครับ 1440 วินาที = 1 วัน
                      # หรือ -1 สำหรับการ Ban IP ตลอดไป จนกว่าจะ Reboot
maxretry = 3          # ให้ผู้ไม่ประสงค์ดี หรือแม้แต่เราเอง ลองได้กี่ครั้ง
...
[ssh-ddos]
enabled = true       # ผมเปลี่ยนจาก false เป็น true เพื่อเพิ่มการตรวจสอบ SSH DoS
port     = ssh, sftp
filter     = sshd-ddos
...

แก้ไขเสร็จ สั่งเริ่ม Service ใหม่

# /etc/init.d/fail2ban restart

ผลคือ

# cat /var/log/fail2ban.log
...
2007-09-17 18:33:15,860 fail2ban.actions: WARNING [ssh] Ban 125.24.142.28
2007-09-17 18:34:25,008 fail2ban.actions: WARNING [ssh] Ban 60.191.41.108
...

ความสามารถของ fail2ban ยังไม่หมดแค่การตรวจสอบ และปิดกั้นสำหรับ SSH เท่านั้น ยังมีอีกหลาย Service ที่ fail2ban สามารถเฝ้ายามให้ได้ ไม่ว่าจะเป็น apache, vsftpd, proftpd, postfix, couriersmtp, named (DNS) เป็นต้น

หลังจากวันนี้ไป... ใครจะมาโจมตีก็ทำได้ยากซักหน่อยละครับผม :)

Comments

แล้วโปรแกรมจะมาอ่าน config ไฟล์ .local แทนไฟล์ .conf หรืออ่านทั้งสองตัวครับ
แล้ววิธีการนี้ใช้ได้กับทุกโปรแกรมหรือเปล่าครับ

>> แล้วโปรแกรมจะมาอ่าน config ไฟล์ .local แทนไฟล์ .conf หรืออ่านทั้งสองตัวครับ
สำหรับ .local จะเป็นการ Override ครับ คือ เมื่อระบบเจอไฟล์ .local จะใช้ .local ไม่สนใจ .conf ครับ

>> แล้ววิธีการนี้ใช้ได้กับทุกโปรแกรมหรือเปล่าครับ
ขึ้นอยู่กับแต่ละโปรแกรม แต่โดยส่วนใหญ่ตาม policy ของ debian จะเป็นแบบนี้
___
Neutron: Linux Addict!

มีอีกอันที่น่าสนใจครับ ใช้ PAM นี่แหล่ะ

http://www.ducea.com/2006/06/29/using-pam-to-block-brute-force-attacks/

เห็นเธออยู่กับคนอื่นแล้วมีความสุข ดีกว่าเห็นเธอทุกข์เมื่ออยู่กับฉัน

เท่าที่อ่าน และตาม BTS (Debian Bug Tracking System) ไป (#333081) เป็น ITP (Intent To Package) แต่ปรากฏว่าไม่มีการเคลื่อนไหว ตั้งแต่ปีที่แล้ว และไม่มีการปิด Bug ตรวจสอบใน aptitude ก็ไม่ปรากฏ libpam-abl

เลยเป็นที่น่าเสียดายที่ไม่สามารถทดสอบได้สะดวกนัก หากใครมีเวลาทดสอบ ช่วยแจ้งผลการทดสอบด้วย ว่าดีร้ายเช่นไร
ขอบคุณครับ
___
Neutron: Linux Addict!

ผมมองว่าถ้า Hacker จะทำการ Hack จริงๆ นี่ก็ค่อนข้างน่ากลัวนะครับ เพราะว่าเค้าใช้วิธีเปลี่ยน Proxy ไปเรื่อยๆ ใน Brute force ซึ่งทำให้ยากต่อการ Blocked นะครับ เพราะว่าบางที policy ที่เราออกแบบไว้อาจจะดักไม่ได้ก็ได้นะครับ

ผมก็เห็นด้วยในข้อนี้ แต่อย่างน้อยการป้องกันในรูปแบบนี้ก็ช่วยได้ในระดับหนึ่ง ดีกว่าไม่ป้องกันเลย ส่วนกรณีอื่น ๆ คงต้องหามาตรการป้องกัน เพิ่มเติม ตามความเหมาะสมครับผม :)
___
Neutron: Linux Addict!

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้