Messages posted by: mrro

Cái hay không phải là việc đi tìm giải pháp, mà nó nằm ở chỗ "hướng tiếp cận vấn đề" như thế nào. Về khả năng tiếp cận vấn đề, thành thật mà nói thì người VN chúng ta còn thua kém bọn "tây" rất xa.
Người ta thì nhìn vấn đề và giải quyết từ gốc đến ngọn, nhiều khi chỉ cần chặt phần gốc xong là phần ngọn tự nó cũng tiêu tan. Còn chúng ta thì chỉ thấy phần ngọn, chặt cái ngọn, rồi hả hê với nhau, trong khi cái gốc còn nguyên, chỉ cần dăm ba cơn mưa rào là đâu lại vào đấy.

Xét ở mặt vĩ mô, liệu chúng ta đã có ai thử nghĩ: tại sao chỉ có VN mới có mấy cái vấn nạn kiểu như "gaixinh" hay "funni" trong khi ở nước ngoài thì hầu như không có hoặc có rất ít?
Báo chí VN cũng không hề thấy câu hỏi này mà chỉ toàn thấy tung hô những chiến tích (ảo) khi chúng ta chặt được cái phần ngọn và những bài viết mà đọc vào ta có cảm tưởng như những người viết ra mấy con virus đó là những "kỳ tài trong tin học".

Vấn đề cốt lõi nằm ở ý thức của con người!
- Ý thức của người viết chương trình
- Ý thức của người sử dụng

Nếu chúng ta không dập tắt những ý nghĩ "viết được con virus như vậy là anh hùng", "thà làm 1 phút huy hoàng (được ... lên báo?)" thì hết gaixin rồi sẽ đến funni rồi đến thứ khác nữa.
Và nếu người dùng của chúng ta "bạ đâu cũng click", "file nào cũng load chạy thử" thì dù có cài version 100.0 của chương trình bác Hoàng hay áp dụng 10 lần cái hay hơn ý tưởng của bác Thái thì cũng "chết vì ngu" như thường.

Đâu từ 10, 20 năm trước cho tới tận bây giờ, trên báo, đài, TV vẫn có chuyên mục câu chuyện cảnh giác để giúp người dân nâng cao kiến thức (phòng tránh) và ý thức (tố giác bọn tội phạm).
Luật VN đã có qui định người viết virus là tội phạm, phát tán virus là vi phạm pháp luật. Nhưng ngoài những bài viết "ngầm" ca tụng mấy tên script kiddie và tung hô "chiến tích lẫy lừng" của những "anh hùng CNTT" thì tuyệt nhiên không thấy những hành động cụ thể nào để nhằm nâng cao kiến thức và ý thức của người làm tin học cả!

Hì những gì bồ nbthanh nói không có gì là mới cả, bản thân tui cũng đã có một http://blog.360.yahoo.com/blog-9hIPHNAlc6d3QoYURIU-?cq=1&p=143 có nội dung tương tự từ cách đây hơn một tháng:

...
Kể cũng lạ thiệt, chắc không nơi nào trên thế giới như ở VN khi mà bọn tội phạm đến một tờ báo online, chứ không phải cơ quan công an, để phân trần, chứ không phải để khai báo về hành vi phạm tội của mình. Haha, Vietnamnet đúng là chuối, đăng cả hình thằng đó lên vậy mà còn viết tắt họ tên. WTF? Cơ quan công an cũng chuối nốt, chẳng thấy động tịnh gì sấc. Cứ cái đà này thì sẽ còn xuất hiện nhiều con virus khác nữa. Viết virus = được lên báo mà, giống như tuyên dương người tốt việc tốt.
...

Hì tui thấy bồ nbthanh rất thích đem chuyện nước ngoài, chuyện Tây để nói về chuyện VN, thành ra cũng mạn phép hỏi bồ là ở nước ngoài chắc nó không có virus đâu phải không? Tại theo cách bác nói thì nó đã giải quyết được tận gốc của vấn đề rồi mà. Châm chọc tí cho vui, tui cho rằng sẽ là rất thiếu thực tế khi nghĩ rằng chỉ cần giáo dục và răn đe là có thể tiêu diệt được tội phạm. Mọi xã hội ở mọi thời đại đều có tội phạm và con người ta luôn cần những công cụ ngăn ngừa bọn tội phạm đó. Đó là về phía tội phạm, về phía user, những ai nghĩ rằng chỉ cần giáo dục, rèn luyện họ là có thể ngăn ngừa được virus thì chắc là chưa bao giờ làm về security cả.

Nói về chuyện Tây thì cũng xin thưa với bồ nbthanh là ở Tây nó chẳng có ba cái con kiểu như "gaixinh" hay "funni" đâu, nó chỉ có botnet với hàng triệu zombie mà thôi. Ngoài ra theo tui được biết thì các chương trình antivirus mà bồ nbthanh có đề cập đều xuất phát từ "Tây" mà ra cả. Nếu họ đã "giải quyết tận gốc" vấn đề thì xin bồ nbthanh giải thích giùm những sự thật ở trên.

Đi sâu hơn 1 chút về vấn đề kỹ thuật. Với cách giải quyết của bác Thái, "greylisting", "challenge-response" rồi "Bayesian filtering" nghe rất là mĩ miều và hứa hẹn. Nhưng nếu tôi nhớ không lầm thì Edison (và các nhà khoa học vĩ đại khác) đều nghiên cứu và thực nghiệm trước rồi mới công bố kết quả thực nghiệm (tức là họ đi từ gốc cho đến ngọn, và trên thực tế họ vĩ đại cũng vì 1 lẽ đơn giản như vậy) chứ không ai làm ngược lại xây cái nóc nhà rồi lúc lắp xuống mới không thấy cái móng và tường nhà ở đâu để mà lắp.

