Monday, July 30, 2007

www.tuoitre.com.vn thay đổi cách thiết kế menu

Cập nhật mới: các menu ở www.tuoitre.com.vn giờ đã trở thành clickable, có vẻ như họ rất quan tâm đến những gì tôi viết ;).

Hôm nay vào www.tuoitre.com.vn, tôi thấy họ lại thay đổi thiết kế của menu. Bản thân tôi nghĩ rằng thiết kế mới này là một bước lùi đáng kể so với thiết kế cũ mà tôi đã phân tích trước đây.

Chỗ không hay nhất trong thiết kế này là unclickable
menu. Tôi không thể click trực tiếp vào các menu như "Thế giới" hay "Thể Thao", mà tôi phải rê chuột vào các menu này, rồi sau đó rê chuột xuống các submenu bên dưới và click vào các submenu này. Điều này sẽ đem lại rất nhiều phiền toái cho tôi:

Thứ nhất, để đọc được tin tức trong một chuyên mục nào đó, tôi phải thực hiện tổng cộng 3 thao tác, thay vì chỉ 1 thao tác nếu như các menu là clickable. Đó là chưa kể một vài submenu còn sổ ra một dropdown menu nữa, tôi buộc phải click vào chúng thêm một lần nữa. Khi số lượng thao tác tăng lên, nghĩa là xác suất tôi - người sử dụng - gây ra lỗi hoặc phải suy nghĩ sẽ tăng lên rất nhiều.

Bản thân tôi hồi nãy khi truy cập vào www.tuoitre.com.vn, như thường lệ, tôi "Ctrl + Click" vào menu "Thể Thao", rồi Ctrl + Click vào menu "Kinh tế" và menu "Khoa học". Đó là thói quen của tôi, trước giờ mỗi khi tôi làm vậy, tôi sẽ đọc được ngay những gì tôi muốn đọc. Tôi nghĩ rất nhiều người khác cũng có thói quen như vậy, hoặc ít ra, họ luôn nghĩ như tôi rằng, menu trên một website luôn phải clickable. Rõ ràng, khi chuyển các menu thành unclickable, www.tuoitre.com.vn đã phá vỡ thói quen của tôi và rất nhiều người khác.

Rồi khi phải rê chuột 3 lần, chuyện click nhầm, click không trúng vào submenu sẽ dễ xảy ra hơn. Ví dụ như tôi rê chuột vào "Kinh tế", rồi tôi muốn truy cập vào mục "Chứng khoán", nên tôi tiếp tục rê chuột vào submenu "Chứng khoán". Xui là trong lúc tôi rê chuột, chuột của tôi lại chay ngang qua "Nhịp sống số", thế là cái submenu "Chứng khoán" biến mất. Vậy là nếu muốn xem thông tin chứng khoán, tôi phải làm lại từ đầu, một lần, hai lần, hoặc là tôi sẽ bỏ cuộc, qua VnExpress đọc cho lẹ.

Thứ hai, với cách thiết kế như thế này, có vẻ như www.tuoitre.com.vn muốn ép người đọc chỉ được đọc từng chuyên mục riêng biệt trong các mảng đề tài lớn, mà không được phép xem toàn bộ tin tức của một mảng đề tài nào đó.

Ví dụ như mảng đề tài "Nhịp sống trẻ" chẳng hạn, nó có 3 chuyên mục nhỏ hơn mang tên: "Làm đẹp - Thời trang", "Nhịp sống trẻ", "Tình yêu - lối sống". Do tôi không thể click vào menu chính "Nhịp sống trẻ", thành ra bây giờ tôi chẳng thể nào xem được cùng một lúc tin tức của cả 3 chuyên mục này, mà chỉ được phép xem từng chuyên mục riêng biệt. Quái lạ nhỉ?

Chuyện phân chia chuyên mục này cũng đem đến cho tôi một thắc mắc nhỏ khác: sao trong đề tài "Nhịp sống trẻ" (thằng cha) lại có một chuyên mục cùng tên "Nhịp sống trẻ" (thằng con), hai thằng này có gì giống nhau và khác nhau? Rà lại mấy cái đề tài khác, tôi thấy đề tài nào cũng có ít nhất một chuyên mục trùng tên đề tài, thậm chí thằng "Khoa học" chỉ có mỗi một "thằng con" cùng tên, vậy mà cũng bắt tôi phải click và rê chuột nhiều lần chi vậy trời?

Còn vài ba lỗi vặt vãnh khác nữa mà do thời gian không cho phép nên tôi không muốn bàn đến.

----

Sau khi đọc mấy bài phân tích của tôi về www.tuoitre.com.vn, một người bạn có hỏi tôi, tại sao tôi lại quan tâm đến chuyện này vậy, nó đâu phải lĩnh vực chuyên môn của tôi đâu?

Tôi nghĩ là có đó, có một sự liên hệ rất mật thiết giữa usability và security. Trong quá trình làm việc, tôi quan sát được thế này, một phần mềm hay một website nào có usability tốt thường sẽ secure và ngược lại. Thì phải rồi, nếu người ta đã quan tâm đến những vấn đề be bé như cách thiết kế menu thì chắc chắn người ta cũng sẽ quan tâm đến những vấn đề sống còn như security ;). Hi vọng sẽ có dịp đào sâu hơn đề tài thú vị này.

Thursday, July 26, 2007

Không phải cứ "hàng khủng" là tốt (tt)

Nhắc lại phần đầu, máy chủ Oracle của một khách hàng mặc dù có đến 32G RAM và 16CPU nhưng vẫn thường xuyên bị treo vì quá tải. Tôi được giao nhiệm vụ tìm hiểu nguyên nhân và nhờ sự hỗ trợ của Oracle Metalink, tạm thời tôi đã tìm ra đầu mối liên quan đến Hugepages.

HugePages là một tính năng được giới thiệu từ phiên bản Linux kernel 2.6. Linux sử dụng page như là đơn vị cơ bản của bộ nhớ - bộ nhớ vật lý được phân chia và truy cập theo từng page. Kích thước mặc định của một page trong kiến trúc x86 là 4KB, trong ia64 là 16KB, nghĩa là nếu tôi có 32G RAM, Linux sẽ tự động chia lượng RAM này thành 2^21 page, một con số khổng lồ.

Hugepages, như tên gọi của nó, giúp Linux tăng kích thước mỗi page lên, nhằm mục đích giảm số lượng page. Với kiến trúc x64, khi sử dụng Hugepages, mỗi page sẽ có kích thước lên đến 256MB, nghĩa là nếu tôi có 32RAM, Linux chỉ cần chia ra 128 hugepage là đủ.

Trước khi đi vào chi tiết những lợi ích của Hugepage, ta hãy cùng điểm qua hai thành phần rất quan trọng trong cách Linux quản lý bộ nhớ:

  • Page Table: Một page table là một cấu trúc dữ liệu ánh xạ giữa địa chỉ bộ nhớ ảo (virtual memory address) và địa chỉ bộ nhớ vật lý (physical memory address). Chúng ta đều biết, mỗi process trong Linux đều được kernel cấp cho một không gian bộ nhớ ảo tách biệt lẫn nhau. Các bộ nhớ ảo này sẽ được ánh xạ qua bộ nhớ vật lý thông qua các page table. Khi lượng RAM tăng quá lớn, sử dụng page với kích thước mặc định sẽ làm cho page table trở nên cực lớn. Khi đó kernel sẽ mất nhiều thời gian để dò tìm ánh xạ giữa địa chỉ bộ nhớ ảo và bộ nhớ vật lý.
  • TLB: TLB là một bộ nhớ đệm (còn gọi là buffer hay cache) nằm trong CPU; TLB chứa một phần của page table. TLB có kích thước cố định, được tạo ra nhằm mục đích tăng tốc việc chuyển đổi từ địa chỉ bộ nhớ ảo sang bộ nhớ vật lý (tốc độ truy xuất TLB cao hơn tốc độ truy xuất RAM nhiều lần). TLB là một tài nguyên có hạn, và đương nhiên nó cũng bị ảnh hưởng tương tự như page table nếu lượng RAM quá lớn.
Rõ ràng, việc sử dụng Hugepages sẽ đem lại nhiều lợi ích đáng kể trong trường hợp bạn có quá nhiều RAM, mà thiết thực nhất là:
  • Giảm thời gian truy xuất page table: Do số lượng page giảm xuống, kích thước của page table cũng giảm theo, do đó thời gian để kernel tìm kiếm trong page table sẽ giảm xuống đáng kể. Ngoài ra việc tận dụng TLB cũng sẽ trở nên hiệu quả hơn
  • Kernel không bao giờ swap out Hugepages: những vùng bộ nhớ đã được đánh dấu là hugepages sẽ nằm vĩnh viễn trong RAM (cho đến khi reboot hoặc sysadmin muốn thay đổi), kernel không bao giờ swap đám hugepage này ra ngoài ổ cứng. Đây chính là điểm hay nhất của Hugepages, nó giúp chúng ta có thể dedicate một vùng bộ nhớ dành riêng cho một dịch vụ quan trong nào đó trên hệ thống. Trong case này, tôi dùng cho SGA của Oracle.
Sau khi tìm hiểu kỹ về Hugepages, tôi quyết định trao đổi với các anh chị bên DBA cũng như phía lãnh đạo của khách hàng. Họ tỏ ra khá nghi ngờ, bởi lẽ cũng như tôi, họ nghĩ chỉ có thể áp dụng Hugepages được cho x86 mà thôi. Dẫu vậy, họ không còn cách nào khác cả, tôi lúc đó là niềm hi vọng duy nhất của họ, nên họ cũng quyết định cho phép tôi thực hiện.

Việc đầu tiên cần phải làm là tính số lượng Hugepages cần phải có để chứa đủ SGA hiện tại của thằng Oracle. Oracle có cung cấp sẵn một script để làm chuyện đó:
#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.

# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`

# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk {'print $2'}`

# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1

# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk {'print $5'} | grep "[0-9][0-9]*"`
do
MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
if [ $MIN_PG -gt 0 ]; then
NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
fi
done

# Finish with results
case $KERN in
'2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
'2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
*) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac

# End
Như comment ở phần đầu cho thấy, script này tính tổng số lượng shared memory mà hệ thống đang có tại thời điểm chạy script. Tôi chạy script này ngay lúc thằng Oracle đang giãy chết, và kết quả là: Recommended setting: vm.nr_hugepages = 82.

Như vậy, tổng cộng lượng RAM mà tôi phải dành riêng cho thằng Hugepages là 82 x 256M = 20,5G. Do Oracle sẽ sử dụng đám hugepage này như là shared memory, vì thế, tôi phải điều chỉnh cấu hình Linux để nâng tổng dung lượng shared memory lên 25G, trong đó kích thước lớn nhất của một segment là 21G.

