Vision of the Machine

7/26/2018

Getting start with NanoPi DUO

NanoPi DUO

Hardware Spec

CPU: Allwinner H2+, Quad-core Cortex-A7
DDR3 RAM: 256MB/512MB
Connectivity: 10/100M Ethernet
Wifi：XR819
USB Host: 2.54mm pin x2, exposed in 2.54mm pitch pin header
MicroSD Slot x 1
MicroUSB: OTG and power input
Debug Serial Interface: exposed in 2.54mm pitch pin header
Audio input/output Interface: exposed in 2.54mm pitch pin header
GPIO: 2.54mm spacing 12pin x2. It includes UART, SPI, I2C, IO etc
PCB Dimension: 25.4 x 50mm
Power Supply: DC 5V/2A
Temperature measuring range: -40℃ to 80℃
OS/Software: U-boot，Linux Kernel 4.11.2 (mainline) , Ubuntu 16.04.2 LTS (Xenial)

Link : Product Page
Link : WiKi Page

1) Download Ubuntu Linux image here.
2) Flash image to SD card using Win32DiskImager
3) Connect serial-2-usb @115,200bps 8/n/1
4) Insert SD card & power to NanoPi-Duo
5) Configure device
sudo npi-config
6) Start WiFi

sudo nmcli r wifi on

Scan Surrounding WiFi Sources

sudo nmcli dev wifi

Connect to a WiFi Source

sudo nmcli dev wifi connect "SSID" password "PASSWORD" ifname wlan0

7) Update & Upgrade
sudo apt-get update
sudo apt-get upgrade
8) Install camera utilities
sudo apt-get install v4l-utils

9/27/2016

Getting start with NanoPi-M1 PART-II

SETTING WiFi ON NanoPi-M1

I'm using EDUP Nano 802.11N model EP-N8508GS which works well on my Raspberry Pi and hopefully it should support NanoPi-M1 as well.
Without power down NanoPi, just plug-in the dongle and list the USB device,

lsusb

Great! I got the return

Bus 003 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Trying to check network configuration using a simple command

ifconfig

But unfortunately got an error in return...

-bash: ifconfig: command not found

Hmmm.... whats'up! something differ from Pi!!!
Let's try again with root privilege,

sudo ifconfig

[sudo] password for fa: (enter root password)

Success!!! I got the network configuration!
Next, open the network configuration file.

sudo nano /etc/network/interfaces

Add the following lines,

allow-hotplug wlan0
iface wlan0 

inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.confiface 

default inet dhcp

Now open file '/etc/wpa_supplicant/wpa_supplicant.conf' but there's nothing so a new file will be created, append the following lines,

network={ ssid="xxxxx"psk="12345678"key_mgmt=WPA-PSK}

Save and Exit and try to enable the interface...
```
ifdown wlan0
ifup wlan0
```

Wow! it's work!!!

SHARING FOLDER WITH WINDOWS MACHINE

I want to open image/video/audio, edit python program using Windows machine, so sharing files from myNano to PC is a great idea.
Now let's install and configure 'SAMBA' (for more details read here and here):

sudo apt-get install samba samba-common-bin

After installation, configure the software by opening the file '/etc/samba/smb.conf' using the command:
```
sudo nano /etc/samba/smb.conf
```
Read through the file and make sure you have the following parameters set:
```
workgroup = WORKGROUP
wins support = yes
```
You can use anything as your workgroup name as long as it is alphanumerical and matches the workgroup you would like to join. The default workgroup in Windows 7 is WORKGROUP.

Setup folder to share

Next step is to create the folder to be shared. To create a folder called “share” in home directory do the following:
```
sudo mkdir -m 1777 home/share
```
With the folder created we can now tell the Samba software to share it on the network. Open the file '/etc/samba/smb.conf' using the command:
```
sudo nano /etc/samba/smb.conf
```
Scroll to the bottom and add the following:
```
[data]
 comment= myNanoPi Share
 path=/home/share
 browseable=Yes
 writeable=Yes
 only guest=no
 create mask=0777
 directory mask=0777
 public=no
```
Notice how we tell Samba that public access is not allowed via “public=no” this means that anyone wanting to access the shared folder must login with a valid user.

In this case the valid user is the user called “fa”. To let Samba know that “fa” is a network user run the command:
```
sudo smbpasswd -a fa
```
If you do not want to deal with logging in you can always make the share publicly available by changing the config file to say:
```
public=yes
```

9/26/2016

Getting start with NanoPi-M1 PART-I

Revision : 1.0

Date : 26/09/2016

Author : CCPC-Rombix

PART I

I'm looking for Embedded Linux Board that cheaper and smaller than Raspberry Pi-3 for my Active-Camera Box (Photo capture, VDO-Audio capture and Live Streaming). The NanoPi-M1 is another choice for me and here's my experimenting...

STARTUP

Take a look at official NanoPi-M1 features here and WiKi page here.
Download Debian disk image here (be patient! took very long time).
On Windows machine, create disk image using Win32DiskImager.
Insert SD-Card with os installed, plug-in LAN cable and apply 5V/2A power supply to micro usb port.
After device boot, Find NanoPi-M1 IP address, I'm using AdvanceIP Scanner.

UPDATE OS

First of all to make sure that every thing is up-to date, it's recommended to update the OS.
Login using default user name: fa password: fa
Perform update & upgrade using command

sudo apt-get update --fix-missing
sudo apt-get upgrade --fix-missing

UTILIZED FULL DISK SPACE

After update OS and check disk space (using command: df -h) the NanoPi seen space on my TF-card only 3.9GB.
The rootfs section of the TF-card need to be resized, run the following command on the NanoPi terminal:

sudo fs_resize

Following the prompt type in "y" to start re-sizing the file system and a second "y" to reboot the M1. After the M1 is rebooted check the new section by using the following command：

df -h

UTILITY FOR USB DEVICES

I wan't to use USB-WiFi, USB-Camera, 3G-Dongle and other USB devices on my NanoPi, so the USB utility is required.
Install USB utility...

  sudo apt-get install usbutils

Now I can use command: 'lsusb' to check if the USB device is compatible to my NanoPi.

CHANGING THE HOSTNAME

The factory hostname 'FriendlyArm' do not make sense to me, I want to change it to something like 'myNanoPi'.
Follow these step to change hostname from 'FriendlyArm' to 'myNanoPi'

sudo nano /etc/hostname

Leave all of the entries alone except for the labeled 127.0.1.1 , change the hostname to “myNanoPi“.
CTRL-O to save, CTRL-X to exit and get back to the terminal, type the following command to open the hostname file:
sudo nano /etc/hostname

This file only contains your current hostname, change it to "myNanoPi"
Finally, we need to commit the changes to the system and reboot the system for the changes to take effect. At the terminal, enter the following command to commit the changes:

sudo /etc/init.d/hostname.sh

sudo reboot

Once the system comes back online, you can check the device list in your router to see if the new hostname has properly resolved.

LOGIN TO myNanoPi USING TightVNCViewer

NanoPi's OS is pre-installed with TightVNCServer. my NanoPi is not connected to a display device, but I can login to myNanoPi from a mobile phone, download and install a "VNC Viewer" from hereand login to the myNanoPi via VNC at port 1. Its default password is "fa123456" (same as login from TightVNCviewer on PC).

