Messages posted by: mrro

"Công ty tớ vừa trang bị một loạt stateful firewall, tốn mấy trăm nghìn đô la. Phen này tớ ăn ngon ngủ kỹ. Không phải lo bị tấn công nữa".

Tôi sẽ hỏi lại, thế còn những tấn công nhằm vào cái firewall thì sao? smilie

--m

Chào quanta,

Thú thật là tôi thấy yêu cầu này hơi lạ, bởi lẽ mặc dù không cho checkout về máy client, nhưng đây là code của họ, chúng ta chẳng có cách nào kiểm tra được họ có checkout về...não bộ và lưu ở đó hay không. Đối với những đoạn mã do họ viết ra, chắc chắn họ sẽ nhớ rõ. Còn đối với những đoạn mã không phải của họ, nếu muốn, họ có thể âm thầm mỗi ngày ngồi *học* chúng chẳng hạn. Vả lại, tôi thấy để junior developer đọc code của senior developer là một cách đào tạo khá hiệu quả.

Kinh nghiệm của tôi là nếu không thể tin tưởng, tốt nhất không cho developer thấy những gì không phải do họ viết ra. Để làm được việc đó, trước hết đòi hỏi software phải được thiết kế để các developer có thể độc lập làm việc với nhau. Ý tưởng chủ đạo là:

1. chia software ra thành từng phần nhỏ hơn (có thể là module hoặc là một chương trình độc lập)

2. xác định interface để các module này có thể tương tác làm việc với nhau

3. giao các module cho developer

4. cấu hình svn, chỉ cho phép họ truy cập đến module của họ mà thôi

Vài chia sẻ,

-m

Cái khó khăn lớn nhất đối với Linux đó là khâu hỗ trợ kỹ thuật, khi bạn bị "bí" ở 1 vấn đề nào đó thì không có cầu cứu từ nhà cung cấp được cả ngoại trừ bạn phải trả phí cho họ . Bởi vậy nếu bro muốn "nhớ nổi" các lệnh trong Linux thì chỉ có cách thao tác các command line cho thành thạo và khi bị "bí" thì xem lại tài liệu, nó cũng là cách ôn lại kiến thức đã học

Hì, cái này đích thị là FUD. Tôi xài Linux đã gần 4 năm, và ngay từ khi mới bắt đầu cho đến giờ vẫn chưa hề phải trả 1 đồng nào để được hỗ trợ kỹ thuật. Thậm chí nhiều lúc tôi (thường là công ty của tôi) muốn trả tiền để được hỗ trợ mà không biết phải trả cho ai luôn (cái này mới là vấn đề của Linux nói riêng và các phần mềm FOSS nói chung).

To father_nghia_den:

Làm nhiều sẽ nhớ thôi, không phải lo lắng. Nếu không nhớ thì lên Google tìm. Mấy lời khuyên của mudzot rất có lý đó.

-m

"Con gián" của gamma hại nhỉ? smilie

Anyway, tôi cho rằng, mọi hành động điều chỉnh cookie, như cách anh conmale đề cập, chỉ là những "mánh mung", hòng gây thêm khó khăn cho kẻ tấn công, chứ không phải là một giải pháp triệt để.

Hơi off-topic, tôi nghĩ có lẽ chúng ta đang xác định sai vấn đề cần giải quyết, nên các giải pháp đưa ra đều khó lòng mà triệt để. Vấn đề mà chúng ta cần giải quyết ở đây không phải là xác thực người dùng (user authentication, như mọi người vẫn đang cố gắng triển khai, thông qua các hình thức cookie, username, password, token...), mà phải là xác thực từng hành động mà người dùng thực thi trên hệ thống (transaction authentication).

Tôi đưa ra một ví dụ về sự thất bại của chiến thuật xác thuật người dùng. Ngay ở HVAOnline, trước đây, JForum bị dính một lỗi CSRF (có một topic về đề tài này trên HVAOnline), anh conmale mới triển khai một kiểu securityHash, là một hidden field trong mấy cái form trên HVAOnline. securityHash giải quyết được CSRF cho đến khi gamma, với sự cố "con gián" :-d, đã chôm được luôn cookie (và thật ra khi đã bị XSS rồi, thì securityHash kô còn có tác dụng nữa) và từ đó chiếm luôn session của những người nào mải mê "bắt gián".