Tôi thêm ba dòng như sau vào /etc/sysctl.conf:
# single segment = 21G, Oracle SGA = 20G
kernel.shmmax = 22548578304
# total shared memory 25G
kernel.shmall = 1638400
# total hugepages = 20,5G
vm.nr_hugepages= 82
Nếu bạn không hiểu các dòng trên, hãy thử tự tìm trên Google tài liệu về kernel.shmmax và kernel.shmall để xem các thông số này nghĩa là gì. Do số lượng non-swappable RAM mà Oracle chiếm dụng là rất lớn, nên tôi phải thêm hai dòng sau đây vào /etc/security/limit.conf:

oracle soft memlock 22020096
oracle hard memlock 22020096

Hai dòng này cho phép user oracle được phép chiếm dụng tối đa 21G RAM. Nhắc lại, nếu bạn không hiểu những thông số này, thử tìm trên Google xem sao.

Chuẩn bị xong xuôi. Tôi yêu cầu được phép khởi động lại máy chủ. Lý do phải khởi động là sau một thời gian chạy, RAM đã bị phân chia thành nhiều mảnh nhỏ, cách duy nhất để gom RAM lại là khởi động lại máy chủ, rồi mới có thể chia RAM thành hugepage và gán 20G hugepage cho Oracle. Oracle rất thông minh, khi nó thấy có hugepage, nó sẽ tự động sử dụng hugepage, mà không cần phải cấu hình gì thêm.

Sau 20' chờ cho thằng Oracle nó dừng và đóng database lại, khách hàng cho phép tôi khởi động lại máy chủ. Máy chủ này nó khởi động cũng tương đối nhanh, chỉ mất chưa đầy 10' là đã xong rồi.

Việc đầu tiên phải làm là kiểm tra xem Linux đã chia RAM thành Hugepages chưa:
# cat /proc/meminfo | grep Huge
HugePages_Total: 82
HugePages_Free: 82
Hugepagesize: 262144 kB
Rồi đã có 82 hugepage đang nằm chờ thằng Oracle "sực". Tôi khởi động Oracle, và kiểm tra lại số lượng hugepage:
# cat /proc/meminfo | grep Huge
HugePages_Total: 82
HugePages_Free: 2
Hugepagesize: 262144 kB
Yahoooo! Oracle đã "ăn" mất 80 miếng hugepage x 256M = 20G, vừa bằng với cấu hình SGA của nó. Tôi báo cho khách hàng biết, kêu nhân viên của họ làm việc lại và tôi bắt đầu theo dõi xem hệ thống vận hành thế nào.


Thật là hồi hộp, không biết những điều chỉnh của tôi có hiệu quả hay không nữa. 10', 20', 30', 1 tiếng trôi qua, vmstat không thấy swap nữa rồi, top cũng không thấy kswapd nữa, toàn là Oracle, CPU idle 50%-60%, mọi thứ êm ru đến tận hôm nay!


Tôi đã từng làm rất nhiều case về performance tuning trên Linux nhưng chưa có lần nào thành công mỹ mãn như lần này, khi mà chỉ với vài dòng cấu hình đã đưa một máy chủ từ chỗ sống dở chết dở thành chạy trơn tru đến tận bây giờ, sau hơn 2 tháng mà vẫn chưa gặp sự cố nào khác. Tôi còn vui sướng hơn cả khách hàng của mình bởi lẽ nó giúp tôi lấy lại niềm tin sau nhiều lần làm performance tuning mà không thu được gì đáng kể.

Bài học rút ra từ case này: phải hiểu tận tường những công cụ mà bạn sử dụng nếu không có ngày nó sẽ gây hại khôn lường!

Tấn công DDoS bằng PDF Spam

Hôm nay tôi có một case khá thú vị. Một khách hàng gọi điện, báo server của họ đặt ở FPT Telecom (chỗ 64-66 Võ Văn Tần Q.3) bị phía FPT Telecom...tắt mất vì có quá nhiều traffic đi vào server này, có thời điểm lên đến 100Mbs. Họ nhờ tôi đến FPT Telecom trực tiếp kiểm tra xem nguyên nhân tại sao có quá nhiều traffic đến server.

Trên đường đi, tôi được biết server của khách hàng tôi không hề bị treo hay gặp vấn đề gì cả, chỉ có...firewall của FPT Telecom (nếu tôi đoán không lầm là Checkpoint trên Windows) lại bị treo khi phải tiếp nhận và xử lí lượng traffic lớn như thế; thành ra toàn bộ các server nằm phía sau con firewall này coi như bị cách ly với thế giới bên ngoài.

Bên FPT Telecom cũng đã thông báo cho khách hàng của tôi rồi, nhưng khách hàng của tôi lại không biết cách kiểm tra thế nào, thế mới xảy ra chuyện FPT Telecom buộc lòng tắt server và disable cái switch port luôn.

Đến chỗ FPT Telecom, đợi gần 15' đám
bảo vệ mới cho vào, rồi leo thang bộ lên đến tận tầng 5, tôi muốn ná thở vì còn phải vác theo cái balo to phía sau lưng. Đám FPT Telecom này đối xử với khách hàng lạ thật, nó bắt phải vào ngồi trong phòng server, chịu lạnh cũng như ồn kinh khủng.

Mở server lên, việc đầu tiên tôi làm là tìm hiểu xem server đang chạy các dịch vụ gì. Đây là server hosting, thành ra nó chạy toàn những dịch vụ phổ biến như named, apache, exim...Do tình trạng traffic đi vào ồ ạt rất giống với việc bị tấn công DDoS, nên tôi thử nhìn vào log của các dịch
vụ này xem có gì bất thường không.

Dịch vụ đầu tiên tôi coi là thằng apache. Toàn bộ log của nó chỉ có mỗi 40M; lước sơ qua nội dung log của một số website host trên server này, tôi cũng không thấy có dấu hiệu gì của một cuộc tấn công DDoS nhắm vào web-application.

Dịch vụ thứ hai tôi coi là thằng Exim. Chà, log của thằng này dữ dội hơn, riêng exim_rejectlog đã là hơn 72M chỉ trong ngày hôm đó. Tổng cộng log của nó là hơn 200M. Khách hàng cũng cho biết, mỗi ngày họ nhận được rất nhiều spam mail.

Do switch port của server đã bị disable, nên ngoài mấy cái log này ra, tôi chẳng thể biết được traffic đi đến server này là loại traffic nào. Do đó việc tiếp theo tôi làm là thuyết phục bên phía FPT Telecom enable lại switch port của server này.

Cũng may là tôi có quen với người chịu trách nhiệm ở FPT Telecom (do tôi từng giúp họ khắc phục một sự cố tương tự), nên sau một hồi thương thuyết, họ quyết định enable lại switch port của con server trong vòng 10', rồi sẽ disable tiếp cho đến khi nào tôi tìm ra nguyên nhân.

Hóa ra tôi chẳng cần đến 10'. Ngay khi switch port của server được enable lại, tôi liền chạy tcpdump để bắt các packet gửi đến server. Chà, mới chạy được chưa đầy 10 giây mà thằng tcpdump báo đã chụp được hơn 10.000 packet rồi. Nhiêu đây là đủ để coi rồi, nên tôi dừng tcpdump, và báo bên FPT Telecom disable switch port lại.

Tôi nối laptop vào console của server, download file dump về xem. Hmm mới snifff có chưa đầy 10 giây mà file này đã nặng gần 1,5M rồi. Mở nó lên bằng Wireshark, đập vào mắt tôi đầu tiên là có quá nhiều...ARP broadcast packet. Tiếp theo là SMTP, DNS rồi mới đến HTTP.

Thông tin netstat trên server cũng cho biết các connection chủ yếu đang được đổ dồn dập vào port 53 và port 25 từ nhiều nguồn IP khác nhau.

Hình ở trên là kết quả tôi sử dụng tính năng "Follow TCP Stream" của Wireshark đối với các packet của một SMTP connection. Có vẻ như ai đó đang hối hả gửi mail có attachment rất lớn đến server này.

Thông tin về DNS traffic cũng cho thấy, đa số các query đến named chạy trên server này là hỏi MX record của một số domain được đặt tại đây.

Để hoàn chỉnh, tôi tiếp tục lần theo dấu vết của HTTP traffic. Không có gì bất thường cả, có vẻ như nguyên nhân chính nằm ở SMTP và DNS rồi.

Dựa vào DNS, tôi liệt kê ra danh sách các domain đang bị gửi spam, và đề nghị khách hàng tôi tạm thời disable những domain này, không cho phép nhận mail nữa; rồi tôi yêu cầu bên FPT Telecom mở lại switch port, chạy tcpdump để coi traffic có tăng lên hay không.

May mắn quá, đúng như tôi dự đoán, tôi sniff gần cả phút mà chỉ thu được chưa đầy 500Kb. Tôi chờ thêm 20', bên FPT Telecom cho biết traffic đi đến server đã giảm hẳn. Mọi thứ đã trở lại bình thường.

Lục lọi thông tin trên server và đám packet bắt được bằng tcpdump, tôi thấy rằng attachment mà đám spammer đang cố gửi đến server toàn là mấy file PDF. Cách đây vài ngày Internet Storm Center cũng có cảnh báo về PDF Spam. Bản thân tôi mỗi ngày cũng nhận vài cái PDF spam này. Tuy vậy hệ thống của tôi cũng ổn, không gặp vấn đề gì.

Bài học rút ra từ case này: đừng bao giờ sử dụng Windows làm firewall ;).

Monday, July 23, 2007

VNNIC bán thông tin khách hàng cho spammer?

Liên tục trong tuần này tôi nhận được tổng cộng 5 email từ các công ty VDC Hà Nội, VDC Tp.HCM, PAVietnam và NetNam. Ngoại trừ một email có tiêu đề là "Thử phát nữa" (??!!) từ VDC Tp.HCM, tất cả các email còn lại đều...khuyên tôi nên chuyển các tên miền .vn tôi đang sở hữu ở VNNIC sang công ty của họ. Dĩ nhiên tất cả đều không quên quảng cáo về công ty cũng như dịch vụ "ưu việt" mà họ hứa hẹn sẽ cung cấp cho tôi, nếu tôi đồng ý với đề nghị của họ.

Đây rõ ràng là hành động spamming và các công ty kể trên chính là spammer, bởi lẽ tôi không muốn và không đăng ký để nhận email quảng cáo từ họ. Tuy vậy, chuyện các công ty kể trên đi spam khách hàng đã là chuyện thường ngày ở huyện, không có gì mới cả. Chuyện mới ở đây là tại sao các công ty này lại có thông tin về tên miền và địa chỉ email của tôi? Phải chăng VNNIC đã bán thông tin khách hàng cho spammer?

Sunday, July 22, 2007

Thư rác VN

VietnamNet vừa có đăng một bài nhan đề Thư rác Việt Nam vào thời "loạn"!
Dịch vụ gửi thư rác ở Việt Nam đã lên đến mức "chuyên nghiệp". Ngay tại Hà Nội, đã có hàng chục công ty công khai tên tuổi, danh tính tuyên bố sẵn sàng gửi thư rác thuê với số lượng hàng triệu e-mail mỗi ngày
Nhìn chung bài báo đưa ra được những cảnh bá
o cần thiết về tình trạng bùng phát của việc gửi spam ở VN. Tuy vậy tôi thấy có vài điểm cần bàn ở đoạn cuối của bài báo này:
Ai là người chịu thiệt?