Continue to part II for device installation....

7/29/2016

https โดนแฮกได้ยังไง จะระวังตัวยังไง

สอนแฮกเว็บแบบแมวๆ·7 มิถุนายน 2016

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

คำตอบสั้น ๆ ง่าย ๆ คือ มีโอกาสโดนดักข้อมูลครับ

คราวนี้ลองมาดูกันต่อ หลายคนอาจสงสัยว่าแล้ว เอ๊ะ! เว็บที่เป็น https:// แล้วขึ้นเตือนว่า “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” มีหน้า error ขึ้นกุญแจสีแดงแบบนี้ กับเว็บที่เป็น https:// ที่เป็นกุญแจสีเขียวใช้งานได้ปกติ แตกต่างกันยังไง? 

อยากรู้จริงปะครับ เรื่องมันยาว... จะเริ่มละนะครับ พร้อมยัง? จะอ่านกันจบไหมเนี่ย~

การโดนดักข้อมูลบน HTTP

เราคงไม่ต้องพูดถึง http:// กันมากแล้วเนอะ กรณี http:// คือไม่มีการเข้ารหัสใด ๆ ถ้าโดนแฮกเกอร์ในวง network เดียวกัน เช่นใช้ WiFi เดียวกัน อาจเป็นแบบ WPA/2 Personal หรือพวก captive portal ที่ล็อคอินผ่านหน้าเว็บก็ได้ สามารถโดนดักข้อมูลด้วยการทำ man-in-the-middle (จากนี้ขอย่อว่า MitM) แบบ passive ได้ง่ายและสบายมาก ๆ วิธีการคือ..

1. monitor mode

เปิด wireshark เลือก network interface ของ WiFi ที่ทำ monitor mode ได้ซึ่ง wireless chipset + driver ต้องรองรับด้วย ใครใช้ Macbook มันเปิดได้อยู่แล้วใครใช้ยี้ห้ออื่นต้องใช้พวก Alfa WiFi adaptor มาต่อ
อธิบายภาษาไอที: ปกติ เครื่องที่เราใช้ wifi เช่น iphone หรือ macbook ตัว wireless chipset จะทำงานเป็น managed mode หมายถึงเป็น ผู้ใช้งานที่ จะต่อไปยัง access point เพื่อจะรับ-ส่งข้อมูลกันในหรือนอก network, ส่วนพวก access point/hotspot พวกนี้จะทำงานใน master mode คือรอให้ ผู้ใช้งานมาต่อ รับหน้าที่บริหารจัดการการส่งข้อมูลระหว่างผู้ใช้งาน และจะมี mode อื่น ๆ อีก เช่น repeater mode ไว้เปิดให้อุปกรณ์ access point ที่จะเอามาขยายสัญญาณ เป็นต้น แต่มีอยู่ mode นึงครับชื่อว่า monitor mode ในโหมดนี้สิ่งที่ wireless chipset ในคอมจะทำคือไม่ส่งข้อมูลใด ๆ ออกไป แต่จะทำการ “อ่าน” ข้อมูลทั้งหมดที่ลอยอยู่ในอากาศ โดยไม่สนว่า ข้อมูลที่ลอยอยู่ในอากาศนั้นเป็นของ access point ไหนหรือ client ไหนก็ตาม ถ้าเจอในอากาศดักมาให้หมด! แต่เงื่อนไขคือดักได้ทีละ 1 channel ในขณะนึงเท่านั้น (โปรแกรมบางตัวเช่น airodump-ng ใน aircrack suite มันดักทีละหลาย channel ได้เพราะมันทำการ hopping เร็ว ๆ ข้าม channel รัว ๆ ครับแต่จริง ๆ มันอยู่ได้ทีละ 1 channel เท่านั้น)

2. promiscuous mode

เลือกเปิด promiscuous mode อันนี้เปิดได้อยู่แล้วทำได้ทั้งใน วงแลนหรือ  WiFi
อธิบายภาษาไอที: ปกติใน network แบบเก่าที่ใช้ hub การส่งข้อมูลระหว่างเครื่อง A ไปยัง เร้าเตอร์ B ข้อมูลใน data packet จะระบุต้นทางเป็น A ปลายทางเป็น B ซึ่งถ้ามีเครื่อง C ใน network เดียวกัน ต่อให้ C ได้รับ packet ที่ A จะส่งให้ B มันก็จะไม่ยอมรับ ทำการ  drop packet ทิ้ง แต่การเลือกเปิด promiscuous mode คือให้ไม่สนว่าปลายทาง data packet จะส่งไปเครื่องไหน ให้เลือกดักข้อมูลไว้ก่อนเลย แต่ปกติแล้ว promiscuous mode เปิดไว้เฉย ๆ มันก็ดักข้อมูลยังไม่ได้ทันทีเพราะสมัยนี้เค้าไม่ได้ใช้ hub กันแล้วข้อมูลมันไม่ได้ส่งหาทุกคน ดังนั้นการจะเปิด mode นี้ต้องมีตัวช่วยอื่น ๆ ด้วย เช่นสามารถดักรับข้อมูลในอากาศได้อยู่แล้วด้วย monitor mode แล้วจึงเปิด promiscuous mode ให้ wireshark นำ data packet ของการคุยกันระหว่างเครื่องอื่นที่ดักได้มาแสดงผล.. โหมดนี้แหละที่คนชอบเรียกกันว่า sniffer mode เพราะว่าชื่อจริงมันอ่านย๊ากก (แซวเล่นนะครับ)

3. WPA/2 Personal

ครบเงื่อนไข 2 ข้อแรกนี้ ถ้าอยู่บน open WiFi ที่ต่อได้เลยหรือเป็น login ผ่านหน้าเว็บก็จบเลย ดักข้อมูลได้ทันที *แต่* ถ้าเป็น WPA/2 Personal ก็จะต้องใส่รหัส Pre-Shared Key ลงไปในออฟชั่น preference ของ Wireshark ก่อน (กรณีนี้คือคนดักข้อมูลเข้าไปใช้ WiFi สาธาณะนั้น ๆ ได้ถ้าไม่ได้ก็ต้อง aircrack หากันเองนะครับ) ให้มัน เอาคีย์ไปถอดรหัส data packet ที่ดักมาจาก monitor mode ได้จากนั้นก็จะแอบดักดูข้อมูลทั้งหมดที่อยู่ในอากาศของคนอื่นใน WiFi เดียวกันได้ทันที 

ถ้ามี username / password / credit card อะไรถูกส่งผ่าน http:// ก็เห็นกันชัด ๆ เต็มตาไปเลยจ้า

