Messages posted by: StarGhost

Về việc cấu hình CDN, bạn cần phải tính toán thật kĩ về request routing. Bạn cho biết về việc sử dụng DNS load balancing cho CDN, tức là việc routing dựa vào khoảng cách địa lý. Tuy nhiên Việt Nam tương đối nhỏ, nên khoảng cách địa lý có thể không không phải quá quan trọng. Ngoài ra còn có các yếu tố khác như load, throughput, bandwidth cost/limitation, v.v… Việc sử dụng DNS cho CDN request routing cũng có một giới hạn nữa là nếu DNS resolver không phải là local thì sẽ giảm thiểu độ hiệu quả, ví dụ có một vài lần mình thấy DHCP trả về IP DNS của Google.

Còn về các vấn đề liên quan đến security thì phải tuỳ thuộc vào đặc thù của dữ liệu và việc sử dụng chúng, và tốt nhất là nên xử lý tốt trước khi đi vào hoạt động nếu không muốn bị "vỡ trận" vì DDoS. Việc này đòi hỏi sự kết hợp nhuần nhuyễn giữa load balancing, mod_security và iptables, và log.

Có khả năng do firewall hoặc NAT, hoặc đơn giản là không có route đến cái IP đó.

Nếu bạn chỉ có yêu thích CNTT và lại học khác ngành, thì nhiều khả năng là bạn khó có thể làm được các công việc thuần kĩ thuật. Các công việc khác liên quan đến IT thì lúc xin việc người ta chú trọng vào business competencies hơn là kiến thức kĩ thuật. Vậy nên mình cho rằng bạn học môn gì thì cũng không quá quan trọng. Tất nhiên dù trình độ bạn có như thế nào bạn cũng sẽ có một lợi thế là bằng cấp từ nước ngoài. Còn nếu bạn thực sự muốn làm công việc kĩ thuật thì mấy môn trên không giúp ích gì nhiều. Ngoài ra, dân IT "chính gốc" thì cũng bắt đầu từ "không chính gốc" mà ra thôi, không có gì là đặc biệt cả.

Vẫn còn capture được HTTP header thì làm sao mà chả tốn tài nguyên. Tại sao phải tốn công xử lý các kết nối mà cuối cùng sẽ bị chặn? Còn việc lo chặn nhầm người sử dụng ư, vậy sự khác nhau giữa người dùng thực sự và kẻ tấn công là gì?

Đọc tới đọc lui, cuối cùng vẫn không thấy tác giả đề cập đến điểm quan trọng nhất: thế nào gọi là "siêu lập trình viên", hoặc lập trình viên "pro". Không có mục tiêu thì đi bao giờ mới đến đích.

Chỉ thấy tác giả định nghĩa lập trình viên giỏi nhất là người viết ra chương trình hoàn thiện nhất. Tuy nhiên thế nào là "hoàn thiện nhất" cũng không giải thích cụ thể. Hơn nữa, với cái định nghĩa đó thì ngoại trừ mấy tay chuyên viết apps solo ra thì còn lại không đủ tiêu chuẩn để trở thành lập trình viên giỏi nhất, vì họ không có khả năng viết hoàn toàn một chương trình, thì nói gì đến chuyện hoàn thiện.

em muốn đi theo bảo mật ạ , Nhưng hiện giờ em chưa biết gì về nó

Không biết bảo mật là cái gì vậy mà muốn đi theo nó? Bạn này chắc là bị một bạn tên là "bảo mật" dụ kẹo. Đề nghị bạn "bảo mật" đứng ra nhận trách nhiệm. Còn lại, đối với các bạn khác sắp bị "dụ kẹo", hoặc đã bị "dụ kẹo" bởi bất cứ thứ gì, thì trước khi quyết định đi theo nó nên tìm hiểu kĩ xem nó là cái gì, tránh việc tiền mất tật mang. Bạn nào than phiền không biết bắt đầu từ đâu, thì đáng tiếc mình phải nói rằng: phẩm chất của các bạn chưa đủ để "đi theo bảo mật" (đại khái giống như con người ở thời đại này tham sân si quá nặng không thể tu thiền giải thoát, phải tìm lối "tắt mà không tắt"như tu Tịnh độ).

