Chiêu mới của spammer

(5s cho quảng cáo: tôi có thiết kế và xây dựng một cái anti-spam appliance có tên là Asas, bạn hãy thử tìm hiểu nó nếu như spam đang là vấn đề của bạn!)

Khi giải thích về sự bùng nổ của spam trong thời gian vừa qua, các chuyên gia trên thế giới thường bàn về việc spammer sử dụng hình ảnh trong spam cũng như việc chúng tận dụng hệ thống botnet với hàng triệu zombie để gửi spam ra ngoài. Thật ra đây không phải là những chiêu thức mới, tôi đã thấy chúng trên hệ thống của mình từ nhiều tháng nay. Hệ thống chống spam của tôi vẫn ngăn chặn được hơn 99.99% lượng spam gửi đến hệ thống của tôi thông qua botnet, dù đó là text spam hay image spam.

Hai kĩ thuật chính mà tôi sử dụng là
greylistingBayesian filtering -1-, trong đó greylisting tự nó đã tiêu diệt được hơn 80% spam rồi, phần còn lại sẽ được Bayesian filtering xử lí nốt. Anh Ngô Quang Hưng trong bài viết mới nhất trên blog của mình có nhận xét các mô hình Bayesian filtering xây dựng dựa trên ý tưởng của Paul Graham không thể chống được image spam. Thật ra theo quan sát của tôi thì Bayesian filtering khá hiệu quả và cho đến thời điểm hiện tại, đó là kĩ thuật duy nhất có thể khắc chế được image spam. Vấn đề của các hệ thống Bayesian filtering là bạn phải dành thời gian để huấn luyện cho nó nhưng người sử dụng cuối lại không thích làm chuyện này. Trong số 1200 khách hàng của tôi, chỉ có khoảng 30 thường xuyên huấn luyện cho bộ filter của họ. Tôi cũng huấn luyện cho bộ filter của mình thường xuyên, kết quả là khoảng vài ba tháng tôi mới nhận được một cái spam và không có email hợp lệ nào của tôi bị nhận nhầm là spam cả. Tuy nhiên, từ hai tuần nay, ngày nào tôi cũng nhận được ít nhất một cái spam. Chuyện gì đã xảy ra?

Thông thường mỗi ngày hệ thống email của tôi chỉ nhận được khoảng 1000-3000 email, bao gồm cả email hợp lệ và spam, vậy mà từ cuối tháng 11 đến nay, không có ngày nào mà tôi nhận ít hơn 5000 email, cá biệt ngày 07/12/2006 tôi nhận đến gần 39.000 email, 99% trong số đó là spam. Bayesian filtering vẫn hiệu quả nhưng greylisting đã bị qua mặt cái rột làm cho đường truyền và các máy chủ của tôi lúc nào cũng nhộn nhịp. Phải chăng bọn spammer đã nghĩ ra chiêu nào mới rồi chăng? Đúng là chúng đã có trò mới làm cho tất cả các kĩ thuật chống spam hiện hành ngoại trừ Bayesian filtering trở nên vô dụng.

