Messages posted by: LeVuHoang

Mọi người trên kia đã nói hết rồi mà.

Releases 0.1.1 of IPCop up to and including 1.2 are not stateful as they are based of IPChains technology. Version 1.3 uses IPTables, and is a fully stateful firewall.

http://www.ipcop.org/index-pn.php?name=FAQ&id_cat=6

Tốt nhất, là sau khi cho cert vào webserver A, export cái cert+pub key+private key ra, thành 1 file .p12, rồi mang cái file này đi import vào đâu cũng được (web B, C, D). File p12 này cũng là để backup, vì nó cài vào bất kỳ server nào, server đó sẽ y chang webserver A.

Chính xác. 1 cert vẫn dùng cho 2 server được. 1 server tạo CSR, import cert xong, export ra .p12 rồi mang qua server 2 import vào.

---> cái này thì tùy thuộc vào cái path mà requests đi vào và cơ chế duy trì session khi truy cập xuyên qua https. Nếu em load balancing theo kiểu dùng DNS round robin cho 2 web servers chẳng hạn mà 1 cái thì mang verisign, 1 cái thì mang startCom thì sẽ có vấn đề.

anh conmale, em nghĩ thangdiablo sử dụng DNS round robin thì chắc không quan tâm đến vấn đề session. Cụ thể là login ở máy 1 và qua máy 2 vẫn còn ở trạng thái login. Thangdiablo confirm lại vụ này nha. Nếu chỉ là các trang tin tức, giới thiệu, không cần session, thì 2 cert này trên 2 server theo ý kiến cá nhân của tui vẫn có thể work bình thường.

1 cert làm sao có 2 CA chứng nhận được hả bác? bác có nhầm lẫn chỗ nào không ạ?

Trong trường hợp của thangdiablo, theo tui hiểu là 2 cert, 2 CA khác nhau. 1 là Verisign, 1 là StartCom. 2 cert này install trên 2 server khác nhau và thangdiablo sử dụng DNS round robin để chuyển qua lại. Có chỗ nào nói 1 cert, 2 CA đâu nhỉ?

À, nếu xài load balancer, giải pháp rẻ tiền ấy ạ, tớ ko biết pound là cái gì, tớ hay xài Apache (mod_ssl + mod_proxy + mod_balance), cái này có lẽ là rẻ nhất đó

http://www.apsis.ch/pound/

Giả thiết là không có load balance device có khả năng SSL đứng trước các webserver.

Phía trên tui có nêu giải pháp phần mềm là dùng Pound đó, không nhất thiết phải mua hàng khủng là F5, hehe. Thậm chí có thể dùng 1 server vừa làm load balancing vừa làm web server nhưng tốt nhất thì nên 3. Túm lại giải pháp rẻ tiền là pound.
Cũng như mrro nói, muốn biết 2 server, 2 CA khác nhau, chạy DNS round robin được không thì cứ lấy cái máy chủ ra chạy là biết ngay thôi mà smilie

mrro nói rõ rồi, có gì "hơi khó" đâu để xài 1 cert cho 2 (hay nhiều server), miễn là chúng phục vụ cùng 1 domain.

@thangdiablo: Quan trọng là lão cần cert cho 1 domain hay nhiều domain, có 2 giải pháp:
1. Nếu 2 server kia sử dụng sub-domain khác nhau như domain1.thang.com, domain2.thang.com thì lão phải mua 2 certs. Nếu muốn chỉ mua 1 cert thôi thì có thể xem xét mua wildcard cert của Verisign, hơi mắc xíu smilie

. https://www.verisign.com/ssl-certificates/wildcard-ssl-certificates/index.html
2. Nếu lão dùng 1 thiết bị cân bằng tải, proxy phía trước, có chức năng decrypt https, thì chỉ cần mua 1 cert thôi, rồi cung cấp cái cert của Verisign cho nó decrypt. Ví dụ của trường hợp này là pound (giải pháp phần mềm) và F5 (hardware)

- Việc xin cấp Certificate từ verisign sẽ diễn ra thế nào?

Steps trên site Verisign có, tui chỉ thêm 1 note cho lão là đại diện của Verisign sẽ gọi điện cho lão để hỏi lý do, confirm này nọ...

Theo tui nghĩ thì áp AV proxy chỉ là hạn chế sai lầm của người dùng thôi. Lão nên nghiên cứu cách để end-user ít bị nhiễm virus nhất. Làm rồi có được trả công không smilie

?

Chủ đề của bạn bị xoá thì không biết ai xoá, nhưng hôm đó bạn đã spam rất nhiều bài rác trong diễn đàn. Mỗi topic 1 chữ, ví dụ như "Welcome", "hva"...
Tôi buộc lòng phải xoá các bài đó và lock nick bạn.