ที่ว่ามาคือการทำ passive MitM บน WiFi ในอากาศครับ แต่ถ้าบน ethernet (LAN) ละ? กรณีนี้ ถ้าเราทำการ mirror traffic จาก switch ออกมา หรือไปคั่นกลางเพื่อดักข้อมูลไม่ได้ สิ่งที่ต้องทำคือ active MitM ครับ วิธียอดนิยมก็เช่นการทำ ARP Spoofing, DNS Spoofing ทั้งหลายนั้นเอง
อธิบายภาษาไอที: ปกติเวลาในวง LAN เครื่องสองเครื่อง*จะส่งข้อมูลหากันภายใน network* ย้ำว่าภายในนะครับ จะรู้ว่า ใครมีหมายเลข IP อะไร ผ่าน protocol ที่ชื่อว่า ARP ที่จะคอยส่งคำถาม/คำตอบว่า IP ในวง LAN นี้มี MAC address อะไร เพื่อจะส่งข้อมูลหากันถูกเครื่องนะครับ การทำ ARP Spoofing คือการ หลอกประกาศ หลอกตอบ เครื่องอื่น ๆ ในวง LAN ว่าเราเป็นใครอีกคนที่จริง ๆ แล้วไม่ใช่เรานะครับ ส่วนมากที่จะใช้กันคือ หลอกว่าเครื่องของแฮกเกอร์เป็นเร้าเตอร์ เพราะว่าเมื่อ คอมสักเครื่องในวง LAN เผลอเข้าใจผิดว่าเครื่องแฮกเกอร์เป็นเร้าเตอร์ เวลาจะส่งข้อมูลออกไปภายนอก network เช่นไปเฟซบุ๊กเงี้ย มันจะส่งไปที่เร้าเตอร์ก่อน ทำให้แฮกเกอร์ที่ไม่ใช่เร้าเตอร์จริง ๆ ดันได้รับข้อมูลไปด้วย ผลคือสามารถดักอ่านข้อมูลคนอื่นได้นะครับ โปรแกรมที่ทำได้ก็เช่นบน Linux มี ettercap/arpspoof บน Windows มี Cain & Able โบราณสุด ๆ... ส่วนอีกทริคที่นิยมใช้กันคือ การประกาศหรือหลอกตอบว่า เครื่องเร้าเตอร์มี MAC address มั่ว ๆ ที่ไม่มีอยู่จริงในวง LAN ผลคือ คอมที่หลงเชื่อไปนั้นจะเข้าเน็ตเข้าเว็บอะไรไม่ได้นะครับ นี้เป็นหลักการของโปรแกรม netcut ที่ไว้ตัดเน็ตแกล้งกันนั้นเอง

แต่เทคนิคการทำ spoofing ทั้งหลายนี้ สามารถถูกตรวจเจอได้ง่าย ๆ ว่าใครเป็นคนทำ หาตัวคนร้ายได้ไม่ยาก เพราะเครื่องแฮกเกอร์จะต้องคอยส่ง data packet ปลอม ๆ พวกนี้ ผู้ดูแลระบบหรืออุปกรณ์ network security สมัยใหม่สามารถตรวจเจอได้ กลับกันในแบบ passive MitM อันแรกนี้สิ โอกาสตรวจเจอยากกว่ามากครับ เพราะฉะนั้นแอดมินขอย้ำว่าใช้ WiFi สาธาณะร่วมกับคนอื่น มีความเสี่ยงจะโดนดักข้อมูลได้เยอะนะครับ ถ้ายังส่งข้อมูลที่ไม่ได้เข้ารหัส.. แต่เดี๋ยวก่อน วิธีดักข้อมูลแบบ passive ที่ว่ามาใช้ใน WPA/2 Enterprise ไม่ได้ครับ ที่มันมีให้กรอก username/password ของใครของมันเวลา login เป็นหน้าต่างขึ้นมา (ไม่รวมแบบกรอกผ่านหน้าเว็บนะครับ) ใครใช้อยู่ก็ไปกังวลแบบ active แทนวิธีป้องกันสำหรับผู้ดูแลระบบก็ทำพวก dynamic arp inspection/dhcp snooping/static IP คอย monitor network traffic เช็คสุขภาพ network ตัวเอง คอยวิเคราะห์ log จากอุปกรณ์ network security บ่อย ๆ จะช่วยลดความเสี่ยง-แก้ปัญหาการโดนดักข้อมูลแบบ active MitM ได้ครับ!

หรือโชคร้ายกว่านั้นหน่อยถ้า เราไม่ได้ถูกทำ MitM ทั้งแบบ passive หรือ active ในวง network เดียวกัน แต่อุปกรณ์ network ระหว่างการส่งข้อมูลจากเครื่องเราไปยังเว็บปลายทางดันโดนแฮก หรือโดนเข้าถึงได้จากผู้ไม่หวังดี ก็สามารถดักเห็นข้อมูลของผู้ใช้งานทุกคนที่ไม่ได้เข้ารหัสบน http:// ได้เช่นกันครับ

จากรูปจะเห็นว่าการที่ เราเข้าเว็บ site.com จริง ๆ แล้วข้อมูลเรามันไม่ได้เด้งดึ๋งจากเครื่องเราผ่านเข้า web server ของ site.com ตรง ๆ แต่มันผ่านมือคนหลายมือ และแต่ละมือ ก็มีโอกาสจะเข้าถึงข้อมูลเราได้ง่าย ๆ ถ้าไม่ได้มีการเข้ารหัสข้อมูลครับ เช่นจาก ISP ผู้ให้บริการอินเทอร์เน็ตบ้านเราอย่าง True, 3BB บลา ๆ พวกนี้ ข้อมูลเราวิ่งผ่าน อุปกรณ์เค้าเต็ม ๆ มันก็ไม่ใช่เรื่องยากเกินความสามารถเลยที่เค้าจะเลือกจะเข้าถึงข้อมูลเราได้ และอาจนำข้อมูลนี้ไปแชร์ต่อใครก็ตามเช่น รัฐบาล หรือ ตำรวจ  เคยได้ยินไหม ประโยคที่เวลาคนโดนแฮก หรือมีคดีไซเบอร์แล้วคนชอบบอกว่า “ไปขอ log จาก ISP มาสิ” นี้แหละครับ

ตัวอย่างอีกเหตุการณ์การง่าย ๆ ที่แต่ละ มือคน ที่ข้อมูลเราวิ่งผ่านจะเห็นข้อมูลเรา องค์กรทั่ว ๆ ไปจะมี web proxy server อยู่เวลาพนักงานในบริษัทจะเข้าเว็บจะวิ่งผ่านเครื่องนี้เพื่อจุดประสงค์บางอย่างเช่น จะบล็อคเว็บบางเว็บไม่ให้พนักงานเข้า หรือช่วยในการลดปริมาณข้อมูลการส่งออกด้วยการทำ caching (เป็นการทำสำเนาข้อมูลของเว็บที่เคยเข้าแล้วเก็บไว้แล้วส่งให้คนถัดไปที่จะมาเข้าเว็บเดิมแทนที่จะต้องวิ่งไปคุยกับเว็บนั้นหลาย ๆ รอบเปลืองเน็ตบริษัท) ตัว web proxy server นี้แหละตัวดี ผู้ดูแลระบบสามารถเปิด wireshark/tcpdump ดักข้อมูลที่ไม่ได้เข้ารหัสของทุกคนในบริษัทได้ครับ

การโดนดักข้อมูลที่เป็น HTTPS

