... Lúc này, JAL đã SSH vào firewall của HVA và chúng tôi "chat" xuyên qua talk daemon -74-. Tôi bảo JAL rằng tình hình xem ra căng thẳng chớ chẳng đơn giản. Hai anh em trao đổi khá nhiều về tình trạng ứ nghẽn do dạng UDP DDoS mới mẻ này. JAL buộc miệng hỏi: "Sao mình không thử cho chúng vào 'black hole' anh?" Tôi lẩm bẩm: "Black hole, black hole, /dev/null..... " và chợt nhớ ra tôi đã từng thiết lập một cơ chế "/dev/null" này cho firewall của HVA trước đây -75-. Tôi bảo JAL: "Được rồi, để anh. Bây giờ anh đi ngủ, anh quá mệt rồi."  

# iptables -A INPUT -p udp -j DROP > /dev/null 2>&1

conmale wrote:

... Lúc này, JAL đã SSH vào firewall của HVA và chúng tôi "chat" xuyên qua talk daemon -74-. Tôi bảo JAL rằng tình hình xem ra căng thẳng chớ chẳng đơn giản. Hai anh em trao đổi khá nhiều về tình trạng ứ nghẽn do dạng UDP DDoS mới mẻ này. JAL buộc miệng hỏi: "Sao mình không thử cho chúng vào 'black hole' anh?" Tôi lẩm bẩm: "Black hole, black hole, /dev/null..... " và chợt nhớ ra tôi đã từng thiết lập một cơ chế "/dev/null" này cho firewall của HVA trước đây -75-. Tôi bảo JAL: "Được rồi, để anh. Bây giờ anh đi ngủ, anh quá mệt rồi."  

Thế này được không anh? Code:

# iptables -A INPUT -p udp -j DROP > /dev/null 2>&1

 

Hì hì, em nghĩ sao? Được không? Cái > đó sẽ đưa cái gì vào /dev/null? 

Cho phép em hỏi một tẹo. Một socket được khởi tạo thì nó cần có tham số là source hay destination port kèm với tham số giao thức cũng như IP, vậy anh bạn kia hẳn phải viết lại cả socket library của trình biên dịch (compiler) thì mới có thể thực hiện một kết nối và gửi một packet đi khi mà không hề tồn tại tham số port đích ( packet đó không biết nó sẽ chạm tới đâu ,tới port nào ). P/s: Nếu có sai chỗ nào thì mọi người góp ý dùm vì mình lâu rồi không còn nguyên cứu chuyên sâu về kĩ thuật nữa, kiến thức cũng rớt dần. 

Cho phép em hỏi một tẹo. Một socket được khởi tạo thì nó cần có tham số là source hay destination port kèm với tham số giao thức cũng như IP, vậy anh bạn kia hẳn phải viết lại cả socket library của trình biên dịch (compiler) thì mới có thể thực hiện một kết nối và gửi một packet đi khi mà không hề tồn tại tham số port đích ( packet đó không biết nó sẽ chạm tới đâu ,tới port nào ).  

em có vài điều băn khoăn ở đây với thiết kế của HVA mình phần firewall, sao lại thực hiện cản lọc chi tiết vậy anh. Điều này có gì đó trái với suy nghĩ của anh về việc thiết kế firewall chỉ cho phép các ứng dụng hợp lệ và loại trừ mọi phần còn lại. vd với UDP, ngoại trừ cho phép kếi nối UDP đến một IP dns nào đó mà ta tin cậy, mọi udp khác cần bị drop. Suy nghĩ của anh về một rule drop null port sẽ mang tính là ứng dụng với tình huống hiện tại chứ chưa phải là cho phép loại trừ tổng quát <sry vì hơi khó diễn đạt >  

Tôi tự nhủ: "ngay cả firewall không drop mấy packets bất hợp lệ này thì chúng cũng tự động bị triệt tiêu vì chúng chẳng đi về đâu cả. Thôi, cứ thử nghiệm để xem thêm thế nào." 

Có một điểm lợi với phương pháp này là mình có thể log (lưu tường trình) -71- để nắm tổng quát biên độ, trường độ và cường độ của dạng tấn công này 

Em có check thử thấy hva open 3 port là 80 25 và 5555,em nghĩ với các cổng này, chỉ giao thức TCP là được phép truy cập với trạng thái thông thường nhất <đủ port, đủ IP, state hợp lý và rate trong hạn>, mọi giao thức khác cần xóa bỏ.  

More: với một server thường, bảo mật được như HVA là tốt rồi, tuy nhiên em băn khoăn về khả năng HVA chống chịu tấn công phá hoại. Với ví dụ trên ,sao HVA chưa tích hợp thêm firewall phần cứng hoạt động chế độ tranfarent lọc cản các gói tin không hợp lệ trước khi đi vào HVA server với firewall iptables. Cụ thể anh đã phải nhờ vào can thiệp của ISP để cản lọc ở phần router và hầu hết các tác vụ cản loại thực hiện ở OS <và cho dù như vậy, hva vẫn hoạt động thật tuyệt vời.> 