Hì tui gửi ý tưởng lên đây, với 3 chữ đầu tiên là RFC, ý của tui là nhờ mọi người xem xét, đóng góp xem liệu ý tưởng đó có khả thi cả về mặt kĩ thuật lẫn mặt usability hay không. Tui có mặt hạn chế là không đưa ra phiên bản demo trước khi trình bày ý tưởng của mình thành ra tui chưa lường được những khó khăn mà mình sẽ gặp phải trong quá trình triển khai thực tế. Tuy nhiên trong quá trình tranh luận, tui cũng nhận ra được nó không phù hợp về mặt kĩ thuật và có nhiều điểm cần phải bàn về mặt usability. Điều này giúp tui không phải tốn công sức ngồi triển khai một giải pháp đã phá sản ngay từ ở khâu ý tưởng. Tui hoàn toàn đồng ý với bồ nbthanh, lẽ ra chính bản thân tui phải thấy được những khuyết điểm của mình để không làm tốn công sức của những người khác, nhưng bồ cũng biết rồi đó, tui chẳng vĩ đại như Edison để mà có thể tự thấy được hết những lổ hỏng trong suy nghĩ của mình.

Tôi cũng rất mong bác Thái được như Edison hay 1 phần của Edison. Dù sao cũng là sự nở mày nở mặt của dân VN ta, nhưng trên thực tế thì bác Thái của chúng ta vẫn còn chưa

Hì, rất tiếc phải phụ lòng bồ nbthanh bởi lẽ tui chưa bao giờ mơ ước được trở thành Edison của VN cả.

Người ta có thể đánh giá cao ý tưởng của bạn, nhưng bạn chỉ trở nên có ích cho nhân loại khi ý tưởng của bạn thực hiện được và đem lại lợi ích cho cộng đồng (chứ thế giới có 6 tỉ người thì mỗi ngày chắc cũng có cỡ...1 tỉ ý tường hay ra đời!).

HÌ tui không hiểu câu nói này của bồ nbthanh có hàm ý điều gì trong đó, bởi lẽ tui đọc đi đọc lại mãi mà vẫn thấy nó xưa như trái đất và hoàn toàn chẳng ăn nhập gì với đề tài đang bàn luận ở đây.

Thay vào những thứ "đao to búa lớn" như "challenge-response" hay "Bayesian filtering" (nghe hay thật đấy, mĩ miều thật đấy nhưng...kết quả áp dụng như thế nào?), ta thử tiếp cận theo 1 hướng khác "bình dân" hơn 1 chút thử coi sao: scan ngay cái link được gởi qua chat.
Đằng nào thì giải pháp của bác Thái cũng thu gọn về việc ngăn user tiếp cận với các link độc hại. Vậy thì thay vì tạo thêm phiền hà cho user qua cái challenge-response, mình chỉ cần scan cái link được gởi đi thì sẽ đơn giản và hiệu quả hơn nhiều, và đây cũng là cách các chương trình scan virus áp dụng.
- Nếu link là 1 site, thì các site "độc hại" đều có 1 dấu hiệu nhận dạng chung là "tự động load và thực thi 1 đoạn mã nguy hại nào đó". Nếu link được gởi qua chat được chương trình của ta nhận dạng ra được thì...a lê hấp, xử sao thì xử.
- Nếu link là 1 file thực thi thì chương trình của ta có thể không làm gì được nhiều, nhưng phần việc còn lại đã có các chương trình anti-virus lo rồi (ta không nên bao đồng mà ôm đồm nhiều quá!). Tuy nhiên, ít ra chương trình của chúng ta có thể send 1 thông điệp tới user (hoặc cả 2 user) chằng hạn như là "file này là file thực thi, nó có thể gây nguy hiểm cho máy tính của bạn, hãy cẩn trọng, v.v...". Như vậy cũng góp phần nâng cao ý thức của user và ít nhiều cũng làm user "suy nghĩ 2 lần" trước khi chạy 1 file từ internet.

Bồ nbthanh quả là có nghề trong nghệ thuật dẫn dắt câu chuyện, bồ nên đăng kí thi làm MC đi. Từ chỗ cho rằng việc làm của tui là vô ích, và sau khi tui đã giải thích là nó có ích, bồ dẫn dắt qua hàng loạt chuyện khác, bây giờ là đề tài kĩ thuật. Rất tiếc là bồ nbthanh không đọc rõ ý tưởng mà tui trình bày, vấn đề mà tui đang cố giải quyết nên mới lập lại những gì tui đã viết.

Về cái gạch đầu dòng thứ nhất, đó chẳng phải là nội dung của ý tưởng về whitelist và blacklist. Về cái gạch đầu dòng thứ hai, ngay từ bên topic Phòng chống các loại SPIM viết bằng AutoIt, tui cũng đã không tán thành việc tạo ra thêm một chương trình anti-virus kiểu như IEProtector. Cái ý send thông điệp tới user là một kiểu của trường phái "giáo dục user" và tui thì luôn tin rằng "giáo dục user" một mình nó chẳng bao giờ có thể bảo vệ được user. Có hai bài viết của "Tây" rất hay về đề tài này, http://www.schneier.com/blog/archives/2006/08/educating_users.html của Schneier Bruce và http://www.ranum.com/security/computer_security/editorials/dumb/index.html của Marcus Ranum, bồ nbthanh nếu có thời gian thì nên đọc qua:

The real question to ask is not "can we educate our users to be better at security?" it is "why do we need to educate our users at all?" In a sense, this is another special case of "Default Permit" - why are users getting executable attachments at all? Why are users expecting to get E-mails from banks where they don't have accounts? Most of the problems that are addressable through user education are self-correcting over time. As a younger generation of workers moves into the workforce, they will come pre-installed with a healthy skepticism about phishing and social engineering.

Dealing with things like attachments and phishing is another case of "Default Permit" - our favorite dumb idea. After all, if you're letting all of your users get attachments in their E-mail you're "Default Permit"ing anything that gets sent to them. A better idea might be to simply quarantine all attachments as they come into the enterprise, delete all the executables outright, and store the few file types you decide are acceptable on a staging server where users can log in with an SSL-enabled browser (requiring a password will quash a lot of worm propagation mechanisms right away) and pull them down. There are freeware tools like MIMEDefang that can be easily harnessed to strip attachments from incoming E-mails, write them to a per-user directory, and replace the attachment in the E-mail message with a URL to the stripped attachment. Why educate your users how to cope with a problem if you can just drive a stake through the problem's heart?

Về những từ chữ như "challenge-response" hay "bayesian filtering", tui thấy nó hoàn toàn bình thường đối với ai quan tâm về security. Nên nhớ chúng ta đang ở trong một forum về security để thảo luận về security. Chẳng ai biết được kết quả thực tế khi triển khai các ý tưởng này và tui tin rằng đó là lý do mà tui ngồi ở đây tranh luận với bồ nbthanh và tất cả mọi người. Tất cả hay ít nhất là tui đều mong muốn có một giải pháp gọn đẹp cho một vấn nạn lầy lội.

-m

nbthanh wrote:

Tôi đang tự nghĩ bác Hoàng với bác Thái giờ đang rảnh rang quá, hay là hết nghĩ ra chuyện gì hay hay để làm rồi hay sao ấy nhỉ?

Ngoài cái lợi nho nhỏ trước mắt là website của các bác được người ta vào để...download chương trình, còn lại nhìn tới nhìn lui, nhìn qua nhìn lại tôi chưa thấy người dùng có lợi lộc gì từ chương trình hay ý tưởng của 2 bác cả, đó là chưa kể "lợi thì có lợi nhưng răng không còn"

Hì, có thể đối với bồ nbthanh thì việc tìm kiếm giải pháp cho spim chẳng có gì hay nhưng đối với tui thì đây là việc làm rất lý thú. Ít nhất nếu tìm ra được một giải pháp hiệu quả thì nó cũng giải quyết được một vấn đề thiết thực mà rất nhiều người đang gặp phải. Trong thời gian rảnh rỗi thay vì làm những chuyện vô bổ thì ngồi suy nghĩ việc phòng chống spim đối với tui là một công việc hấp dẫn. Tui chẳng biết mình có thành công hay không nhưng tui biết mình sẽ học được nhiều điều từ quá trình tìm tòi để sáng tạo ra cái mới. Ngoài ra nếu may mắn thành công, tui sẽ có cơ hội quảng bá cho công ti của mình.

Trong quá trình tìm kiếm giải pháp dĩ nhiên sẽ có những ý tưởng hay sản phẩm không đạt yêu cầu. Đó là chuyện hoàn toàn bình thường, ngay cả Edison vĩ đại đến vậy mà cũng phải mất cả 2000 lần mới chế được bóng đèn điện mà. So sánh việc chống spim với việc tạo ra bóng đèn điện quả là khập khiễng nhưng cả hai việc làm này giống nhau ở điểm là đều giải quyết một vấn đề của xã hội. Hàng chục nghìn máy tính bị nhiễm virus lây lan qua YIM, tui với tư cách là một người làm trong ngành an ninh máy tính, tự nghĩ rằng mình phải có trách nhiệm tìm kiếm giải pháp cho vấn nạn này. Nếu chúng ta, những người có chuyên môn, không giải quyết vấn nạn này thì ai sẽ giải quyết nó?

-m

PS: mấy hôm nay bận quá tui không có thời gian suy nghĩ tiếp về đề tài này. Hi vọng cuối tuần tui sẽ tìm được một giải pháp đẹp nào đó :p.

challenge code là 1 string trong cửa sổ Windows hay 1 bitmap vậy ?

Challenge code là một string nằm trong cửa sổ Windows.

Ngoài ra, nếu user kia send 1 phát rồi offline, vậy thì cái message đó sẽ không bao giờ đến với user nhận ?

Tất cả các msg đã nhận mà chưa được confirmed đều được lưu vào database, không có chuyện mất msg ở đây.

Với mỗi người phải reply đoạn code 1 lần, chat với 10 người thì trả lời bao nhiêu lần ?

Hì, bồ không đọc kĩ những gì tui viết rồi:

- Chỉ có msg chứa link mới phải đi qua challenge-response.

- Người nhận msg không phải làm gì cả, chỉ có những người nhận mới phải thực hiện thao tác challenge-response. Tui là người nhận msg, tui không muốn nhận msg chứa link tới virus do đó tui yêu cầu tất cả những người gửi msg cho tui phải đi qua thao tác challenge-response mà tui đưa ra. Nếu bồ thật sự muốn gửi link đến cho tui thì việc gửi thêm một challenge-code không phải là điều quá bất tiện.

Đây chính là giải pháp. Rất đơn giản không khó như mrro nghĩ đâu