คราวนี้จะเกิดอะไรขึ้นถ้า.. เกิดเหตุการณ์แบบเดียวกันแบบที่เล่ามาข้างบนเลยโดน passive/active MitM เละเทะ แต่ปรากฏว่าเว็บที่เราใช้เป็น HTTPS ครับ ตามในกระทู้พันทิปที่ถามถึงครับ ผลคือคนที่ดักข้อมูล ก็ดักได้ต่อไปครับ แต่ว่า ข้อมูลที่ได้มานั้น จะถูกเข้ารหัสด้วย SSL หรือ TLS .. จนถึงจุดนี้ทุกอย่างแลดู สวยงามดี งั้นถ้าเราเข้าเว็บที่เป็น https:// มีการเข้ารหัสแล้ว แสดงว่าต่อให้เราโดนดักข้อมูล ก็สบายใจได้ เพราะคนที่ได้ข้อมูลไปไม่สามารถถอดรหัสได้นี่นา คำตอบคือ... ไม่ใช่เสมอไปครับ

เพราะว่าตั้งแต่เกิดการใช้งาน https://  เพื่อเข้ารหัสข้อมูลป้องกันการถูกดักอ่านข้อมูลนั้น ก็มีการศึกษาค้นคว้าวิจัย วิธีโจมตี https ต่าง ๆ นา ๆ หลายรูปแบบ บางการโจมตี มุ่งไปที่ช่องโหว่ในตัวการเข้ารหัสด้วย SSL/TLS โดยตรง เพื่อหวังจะถอดรหัสอ่านข้อมูลข้างในเช่น BEAST, CRIME, POODLE, FREAK, LOGJAM อะไรพวกนี้นะครับ เป็นชื่อช่องโหว่ หลายคนในวงการไอที อาจเคยคุ้น ๆ หูกันมาบ้าง พวกช่องโหว่เหล่านี้ ใช้โจมตีในสถานการณ์จริง ๆ ค่อนข้างยากมาก เพราะมีเงื่อนไขเยอะ ส่วนใหญ่หลุดออกมาจากโลก academic ตีพิมพ์จาก paper ปริญญาเอก โดยทั่ว ๆ ไปเราจะไม่ได้นำมาใช้แฮกกัน คนจะสนใจโจมตีช่องโหว่พวกนี้ได้ต้องเป็นระดับรัฐครับเช่น NSA ของอเมริกา เพราะต้องมีงบ มี resource เยอะถึงจะทำได้ หรือทำแล้วคุ้มค่าจริง ๆ ส่วนคนธรรมดาที่อยากจะดักข้อมูลที่เป็น https:// เค้าจะใช้แนวทางดังต่อไปนี้ครับ

1. SSLStrip

เทคนิคนี้มีชื่อที่อธิบายกระบวนการของมันเองได้ชัดเจนครับคือการ strip ถอดเจ้า SSL/TLS ออกนั้นเอง วิธีการคือ เราต้องทำ MitM ใน network ให้ได้ก่อนครับ วิธีทำดังที่อธิบายไว้แล้วข้างบน  

จากนั้น แฮกเกอร์ที่อยู่ตรงกลางในรูปคือตรงคำว่า “SSLStrip” นั้นแหละ จะทำการดักว่า ถ้าเหยื่อ (คอม ด้านซ้าย) พยายามจะต่อเข้าเว็บ เฟซบุ๊ก https ให้แฮกเกอร์ทำการเรียก เฟซบุ๊ก https แทนเครื่องเหยือ แต่ตอนส่งข้อมูลกลับมา ให้ส่งว่าเว็บที่กำลังเข้าอยู่เป็น เฟซบุ๊ก http คือการ “ถอด s ออก” เปลี่ยนจาก https เป็น http อย่างแยบยล ถ้า ผู้ใช้งานไม่ทันได้สังเกตว่าอยู่ดี ๆ เว็บที่เข้าอยู่จาก https เปลี่ยนเป็น http แล้วล็อคอินเข้าใช้งาน หรือส่งข้อมูลตามปกติ ก็ทำให้แฮกเกอร์สามารถดักอ่านข้อมูลได้ครับ

ทางแก้ไขสำหรับผู้ใช้งานทั่วไปคือ ระวังอย่าให้โดน MitM ครับ ถ้าไม่โดน MitM ก็โดน SSLStrip ไม่ได้แน่ ๆ ต่อมาคือ คอยสังเกตว่าเว็บที่เราใช้งานที่มันจะต้องเป็น https มันยังเป็น https อยู่รึเปล่า ถ้าวันดีคืนดี s มันหายไปเป็น http ธรรมดาแปลว่าเราอาจจะโดนของเข้าให้แล้วนะครับ แต่อันนี้ก็ขึ้นอยู่กับเว็บปลายทางด้วย บางเว็บอาจจะรองรับการเข้าแบบ http ปกติด้วยก็ได้ ก็ให้เราลองเลือกใช้เป็น https ดูว่าถูก ถอด s ออกหรือไม่ครับ 
อธิบายภาษาไอที: ใครอ่านแค่ส่วนแรกของ SSLStrip ก็มึนแล้วข้ามไปข้อ 2 เลยก็ได้นะครับ, ส่วนทางแก้ไขในโลก computer security นักวิจัยด้านความปลอดภัยก็พยายามหากระบวนการเข้ามาแก้ปัญหาตรงนี้ชื่อว่า HTTP Strict Transport Security (ขอเรียกย่อ ๆ ว่า HSTS) ซึ่งกระบวนการนี้จะถูกใช้โดย web browser กับ web server ที่เวลาส่ง HTTP Response header ชื่อ strict-transport-security ตอบกลับมาให้รู้ว่า เมื่อ web browser จะเข้าใช้งานเว็บ domain นี้ ต่อไปอีกวินาที (max-age) จะกำหนดให้... 

- จะต้องเข้าเว็บนั้น ๆ เป็น https ให้หมด! ห้ามเข้าเว็บชื่อนี้เป็น http เด็ดขาด! 
- เสริมอีกว่าถ้ามี error ในใบรับรองความปลอดภัย certificate (คำคีย์เวิร์ดสำคัญของเราวันนี้โผล่มาแล้วในที่สุด!) หรือการเชื่อมต่อใน SSL/TLS  ก็จะให้ web browser ห้ามเข้าเว็บนั้นเด็ดขาด! เช่นกัน

เอาจริง ๆ HSTS เกิดมาเพื่อแก้ไขอีกปัญหานึงชื่อว่า mixed content ด้วยคือในเว็บที่เป็น https คนเขียนเว็บนั้นเผลอใส่รูปใส่ js css ใส่ลิ้งเป็น http ถ้าผู้ใช้งานเข้าเว็บแล้วมันถูกโหลดอัตโนมัติ ต่อให้เว็บเป็น https ข้อมูลพวก cookie ที่ใช้ยืนยันว่าเรากำลังล็อคอินเว็บอยู่อาจหลุดไปอยู่ในมือคนดักข้อมูลได้ (ถ้าไม่ได้ ตั้ง secure flag ตอน set-cookie ไว้) 