Việc hash password thường không phải diễn ra qua JS, mà là qua HTTP authentication. Tuy nhiên vì không có server authentication nên sẽ bị tấn công man-in-the-middle như bạn nói. Nếu chỉ là hash mà không có salt, thì server chỉ cần phải lưu hash(password) và so sánh với hash nhận được. Nếu có salt (challenge-response) thì server phải lưu chính xác password.

Còn về mặt lý thuyết, việc hash n lần theo dạng h^n(m) sẽ làm tăng khả năng tạo ra collisions nếu hash function không phải injective khi ánh xạ image đến image. Trên thực tế chỉ có encryption primitives thoả mãn điều kiện này. Tuy nhiên các hash functions hiện tại, kể cả MD5, đủ tốt để phục vụ cho việc hash nhiều lần.

Về chuyện xảy ra thời tiền SSL, thì mời bạn tham khảo sách giáo khoa lịch sử. Đại khái là SSL được tạo ra không lâu sau HTTP nên giai đoạn ở giữa chỉ là khoảng đệm. Đối với tình hình hiện tại nếu có website đòi hỏi login mà không có SSL thì người dùng khó có cách nào bảo vệ chính mình ngoài việc đơn giản là không login.

Ngoài việc gửi password theo dạng plaintext thì client có thể hash password trước rồi mới gửi (xem thêm về challenge-response authentication), hoặc sử dụng PAKE. Tuy nhiên dù là cách nào thì cũng gặp phải 2 vấn đề: 1) entropy của password là rất thấp và 2) nếu giải pháp chỉ bảo vệ password thì hầu như không có ý nghĩa, vì kết nối hoàn toàn có thể bị compromised.

TLS/SSL là giải pháp toàn diện, và hiện tại chi phí mua certificate cũng không quá cao, đặc biệt là với các dịch nhạy cảm như e-commerce. Trước đây khi chưa có TLS/SSL thì căn bản là không có giải pháp an ninh hoàn hảo.

Việc áp dụng checklist sẵn có cho hệ thống là tương đối nguy hiểm, vì bạn khó mà trả lời được câu hỏi: checklist này có bao gồm các điều kiện cần và đủ cho an ninh của hệ thống hay không? Thay vì đó, bạn nên bắt đầu từ việc xác định các yêu cầu về mặt chức năng của hệ thống. Sau đó xác định các nhân tố có thể là nguy cơ tiềm ẩn cho các chức năng đó, ví dụ insider, DDoS, hardware failure, v.v… Dựa vào đó đưa ra các yêu cầu về security cho hệ thống, ví dụ authentication, secure channel, confidentiality, integrity, physical.

Sau khi xác định các yêu cầu về security thì mới tiến hành xây dựng checklist cho mỗi yêu cầu. Lúc này nếu bạn không có kiến thức kĩ thuật về một yêu cầu nào đó thì mới nên tìm checklist cho nó. Nên nhớ: các bước ở trên càng được tiến hành chi tiết, thì việc xây dựng checklist càng nhanh chóng và chính xác.

Nói chung về mặt nguyên tắc thì HSRP được thiết kế cho Standby/Active, còn Load Sharing chỉ là side effect của nó. Thế nên nếu không cần thiết thì không nên dùng HSRP cho load sharing, vì HSRP không có hỗ trợ thêm các chức năng chuyên biệt của load sharing như load distribution, dynamic balancing, etc.

Còn về câu hỏi nguyên tắc cấu hình thì mình cũng không rõ là bạn hỏi cái gì, vì chỉ có 2 cái switches thì cần cái nguyên tắc gì ngoài việc bảo đảm connectivity. Nếu vẫn muốn dùng load sharing thì cần đảm bảo load được chia sẻ đều giữa các paths (cả outgoing và incoming), vì HSRP chỉ có tác dụng đối với outgoing traffic, và cần sự phối hợp của host configuration và/hoặc DHCP.

Fly91 wrote:

invalid-password wrote:

Nếu bạn không phải là người nghiên cứu về các lỗ hổng mà chỉ là người quản trị, đảm bảo an toàn mạng thì bạn chỉ cần biết rằng hiện nay đang có một cái lỗ hổng gọi là HeartBleed, nó ảnh hưởng tới những cái gì-hệ thống nào, và cần làm gì (patch, update) để khắc phục nó, hết.