Rõ ràng, các phương thức xác thực như cookie, session hay securityHash không phải là giải phát triệt để để bảo đảm an ninh cho phía server, ngăn ngừa những tổn hại có thể xảy ra với server trong trường hợp credential của user bị đánh cắp. Đó là tôi chưa kể đến những vấn đề như MITM trojan có khả năng chôm credential của user một cách tự động và "trong suốt" luôn. Tóm lại, từ máy tính của người dùng đến server, có quá nhiều cạm bẫy và rủi ro có thể khiến người dùng bị chôm mất credential của mình.

Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không?

Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như:

- đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng.

Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.

Đương nhiên xây dựng một hệ thống như thế đòi hỏi tiền bạc, thời gian, nhân lực và rõ ràng là không thể áp dụng cho HVAOnline.

- đối với một hệ thống như HVAOnline, chúng ta có thể điều chỉnh bằng các rule, chẳng hạn như:

+ ủy thác thực hiện các chức năng quan trọng vào một lớp IP nhất định.

+ trước khi thực hiện bất kỳ chức năng nào, phải verify lại mật khẩu.

+ tách bạch giữa account quản lý và account sinh hoạt trên diễn đàn (chẳng hạn như "quanlytruong")

+ ...

Sorry mọi người, hơi bị off-topic smilie

.

-m

Bản thân tôi thấy bồ CK hỏi rất rành mạch rõ ràng và đây cũng là một đề tài thú vị để thảo luận. Bồ StarGhost với FaL cảm thấy không thích thảo luận về nó thì đừng tham gia, còn nếu tham gia thì nên tập trung tìm giải pháp, không nên bàn ra.

Bồ CK đang cần phải triển khai một http://en.wikipedia.org/wiki/Chosen_plaintext_attack (to mfeng:tôi nghĩ đây là chosen-plaintext attack bởi CK có thể chọn plaintext là user, email hay password và quan sát được output). Theo lý thuyết thì nhiệm vụ cuối cùng của cryptanalyst là lấy được key được sử dụng để mã hóa (từ đó giải mã được hết các ciphertext). Tuy nhiên, trong thực tế, nhiệm vụ trước tiên của cryptanalyst phải làm là tìm hiểu thuật toán mã hóa được sử dụng. Nên rõ ràng, vấn đề của CK là rất thực tế và đáng tìm hiểu.

Trong trường hợp này, đánh giá đối tượng mà CK đang tấn công, tôi dự đoán họ chỉ sử dụng những thuật toán mã hóa thông dụng như RC4, DES, TDES hoặc AES (có thể thêm Twofish hoặc Blowfish, nhưng tôi nghĩ xác suất là thấp).

Nếu là tôi, để tìm hiểu xem đối tượng sử dụng thuật toán nào, tôi sẽ:

* Tìm hiểu ngôn ngữ mà họ sử dụng, và xem ngôn ngữ đó, by default, là hỗ trợ những thuật toán mã hóa nào.

* Tìm hiểu phần mềm mà họ đang sử dụng, và xem phần mềm đó, có những module nào hỗ trợ mã hóa, theo những thuật toán nào.

Tôi thấy một điều kỳ lạ ở đây là tất cả các ciphertext đều là 30 byte - 240 bit, CK có thể confirm lại hay không?

-m

to kid_b0d: Firewall và Router khác nhau chứ trước tiên firewall là phần mềm (hình như cũng có cả firewall cứng) còn router là phần cứng trong đó nó tích hợp nhiều chức năng mềm như firewall, routing, ip sharing... (hix em chỉ đưa router ra đây làm ví dụ là firewall sẽ tích hợp vào một thiết bị phần cứng thôi mà)

muốn nó mềm thì nó mềm, muốn nó cứng thì nó cứng thôi. Bất kỳ thiết bị nào cũng là sự kết hợp giữa phần mềm và phần cứng, firewall hay router không là ngoại lệ. Ví dụ như mấy con router của Cisco, phần cứng của nó là cái cục sắt có cả CPU và mấy cái mạch ASIC, còn phần mềm của nó là IOS. Không có IOS thì cái cục sắt đó cũng chẳng hoạt động được.

-m