Sự khác nhau duy nhất là mrro sử dụng "người học", còn họ thì dùng "máy học".

Cũng "máy học" mà StarGhost, nhưng ở mức độ simple chứ chưa có heuristic.

@gamma, mrro: vụ captcha là 1 ví dụ, thay vì đưa ngược IP lại vào iptables để chặn, script tiến hành đưa danh sách IP đó vào .htaccess để hiển thị bảng thông báo yêu cầu nhập user/pass định sẵn thì như thế nào?

Một khi đã chặn thì chắc chắn nó phải là zombie. Chỉ trừ trường hợp nhiều khách hàng sử dụng chung một IP, thì như đã nói ở trên, mình sẽ chặn zombie bằng các cách khác, chứ không chặn ở tầng network nữa.

Nếu mỗi khách hàng 1 IP thì mọi chuyện đơn giản hơn, nên mình đang quan tâm và suy nghĩ về vấn đề chặn ở tầng "khác network" smilie

Nếu chặn ở tầng network (ở cửa vào hoặc 1 chỗ nào đó phù hợp) thì 2 cái này hoàn toàn giải phóng khỏi việc kiểm tra các request từ nguồn IP biết chắc chắn rằng không hợp lệ. Vì ko có kết nối nào được mở cả, không có dữ liệu nào khác ngoài gói syn đến FW.

Vì thế phải kết hợp chặn ở nhiều tầng. Trong loạt bài "Ký sự các vụ DDoS vào HVAOnline", ngoại trừ việc cản ở iptables, còn bao gồm cả sử dụng mod_security và snort để phân tích payload và chặn gói tin.

Còn ở lớp ứng dụng, thì kết nối bất hợp lệ vẫn được tạo ra, request tấn công vẫn được gửi đến, và phải check luôn luôn các dữ liệu đó trước khi chuyển cho web app xử lý => tăng tải cho hệ thống kiểm soát đó.

mod_security kiểm tra url (có session) xong mới chuyển qua php, database... nhằm giảm thiểu số lượng connection.

Thiết nghĩ bạn myquartz không nên quá cứng nhắc như vậy vì filter ở network layer không phải là phương thuốc thần kỳ để có thể chặn đứng mọi cuộc tấn công. Trong loạt kí sự của bác conmale, mặc dù đã có filter ở tầng network, nhưng vì gói tin quá "hoàn hảo" nên bắt buộc phải dùng thêm snort/mod_security.
Bạn thử nghĩ nếu không để mod_security xử lý url trước khi đưa xuống php --> database thì liệu apache/mod_security chết trước hay database chết trước.

Trở lại với đề nghị của tui, log từ web server sẽ được đổ về log central, từ đó sẽ có 1 script phân tích, đẩy ngược IP lại vào .htaccess của web server và bắt người dùng nhập info hoặc captcha thay vì block IP.

@gamma: Dãy cookie "tao là người" có thể là 1 dãy random nhưng ở 1 số vị trí là cố định.
Ví dụ:
123ab456
789ab012

Nếu attacker tinh ý thì vẫn có thể đoán được tuy nhiên cũng giảm thiểu được tình trạng hiện tại?

@myquartz: Điều này là yếu điểm của real time response, tương tự như sử dụng mod_security hay snort để phân tích payload của request. Càng giới hạn offset của việc tìm kiếm sẽ giảm tải cho hệ thống.

1 cách khác có thể thay thế cho cookie là random url. Khi người dùng xác thực thành công, có thể được cấp cho value kiểu: /index.php?auth=123ab456
Đây cũng có thể nói là 1 kiểu cấp session. Bạn login rồi thì đi tiếp, chưa được cấp session thì dừng lại nhập captcha.
Cũng nên nhớ rằng, chỉ khi IP nào có request đột biến mới xuất hiện bản thông báo trên.

1 giải pháp khác nữa, là sử dụng .htaccess kết hợp với offline log analyzer của mrro, nếu IP đó vượt quá limit request, script sẽ tự động update IP trên vào .htaccess, yêu cầu nhập 1 user/pass định sẵn để tiếp tục.

Trở lại giải pháp của mrro là chặn ở tầng IP, trong kí sự của conmale thì luôn cật lực phản đối việc chặn như thế. Vậy giải pháp của mrro ngoài việc khách hàng gọi điện unblock IP thì có giải pháp nào khác để dung hoà cả 2?

Ngoài ra, ai có giải pháp hay hơn thì cứ trình bày cho mọi người cùng tìm hiểu.

Đây cũng là 1 giải pháp, nếu số request của 1 IP vượt quá giới hạn, web server hiển thị captcha cho người dùng nhập vào. Sau khi nhập xong, sẽ được cấp cookie "tao là người", và có cookie đó sẽ không bị hạn chế truy cập nữa. hehe