Mình thì mình không nghiên cứu về các lỗ hổng, đọc thì nhức đầu, mà cũng không dùng làm gì cả, lại mau trôi qua và chìm vào quên lãng, nên mình không đọc Mình cũng làm về sờ-cu rờ-ti (security) nè, việc của mình chỉ đơn giản là cài patch, sau đó lãnh lương. Nghề bảo mật thật là đơn giản !

nghe anh nói về nghề sờ-cu rờ-ti hay và đơn giản nhỉ ^^ em thích làm quá đi ạ^^

Muốn làm được công việc đơn giản đó trước hết bạn phải được người ta nhận vào làm cái đã.

Các site decrypt online thường tìm pass trong database sẵn có, nên việc không tìm thấy là chuyện thường. Mình không biết Wordpress tạo password như thế nào, nhưng nhìn dài thế kia mà nếu là MD5 thì ắt hẳn là có salt, nên việc tìm không ra password là điều hiển nhiên.

Có mùi… giật tít, bom tấn, câu khách… Nghe chừng xnohat đang nhàn nhã.

Mũ Trắng wrote:

conmale wrote:

Những thứ em trình bày ở trên không phải là drDoS.

Cần bao nhiêu "máy chủ" bị spoofed để tạo ra DDoS?

Vậy như nào mới là drdos hả anh? Anh giải thích giúp em với! Em đã vừa đọc lại rất kỹ các tài liệu drdos cả
trong HVA và cả tài liệu gốc nữa, những thứ em đang hiểu chính là những điều em vừa nói.

Một cuộc tấn công DRDoS cần thoả mãn 2 yêu cầu sau:
1. attacker giả mạo victim và gửi hàng loạt requests đến nhiều nơi, và mỗi request sẽ tạo ra reply gửi trả về victim, và
2. chi phí cho việc tạo ra mỗi request phải ít hơn (nhiều) so với chi phí mà request đó tạo ra cho victim.

Các attacks dùng source routing trong quá khứ thoả mãn cả 2 điều kiện, nên chúng là một ví dụ của DRDoS.

gdb hình như không bật ASLR thì phải...

Trước khi thiết kế một phương thức bảo mật nào đó, người ta thường cần cái gọi là "adversary model", nôm na là: phương thức bảo mật này nhằm ngăn chặn đối tượng nào? Các bạn "người xấu" thường thường hay bị tóm là vì các bạn ấy không hiểu được "adversary model" trước khi hành động.

Ở đây "adversary model" là C50, nhưng có vẻ như bạn cũng không hiểu được họ có những khả năng, tài nguyên, quyền hạn như thế nào. Về phương diện lý thuyết, Tor là một hệ thống khá hoàn hảo cho việc ẩn danh (Anonymity), nhưng thực tế chưa chắc, vì quá trình xây dựng hệ thống Tor là một quá trình không có kiểm soát, và khó mà biết được trong đó có cái gì. Ngoài ra, C50 (cũng như các cơ quan điều tra) có quả nhiều phương pháp để tìm ra bạn mà không cần phải tấn công hệ thống Tor.

p/s: cái mô hình ở trên có đoạn decodeMD5 là mình thấy có vẻ hơi thiếu khả thi.

Về nguyên tắc, một cuộc gọi VoIP là một kết nối Internet. Vì vậy, nếu có phương pháp nào dùng để phát hiện nghe lén VoIP thì nó thường thoả mãn một trong 2 điều kiện sau: hoặc là nó dựa vào công nghệ liên quan đến tiếng nói, hoặc là nó có thể áp dụng cho không chỉ VoIP mà cả các loại kết nối Internet khác.

Việc dựa vào công nghệ tiếng nói để phát hiện nghe lén thì có vẻ hơi thiếu khả thi, nên có lẽ lựa chọn còn lại là dựa vào công nghệ phát hiện nghe lén các kết nối Internet. Chi tiết như thế nào thì mời bạn tìm hiểu thêm. Trong mục E-book và Phòng đọc có lẽ cũng có khá nhiều thông tin hữu ích.

@gamma: nếu không ai muốn xếp hàng thì ta bắt họ xếp hàng thôi. Tất nhiên giải pháp này chỉ phù hợp trong trường hợp flash crowd chứ không có tác dụng với DDoS.