Tất nhiên là người dùng! Năm 2005, một trong những nhà cung cấp dịch vụ Internet ở Việt Nam từng bị thế giới xếp vào danh sách có số lượng spam mail ở mức báo động, và các doanh nghiệp sử dụng dịch vụ của ISP này sau đó không thể gửi thư điện tử ra nước ngoài vì bị chặn. Đương nhiên người dùng mới là những người chịu thiệt đầu tiên.

"Thời gian gần đây, số thư rác tiếng Việt bùng phát gây ra những phiền toái và thiệt hại cho công ty chúng tôi rất nhiều, có hôm, cả cơ quan bị nghẽn mạng và không liên lạc qua email được vì webmail quá tải!" - Anh Việt - phó giám đốc công ty Vi...com.vn (Hà Nội) bức xúc.

Tuy không có thống kê cụ thể, nhưng tôi tin rằng số lượng spam tiếng Việt, hay nhằm để quảng cáo cho các sản phẩm, website của người Việt như bài báo này đề cập, chiếm một phần rất nhỏ, hầu như không đáng kể trong tổng số lượng spam của cả thế giới, mà theo Wikipedia, lên đến hơn 90 tỉ spam/ngày.

Vậy do đâu mà VDC từng bị Spamhaus đánh giá là một trong 10 ISP gửi spam nhiều nhất thế giới? Tôi nghĩ là do botnet. Rất nhiều máy tính ở VN đã bị biến thành zombie, thuộc các botnet nằm dưới sự quản lý của các tay bot herder nước ngoài. Khi các máy tính này bị sử dụng để gửi spam, các hệ thống anti-spam trên thế giới sẽ thấy spam này xuất phát từ VN, rồi tự động đưa VN vào blacklist.

Thật tế, trong quá trình triển khai hệ thống chống spam cho các khách hàng, tôi có làm thử một số thống kê về nguồn gốc của các spam này, kết quả là rất nhiều trong số đó xuất phát từ VN, mặc dù spam nằm trong inbox của khách hàng vẫn chỉ quanh quẩn..."enlarge..." với "from the desk of..." ;).

Cập nhật: Sophos vừa công bố danh sách 12 quốc gia spam-relaying đứng đầu thế giới:

Position Country Percentage of spam relayed
1United States

19.6%b
2China (including Hong Kong)

8.4%
3South Korea

6.5%
4Poland

4.8%
5Germany

4.2%
6Brazil

4.1%
7France

3.3%
8Russia

3.1%
9Turkey

2.9
10United Kingdom

2.8%
11Italy

2.8%
12India

2.5%
Others35.0%

Lưu ý là Sophos dùng từ "spam-relaying countries", chứ không phải "spamming countries". Những con số thống kê này cũng phần nào chứng minh được nhận định ở trên của tôi là hoàn toàn có cơ sở.

Tuesday, July 17, 2007

Dùng iptables NAT thay thế cho reverse proxy

Hôm rồi một khách hàng thông báo website của họ cứ chập chờn, lúc vào được, lúc lại không. Tôi vào kiểm tra thì thấy web-server của họ hoàn toàn ổn, duy một điều coi log lại không thấy kết nối nào đến được web-server cả. Loay hoay một hồi, khách hàng mới báo cho biết rằng họ có sử dụng một con squid làm reverse proxy đứng trước web-server, mục đích là để cache lại static content.

Tôi vào kiểm tra con squid này thì phát hiện trong log của nó phun ra khá nhiều lỗi. Google cho biết đây là những lỗi khá nghiêm trọng và cũng có đưa ra vài giải pháp, nhưng do tôi không có nhiều kinh nghiệm với squid thành ra loay hoay mãi mà vẫn không sao giải quyết được.

Tôi quyết định tạm thời stop con squid này lại, tìm một giải pháp thay thế. Ban đầu tôi định sử dụng Apache để làm reverse proxy do tôi có nhiều kinh nghiệm với thằng này. Tuy vậy, giải pháp này khá mất thời gian mà con reverse proxy này cũng sẽ bị "kết liễu" trong vài ngày tới, nên tôi quyết định sử dụng chức năng NAT của iptables để làm luôn cho gọn.

Thú thật là rất lâu rồi tôi không đụng đến iptables, nên tôi cũng mất gần 15' coi tài liệu mới nhớ lại cách làm. Tôi ghi lại ở đây để sau này có gặp sự cố tương tự thì có cách giải quyết nhanh:

iptables -t nat -A PREROUTING -p tcp --dport 80 -d 1.1.1.1 -i eth0 -j DNAT --to 2.2.2.2:80

iptables -t nat -A POSTROUTING -p tcp --dport 80 -o eth0 -j SNAT --to 1.1.1.1

Ghi chú:

- 1.1.1.1 là IP address của eth0 trên reverse proxy, 2.2.2.2 là IP address của eth0 trên web-server.

- 2 lệnh này được chạy trên reverse proxy và chúng chỉ "redirect" traffic đến cổng 80, nếu bạn cần redirect traffic đến các cổng khác như 443 chẳng hạn, bạn phải thêm vào các lệnh tương ứng.

- Lệnh số 1 có tác dụng chuyển destination IP address (hence DNAT) của tất cả TCP packet đến cổng 80 của IP 1.1.1.1 thành cổng 80 của IP 2.2.2.2. Lệnh này nằm ở chain PREROUTING, nghĩa là nó được apply trước giai đoạn routing.

- Lệnh số 2 có tác dụng chuyển source IP address (hence SNAT) của tất cả TCP packet đi ra bằng đường eth0 có destination port là 80 thành 1.1.1.1. Lệnh này nằm ở chain POSTROUTING, nghĩa là nó được apply sau giai đoạn routing.

Giải thích:

1. client 3.3.3.3 gửi một packet (src=3.3.3.3, dst=1.1.1.1) đến reverse proxy 1.1.1.1

2. Lệnh thứ nhất sẽ chuyển packet này thành (src=3.3.3.3, dst=2.2.2.2).

3. Lệnh thứ hai sẽ chuyển packet này thành (src=1.1.1.1, dst=2.2.2.2).

3. Sau khi web-server 2.2.2.2 nhận được packet này, nó sẽ tạo ra một packet (src=2.2.2.2, dst=1.1.1.1) và gửi lại cho reverse proxy 1.1.1.1.

4. reverse proxy 1.1.1.1 sẽ nhìn vào NAT table của lệnh thứ hai để chuyển packet này thành (src=2.2.2.2, dst=3.3.3.3)

5. reverse proxy 1.1.1.1 tiếp tục nhìn vào NAT table của lệnh thứ nhất để chuyển packet này thành (src=1.1.1.1, dst=3.3.3.3)

6. reverse proxy 1.1.1.1 gửi packet (src=1.1.1.1, dst=3.3.3.3) lại cho client 3.3.3.3

20 chai/tháng + 5% cổ phiếu dạng cổ đông chiến lược