Đành chịu khó tiếp điện thoại từ Trung tâm dịch vụ khách hàng, để gỡ IP đó khỏi danh sách, hoặc cập nhật vào whitelist. Đơn giản phải ko?

Cái này đáng giá đây smilie

.
Giải pháp cookie bên trên chỉ là 1 suy nghĩ làm sao cố gắng "phân loại" được các request gọi đến. Gán cho nó 1 cái gì đó có đặc tính. Dĩ nhiên là không có giải pháp nào toàn diện cả, và phải cải tiến hoặc suy nghĩ giải pháp mới.

zoombie request thì thường sẽ khác với customer request, mình sẽ dựa vào đó để chặn trên application.

Trên thực tế thì trong cuộc DoS vừa qua của mrro và x-flash của conmale, thì đều có signature khác với customer request.
Giờ đặt trong trường hợp là ứng dụng gởi request hợp lệ (có thể đơn giản là dùng IE component, hoặc tạo 1 cái request có header y hệt như IE header) thì tầng application chặn như thế nào?
Nếu tinh vi hơn nữa, sau mỗi request tiến hành clear cookie thì sao?
Mình đang quan tâm việc chặn ở tầng application và giải pháp trên sẽ hành xử ra sao nếu các cú request nằm trong cùng 1 isp gateway.

Vấn đề này anh conmale cũng đã đề cập và giải quyết trong loạt bài "Ký sự các vụ DDoS vào HVAOnline" rồi mà anh!

Giải pháp này theo Hoàng được biết thì Iptables block IP thì phải, mrro confirm nhé.

trong loạt bài của anh conmale: Analyzer chính là IPtables + Snort, analyzer ở trong bài viết đó anh conmale đã dựa vào sự khác biệt của gói tin hợp lệ và gói tin tấn công để tiến hành lọc chứ không có block. Tuy nhiên giải pháp này cần sự can thiệp của người quản trị đúng như anh Thái đã nói ở trên

Đúng rồi, nhưng vấn đề trong chủ đề mrro muốn nêu ra là, "máy học". Tự động active response chứ ít có sự tác động của con người càng tốt.

Giải pháp cookie không hoàn chỉnh vì cookie ở đầu cuối người dùng, mà đầu cuối lại đã bị chiếm quyền điều khiển, hơn nữa việc DDoS không chỉ riêng web server.

Giải pháp cookie chỉ là 1 trong nhiều tần để cản lọc mà thôi.

Chứ tình huống thật thì nó khác từ nhiều cho tới rất nhiều nha

Nên mới chờ mrro nói chi tiết đây, hehe

Đối với vấn đề thứ nhất, chúng tôi cài đặt thêm một phần mềm cho các máy chủ Windows, để đẩy các sự trên trên đó về hệ thống log của chúng tôi

Thái cho hỏi là syslog/udp, có giải phảp syslog/tcp nào không?

Theo như tui hiểu, điều cốt lõi trong mô hình của mrro là log central và analyzer. Analyzer server sẽ tiến hành kết nối vào log central, phân tích, tổng hợp, đưa ra IPs có hơn 100 request/s rồi đưa ngược trở lại vào iptables để ngăn chặn. Những IP này có thể được unblock theo thời gian định trước.

Bài giới thiệu của mrro có phần hơi chung chung quá, mrro có thể giới thiệu kỹ hơn về server offline analyze kia không?
Cụ thể là, chặn ở tầng network và application như thế nào? Có còn chặn ở tầng nào khác hay không?

Ngoài ra, như ý tui đã nói ở phần trước, nếu 1 net cafe vài trăm users đang sử dụng. 1 user DoS site khách hàng, IP của net cafe đó sẽ được đưa vào blocked IP. Vậy tất cả các người dùng khác đều không thể truy cập được?

Một ý nữa hôm trước tui có nói sơ qua, là chặn theo request. Mô hình như sau:
attacker ===> analyzer ===> webserver

Bước 1: attacker request lần đầu tiên. Analyzer sẽ tiến hành insert 1 giá trị vào cookie của attacker, ví dụ count=1
attacker ===> analyzer [count = 1; requesttime=12:00:00] ===> webserver

Bước 2: attacker request tấn công lần nữa
attacker ===> analyzer [count =2; requesttime=12:00:01] ===> webserver

Trong 1 khoảng thời gian định trước, ví dụ như 1 giây, analyzer thấy số lượng request từ attacker có count quá nhiều, sẽ tiến hành deny request đó.
Như vậy, dù có cùng 1 IP, nhưng khác cookie, cũng vẫn truy cập bình thường

attacker ===> analyzer [count=100; requesttime=12:00:02] [stop]
user ===> analyzer [count=2; requesttime=12:00:02] ===> webserver

Nhiệm vụ duy nhất của analyzer là gán và check giá trị cookie của attacker.