Không tồn tại giải pháp triệt để và thực tế khi chống lại insider attacks. Việc tốt nhất mà một hệ thống bảo mật bằng máy tính có thể làm là thiết lập access control policy. Một khi policy cho phép truy cập dữ liệu (dù là dưới dạng nào), thì khả năng rò rỉ luôn tồn tại. Trong trường hợp này, người ta cần một loạt các phương pháp cản trở thất thoát như:
- trusted computing,
- kiểm tra an ninh (thiết bị, thân nhiệt, nhịp tim, v.v...) lúc ra vào trụ sở và giữa các khu vực có cấp độ an ninh khác nhau,
- camera giám sát hoạt động,
- chặn sóng điện thoại.

Tất cả các phương pháp này cần được thiết lập đồng thời và hợp lý. Riêng về việc hạn chế truy cập Internet, nếu attacker thuộc loại chuyên nghiệp, thì hầu như rất khó để có thể ngăn cản việc truyền dữ liệu ra ngoài qua Internet, vì attacker có thể sử dụng covert channel hoặc steganography. Các phương thức kiểm soát truy cập mạng (Wired, wireless) kể trên của bạn mặc dù quan trọng, nhưng chỉ nên coi là lớp phòng thủ cuối cùng và thứ yếu, vì chúng ít hiệu quả và attacker cũng không nhất thiết phải sử dụng Internet để truyền dữ liệu ra ngoài.

ldd wrote:

Mình rất mong có những chuyên gia cảm thấy thú vị để "ngồi nghịch" giao thức này như bạn nói! Hãy xem điều đó như một cuộc dạo chơi, một chút "bé yêu khoa học", một chút khám phá...

Mình e rằng các chuyên gia thực thụ sẽ không có thời gian ngồi nghịch giao thức của bạn, vì rằng trên thế giới ở mỗi thời điểm luôn có hàng ngàn người đang làm y như bạn. Thứ nhất, giao thức của bạn hiện ở trình trạng đóng, thứ hai, nó chưa có đặc điểm nào thực sự mới hoặc nổi trội. Ví dụ: truyền file qua HTTP hỗ trợ cả nén và mã hoá.

ldd wrote:

Như mình đã đề cập ở bài gần nhất, thì đây là 1 giao thức lai giữa FTP và SSL. Còn điểm đặc biệt thì có lẽ sẽ còn nhiều vì đây là giao thức tự chế, nghĩa là mình có thể thêm vào bất kỳ một logic mới nào đó (và vẫn phải dựa trên nền TCP). Mình có thể ví dụ nhé: như mỗi lần truyền tải thì dữ liệu sẽ được mã hoá theo một kiểu khác nhau, và thứ tự các kiểu mã hoá này là random. Hoặc có thể dùng nhiều kiểu mã hoá bất đối xứng trong cùng 1 phiên gửi nhận dữ liệu... đây chỉ là ý tưởng, mình chưa hiện thực nó vào GBProtocol vì nghĩ rằng làm thế sẽ ảnh hưởng nhiều đến tốc độ truyền tải dữ liệu.

Quan điểm chủ quan của mình là bạn chưa thực sự nắm vững về lĩnh vực mật mã nên mới đưa ra những ý tưởng trên. Bạn đã bắt chước SSL, vậy tại sao không dùng thẳng SSL luôn? Hơn nữa SSL đã lỗi thời, có lẽ bạn nên tham khảo TLS.

ldd wrote:

Điểm đặc biệt của GBProtocol là việc truyền tải dữ liệu ở chế độ mã hoá hoặc không mã hoá là vẫn trên cùng 1 port, không giống như các chuẩn khác phải là 2 port riêng rẽ cho chế độ mã hoá và không mã hoá.

Mình chưa hiểu điểm đặc biệt này nó đặc biệt ở chỗ nào. Việc chia ra 2 port riêng biệt sẽ giúp ích rất nhiều trong việc quản lý, trong tiếng anh người ta gọi là fine granularity.

Nếu bạn muốn nhận được những đánh giá chính xác và sâu sắc về protocol của bạn liên quan đến hiệu suất, độ tin cậy và tính bảo mật thì tốt nhất bạn nên viết một tài liệu trình bày cặn kẽ tất cả các thiết kế liên quan đến protocol cũng như (nếu cần thiết) software ứng dụng protocol này. Nếu không sẽ rất hiếm người có thời gian mò cái source code của bạn để phân tích.

