Duck hunt

.Tải Uc Browser 9.6 bản mới vào mạng và download nhanh gấp 8 lần OperaUc Browser,OperaMini

.
Wap UpLoad FORM
UC BROWSER 9.6
[Download] [Hướng Dẫn]
tCú Pháp Đăng Ký Nick Team
tNinja School Online 1.3.7
tMạng Xã Hội Avatar 2.5.8
tBắn Súng Mobi Army 2.3.9
tKhí Phách Anh Hùng 1.6.7
»Phong Vân Truyền Kỳ V30
tNgôi Làng Của Gió 3D 1.1.7
»GROUP-YOUTUBE-FANPAGE«

home>HACKING

.

Lượt Xem: XtCAT -:- 404
0: php_network_getaddresses: getaddrinfo failed: Name or service not known
Advertise Here

404 - Page Not Found - Back Home


Total Visits: 40776123
Visits Today: 208758
This Week: 3298226
This Month: 6591471

This site, is built entirely by using XtGem.

XtGem is a visual mobile site building tool, allowing users to create and maintain highly customizable personal mobile sites completely free of charge - and without a need to know any programming language at all!

-Tóm tắt những điểm tối quan trọng trong việc chống chọi với DDoS (distributed denial of service attack) cho những ai quan tâm.
- DDoS có nhiều dạng, nhiều biến thái tấn công nhưng tượng trưng có một mục đích: làm người dùng không thể sử dụng được dịch vụ.
- DDoS có hai dạng chính:
1) làm ngập băng thông khiến cho người dùng không thể truy cập dịch vụ.
2) làm cho dịch vụ hoàn toàn tê liệt vì hết tài nguyên khiến cho người dùng không thể truy cập dịch vụ.
Chống đỡ hai dạng trên đều đòi hỏi gia tăng tài nguyên (băng thông, CPU, diskspace, memory). Tài nguyên càng phát tán rộng ra nhiều network càng tốt.
- Giảm thiểu tác hại của DDoS có hai hướng chính:
1) Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể.
2) Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian (nếu không tìm ra được đặc điểm cụ thể).
- Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể dựa trên những thông tin lấy từ logs (tổng quát về IP, user-agents, số lần truy cập trong một khoảng thời gian nào đó) hoặc từ packet capturing bằng tcpdump hoặc wireshark (chi tiết tính chất trong các packet header và payload). Làm việc này đòi hỏi am hiểu đặc tính của log và tính chất của các gói tin.
- Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian dựa trên kết quả phân tích số lần truy cập đi từ một IP trong một khoảng thời gian. Làm việc này đòi hỏi am hiểu đặc tính của log.
Bốn điểm cần lưu ý:
I. Cản trên tầng IP cho những đặc điểm cụ thể trên tầng IP (ví dụ: iptables). Cản trên tầng application cho những đặc điểm trên tầng application (ví dụ: mod_security). Tránh đừng cản lọc những thứ thuộc về tầng application trên tầng IP và ngược lại, tránh đừng cản lọc những thứ thuộc tầng IP trên tầng application vì chúng không hiệu suất.
II. Nếu blackhole (/dev/null) được ngay trên router thì thực hiện ngay thay vì cản lọc trên firewall.
III. Cản lọc không dừng lại ở MỖI TẦNG mà ở trên TẤT CẢ CÁC TẦNG GIAO THỨC bất cứ nơi đâu có thể được, thậm chí phối hợp giữa các tầng.
IV. Tính hiệu suất, gọn nhẹ là chìa khoá để bảo tồn tài nguyên.
DDoS và nguyên tắc phân tích gói tin
Giảm thiểu tác hại của DDoS có hai hướng chính:
1) Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể.
2) Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian (nếu không tìm ra được đặc điểm cụ thể).
Từ những thông tin nào có thể giúp mình thực hiện việc giảm thiểu ấy? Cách khó nhất, tỉ mỉ nhất nhưng cũng chính xác nhất là lấy thông tin từ những gói tin bắt được trong lúc chúng tràn vào mục tiêu (để thực hiện việc DDoS).
Có lẽ một trong những công cụ phổ biến nhất ngày nay cho công việc bắt gói tin và phân tích gói tin đó là Wireshark (ngày xưa có tên là Ethereal). Công cụ này cho phép chúng ta sắp xếp gói tin theo:
ddos- thời gian gói tin đi đến.
- theo nguồn IP của gói tin.
- theo dạng giao thức của gói tin.
- theo chiều dài của gói tin.
- và đi sâu vào tính chất của từng gói tin.
Tuỳ nhu cầu, tuỳ hoàn cảnh mà sử dụng biện pháp sắp xếp để phân tích. Đôi khi cần phải đổi từ cách sắp xếp gói tin từ dạng này sang dạng khác để có thể nắm bắt tính chất được xem là "đặc điểm cụ thể".
Tất nhiên, logs trên proxies, trên web server (như Apache, Nginx, IIS..v..v..) cũng có thể dùng để phân tích nhưng chúng thiếu hẳn những thông tin cụ thể về giao thức. Tuy vậy chúng có điểm lợi là đơn giản hơn, dễ phân tích hơn nhưng nếu muốn nắm rõ tính chất những gói tin thuộc dạng DDoS không thể không dùng Wireshark để bắt gói tin và phân tích gói tin.
Lấy một đoạn packets được dùng để tấn công một nạn nhân gần đây (5/7/2013), chúng ta có thể thấy gì?
- Các gói tin đã được sắp xếp (sort) theo nguồn (IP) ở đây đang tập trung vào phân tích nguồn 113.170.184.21.
- Nếu bấm vào dòng có giao thức là HTTP và có Info là "GET / HTTP/1.1" thì sẽ thấy có giá trị "User-Agent" hiện ra. Theo thông tin ở đây, đó là một điện thoại di động dạng Android và có địa phương (locale) là Canada (en-ca).
- Gói tin HTTP kia có chiều dài là 502 bytes (bao gồm chiều dài của gói tin TCP/IP tầng dưới).
- Nếu sử dụng tính năng "follow TCP stream" của gói tin cụ thể trên, bạn sẽ thấy một nhóm các gói tin được gởi / nhận và được ráp lại.
Nếu xoáy sâu xuống một chút, mình có thể thấy thêm đây là một gói ACK có PSH flag và có chiều dài là 448 bytes.
ddosNếu tiếp tục xem xét danh sách các request đi từ 113.170.184.21, bạn sẽ thấy nhiều gói tin có tính chất y hệt xảy ra nhiều lần. Đó là chuyện bình thường nhưng sự thể sẽ bất thường khi cùng một IP lại có User-Agent khác cùng gởi request trong cùng 1 giây đó và đặc biệt, chúng gởi request đến cùng một địa chỉ lặp đi lặp lại liên tục như: http://www.abc.c om/ trong một khoảng thời gian.ddosNhững thông tin trên có vẻ rất bình thường nhưng đó là một bức ảnh mẫu để so sánh và để đặt ra những câu hỏi giúp cho việc phân tích, ví dụ:
a. Tại sao một IP thuộc Việt Nam mà lại dùng bằng điện thoại Android có ấn định địa phương là Canada?
b. Tại sao một IP như trên lại có User-Agent khác có ấn định địa phương là từ Đan Mạch gởi nhiều request cùng một lúc đến cùng một địa chỉ URL?
c. Tại sao những HTTP requests kia có cùng những nhóm "length" y hệt nhau và lặp đi lặp lại?
d. Tại sao chúng có cùng giá trị Referer, thậm chí Referer ấy không tồn tại?
e. Có bao nhiêu requests xảy ra trong một giây, một phút, 5 phút đi cùng một IP có cùng một User-Agent?
f. Có bao nhiêu User-Agents khác nhau đi từ một IP trong một khoản thời gian nào đó?
g. Liệu những IP tấn công kia có phải là IP của một proxy có nhiều người dùng chung hay không?
v....v....v....
Nói chung, càng nhiều câu được đặt ra và trả lời càng giúp cung cấp các thông tin để hình thành những điểm đặc thù của dạng tấn công. Từ đó mới có thể hình thành biện pháp cản lọc.
1. Cản lọc trên tầng IP:Là những cản lọc thuần tuý mang tính chất thuộc về tầng IP thay vì những "string" và "text" thấy được ở tầng application (sau khi các packets đã gom lại hoàn chỉnh). Ví dụ, bạn thống kê được có 1 triệu requests đánh tới "index.php" có mấy chục User-Agents khác nhau và những requests này thuộc dạng ACK-PSH và có chiều dài chung là 488, 502, 515, 576, 590 (chẳng hạn). Trong khi đó, các requests (được xem là hợp lệ và sạch sẽ) của người dùng bình thường có chiều dài khác. Bạn có thể có hai chọn lựa:
1.1 Cản cụ thể các packets ACK-PSH có chiều dài như trên vì bạn (biết) rằng người dùng đến trang web của bạn không có mấy ai xài đổ địa phương là Canada, Đan Mạch, Belarus...v.v.v.. Chọn lựa này có thể cản nhầm một số người nhưng trong tình trạng bị đập nặng nề, đó là một chọn lựa nhằm cứu vãn số người dùng còn lại.
1.2 Cản tổng quát dựa trên số lần truy cập trong 1 giây (hoặc một phút, hoặc một khoản thời gian nào đó). Lý là người dùng bình thường chẳng có ai liên tục truy cập hàng chục lần đến trang chủ trong mỗi giây hoặc vài trăm lần đến một hoặc nhiều URL trong một phút. Chẳng có ai có thể đọc nhanh như thế.
2, Cản lọc trên tầng application:Là những cản lọc cụ thể và chính xác những "string" và "text" thấy được trên logs của các web server. Ví dụ, bạn thống kê được có 1 triệu requests đánh tới "index.php" có mấy chục User-Agents khác nhau và bạn biết rằng những User-Agents ấy trước giờ ít xuất hiện vì không có mấy ai xài đổ địa phương là Canada, Đan Mạch, Belarus...v.v.v.. Bạn cũng có hai chọn lựa:
2.1 Cản cụ thể các User-Agents lạ như đã thống kê. Chọn lựa này có thể cản nhầm một số người nhưng trong tình trạng bị đập nặng nề, đó là một chọn lựa nhằm cứu vãn số người dùng còn lại. Ngày nay, biện pháp cản lọc trên tầng application có vô số các công cụ, tiên ích, plugins, modules...v..v... giúp cho việc này.
2.2 Cản tổng quát dựa trên số lần truy cập trong 1 giây (hoặc một phút, hoặc một khoản thời gian nào đó), y hệt với nguyên tắc phần 1.2 ở trên.
ddos-DDoS và nguyên tắc hành động cụ thể
Một số bạn hỏi tôi "hành động cụ thể" ra làm sao? Đây là câu hỏi khó vì mitigateDDoS là công việc cực kỳ khó khăn. Việc này chẳng những đòi hỏi phải am hiểu giao thức mạng một cách tinh tế để xác định mình đang bị tấn công như thế nào mà còn đòi hỏi thấu đáo mô hình, cấu trúc, công nghệ và cách quản lý của hệ thống đang bị lâm nạn. Không có một thiết bị kỳ diệu nào có thể tự động nhận diện và khắc phụcDDoS một cách dễ dàng cả.
Như tôi đã đề cập trong bài đầu tiên: "Cản lọc không dừng lại ở MỖI TẦNG mà ở trên TẤT CẢ CÁC TẦNG GIAO THỨC bất cứ nơi đâu có thể được, thậm chí phối hợp giữa các tầng." và việc này chỉ có thể do NGƯỜI THẬT thực hiện. Hãy bàn đến mô hình để nắm rõ hơn tại sao việc thấu đáo nó là tối quan trọng.
1. Mô hình:Thông thường, một data center có một hoặc nhiều đường cáp đến nhà cung cấp mạng và mỗi đường cáp này kết nối với một thiết bị định tuyến bìa (border router). Bên trong thiết bị định tuyến này có thể là tường lửa ngoài và khu vực này được chia ra làm nhiều mảng mạng được gọi là DMZ, chúng được bảo vệ bằng nhiều tường lửa khác nhau. Một trong những mảng DMZ có thể được dùng cho khu vực dịch vụ web. Khu vực này có thể là một hoặc nhiều mạng tách biệt và có thể có ít hoặc nhiều thiết bị tuỳ theo nhu cầu. Một trong những mô hình điển hình có dạng như sau:
ddosMô hình được hình thành thế nào xuất phát từ chính sách bảo mật cụ thể dựa trên nguyên tắc CIA (confidentiality, integrity và availability) và được thiết kế để thoả mãn từng nhu cầu cụ thể của từng môi trường. Bởi vậy, sự hiện diện của mỗi tầng, mỗi cấu phần đều có mục đích cụ thể và chính xác và không thể hình thành theo phản xạ tự nhiên hay theo việc bắt chước ai đó vì họ "dùng như thế", "thiết kế như thế".ddosVì mỗi tầng có đặc trưng và trách nhiệm khác nhau cho nên khi hỏi "hành động cụ thể" phải làm gì có nghĩa là "hành động cụ thể" phải CỤ THỂ CHO TỪNG ĐẶC TRƯNG VÀ TRÁCH NHIỆM ĐÓ. Chẳng những vậy, "hành động cụ thể" còn tuỳ thuộc vào cụ thể từng loại thiết bị, từng hệ điều hành, thậm chí từng ứng dụng được sử dụng (hoặc có ý định sử dụng). Đó là chưa kể đến khía cạnh khả năng tài chính và lực lượng kỹ thuật mỏng dày, cạn sâu như thế nào nữa.
2. Công cụ: Một khi mô hình, hoặc nói một cách khác: cái KHUNG của giải pháp đã được hình thành thì chọn lựa công cụ cho thích hợp là việc đi theo sau. Công cụ ở đây không hẳn là những thiết bị "cứng" đắt tiền, tiếng tăm mà có thể là những công cụ rẻ tiền, thậm chí miễn phí nhưng có thể đáp ứng chính xác vai trò của mỗi cấu thành.
Một trong những vấn nạn lớn lao là thiếu kinh nghiệm hoặc thiếu (sợ) trách nhiệm cho nên cứ chọn "giải pháp" mua thiết bị để dễ dàng đổ thừa cho đám bán thiết bị. Không có thiết bị nào trên cõi đời này có thể tự vận động mà không cần con người ấn định, thiết lập những thứ cần thiết và chính xác với nhu cầu của con người cả. Cái chính công cụ là "đồ nghề" để mà con người có thể làm việc, bất kể đắt tiền, rẻ tiền, thậm chí miễn phí, công cụ chọn lựa để thích hợp với bất cứ giải pháp nào cũng cần:
- linh động và chính xác.
- càng đơn giản càng tốt.
- càng dễ mở rộng càng tốt.
- càng có thể kết nối hoặc tương tác với các tầng, các cấu phần một cách dễ dàng càng tốt.
Phần còn lại là trí tuệ của con người trước tình huống.

=>Nguồn: Hoàng Ngọc Diêu (Notes)
.Thucdaik
Đăng lúc:18:04 23/01/2017
Chia sẻ:smsGZFT
Chia sẻ bài viết:

Link:
BBCode:
☆BÌNH LUẬN
0: php_network_getaddresses: getaddrinfo failed: Name or service not known
☆ BẠN XEM CHƯA?
※ TRUNG TÂM HỖ TRỢ
.[SMS]0932812053
.Yahoo!:AdmjnWapViip@yahoo.com
.Gmail:AdmjnWap@Gmail.Com
.FB:FaceBook Admin