(bạn Lê Quỳnh, phóng viên VNN, có hỏi ý tôi về việc đăng bài này lên VNN, và tôi đã đồng ý. Các bạn có thể xem ở http://vietnamnet.vn/giaoduc/2009/03/833719/).

Câu hỏi nào là khó trả lời nhất khi phỏng vấn xin việc? Không biết đối với người khác thì như thế nào, đối với tôi đó chính là câu "thế anh đề nghị mức lương bao nhiêu?".

Từ trước đến giờ, không kể các dạng làm theo hợp đồng, tôi có apply vào tổng cộng 3 công ty. Hầu như lần nào tôi cũng đề nghị một mức lương thấp hơn tôi dự tính rồi nhận một mức lương thấp hơn tôi xứng đáng được nhận.


Công ty đầu tiên đầu tiên của tôi là FPT Telecom, hồi cuối năm 2003. Lúc người phỏng vấn hỏi câu trên, tôi đã rất thành thật khai báo mất lương hiện tại của tôi là 2.500.000/tháng (lúc đó tôi làm cộng tác viên cho Tuổi Trẻ Online) và chỉ muốn nhận bằng khoản lương đó. Bài học đầu tiên: mỗi lần đổi công việc là mỗi lần phải được tăng lương, nghĩa là bạn phải yêu cầu một mức lương cao hơn công việc cũ, coi như là chi phí để làm quen với môi trường mới.

Công ty thứ hai là Mai Linh, đầu năm 2004. Lúc thỏa thuận vấn đề lương bổng, tôi đã không thống nhất một con số cụ thể mà lại chỉ thỏa thuận phần lương cứng quá thấp (còn thấp hơn ở FPT Telecom), phần còn lại tính theo từng dự án. Bài học thứ hai: nên thỏa thuận một con số cụ thể, chí ít con số này phải đủ nuôi sống bạn theo cách bạn muốn, trước khi bàn đến những nguồn thu nhập khác.


Công ty thứ ba cũng chính là công ty hiện tại, hồi cuối năm 2004. Lần này tôi đã có nhiều kinh nghiệm hơn rồi, thành ra lúc phỏng vấn, tôi đã mạnh miệng đề nghị một mức lương cao gần gấp ba so với mức lương ở công ty trước. Nếu bạn nghĩ bạn xứng đáng, hãy mạnh dạn đề nghị mức lương của mình, không có việc gì phải e dè cả.

Các sếp đồng ý với mức lương mà tôi đề nghị, dẫu vậy, họ yêu cầu trong thời gian thử việc, tôi chỉ nhận được 70% mức lương đó (và sau hơn 2 năm tôi mới được tăng lên đúng mức lương mà tôi đề nghị :-d). Bài học thứ ba: phải thỏa thuận thời gian thử việc là bao lâu để tránh trường hợp làm hoài mà lương không thấy tăng về mức thỏa thuận ban đầu.

Công ty hiện tại cũng cho tôi một bài học khác về việc tăng lương. Bài học thứ tư: phải thỏa thuận hoặc biết chính xác chính sách tăng lương và chế độ thưởng của công ty là như thế nào trước khi ký hợp đồng. Thường các công ty 6 tháng tăng một lần tùy theo từng đối tượng, cũng có công ty 3 tháng một lần và công ty 2 năm một lần như ở chỗ tôi đang làm . Còn thưởng thì vô chừng, nhất là đối với các công ty đã cổ phần hóa .

Một vấn đề nhỏ khác cũng cần phải lưu ý là khi thỏa thuận mức lương, bạn phải chắc chắn rằng đây là lương mà bạn sẽ được nhận, sau khi trừ đi tất cả các khoản khác như thuế thu nhập cá nhân, bảo hiểm y tế...

---

Từ đầu đến giờ tôi đề cập đến những kinh nghiệm rút ra được từ những lần thỏa thuận lương bổng mà chưa đề cập đến lý do tại sao trước đây khi đi phỏng vấn, tôi lại thường có xu hướng chọn mức lương thấp hơn dự tính. Tôi thấy đây không phải là vấn đề của riêng tôi, mà là vấn đề của khá nhiều người, nhất là những bạn chưa có kinh nghiệm đi làm.

Có lần tôi phỏng vấn một anh xin vào công ty của tôi, tôi hỏi anh câu hỏi trên, và nhận được câu trả lời thế này: "Lương đối với em không quan trọng lắm, quan trọng là được học hỏi, rèn luyện blah blah blah...".

Tôi đánh giá anh này thành thật nhưng hơi khờ. Nhà tuyển dụng sẽ không có thiện cảm với những người không đi làm vì tiền, bởi nó là một dấu hiệu của sự chưa trưởng thành. Nếu tiền đối với bạn không quan trọng, nhà tuyển dụng sẽ suy ra công việc đối với bạn cũng không quan trọng luôn, đơn giản vì mục tiêu lớn nhất của công việc là kiếm tiền.

Cứ so sánh thế này xem. Giữa một ông bố mỗi ngày phải chạy lo miệng ăn cho hai đứa con nhỏ và một anh sinh viên mới tốt nghiệp "tiền chả là cái đinh gì hết", ai sẽ làm việc chăm chỉ hơn?

Hơn nữa, trong mắt nhà tuyển dụng, những người trả lời theo kiểu trên thường là những người không có năng lực, hoặc không tự tin vào khả năng của họ, hoặc không biết được khả năng của họ đến đâu. Không có một doanh nghiệp nào muốn biến công ty của họ thành nơi thực tập miễn phí cho những người như thế cả.

Do đó, dẫu mục tiêu của bạn là học hỏi, rèn luyện kinh nghiệm (đây là một mục tiêu chính đáng), bạn vẫn phải quan tâm đến lương bổng nếu bạn muốn tìm được việc làm. Bạn phải chứng minh cho nhà tuyển dụng thấy rằng, bạn tự tin vào giá trị của mình thông qua mức lương mà bạn đề nghị.

--

Vậy đề nghị bao nhiêu là vừa? Tôi nghĩ mỗi người khi apply vào một công việc nào đó, cũng đã có sự lựa chọn mức lương cho mình, bằng cách tham khảo mức lương của các đồng nghiệp hoặc mức lương trung bình trên thị trường. Nói chung, nguyên tắc chủ đạo là: bạn phải cảm thấy vui vẻ và thoải mái với mức lương của mình.

Nếu bạn nhận một mức lương quá cao so với giá trị của bạn (điều này hiếm khi xảy ra, vì những lý do ở trên), vô tình bạn lại tự đặt áp lực lên bản thân. Tiền càng nhiều thì trách nhiệm càng cao mà bạn.
Khi bạn nhận một mức lương thấp hơn mong đợi, bạn sẽ khó có thể toàn tâm toàn ý hoàn thành công việc của mình. Có thực mới vực được đạo mà bạn.

Trong cả hai trường hợp này, cả bạn và nhà tuyển dụng đều gặp nhiều thiệt hại về mặt tinh thần và vật chất; do đó để tốt cho cả hai phía, bạn nên mạnh dạn đề nghị một mức lương giúp bạn thật sự cảm thấy vui vẻ và thoải mái.

--


Sở dĩ hồi trước tôi thường đề nghị mức lương thấp hơn tôi dự tính là vì lúc đó tôi vẫn chưa đủ tự tin vào bản thân mình. Còn bây giờ nếu phải đi xin việc, chắc chắn tôi sẽ đề nghị mức lương là title của entry này .

Không phải cứ "hàng khủng" là tốt

Cách đây hơn 2 tháng, một khách hàng của tôi có một project rất quan trọng: nâng cấp máy chủ database từ Oracle 9i lên Oracle 10g cho hệ thống core-banking của họ.

Mọi việc diễn ra tốt đẹp cho đến ngày đưa hệ thống vào production. Cứ chạy chừng 30' là con server "hàng khủng" 16 CPU Intel Itanium 2 + 32G RAM "sụm bà chè". CPU idle 0%, ssh vào còn không được, huống hồ chi là chạy Oracle. Họ liên hệ với tôi để tìm cách cứu chữa (tôi vốn có làm dự án core-banking này từ trước).

Việc đầu tiên tôi làm là...nhất nút reboot máy chủ. Dẫu biết đối với hệ thống database, việc hard reset như thế là điều tối kỵ, nhưng lúc đó quả thật tôi chẳng còn lựa chọn nào khác để giải thoát máy chủ ra khỏi tình trạng treo cứng, đành phải gửi trọn niềm tin vào Larry Ellison, hi vọng "bé" Oracle sẽ tự phục hồi sau khi reboot (thật ra vẫn còn một giải pháp dự phòng nếu Oracle không thể tự phục hồi được nên tôi mới tự tin vậy).

Sau khi reboot, tôi bắt đầu chuẩn bị một mớ công cụ cần thiết như top, vmstat, iostat, sar, oprofile; mở vài cái "tail -f" trên alert log của Oracle, đăng nhập vào Oracle Metalink...Xong xuôi, tôi bật Oracle lên lại và thử cho người dùng kết nối vào lại.

Chạy được đúng 20', server lại "hấp hối". top báo rằng CPU idle là 0%, trong đó iowait (iowait = network i/o + memory i/o + disk i/o) chỉ dao động từ 3-4%, user (các thao tác thuộc user space, Oracle process nằm ở đây) cũng chỉ tầm 5%-10%, còn lại tất cả tập trung dồn vào sys (các thao tác thuộc kernel space).
Trong danh sách process list của top, kswapd liên tục dẫn đầu. Đây là điều bất thường so với baseline của server này. Lẽ ra user phải chiếm đa số, kế tiếp là iowait, rồi mới đến sys.

Rồi server bắt đầu swapping đến chóng mặt. iowait tăng lên, sys vẫn không giảm, useridle luôn ở mức xấp xỉ 0%. Mà bạn biết rồi đó, một khi server đã swapping thì chẳng còn cách nào khác ngoài việc reboot nó. May mắn là tôi đã chuẩn bị sẵn lệnh shutdown Oracle trước khi quá muộn, thành ra lần này không cần reboot nữa.

Có hai câu hỏi được đặt ra:

- Tại sao sys lại chiếm đa số? kswapd đang làm gì?

- Tại sao với lượng RAM nhiều như thế mà iowait vẫn tăng lên và server bắt đầu swapping dữ dội?

----

Kinh nghiệm trong quá khứ làm việc với Oracle cho tôi biết rằng, mọi câu hỏi liên quan đến Oracle đều có thể được trả lời trong Oracle Metalink (nếu sếp của bạn bắt bạn sử dụng Oracle nhưng không mua account Metalink cho bạn, lời khuyên là hãy xin nghỉ việc càng sớm càng tốt :-d).

Tôi bắt đầu tìm kiếm với các keyword có thể nghĩ ra được. Mất gần 1h mò mẫm mà tôi vẫn chưa tìm được bất kì tài liệu nào đề cập đến hiện tượng giống với tình trạng hiện thời của tôi. Cũng may là lúc này đã qua giờ giao dịch rồi, nên thời gian cũng tương đối rộng rãi hơn. Tôi quyết định dành ra 30' nữa để tìm, trước khi tạo một service request yêu cầu sự hỗ trợ trực tiếp từ Oracle.

Ngoài tôi ra, các anh chị DBA cũng ra sức tìm kiếm. Thường trong trường hợp như thế này, tất cả sẽ join vào một conference để tiện việc trao đổi thông tin. Đây là việc làm rất có lợi và cần thiết, bởi lẽ các anh chị DBA thường không rành lắm về Linux, còn bản thân tôi cũng không có nhiều kiến thức về Oracle.

Trong số các tài liệu được các anh chị DBA gửi lên conference, tôi chú ý đến một tài liệu có tên như sau: How to Configure RHEL 4 32-bit for Very Large Memory with ramfs and HugePages Note:317141.1 Type: WHITE PAPER.

Chà, "very large memory", sao tôi không nghĩ đến keyword này nhỉ?

Lúc đầu tôi vẫn không nghĩ tài liệu này sẽ giải quyết được vấn đề, bởi lẽ nó ghi rõ ràng là 32-bit, trong khi hệ thống của tôi là 64-bit. Hơn nữa nếu tôi nhớ không lầm, HugePages chỉ có tác dụng cho hệ thống 32-bit mà thôi. Tuy thế, tôi vẫn mở nó ra xem; dẫu gì nãy giờ cũng tiêu tốn nhiều thời gian rồi, tốn thêm một chút nữa cũng không sao :-p.

Điều đầu tiên tôi nhìn thấy trong tài liệu là dòng:
This document aims to guide Linux system administrators on Red Hat Enterprise Linux 4.0 to configure Very Large Memory and big SGA for Oracle RDBMS with ramfs and hugepages

The configuration provided in this document applies strictly to 32-bit Linux. For HugePages on 64-bit Linux, see Note 361468.1

Chà, nó ghi là nếu muốn tìm hiểu về HugePages trên Linux 64-bit thì coi cái Note:361468.1. Như vậy có nghĩa là vẫn có thể áp dụng được HugePages cho 64-bit Linux àh? Tôi nhanh chóng tải cái Note:361468.1 về và quả thật, nó chính là thứ tôi cần tìm!

Hóa ra tôi hiể nhầm về HugePages thật:
HugePages is a feature of the Linux kernel which allows larger pages to manage memory as the alternative to the small 4K pagesize. For a detailed introduction, see Note 361323.1.

There is a general misconception where the HugePages is a feature specific to 32-bit Linux. This document focuses on uses of HugePages on 64-bit Linux platforms.
Phần cuối của tài liệu này trông có vẻ rất promising:
Why HugePages Should Be Used on 64-bit Linux?

* Very Large Memory: The 64-bit systems do have VLM. So the general VLM issues apply.

* Not swappable: HugePages are not swappable. Therefore there is no page replacement mechanism overhead. HugePages are universally regarded as pinned.

* Eliminated page table lookup overhead: Since the pages are not subject to replacement, page table lookups are not required.

* Faster overall memory performance: On virtual memory systems each memory operation is actually two abstract memory operations. Since there are less number of pages to work on, the possible bottleneck on page table access is clearly avoided.

* kswapd: kswapd will get very busy if there is a very large area to be paged (i.e. 13 million page table entries for 50GB memory) and will use an incredible amount of CPU resource. When HugePages are used, kswapd is not involved in managing them.
Có vẻ như tôi đang đi đúng hướng rồi. Tôi quyết định đọc lại về HugePages để hiểu rõ hơn về nó. Một điều may mắn là trước đây tôi có đọc rất kĩ về phần memory management của Linux kernel trong cuốn Understanding The Linux Kernel, thành ra tôi không mất nhiều thời gian lắm để hiểu rõ HugePages.

(còn tiếp)

Một phương pháp chống DDoS bằng xFlash

Ý tưởng

Dựa vào gợi ý của Amit Klein:

Notice the first limitation of the technique - it states that no raw CR and LF can be placed in the body section. This means that the technique cannot be used to send (POST) requests whose body complies with the "multipart/form-data" content-type format (this format uses raw CRs and LFs to mark headers and boundaries). In other words, a (POST) request whose body is a valid "multipart/form-data" stream is guaranteed (as far as today's knowledge extends) not to be sent from a Flash player. Web application authors can therefore use HTML forms whose ENCTYPE attribute is set to "multipart/form-data", and enforce that the submission contains a valid multipart/form-data body. Once these mechanisms are in place, and a request passes through, it is known not to originate from a Flash player, so the attack
described here is irrelevant.
Gợi ý ở trên có thể được diễn giải như sau:
  • Cách thức browser xử lí các HTML form có enctype = "multipart/form-data" và enctype = "application/www-urlencoded" (default) hoàn toàn khác nhau. Điểm khác nhau đặc trưng là khi submit (nghĩa là tạo ra POST request) form "multipart/form-data", browser sẽ tự động set Content-type là "multipart/form-data", còn khi submit các form khác, browser sẽ sử dụng Content-type là "application/www-urlencoded".
  • Flash (với các hàm thường được sử dụng để DDoS như LoadVars, GetURL hay SendtoURL, etc...) không thể gửi POST request theo định dạng "multipart/form-data". Đây chính là "gót chân Asin" của Flash.
  • Do đó nếu bằng một cách nào đó, ta có thể set tất cả các form thành enctype = "multipart/form-data", nghĩa là ép tất cả POST request có Content-type là "multipart/form-data", ta sẽ có thể phát hiện ra những POST request xuất phát từ Flash, vốn dĩ luôn có Content-type là "application/www-urlencoded".
Hiện thực

Để hiện thực hóa ý tưởng này, ta cần phải có một cách nào đó biến tất cả các HTML form thành enctype = "multipart/form-data", rồi sau đó phải chỉnh sửa lại server-side code để xử lí các form này (tin vui: thử nghiệm với một vài ngôn ngữ lập trình phổ biến như PHP, Java và Ruby, tôi thấy rằng không cần phải chỉnh sửa server-side code, các ngôn ngữ này đều có cách thức xử lí giống nhau với hai loại enctype của HTML form).

Vậy nhiệm vụ còn lại là điều chỉnh HTML form. Cách dễ thấy nhất là sửa code HTML. Phần còn lại của bài này tôi trình bày một cách khác, không cần chỉnh sửa code HTML. Đó là sử dụng output filter của Apache 2.x.

Ý tưởng cơ bản là triển khai một cái reverse proxy bằng Apache 2.x, đứng trước tất cả các server cần được bảo vệ khỏi xFlash. Trên cái reverse proxy đó, ta sẽ sử dụng một output filter module làm nhiệm vụ tự động thêm attribute enctype="multipart/form-data" vào tất cả các HTML form mà nó thấy.

Ban đầu tôi tính viết riêng một cái Apache 2.x module để làm chuyện này, nhưng rồi vô tình phát hiện ra có sẵn một module đã làm chuyện đó rồi. Đó là module mod_line_edit:
mod_line_edit is a general-purpose filter for text documents. It operates as a simple on-the-fly line editor, applying search-and-replace rules defined in a configuration or .htaccess file.
Để sử dụng mod_line_edit, trước tiên bạn cần phải biên dịch nó. Có hai cách biên dịch: biên dịch mod_line_edit thành một module tĩnh hoặc thành một module động (DSO). Nói chung để tối ưu hóa tốc độ xử lý, nên biên dịch mod_line_edit thành một module tĩnh theo cách sau đây:

server$ cd /usr/local/src
server$ wget http://www.tux.org/pub/net/apache/dist/httpd/httpd-2.2.4.tar.gz
server$ wget http://apache.webthing.com/mod_line_edit/mod_line_edit.c
server$ tar -xzf httpd-2.2.4.tar.gz

server$ mkdir -p httpd-2.2.4/modules/line_edit
server$ cp mod_line_edit.c httpd-2.2.4/modules/line_edit
server$ cp httpd-2.2.4/modules/echo/Makefile.in httpd-2.2.4/modules/line_edit
server$ cd httpd-2.2.4/
server$ "./configure" \
"--prefix=/opt/httpd" \
"--with-module=line_edit:mod_line_edit.c"

Cấu hình mod_line_edit cực kì đơn giản. Đầu tiên thêm hai dòng này vào httpd.conf để kích hoạt mod_line_edit:
FilterProvider textedit line-editor resp=Content-Type $text/
FilterChain textedit
Để mod_line_edit tự động thêm attribute enctype="multipart/form-data" vào tất cả các HTML form, thêm dòng sau đây vào nơi thích hợp (virtual host, location, etc...)
LERewriteRule '(<>' '$1 enctype="multipart/form-data">' Ri
Rồi xong, tất cả các form HTML của bạn sẽ tự động có enctype = "mutilpart/form-data". Nghĩa là POST request của bạn sẽ luôn có Content-type là "multipart/form-data".

Việc còn lại là cấu hình mod_security để nó phát hiện và loại bỏ các POST request có Content-type là "application/www-urlencoded" xuất phát từ xFlash. Tôi dành phần này lại cho các bạn tự làm.

Ưu điểm và nhược điểm


Phương thức mà tôi trình bày ở trên có những ưu điểm nhất định so với các phương thức phổ biến hiện nay:
  • Thứ nhất, do phương thức này đánh vào "gót chân Asin" của xFlash nên bạn không cần thay đổi cấu hình mà vẫn có thể phát hiện được xFlash dẫu kẻ tấn công có thay đổi nơi chứa xFlash hay thay đổi mục tiêu tấn công.
  • Thứ hai, nếu áp dụng theo mô hình reverse proxy, bạn sẽ có thể cùng một lúc bảo vệ được nhiều web-server bên trong khỏi xFlash, rất thích hợp với các hosting provider.
Tuy vậy, phương thức này cũng có những nhược điểm:
  • Thứ nhất, nó chỉ chống được thế hệ xFlash hiện tại. Theo nghiên cứu của riêng tôi, Flash, cụ thể là Flash Player 9 với ActionScript 3, cực kì nguy hiểm. Cách làm này sẽ không thể chống được thế hệ xFlash mới được phát triển dựa trên tính năng của ActionScript 3. Ngoài ra, nếu kẻ tấn công biết cách khai thác các lỗ hổng của Flash 9 trở về trước, phương thức này cũng sẽ trở nên vô tác dụng.
  • Thứ hai, nó chỉ phát hiện và chống được POST request từ xFlash. Theo anh con-ma-le cho biết, một số biến thể xFlash hiện tại chỉ chơi GET request mà thôi.
  • Thứ ba, đối với những website có áp dụng AJAX, phương thức này có khả năng sẽ gây ra false positive. Lý do là XMLHTTPRequest của Javascript cũng gửi POST request có Content-type là "application/www-urlencoded". May mắn là tất cả các AJAX framework mà tôi biết đều có khả năng thêm custom header vào HTTP request, do đó bạn có thể nhìn vào header này để phân biệt giữa xFlash và AJAX.
  • Thứ tư, với cái rule của mod_line_edit ở trên, website của bạn có nguy cơ không còn tuân theo chuẩn của W3C nữa. Ví dụ như nếu một webpage của bạn đã có sẵn enctype = "multipart/form-data", khi mod_line_edit thêm vào một attribute tương tự, webpage này sẽ không còn đúng chuẩn W3C.
Kết luận

Phương thức này không phải là "silver bullet" có thể giải quyết dứt điểm xFlash. Tuy vậy nó cũng có khả năng hạn chế được sức tàn phá của thế hệ xFlash hiện tại. Tôi nghĩ chỉ có hai cách có thể giải quyết dứt điểm xFlash:
  • Không sử dụng Flash. Nếu bạn hiểu rõ Flash nguy hiểm đến cỡ nào, hoặc nếu bạn tin tưởng tôi, tôi khuyên bạn không nên sử dụng Flash hoặc it nhất mặc định là không cho chạy Flash, rồi có thể enable theo từng website cụ thể. NoScriptFlashBlock có thể giúp bạn làm chuyện này dễ dàng!
  • Đừng cố chống xFlash bằng cách nhìn vào các đặc trưng của nó. xFlash hoàn toàn có thể tạo ra những request giống y những request hợp lệ. Hãy chống xFlash như chống các loại DDoS khác, nghĩa là: a) đầu tư vào cơ sở hạ tầng, bao gồm hệ thống server, đường truyền và con người; b) tối ưu hóa hệ thống, đảm bảo tốc độ xử lí tốt nhất với chi phí bỏ ra; c) thiết kế hệ thống thật scalable, bởi xét cho cùng, bị xFlash tấn công cũng tương tự như lượng user của bạn tăng lên đột biến.