เกร็ดเล็กน้อย ผู้อ่านที่เฉลียวใจนิดนึง อ่านมาถึงตรงนี้อาจสังเกตได้ว่า HSTS มีช่องโหว่เล็กน้อย คือ web browser จะทราบได้ว่าเว็บนั้น ๆ มีการเปิดใช้งาน HSTS รึเปล่า ขึ้นอยู่กับ HTTP Response จาก web server ที่ตอบกลับมาแล้ว ดังนั้นแปลว่า HTTP Request แรกสุดที่เราส่งไปเว็บนั้นผ่าน web browser หรือ ตอนที่เราส่งหลังจาก clear cache หรือระยะเวลาหมดอายุในครั้งแรกนั้น จะไม่มีการเปิดใช้ HSTS ทำให้ถ้าเราดวงจู๋ โดนดักข้อมูลตรงจุดนี้ละก่อน HSTS ก็ช่วยอะไรไม่ได้ครับ เพราะแฮกเกอร์ก็สามารถ strip HSTS header ตอนตอบกลับมาออกได้นะครับ ดังนั้น web browser หลัก ๆ อย่าง Firefox หรือ Chrome ก็เลย... เอาวะ มาแก้ปัญหานี้กันด้วยการ แทนที่ web browser จะรอให้ web server ตอบกลับมาว่ารองรับการใช้งาน HSTS ทำไมเราไม่ บอก web browser ไปเลยว่า ถ้าจะเข้าเว็บบางเว็บให้ต้องเข้าเป็น https เท่านั้น คือฝังกระบวนการ HSTS สำหรับบางเว็บใหญ่ ๆ ดัง ๆ ที่รู้กันอยู่แล้วว่าพวกนี้ใช้ https  หมด ลงไปเลย แล้วเรียกกระบวนการฝัง HSTS นี้ว่า HSTS preload ครับ

แต่แล้ววันดี คืนดีก็มีคนมาคิดวิธี bypass HSTS ได้ในบางกรณี เช่นไม่ได้ใช้ออฟชั่นใน HSTS header ที่ให้รวมทุก sub-domain โดยการแกล้งทำ DNS spoofing จากเว็บจริงเช่น www.facebook.com ไปที่ sub-domain มั่ว ๆ ที่ไม่ได้ทำ HSTS หรืออาจไม่มีอยู่จริงเช่น wwww.facebook.com เพราะตัว HSTS มันระบุต่อ 1 sub-domain ปัจจุบันที่ request ไปเท่านั้น แล้วให้ทำ SSLStrip ต่อจากนี้แทนวิธีป้องฝั่ง user ก็คอยสังเกตว่ากำลังใช้ sub-domain ผิดปกติรึเปล่า อีกวิธีคือใช้ browser extension ชื่อ HTTPS Everywhere ช่วยบังคับให้เข้าเว็บที่รองรับทั้ง http/https แล้วจะเข้าได้แต่เป็น https ฝั่งผู้ดูแลระบบก็ต้องตั้งค่ากันอย่างรัดกุมว่าจะใช้  https + HSTS ในทุก sub-domain ถ้าทำได้นะครับ

2. SSL Interception Proxy

วิธีนี้เป็นวิธีที่ว่ากันว่า โครงการ single gateway ของไทยเค้าจะทำแหละครับ หลักการของเทคนิคนี้คือขั้นแรกต้องโจมตีด้วยการทำ MitM ปกติให้ได้ก่อน (ใครลืมแล้วเลื่อนขึ้นไปอ่านว่าทำยังไงได้บ้างนะครับ) ขึ้นอยู่กับเรามองว่าคนจะดักข้อมูลเป็นใคร ซึ่งถ้าเป็น ISP หรือคนดูแล web proxy server ในองค์กร ไม่ต้องทำอะไร นั่งเฉย ๆ ก็มีข้อมูลผู้ใช้งานวิ่งผ่านตัวเองเป็น passive MitM อยู่แล้วนะครับ เพียงแต่อ่านข้อมูลที่เข้ารหัสด้วย SSL/TLS ยังไม่ออกเท่านั้นเอง จะเข้าใจวิธีการโจมตีนี้ได้ต้องพอเข้าใจว่า https ทำงานยังไงนะครับ 

จากรูป 7 ขั้นตอนในการ เปิด SSL/TLS session ตอนเริ่มการทำงาน https คร่าว ๆ นะครับ ขอสรุปเฉพาะส่วน certificate ละกัน...

- web server ส่งกุญแจเข้ารหัส public key มาให้คนเข้าเว็บ เรียกว่า x.509 certificate (และส่งให้ทุก ๆ คนเหมือนกัน เป็นข้อมูลเปิดเผย) ตัวนี้แหละคือ ใบรับรองของเว็บ ที่เป็น https

- web browser จะนำ ใบรับรองตัวนี้ไปเช็คในเครื่อง ว่าถูกรับรองโดยองค์กรที่ไว้ใจได้ (เรียกว่า trusted CA: Certificate Authority) หรือไม่ ถ้าใช่จะถือว่า เป็นใบรับรองที่เชื่อถือได้ 

- ถ้าใบรับรองนั้น trusted หมดทั้ง chain จนไปถึง root CA และการตั้งค่าต่าง ๆ ปกติดี web browser จะ ขึ้นเป็นกุญแจตามปกติให้เราครับ

- ปัญหาคือถ้าใบรับรอง certificate นั้นไม่ได้ถูกรับรอง (คือการ sign ด้วย private key) โดย CA ที่น่าเชื่อถือ จะถือว่าไม่น่าเชื่อครับ... คำถามคือ จะรู้ได้ไงว่า CA ไหนน่าเชื่อถือ? อันนี้ ในระบบปฏิบัติการทั้ง Windows/Linux/OSX มันจะมี list ของ CA ที่น่าเชื่อถือใส่ไว้ให้อยู่แล้วใน certificate store นะครับ ตัวอย่างของ Windows 8.1

CA ในนี้เรียกว่า trusted root CA เป็น CA ที่อยู่สูงสุดในลำดับชั้นของความน่าเชื่อถือ (chain of trust) พวก web browser ส่วนมากยกเว้น firefox จะเช็คใบรับรอง certificate จากการเชื่อมต่อไปเว็บที่เป็น https กับ list ตรงนี้ (ส่วน firefox จะมี list ของ trusted root CA เป็นของตัวเอง แต่ CA เกือบทั้งหมดก็จะเหมือน ๆ กันครับ) โดย trusted root CA สามารถรับรอง CA อื่นให้มีสิทธิ์ไปรับรอง cert ให้ใครต่อก็ได้ แล้วยังถือว่าน่าเชื่อถืออยู่ ได้เรียก CA ที่ถูกรับรองโดย root CA ว่า intermediate CA เพื่อว่าเวลามีคนขอ cert เยอะ ๆ แล้วจะได้ช่วย ๆ กันออกได้ด้วย เกร็ดเล็กน้อยเวลาจะสังเกตว่า CA ไหนเป็น root CA คือค่า Issued To กับ Issued By ของใบรับรองจะเป็นองค์กรเดียวกันนะครับ (เหมือน self-signed เป๊ะ แต่ trusted root CA คือจะอยู่ใน certificate store นี้)

ผลของการที่ถ้า x.509 certificate ที่ส่งมาจาก เว็บ ไม่ได้ถูกรับรองโดย trusted CA คือ web browser จะแจ้งเตือนขึ้น error ว่าการเชื่อมต่อไม่ปลอดภัย มีโอกาสโดนดักข้อมูลได้... 

