Messages posted by: prof

boom_jt wrote:

Mình đoán ý bạn thế này: mình sẽ sử dụng 1 khái niệm gọi là timeout, cookie sẽ chỉ hợp lệ trong 1 khoảng thời gian nhất định đúng ko? Sau khoảng thời gian đó, cookie ko còn hợp lệ, và như vậy kẻ tấn công không thể làm gì đc với cookie ko còn hợp lệ đó?

Uh, cơ bản là như vậy.

boom_jt wrote:

Vậy thì khi quá thời gian đó, phải chăng người dùng sẽ lại phải nhập username/password để có 1 cookie hợp lệ mới (có bất tiện cho người dùng quá ko? ), hay bạn sẽ thực thi cơ chế nào đó ? Mình nghĩ nên đi chi tiết vào vấn đề này để làm rõ khả năng ngăn ngừa session hijacking của phương pháp.

Cơ chế timeout này cũng đã đc áp dụng (yahoo! mail chẳng hạn), tuy nhiên thời gian timeout có thể là 1 ngày (khá dài), đủ để kẻ tấn công làm đc điều hắn muốn ...

Um, trước tiên ta nên thống nhất với nhau một vài giả thiết sau đây để tránh đi quá xa nhé:

- Thứ nhất, việc thảo luận giải pháp chống session hijack mà tớ đề nghị là áp dụng cho "ngữ cảnh" HVA Forum. Nên nhớ mỗi Web application có cấu trúc, kịch bản không giống nhau.
- Thứ nhì, session hijack thực sự trở nên nghiêm trọng đối với các sessions của Vmods/Mods vì kẻ tấn công có thể nhằm vào đó để gây hại cho diễn đàn thông qua các hành động Modify, Delete, v..v... Theo đó, một bộ phận không quá nhiều người dùng mới áp dụng cơ chế này.

Do đó, ý tưởng (dùng timestamp) thì như vậy, nhưng với mỗi application cụ thể nên có cách áp dụng đủ linh động và mềm dẻo. Chẳng hạn, xác định giá trị timestamp thế nào cho hợp lý, những securityHash/token nào cần dùng thêm timestamp, những trang nào thì nên áp dụng kiểu token này, v..v... những việc này cần phải cân nhắc, khảo sát kỹ càng. Một Moderator sau khi request một trang moderate.xyz nào đó, thì không thể sau 30 phút, hay 300 phút mới thực thi hành động Move hay Delete. Mặt khác, tớ cũng đã đề cập tới giải pháp bảo vệ securityHash/token trong khoảng thời gian timestamp rồi. Bạn đọc lại đoạn này nhé:

prof wrote:

Em nghĩ có thể kết hợp thêm yếu tố Timestamp (chẳng hạn, khoảng 30 giây) cho securityHash/token (có tính duy nhất cho 1 session) hiện tại của diễn đàn. Theo đó, phía server sẽ lưu giữ một table các securityHash này và sẽ không chấp nhận một request nào đó nếu giá trị securityHash đã và đang được dùng trước đó. Table này sẽ chỉ lưu các securityHash trong khoảng thời gian của Timestamp sau đó sẽ được giải phóng mà không chiếm tài nguyên.

Trong trường hợp nhận được 2 requests với 2 securityHash giống nhau (bị session hijack), khi đó server-side nên cân nhắc trường hợp reject cả hai request này (vì khi đó không rõ request nào là hợp lệ) hoặc tiến hành verify lại password.

Thân.

boom_jt wrote:

hì, mình chưa rõ là cụ thể () cái timestamp đó đc implement thế nào nội dung truyền giữa client và server là tn?

Ah, thì ra là bạn hỏi về cách implement.