Where are Vietnamese hackers/security researchers?

From rd of VnSecurity:
So the Call for Papers of VNSECON 07 has been closed last week. The technical committees of VNSECON 07 now are looking over all the submissions. The final technical program would be announced sometimes at the beginning of next week and there are some really interesting topics which I love to hear.

I'm kind of disappointed that so far we've only received 03 submissions from Vietnamese (two of them are VNSEC members and one from a student in Hanoi). These submissions are quite ok and I would love to see more submission from Vietnam. We may consider extending 1 - 2 more weeks for submissions on both Technical and Business tracks (see below) for Vietnamese only. So if you want to have a chance to talk about your security experience/research this August in Ho Chi Minh City, please submit your proposal to cfp-AT-vnsecurity.net.

DDoS Attacks and Countermeasures

Tôi mới làm xong cái slide nói về đề tài trên. Mặc dù bàn về DDoS nhưng cũng có nhiều thông tin về xây dựng hệ thống sao cho đảm bảo về performance và scalability. Tôi sẽ trình bày về đề tài này vào lúc 9h sáng 09/06/2007, tại Lầu 2 - Nhà Hàng LION – 11C Công Trường Lam Sơn, Q.1.




Giao diện mới của www.tuoitre.com.vn

Trang www.tuoitre.com.vn mà tôi đã thử mổ xẻ lần trước vừa mới thay đổi giao diện. Theo nhận xét của riêng tôi, giao diện mới của www.tuoitre.com.vn là hay nhất trong các website tin tức phổ biến ở VN, mặc dù vẫn còn vài chỗ chưa được.

Do lần trước tôi chê hơi bị nhiều, lần này tôi sẽ nói về hai vấn đề thôi: điều tôi thích nhất và điều tôi ghét nhất ở giao diện mới này.

Thích nhất: navigation bar nằm ngang