Ở thời điểm hiện tại, việc phổ biến một protocol là vô cùng khó khăn, vì các lí do sau:
- Yêu cầu của giới chuyên gia là rất cao.
- Tính năng mới phải thật sự xuất sắc.
- Quá trình chuẩn hoá rất phức tạp.
- Chi phí cài đặt/thay đổi rất tốn kém.

Tuy nhiên mình vẫn rất hoan nghênh việc này, vì đây là một trong những cách tốt nhất và nhanh nhất để nắm vững về hệ thống mạng.

Khi ta nói một cái modem hoạt động ở tầng Data link, thì có nghĩa là chức năng chính của cái modem đó là ở tầng Data link, còn việc có thể truy cập vào nó qua Web hay cái gì thì chả liên quan gì đến chức năng của nó. Ngoài ra, việc truy cập vào một cái modem cũng không nhất thiết phải diễn ra trên mô hình OSI hoặc TCP/IP, tức là không qua kết nối mạng.

Bạn tìm hiểu về mac-then-encrypt và encrypt-then-mac.

duyvu09 wrote:

Chào mọi người. Mình có đọc trong cuốn sách Computer Networking-A Top-Down Approach Featuring the Internet và đến phần Queuing Delay http://210.43.128.116/jsjwl/net/kurose/introduction/delay.htm) có đoạn ví dụ:

When is the queuing delay big and when is it insignificant? The answer to this question depends largely on the rate at which traffic arrives to the queue, the transmission rate of the link, and the nature of the arriving traffic, i.e., whether the traffic arrives periodically or whether it arrives in bursts. To gain some insight here, let a denote the average rate at which packets arrive to the queue (a is units of packets/sec). Recall that R is the transmission rate, i.e., it is the rate (in bits/sec) at which bits are pushed out of the queue. Also suppose, for simplicity, that all packets consist of L bits. Then the average rate at which bits arrive to the queue is La bits/sec. Finally, assume that the queue is very big, so that it can hold essentially an infinite number of bits. The ratio La/R, called the traffic intensity, often plays an important role in estimating the extent of the queuing delay. If La/R > 1, then the average rate at which bits arrive to the queue exceeds the rate at which the bits can be transmitted from the queue. In this unfortunate situation, the queue will tend to increase without bound and the queuing delay will approach infinity! Therefore, one of the golden rules in traffic engineering is: design your system so that the traffic intensity is no greater than one.

Mình đọc và không hiểu lắm!, ví dụ như "a" có phải là tốc độ trung bình của một gói tin đến queue hay không?, "that all packets consist of L bits" có phải ý là tất cả các gói tin đều có độ dài là L bit?. và tại sao tốc độ trung binh mà bits(bits ở đây là tổng số bit của 1 packet?) đến queue lại là La bits/sec?. Mong các bạn giúp mình. Cảm ơn mọi người.
(Anh văn mình rất là kém, mình đang tập đọc tài liệu anh văn!, có thể trên đây là những câu hỏi khá cơ bản với mọi người, nhưng mong các bạn giúp mình).

Vấn đề của bạn thuộc về phạm trù đọc hiểu tiếng Anh hơn là về kiến thức. a ở đây không phải là tốc độ, mà là số lượng packets đến mỗi giây. L là độ lớn mỗi packet (theo bit). Như vậy La là số lượng bits đến mỗi giây. R là số lượng bits được chuyển tiếp mỗi giây.

conmale wrote:

Cho đến bây giờ vẫn chưa thu thập được những thông tin cốt yếu để xác định HVA vừa bị tấn công cụ thể như thế nào bởi vì ngay khi luồng DDoS ập vào thì nhà cung cấp dịch vụ đã "null-route" trọn bộ traffic đến IP của HVA. Bởi thế, từ bên trong máy chủ, mình không có cách nào capture được thông tin cụ thể.

Xét trên biểu hiện tổng quát thì dường như đây là một dạng spoof IP để DDoS bởi vì trên logs của máy chủ có một số thông tin về cảnh báo spoof IP ngay trước lúc nhà cung cấp dịch vụ tiến hành "null-routing". Đây chỉ là phỏng đoán và không chắc là đúng vì không có bằng chứng cụ thể ở cấp độ "packet".