Theo tớ "đoán", có lẽ securityHash/token của HVA chưa gồm yếu tố thời gian nên có thể bị lợi dụng (Session Hijack). Vì vậy, mỗi khi một securityHash/token được tạo, sẽ kèm theo thời gian tạo token này (bên cạnh các yếu tố đặc trưng khác). Server-side sẽ qui định timestamp bao nhiêu đó để token còn hợp lệ (tính từ thời gian tạo) khi mods tiến hành thao tác điều hợp. Nếu bạn đã quen với các khái niệm cơ bản như cookies, sessionID, token, và cách chúng được hình thành và gửi/nhận thế nào thì việc implement thêm timestamp sẽ không quá khó khăn. Có lẽ tôi xin không đi vào tiểu tiết hơn nữa, chẳng hạn như cách tổ hợp thêm yếu tố thời gian vào securityHash/token thế nào, quản lý timestamp ra sao, lưu trữ thế nào,... vì điều này tùy thuộc vào khả năng "tuỳ biến" của mỗi người.

Hi vọng giải đáp được câu hỏi của bạn.

Thân mến.

boom_jt wrote:

...
p/s: @prof: mình chưa hiểu rõ lắm ý tưởng timestamp của bồ, có thể nói rõ thêm cho mình hiểu chút đc ko, sozy

Bạn chưa rõ cụ thể ở điểm nào?

P.S: Không cần phải "sozy" đâu, boom_jt. Không rõ thì hỏi cho rõ thôi mà smilie

.

Chào cả nhà,

Mấy hôm nay thấy topic sôi động ghê mà bận quá ko thể tham gia thảo luận được với mọi người. Bây giờ mới có thể vào "góp vui" cùng bà con chút xíu smilie

.

conmale wrote:

Hì hì, mục đích đằng sau là để tìm hiểu những giới hạn của giao thức HTTP hiện nay trong phạm vi session management đó em . Cái này quan trọng và lý thú hơn chỉ dừng lại ở mức "quick fix".

Hi hi, anh conmale coi bộ muốn bà con "xới tung" HTTP & its related stuff lên mới đã hay sao đó mà đặt giả thiết bài toán khó nhằn ghê smilie

. Thành thực mà nói, do bản chất "vốn có" của HTTP là một stateless protocol nên vô hình chung dẫn tới bài toán Session Management trở nên cầu kỳ, phức tạp. Bất kỳ một Web application nào khi có nhu cầu đụng tới vấn đề authentication thì hầu như phải tự thêm thắt các phương pháp "tự chế" (đối với context trong topic này là các thứ khá quen thuộc như cookies, sessionID, securityHash,...) nhằm mục đích "tha thiết" là: xác thực/định danh người dùng.

conmale wrote:

Điểm này hoàn toàn đúng. Tuy vậy, vấn đề nằm ở chỗ xác định sự cân bằng giữa đòi hỏi bảo mật và tiện dụng của một ứng dụng. Một ứng dụng online banking cần "transaction authentication" là điều cần thiết bởi vì mỗi cú bấm đều critical. Đối với một forum, tính critical không cao đến thế. Nếu đặt tính critical của một forum lên mức đòi hỏi "transaction authentication" thì nó bị mất tính linh động và dễ dùng.

Đứng về mặt technology, mình có thể vận dụng nhiều phương pháp để giải quyết tình trạng hijacking. Cái khó là duy trì được mức transparent và friendly trong quá trình sử dụng.

Um, thiết nghĩ anh conmale có vẻ quá "trăn trở" về vấn đề transparent & friendly trong khuôn khổ forum nên khó có thể đạt được một giải pháp "dĩ hoà vi quý". Vì xét cho cùng, trên một forum, các tác vụ quan trọng nhất, đáng để "lừa" nhất, là các tác vụ điều hợp (của mods) nên việc verify lại mật khẩu là điều nên làm trong trường hợp cần thiết.

Em nghĩ có thể kết hợp thêm yếu tố Timestamp (chẳng hạn, khoảng 30 giây) cho securityHash/token (có tính duy nhất cho 1 session) hiện tại của diễn đàn. Theo đó, phía server sẽ lưu giữ một table các securityHash này và sẽ không chấp nhận một request nào đó nếu giá trị securityHash đã và đang được dùng trước đó. Table này sẽ chỉ lưu các securityHash trong khoảng thời gian của Timestamp sau đó sẽ được giải phóng mà không chiếm tài nguyên.