Điều tôi ứng ý nhất ở giao diện mới này chính là nagivation bar được chỉnh sang nằm ngang. Người thiết kế www.tuoitre.com.vn đã mạnh dạn (và hoàn toàn chính xác) khi vượt qua khỏi lối mòn thiết kế navigation bar nằm dọc của hầu như tất cả các trang tin ở VN (có lẽ tất cả đều cố gắng bắt chước VnExpress). Có nhiều lợi ích khi chuyển navigation bar sang nằm ngang:

Thứ nhất,
navigation bar nằm ngang sẽ tách rời hoàn toàn so với nội dung của website, nó giúp người dùng nhanh chóng nhận ra được những đề mục chính mà website này cung cấp.

Navigation bar là một phần quan trọng của website, nhưng nó không phải là nội dung, mà chỉ là công cụ, dùng để hỗ trợ người dùng duyệt website dễ hơn. Do đó, nó cần phải được tách ra khỏi nội dung.

Thứ hai, sẽ có nhiều chỗ trống hơn cho những nội dung chính. Trong một website, phần quan trọng nhất là góc nhìn bên trái, từ logo trở xuống. Đó là nơi mà người dùng nhìn vào đầu tiên khi họ truy cập vào một website nào đó (trừ những người đọc từ phải sang trái).

Ở giao diện cũ của www.tuoitre.com.vn cũng như giao diện của vnexpress.net hay www.thanhnien.com.vn, nơi "tấc đất tấc vàng" đó được dành cho navigation bar.



Như tôi đã nói ở trên, navigation bar chỉ là công cụ, nó không thể quan trọng bằng nội dung chính của website, thành ra ở vị trí mặt tiền đó, tốt nhất là dành cho tin nổi bật nhất, như cách làm của www.tuoitre.com.vn hiện tại.

Thứ ba, navigation bar được thiết kế theo dạng tab, với hai cấp trên dưới. Cách thiết kế tab này rất hay ở chỗ:
  • nó đơn giản, dễ hiểu, nhìn vào là biết ngay chức năng của nó là gì.
  • dễ click trúng . Thật tế, tôi thường xuyên click trật vào các đề mục ở giao diện cũ của www.tuoitre.com.vn vì nó quá nhỏ và quá gần nhau.
Tuy nhiên, người thiết kế www.tuoitre.com.vn lại có một vài lỗi nho nhỏ trong cách thiết kế tab này. Ví dụ như về màu sắc, tab đang được chọn chưa được tô màu để nổi bật hơn hẳn những tab khác, và thể hiện sự liên kết với những đề mục nhỏ hơn hiện ra bên dưới. Nhìn hình bên dưới bạn sẽ hiểu ý tôi muốn nói:



Ngoài ra chẳng hiểu tại sao, khi tôi duyệt bằng Firefox trên Linux, đôi khi mấy cái tab lại biến mất, ví dụ như hình này nè:




Ghét nhất: trang chủ quá ầm ĩ!

Thật không thể hiểu nổi tại sao www.tuoitre.com.vn lại đưa một clip video vào trang chủ của mình. Có quá nhiều điều không được về cách làm này:

Thứ nhất, nó quá 1990s. Tôi thật sự nhớ lại trang web đầu tiên tôi làm, tôi cũng chèn nhạc vào đó, rồi còn dùng ba cái javascript màu mè hoa lá cành nữa. Bây giờ chẳng ai làm kiểu đó nữa cả, ngay thằng youtube.com là website chia sẻ video mà trang chủ của nó, hay bất kì trang nào khác, cũng không tự động la ầm ĩ nếu người dùng không muốn. Ít nhất phải hỏi ý kiến của tôi chứ, sao tự nhiên lại la ầm ĩ lên như vậy?

Thứ hai, tôi muốn im lặng, tôi muốn im lặng và tôi muốn im lặng!!! Trời ơi, thử tưởng tượng, nửa đêm, cả nhà đang ngủ, tự nhiên bị đánh thức chỉ vì tôi vào www.tuoitre.com.vn đọc tin!

Thứ ba, nó làm thời gian load trang chủ của www.tuoitre.com.vn tăng lên đột biến. Mặc dù tôi đã tắt nhấn nút stop, không cho nó chiếu cái video, thằng Firefox cứ báo là nó đang load, làm tôi vừa tốn đường truyền vô ích, vừa phải tự hỏi, ủa còn nội dung gì chưa hiển thị ra ta? Don't make me think, please!

Tổng kết

Nhìn chung, giao diện này là một bước tiến đáng kể của www.tuoitre.com.vn, khi mà những cái hay nhiều hơn hẳn những cái dở. Hi vọng ban biên tập www.tuoitre.com.vn sẽ nhanh chóng gỡ bỏ cái video khỏi trang chủ, hay ít nhất, người dùng click vào thì mới play.

designing the obvious


Đợt đi chơi vừa rồi tôi mua được 5 cuốn sách:

* 2 cuốn về web design: css masterydesigning the obvious

* 2 cuốn về security: the oracle hacker's handbookreversing: the secrets of reverse engineering

* 1 cuốn tôi chẳng biết xếp vào đâu: building scalable web sites

Mỗi cuốn tôi mua dành cho một mục đích khác nhau. Cuốn css mastery là dành để tặng bạn gái, hi vọng em sẽ nhanh chóng hiểu được css và xhtml, haha lúc đó tôi tha hồ...lợi dụng, nhờ thiết kế giùm mấy cái dự án của tôi. Cuốn oracle là dành cho công việc, hiện tại tôi có rất nhiều thứ phải làm liên quan đến thằng oracle này. Cuốn building scalable web sites dành cho tương lai một vài tháng tới, nếu dự án bán áo thun của tôi thành công, tôi sẽ cần đến nó. Ngoài ra tôi nghĩ nó cũng sẽ giúp ích một phần nào đó khi đi tư vấn cho mấy cái hệ thống LAMP. Cuốn reversing dùng để giải trí là chính.


Chỉ mỗi cuốn designing the obvious là tôi mua mà không có mục đích gì hết, chỉ vì thấy nó thiết kế đẹp và đọc thử thấy nó nói cũng hay nữa. Vậy mà nó là cuốn tôi đọc xong đầu tiên. Rất đáng đồng tiền bát gạo!

designing the obvious nói về cách thiết kế website sao cho nó...obvious, tạm dịch là hiển nhiên. Nó bàn đến một vấn đề mà tôi đã quan tâm từ lâu nhưng chưa có dịp tìm hiểu kĩ: usability, tạm dịch là tính khả dụng, của một website. Mục tiêu chính của cuốn sách là hướng dẫn designer thiết kế ra những website thiệt hiển nhiên, rõ ràng, rành mạch, và đừng bao giờ bắt khách hàng phải suy nghĩ!


Tuy chủ đề chính là thiết kế website, nhưng tôi cảm nhận mục tiêu cốt lõi của designing the obvious là dạy cho tất cả chúng ta cách thiết kế những sản phẩm đơn giản, dễ dùng mà hiệu quả. Sản phẩm ở đây bao gồm tất cả những thứ mà con người có thể sản xuất ra được, ví dụ như cái entry này, một website bán hàng, một chiếc xe đạp hay một cái tivi chẳng hạn.

Make everything as simple as possible, but not simpler. Đây là câu nói nổi tiếng của Abert Einstein và đó cũng chính là ý tưởng chủ đạo mà designing the obvious muốn truyền tải đến người đọc.


Thật tế đọc xong cuốn này, tôi chưa thiết kế được gì cả nhưng bây giờ nhìn đâu mình cũng thấy những sự rối ren, phức tạp không đáng có. Há há, tự nhiên trở thành "chuyên gia" usability.


Ví dụ như hôm rồi đi đăng kí visa debit card. Tôi đăng kí ở hai ngân hàng, ACB và Eximbank. Và cả hai lần, Tôi đều phải hỏi đi hỏi lại nhiều lần em teller mới biết cách điền mấy cái form, đơn giản vì chúng nó quá non-obvious! Có quá nhiều thuật ngữ chuyên ngành trong mấy cái form đó, ví dụ như "tài khoản ghi có" hay như "mở tài khoản CiF".

Mấy cái form này cũng không đồng nhất. Ví dụ như cùng một câu hỏi về CMND, có form thì hỏi luôn nơi cấp, có form chỉ cần số CMND và ngày cấp. Đây là những điều rất nhỏ nhưng chúng làm cho tôi bận tâm, ủa tôi có điền thiếu không ta, sao mấy chỗ này không giống nhau?


Đừng bao giờ bắt khách hàng phải suy nghĩ! Đó cũng là tên của một cuốn sách khác thuộc hàng bestseller về web usability: don't make me think. Ngày mai tôi sẽ mua cuốn này luôn, hi vọng nó cũng hay và bổ ích như designing the obvious.

Cập nhật: tôi đã đọc don't make me think rồi, cảm nhận ban đầu là nội dung khá giống như designing the obvious nhưng nó cô đọng, xúc tích nên có vẻ chán hơn. Tôi sẽ đọc lại một lần nữa, hi vọng rút ra được điều gì đó.

WordPress 2.1.1 chứa mã nguy hiểm

Một tay hacker xâm nhập vào máy chủ của Wordpress và sửa mã nguồn của phiên bản 2.1.1 để gài vào một backdoor cho phép thực thi mã PHP từ xa:

This morning we received a note to our security mailing address about unusual and highly exploitable code in WordPress. The issue was investigated, and it appeared that the 2.1.1 download had been modified from its original code. We took the website down immediately to investigate what happened.

Ai viết 2.6.20?

LWN.net vừa trả lời một cách xuất sắc cho câu hỏi thường gặp: ai viết code cho Linux? Hóa ra phần lớn mã nguồn của Linux được đóng góp bởi lập trình viên làm việc cho các tập đoàn như Red Hat, IBM, Google và cả Nokia. Bài viết kết luận:

The end result of all this is that a number of the widely-expressed opinions about kernel development turn out to be true. There really are thousands of developers — at least, almost 2,000 who put in at least one patch over the course of the last year. Linus Torvalds is directly responsible for a very small portion of the code which makes it into the kernel. Contemporary kernel development is spread out among a broad group of people, most of whom are paid for the work they do. Overall, the picture is of a broad-based and well-supported development community.

Tự làm một distro Linux

Khi mới tìm hiểu Linux, tôi đã luôn thắc mắc không biết người ta tạo ra một distro như thế nào. Tôi nghĩ chắc hẳn đó phải là một công việc hết sức phức tạp, đòi hỏi nhiều kĩ năng cao cấp mà chỉ những người sử dụng Linux lâu năm mới làm được. Và dĩ nhiên, chắc hẳn bạn cũng biết, tôi đã luôn ao ước một ngày nào đó có thể tự tay mình tạo ra được một distro.

Tôi bắt đầu bằng Linux from scratch. Chà, có vẻ cũng dễ nhỉ, cứ việc làm theo những gì trong sách viết là xong. Nhưng nếu làm thủ công như thế này thì làm sao có thể sản xuất đại trà được nhỉ? Có cách nào làm tự động không ta? Chẳng hạn như tôi chỉ cần đóng gói các software lại, đưa chúng vào để chung trong một thư mục, bấm một nút hay chạy một lệnh là nó sẽ tự động tạo ra cái distro với đầy đủ bộ cài đặt và tài liệu đính kèm. Có ngay rBuilder Online!