2. Để gửi raw socket thì không cần phải viết lại gì cả. Tất cả hệ điều hành đều hỗ trợ khả năng này, miễn là bạn có đủ quyền.  

Giả sử mình có thêm 1 firewall nằm bên ngoài nữa, liệu mình có khắc phục được tình trạng bị DDoS như trên, thuần túy do cản lọc hay không? Em đọc lại bài viết thật kỹ để tìm thấy cái hướng anh đang khai triển ra cho bài kế tiếp. Nhắc lại: cản lọc không có hiệu quả gì cả trong trường hợp này. 

Anh conmale, Vẫn đang tò mò chờ xem anh implement cái blackhole bằng iptables như thế nào. Em chưa có dịp thử, nhưng đoán là anh dùng PREROUTE để đưa các gói không hợp lệ vào localhost port nào đó có /dev/null ? Em nghĩ giải pháp cho tình trạng này là thay vì filter traffic thì nên để mấy gói tin bất hợp lệ đi vào, và đi qua thật nhanh. Các gói UDP đó không có ảnh hưởng gì cho hệ thống mà mình lại phải tốn thời gian filter -> input queue có thể bị đầy. Nếu có thể (sử dụng blackhole như anh nói) đưa các gói tin bất hợp lệ đi qua thật nhanh mà không cần process nó thì có thể free một chút băng thông làm việc khác. khoai 

Em có đọc qua tài liệu về route null, cụ thể có link minh họa ở đây The difference between iptables DROP and null-routing http://www.tummy.com/journals/entries/jafo_20060727_140652 Trong bài viết, tác giả cũng viết khá rõ ràng, rằng nếu sử dụng iptables thì hệ thống ít nhất cần so sánh các tham số như ip gói tin, loại gói tin, port ,.... trong khi nếu sử dụng route null thì chỉ cần thông số duy nhất là IP mà thôi. Nhưng có 2 vấn đề trở ngại là : - phải biết đích xách IP nguồn gửi, vấn đề này tưởng dễ mà không dễ nếu như chúng ta bị 1000 host tấn công một lúc - gói tin cần qua iptables trước khi được route, phải chăng cần stop iptables để xuống thẳng firewall ?? hoặc tệ hơn chút là iptables chỉ check ip và accept ngay khi có IP nguồn hợp lệ <trùng với ip block> để cho nó xuống thẳng route và nhét vô route null. Cho dù vậy, xét thấy nó vẫn cứ thế nào ấy, ít nhất vẫn cần iptables check IP nguồn rồi route lại check tiếp ip nguồn, 2 lần check. Thực ra kỹ thuật này không có cái gọi là /dev/null để redict gói tin đâu. ;)  

ip route add $REMOTEADDRESS via 127.0.0.1

Hì hì, em đoán đúng đó. Em có thể phân tích thêm lý do tại sao em nghĩ rằng mình phải "đưa các gói không hợp lệ vào localhost port nào đó" mà không phải là /dev/null (như một device bình thường)? 

$ nc -l -p 12345 -u -e /dev/null

conmale wrote:

Hì hì, em đoán đúng đó. Em có thể phân tích thêm lý do tại sao em nghĩ rằng mình phải "đưa các gói không hợp lệ vào localhost port nào đó" mà không phải là /dev/null (như một device bình thường)? 

Em chỉ không nghĩ ra cách gì wwwect dữ liệu đi vào network device sang một device khác (ở đây là /dev/null). Nhưng iptables có thể wwwect traffic sang một interface khác nhờ cơ chế NAT. Do đó em nghĩ mình có thể tọa một process nào đó, lắng nghe trên localhost port 12345 udp. Sau đó dùng iptables rules, match các udp rules hợp lệ. Còn các gói udp khác thì cứ đưa nó vào localhost:12345. Cái process đang LISTEN trên localhost:12345 có thể đưa dữ liệu vào /dev/null. Ví dụ Code:

$ nc -l -p 12345 -u -e /dev/null

khoai 

hi hi Xem ra Mr Khoai gần tìm được ra đáp án rồi. Rõ ràng các làm này tối ưu hơn nhiều so với route null rồi. Em chỉ còn chút thắc mắc về việc xử lý với 1000 IP 1 lúc, rõ ràng để lập nên list các ip là một việc khó,lưu lại và kiểm tra list IP này với delay nhỏ nhất chắc còn nhiều việc để phải suy nghĩ sâu nữa.Không biết anh commale có thể gợi ý chút xíu gì không Em đề nghị dừng thảo luận về giải pháp ở đây, để có anh commale còn vốn viết tiếp hồi sau nhỉ :P :P  

