text:
Monday, July 30, 2007
www.tuoitre.com.vn thay đổi cách thiết kế menu
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)
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.
- 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.
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/bashNhư 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.
#
# 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ư 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 = 20GNế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:
kernel.shmmax = 22548578304
# total shared memory 25G
kernel.shmall = 1638400
# total hugepages = 20,5G
vm.nr_hugepages= 82
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 HugeRồ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:
HugePages_Total: 82
HugePages_Free: 82
Hugepagesize: 262144 kB
# cat /proc/meminfo | grep HugeYahoooo! 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.
HugePages_Total: 82
HugePages_Free: 2
Hugepagesize: 262144 kB
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
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?
Đâ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
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àyNhì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:
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ở.
Saturday, July 21, 2007
Ngồi ở đâu trên máy bay là an toàn nhất?
Tuesday, July 17, 2007
Dùng iptables NAT thay thế cho reverse proxy
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
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
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, user và idle 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.Phần cuối của tài liệu này trông có vẻ rất promising:
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.
Why HugePages Should Be Used on 64-bit Linux?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.
* 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òn tiếp)
Một phương pháp chống DDoS bằng xFlash
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 attackGợi ý ở trên có thể được diễn giải như sau:
described here is irrelevant.
- 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 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$ 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$ "./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/Để 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...)
FilterChain textedit
LERewriteRule '(<>' '$1 enctype="multipart/form-data">' RiRồ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.
- 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.
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ể. NoScript và FlashBlock 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?
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
Giao diện mới của www.tuoitre.com.vn
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.
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 mastery và designing the obvious
* 2 cuốn về security: the oracle hacker's handbook và reversing: 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
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?
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
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.
Phần thưởng nào dành cho người làm 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.Đâ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ể.
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.
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
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Trong đó phần payload sẽ có cấu trúc như sau nếu nó là frame PPPoE:
| DESTINATION_ADDR
| (6 octets)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR
| (6 octets)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~
~ payload
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bạn chú ý trường SESSION_ID:
| VER | TYPE | CODE | SESSION_ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 usedKhi 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?
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 đó.
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
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
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!