ทำไมอย่างงั้นละ.. ในเมื่อการเข้าเว็บ https ด้วย certificate ใด ๆ ที่จะรับรองโดยใครมันก็มีการเข้ารหัสข้อมูลทั้งนั้นนี่หน่า? ไม่ได้มีผลต่อ ความปลอดภัย (security) เลยว่า การเข้ารหัสมันจะอ่อนแอลงตรงไหน??

คำตอบคือ มันมีปัญหาเรื่องความน่าเชื่อถือ (trust) ว่าการเข้ารหัสที่เรากำลังเชื่อมต่ออยู่นี้ เราเข้ารหัสคุยกับ web server ปลายทางนั้นอยู่จริง ๆ รึเปล่า? ไม่ใช่ว่าเป็นการเชื่อมต่อที่เข้ารหัส แต่เราดันเข้ารหัสคุยกับเครื่องของแฮกเกอร์ที่ทำ MitM ดักข้อมูลเราอยู่ซะงั้น... 

เพราะว่าการที่มันมี certificate ที่ออกโดยใครก็ได้และไม่ได้ถูกรับรองโดย trusted CA ที่ชื่อว่า self-signed certificate ปัญหาคือการที่ใครก็สามารถออกได้ มันจึงไม่มีความน่าเชื่อถือ เช่น ใคร ๆ ก็ออก x.509 certificate ให้ www.facebook.com ได้ (เพียงแต่ จะไม่ได้ถูก Issued by โดย trusted CA) 

ผลคือคนที่ดักข้อมูล MitM ได้ สามารถที่จะ จำลองการเชื่อมต่อ https ทั้งสองฝั่ง.. 

1 จากทั้งฝั่งเหยื่อเข้าเว็บ https มาเครื่องที่กำลังดักข้อมูล ตรงนี้คนดักข้อมูลสามารถส่ง self-signed certificate ของ www.facebook.com ไปให้เหยื่อใช้เข้าเว็บที่เป็น https ได้ เชื่อจะเห็นว่าตัวเองกำลังเข้าเว็บเป็น https://www.facebook.com/ ปกติเลย มีการเข้ารหัส *แต่* จะมี error บอกว่าการเชื่อมต่ออาจไม่ปลอดภัยเพราะใบรับรองไม่น่าเชื่อถือนั้นเอง
2 / 2.3 จากฝั่งเครื่องที่ดักข้อมูลเชื่อมต่อ https ของจริงปกติไปยังเว็บเป้าหมายจริง ๆ 
4 เอาผลที่เว็บของจริง https://www.facebook.com/  ตอบกลับมา มาเข้ารหัสด้วย SSL/TLS session  + private key ที่สร้างสำหรับ self-signed certificate ที่ส่งให้ใน 2.1 ส่งกลับไปหาเหยื่อ

ผู้ใช้งานเว็บที่เป็น https ก็สามารถที่จะป้องกันการโจมตีจากเทคนิคประเภทนี้ได้ด้วยการตระหนักว่า ถ้าเราเข้าเว็บที่เคยเป็น https กุญแจสีเขียว แล้ววันดีคืนดี เข้ามาใช้เป็นกุญแจสีแดงเออเร่อ หรือเออเร่อมันทุกเว็บที่เป็น https ให้ตั้งสมมุติฐานไว้ได้เลยว่าเราอาจจะกำลังโดนดักข้อมูลอยู่ให้ลองเปลี่ยนไปใช้ network ที่อื่น หรือหาสาเหตุของปัญหานะครับ ส่วนฝั่งของโลก computer security เกิดเป็นแนวทางการทำ certificate pinning และ HPKP นะครับ อันนี้แอดมินเคยอธิบายไว้แล้วในโพสต์นี้ นะครับ ใครสนใจก็ตามไปอ่านกันได้

สรุป https แบบ error สีแดง เทียบ https ไม่มีเออเร่อกุญแจสีเขียว

จากเหตุการณ์นี้ทำให้เราเห็นว่าการใช้  ใบรับรองที่ไม่น่าเชื่อถือ self-signed certificate ที่ web browser แจ้งเตือน error กุญแจสีแดง ๆ ว่า “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” นั้นผลคือ .. 

ทำให้ ผู้ใช้งานเว็บทั่วไป ไม่สามารถแยกแยะได้ว่า เว็บที่ตนเองกำลังใช้งานอยู่นั้น กำลังใช้ self-signed certificate กุญแจสีแดง ที่ผู้ดูแล web server นั้นเป็นคนออกเองจริง ๆ อย่างถูกต้อง *หรือ* กำลังใช้ self-signed certificate ที่ออกโดยแฮกเกอร์ ที่กำลังทำ MitM ดักข้อมูลที่เป็น HTTPS ทั้งสองทางของเราอยู่กันแน่

เพราะมันก็ขึ้น error แบบเดียวกันเป๊ะ ว่า certificate ไม่ได้ถูกรับรองโดย trusted CA (หรือถ้าใครมีความพยายามมากพอ อาจจะคอยนั่งจำ certificate fingerprint ไว้เวลาเข้าเว็บ self-signed ก็คอยกดดูเองเรื่อย ๆ ว่ายังเป็น fingerprint อันเดิม? ลำบากสุด  ๆ ไปเลยครับ) แต่ในทางกลับกันถ้า เว็บนั้นใช้ certificate ที่ออกโดย trusted CA แล้ว แสดงว่าเว็บนั้นมีความน่าเชื่อถือเพราะ trusted CA มีความน่าเชื่อถือมากพอ เป็นบริษัทที่น่าไว้ใจมากพอว่าจะไม่เป็นคนดักข้อมูลเรา เนื่องจากถูกตรวจสอบอย่างแพงและเข้มข้นจากเจ้าของ certificate store ต่าง ๆ เช่น Microsoft, Mozilla, Apple .. (อื่น ๆ อีกขึ้นกับว่าจะอยากเป็น trusted root CA กับเจ้าไหนบ้าง) ไม่ได้จะเป็นกันง่าย ๆ

trusted CA จะเป็นผู้ตรวจสอบข้อมูลจากผู้ขอรับรอง certificate นั้นว่าเป็นเจ้าของชื่อเว็บ domain นั้นจริง ๆ ก่อนที่จะทำการรับรองให้ครับ (ตอนนี้มีวิธีอัตโนมัติกันบ้างแล้ว แต่ยิ่งของ่ายความน่าเชื่อถือก็ยิ่งน้อย)

ในอดีตเคยมีการจับได้ว่ามี trusted root CA เจ้านึงชื่อ DigiNotar โดนแฮก และออกใบรับรองปลอม ให้ gmail นำมาดักข้อมูลผู้ใช้งานในอิหร่านได้ เป็นแสน ๆ คน .. ผลที่ตามมาคือบริษัทล้มละลายเจ๊งทันทีครับ โดนค่าปรับ โดนฟ้องอ่วม .. ทุก certificate store เพิกถอน ออกอัพเดทเอา DigiNotar ออกจากรายชื่อ trusted root CA ของตัวเองอย่างรวดเร็ว