Bạn hãy nhìn vào một SMTP session mà tôi chộp được trên máy chủ của mình (sau khi loại bỏ các thông tin nhạy cảm và điều chỉnh lại để có thể gửi lên Blogger):
220 smtp-svr.mydomain.com ESMTP Postfix
HELO mb2i1.ns.pitt.edu
MAIL FROM:[] ENVID=01MAFFI93UXW00LJAJ@mb2i1.ns.pitt.edu SIZE=14336
RCPT TO:[myuser@mydomain.com] NOTIFY=FAILURE,DELAY
DATA
250 2.1.0 Ok
354 End data with [CR][LF].[CR][LF]
Received: from PROCESS-DAEMON.pitt.edu by pitt.edu (PMDF V6.2-X27 #30902)
id [01MAFG5RAHOW00LUPZ@mb2i1.ns.pitt.edu] for myuser@mydomain.com; Thu, 07 Dec 2006 03:28:02 -0500 (EST)
Received: from pitt.edu (PMDF V6.2-X27 #30902) id [01MAFFI8YWXE00LJAJ@mb2i1.ns.pitt.edu]; Thu, 07 Dec 2006 02:16:04-0500 (EST)
Date: Thu, 07 Dec 2006 02:16:04 -0500 (EST)
From: "PITT.EDU Postmaster" [postmaster+@pitt.edu]
Subject: Delivery Notification: Delivery has failed
To: myuser@mydomain.com
Message-id: [01MAFFI94P2W00LJAJ@mb2i1.ns.pitt.edu]
MIME-version: 1.0
Content-type: multipart/report; report-type=delivery-status;
boundary="Boundary_(ID_rdIDymSAUEXxntiG/SdxWQ)"

--Boundary_(ID_rdIDymSAUEXxntiG/SdxWQ)
Content-type: text/plain; charset=us-ascii
Content-language: EN-US

This report relates to a message you sent with the following header fields:

Message-id: [000901c719cf$90cf2e10$00000000@familiez6g65da]
Date: Thu, 07 Dec 2006 08:16:07 +0100
From: Right to [myuser@mydomain.com]
To: denny@dental.pitt.edu
Subject: in ALL FORMATS

Your message cannot be delivered to the following recipients:

Recipient address: denny@dental.pitt.edu
Reason: Remote SMTP server has rejected address
Diagnostic code: smtp;550 5.1.1 User unknown
Remote system: dns;mail.dental.pitt.edu. (TCP|136.142.11.140|1142|136.142.194.83|25)

--Boundary_(ID_rdIDymSAUEXxntiG/SdxWQ)
Content-type: message/delivery-status

Reporting-MTA: dns;pitt.edu (dental.pitt.edu)

Action: failed
Status: 5.1.1 (Remote SMTP server has rejected address)
Original-recipient: rfc822;denny@dental.pitt.edu
Final-recipient: rfc822;denny@dental.pitt.edu
Remote-MTA: dns;mail.dental.pitt.edu.
(TCP|136.142.11.140|1142|136.142.194.83|25)
Diagnostic-code: smtp;550 5.1.1 User unknown

--Boundary_(ID_rdIDymSAUEXxntiG/SdxWQ)
Content-type: message/rfc822

Return-path: [myuser@mydomain.com]
Received: from dental.pitt.edu by pitt.edu (PMDF V6.2-X27 #30902)
id [01MAFFI8YWXE00LJAJ@mb2i1.ns.pitt.edu]; Thu, 7 Dec 2006 02:16:04 -0500 (EST)
Received: from psmtp.com ([64.18.2.80]) by pitt.edu (PMDF V6.2-X27 #30902)
with SMTP id [01MAFFI5GHVM00L7YV@mb2i1.ns.pitt.edu] for denny@dental.pitt.edu;
Thu, 07 Dec 2006 02:16:00 -0500 (EST)
Received: from source ([84.129.101.226]) by exprod7mx78.postini.com
([64.18.6.11]) with SMTP; Thu, 07 Dec 2006 02:15:58 -0500 (EST)
Received: from JFPD (unknown [112.118.33.117]).by mydomain.com with ESMTP id
314AA01CF68F.for [denny@dental.pitt.edu]; Thu, 07 Dec 2006 08:16:35 +0100 (GMT)
Date: Thu, 07 Dec 2006 08:16:07 +0100
From: Right to [myuser@mydomain.com]
Subject: in ALL FORMATS
To: denny@dental.pitt.edu
Message-id: [000901c719cf$90cf2e10$00000000@familiez6g65da]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: multipart/related;
boundary="Boundary_(ID_Pd201HfOT4jSJhrcRe4QtA)"; type="multipart/alternative"
X-Priority: 3
X-MSMail-priority: Normal
X-pstn-levels: (S: 0.00000/66.32415 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )

--Boundary_(ID_Pd201HfOT4jSJhrcRe4QtA)
Content-type: multipart/alternative;
boundary="Boundary_(ID_JTZ73T/gUJLJa0tdNeXVCA)"

--Boundary_(ID_JTZ73T/gUJLJa0tdNeXVCA)
Content-type: text/plain;.charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

Ap and, peoples right to know statement?
All, formats photo video. Press essential, global news network ap and, =
peoples right!

--Boundary_(ID_JTZ73T/gUJLJa0tdNeXVCA)
Content-type: text/html;.charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

[HTML][HEAD]
[META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1"]
[META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR]
[STYLE][/STYLE]
[/HEAD]
[BODY bgColor=3D#ffffff]
[DIV][FONT face=3DArial size=3D2][A HREF=3Dhttp://laryslarys.com/][IMG =
alt=3D"" hspace=3D0=20
src=3D"cid:000401c719cf$90bcde90$00000000@familiez6g65da" =
align=3Dbaseline=20
border=3D0][/A][/FONT][/DIV]
[DIV][FONT face=3DArial size=3D2]Ap and, peoples right to know =
statement?[/FONT][/DIV]
[DIV][FONT face=3DArial size=3D2]All, formats photo video. Press =
essential, global=20
news network ap and, peoples right![/FONT][/DIV]
[/BODY][/HTML]

--Boundary_(ID_JTZ73T/gUJLJa0tdNeXVCA)--

--Boundary_(ID_Pd201HfOT4jSJhrcRe4QtA)
Content-id: [000401c719cf$90bcde90$00000000@familiez6g65da]
Content-type: image/gif;.name="Photos Books.gif"
Content-transfer-encoding: base64
Nhìn vào ba dòng màu đỏ đầu tiên, bạn có thể thấy đây là một email hoàn toàn hợp lệ, được gửi từ mb2i1.ns.pitt.edu đến hệ thống của tôi, với nội dung thông báo cho myuser@mydomain.com rằng email của anh ta gửi đến denny@dental.pitt.edu đã bị từ chối. Nội dung email cũ cũng được đính kèm vào thông báo và gửi lại myuser@mydomain.com. Và bạn có thể nhận ra, nội dung email cũ đó chính là một cái image spam (từ đoạn này trở về sau, ta chỉ tập trung phân tích cái spam này).

Bạn hãy nhìn tiếp vào dòng màu đỏ thứ 4, Received: from JFPD (unknown [112.118.33.117]).by mydomain.com with ESMTP id 314AA01CF68F.for [denny@dental.pitt.edu]; Thu, 07 Dec 2006 08:16:35 +0100 (GMT) . Dòng này nằm trong header của cái spam, với mục đích đưa thông tin cho mail server ở địa chỉ exprod7mx78.postini.com -2- rằng cái spam được nhận từ JFPD - 112.118.33.117 bởi server mydomain.com để chuyển cho denny@dental.pitt.edu. Rõ ràng đây là những thông tin giả mạo, bởi lẽ:
  • tôi không có khách hàng nào ở địa chỉ 112.118.33.117 (IP2Location cũng không biết địa chỉ IP này nằm ở quốc gia nào luôn!)
  • hệ thống mail của tôi chỉ chấp nhận relay đến các địa chỉ @mydomain.com
  • signature trên hệ thống mail của tôi cũng khác xa signature ở trên
Như vậy bạn có thể thấy rằng, một kẻ nào đó ở địa chỉ 84.129.101.226 đang chơi trò "ném đá dấu tay", hắn mạo danh khách hàng của tôi để gửi spam cho người khác. Mục tiêu cuối cùng của spammer là làm sao spam đến được inbox của bạn và với cách làm này thì xác suất để chuyện đó xảy ra tăng lên gấp đôi:
  • nếu denny@dental.pitt.edu là một địa chỉ email có thật thì anh này sẽ nhận cái spam đó
  • nếu denny@dental.pitt.edu không có thật như trong trường hợp này thì khách hàng của tôi ở địa chỉ myuser@mydomain.com sẽ nhận cái spam.
Bạn hãy nhìn vào hai dòng màu đỏ tiếp theo là X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180. Hai dòng này là signature mà tôi đã gặp rất nhiều lần trong các spam gửi ra từ một con zombie trong botnet. Đến giờ tôi vẫn chưa thể hiểu được nguyên nhân cặn kẽ tại sao spam gửi ra từ botnet mà lại có signature y như email gửi bằng Outlook Express. Bọn spammer gửi hàng tỉ email mỗi ngày, chúng không bao giờ chơi kiểu thủ công, ngồi gõ từng email trong Outlook Express rồi nhấn nút gửi đi. Thay vì gõ từng email, chúng sử dụng botnet với hàng triệu zombie để tự động hóa việc gửi spam, chỉ cần gõ một lệnh là có thể gửi ra ngoài vài triệu spam ngay tức thì. Có hai giả thuyết mà tôi nghĩ rằng có thể giải thích được nguyên nhân signature này xuất hiện rất nhiều trong spam (tôi nghiêng về giả thuyết thứ nhất hơn, bạn nào có ý kiến gì khác xin vui lòng chỉ cho tôi được biết với):
  • Các tay spammer cố ý chèn những thông tin trên vào spam để đánh lạc hướng các phần mềm chống spam. Tìm trên Google, tôi thấy có vài rule của SpamAssassin có liên quan đến những header này.
  • Phần mềm mà spammer cài đặt lên máy của zombie tận dụng MineOLE để gửi spam ra ngoài và MimeOLE đã tự động chèn signature của mình vào.
Dẫu signature kia được chèn vào cái spam bằng cách nào đi chăng nữa thì tôi vẫn có thể chắc chắn đến 99% rằng máy tính ở địa chỉ IP 84.129.101.226 đã bị biến thành zombie. Đây chính là nơi mà từ đó cái spam được gửi đến máy chủ exprod7mx78.postini.com.

Ta có thể tổng kết lại đường đi của cái spam này qua ba giai đoạn như sau:
  • Spammer điều khiển zombie 84.129.101.226 để gửi spam có From: Right to [myuser@mydomain.com] To: denny@dental.pitt.edu đến máy chủ exprod7mx78.postini.com
  • Máy chủ exprod7mx78.postini.com chuyển email đó đến máy chủ mb2i1.ns.pitt.edu
  • Máy chủ mb2i1.ns.pitt.edu không tìm thấy địa chỉ denny@dental.pitt.edu trong hệ thống của mình bèn gửi trả ngược lại email đó cho myuser@mydomain.com.
Trong tổng số 35.517 email mà hệ thống của tôi nhận được vào hôm 07/12/2006, có đến 31.895 (chiếm 89,8%) có tính chất tương tự như trên. Chúng đều là những email có tiêu đề kiểu như "Undelivered Mail" được gửi liên tục đến hệ thống của tôi từ 17.519 địa chỉ IP khác nhau. Tôi không có thời gian kiểm tra hết tất cả các IP này, nhưng dựa vào ghi nhận trên hệ thống log, tôi có thể kết luận rằng hơn 95% trong số chúng là những mail server đàng hoàng, không phải là zombie, tương tự như mb2i1.ns.pitt.edu. Máy chủ mb2i1.ns.pitt.edu là một máy chủ mail bình thường, do đó chắc chắn nó sẽ vượt qua được rào cản của greylisting và nó cũng sẽ không nằm trong các danh sách đen! Đây là chiến thuật rất khôn ngoan của các tay spammer, khi chỉ bằng một mũi tên mà chúng đã vô hiệu hóa được hai kĩ thuật rất hiệu quả là greylisting và blacklist -3-.

Vậy làm thế nào để tiêu diệt chúng bây giờ?

Bayesian filtering chắc chắn sẽ là lựa chọn đầu tiên. Bạn có thể thấy rằng có quá nhiều dấu hiệu để nhận diện cái spam ở trên và sự thật là hệ thống Bayesian filtering của tôi vẫn ngăn chặn được khá hiệu quả loại spam này sau khi tôi huấn luyện cho chúng. Tuy nhiên, như tôi đã nói ở trên, bất lợi lớn nhất của Bayesian filtering là bạn buộc phải huấn luyện cho nó đều đặn mà người dùng cuối lại không thích làm chuyện này. Giải pháp của tôi là cung cấp một bộ filter mặc định cho những người không tự huấn luyện. Nếu bạn triển khai thành công Bayesian filtering, chắc chắn nó sẽ loại bỏ được không ít hơn 99% spam mà bạn nhận được, tôi có thể đảm bảo điều đó.

Lựa chọn thứ hai là SPF. Sở dĩ chiến thuật này của spammer thành công vì máy chủ mail exprod7mx78.postini.com không kiểm tra xem địa chỉ IP 84.129.101.226 có nằm trong danh sách được phép gửi email cho domain mydomain.com hay không. Nếu exprod7mx78.postini.com kiểm tra, chắc chắn nó đã không chấp nhận cái spam, bởi lẽ tôi đã công bố SPF record của domain mydomain.com trên máy chủ DNS của mình từ rất lâu rồi. Đây cũng chính là vấn đề của SPF: một ý tưởng hay, tuy nhiên lại có quá ít người triển khai nó thành ra hiệu quả không được cao. Hãy nhanh chân triển khai SPF!

-Thái

---
Ghi chú

-1-: một kĩ thuật chống spam khác cũng khá phổ biến là sử dụng blacklist. Bản thân tôi không thích cách làm này cho lắm bởi đơn giản tôi không muốn một người khác quyết định ai có thể gửi email cho tôi.

-2-: Postini là một công ty chuyên làm về anti-spam. Bạn có thể thấy trong trường hợp này pitt.edu đã sử dụng dịch vụ của Postini nhưng Postsini vẫn không thể ngăn chặn được cái spam đó.

-3-: ngoài bayesian filtering, greylisting và blacklist ra, người ta còn sử dụng các kĩ thuật như Razor, DCC hay Domain Keys. Những kĩ thuật này cũng không có tác dụng trong trường hợp này, bởi lẽ người gửi spam đến cho bạn không phải là spammer (hay zombie) nữa mà là một máy chủ mail hợp pháp!


Comments

Anonymous said…
Hello Thái, tôi chỉ nói đến kiểu text content-based filters như Paul Graham đề nghị thôi — các thế hệ filters mới sẽ phải có thành phần xử lý ảnh, không thể dựa trên nội dung text không thôi được. Nếu không sẽ có nhiều false positives khi bạn thật sự hay trao đổi ảnh với bạn bè. Nếu bọn nó dùng ý tưởng kiểu captcha trong hình ảnh thì còn phiền toái hơn. Captcha được thiết kế chống spam, nhưng hoàn toàn có thể thành công cụ của spammers.

Tôi đồng ý là các spam filters hiện tại thực ra vẫn còn khá tốt và chính xác khoảng 99%, nhất là khi users chịu khó click “junk”, “not junk”, “junk”, “not junk”, … :-) . Nhưng khi mà 90% emails là rác, thì 1% mail rác lọt vào mailbox của chúng ta đã là nhiều lắm rồi. Filtering mãi không phải là giải pháp tận gốc.

Đây là chưa tính đến phí phạm rất lớn của các tài nguyên tính toán (máy chủ, bandwidth, ...).
Anonymous said…
Hi Thái,

Trường hợp Thái gặp na ná trường hợp anh gặp trước đây (và vẫn còn đang gặp):

# Spammer điều khiển zombie 84.129.101.226 để gửi spam có From: Right to [myuser@mydomain.com] và To: denny@dental.pitt.edu đến máy chủ exprod7mx78.postini.com
# Máy chủ exprod7mx78.postini.com chuyển email đó đến máy chủ mb2i1.ns.pitt.edu
# Máy chủ mb2i1.ns.pitt.edu không tìm thấy địa chỉ denny@dental.pitt.edu trong hệ thống của mình bèn gửi trả ngược lại email đó cho myuser@mydomain.com.

giả sử spammer compose 1 list users thuộc domain A(users)@domainA.com

Nó chỉ đơn giản insert MAIL FROM vào header (for each trong loop) và gởi đến một SMTP nào đó có username không tồn tại là cả tỉ mail sẽ "bounce" về đúng nạn nhân.

Cái này qua mặt hàng khối spam filtering system bởi vì hầu như không có SMTP nào filter mail từ "mailer-daemon" cả. Hơn nữa, mail message được "enveloped" và smtp gởi bounce thường là các IP không nằm trong blacklist.
Anonymous said…
Chào Thái,
Tôi thấy bài của Thái rất có giá trị. Nhưng tôi chưa hề triển khai một hệ thống lọc spam bao giờ cho nên chưa thể hiểu hết ngay được bài này. Tôi mong Thái giúp tôi một số điểm khác như sau:
1. Nên triển khai và vận hành một hệ thống lọc mail spam như thế nào (software, configuration, ...)?
2. Làm thế nào để biết chắc rằng hệ thống đó không lọc nhầm những thư bình thường?
3. Trong trường hợp lọc nhầm, làm thế nào để khôi phục lại những thư đó?
Mong nhận được sự giúp đỡ của Thái cũng như các anh tham gia vào blog này.
Thai Duong said…
Chào bạn anonymous,

Thiết kế và xây dựng một hệ thống chống spam hiệu quả không phải là một vấn đề có thể tóm gọn được trong phạm vi một bài viết. Người ta đã viết về đề tài này khá nhiều, nếu bạn có hứng thú thì nên tìm đọc những cuốn sách sau: Ending Spam và Slamming Spam: A Guide for System Administrators.

Về các câu hỏi của bồ, tôi xin trả lời như sau:

1. Nên triển khai và vận hành một hệ thống lọc mail spam như thế nào (software, configuration...)?

Kinh nghiệm của tôi cho thấy, tốt nhất bạn nên xây dựng hệ thống chống spam tách biệt với hệ thống mail của bạn, theo mô hình SMTP Proxy. Hệ thống chống spam lúc này sẽ đóng vai trò là mail gateway, mail từ Internet sẽ đi qua hệ thống chống spam trước khi nó được chuyển đến hệ thống mail ở bên trong.

2. Làm thế nào để biết chắc rằng hệ thống đó không lọc nhầm những thư bình thường?
3. Trong trường hợp lọc nhầm, làm thế nào để khôi phục lại những thư đó?

Thông thường thì tất cả các giải pháp chống spam đều không xóa hẳn email mà nó cho là spam, mà chỉ cách ly (quarantine) email đó ra một mailbox và thông báo cho người dùng biết để họ có thể đánh giá về email đó.

-Thái.
Anonymous said…
T có thể chỉ giúp mình cách chống spam trong mdaemon không, đang làm đề tài mà không biết về cái này chỉ mới tìm hiểu. Làm ơn nghen!. Dành chút thời gian chỉ điểm giúp. cảm ơn trước vậy.
TUNGOC