Trong trường hợp nhận được 2 requests với 2 securityHash giống nhau (bị session hijack), khi đó server-side nên cân nhắc trường hợp reject cả hai request này (vì khi đó không rõ request nào là hợp lệ) hoặc tiến hành verify lại password.

mrro wrote:

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 là bài toán authentication chỉ có thể được giải quyết rốt ráo khi không còn phụ thuộc vào việc authenticate users nữa mà thay vào đó là authenticate nội dung giao dịch. Tuy nhiên, để có giải pháp hoàn thiện dựa trên AI, vấn đề thời gian & nghiên cứu nên được đầu tư một cách nghiêm túc. Lý do, nếu hệ thống không được "training" tốt, không lựa chọn được AI learning algorithms tốt, thì khả năng chịu false positive là không thể tránh khỏi.

Mến.

levinthan wrote:

Hi . Lại có người giúp nữa rồi. Vui quá . Mình đã giới hạn các thông số của apache server ( timeout , MaxKeepAliveRequests , keelalivetimeout ,ThreadsPerChild ,MaxRequestsPerChild, ThreadLimit ) nhưng vẫn không khắc phục được. Mình có đọc một số bài viết giới hạn lại TCP/IP trong windows bằng cách chỉnh sửa registry . Để mình thử cái đó xem sao .Có phải cái này không nhỉ

Open your registry and find the key below.

Create a new DWORD value called "SynAttackProtect" and set it to either 0, 1 or 2 based on the table below.

This value causes Transmission Control Protocol (TCP) to adjust retransmission of SYN-ACKS. When you configure this value, the connection responses time out more quickly in the event of a SYN attack (a type of denial of service attack).

* 0 (default) - typical protection against SYN attacks
* 1 - better protection against SYN attacks that uses the advanced values below.
* 2 (recommended) - best protection against SYN attacks. This value adds additional delays to connection indications, and TCP connection requests quickly timeout when a SYN attack is in progress.

Optional Advanced Values

For extra control you can create these additional DWORD values in the same key for each of the items below. They are not required for SynAttackProtect to be effective.

* TcpMaxHalfOpen - default value is "100"
* TcpMaxHalfOpenRetried - default value is "80"
* TcpMaxPortsExhausted - default value is "5"
* TcpMaxConnectResponseRetransmissions - default value is "3"

Mình đã up lại đoạn sniff trong quá trình bình thường và bị flood , bạn nào rảnh có thể xem giúp mình nhé http://stukyo.com/flood.rar
...

Thông tin về bài viết đó chưa đủ. Tôi đã để link của công cụ mà tôi giới thiệu cho bạn trong chữ "này" rồi mà. Cụ thể là ở đây: http://www.sniff-em.com/hardenit.shtml. Bạn tải về và thắt chặt thêm cho phần TCP/IP trên Web server của mình.

...
Bạn có thể sử dụng công cụ này. Lưu ý: do hệ thống hiện tại của bạn đang bị tấn công, nên tốt nhất bạn lựa chọn các giá trị tùy chọn thắt chặt nhất, sau đó nới lỏng dần từng tham số rồi xem phản ứng của hệ thống ra sao khi sử dụng công cụ trên.

Mình sẽ tham khảo một số router xem sao . Có lẽ giá cao thật nhưng nếu nó lọc được 1 ít flood thì cũng cam .
http://www.draytek.com.vn/category.aspx?cat=2
Ở đây có vài cái router support load balancing . Nhưng quan trọng nhất là về mặt security , cái nào cũng là " best security , anti ddos, flood " . cái dlink 520t của mình cũng quảng cáo như vậy
Hiện mình đang ngắm 2 cái là Vigor2910 Dual WAN Security Router ( 170+ $ ) và Vigor2950 Dual WAN Security Router (460+ $). Không biết cái nào phù hợp hơn nhỉ .
...

Bạn nên tự cân nhắc xem thiết bị nào phù hợp với túi tiền và nhu cầu của mình. Tớ sẽ ngâm cứu đoạn sniff mà bạn cung cấp xem có manh mối gì không. Hi vọng có thể giúp được bạn điều gì đó.