Chà, có vẻ như ý tưởng này đã phá sản bởi vì tui vừa tham khảo API của AutoIt, nó có hỗ trợ hàm WinGetText để capture text từ một cửa sổ Windows. Tui luôn nghĩ nó không có khả năng làm chuyện này. Sorry mọi người vì sự cẩu thả này.

Như vậy kĩ thuật greylisting mà tui trình bày ở trên không còn có tác dụng. Whitelist và blacklist thì vẫn còn chơi được. Có lẽ đã đến lúc phải nghĩ đến giải pháp cuối cùng là sử dụng Bayesian filtering. Tui sẽ viết kĩ hơn về whitelist, blacklist và Bayesian filtering trong bài viết tới.

-m

PS: cảm ơn bồ LeVuHoang, nếu không thảo luận với bồ về đề tài này thì tui đã cấm đầu cấm cổ implement cái ý tưởng greylisting ở trên mà không tham khảo lại cách làm việc của AutoIt.

Mr.Ñººb wrote:

1. Yahoo Messenger có cung cấp plugin để nhận/gửi message hay ko, tui chưa biết, nhưng khả năng này nếu có thì hạn chế, vì việc cung cấp những API như vậy một cách thoải mái sẽ dẫn tới nạn SPIM và ăn cắp những message một cách bất hợp pháp thông qua plugin.

Câu trả lời là có. Xin vui lòng tham khảo Yahoo! Messenger Plugin SDK.

2. Tui giả sử là về mặt kỹ thuật có thể thực hiện được ý tưởng của bạn mrro, có thể dùng Yahoo Plugin để thực thi việc nhận/gửi message.
- Giả sử một người dùng hợp pháp cần gửi và họ phải thông qua cơ chế challeng code, liệu họ có đủ kiên nhẫn để thực hiên challenge hay ko?
- Cơ chế nào đảm bảo virus (ko chỉ là AutoIT) ko đọc được challence code, theo tui biết, hiện nay, yahoo messenger chưa hỗ trợ việc truyền nhận image trong cửa sổ chat(???)
- Giả sử có thể có việc truyền nhận image dùng làm challenge code, lỡ cái image đó khó đọc và
người gửi gõ sai, như thế họ, sẽ phải gửi lại từ đầu rất là phiền phức.
- Điều gì xảy ra khi người gửi muốn gửi một link hay cho một group friend list 200 người, khi đó họ sẽ phải gõ tới 200 cái challenge code?
Nếu dùng standalone soft thì ko phụ thuộc vào API nhưng vẫn còn đó các vấn đề sau cùng

- Nhiệm vụ của chúng ta là bảo vệ người dùng. Khi Bob quyết định sử dụng phần mềm của chúng ta, anh ta đã quyết định rằng tất cả những người muốn gửi link cho anh ta đều phải đi qua cơ chế challenge-response. Chính Bob chứ không ai khác là người đưa ra qui định kiểm soát msg gửi đến mình. Chúng ta chỉ giúp Bob hiện thực hóa qui định đó bằng phần mềm. Nếu như Alice muốn gửi msg đến Bob thì hiển nhiên Alice phải tuân theo các qui định mà Bob đưa ra. Nếu Alice không đủ kiên nhẫn để gửi lại challenge code thì chứng tỏ Bob cũng không cần nhận msg đó.

- Không có gì đảm bảo virus sẽ không chôm được challenge code. Tui chỉ nói là rất khó. Tui mường tượng để chôm được challenge code này, con virus phải làm được một trong những chuyện sau đây:

+ Có khả năng thông hiểu yahoo! messenger protocol để có thể sniff được cái msg ra từ mớ yahoo! messenger packet.

+ Sử dụng WinAPI để capture đoạn text từ cửa sổ chat của user.

Theo tui biết thì hiện tại AutoIt script không có khả năng làm chuyện này. Dĩ nhiên là một chương trình viết bằng một ngôn ngữ lập trình mạnh hơn kiểu như Delphi hoàn toàn có khả năng làm chuyện này, nhưng tui tin rằng:

+ Chẳng ai đủ thông minh viết một chương trình như vậy lại đi viết virus. Nếu có đi chăng nữa thì lượng người này là rất thấp và số lượng virus dạng này là rất ít nên chúng ta có thể an tâm bỏ qua sự hiện diện của chúng.

+ Khi ý tưởng greylisting ra đời, cũng có nhiều ý kiến lo lắng là đến một lúc nào đó, spammer sẽ tuân theo RFC để bypass greylisting. Thực tế cho đến nay, năm 2006, nghĩa là hơn 3 năm kể từ ngày người ta công bố kĩ thuật này, greylisting vẫn rất hiệu quả. http://www.innology.com.vn/products/asas chặn được hơn 90% spam nhờ vào greylisting. Điều này cho thấy chắc chắn lượng virus có khả năng chôm challenge-code sẽ cực hiếm.

- Tui không nghĩ đến chuyện sử dụng cơ chế challenge-response bằng hình ảnh.

- Việc gửi mass msg trên YIM là một hành vi rất thiếu văn hoá, do đó tui hi vọng phần mềm này phần nào sẽ giảm thiểu được hành vi này.

-m

LeVuHoang wrote:

uhm, vậy mrro trình bày phương pháp chống mọi loại SPIM xem ?

Nó có ở http://vnhacker.org/hvaonline/posts/list/4087.html.

Chào mọi người,

Trong topic http://vnhacker.org/hvaonline/posts/list/4002.html tui có đề cập đến một số ý tưởng của tui để giải quyết một cách trọn vẹn vấn đề SPIM (qua đó góp phần hạn chế sự lây lan của AutoIt virus). Bài viết này sẽ trình bày những ý tưởng đó, tui gửi lên đây mong nhận được góp ý của tất cả mọi người.