Có thể nói rằng công nghệ hay nhất mà tôi học được trong năm 2006 chính là công nghệ do rPath cung cấp thông qua rBuilder Online. Một công nghệ tuyệt vời giúp bạn có thể tạo ra được một distro trong nháy mắt với vài cái click chuột. Nhưng đã có quá nhiều distro tốt rồi, tạo thêm nữa chi cho phí thời gian? Chính xác. Rất ít người sử dụng rBuilder Online để làm distro mà chủ yếu tập trung vào xây dựng các software appliance. Software appliance thật ra cũng là distro nhưng nó khác với distro ở chỗ nó được tối ưu hóa để chạy một hoặc một nhóm nhỏ các phần mềm chuyên dụng mà thôi. Ví dụ như LAMP Appliance là một software appliance chỉ có chứa bộ stack Linux, Apache, MySQL và PHP giúp bạn có thể chạy các web-app được xây dựng dựa trên technology stack này. Hay như SugarCRM, AsteriskNow, MediaWiki...là những software appliance được xây dựng để chỉ chạy các phần mềm tương ứng.

Khi sử dụng software appliance, hệ điều hành trở nên trong suốt với người sử dụng. Bạn sẽ không cần quan tâm đến hệ điều hành nữa mà chỉ cần tập trung vào ứng dụng ở bên trên đó. Đây chính là ý tưởng chủ đạo của khuynh hướng the application without the operating system. Khi đã có trong tay một software appliance, bạn có rất nhiều cách để sử dụng software appliance đó:
  • cài nó lên máy chủ của mình như một distro bình thường. Đây là cách thường làm của các doanh nghiệp.
  • biến nó thành một hardware appliance. Đây chính là cách kiếm tiền của các công ti sản xuất và bán thiết bị phần cứng.
  • biến nó thành một virtual appliance. rPath hỗ trợ cả VMWare và Xen. Như tôi đã nói ở lần trước, virtual appliance chắc chắn là xu hướng chủ đạo trong việc xây dựng hệ thống thông tin của các doanh nghiệp. Năm 2007 sẽ là năm của virtual appliance.
Nào còn chờ gì nữa? Hãy nhanh chân tìm hiểu công nghệ của rPath!

Phần thưởng nào dành cho người làm bảo mật?

Nên đọc bài này nếu bạn có ước muốn trở thành chuyên gia bảo mật:
One of the problems with the field of Information Security, particularly secure application development, is that it is not an inherently rewarding practice. Development is a rewarding practice when you add new functionality, or make existing processes easier to use or more efficient.