จากรูปเป็น X.509 certificate ของ *.facebook.com ที่ถูกรับรองโดย DigiCert SHA2 CA ที่เป็น intermediate CA และตัว DigiCert SHA2 ก็ถูกรับรองโดย DigiCert ที่เป็น Root CA อีกที จะเห็นว่า chain of trust ลำดับชั้นของความน่าเชื่อถือถูกการันตรีมาเป็นทอด ๆ จาก Root CA สู่ Intermediate CA สู่ public key certificate ของเว็บที่จะเอามาให้เราใช้ ทำให้เรามั่นใจว่า ใบรับรองอันนี้ส่งมาจาก server ที่น่าเชื่อถือได้ว่าเป็นเฟซบุ๊กจริง ๆ เพราะ server คนอื่นเช่นของคนดักข้อมูลจะไม่มี private key ที่ไว้ถอดรหัส key ที่ใช้เข้ารหัสข้อมูลใน https นะครับ 

ปัญหาอีกอย่างก็คือการรับรอง certificate ของเว็บมันมี ค่าใช้จ่าย ครับยิ่งมีหลาย sub-domain หรือจะทำ wildcard certificate แบบเฟซบุ๊กก็มีค่าใช้จ่ายเพิ่มขึ้นอีก ที่จะต้องจ่ายตังให้  CA ที่จะมายืนยันความเป็นเจ้าของ ก่อนออกใบรับรองของเซิร์ฟเวอร์เรา.. ทำให้เว็บมหาวิทยาลัย หรือองค์กรบางแห่ง ไม่ได้ใช้ trusted certificate ในการให้บริการเว็บด้วย https ดังที่น้องเค้ามาถามไว้... โดยเฉพาะอย่างยิ่งระบบใน internal network ที่ไม่ได้เข้าผ่าน internet มักจะใช้ self-signed certificate กัน ก็น่าเห็นใจที่บางองค์กรหรือมหาวิทยาลัยมี domain/server มากมายจะให้ซื้อใบรับรองจริงใช้ก็เสียงบ เป็นกิจวัตรทุกปีแน่ ๆ คนทำงานราชการก็คงรู้อยู่ว่าเบิกงบอะไรสักอย่างไม่ใช่เรื่องง่าย ๆ 

ข่าวดีคือตอนนี้ในปัจจุบันมีการให้บริการจาก trusted CA ที่สนับสนุนโดย Mozilla/Cisco/Akamai เพื่อจะรับรอง certificate ให้ domain ที่ใครสักคนเป็นเจ้าของได้ฟรี ๆ ในโครงการชื่อ let’s encrypt นะครับ ใครสนใจก็ลองไปกูเกิลหาวิธีทำดูง่ายมาก ๆ สำหรับ apache/nginx แทบลงจะอัตโนมัติให้ทุกอย่างไม่ต้องรู้ ไม่ต้องตั้งค่าอะไรเลย ก็มี https สีเขียว ๆ ให้ใช้ได้ละครับ พร้อมทั้งยังใช้การตั้งค่าต่าง ๆ ของ SSL/TLS ไว้เป็น best practice เป็นค่าเริ่มต้นที่เมื่อสแกนตรวจสอบความปลอดภัย https จากเว็บ Qualys SSL Labs  แล้วได้คะแนน A ทันทีเลยด้วยครับ

CREDIT: https://www.facebook.com/longhackz/

7/25/2016

LINUX: จะรู้ได้อย่างไร ว่าเรา ถูก HACK

หลังจาก hacker ได้ทำการ compromise ระบบแล้วนั้น ส่วนใหญ่ hacker จะไม่ทำการลบข้อมูลหรือทำอะไรที่จะเป็นผลเสียต่อระบบ ของท่าน แต่ hackers จะทำการติดตั้ง back door ในระบบซึ่งทำให้ hacker สามารถเข้าถ้าระบบในฐานะ root หรือบางที hacker อาจใช้ระบบของท่านในการโจมตีระบบอื่นๆต่อไป

เพราะฉะนั้นหากท่านประสบปัญหาอย่างเช่น ระบบของท่านเกิดช้าขึ้นมาอย่างผิดปกติแต่เมื่อท่านได ้ทำการตรวจสอบ disk space และ process แล้วก็ไม่มีสิ่งใดผิดปกติ checklist ต่อไปนี้คือสิ่งที่ท่านควรตรวจสอบเพื่อบอกว่าระบบของ ท่านถูก hacked หรือไม่

1. เหตุการณ์หรือสัญญาณที่ผิดปกติ

ถ้าท่านไม่สามารถทำการ ssh, telnet หรือ login เข้าสู่เครื่องได้เป็นสิ่งบอกเหตุว่าท่านอาจจะถูก hacked ได้
ท่านควรจะทำการตรวจสอบเหตุต่างๆ ที่ไม่สามารถอธิบาย เช่น network ซึ่งผิดปกติ resource ถูกใช้ไปเยอะมากทั้งที่มี users เข้าใช้อยู่เพียงไม่กี่คน
ควรตรวจสอบ /etc/password file ว่ามี account ใดบ้างที่เพิ่งถูกเพิ่มเข้ามาโดยที่คุณไม่ได้ทำการเพ ิ่มเอง รวมทั้งตรวจสอบ accounts ที่ไม่มี password หรือ UID ถูก set ให้เท่ากับ "0"
2. ตรวจหา sniffer

เนื่องจาก sniffer จะทำให้ network interface รับ packet ทุกชนิดที่เข้ามาและทำการบันทึก packet ซึ่งประกอบด้วย username และ password ของ ftp และ telnet แม้ว่าท่านจะแก้ปัญหานี้โดยการใช้ switching แทน hub แต่ถ้าเครื่องดังกล่าวเป็น Internet gateway แล้วปัญหาก็ไม่ได้หมดไป ท่านสามารถทำการ check promiscoous mode ได้โดย # ifconfig - a/grep PROMISC

แต่มี rootkit บางตัวที่ทำการเปลี่ยนแปลง ifconfig เพื่อหลบซ่อนจากการใช้ parameters นี้ เพื่อความแน่ใจให้ท่าน run antisniff http://www.securitysoftwaretech.om/antisniff/ จาก remote machine

3. ตรวจสอบ logs

ทำการตรวจสอบ log files โดยการใช้คำสั่ง last เพื่อที่จะ list logins ท้ายๆออกมาแล้วตรวจสอบว่ามี unknown users หรือ usernames ที่แปลกๆหรือไม่ รวมทั้ง access time ของแต่ละ user ด้วยว่ามีความผิดปกติหรือไม่

# last | head

ตรวจสอบ message file ใน /var/log/ (สำหรับ Linux) หรือ /var/adm/ (สำหรับ Solaris)
รวมทั้งตรวจสอบ log files อื่นๆ ซึ่งใช้โดย syslog (โดยดูจาก /etc/syslog.conf) โดยการ grep su failures ทั้งหลายและเหตุการณ์ที่ vid = 0

# grap "vid = 0" /var/log/
และ
# grep "su" /var/log/

log files ซึ่งมีขนาดเท่ากับ "0" ก็อาจเป็นสัญญาณของการถูกบุกรุกเช่นเดียวกัน
เนื่องจาก rootkit ใหม่ๆ จะทำการลบ usermane จาก wtmp, utmp และ lastlog files เพราะฉะนั้นหากท่านไม่ได้ใช้อุปกรณ์ที่เรียกว่า write once read many เช่น CD-R ในการบันทึก log files ท่านไม่ควรไว้ใจ log files เท่าใดนัก
4. ไม่ควรเชื่อ ps command