levinthan wrote:

Hic. Vẫn đang bị flood

Hello levinthan,

Tôi cũng là người theo dõi khá sát tình trạng của bạn trong mấy ngày gần đây. Rất tiếc, các pcap files đã được xoá (theo khuyến cáo của anh conmale) nên tôi cũng ko thể biết chính xác những gì đã được gửi tới web server của bạn. Theo phỏng đoán của tôi, bên cạnh việc hiệu chỉnh apache theo sự trợ giúp của anh conmale, có lẽ bạn cần hiệu chỉnh thêm một chút các tham số liên quan tới phần TCP/IP của Windows mà Web server đang chạy trên nó, từ đó hi vọng giảm thiểu tình trạng SYN flood(!). Bạn có thể sử dụng công cụ http://www.sniff-em.com/hardenit.shtml. Lưu ý: do hệ thống hiện tại của bạn đang bị tấn công, nên tốt nhất bạn lựa chọn các giá trị tùy chọn thắt chặt nhất, sau đó nới lỏng dần từng tham số rồi xem phản ứng của hệ thống ra sao khi sử dụng công cụ trên.

Ngoài ra, theo gợi ý của bác PXMMRF, nếu có thể bạn cũng nên cân nhắc khả năng tăng cường phần hardware cho hệ thống. Nếu bạn đã có 2 ADSL lines, bạn có thể tham khảo sản phẩm Draytek Security Router hỗ trợ out-bound load balancing trên 2 WAN interfaces. Chi phí cho Router này cũng tầm trên dưới 10 tr VNĐ.

Hi vọng chút góp ý phần nào giúp được bạn vượt qua được đợt khó khăn này.

Thân mến.

osamabinladel wrote:

Em thấy nên có cái gi` đó tương tự như nút thank, tất nhiên là không để đánh giá gì về đóng góp hay để set này nọ...
mà là em thấy nếu không có thanks hay gì đó thì mem phải reply để cảm ơn người viết, thật không hay nếu chỉ một bài đầu lại kéo theo sau đó hàng loại bài reply với nội dung không có gì mới lạ :"Thanks u, thanks, Cảm ơn, cảm ơn rất nhiều, thanks for sharing,............"

tránh rác rum ấy mà !
Thân !

Hì, cảm ơn cũng có nhiều cách mà osamabinladel. Thiết nghĩ nếu ai đó đọc được bài viết hay trên HVA, việc họ thường xuyên ghé thăm HVA, rồi tham gia giải đáp, viết bài cho HVA, có lẽ đó là cách cảm ơn mà theo mình là thiết thực nhất đấy smilie

.

kute.nf wrote:

Thời gian vừa qua website của em bị kẻ gian xóa hết data. Họ chỉ để lại các files còn các dữ liệu có đuôi .php và html thì bj xóa hết cả. Theo các anh thì em cần làm j. Em đã đổi pass FTP nhưng nó vẫn hack dc. Vậy là sao các anh. Cho e lời chỉ dẫn dc hok? Em cảm ơn

Hello kute.nf,

Bạn chẳng đưa ra một chút thông tin nào về hệ thống/website của bạn thì ai có thể giúp bạn đây? Bạn nên cung cấp một cách đầy đủ & chi tiết nhất có thể thông tin về website của bạn thì mọi người mới có thể giúp bạn xác định được nguyên nhân và cách khắc phục. Chẳng hạn, website chạy trên Web server nào? Hệ điều hành nào? Sử dụng hệ QTCSDL nào? Phiên bản bao nhiêu? Chính sách hosting thế nào? v...v...

Hi vọng bạn rút kinh nghiệm trong các bài viết sau.

chaien281985 wrote:

Choài. Dùng hết hả anh. À anh có tài liệu tiếng việt về PE toturial ko? em tìm mãi trên mạng mà ko có.

Cảm ơn anh nhiều

Bạn sang REAonline.net sẽ tìm được nhiều thứ liên quan tới PE.

Mến.