0. Giới thiệu

Dựa vào kinh nghiệm xây dựng hệ thống anti-spam, tui cho rằng các kĩ thuật anti-spam mà chúng ta đang sử dụng hiện tại như Bayesian filtering, whitelist, blacklist...đều có thể được áp dụng để giải quyết vấn đề anti-spim. Trong bài viết này, tui xin trình bày giải pháp dựa trên ý tưởng http://greylisting.org. Tui cho rằng một mình greylisting không thể giải quyết trọn vẹn vấn đề anti-spim nhưng đây là một ví dụ sinh động về cách áp dụng các giải pháp anti-spam cho vấn đề anti-spim. Tui tin rằng một giải pháp kết hợp các ý tưởng greylisting, whitelist, blacklist và Bayesian filtering sẽ đủ khả năng tiêu diệt hoàn toàn spim.

(5s cho quảng cáo: http://www.innology.com.vn có xây dựng một giải pháp anti-spam áp dụng đầy đủ các kĩ thuật kể trên, tên gọi là http://www.innology.com.vn/products/asas. Tất cả những ý tưởng trình bày trong tài liệu này đều được trích rút ra từ quá trình thiết kế và xây dựng Asas)

1. Yêu cầu chung

Tui có tự đặt ra cho mình các tiêu chí chung sau đây của các giải pháp:

- Mục tiêu của các giải pháp là user không còn nhận spim nữa.

- Phải tiện dụng cho user, tốt nhất là hoàn toàn trong suốt với user.

- Tốc độ phải thoả mãn tiêu chí "instant".

- Cũng tương tự như spam, spim "tiến hoá" theo thời gian, do đó giải pháp đưa ra phải có khả năng tự thích nghi và tự điều chỉnh với các loại spim sẽ xuất hiện trong tương lai.

Tất cả các giải pháp không thoả mãn được ít nhất 2 trong 4 tiêu chí trên đều phải được xem xét lại trước khi hiện thực.

2. Ý tưởng

Tui hi vọng là khi đọc đến phần này, mọi người đã tham khảo sơ qua kĩ thuật http://greylisting.org. Giải pháp của chúng ta là xây dựng một phần mềm (có thể là một standalone software hoặc là một plugin cho Yahoo! Messenger hoặc có thể là cả hai) thực thi cơ chế greylisting trên IM. Phần mềm của chúng ta phải có khả năng làm những việc sau đây:

- Thấy được tất cả các msg gửi đến user đang sử dụng YIM.

- Có khả năng thay đổi hay thậm chí drop các msg đó trước khi nó được gửi đến YIM.

- Có khả năng gửi msg ra ngoài sử dụng tài khoản YIM của user.

Để đơn giản, chúng ta sẽ chỉ xét các msg có chứa đường link. Khi nhận được các msg này, thay vì deny như cách làm của greylisting khi chống spam mail, chúng ta sẽ thực thi cơ chế challenge-response như sau:

- tạm thời lưu msg đó vào database.

- tự động gửi ngược lại cho sender một đoạn challenge code dài 6 kí tự (có thể thay đổi số lượng kí tự). Đoạn challenge code này được gửi như một instant msg thông thường.

- nếu sender gửi lại cho chúng ta đoạn challenge code đó, chúng ta sẽ hiển thị msg đã lưu ở trên ra cho user.

Phần mềm chúng ta có tác dụng bởi lẽ:

- sẽ là rất khó cho virus chôm được challenge code.

- sẽ là rất dễ cho con người thấy được challenge code.

3. Một vài use case

Giả sử chúng ta có 3 user: Alice, Bob và Mallory. Alice muốn gửi một msg đến Bob thông qua YIM, Bob có cài đặt phần mềm của chúng ta còn Mallory thì đã bị nhiễm virus có cơ chế lây lan qua YIM. Bob có trên friend list của cả Alice và Mallory.

3.1. Alice gửi một msg có chứa link đến Bob

- Phần mềm của chúng ta sẽ thực thi cơ chế đã đề cập ở trên.

- Alice thấy challenge code, gửi lại cho Bob (thực chất là gửi cho phần mềm của chúng ta) đoạn code đó.

- Chúng ta sẽ hiển thị msg đó như bình thường cho Bob thấy.

- Bob sẽ không hề biết chuyện gì đã xảy ra trước khi đọc được msg từ Alice.

3.2. Mallory hay là virus trên máy của anh ta gửi một msg có chứa link đến Bob

- Phần mềm của chúng ta sẽ thực thi cơ chế đã đề cập ở trên.

- Virus trên máy của Mallory không thể thấy được challenge code, do đó Bob sẽ không bao giờ nhận được spim gửi bởi con virus này.

- Bob sẽ không hề biết chuyện gì đã xảy ra tương tự như trên.

4. Whitelist và blacklist

Để tăng tính tiện dụng cho user, chúng ta sẽ cho phép họ tự quản lí:

- Whitelist: danh sách các URL mà họ cho phép xuất hiện trong các msg, ví dụ như vnexpress.net, www.tuoitre.com.vn...Khi các đường link trong msg nằm trong whitelist thì chương trình của chúng ta sẽ không thực thi cơ chế challenge-response kể trên mà tự động hiển thị msg cho user.

- Blacklist: danh sách các URL mà họ không cho phép xuất hiện trong các msg, ví dụ như các website chứa virus đã được công bố. Khi một đường link trong msg nằm trong blacklist thì chương trình của chúng ta sẽ không thực thi cơ chế challenge-response kể trên mà tự động drop msg đó.

Ngoài ra nếu có điều kiện, chúng ta cũng sẽ triển khai một global blacklist tương tự như cách làm của các dự án như Spamhaus chẳng hạn.

5. Kết luận

Bài viết này trình bày sơ lược về việc áp dụng kĩ thuật greylisting để phòng chống spim. Để đơn giản, chúng ta chỉ xét đến các msg chứa một hay nhiều đường link. Chúng ta áp dụng cơ chế challenge-response để đảm bảo rằng msg mà chúng ta nhận được là do một con người gửi chứ không phải một chương trình phần mềm. Để tăng tính tiện dụng, chúng ta cũng áp dụng cơ chế whitelist và blacklist thường thấy khi chống spam.

Như đã trình bày ở phần đầu, tui cho rằng một mình kĩ thuật greylisting không thể giải quyết trọn vẹn vấn đề spim. Đây chỉ là một ví dụ sinh động cho việc áp dụng các kĩ thuật chống spam để chống spim.

Hi vọng sẽ nhận được góp ý từ mọi người, cả về ý tưởng lẫn khả năng hiện thực nó,

-m.

Hì, đúng là bồ LeVuHoang không hiểu ý tui nói. Để tui nói lại lần nữa, IEProtector có thể là một chương trình tốt nhưng nó không thể giải quyết được vấn đề SPIM. Bảo vệ IE và chống SPIM là hai vấn đề hoàn toàn khác nhau. IEProtector có thể được sử dụng để giúp user lướt web an toàn hơn với IE nhưng nó không thể giúp user hoàn toàn tránh khỏi vấn nạn SPIM.

- SPIM không có link là những SPIM theo kiểu hoax dạng như "ở bệnh viện Việt Đức có em bé blah blah blah".

- SPIM có link nhưng link đó lại không chứa virus mà là website có nội dung xấu.

- SPIM có link, khi click vào link, user sẽ download (chứ không chạy tự động) một con trojan nào đó (không viết bằng AutoIt).

- User sử dụng một loại browser khác.

Tui xin liệt kê lại 4 bước để phát tán virus qua IM:

1. Tác giả kích hoạt virus bằng cách gửi một msg chứa đường link đến virus cho friend list của mình.

2. Một nhóm người trong friend list của tác giả click vào đường link.

3. Browser của họ (có thể là IE hoặc Firefox) download và chạy con virus (một cách tự động hoặc không tự động).

4. Virus nhiễm vào máy tính của những người này và nó bắt đầu quay lại thực hiện bước 1 với một hoặc nhiều msg khác nhau.

IEProtector bảo vệ user ở bước 3 và 4 nhưng vấn đề của SPIM là nằm ở bước thứ 2: chúng ta cần phải bảo vệ user để họ không thấy SPIM. Nếu họ không thấy SPIM thì sẽ không có chuyện click vào đường link. Nếu họ không click vào đường link thì sẽ không cần IEProtector. Rõ ràng IEProtector chỉ cần thiết khi user đã thấy, đã đọc và đã click vào link, nghĩa là đã nhận SPIM rồi. Do đó nói IEProtector có thể chống SPIM là sai. Nó chỉ có khả năng giúp user bảo vệ IE của mình, đúng như tên gọi của nó mà thôi.

Để mrro hiểu rõ hơn cách IE Protector hoạt động và vì sao nó không thể bị dù có là 0 day exploit.
Mrro thử làm theo cách sau:
+ Thực thi IE Protector
+ Thiết lập chế độ "Cấm IE thực thi..."

Rồi làm 1 ví dụ nào đó bypass được xem

Hì đây lại là một chuyện hoàn toàn khác. Bản thân tui không có hứng thú với IEProtector nhưng bồ LeVuHoang cần phải chú ý điểm này:

- IEProtector có thể phân biệt được đâu là chương trình user thật sự muốn chạy, đâu là virus tự chạy?

- mrro không có khả năng bypass được IEProtector thì không có nghĩa là nó an toàn. LeVuHoang không bypass được IEProtector cũng không có nghĩa là nó an toàn.

-m

LeVuHoang wrote:

Trả lời từng người một... hì hì...

=== mrro
Chương trình này sẽ ngăn chặn không chỉ ở bước 4 mà là ở bước 3 & 4.
Khi người dùng click vào link, IE mở lên (nhưng chưa kịp chạy) malware, chương trình đã scan và auto delete trước khi nó kịp thực thi (cách mà các Anti Virus thường làm để quét file trước khi file được thực thi file).
Ngoài ra, nếu người dùng hoặc 1 trang muốn ép (0-day exploit) IE chạy một file nào đó. Chương trình sẽ hiện lên 1 bảng confirm xem có cho phép hay không. Nếu không cho phép, chương trình sẽ lập tức deny và hành động execute file đó xem như chưa bao giờ xảy ra.
Như vậy giải pháp đã được triệt để ở bước 3 + 4.
.......
và đó là giải pháp thích hợp để phòng chống SPIM nói chung và phòng chống các 0-day exploit nói riêng. Cho dù IE có lỗi cũng không execute được các mã lệnh độc hại được down xuống từ web.

Tui nói giải pháp của bồ LeVuHoang chưa thể giải quyết triệt để chống SPIM và 0-day exploit nói riêng vì những lý do (và quan ngại) sau đây:

1. Thực ra, xét một cách tổng quát, IEProtector cũng chỉ là một chương trình antivirus. Chúng ta đã có quá nhiều chương trình antivirus, và tác dụng của những chương trình này thì mọi người đều cũng đã rõ. Nếu chúng thật sự làm được việc thì có lẽ virus, spyware, trojan hay các loại malware nói chung đều đã được đưa vào viện bảo tàng. Tui thật sự nghi ngờ vào khả năng làm việc hiệu quả của IEProtector.

2. Tui cho là cách tiếp cận vấn đề của bồ LeVuHoang trong trường hợp này là chưa chính xác. IEProtector (nếu làm việc hiệu quả) là một chương trình tốt nhưng bản thân nó không thể giải quyết vấn đề SPIM trên YIM đơn giản vì nó chỉ được kích hoạt khi user đã đọc msg và click vào link. Cứ giả định IEProtector có thể phát hiện được hết tất cả các loại malware, ngăn chặn được hết 0-day exploit (một điều mà tui rất nghi ngờ) thì vẫn có ít nhất hai trường hợp sau đây IEProtector không thể làm được gì:

- SPIM không có link.

- User sử dụng một browser khác IE.

Tui cho rằng muốn giải quyết triệt để vấn đề SPIM, chúng ta cần tiếp cận ở bước thứ 2. Ý tưởng cơ bản nhất là làm sao để user không còn nhận được SPIM. Đó cũng là cách lâu nay chúng ta đối phó với vấn đề SPAM mail.

-m

Chào mọi người,

Hai ba tuần vừa qua tui cũng dành một ít thời gian để suy nghĩ về giải pháp cho vấn nạn virus phát tán qua Yahoo! Messenger nói riêng và SPIM nói chung. Tui cho việc cần làm đầu tiên là điểm lại các bước phát tán và lây nhiễm của một con virus lây lan qua Yahoo! Messenger:

1. Tác giả kích hoạt virus bằng cách gửi một msg chứa đường link đến virus cho friend list của mình.

2. Một nhóm người trong friend list của tác giả click vào đường link.

3. Browser của họ (có thể là IE hoặc Firefox) download và chạy con virus (một cách tự động hoặc không tự động).

4. Virus nhiễm vào máy tính của những người này và nó bắt đầu quay lại thực hiện bước 1 với một hoặc nhiều msg khác nhau.

Như vậy, IEProtector của bồ Lê Vũ Hoàng bảo vệ người dùng YIM ở bước thứ 4, nghĩa là khi họ đã click vào đường link, download (và có thể đã chạy) con virus rồi. IEProtector lúc này có chức năng tương tự như một chương trình anti-virus (lẽ ra BKAV đã phải làm điều này trước khi IEProtector ra đời smilie

). Nếu hoạt động tốt đúng như mong đợi, rõ ràng IEProtector là một giải pháp thích hợp ra đời đúng lúc để tiêu diệt đám AutoIt scripter. Đó là tất cả những gì IEProtector làm được nhưng rất tiếc là bây nhiêu đó thì chưa đủ để giải quyết trọn vẹn bài toán SPIM và virus trên YIM.

(còn tiếp, phần sau tui sẽ trình bày lý do tại sao IEProtector chưa giải quyết được SPIM cũng như giải pháp của http://www.innology.com.vn cho vấn đề này smilie

)

-m

lQ wrote:

Đừng nói đến OS. Cỡ 10 mrro cũng chưa chắc làm đc cái Browser riêng cho mình đâu anh PXMMRF àh. Hơn thế nữa, K.A. còn phải sử dụng nhiều tiện ích khác thì mới có hình dáng và chức năng được đến như vậy. Đơn cử có iptables, rAA.

Phương châm của tui khi làm phần mềm là: reuse, reuse and reuse. Phần "xác" của K.A là của cộng đồng mã nguồn mở, tui chỉ tập trung vào phần "hồn" để làm sao K.A đáp ứng được nhu cầu của người dùng, mà trước tiên là ở Việt Nam. Vì vậy, dẫu 10 mrro có làm được một cái browser cho riêng mình thì tui cũng sẽ không làm.

lQ wrote:

Góp ý với mrro thêm 1 số tính năng:
- Log lại tất cả History của các Kiosk. Kèm theo là công cụ phân tích cái log này. Ko nên quá ỷ lại vào log của chương trình.

Không hiểu ý của bồ lQ cho lắm?

-m

Chào bà con,

Mấy hôm nay tôi dành khá nhiều thời gian để suy nghĩ về hướng phát triển sắp tới của sản phẩm này. Thực tế ý tưởng làm kiosk sử dụng Linux và Firefox không phải là mới, đã có khá nhiều người thực hiện làm việc này trước đây rồi. Do đó nếu Kiosk Appliance muốn tồn tại thì nó phải tạo ra được sự khác biệt.

Quan sát cách tiến hành của những người đi trước, tôi thấy có một điểm chung: sản phẩm của họ thường chỉ có thể phục vụ cho một mục đích duy nhất. Đây chính là điểm khác biệt đầu tiên của Kiosk Appliance: mọi người có thể dễ dàng tùy biến nó để phục vụ cho các nhu cầu khác nhau. Người sử dụng có thể thay đổi chức năng của nó, từ máy teller trong ngân hàng sang kiốt tra cứu thông tin trong thư viện hay điểm truy cập Internet ở sân bay, sau vài cái click chuột.

Hơn thế nữa, với Firefox và thư viện extension khổng lồ của nó, Kiosk Appliance phải khuyến khích người dùng sáng tạo. Còn gì tuyệt vời hơn nữa khi người dùng nghĩ ra những ứng dụng mới của Kiosk Appliance mà ngay cả chính tác giả nó còn chưa biết đến? Đây là sự khác biệt thứ hai của Kiosk Appliance.

Một vấn đề khác của những người đi trước là họ không có công cụ quản lí tập trung các kiốt. Kiosk Appliance sẽ cung cấp một công cụ như thế. Chỉ cần ngồi ở một chỗ, người dùng có thể quản lí toàn bộ các kiốt có trong hệ thống của họ. Họ có thể theo dõi, thay đổi cấu hình, chỉnh sửa các tùy chọn, cài đặt các extension mới hay nâng cấp phần mềm cho tất cả các kiốt với vài cái click chuột. Đó là sự khác biệt thứ ba mà Kiosk Appliance có được.

Hi vọng là tôi có thể biến những ý tưởng này thành hiện thực.

-m

channhua wrote:

Có lẽ mọi người sẽ cho rằng dự án này rồi sẽ thất bại bởi lẽ thay thế Windows bằng Linux trên bình diện desktop là điều mà cả thế giới còn chưa làm được.

có bác mrro làm được

phần này hay đấy, giống như ipcop vậy, chiên cho fw

Bồ channhua quá lời rồi :p, mặc dù lúc nghĩ đến chuyện làm Kiosk Appliance, mrro cũng tưởng đó là một ý tưởng mới nhưng mà thật ra trên thế giới người ta đã nói và làm rất nhiều kiosk bằng Linux. mrro chẳng qua đem cái công nghệ và ý tưởng đó về áp dụng ở Việt Nam mà thôi.

-m

Xuất phát từ nhu cầu giảm chi phí bản quyền phần mềm và các nguy cơ an ninh, một ngân hàng có tài trợ cho tôi xây dựng một bản phân phối Linux để thay thế hệ điều hành Microsoft Windows mà các giao dịch viên (teller) đang sử dụng. Có lẽ mọi người sẽ cho rằng dự án này rồi sẽ thất bại bởi lẽ thay thế Windows bằng Linux trên bình diện desktop là điều mà cả thế giới còn chưa làm được.

Thực ra nhu cầu của các giao dịch viên rất đơn giản. Phần mềm duy nhất mà họ sử dụng là trình duyệt Internet Explorer. Mỗi ngày, họ đăng nhập vào Windows, mở Internet Explorer lên theo chế độ full-screen, rồi truy cập vào hệ thống web-based Core-Banking của ngân hàng là đã có thể bắt đầu tiến hành giao dịch với khách hàng. Họ cần và chỉ cần một trình duyệt là có thể làm việc tốt. Rõ ràng Windows không còn cần thiết nữa, vậy tại sao không thay thế nó bằng một giải pháp khác kinh tế và an toàn hơn? Và http://www.innology.com.vn/products/kiosk đã ra đời để trả lời cho câu hỏi này.

Kiosk Appliance về cơ bản là một công cụ duyệt web (web-browsing appliance). Vẻ đẹp của Linux thể hiện ở chỗ hệ điều hành này có thể được tùy biến để làm một nhiệm vụ duy nhất, trong trường hợp này là duyệt web, loại bỏ tất cả những dịch vụ và phần mềm không cần thiết. Toàn bộ hệ thống có thể được khóa chặt để ngăn chặn người sử dụng chạy bất cứ chương trình hay thực hiện bất kì thay đổi nào khác.

Kiosk Appliance bao gồm một phiên bản vừa đủ của Linux và trình duyệt Mozilla Firefox. Sau khi khởi động, Kiosk Appliance sẽ tự động chạy Firefox theo chế độ full-screen và đảm bảo rằng:

* Firefox là phần mềm duy nhất đang được chạy

* Đó cũng là phần mềm duy nhất có thể chạy.

Firefox được cấu hình để không cho phép người sử dụng thực hiện bất kì thay đổi nào trên hệ thống. Họ không được phép truy cập vào hệ thống file, cũng như không được phép chỉnh sửa cấu hình của Firefox. Ngoài ra Kiosk Appliance cũng không lưu trữ bất kì thông tin cá nhân (mật khẩu, địa chỉ URL đã truy cập) của người dùng. Nếu người sử dụng tắt Firefox, nó sẽ tự động khởi động lại, đồng thời tái lập (reset) lại toàn bộ hệ thống. Kiosk Appliance cũng tự động reset sau khi không được sử dụng trong 5 phút.

Ngoài khả năng ứng dụng trong lĩnh vực ngân hàng như đã đề cập ở trên, Kiosk Appliance còn cho phép chúng ta xây dựng các kiosk hiển thị và tra cứu thông tin rất hữu ích thường thấy trong các tiệm cafe Internet, các thư viện, phòng triển lãm và viện bảo tàng, các học viện, văn phòng hành chính, hội thảo, sân bay, siêu thị và khu mua sắm--tóm lại tất cả những địa điểm có nhu cầu truy cập thông tin một cách dễ dàng và đơn giản. Sự thật là với thư viện extension và plugin khổng lồ của Firefox, tầm ứng dụng của Kiosk Appliance chỉ phụ thuộc vào sự tưởng tượng của người sử dụng.

Tại sao phải trả hàng trăm USD chỉ để xài Internet Explorer trên Windows? Làm thế nào để duyệt web an toàn, tránh khỏi các nguy cơ virus/worm/spyware/adware? Nếu như bạn từng tự hỏi những câu hỏi này thì Kiosk Appliance chính là giải pháp mà bạn đang cần.

-m

security through obscurity is worse than no security et at.