Giải pháp hiện thời là tạo ra một loạt (càng nhiều càng tốt) các reverse proxies đứng trước HVA để chẻ traffic ra thành nhiều phần nhỏ nhằm tránh tính trạng 1 máy chủ bị "null-route".

Anh conmale cho em hỏi là ISP tiến hành "null-routing" là do họ tự nguyện hay là do anh thuê cái dịch vụ "null-routing" này của họ? Nếu họ tự nguyện thì anh có biết lí do tại sao họ lại bỏ công sức ra làm vậy hay không?

Cám ơn anh.

conmale wrote:

Mình đang nói đến điểm mạnh và yếu của giao thức mà. Mình chưa bàn đến băng thông.

Nói về khả năng chống DDoS của IPv6, hay nói đúng hơn là của IPSec, nhận định của em là như sau:
- Giống như TCP SYN flood, IKEv2 hoàn toàn có thể bị DDoS bằng cách tương tự với các kết nối half-open từ fake(forged) IP.
- Cả TCP và IKEv2 đều hỗ trợ cookie, chỉ riêng điểm này đã nói lên vấn đề với IKEv2
- IKEv2 tệ hơn TCP ở chỗ, khi không hỗ trợ cookie, IKEv2 cần nhiều computing power hơn để xử lý half-open connections, vì nó phải giải mã packet.
- Cả TCP và IPSec đều chống được IP spoofing/forging cho các layer cao hơn nó.
- IPSec có lợi thế hơn TCP ở chỗ nó hoạt động ở IP layer, còn TCP ở tầng cao hơn, và vì thế quá trình bóc tách headers cho mỗi packet cũng ít hơn 1 lần.
- Tuy nhiên, với các kiểu DDoS giả dạng flash crowds, TCP chắc là "sống khoẻ" hơn IPSec nhiều vì nó không đòi hỏi encryption và integrity check.

Từ đó, em nghi ngờ về nhận định rằng với việc IPv6 được sử dụng đại trà, tình trạng và hậu quả của DDoS sẽ được cải thiện.

conmale wrote:

Chuyện DDoS thì không bao giờ có thể triệt tiêu hoàn toàn được. Chỉ có thể giảm thiểu.

Đây là vì anh chỉ đứng dưới góc độ của end systems nên mới có nhận định như thế. Cái em muốn thảo luận là về các đặc điểm của một mô hình lí tưởng mà ở đó có thể (chỉ là ví dụ) botnets vẫn tồn tại, nhưng mà dùng nó đi tấn công bất cứ hệ thống nào, dù nhỏ dù lớn, dùng bất cứ phương pháp gì (kể cả bandwidth DDoS) cũng không còn nhiều tác dụng (ví dụ: bị dập tắt chỉ sau 5-10 phút). Bối cảnh đó khác hoàn toàn với tình trạng "sống chung với lũ" và "mạnh ai nấy lo" hiện nay.

conmale wrote:

- Nếu chủ nhân không muốn tham gia DDoS và là nạn nhân thì trước tiên chỉ có mỗi "nạn nhân" ấy bị block thay vì hàng loạt người bị block như tình trạng hiện nay. Cái này giúp giảm thiểu "từ chối dịch vụ" do chính biện pháp ban. Nếu 100000 static IPv6 IP bị ban thì chỉ 100000 IP đó bị ban thay vì 100000 x 10 hoặc x 100 bị ban như IPv4 hiện nay thì vẫn tốt hơn.

À như vậy thì hậu quả DoS so với IPv4 được giảm đi 10 hoặc 100 lần. Nhưng mà như vậy liệu đã phải là cái đích cuối cùng của cuộc chiến chống DDoS?

conmale wrote:

- IP Spoofing không tồn tại với IPv6 được.

Ở đây theo em hiểu ý của anh là receiver hoàn toàn có thể xác định IP address của sender trước khi tiến hành communicate ở các layer cao hơn. Điều này thì em đồng ý. Tuy nhiên IPv6 với IPSec căn bản không có chống được ai đó spoof (hoặc nói đúng hơn là fake) IP address và gửi packet khi bắt đầu IKE. Dù IKE có khả năng chịu đựng DDoS tốt hơn các protocol ở layer cao như TCP, nhưng hoàn toàn khác với việc chỉ cần nhìn IP address sau đó drop và drop.