ตรวจสอบชื่อและจำนวนของ running processes และพยายามหา processes ที่ไม่ค่อยคุ้น ข้อแปลกๆ หรือ startup time ที่ไม่ค่อยปกติ รวมทั้ง process ที่ใช้ CPU time มากๆอย่างไรก็ตามโดยปกติแล้วผู้บุกรุกจะ run sniffers อยู่ภายใต้ daemon ปกติ เช่น sendmail หรือ named และ rootkits โดยส่วนใหญ่ก็จะทำการเปลี่ยนแปลง ps และ pidof เพื่อที่จะหลบซ่อน process ของพวกเขา ดังนั้นท่านควรจะเปรียบเทียบระหว่างผลลัพธ์ของ ps กับผลลัพธ์ใน /proc เช่น

#ps --no-headers -ef | wc

เมื่อท่าน run คำสั่งต่อไปนี้ใน RedHat 7.0 # ps - -no- headers- ef | wc แล้วผลต่างกันกับที่ run # ls - d /proc/ [0-9]* นั่นคืออาจมี process ที่แอบซ่อนอยู่
ในระบบ Solaris อาจใช้คำสั่ง crash เพื่อที่จะแสดง list ของ processes แล้วเปรียบเทียบกับ ps output
violin $ crash dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout > proc
หรือท่านอาจจะติดตั้งและ run Isof ftp://vic.cc.purdue.edu/pub/tools/ ซึ่งโปรแกรมนั้นจะบอกท่านว่า process ไหนกำลังใช้ files อะไร

5. ตรวจสอบ ports

ทำการ scan ports ของเครื่องโดยใช้ port scanner เช่น nmap [http://www.insecure.org/nmap/ ซึ่งค่า defaults ของ nmap นั้นคือ port1-1024 แต่ trojan horses ส่วนใหญ่จะใช้ ports ที่สูงกว่านั้น หากท่านต้องการเฉพาะเจาะจง ports ที่ต้องการจะ scan ให้ใช้ option-p เช่น

# nmap - p 1 - 65535 your_machin_address
หลังจากนั้น ให้ทำการใช้คำสั่ง netstat -a เพื่อตรวจสอบ port ที่เปิดอยู่บนเครื่องนั้นๆ
# netstat -a

หากพบว่ามี ports ที่ปรากฎใน output ของการใช้ nmap แต่ไม่ปรากฎใน output เมื่อใช้คำสั่ง netstat นั้นอาจหมายถึง netstat ได้ถูกเปลี่ยนแปลงเพื่อหลบซ่อน service บางอย่าง

6. ตรวจสอบ binaries

rootkits ส่วนใหญ่จะทำการเปลี่ยนแปลง system binaries เพื่อทำการหลบซ่อน file, sniffer หรือ port ที่ถูกเปิดอยู่ บน RedHat ท่านสามารถตรวจสอบ binaries ได้โดยใช้คำสั่ง

altis $ rpm - va | grep '1...5'
ซึ่งผลลัพธ์ที่เกิดขึ้นอาจเป็นลักษณะนี้คือ
s.5.....T c/etc/services
s.5....T c/etc/info-dir
s.5....T c/etc/inetd.conf
นั้นหมายถึงขนาดของ file เปลี่ยน (5)
MD5 checksum เปลี่ยน (5)
และเวลาที่ได้รับการเปลี่ยนแปลงถูกเปลี่ยน (T)

บนระบบซึ่งเป็น UNIX ท่านสามารถใช้คำสั่ง find ค้นหา files ที่ถูกเปลี่ยนแปลงในช่วงเวลาหนึ่งๆ ส่วน option ที่ใช้น่าจะใช้ -ctime option ดังนี้

# find/ bin -ctime -7

แต่วิธีที่ดีที่สุดคือใช้คำสั่ง cmp แล้วเปรียบเทียบ วันที่ ขนาดของไฟล์ และ time-stamp ของ system files กับ machine ที่เป็น clean machine และใช้ OS ประเภทเดียวกันซึ่งโดยปกติ binaries files ที่ถูกเปลี่ยนคือ

chsh, crontab, du, df, find, ifconfig, inedd, killall, login, ls, netstat, passwd, ps, sshd, syslogd และ top

ท่านสามารถใช้โปรแกรม tripwire หรือ samhain เพื่อให้แจ้งเตือนเมื่อ system files ถูกเปลี่ยนแปลง

Tripwire http://www.tripwire.org
samhain http://samhain.sourceforge.net

7. ตรวจสอบ Config Files

ท่านควรตรวจสอบ files ซึ่งถูกเปลี่ยนแปลงบ่อยๆได้แก่

/etc/inetd.conf file
หรือ
/etc/xinetd.conf file
หรือ
/etc/xinetd.d directory

พยายามตรวจดู service ที่เพิ่มเข้ามา ถูกเปลี่ยนแปลงหรือเป็น service ที่ท่านไม่คุ้นเคย

/etc/hosts.eguiv, ~/.rhosts

พยายามตรวจดู creationdate และ "+" รวมทั้ง host names ที่ท่านไม่คุ้นเคย

/dev/* เนื่องจากมี rootkits บางประเภทที่จะติดตั้ง configuration files ใน /dev/ ท่านสามารถตรวจสอบ text files ใน /dev directory ได้ดัวนี้

# file /dev/* | grep text
/ dev/ ptyp : ASCIItext
/ dev/ ptyq : ASCIItext
/ dev/ ptyr : ASCIItext

จากตัวอย่างนี้ท่านจะเห็นว่า rootkit ได้ใช้ text file ptyr เพื่อจะหลบซ่อนจาก command lsใช้ ptyq เพื่อจะลบ sockets/ addresses ออกจาก netstat และใช้ ptyq เพื่อจะลบ processes ออกจาก ps

ในฐานะ root ให้ท่าน run crontab - l and atq เพื่อตรวจดูว่ามีโปรแกรมใดที่กำลังรอการทำงานอยู่หรื อไม่

8. ตรวจสอบ setuid, setgid และไฟล์อื่นๆที่หลบซ่อนอยู่

ทำ setuid และ setgid files จะ run อยู่ในฐานะ root แม้ว่าจะถูก executed โดย user ธรรมดาก็ตาม
หากท่านต้องการค้นหา setuid files ให้ใช้คำสั่ง

# find / - perm -4000 -print

และในการค้นหา setgid ให้ใช้คำสั่ง

# find / -perm -2000 -print

โดยปกติแล้วผู้บุกรุกจะแอบซ่อน setuid files และ tools ท่านไว้ใน hidden directories ท่านสามารถตรวจสอบหา files ที่แอบซ่อนอยู่ได้โดยใช้คำสั่ง find

# find / -name " . * "

หรือบางทีผู้บุกรุกจะเลือก directory ไปในการแอบซ่อน files เช่น ~/ gnome, ~/.xauth เหล่านี้เป็นต้น

CREDIT: http://hosxp.net/smf2/index.php?topic=10974.0