The really dangerous part of this lack of reward is that hacking is inherently rewarding for those with that mindset. I've told co-workers many times that if I didn't really have a concern with the legality or the morality of it, (we won't get into whether Robin Hood was virtuous or not), I would probably want to be a hacker. In a development world, or even in support of a development world, you're driven by project deadlines and feature sets that the users covet. Security is (generally) an afterthought. In the black hat world, unless you're being directly paid for something you're supposed to produce ultimately, you're driven by your own creativity and your own ability to come up with an effective attack, and to do so without being caught, and before everybody else does.

To me, the second sounds very rewarding. In the former, you're paid to implement somebody else's creativity, and on their timeline, etc. In the latter, you're driven by the good idea. - new and crazy ideas are rewarded, not dismissed.
Đây chính xác là những gì tôi cảm nhận được sau hơn hai năm làm việc như một người gác cổng. Nếu cho rằng sự tín nhiệm của sếp và lương bổng là phần thưởng lớn nhất của một người đi làm thuê thì chắc chắn rằng phần thưởng của tôi phần nhiều không đến từ công tác bảo mật. Bảo mật là một công tác quan trọng, sếp của tôi hiểu điều đó nhưng rõ ràng những gì mà công tác này đem lại cho công ty là hết sức mơ hồ. Tôi đã ngăn chặn được bao nhiêu vụ tấn công? Mỗi vụ tấn công đó nếu xảy ra sẽ làm cho công ty mất bao nhiêu tiền? Thật khó mà đưa ra một con số cụ thể.

Nếu ta chia nhỏ người làm bảo mật ra hai nhóm, nhóm chuyên thực hiện công tác bảo vệ và nhóm chuyên thực hiện công tác tấn công, thì công việc của nhóm đầu cũng không đem lại nhiều pleasure như công việc của nhóm sau. Ví dụ như triển khai mod_security sẽ không hấp dẫn bằng việc tìm và khai thác XSS, CSRF hay SQL Injection. Hay triển khai SELinux sẽ không thú vị bằng việc phát hiện và khai thác lỗi tràn bộ đệm trong một phần mềm mà công ti bạn đang sử dụng hoặc phát triển. Nhóm tấn công cũng dễ có nhiều credit hơn là nhóm bảo vệ, bởi lẽ họ chứng minh được hiệu quả thực tế công việc của họ (bằng cách tìm ra lỗi và khai thác chúng). Tôi kiêm nhiệm luôn hai công việc này và kinh nghiệm cho thấy sếp quan tâm đến những lỗ hổng mà tôi tìm thấy hơn là những giải pháp mà tôi sẽ triển khai để đề phòng các tấn công sẽ xảy ra (hoặc không bao giờ xảy ra).

Trong thực tế, phần thưởng của tôi phần nhiều đến từ những dự án hoàn toàn không liên quan gì đến bảo mật. Đó là những dự án xây dựng và triển khai hệ thống thông tin, những dự án tạo ra được một kết quả cụ thể mà sếp và sếp của sếp có thể thấy được. Đây cũng là điều dễ hiểu, nó cho thấy quan điểm bảo mật là một vấn đề kinh tế của Bruce Schneier là hoàn toàn có cơ sở. Nếu sếp tôi chỉ trả tiền để tôi bảo vệ những hệ thống có quá nhiều lỗ hổng, rõ ràng sếp tôi chỉ đang làm giảm nhẹ cái risk của công ti hơn là giải quyết vấn đề thực sự: xây dựng được hệ thống an toàn ngay từ đầu. Đây mới chính là nhiệm vụ của người làm bảo mật. Bảo mật không thể là một qui trình đi sau qui trình phát triển sản phẩm hay xây dựng hệ thống, bảo mật phải diễn ra song hành cùng các qui trình này. Nghĩa là bạn, một chuyên gia bảo mật, phải giúp cho sếp của bạn xây dựng được những hệ thống thông tin an toàn, hiệu quả và kinh tế ngay từ đầu. Lúc đó khả năng của bạn mới được phát huy tối đa và lẽ dĩ nhiên, phần thưởng của bạn cũng sẽ rất xứng đáng.

-Thái

ADSL DoS

Trong bài trước tôi có nói về ý tưởng làm luận văn tốt nghiệp với đề tài bàn về những điểm yếu trong cơ sở hạ tầng mạng có thể ảnh hưởng đến sự an toàn của người sử dụng Internet ở VN. Trong bài này tôi sẽ trình bày một điểm yếu nhỏ trong dịch vụ ADSL hay Cable Internet -1- của các ISP. Tận dụng điểm yếu này, bạn có thể tấn công theo kiểu từ chối dịch vụ, ngăn cản một người nào đó sử dụng dịch vụ ADSL khi bạn biết được địa chỉ MAC -2- của họ.

Tôi đã kiểm tra và xác nhận lỗ hổng này tồn tại trong dịch vụ Cable Internet của SCTV. Tôi chưa kiểm tra các ISP khác như FPT, MegaVNN hay Vietel nên không biết liệu họ có bị vấn đề này hay không. Nếu có điều kiện, tôi sẽ kiểm tra thử và cập nhật trên blog này.

Theo tôi được biết, tất cả các nhà cung cấp dịch vụ ADSL ở VN đều sử dụng giao thức PPPoE - Point to Point Protocol Over Ethernet để kết nối máy tính của bạn vào hệ thống mạng của họ. PPPoE, được miêu tả trong RFC 2516, là giao thức cho phép truyền frame PPP qua mạng Ethernet bằng cách nhúng frame PPP vào frame Ethernet. Sở dĩ các ISP đều sử dụng PPPoE vì họ muốn tận dụng lại hệ thống trang thiết bị đã được xây dựng để phục vụ cho mạng Dial-Up, vốn dĩ sử dụng giao thức PPP. Một frame Ethernet có cấu trúc như sau:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR
| (6 octets)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR
| (6 octets)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~
~ payload
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trong đó phần payload sẽ có cấu trúc như sau nếu nó là frame PPPoE:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bạn chú ý trường SESSION_ID:
The SESSION_ID field is sixteen bits. It is an unsigned value in network byte order. It's value is defined below for Discovery packets. The value is fixed for a given PPP session and, in fact, defines a PPP session along with the Ethernet SOURCE_ADDR and DESTINATION_ADDR. A value of 0xffff is reserved for future use and MUST NOT be used
Khi bạn gửi một frame PPPoE, máy chủ PPPoE ở ISP sẽ nhìn vào SESSION_ID và SOURCE_ADDR để xác định kết nối của bạn. Đây chính là điểm yếu của PPPoE, nếu bạn biết được địa chỉ MAC và đoán được SESSION_ID của một người nào đó, bạn sẽ có toàn quyền điều khiển kết nối PPPoE của họ. Trên thực tế, tôi có thể ngắt kết nối PPPoE của bất kì người nào sử dụng dịch vụ Cable Internet của SCTV khi đã biết được địa chỉ MAC của họ.

Do SESSION_ID chỉ có 16 bit nên bạn không cần đoán nó làm gì mà chỉ cần gửi hàng loạt SESSION_ID khác nhau đến máy chủ PPPoE của ISP. Trong trường hợp xấu nhất, bạn sẽ phải gửi 2^16-1 PADT frame khác nhau, mỗi frame dài 20 byte. Tôi có viết thử một chương trình nhỏ để làm chuyện này và thấy rằng sử dụng một máy tính, tôi mất khoảng trên dưới 20 phút để gửi 2^16-1 PADT frame. Bạn có thể dựa vào đặc tính luôn tăng tuyến tính theo thời gian của SESSION_ID để giảm bớt số lượng PADT cần gửi. Trên thực tế, tôi thường chỉ mất dưới 5 phút để kết liễu một phiên PPPoE.

Bạn có thể thấy rằng, nhiệm vụ khó nhất là tìm địa chỉ MAC của nạn nhân. Tôi nghĩ cách tấn công hiệu quả nhất trong trường hợp này là sử dụng social engineering. Bạn giả làm người của ISP, gọi điện cho nạn nhân, yêu cầu họ cung cấp địa chỉ MAC. Tôi tin xác suất thành công của social engineering sẽ trên 50% bởi vì địa chỉ MAC không phải là thứ nhạy cảm như mật khẩu, người ta sẽ sẵn sàng cung cấp nó cho bạn. Một khi đã biết địa chỉ MAC rồi, nạn nhân cũng khó lòng mà thay đổi nó như đổi mật khẩu. Hihi, đọc bài này xong thì nếu ai gọi điện thoại cho bạn kêu bạn cung cấp địa chỉ MAC thì nhớ báo công an nhen :-d.

-Thái

-----
Ghi chú
-1-: Do ở đây cả ADSL và Cable Internet đều sử dụng giao thức PPPoE nên từ đây về sau tôi sẽ gọi chung là ADSL.

-2-: Tùy thuộc vào mỗi người, địa chỉ MAC này có thể là địa chỉ MAC trên máy tính cá nhân hay địa chỉ MAC của modem ADSL.

Hội hay là thảo?

(bài này đánh giá chất lượng một cá nhân, tổ chức khác, nếu bạn không thích xin vui lòng đừng đọc)

Thứ bảy tuần rồi tôi mới tham dự một hội thảo bảo mật có tên khá kêu là Đại hội hacker mũ trắng. Hội thảo được tổ chức khá hoành tráng, kéo dài từ 8h sáng đến tận 5h chiều ở Dinh Thống Nhất với sự tham dự của Microsoft, MiSoft, VietShield, Athena...Buổi sáng tôi bận việc nên chỉ tham gia vào phiên thứ hai, bắt đầu lúc 13h30. Tôi đến lúc 13h45, cũng may là bài tham luận đầu tiên của buổi chiều vẫn chưa bắt đầu. Chà, dân mình quan tâm đến bảo mật thật, tôi ước đoán có khoảng 800-1000 người ngồi gần hết hội trường chính của dinh Thống Nhất, trong đó khoảng 70%-80% là sinh viên (một người bạn của tôi tham dự phiên buổi sáng cho biết buổi sáng toàn mấy bậc trung niên ngồi nghe).

Gần 2h chiều, bài tham luận mang tên "10 phút tấn công hệ thống email server", với diễn giả là một tay CCIE, mở đầu cho phiên buổi chiều. Diễn giả bắt đầu bằng việc đưa ra khá nhiều định nghĩa, mà tôi chỉ ấn tượng nhất là hai định nghĩa như sau:
  • Vùng biên: những vùng trung chuyển email + những vùng nhận email bao gồm cả workstation của người dùng cuối. Tác giả còn đưa ra thêm một vùng nào đó mà tôi không nhớ rõ.
  • Directory harvest attack: đây là cách thức tấn công của spammer bằng cách gửi một email đến địa chỉ broadcast trong hệ thống để nó tự động forward đến các email khác, kiểu như gửi đến địa chỉ của mailing list vậy đó.
Thú thật rằng nghe diễn giả định nghĩa xong là tôi muốn đi về rồi. Có thể khác nhau về câu chữ, nhưng khái niệm vùng biên (perimeter) mà bao gồm luôn cả workstation của người dùng cuối thì có lẽ cái vùng biên đó nó không còn nằm ở biên nữa rồi. Tếu nhất là cách diễn giả định nghĩa directory harvest attack. Tôi hỏi anh bạn đi cùng, không biết tay này dịch tài liệu ở đâu nhỉ?

Cũng may phần tiếp theo khi nói về các nguy cơ trong việc sử dụng email, diễn giả có đề cập đến virus, spam và phishing. Nói về virus, diễn giả cho rằng cách phòng chống tốt nhất là sử dụng trình anti-virus ở phía client. Nói về spam, diễn giả cho rằng chống spam rất là khó và nó thường được sử dụng để tấn công DDoS vào hệ thống mail. Nói về phishing, diễn giả mô tả nó là cách thức bọn hacker chôm tiền của bạn rồi hết. Toàn bộ thời gian còn lại, tác giả nói về cách sniff hệ thống mạng để chôm mật khẩu email bằng Cain & Abel. Àh, giờ thì tôi mới hiểu, hèn chi diễn giả định nghĩa vùng biên như vậy. Tấn công hệ thống email server theo ý của diễn giả là sniff hay tấn công MITM để chôm mật khẩu của người dùng. Chấm hết.

Tôi kiên nhẫn ngồi nghe tiếp bài thứ hai mang tên Physical Security của một diễn giả đến từ Athena. Bài này đỡ hơn một tí, tay diễn giả ít ra còn biết mình đang nói về vấn đề gì. Nhưng xét chung thì cũng không có nhiều điểm hấp dẫn, bởi lẽ diễn giả luôn bắt đầu bằng "theo các tài liệu mà tôi đọc". Tôi bỏ về giữa chừng bởi lẽ tôi không nghĩ rằng tôi cần một người khác dịch và đọc tài liệu cho tôi nghe.

Nếu họ có tổ chức những hội thảo khác, chắc chắn tôi sẽ tham dự tiếp. Mặc dầu chúng có thể chẳng đem lại nhiều kiến thức, nhưng đối với một người làm tư vấn bảo mật như tôi, lên danh sách đen những cá nhân và công ty dởm là một việc làm hết sức quan trọng, nó sẽ giúp khách hàng của tôi không chọn nhầm đối tác.

-Thái

PS: anh bạn đi cùng có hỏi tôi một câu thế này, bao giờ VN mình mới có được một hội thảo cỡ như Blackhat? Lớn như Blackhat thì hơi khó, nhưng tôi nghĩ việc tổ chức một hội thảo nho nhỏ nhưng nghiêm túc là việc trong tầm tay. Không cần marketing, không cần báo chí, không quá ồn ào, không cần đông người, chỉ có hacking và security. Đó là ý kiến của một anh bạn khi tôi trao đổi qua email về việc làm sao đưa cộng đồng làm bảo mật ở VN xích gần hơn với thế giới bên ngoài. Hi vọng sang năm 2007 chúng ta sẽ có một hội thảo như vậy.

Cái giá của spam

Một khách hàng của tôi hôm rồi có hỏi có cách nào để ước lượng được mỗi năm công ty của họ đã phải tiêu tốn hết bao nhiêu tiền cho vấn đề spam? Tôi thử tìm trên Google và thật bất ngờ là có khá nhiều công cụ (marketing) giúp tính thiệt hại do spam gây ra cho doanh nghiệp. Dĩ nhiên những con số mà các công cụ này đưa ra chỉ mang tính chất tham khảo, nhưng nó cũng cho chúng ta thấy rằng spam không chỉ gây phiền toái mà nó còn gây thiệt hại về kinh tế. Thông thường doanh nghiệp chỉ triển khai giải pháp chống spam để giải quyết vấn đề đầu tiên, họ ít hoặc hoàn toàn không nghĩ đến vấn đề thứ hai.

Trong trường hợp của khách hàng ở trên, họ có 1000 nhân viên có địa chỉ email, lương trung bình mỗi người là $3/giờ, mỗi người nhận 50 email mỗi ngày, trong đó 90% là spam. Như vậy họ mất $26041.67 mỗi năm. Chà, gần nửa tỉ bạc rồi còn gì, đó là chưa kể đến đường truyền, máy chủ, lưu trữ và lương cho sysadmin như tôi :p.

Đòn hi sinh của đám spammer

Tôi dành nguyên buổi tối ngày hôm qua để khắc phục sự cố trên hệ thống chống spam. Lũ spammer thật khốn nạn, chúng đẻ ra đủ mọi cách để chơi xấu. Nếu như lần trước là trò ném đá dấu tay thì lần này chúng đánh thẳng vào hệ thống chống spam của tôi. Đúng là quân bất nhân!

Mấy ngày gần đây không ngày nào tôi không bị khách hàng than phiền về trình trạng chập chờn của hệ thống chống spam, khi mà họ không thể nhận được email từ phía đối tác gửi vào.
Tìm hiểu log, tôi phát hiện ra DSPAM, một phần mềm quan trọng trong hệ thống chống spam cứ vài phút lại lăn ra chết cứng, mặc kệ tôi đã tái khởi động cũng như điều chỉnh các thông số như thế nào. Tôi đã sử dụng phần mềm này được hơn 1 năm nay và đây là lần đầu tiên tôi thấy tình trạng này. Trước giờ nó rất ổn định, chỉ đôi lần bị quá tải chứ chưa bao giờ chết bất đắt kì tử như thế này. Đám spammer lại giở trò gì nữa chăng? Tôi quyết định biên dịch lại DSPAM, mở tính năng debug để xem chuyện gì đã xảy ra. Để chắc ăn, tôi khởi động lại toàn bộ hệ thống chống spam rồi đặt một cái tail cùng một cái strace và một cái tcpdump để vừa theo dõi thông tin debug, vừa xem xét diễn biến bên trong của phần mềm đang gặp lỗi, cũng như chộp các packet gửi đến hệ thống của tôi.

Tình hình có vẻ căng àh, lúc mới khởi động thì hệ thống vẫn chạy ngon nhưng chỉ cần 5' hoặc 10', thằng DSPAM lại lăn ra chết. Nó không chết hẳn, mà chiếm trọn CPU và RAM trên hệ thống, làm cho các thành phần khác cũng cứng đơ. Nhìn vào thông tin debug, tôi thấy nó đang xử lí một cái spam gửi đến địa chỉ mailer-daemon@mydomain.com. Thằng strace cũng đang dừng lại ở chỗ đó. Tôi kiên nhẫn chờ 5', 10' rồi 15' nhưng nó vẫn chưa xử lí xong nữa. Toàn bộ hệ thống gần như đứng yên, spam từ ngoài vẫn ào ạt gửi vào, nằm sắp lớp như cá mồi trong mấy cái hàng đợi.

Tôi lướt thử qua nội dung cái spam mà thằng DSPAM đang xử lí. Chà, sao trông nó kì cục vậy nè, chẳng có bất kì đoạn text nào trong đó, chỉ có những chuỗi rất dài phân cách với nhau bởi chuỗi kí tự =3D. DSPAM rất được đám sysadmin như tôi ưa chuộng, có lẽ nào cái spam này được gửi đi với một nhiệm vụ kết liễu phần mềm này? Tôi không dám chắc điều đó nhưng quả thật trong vài ngày vừa qua, tôi chứng kiến rất nhiều spam kiểu như thế này gửi vào hệ thống của mình. Thằng DSPAM hễ đụng phải đám spam này là lại lăn ra chết. Có vẻ như sau khi thất bại trong cuộc chiến với Bayesian filtering, đám spammer đã chơi đòn hi sinh, sử dụng lực lượng cảm tử để tiêu diệt hết những phần mềm triển khai ý tưởng của Paul Graham. Một fuzzer dành riêng cho phần mềm chống spam chăng?

Tôi sẽ gửi báo cáo cho tác giả của DSPAM và Internet Storm Center, hi vọng họ sẽ tìm ra được manh mối. Giải pháp tạm thời là chặn tất cả các spam đáng nghi kể trên không cho chúng đụng tới bé DSPAM nữa!