Có một điều làm em thắc mắc: tại sao bác admin lại mang vấn đề này ra thảo luận và lại mong muốn mọi người hiểu rõ bản chất của vấn đề nhỉ? Có lợi gì và có hại gì cho chính bác và cho actker? 

Mr. Khoai "đẩy" đến chỗ dùng netcat để đưa packet vào /dev/null theo dạng đã đưa ra ở trên là một gặt hái rất lớn trong việc thảo luận. Tiếc là Mr. Khoai chưa giải thích tại sao một packet đi vào xuyên qua một socket không thể wwwect vào một device như /dev/null smilie . Khai triển ngọn ngành điểm này thì mức độ lãnh hội về internet socket, unix socket, devices và filesystem sẽ đi đến chỗ chín mùi. 

Hix, khổ ghê, lần nào thảo luận gì đó với anh đều tìm ra cả đống thứ phải học. Em vẫn không thể giải thích tại sao không thể wwwect network traffic vào /dev/null, mà phải wwwect đến một socket. Theo em nghĩ, netfilter được iptables điều khiển. Tuy nhiên iptables và netfilter không cung cấp một công cụ nào đó để mình wwwect dữ liệu sang một device khác. Netfilter có thể wwwect network traffic sang một socket khác (một IP : PORT khác) nên em nghĩ đến cách đó. Hy vọng trong bài tiếp theo, hoặc một bài nào đó, anh sẽ giới thiệu hoặc giải thích phần trên một cách rõ ràng.  

ls -a > /dev/null

Ky0shir0, Điểm quan trọng ở đây khoai nghĩ là anh conmale muốn phổ biến kiến thức và tạo môi trường thảo luận trên diễn đàn. Không thể dựa vào điểm các attacker không biết mình implement cơ chế bảo mật thế nào để rồi nghĩ là mình sẽ không bị tấn công. Đọc mấy bài này y như coi phim/đọc truyện kiếm hiệp :D khoai 

Đọc mấy bài này y như coi phim/đọc truyện kiếm hiệp :D khoai 

Nói về mặt "mở rộng" thảo luận khiến cho attacker lợi dụng tiếp tục tấn công thì việc này đã và đang xảy ra với HVA. Cái khó nằm ở chỗ không giấu, vẫn chia sẻ, vẫn mở rộng, vẫn ứng dụng được mà kẻ tấn công không thể lợi dụng để làm gì khác. Đây cũng là một trong những điểm phải... "hy sinh" để rộng đường thảo luận vậy :P . 

Trong các ký sự của đại ca con ma le lé (đừng lấy dép chọi u đầu em) :D nếu anh trai cho đám nhỏ, đàn em như em file tcpdump khi bị tấn công đem về nhà phân tích thì quá tốt :)  

Hi nếu như có file đó rùi, cần chi nữa không ? file config firewall nha ? Thực ra mình kô nghĩ điều đó là cần thiết, vì Mr Commale cũng miêu tả rõ ràng rồi mà. Hơn nữa, sao bạn không thử chơi cờ tưởng nhỉ, hacker là mình thì sẽ DDOS nè, rồi mình sẽ chống thế này nè -:-) -:-) Ask for more hay Deep thinking  

... Vì sao iptables không thể "wwwect" input stream vào /dev/null bằng các cách như >, hoặc pipe vân vân? Lý do là iptables không cung cấp cho mình một interface để tương tác với /dev/null, và, input stream không thể ra vào trực tiếp trên các file stdin, stdout và stderr. Mình có thể chạy iptables bằng bash (script), và khi sử dụng các ký tự đặc biệt này thì chính bash sẽ open stdin, stdout, và stderr, rồi chính bash sẽ lo vụ wwwect. iptables khi nhận một gói tin sẽ open các files khác (socket, cho wwwect, hoặc /dev/eth1 nếu đang làm gateway chẳng hạn) và "wwwect" gói tin đến file đó.  

Giả sử iptables có một target là -j NULL, ta có thể wwwect input stream trực tiếp từ socket vào /dev/null. Lúc này, chính iptables sẽ open /dev/null và tiến hành write dữ liệu vào đó. Việc hack netfilter và iptables để làm việc này thì không phải không làm được. Nhưng mình có thể sử dụng một cách khác để đạt kết quả tương tự. khoai 

Cho em chen ngang chút : Trong router cisco có phải dủng câu lệnh này phải kô ạ: Code:

ip route x.x.x.x x.x.x.x null0

 

dabu wrote:

Cho em chen ngang chút : Trong router cisco có phải dủng câu lệnh này phải kô ạ: Code:

ip route x.x.x.x x.x.x.x null0

 

Để làm chi em? 

hi anh conmale, ngoài việc bị flood đường truyền, hình như công đoạn log của iptables cũng làm cho server load cao. Phải vậy ko anh?