markdown:
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](http://vnhacker.blogspot.com/2007/06/giao-din-mi-ca-wwwtuoitrecomvn.html).
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.

Content-Type: text/html; charset=UTF-8

Cache-Control: private, max-age=0

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Server: GSE

Vary: Accept-Encoding


text:
(VTC News) - Họ tên đầy đủ của anh là Giàng A Linh, chính xác 36 tuổi, còn người yêu, mối tình nồng cháy của anh là “em” Hạng Thị Sông, năm nay tròn 80 tuổi.
Những ngày lang thang ở thị trấn Sapa, trong cái lạnh 1-2 độ C, bên bếp than hồng nức mùi khoai nướng, tôi được nghe chị bán hàng kể về mối tình độc nhất vô nhị: Mối tình của chàng trai 36 tuổi với bà già 80.
Quả thực, khi nghe chị bán hàng kể chuyện này, tôi không thể tin được và nghĩ đó là một câu chuyện hài, người ta kể cho vui miệng. Hoặc cũng có thể đó là một câu chuyện thêu dệt, như hàng chục sự tích tình yêu khác ở xứ sở Mường Tiên, với mục đích hút khách du lịch.
Ấy vậy mà, một lần, vào ngôi chợ cũ kỹ trăm tuổi ở góc thị trấn, tôi tò mò thử hỏi những người bán hàng về mối tình đôi đũa lệch mà chị bán hàng đêm kể, không ngờ, mọi người đều quả quyết đúng là có mối tình đó.
Bà Giàng Thị Sử, chủ cửa hàng thổ cẩm ở chợ Sapa cười phớ lớ: “Đúng là có chuyện tình đó nhà báo à. Chuyện tình này vui lắm, hay lắm, khiến bọn già chúng ta xúc động là đằng khác”.
Nói rồi, bà Giàng Thị Sử dẫn tôi đi một vòng quanh chợ Sapa để tìm đôi uyên ương. Theo bà Sử, đôi uyên ương này tay trong tay, như hình với bóng suốt ngày đêm, nên hễ tìm thấy một người, thể nào cũng tìm thấy người kia.
Tuy nhiên, đi hết vòng chợ mà chúng tôi không tìm thấy đôi uyên ương. Đang lúc dò hỏi, thì một người nói với bà Sử: “Không thấy bà Sông đâu cả, chỉ thấy thằng Linh đang uống rượu ở tầng dưới kia thôi”.
Người đàn ông có khuôn mặt khá khôi ngô, đang ngồi uống rượu một mình bên một cái phản bán thịt bỏ không. Trên bàn là một chai rượu đã cạn, bát và đĩa sạch nhẵn thức ăn.
Tôi hỏi: “Anh Giàng A Linh phải không? Có chuyện buồn hay sao mà ngồi uống rượu một mình thế?”. Anh chàng Linh cất lời: “Ta buồn quá, ngồi uống rượu thôi. Ta uống hết chai rồi mà không say được à. Ta muốn say quá mà không say được”.
Tôi giơ máy ảnh ra chụp, anh chàng người Mông này lấy tay che mặt, bảo: “Cho ta 5 ngàn, thì ta cho chụp ảnh”. Tôi đưa cho Linh 5 ngàn. Tức thì, anh ta lại bảo: “5 ngàn chỉ chụp một cái thôi. Cho ta 10 ngàn thì chụp ảnh thoải mái”. Không ngờ, anh chàng này đã ngất ngư như thế mà vẫn biết đòi tiền công “làm mẫu”.
Kiếm được đủ tiền trả rượu và mồi nhậu, Linh liền dốc tuột lòng mình, dù cái giọng lơ lớ nửa Kinh, nửa Mông vẫn còn chưa chuẩn.
Linh kể, họ tên đầy đủ của anh là Giàng A Linh, chính xác 36 tuổi, còn người yêu, mối tình nồng cháy của anh là “em” Hạng Thị Sông, năm nay tròn 80 tuổi. Nhà Linh ở xã Sa Pả, cách thị trấn Sapa nửa ngày đi bộ, còn nhà người yêu ở xã Sử Pán, mất một ngày cuốc bộ mới tới nơi.
Linh ngồi kể cho tôi nghe những đau khổ tan nát cõi lòng, do mối tình của mình bị mọi người ngăn cản. Còn tôi ngồi bấm ngón tay, thấy anh chàng này kém người yêu đến 44 tuổi, tức là “bạn gái” nhiều gấp hơn hai lần Linh. Mối tình “đôi đũa lệch ngược” này, tìm khắp thế giới chắc cũng khó có thể thấy được.
Theo lời Linh, hai người đã yêu nhau 6 năm nay và từ đó đến nay, mối tình của họ không ngớt sóng gió. Cả họ hàng, gia tộc nhà Linh phản đối, cả họ hàng, gia tộc, con cháu bà Sông cũng kiên quyết ngăn cản mối tình thác lũ này.
Linh bấm ngón tay và bảo, tổng số đã có 15 lần Linh đưa người tình về ra mắt họ hàng, nhưng lần nào bố mẹ, anh em Linh cũng chửi mắng Linh thậm tệ. Linh buồn rầu: “Ta không thể hiểu được những người trong gia đình ta. Ta yêu Sông là tình yêu trong sáng, yêu bằng cả trái tim, không vụ lợi gì. Chúng ta chẳng có lỗi gì cả, vậy sao cứ ngăn cản chúng ta, hả trời ơi!”. Hỏi trời, hỏi đất xong, Linh lại “cưa đôi” chén rượu với tôi.
Người mà Linh tức nhất là bố đẻ và các bác. Họ chửi rằng, Linh đã làm xấu mặt gia đình vì yêu một bà già. Người Linh giận thứ nhì là mẹ đẻ Linh. Mỗi khi Linh dẫn người yêu về, bà mẹ đẻ, ít hơn vợ Linh 10 tuổi lại nhảy lên như dẫm phải bỏng: “Mày đui mày mù gì đâu mà sao lại rước bà già về hả? Mày định rước nó về làm mẹ tao hả?”. Xỉ vả chán chê rồi bà đuổi hai người yêu nhau ra khỏi nhà, đóng sầm cửa lại.
Linh bảo, 15 lần đưa người tình về, thì 15 lần bị xỉ vả như thế, khiến Linh mất hết can đảm, chịu đựng. Sự chịu đựng, nhẫn nhục của con người chỉ có giới hạn. Bố mẹ, họ hàng mắng chửi Linh là chuyện bình thường, nhưng xúc phạm người yêu của Linh thì đúng là không thể chấp nhận được.
Mỗi lần bị gia đình “bạn trai” hắt hủi, bà Sông lại rất buồn. Bà khóc ròng. Từng ấy tuổi, nhưng mỗi khi khóc, nước mắt bà chan chứa, Linh thấm ướt mấy cái khăn liền.
Về phía gia đình bà Sông cũng phản đối quyết liệt không kém. Biết rằng, con cái, gia đình không chấp nhận chàng rể tý tuổi, bà Sông không thèm hỏi ý kiến nữa. Bà Sông đã ở tuổi bà, tuổi mẹ, có hỏi thì hỏi người bề trên, mà người bề trên thì chết hết rồi, nên bà tự quyết được. Ấy thế mà, thi thoảng đám con cháu lại kéo lên Sapa mắng bà sa sả, rồi tìm đủ cách đe dọa, cấm Linh không được yêu bà nữa.
Còn tiếp…
Phạm Ngọc Dương
Mối tình của người đàn bà 80 và chàng trai 36 tuổi liệu có vượt qua được sóng gió? Liệu họ có đi đến hôn nhân? Kính mời quý độc giả đón đọc kỳ tới.
Độc giả bình luận gì về mối tình này hoặc có thông tin về những mối tình kỳ lạ xung quanh bạn, hãy gửi ý kiến cho chúng tôi vào ô "Phản hồi của độc giả về bài viết" dưới cuối bài. Gõ tiếng Việt có dấu để được đăng tải. Trân trọng!

markdown:
**(VTC News) - Họ tên đầy đủ của anh là Giàng A Linh, chính xác 36 tuổi, còn người yêu, mối tình nồng cháy của anh là “em” Hạng Thị Sông, năm nay tròn 80 tuổi.**
*Đôi uyên ương hạnh phúc bên nhau.*
Quả thực, khi nghe chị bán hàng kể chuyện này, tôi không thể tin được và nghĩ đó là một câu chuyện hài, người ta kể cho vui miệng. Hoặc cũng có thể đó là một câu chuyện thêu dệt, như hàng chục sự tích tình yêu khác ở xứ sở Mường Tiên, với mục đích hút khách du lịch.
Ấy vậy mà, một lần, vào ngôi chợ cũ kỹ trăm tuổi ở góc thị trấn, tôi tò mò thử hỏi những người bán hàng về mối tình đôi đũa lệch mà chị bán hàng đêm kể, không ngờ, mọi người đều quả quyết đúng là có mối tình đó.
Bà Giàng Thị Sử, chủ cửa hàng thổ cẩm ở chợ Sapa cười phớ lớ: “Đúng là có chuyện tình đó nhà
[báo](http://vtc.vn) à. Chuyện tình này vui lắm, hay lắm, khiến bọn già chúng ta xúc động là đằng khác”.
*Bà Giàng Thị Sử: "Chuyện tình này khiến bọn già chúng ta phải xúc động".*
Tuy nhiên, đi hết vòng chợ mà chúng tôi không tìm thấy đôi uyên ương. Đang lúc dò hỏi, thì một người nói với bà Sử: “Không thấy bà Sông đâu cả, chỉ thấy thằng Linh đang uống rượu ở tầng dưới kia thôi”.
Người đàn ông có khuôn mặt khá khôi ngô, đang ngồi uống rượu một mình bên một cái phản bán thịt bỏ không. Trên bàn là một chai rượu đã cạn, bát và đĩa sạch nhẵn thức ăn.
Tôi hỏi: “Anh Giàng A Linh phải không? Có chuyện buồn hay sao mà ngồi uống rượu một mình thế?”. Anh chàng Linh cất lời: “Ta buồn quá, ngồi uống rượu thôi. Ta uống hết chai rồi mà không say được à. Ta muốn say quá mà không say được”.
*"Cho ta 10 ngàn thì chụp ảnh thoải mái".*
Kiếm được đủ tiền trả rượu và mồi nhậu, Linh liền dốc tuột lòng mình, dù cái giọng lơ lớ nửa Kinh, nửa Mông vẫn còn chưa chuẩn.
Linh kể, họ tên đầy đủ của anh là Giàng A Linh, chính xác 36 tuổi, còn người yêu, mối tình nồng cháy của anh là “em” Hạng Thị Sông, năm nay tròn 80 tuổi. Nhà Linh ở xã Sa Pả, cách thị trấn Sapa nửa ngày đi bộ, còn nhà người yêu ở xã Sử Pán, mất một ngày cuốc bộ mới tới nơi.
Linh ngồi kể cho tôi nghe những đau khổ tan nát cõi lòng, do mối tình của mình bị mọi người ngăn cản. Còn tôi ngồi bấm ngón tay, thấy anh chàng này kém người yêu đến 44 tuổi, tức là “bạn gái” nhiều gấp hơn hai lần Linh. Mối tình “đôi đũa lệch ngược” này, tìm khắp
[thế giới](http://vtc.vn/quoc-te.311.0.html) chắc cũng khó có thể thấy được.
*"Nâng chén tiêu sầu càng sầu thêm".*
Linh bấm ngón tay và bảo, tổng số đã có 15 lần Linh đưa người tình về ra mắt họ hàng, nhưng lần nào bố mẹ, anh em Linh cũng chửi mắng Linh thậm tệ. Linh buồn rầu: “Ta không thể hiểu được những người trong gia đình ta. Ta yêu Sông là tình yêu trong sáng, yêu bằng cả trái tim, không vụ lợi gì. Chúng ta chẳng có lỗi gì cả, vậy sao cứ ngăn cản chúng ta, hả trời ơi!”. Hỏi trời, hỏi đất xong, Linh lại “cưa đôi” chén rượu với tôi.
*Tác giả và chàng trai có mối tình bất hủ.*
Linh bảo, 15 lần đưa người tình về, thì 15 lần bị xỉ vả như thế, khiến Linh mất hết can đảm, chịu đựng. Sự chịu đựng, nhẫn nhục của con người chỉ có giới hạn. Bố mẹ, họ hàng mắng chửi Linh là chuyện bình thường, nhưng xúc phạm người yêu của Linh thì đúng là không thể chấp nhận được.
Mỗi lần bị gia đình “bạn trai” hắt hủi, bà Sông lại rất buồn. Bà khóc ròng. Từng ấy tuổi, nhưng mỗi khi khóc, nước mắt bà chan chứa, Linh thấm ướt mấy cái khăn liền.
Về phía gia đình bà Sông cũng phản đối quyết liệt không kém. Biết rằng, con cái, gia đình không chấp nhận chàng rể tý tuổi, bà Sông không thèm hỏi ý kiến nữa. Bà Sông đã ở tuổi bà, tuổi mẹ, có hỏi thì hỏi người bề trên, mà người bề trên thì chết hết rồi, nên bà tự quyết được. Ấy thế mà, thi thoảng đám con cháu lại kéo lên Sapa mắng bà sa sả, rồi tìm đủ cách đe dọa, cấm Linh không được yêu bà nữa.
**Còn tiếp…** **Phạm Ngọc Dương** **Mối tình của người đàn bà 80 và chàng trai 36 tuổi liệu có vượt qua được sóng gió? Liệu họ có đi đến hôn nhân? Kính mời quý độc giả đón đọc kỳ tới. Độc giả bình luận gì về mối tình này hoặc có thông tin về những mối tình kỳ lạ xung quanh bạn, hãy gửi ý kiến cho chúng tôi vào ô "Phản hồi của độc giả về bài viết" dưới cuối bài. Gõ tiếng Việt có dấu để được đăng tải. Trân trọng!**

WARC-Type: response

Content-Type: application/http; msgtype=response

WARC-Truncated: length

Cache-Control: max-age = 180

Content-Encoding: gzip

Connection: close

Server: OSX Server

X-Powered-By: Apple

X-Status: CM

Content-Type: text/html


text:
Danh mục: ClipXemNhieu> Giải trí
Copyright 2014 © ClipXemNhieu.com All rights reservedChúng tôi trên Google+
Clip được sưu tầm từ youtube

Vary: User-Agent

Server: LiteSpeed

Cache-Control: public, max-age=2592000

Pragma: no-cache


text:
Nhân cái chết của tên *việt-gian VÕ VĂN KIỆT
- Trần Thanh -
(Bài viết đặc biệt gởi các độc giả ở trong nước và gởi tặng trung tâm băng nhạc "quê hương là chùm khế ngọt")
Cuối cùng thì tên việt gian Võ Văn Kiệt cũng phải về chầu diêm vương! Bạc tỷ đô la cũng không cứu được hắn. Không biết khi chết xuống âm phủ thì hắn có đem theo được số bạc tỷ đô la mà hắn đã ăn cướp của toàn dân hay không? Phải như lúc bị bệnh nặng gần chết, hắn biết ăn năn, hối lỗi về những tội ác của hắn và quyết định đem một phần tài sản của hắn mà chia lại cho những người dân oan đang sống vất vưởng như những con chó đói ở ngoài đường thì hay quá! Cái đó mới có thể được gọi là "đổi mới" hay "cải cách"!
Ba ngày sau khi hắn chết, các tờ báo của việt cộng mới dám đăng tin và đăng bài ca ngợi những "công đức" của hắn.
Riêng tại hải ngoại, khi hay tin tên Kiệt chết, chỉ có tờ báo NGƯỜI VẸM ở quận Cam nước Mỹ là vội vàng cho đăng một bản tin dưới dạng "thành kính phân ưu", thương tiếc "ngài" THỦ TƯỚNG NƯỚC VIỆT NAM(!), đồng thời tên bồi bút NND, chuyên viên bưng bô cho việt cộng, chuyên viết các bài "bình loạn" chính trị, viết một bài ca ngợi những "công đức" của "ngài" Kiệt lặc! (cặc liệt) Thật là đáng tởm quá! Vậy mà nếu có ai lên án báo Người Vẹm là tay sai của việt cộng thì bọn chúng lại dãy nảy lên như đĩ ngồi phải cọc và la làng lên là chúng bị "vu oan"!!!
Đám đàn em cùng phe đảng của tên Kiệt cùng với đám bưng bô ở hải ngoại đã ca ngợi Kiệt như là một ngôi sao sáng, một vị cứu tinh của đất nước, một "Goóc Ba Chớp" của cái chế độ việt gian cộng sản Việt
Chưa hết, ở hải ngoại, bọn bưng bô còn đưa tin: anh Sáu chính là hậu duệ của cụ Phan Thanh Giản! (Tên thật của Kiệt là Phan Văn Hòa, sanh quán tại tỉnh Vĩnh Long)
Hoặc :
- anh Sáu đã từng là giáo sư trung học đệ nhị cấp nên mới lấy được vợ là tiến sĩ hóa học!
- anh Sáu là người trí thức nên mới có tư tưởng đổi mới, chống lại phe cộng sản bảo thủ
- bản thân anh Sáu là người trí thức nên anh Sáu mới biết quý trọng người trí thức, chẳng hạn như đã bảo bọc cho nhạc sĩ Trịnh Công Sơn, cấp biệt thự cho Trịnh Công Sơn ở để sáng tác nhạc, phục vụ cho .... đảng!
Nếu như "bác" Hồ có những câu nói .... ngu để đời, thì anh Sáu cũng có những câu bá láp, bịp bợm sau đây, được bọn thổi ống đu đủ ở hải ngoại vừa thổi vừa hít hà cái mùi ... thối của nó:
- Ngày 30 tháng 4 năm 1975 có triệu người vui thì cũng có triệu người buồn.
Tổ quốc Việt
Nhận xét:
- (Cái gì cũng "của mình", tức của người dân, chỉ trừ có cái ngân hàng là thuộc về nhà nước! Đặc biệt cái nhà tù với cái còng số tám cũng là "của mình"!!!)
- Kiệt uống rượu mừng thắng lợi với "triệu thằng vui" và đồng thời hắn thò tay móc túi "triệu kẻ buồn". Mâm nào cũng có hắn!!!
Điều cần nhớ là tên Kiệt chỉ dám tuyên bố những câu "ranh ngôn" như vậy sau khi hắn đã về vườn, đóng vai nhà dân chủ cuội, dân chủ dỏm để làm cò mồi chính trị và tiếp tục lừa bịp người dân trong nước và hải ngoại. Những kẻ đầu tôm ngu ngốc gia truyền cứ thấy Kiệt tuyên bố mấy câu "cấp tiến" nêu trên thì đã vội vàng suýt xoa, khen mãi Kiệt là người rất "phóng khoáng, cởi mở"!
Nói một cách ngắn gọn: Kiệt có đầu óc "cấp tiến" hay "cải cách" hay "chống đảng" cũng chỉ nhằm một mục đích chính: CHỐNG ĐẢNG ĐỂ CỨU ĐẢNG. Việc làm của hắn về bản chất cũng không khác gì hai tên việt gian đã chết trước hắn, đó là Trần Độ và Hoàng Minh Chính. Hắn chủ trương đổi mới hay cải cách là nhằm giúp cho bộ máy cai trị của bọn việt gian cộng sản hoạt động TINH VI và HỮU HIỆU hơn, nhằm tiếp tục ngồi trên đầu 80 triệu dân để bóc lột lâu dài từ đời này sang đời khác, chớ không phải vì chén cơm manh áo của toàn dân. Nếu hắn là đảng viên cộng sản thanh liêm thì tại sao tài sản của giòng họ hắn ước tính trên 2 tỷ đô la? Chỉ có đi ăn cướp mới có được một số tiền lớn như thế. Các vị tổng thống Mỹ khi về hưu còn bị thiếu nợ như chúa chổm chớ làm gì có được một tài sản khổng lồ như tên Kiệt?
Chắc hẳn các bạn đã từng nghe tên Kiệt ca sáu câu vọng cổ "cấp tiến" như thế này:
- Các đồng chí ơi, các đồng chí bóc lột của thằng dân được 10 đồng thì nên nhả ra bớt 3 đồng cho nó, để nó còn có đường mà sống. Ăn ít no lâu, ăn nhiều tức bụng. Đằng này các đồng chí lột của nó hết 10 đồng mà chỉ nhả ra có một đồng cho nó thì đói quá, thằng dân sẽ liều mạng nổi loạn. Tức nước thì vỡ bờ, già néo thì đứt giây. NGHỆ THUẬT ... BÓC LỘT LÀ PHẢI NHƯ VẬY! Có như vậy tụi mình mới lừa bịp được thế giới và ngồi trên đầu 80 triệu dân lâu dài được chớ!
Chống đảng là để cứu đảng và cứu đảng chính là cứu chính bản thân tên Kiệt và bè đảng ăn cướp của hắn. Người dân đen hoàn toàn không bao giờ được hưởng một chút xíu lợi lộc gì hết. Thằng chó việt gian cộng sản nào cũng như nhau, cũng có cùng một bản chất với năm đặc trưng, đó là THAM LAM, GIAN ÁC, LƯU MANH, NGU DỐT và HÈN NHÁT. Thằng bảo thủ hay thằng cấp tiến nào nắm quyền thì cái số phận nghèo khổ tăm tối, đốn mạt của người dân đen vẫn không thay đổi: những người công nhân và nông dân vẫn phải hàng ngày đi cày 14 tiếng đồng hồ hộc máu mồm, mười chén mồ hôi mới đổi được một chén cơm; những em điếm tuổi vị thành niên phải liên tục tiếp khứa từ sáng tới khuya, mà miệng dưới không nuôi nổi miệng trên! Thằng chó cộng sản gốc miền bắc hay thằng chó cộng sản gốc miền nam ĐỀU CHÓ ĐẺ NHƯ NHAU. Nghĩa là bọn chúng rất chó má, sẵn sàng ăn thịt lẫn nhau, đừng có nói gì sanh mạng của người dân mà chúng tha! Đừng có tưởng bở rằng thằng cộng sản gốc miền nam là "cởi mở" hay "cấp tiến"! Thằng chó Lê Hồng Anh, đại tướng công an, nhân vật số 2 của bộ chính trị là dân miền nam thứ thiệt, quê ở Rạch Giá. Đừng thấy nó gốc
Tất cả những tên gộc việt gian cộng sản đều có tội với đất nước, không tội ít thì tội nhiều, chớ bọn chúng hoàn toàn không có một công lao gì hết. Cái gọi là "công" đổi mới của Võ Văn Kiệt chính là nhằm giúp cho băng đảng cướp của hắn có cơ hội vơ vét cho mau đầy túi và duy trì quyền lực của bọn chúng được lâu dài. Chúng ta phải ý thức thật rõ điều này và quyết tâm lật đổ chế độ cộng sản để đem lại tự do cho đất nước. Thằng việt gian cộng sản nào cũng tàn ác như nhau dù là phe miền nam hay phe miền bắc, phe bảo thủ hay phe cấp tiến, phe thân Nga xô, phe thân Trung Cộng hay thân Mỹ. Tất cả đều là những bọn chó săn. Nếu như trước đây bọn chúng dùng roi cá đuối có gai để đánh chúng ta thì sau này, nhờ sáng kiến "đổi mới" của Võ Văn Kiệt, chúng "nhân đạo" hơn, đánh chúng ta bằng roi điện hoặc loại dùi cui vuông*, như vậy không thể gọi là "công lao" hay "nhân đạo" mà đi ca ngợi bọn chúng! Kết quả của việc tra tấn đó là dẫn đến cơ thể của chúng ta bị tàn tạ, mang trọng thương rồi chết. Làm gì có chuyện "nhân đạo" ở đây? Không có tội thì đánh cho có tội, mà đã có "tội" thì đánh cho chừa!
Ba mươi ba năm đã trôi qua mà ở hải ngoại vẫn còn đầy dẫy những tên bồi bút đi bưng bô cho việt cộng. Không thể có một sự ngu lâu như vậy. Chỉ có thể có một sự giải thích hợp lý: đó là ĂN XÔI CHÙA NÊN NGỌNG MIỆNG! Những tội ác tày trời của tên Sáu Dân Võ Văn Kiệt thì những tên bồi bút cố ý lờ đi, bọn chúng chỉ thấy anh Sáu là "người hùng đổi mới"! Tên bồi bút NND của báo Người Vẹm ở quận
- Anh Sáu mất đi, các đàn em của anh sẽ bơ vơ. Rồi đây phe cộng sản bảo thủ sẽ loại trừ hết các đảng viên thuộc phe "đổi mới-cấp tiến" của anh Sáu ra khỏi hệ thống quyền lực. Phong trào đổi mới sẽ đi về đâu, tương lai nước Việt
Thật không khác gì giọng điệu của tên bồi bút Tố Hữu khóc người cha chết của hắn là Xít Ta Lin! Thương mình thương một thương ông Sáu Dân thương mười!!! Tên bồi bút NND xứng đáng được đảng việt gian cộng sản trao tặng cho "huân chương bưng bô" hạng nhất!
Nói tóm lại, chết được thằng việt gian nào thì bớt cho người dân một phần gánh nặng như quả núi đang đè lên số phận nghiệt ngã của dân tộc. Để tiễn đưa tên Sáu Dân xuống địa ngục A Tỳ đoàn tụ với "bác" Hồ và các tên dân chủ cuội như Trần Độ, Hoàng Minh Chính, chúng ta nên có một bài "đíu văn", định nghĩa thế nào là việt gian cộng sản, nhằm thức tỉnh những cái đầu tôm ở hải ngoại và ở trong nước:
(Nhại theo bài thơ "Quê Hương là chùm khế ngọt" của tác giả Đỗ Trung Quân)
Việt gian là gì hở mẹ?
Mà cô giáo dạy phải yêu?
Việt gian là gì hở mẹ?
Ai kinh qua phải khiếp hồn?
Việt gian là tên Hồ cáo
Tuổi thơ con hát trong trường
Việt gian là tên Hồ điếm
Tham tàn, Gian ác, Lưu manh
Việt gian là bầy Ác quỷ
Cùng nhau giết hại lương dân
Việt gian là bầy Quỷ dữ
Bán biển, Bán đất, Bán dân!!!
Việt gian là bầy Đàng điếm
Vô cùng Gian ác, Lưu manh
Việt gian là phường Xảo quyệt
Lừa dân, lừa cả loài người!
Việt gian là phường Xảo trá
Lừa dân, lừa cả Phật, Trời!!!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
Việt-Gian nếu ai không hiểu
Sẽ không lớn nổi thành người!!!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
Việt gian nếu ai không hiểu
Sẽ chôn vùi hết cuộc đời!!!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
Việt gian nếu ai lầm tưởng
Sẽ ân hận suốt cuộc đời!!!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
Việt gian nếu ai ca ngợi
Sẽ ân hận suốt nghìn đời!!!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
Việt gian nếu ai thương hại
Sẽ mang hận xuống tuyền đài!!!
Trần Thanh
Thứ Sáu, ngày 13 tháng Sáu, năm 2008
Chú thích:
1. Hai chữ "việt-gian" trong bài này được dùng như danh từ chung (common noun), chữ "việt" không viết hoa.
2. Thơ Nguyễn Hữu Nhật:
Dùi cui cả thế giới tròn
Phủ tay vãi thịt thấm đòn nát da
So với Hà Nội thua xa
Góc vuông chắc gỗ cạnh già sắc lim!

markdown:
**Nhân cái chết
của tên *việt-gian VÕ VĂN KIỆT** **- Trần Thanh -** **(Bài viết đặc biệt
gởi các độc giả ở trong nước và gởi
tặng trung tâm băng nhạc "quê hương là chùm khế
ngọt")**
Cuối cùng thì tên việt gian Võ Văn Kiệt cũng phải về chầu diêm vương! Bạc tỷ đô la cũng không cứu được hắn. Không biết khi chết xuống âm phủ thì hắn có đem theo được số bạc tỷ đô la mà hắn đã ăn cướp của toàn dân hay không? Phải như lúc bị bệnh nặng gần chết, hắn biết ăn năn, hối lỗi về những tội ác của hắn và quyết định đem một phần tài sản của hắn mà chia lại cho những người dân oan đang sống vất vưởng như những con chó đói ở ngoài đường thì hay quá! Cái đó mới có thể được gọi là "đổi mới" hay "cải cách"!
Ba ngày sau khi hắn chết, các tờ báo của việt cộng mới dám đăng tin và đăng bài ca ngợi những "công đức" của hắn.
Riêng tại hải ngoại, khi hay tin tên Kiệt chết, chỉ có tờ báo
**NGƯỜI VẸM ở quận Cam
nước Mỹ là vội vàng cho đăng một bản tin
dưới dạng "thành kính phân ưu", thương tiếc
"ngài" THỦ TƯỚNG NƯỚC VIỆT NAM(!),
đồng thời tên bồi bút NND**, chuyên viên bưng bô cho
việt cộng, chuyên viết các bài "bình
loạn" chính trị, viết một bài ca ngợi
những "công đức" của "ngài" Kiệt
lặc! (cặc liệt) Thật là
đáng tởm quá! Vậy mà nếu có ai lên án báo Người
Vẹm là tay sai của việt cộng thì bọn chúng
lại dãy nảy lên như đĩ ngồi phải cọc
và la làng lên là chúng bị "vu oan"!!!
Đám đàn em cùng phe đảng của tên Kiệt cùng với đám bưng bô ở hải ngoại đã ca ngợi Kiệt như là một ngôi sao sáng, một vị cứu tinh của đất nước, một "Goóc Ba Chớp" của cái chế độ việt gian cộng sản Việt
Chưa hết, ở hải ngoại, bọn bưng bô còn đưa tin: anh Sáu chính là hậu duệ của cụ Phan Thanh Giản! (Tên thật của Kiệt là Phan Văn Hòa, sanh quán tại tỉnh Vĩnh Long)
Hoặc :
- anh Sáu đã từng là giáo sư trung học đệ nhị cấp nên mới lấy được vợ là tiến sĩ hóa học!
- anh Sáu là người trí thức nên mới có tư tưởng đổi mới, chống lại phe cộng sản bảo thủ
- bản thân anh Sáu là người trí thức nên anh Sáu mới biết quý trọng người trí thức, chẳng hạn như đã bảo bọc cho nhạc sĩ Trịnh Công Sơn, cấp biệt thự cho Trịnh Công Sơn ở để sáng tác nhạc, phục vụ cho .... đảng!
*Nếu như "bác" Hồ có những câu nói .... ngu để đời, thì anh
Sáu cũng có những câu bá láp, bịp bợm sau đây,
được bọn thổi ống đu đủ ở hải
ngoại vừa thổi vừa hít hà cái mùi ... thối
của nó:*
- Ngày 30 tháng 4 năm 1975 có triệu người vui thì cũng có triệu người buồn.
Tổ quốc Việt
**Nhận xét:**
-
**(Cái
gì cũng "của mình", tức của
người dân, chỉ trừ có cái ngân hàng là thuộc về
nhà nước!** **Đặc biệt cái nhà tù với cái còng
số tám cũng là "của mình"!!!)**
- Kiệt uống rượu mừng thắng lợi với "triệu thằng vui" và đồng thời hắn thò tay móc túi "triệu kẻ buồn". Mâm nào cũng có hắn!!!
Điều cần nhớ là tên Kiệt chỉ dám tuyên bố những câu "ranh ngôn" như vậy sau khi hắn đã về vườn, đóng vai nhà dân chủ cuội, dân chủ dỏm để làm cò mồi chính trị và tiếp tục lừa bịp người dân trong nước và hải ngoại. Những kẻ đầu tôm ngu ngốc gia truyền cứ thấy Kiệt tuyên bố mấy câu "cấp tiến" nêu trên thì đã vội vàng suýt xoa, khen mãi Kiệt là người rất "phóng khoáng, cởi mở"!
Nói một cách ngắn gọn: Kiệt có đầu óc "cấp tiến" hay "cải cách" hay "chống đảng" cũng chỉ nhằm một mục đích chính:
** Việc
làm của hắn về bản chất cũng không khác
gì hai tên việt gian đã chết trước hắn,
đó là Trần Độ và Hoàng Minh Chính. Hắn chủ
trương đổi mới hay cải cách là nhằm giúp cho bộ
máy cai trị của bọn việt gian cộng sản
hoạt động CHỐNG ĐẢNG
ĐỂ CỨU ĐẢNG. **
Chắc hẳn các bạn đã từng nghe tên Kiệt ca sáu câu vọng cổ "cấp tiến" như thế này:
- Các đồng chí ơi, các đồng chí bóc
lột của thằng dân được 10 đồng thì nên
nhả ra bớt 3 đồng cho nó, để nó còn có
đường mà sống. Ăn ít no lâu, ăn
nhiều tức bụng. Đằng này các
đồng chí lột của nó hết 10 đồng mà chỉ
nhả ra có một đồng cho nó thì đói quá, thằng dân
sẽ liều mạng nổi loạn. Tức nước thì vỡ bờ, già néo
thì đứt giây.
**NGHỆ
THUẬT ... BÓC LỘT LÀ PHẢI NHƯ VẬY! ** Có như vậy tụi mình mới
lừa bịp được thế giới và ngồi trên
đầu 80 triệu dân lâu dài được chớ!
Chống đảng là để cứu đảng và cứu đảng chính là cứu chính bản thân tên Kiệt và bè đảng ăn cướp của hắn. Người dân đen hoàn toàn không bao giờ được hưởng một chút xíu lợi lộc gì hết. Thằng chó việt gian cộng sản nào cũng như nhau, cũng có cùng một bản chất với năm đặc trưng, đó là
**THAM
LAM, GIAN ÁC, LƯU MANH, NGU DỐT và HÈN NHÁT.** ** Nghĩa là bọn chúng rất
chó má, ĐỀU CHÓ ĐẺ NHƯ NHAU. **
Tất cả những tên gộc việt gian cộng sản đều có tội với đất nước, không tội ít thì tội nhiều, chớ bọn chúng hoàn toàn không có một công lao gì hết. Cái gọi là "công" đổi mới của Võ Văn Kiệt chính là nhằm giúp cho băng đảng cướp của hắn có cơ hội vơ vét cho mau đầy túi và duy trì quyền lực của bọn chúng được lâu dài.
**Chúng ta phải
ý thức thật rõ điều này và quyết tâm
lật đổ chế độ cộng sản để đem
lại tự do cho đất nước.** Thằng việt gian cộng sản nào cũng tàn
ác như nhau dù là phe miền nam hay phe miền bắc, phe
bảo thủ hay phe cấp tiến, phe thân Nga xô, phe thân
Trung Cộng hay thân Mỹ. Tất
cả đều là những bọn chó săn. Nếu như
trước đây bọn chúng dùng roi cá đuối có gai để đánh
chúng ta thì sau này, nhờ sáng kiến "đổi
mới" của Võ Văn Kiệt, chúng "nhân
đạo" hơn, đánh chúng ta bằng roi điện hoặc
loại dùi cui vuông*, như vậy không thể gọi là
"công lao" hay "nhân đạo" mà đi ca ngợi
bọn chúng! Kết quả của
việc tra tấn đó là dẫn đến cơ thể của chúng
ta bị tàn tạ, mang trọng thương rồi chết.
Làm gì có chuyện "nhân đạo"
ở đây? Không có tội thì đánh cho có tội,
mà đã có "tội" thì đánh cho chừa!
Ba mươi ba năm đã trôi qua mà ở hải ngoại vẫn còn đầy dẫy những tên bồi bút đi bưng bô cho việt cộng. Không thể có một sự ngu lâu như vậy. Chỉ có thể có một sự giải thích hợp lý: đó là
**ĂN XÔI CHÙA NÊN NGỌNG MIỆNG**!
Những tội ác tày trời của tên Sáu Dân Võ Văn
Kiệt thì những tên bồi bút cố ý lờ
đi, bọn chúng chỉ thấy anh Sáu là "người hùng
đổi mới"! Tên bồi bút NND của báo
Người Vẹm ở quận
- Anh Sáu mất đi, các đàn em của anh sẽ bơ vơ. Rồi đây phe cộng sản bảo thủ sẽ loại trừ hết các đảng viên thuộc phe "đổi mới-cấp tiến" của anh Sáu ra khỏi hệ thống quyền lực. Phong trào đổi mới sẽ đi về đâu, tương lai nước Việt
Thật không khác gì giọng điệu của tên bồi bút Tố Hữu khóc người cha chết của hắn là Xít Ta Lin! Thương mình thương một thương ông Sáu Dân thương mười!!! Tên bồi bút NND xứng đáng được đảng việt gian cộng sản trao tặng cho "huân chương bưng bô" hạng nhất!
Nói tóm lại, chết được thằng việt gian nào thì bớt cho người dân một phần gánh nặng như quả núi đang đè lên số phận nghiệt ngã của dân tộc. Để tiễn đưa tên Sáu Dân xuống địa ngục A Tỳ đoàn tụ với "bác" Hồ và các tên dân chủ cuội như Trần Độ, Hoàng Minh Chính, chúng ta nên có một bài "đíu văn", định nghĩa thế nào là việt gian cộng sản, nhằm thức tỉnh những cái đầu tôm ở hải ngoại và ở trong nước:
**(Nhại theo bài thơ "Quê Hương
là chùm khế ngọt" của tác giả Đỗ Trung Quân)**
Việt gian là gì hở mẹ?
Mà cô giáo dạy phải yêu?
Việt gian là gì hở mẹ?
Ai kinh qua phải khiếp hồn?
Việt gian là tên Hồ cáo
Tuổi thơ con hát trong trường
Việt gian là tên Hồ điếm
Tham tàn, Gian ác, Lưu manh
Việt gian là bầy Ác quỷ
Cùng nhau giết hại lương dân
Việt gian là bầy Quỷ dữ
Bán biển, Bán đất, Bán dân!!!
Việt gian là bầy Đàng điếm
Vô cùng Gian ác, Lưu manh
Việt gian là phường Xảo quyệt
Lừa dân, lừa cả loài người!
Việt gian là phường Xảo trá
Lừa dân, lừa cả Phật, Trời!!!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
**Việt-Gian
nếu ai không hiểu ** **Sẽ không
lớn nổi thành người!!!**
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
**Việt gian
nếu ai không hiểu** **Sẽ chôn
vùi hết cuộc đời!!**!
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
**Việt gian
nếu ai lầm tưởng** **Sẽ ân hận suốt cuộc đời!!!**
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
**Việt gian
nếu ai ca ngợi** **Sẽ ân hận suốt nghìn đời!!!**
Việt gian triệu thằng như một
Như là chỉ một Việt-Gian!
**Việt gian
nếu ai thương hại** **Sẽ mang
hận xuống tuyền đài!!!** **Trần Thanh** **Thứ Sáu, ngày 13 tháng
Sáu, năm 2008** *Chú thích:*
1. Hai chữ "việt-gian" trong bài này được dùng như danh từ chung (common noun), chữ "việt" không viết hoa.
2. Thơ Nguyễn Hữu Nhật:
*Dùi cui cả thế
giới tròn* *Phủ tay
vãi thịt thấm đòn nát da* *So với Hà Nội thua
xa* *Góc
vuông chắc gỗ cạnh già sắc lim!*

Server: Apache

Accept-Ranges: bytes