conmale wrote:

- Người bị DDoS (chủ máy, chủ hệ thống) ban chớ chẳng có ISP nào ban cả. Người bị DDoS có trọn quyền cho phép hoặc ban bất cứ nguồn IP nào vi phạm. Nếu "nạn nhân" bị ban vì chính máy mình là zombie thì người bị ban phải có trách nhiệm tự xoá zombie, tự phục hồi để không bị ban.

Vậy còn vấn đề bandwidth DDoS thì sao anh? Nếu bandwidth của anh bị bão hoà thì dù anh có cấu hình firewall kiểu gì cũng vô ích.

conmale wrote:

Chuyển sang IPv6 thì 90% những kẻ hở của giao thức trong IPv4 sẽ bị loại bỏ và bởi thế, DDoS cũng bị loại bỏ 1 phần lớn.

Khi chuyển sang IPv6, mỗi thiết bị được gán cho 1 IP riêng và nếu IP ấy dùng để DDoS thì nó sẽ bị ban vĩnh viễn. Khỏi DDoS .

Anh có thể cho một số ví dụ về kẽ hở của IPv4 mà sau khi được khắc phục bởi IPv6 thì DDoS sẽ bị hạn chế?

Còn câu sau của anh thì em không đồng ý, có 3 lí do:
- một IP được sử dụng để DDoS không phải là do chủ nhân IP đó muốn, mà là do thiết bị sử dụng IP đó đã trở thành zombie. Nếu IP đó bị ban, thì lại nảy sinh một vấn đề DoS mới, mà anh tưởng tượng giả sử một botnet khoảng 100000 máy bị dùng làm DDoS, mà nếu ban IP của 100000 máy đó thì không phải là DoS trên diện rộng sao.
- nếu IP spoofing vẫn còn tồn tại, làm sao tìm ra chính xác 100000 máy trong botnet để ban IP
- kể cả tìm ra được, ai sẽ thực hiện việc ban IP? ISP chăng? Tier 3, tier 2, hay tier 1 chăng? Họ được lợi gì trong việc đó?

Nhân việc HVA là nạn nhân thường xuyên của các cuộc đánh phá DDoS (nếu mình không nhầm), hôm nay mình muốn mở một cuộc thảo luận với đề tài "DDoS đi về đâu?":

Như các bạn đã biết, DDoS cho đến thời điểm này đã trở thành một vấn nạn của Internet toàn cầu. Mục tiêu của các vụ tấn công DDoS trải khắp các hệ thống và dịch vụ trên Internet, từ các website nhỏ, đến các hệ thống thương mại điện tử (e-commerce), đến các cơ sở hạ tầng quan trọng (critical infrastructure) của các nhà nước và chính phủ. Vậy, sự tiến hoá của công nghệ làm thế nào để loại bỏ vấn nạn này? Để giúp việc thảo luận thêm dễ dàng, mình có một số các câu hỏi gợi ý như sau:
- Những nguyên nhân cơ bản nào cho phép DDoS trở nên dễ dàng như vậy?
- DDoS nên được phân loại như thế nào?
- Nêu các đặc điểm tất yếu của một giải pháp lý tưởng cho mỗi loại DDoS (hoặc DDoS nói chung)? Tất nhiên có thể có nhiều giải pháp lý tưởng cho mỗi loại DDoS (hoặc DDoS nói chung)
- Các đặc điểm này có thể tồn tại song song với nhau hay không?
- Với các đặc điểm như vậy, mức độ tốn kém của việc triển khai giải pháp lý tưởng ra sao?
- Những rào cản nào sẽ xuất hiện trong quá trình triển khai?

Mời các bạn tham gia.

Thân mến.

1. OSI thì căn bản là không sniff được, vì giờ không có ai dùng OSI, mà là TCP/IP
2. Không hiểu chủ đề là về việc đọc các dữ liệu của một gói tin hay là làm cách nào để bắt được gói tin đó?
3. ARP poisoning thì không có liên quan gì đến routing hết, vì routing là thuật ngữ dùng cho IP layer của TCP/IP.