<![CDATA[Latest posts for the topic "HVA bảo mật như thế nào?"]]> /hvaonline/posts/list/51.html JForum - http://www.jforum.net HVA bảo mật như thế nào? "HVA bảo mật như thế nào?" Tôi biết phần lớn câu hỏi này được đặt ra nhằm mục đích tìm tòi, tham khảo để áp dụng cho hệ thống riêng của mình. Vì tính bảo mật của chính HVA, tôi chưa bao giờ có thể trình bày một cách cụ thể và cặn kẽ nhưng câu hỏi này cứ tiếp tục được lặp đi, lặp lại cho nên tôi quyết định đưa ra một "case-study" cho nó. Tất nhiên, tôi sẽ không đưa ra những thông số cụ thể trong cấu hình (vì lý do bảo mật) nhưng tôi sẽ cố gắng đẩy case-study này thành một nơi giải đáp những thắc mắc chung về việc "HVA bảo mật như thế nào?" với hy vọng đưa ra những rút tỉa hữu ích. Một diễn đàn thiện nguyện và hoàn toàn không kinh doanh như HVA, một điểm đích cho đủ mọi loại thử nghiệm từ brute force cho đến các loại scripts, shells, cho đến các dạng tự động hoá "tìm lỗi" và những táy máy rất tỉ mỉ bằng tay và thường gặp nhất: DoS và DDoS, hãy hình dung xem HVA forum: - Cần những gì? - Cần thiết kế ra sao? - Cần quản lý như thế nào? - Cần bảo trì và theo dõi ra làm sao? Hãy cùng nhau khai triển càng chi tiết càng tốt. Mời bà con.]]> /hvaonline/posts/list/43059.html#267749 /hvaonline/posts/list/43059.html#267749 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#267754 /hvaonline/posts/list/43059.html#267754 GMT HVA bảo mật như thế nào? Code:
- Cần những gì?
Về phần cứng. em nghĩ cần một hoặc nhiều máy chủ sao cho đáp ứng đủ nhu cầu truy cập của người dùng (và có thể thêm nếu có sự cố), 1 firewall phần cứng như Pix hoặc ASA Về phần nhân lực thì phải có đội ngũ giỏi có khả năng điều hoạt server và biểt xử lý sự cố Code:
- Cần thiết kế ra sao?
Em thấy mọi hệ thống mạnh đều mang "phong cách" càng ít dịch vụ chạy trên server càng tốt để tránh rủi ro do lỗi phần mềm gây ra. Thường những máy chủ này chỉ chạy những dịch vụ tối cần thiết thôi. Hạn chế hoặc đóng các cổng không cần thiết (như chỉ cần chạy Web thì chỉ mở cổng 80) Sử dụng + Webapp Firewall như mod sec để loại bỏ các bad request, bad refer + stateful firewall như iptable để hạn chế số lần đăng nhập của ssh hay dùng tham số limit của iptable để hạn chế tấn công DDoS + Snort để phát hiện các hành động gây hại cho máy chủ, ở đây Snort đóng vai trò của 1 Network Instrusion Detection System ==> bất kì gói tin nào vào các cổng đang mở phải qua tay của firewall trước rồi mới được phép vào sâu trong server Chrooting cho server, cấm không cho chạy bất kì shell nào như BASH hay CSH.... chạy trong môi trường chroot Chỉ chạy các dịch vụ tối cần thiết như trên. Code:
- Cần quản lý như thế nào?
Thực hiện cập nhật rule cho snort thường xuyên. Để em tham khảo thêm Code:
- Cần bảo trì và theo dõi ra làm sao?
Theo dõi sát sao và sử dụng 1 số monitor để theo dõi CPU, RAM để tránh sự cố về phần cứng. Thêm vài cái tail để capture các gói tin đi vào và đi ra (thường là đối với port 80) Định kì bảo trì server, cập nhật các bản vá (pacth) ]]> /hvaonline/posts/list/43059.html#267755 /hvaonline/posts/list/43059.html#267755 GMT HVA bảo mật như thế nào? - Cần những gì?   1. Có lẽ việc sizing hệ thống ban đầu sẽ là 1 điểm bắt buộc phải quan tâm cho bất kì một hệ thống lớn nào. Ở HVA phải có tính chịu tải cao, giảm thiểu thời gian downtime thấp nhất, người dùng truy cập trơn chu và gặp những trở ngại hạn chế ít nhất trong phạm vi có thể chấp nhận được. (chẳng hạn việc các user bây giờ vô tình vẫn sẽ dính các rules của firewall nếu gateway không ổn định, trình duyệt đang cài cắm thêm các addons như anonymousX hay fake user agent Về mặt hệ thống, sự vận hành của tomcat - postgresql và 1 số các application chịu trách nhiệm cân bằng tải hay caching như nginx cũng phải luôn có sự đảm bảo về mặt chất lượng Ngoài ra, những công cụ quản trị & theo dõi cho phía người quản lí cũng phải được đảm bảo vận hành kĩ lưỡng, chạy đúng, chạy đủ. Áp dụng các giải pháp kiểm soát các luồng truy cập và phân quyền user tương tác trên hệ thống 1 cách hợp lí. Tổng quan, HVA cần tất cả những yếu tố cơ bản để hình thành một nền tảng có chất lượng. Dưới sự quản lí và tầm nhìn rộng cho 5 & 10 ... năm nữa Đây là những điểm HVA nên cần. update sau :-D ]]> /hvaonline/posts/list/43059.html#267756 /hvaonline/posts/list/43059.html#267756 GMT HVA bảo mật như thế nào? Đây không phải là topic hỏi đáp nên các bạn đừng đặt câu hỏi để người khác trả lời! Đây là topic thảo luận hướng gợi mở, để từng cá nhân biết cấu hình bảo mật cho server của mình Các bài viết nào vi phạm sẽ xóa không cần báo trước. - Ky0 -]]> /hvaonline/posts/list/43059.html#267757 /hvaonline/posts/list/43059.html#267757 GMT HVA bảo mật như thế nào? mitigate từng attack vector. Điều này có nghĩa cần đưa ra từng loại attack mà HVA đã, đang và sẽ bị attack để từ đó hình thành GIẢI PHÁP mitigate. Tất nhiên, khi nói đến giải pháp thì luôn luôn cần phân tích. Khi nói đến "từ brute force cho đến các loại scripts, shells, cho đến các dạng tự động hoá "tìm lỗi" và những táy máy rất tỉ mỉ bằng tay và thường gặp nhất: DoS và DDoS" thì ta đã nói đến tổng quát các dạng tấn công và từ đó có thể xác định các vector rồi. Khi nói đến "một diễn đàn thiện nguyện và hoàn toàn không kinh doanh như HVA" thì có nghĩa là nói đến kinh phí hạn hẹp. Kết hợp hai dòng in nghiêng ở trên, hãy hình thành mỗi attack vector và mỗi mitigation kèm theo phân tích.]]> /hvaonline/posts/list/43059.html#267759 /hvaonline/posts/list/43059.html#267759 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#267763 /hvaonline/posts/list/43059.html#267763 GMT HVA bảo mật như thế nào?

conmale wrote:
Một diễn đàn thiện nguyện và hoàn toàn không kinh doanh như HVA 
- Tiêu chí chung sẽ lựa chọn các giải pháp phần mềm open source và miễn phí - Chi phí tốn kém nhất của HVA là đầu tư Server, Đường truyền Internet, Và đám Clouds để hỗ trợ chống DDOS gần đây :D - Về mặt quản lý, bảo trì và theo dõi thì chủ yếu là anh em BQT tranh thủ thời gian bỏ công sức ra đề làm là chính.

conmale wrote:
HVA một điểm đích cho đủ mọi loại thử nghiệm từ brute force cho đến các loại scripts, shells, cho đến các dạng tự động hoá "tìm lỗi" và những táy máy rất tỉ mỉ bằng tay và thường gặp nhất: DoS và DDoS 
Để "chống chọi" với các thứ trên thì HVA: Cần những thứ sau: - Gỡ bỏ các thành phần không cần thiết để tránh lỗi phát sinh (VD: Jforum của HVA bị lột hầu hết các module và code lại một số thành phần theo nhu cầu riêng) - Tối ưu hóa lại tất cả các dịch vụ chạy trên server (MySQL, tomcat, apache, rule của firewall + snort + mod_security, Nginx ...)=> Gia tăng khả năng phục vụ của Server, hạn chế tài nguyên tiêu hao không cần thiết, nhất là khi bị tấn công DOS/DDOS - Tiến hành phỏng thủ theo mô hình pháp đài (IPtables lọc gói, Snort hỗ trợ IPtables ngăn các gói tin ở mức sâu hơn, Mod_Security cản lọc các request "không hợp lệ" mà các lớp bảo vệ trước đó chưa cản lọc được) => Cần phải tính toán kỹ lưỡng từng lớp bảo vệ sẽ cản lọc cái gì. Điều này đòi hỏi kiến thức và kinh nghiêm của người quản trị :P - Do thao tác trên server chủ yếu là từ xa xuyên qua SSH nên: + Thiết lập QoS cho dịch vụ này được ưu tiên khi bị DOS/DDOS. + Không cho đăng nhập SSH với quyền root + Chỉ cho phép kết nối SSH từ các IP cố định - Do HVA chỉ chạy dịch vụ Web(port:80/443) nên: + Che port SSH (22) trước các công cụ Scan như nmap hoặc map port SSH cho các bạn script kiddie và một số thành phần brute force thoải mái :D + Ví du: map port MySQL(Port:3306) sang port 22, Chỉ cho phép truy vấn SQL từ local, Map port SSH sang cổng 110 và "che" đi :P - Xây dựng các PC client sạch để truy cập vào quản lý HVA (tự build và compiler các phần mềm trên máy tính sử dụng Linux, Nếu dùng MacOS thì chỉ sử dụng các phần mềm tải từ Apps Store và chỉ cài các phần mềm có thể tin tưởng) Thiết kế cần: - Xây dựng nhiều server và cấu hình load balancing với nhau. - Xây dựng firewall mềm đứng trước Server và nằm trên một server riêng biệt. - Xây dựng vành dai proxies với Nginx, iptables, mod_security... trên các VPS có băng thông lớn Về mặt quản lý, bảo trì và theo dõi thì vẫn chờ mọi người chia sẻ thêm kinh nghiệm. - Ky0 - PS: Sẽ bổ sung các chi tiết cụ thể hơn sau :)]]> /hvaonline/posts/list/43059.html#267768 /hvaonline/posts/list/43059.html#267768 GMT HVA bảo mật như thế nào?

Ky0 wrote:
- Tối ưu hóa lại tất cả các dịch vụ chạy trên server (MySQL, tomcat, apache, rule của firewall + snort + mod_security, Nginx ...)=> Gia tăng khả năng phục vụ của Server, hạn chế tài nguyên tiêu hao không cần thiết, nhất là khi bị tấn công DOS/DDOS  
Không những tối ưu mà còn phải bảo mật các dịch vụ này nữa. Hồi bữa STL không thể tác động tới data của HVA vì khi login vào server thì database đã giới hạn connection. Và account STL lấy được có quyền "quá thấp" nên STL mới lấy bản data backup tại server ở nhà anh conmale để "show off".

Ky0 wrote:
- Xây dựng các PC client sạch để truy cập vào quản lý HVA (tự build và compiler các phần mềm trên máy tính sử dụng Linux, Nếu dùng MacOS thì chỉ sử dụng các phần mềm tải từ Apps Store và chỉ cài các phần mềm có thể tin tưởng)  
Cái này là bài học xương máu :D

Ky0 wrote:
- Ky0 - PS: Sẽ bổ sung các chi tiết cụ thể hơn sau :) 
Bổ xung thêm cái module ban ip đi anh: nhận ra ip đang DDoS, brute force các dịch vụ thì sẽ tiến hành ban 1 khoảng thời gian. Sau khi hết thời hạn ban nếu tiếp tục tấn công thì sẽ gia tăng thêm thời gian ban ip. Nếu đọc các bài viết của anh conmale và có trí nhớ tốt thì sẽ biết được các thứ anh Ky0 nói đến đã được anh conmale đề cập ở HVA qua:

Ky0 wrote:
+ Thiết lập QoS cho dịch vụ này được ưu tiên khi bị DOS/DDOS.  
Đọc ký sự DDoS hva thì thấy anh conmale để "lộ" cái này.

Ky0 wrote:
+ Không cho đăng nhập SSH với quyền root  
Đọc Rookie thì biết thêm cái này, ngoài ra trong bài Rookie anh conmale còn nói chi tiết hơn đến bảo mật ở ssh.

Ky0 wrote:
+ Chỉ cho phép kết nối SSH từ các IP cố định  
STL chỉ ssh được vào HVA từ ip nhà anh conmale]]> /hvaonline/posts/list/43059.html#267769 /hvaonline/posts/list/43059.html#267769 GMT HVA bảo mật như thế nào? Vấn đề đầu tiên: Cần những gì? Theo em cái đầu tiên và quan trọng nhất là như anh kienmanowar có nói: Đội ngũ quản trị cần những cái đầu lạnh để bình tĩnh ứng phó với mọi tình huống có thể xảy đến và cần những trái tim rực lửa nhiệt huyết , khát khao cống hiến cho cộng đồng. Và vì diễn đàn hiện nay vẫn còn mang tính thiện nguyện, không vụ lợi nên theo em cần tìm một nhà tài trợ mạnh mạnh trên tinh thần thiện nguyện, không vụ lợi, không đòi quảng cáo, hơi quá =)). Giải pháp trước mắt là dùng mã nguồn mở để tiết kiệm. Thiết kế như thế nào? Như đã nói ở trên, do không có kiến thức nên em bỏ qua phần này. Quản lý ra làm sao? Đầu tiên cũng là quan trọng nhất là cần tuyển chọn đội ngũ quản lý điều hành một cách kĩ lưỡng, họ cần có một nền tảng kĩ thuật tốt và kín miệng để tránh các loại social egineering :D . Quản lý chặt việc phân quyền trong quản lí, cụ thể mỗi người chỉ chịu trách nhiệm quản lí một phần trong trách nhiệm của mình, không một cá nhân nào có quyền hành tuyệt đối. Về vấn đề acccount có quyền tuyệt đối hay quen gọi là root thì nên dùng cơ chế phân chia password, tức là mỗi người trong ban quản trị chỉ nắm giữ một phần thông tin xác thực tài khoản này, cụ thể là chia nhỏ password. Quản lý, bảo trì ra làm sao? Nên phân công các thành viên trong BQT sao cho có thể trực 24/24, tránh tình trạng một người phải làm việc quá tải hoặc không có ai quản lí. Vài ý kiến của em mong mọi người nhận xét. ]]> /hvaonline/posts/list/43059.html#267773 /hvaonline/posts/list/43059.html#267773 GMT HVA bảo mật như thế nào?

whatdie15 wrote:
Về vấn đề acccount có quyền tuyệt đối hay quen gọi là root thì nên dùng cơ chế phân chia password, tức là mỗi người trong ban quản trị chỉ nắm giữ một phần thông tin xác thực tài khoản này, cụ thể là chia nhỏ password. Vài ý kiến của em mong mọi người nhận xét.  
---> Cái đấy chỉ là trong mơ thôi, không thể làm được. Thế lúc bạn ssh vào server rồi pm hỏi 1 admin khác đoạn password còn lại à (Thế thì bạn lại có full password rồi)? hay là cùng ngồi trên 1 máy rồi thay nhau gõ? Nếu muốn an toàn theo hướng của bạn thì dùng OTP. 1 admin khác cầm OTP. Mình thấy chủ yếu các bạn đề cập tới HVA bảo mật server để chống hacking mà không thấy ai đề cập tới HVA bảo mật để bảo vệ người dùng (ví dụ: session hijacking xuyên qua XSS). ]]> /hvaonline/posts/list/43059.html#267777 /hvaonline/posts/list/43059.html#267777 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#267799 /hvaonline/posts/list/43059.html#267799 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#267809 /hvaonline/posts/list/43059.html#267809 GMT HVA bảo mật như thế nào?

phanledaivuong wrote:
---> Cái đấy chỉ là trong mơ thôi, không thể làm được. Thế lúc bạn ssh vào server rồi pm hỏi 1 admin khác đoạn password còn lại à (Thế thì bạn lại có full password rồi)? hay là cùng ngồi trên 1 máy rồi thay nhau gõ? Nếu muốn an toàn theo hướng của bạn thì dùng OTP. 1 admin khác cầm OTP. Mình thấy chủ yếu các bạn đề cập tới HVA bảo mật server để chống hacking mà không thấy ai đề cập tới HVA bảo mật để bảo vệ người dùng (ví dụ: session hijacking xuyên qua XSS).  
Á à, ý tôi không phải vậy, thôi để tôi trình bày rõ hơn ý tưởng của mình nhé. Giả sử sever của HVA mình code thêm một phần, việc truy cập đến sever với các admin thì vẫn bình thường, nhưng giới hạn quyền hạn ở mức an toàn, còn nếu muốn thay đổi các thành phần có thể gây nguy hiểm thì phải cần chứng thực, ví dụ một admin muốn chỉnh sửa gì đó, thì trong một khoảng thời gian nhất định, nửa tiếng chẳng hạn, các admin khác vào log in và nhập mã xác nhận để chứng thực admin đó truy cập hợp lệ, admin đã được chứng thực thì có quyền cho đến khi log out. Mình thấy để bảo đảm an toàn thì như vậy cũng không bất tiện lắm, với lại đã cùng là admin thì phải có liên lạc với nhau chứ. Nhưng ở đây lại nảy sinh vấn đề, nếu đã là code thêm thì chắc chắn có lỗi, và có thể bị khai thác, nhưng dù sao cũng an toàn hơn. Bạn đưa ra ý kiến dùng one time pasword cũng là một ý kiến hay, ít ra là nó cũng đã được người ta ứng dụng thành công, còn ý tưởng của tôi thì vẫn còn trong mơ :^) Thân!!!!]]> /hvaonline/posts/list/43059.html#267814 /hvaonline/posts/list/43059.html#267814 GMT HVA bảo mật như thế nào? Whois domain hvaonline.net thì ta nhận được 2 nameserver mà domain trỏ đến là: + ns2.hvaonline.net (74.63.219.13) + ns2.afraid.org (1 free DNS) hvaonline.net (A Record) có 2 IPs được gán là: 78.46.136.116 76.72.167.122 Sau khi ta truy cập vào hvaonline.net, ngay lập tức ta lại bị di chuyển đến www.hvaonline.net (302 moved temporarily) - được lưu lại ở cache trình duyệt vì thế từ lần truy cập thứ 2 trở đi, ngay cả hvaonline.net bị down thì trình duyệt vẫn tự động di chuyển đến www.hvaonline.net -> Đánh lừa được khá nhiều bot nhỉ ? ;) Kể cả băng thông khi truy cập đến hvaonline.net bị nghẽn đi nữa, nhưng những member thường xuyên vào HVA thì lại được trình duyệt nó tự động nhảy sang www.hvaonline.net ... www.hvaonline.net (A Record) có tận 4 IPs được gán (nhiều sv thế :( ): 74.63.219.12 76.72.167.122 78.46.136.116 49.212.135.219 Đây có lẽ chính là những servers chính và chịu trách nhiệm sống còn cho HVA :D Ở đây mới chỉ là trang Home, còn sau đó khi truy cập vào portal hay forum cũng đều được wwwect 2 lần ... Giả thuyết của mình đặt ra là: - Liệu phía sau mỗi lần di chuyển đó( /top | /tof ) ở đây được 1 lần nữa được cản lọc thêm gì đó (...) :D Kế đến là /hvaonline/. Ở đây biết đâu được đằng sau nó thì cái nginx nó có làm thêm nhiệm vụ Proxy và chuyển tiếp về server ẩn phía sau nữa hay không ?   Đó là 1 số điểm trong nhiều điểm hay ở HVA ít người chú ý đến, nhất là mấy lão cấu hình server không nói ra để giữ nghề :-" ]]> /hvaonline/posts/list/43059.html#267922 /hvaonline/posts/list/43059.html#267922 GMT HVA bảo mật như thế nào?

phanledaivuong wrote:
Mình thấy chủ yếu các bạn đề cập tới HVA bảo mật server để chống hacking mà không thấy ai đề cập tới HVA bảo mật để bảo vệ người dùng (ví dụ: session hijacking xuyên qua XSS).  
Điều này luôn được ưu tiên. Hiện nay HVA đã huỷ bỏ việc cho phép chèn hyperlink vào bài viết để vô hiệu hoá mọi kiểu phishing lợi dụng HVA. Còn về XSS hay CSRF thì mấy lão cao thủ của HVA (mà-ai-cũng-biết-là-ai-đó B-) ) vẫn cứ ngày ngày "nghịch" .Bật mí cho mọi người biết là một số lượng không hề ít các lỗi XSS đã được tìm thấy và vá lỗi từ lâu lắc rồi. Bản Jforum hiện giờ có thể nói là đã được vá và sửa lỗi đến nỗi nó khác rất xa so với bản tại Jforum.net ]]> /hvaonline/posts/list/43059.html#267940 /hvaonline/posts/list/43059.html#267940 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#267955 /hvaonline/posts/list/43059.html#267955 GMT HVA bảo mật như thế nào? 1. Deny all, allow selective (cản hết, cho phép theo chọn lựa). 2. If not used, turn off (nếu không dùng, tắt bỏ). 3. Your strongest defense is your weakest point (điểm bảo vệ mạnh nhất chính là điểm yếu nhất của bạn). Với điểm số một, HVA không những deny all ở một tầng giao thức hoặc một ứng dụng mà trải dài từ tầng IP lên đến một chức năng cụ thể ở tầng ứng dụng. Theo mặc định, tất cả là DENY rồi sau đó mới xét đến chuyện ALLOW cái gì và lý do tại sao phải ALLOW. Ngay cả ALLOW rồi cũng phải phân tích cho kỹ cần bảo vệ và giám sát thế nào cho mỗi ALLOW. Với điểm số hai, một máy chủ hoặc một chuỗi máy chủ là để cung cấp dịch vụ. Nếu dịch vụ nào đó không được cung cấp thì không việc gì phải mở nó ra. Chẳng những mở nó hao tổn tài nguyên mà còn mở cửa cho một hoặc nhiều khả năng exploit. Bất cứ một dịch vụ nào được mở ra luôn luôn phải kèm theo các lý do thoả đáng tại sao nó được mở ra và cái gì dùng để kiểm soát và bảo đảm sự bảo mật của nó. Với điểm thứ ba, firewall, IDS, logs check, alerts... không thể bảo đảm bảo mật nếu như bất cứ một việc làm nào, một thay đổi nào, một chỉnh sửa nào trên hệ thống mà không thoả mãn được câu hỏi: WHY? "weakest point" trong bảo mật hầu hết là những thiếu sót hoặc những tắc trách ngu xuẩn vì chủ quan hoặc vì không thoả mãn cái WHY kia. Tất cả mọi thứ liên quan đến bảo mật chỉ gói gém trong 2 thứ: INPUT và OUTPUT. <sẽ tiếp tục khai triển>.]]> /hvaonline/posts/list/43059.html#267958 /hvaonline/posts/list/43059.html#267958 GMT HVA bảo mật như thế nào? 2. If not used, turn off (nếu không dùng, tắt bỏ).  Nguyên tắc này em nghĩ dễ làm cho người đọc nghĩ rằng sẽ build một đống rồi không dùng cái gì sẽ turn off cái đó. Điều này không đúng chút nào và cũng không nên xây dựng hệ thống theo nguyên tắc trên. Em thường xây dựng hệ thống của em từ “blank page”, có nghĩa là từ không có gì, và xây dựng bám sát vào trong nhu cầu cụ thể. Không dùng cái gì thì không install, chỉ install những thứ chắc chắn là sẽ dùng. Dĩ nhiên việc này sẽ mất sức nhiều hơn nhưng bù lại việc quản lý hệ thống sẽ dễ dàng hơn vì người xây dựng sẽ có sự am hiểu về những gì chạy bên trong hệ thống của mình. Điểm yếu duy nhất của cách này có lẽ là việc build cứng một giải pháp thế này nếu cần mở rộng thì thường phải đập ra xây dựng lại (mất sức, mất tiền, mất thời gian), và công việc này chỉ phù hợp cho những người giàu kinh nghiệm. Tuy nhiên nếu xét về bảo mật thì sẽ mang lại hiệu quả rất cao. Nói chung thì em nghĩ điểm thứ 2, nên chuyển thành : Xây dựng từ blank page sẽ phù hợp hơn.]]> /hvaonline/posts/list/43059.html#267985 /hvaonline/posts/list/43059.html#267985 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#268007 /hvaonline/posts/list/43059.html#268007 GMT HVA bảo mật như thế nào? Nguyên tắc này em nghĩ dễ làm cho người đọc nghĩ rằng sẽ build một đống rồi không dùng cái gì sẽ turn off cái đó. Điều này không đúng chút nào và cũng không nên xây dựng hệ thống theo nguyên tắc trên.  
Bạn có thể phân tích rõ hơn nguyên tắc thứ 2 mà anh ấy đề cập không đúng ở chỗ nào và tại sao được không, REASON ?  
Mình không nói nguyên tắc của anh conmale là sai, mình chỉ nói rằng nguyên tắc đó có thể làm người đọc lầm tưởng rằng ý của anh conmale là xây dựng một hệ thống theo kiểu all-in-one, rồi sau đó tắt những thứ không sài. Việc này sẽ vừa tốn thời gian và vừa sót đối tượng. Theo mình security không phải chỉ nằm trong phạm vi quản lý hệ thống mà bao gồm cả việc thiết kế và xây dựng. Đừng xây dựng xong một hệ thống rồi mới nghĩ đến security mà phải nghĩ đến security ngay trong lúc thiết kế và xây dựng.
Khi bạn cho rằng "chỉ install những thứ chắc chắn là sẽ dùng", mình nghĩ là còn sót 1 vế vì những thứ này sẽ cung cấp những DỊCH VỤ đảm nhận nhiều chức năng khác nhau - tuỳ vào đối tượng cụ thể nhé  
"những thứ" ở trên có thể hiểu là "dịch vụ" hoặc là "công cụ". Mình chỉ install những dịch vụ mình sẽ triển khai (webserver : nginx, mail-server: postfix, ... etc), những công cụ mình sẽ sử dụng trong lúc làm việc (htop, ...). Ngoài ra thì không install gì thêm.]]> /hvaonline/posts/list/43059.html#268012 /hvaonline/posts/list/43059.html#268012 GMT HVA bảo mật như thế nào?

C0denam3 wrote:
Nguyên tắc này em nghĩ dễ làm cho người đọc nghĩ rằng sẽ build một đống rồi không dùng cái gì sẽ turn off cái đó. Điều này không đúng chút nào và cũng không nên xây dựng hệ thống theo nguyên tắc trên. Em thường xây dựng hệ thống của em từ “blank page”, có nghĩa là từ không có gì, và xây dựng bám sát vào trong nhu cầu cụ thể. Không dùng cái gì thì không install, chỉ install những thứ chắc chắn là sẽ dùng. Dĩ nhiên việc này sẽ mất sức nhiều hơn nhưng bù lại việc quản lý hệ thống sẽ dễ dàng hơn vì người xây dựng sẽ có sự am hiểu về những gì chạy bên trong hệ thống của mình. Điểm yếu duy nhất của cách này có lẽ là việc build cứng một giải pháp thế này nếu cần mở rộng thì thường phải đập ra xây dựng lại (mất sức, mất tiền, mất thời gian), và công việc này chỉ phù hợp cho những người giàu kinh nghiệm. Tuy nhiên nếu xét về bảo mật thì sẽ mang lại hiệu quả rất cao. Nói chung thì em nghĩ điểm thứ 2, nên chuyển thành : Xây dựng từ blank page sẽ phù hợp hơn. 
Nhận xét của em rất đúng nếu xét ở góc độ "start afresh" để build 1 server hoặc một chuỗi server. Tuy nhiên, nếu xét ở góc độ kiện toàn và bảo trì hoặc thậm chí thay đổi chiến thuật phòng bị thì nguyên tắc "If not used, turn off" là nguyên tắc cứ xảy ra mãi. Trong quá khứ, HVA đã từng áp dụng một hệ thống external caching nhưng sau một thời gian thấy nó không hiệu năng mà còn bị hạn chế ở mặt scalability cho nên sử dụng cache ngay trong heap của JVM. Trong hoàn cảnh ấy, nguyên tắc "If not used, turn off" cực kỳ cần thiết bởi vì chính cache service nuốt memory. Ngày trước HVA cũng đã từng sử dụng snort rất chi tiết để detect DDoS và block nguồn DDoS. Tuy nhiên, sau khi áp dụng và chạy một thời gian thì thấy không hoàn toàn hiệu năng và không thể tránh được false positive cho nên quyết định bỏ snort ra. Khi đó, "If not used, turn off" rất cần thiết vì nó vẫn tiếp tục ngốn tài nguyên và tệ hơn nữa, nó tiếp tục tạo false positive. Về mặt building configuration, HVA chưa bao giờ sử dụng default configuration của bất cứ dịch vụ nào. Nếu xem cấu hình của từng dịch vụ chạy trên HVA (từ firewall cho đến web application) tất cả đều start clean slate. Đây là một nguyên tắc tốt, nó hỗ trợ cho "If not used, turn off" chớ không đối chọi với "If not used, turn off" :).]]> /hvaonline/posts/list/43059.html#268015 /hvaonline/posts/list/43059.html#268015 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#268038 /hvaonline/posts/list/43059.html#268038 GMT HVA bảo mật như thế nào?

9aa6 wrote:
HVA nhà mình bảo mật trên máy chủ host hay tập chung chủ yếu ở mã nguồn web vậy.  
Câu hỏi này tôi thấy dư thừa, đã là bảo mật thì phải kiện toàn hết khả năng mọi tầng chứ, làm gì có chuyện chỉ tập trung bảo mật server hoặc chỉ lo kiện toàn mã nguồn web, mà thật ra dịch vụ web chỉ là một phần của server thì nói bảo mật tức là làm hết tất cả các phần rồi còn gì. Mà anh conmale cũng có khai triễn ý "If not used, turn off" rồi còn gì, nếu không sử dụng thì đóng, mà dịch vụ web này không đóng tức là mình đang sử dụng thì đương nhiên là nó phải được đảm bảo an toàn rồi.]]> /hvaonline/posts/list/43059.html#268045 /hvaonline/posts/list/43059.html#268045 GMT HVA bảo mật như thế nào?

whatdie15 wrote:

9aa6 wrote:
HVA nhà mình bảo mật trên máy chủ host hay tập chung chủ yếu ở mã nguồn web vậy.  
Câu hỏi này tôi thấy dư thừa, đã là bảo mật thì phải kiện toàn hết khả năng mọi tầng chứ, làm gì có chuyện chỉ tập trung bảo mật server hoặc chỉ lo kiện toàn mã nguồn web, mà thật ra dịch vụ web chỉ là một phần của server thì nói bảo mật tức là làm hết tất cả các phần rồi còn gì. Mà anh conmale cũng có khai triễn ý "If not used, turn off" rồi còn gì, nếu không sử dụng thì đóng, mà dịch vụ web này không đóng tức là mình đang sử dụng thì đương nhiên là nó phải được đảm bảo an toàn rồi. 
vậy hva có tận 4 hay 5 cái server riêng ạ. Nếu mà thuê máy chủ thuê host thì làm sao mà bảo mật đc trên máy chủ (cái này phải do nhà cung cấp dịch vụ chịu trách nhiệm đúng ko ạ) .ý e là thế]]> /hvaonline/posts/list/43059.html#268173 /hvaonline/posts/list/43059.html#268173 GMT HVA bảo mật như thế nào?

9aa6 wrote:
vậy hva có tận 4 hay 5 cái server riêng ạ. Nếu mà thuê máy chủ thuê host thì làm sao mà bảo mật đc trên máy chủ (cái này phải do nhà cung cấp dịch vụ chịu trách nhiệm đúng ko ạ) .ý e là thế 
Chuyện không bảo mật được server chỉ xảy ra nếu bạn xài host share thôi, HVA mình là xài máy chủ riêng mà, nếu mà xài host share thì trước mấy vụ đốt như vũ bão của mấy lão phá phách vô server ta, băng thông nào chịu cho nổi. Chắc bạn chưa đọc bài Ký sự các vụ DDos đến HVA, nếu không tinh chình server được thì làm sao có loạt bài đó.]]> /hvaonline/posts/list/43059.html#268177 /hvaonline/posts/list/43059.html#268177 GMT HVA bảo mật như thế nào?

whatdie15 wrote:
Á à, ý tôi không phải vậy, thôi để tôi trình bày rõ hơn ý tưởng của mình nhé. Giả sử sever của HVA mình code thêm một phần, việc truy cập đến sever với các admin thì vẫn bình thường, nhưng giới hạn quyền hạn ở mức an toàn, còn nếu muốn thay đổi các thành phần có thể gây nguy hiểm thì phải cần chứng thực, ví dụ một admin muốn chỉnh sửa gì đó, thì trong một khoảng thời gian nhất định, nửa tiếng chẳng hạn, các admin khác vào log in và nhập mã xác nhận để chứng thực admin đó truy cập hợp lệ, admin đã được chứng thực thì có quyền cho đến khi log out. 
Với vấn đề này của bạn đề ra thì HVA có 1 cách xử lý rất "tuyệt vời" -> Các nick administrator như conmale, mrro, PXMMRF, ... Cũng chỉ có quyền như 1 nick moderator bình thường thôi bạn ạ.

conmale wrote:
Ba nguyên tắc nền tảng mà HVA bảo mật là: 1. Deny all, allow selective (cản hết, cho phép theo chọn lựa). 2. If not used, turn off (nếu không dùng, tắt bỏ). 3. Your strongest defense is your weakest point (điểm bảo vệ mạnh nhất chính là điểm yếu nhất của bạn).  
Đọc nhiều bài của anh conmale viết rồi, mà em vẫn quên không tổng hợp để thấy được cái "tư duy" của người bảo mật server HVA(không biết dùng từ tư duy có chuẩn hay không nên mới cho vào ngoặc kép). Nhân tiện anh viết bài mới phát hiện ra nếu tổng hợp được những bài anh conmale viết thì sẽ chém gió được 1 tý :D, mọi người đọc thêm các link gợi ý để thấy được "tư duy" của người bảo mật server HVA. 1. Deny all, allow selective (cản hết, cho phép theo chọn lựa)
/hvaonline/posts/list/0/105.html 
2. If not used, turn off (nếu không dùng, tắt bỏ).
/hvaonline/readingRoom/item/19279.html 
3. Your strongest defense is your weakest point (điểm bảo vệ mạnh nhất chính là điểm yếu nhất của bạn).
/hvaonline/posts/list/27967.html#171736 
]]> /hvaonline/posts/list/43059.html#268228 /hvaonline/posts/list/43059.html#268228 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#268525 /hvaonline/posts/list/43059.html#268525 GMT HVA bảo mật như thế nào? 1. Deny all, allow selective (cản hết, cho phép theo chọn lựa). Thế nào là "deny all, allow selective" và tại sao phải cần như vậy? Có hai nguyên tắc được áp dụng: 1. allow all, deny selective. 2. deny all, allow selective. nhưng chọn lựa thứ nhì trở thành nguyên tắc được áp dụng rộng nhất và chấp nhận nhiều nhất. Deny all bảo đảm không có gì có thể vượt qua rào cản, loại bỏ khả năng "cho phép" nhưng không kiểm soát được sự cho phép hoặc không ngờ đến sự cho phép đã xảy ra ngoài ý muốn. Trên firewall của HVA, 3 dòng luật được ấn định ngay từ đầu: # DROP everything as default. iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP và kết thúc bằng 3 dòng "catch all": iptables -A INPUT -s any/0 -j DROP iptables -A OUTPUT -d any/0 -j DROP iptables -A FORWARD -s any/0 -j DROP Những gì không trùng hợp với những gì cho phép sẽ mặc định được "DROP". Tất nhiên, với ấn định "deny all" này không bảo đảm tuyệt đối bảo mật bởi vì còn phụ thuộc vào "allow selective" bao gồm cụ thể những gì. Vậy, "allow selective" là những gì và làm sao bảo đảm bảo mật? Để trả lời cho câu hỏi này, việc đầu tiên là xác định nhu cầu cụ thể cần bảo mật là gì?. Đối với HVA, dịch vụ duy nhất là web và hai cổng dịch vụ cần thiết là 80 và 443. Khi đã xác định tổng quan cổng dịch vụ cần mở và cần bảo vệ, luật cho firewall trở nên cụ thể và rõ ràng. Vậy, mở cổng 80 và cổng 443? Nghe rất đơn giản nhưng, mở rồi thì bảo vệ nó như thế nào đây? Cứ mở toang ra vô hạn định? HVA thường bị tấn công với những dạng nào? Đây là "mục tiêu di động" và "allow selective" là một khối di động, luôn luôn thay đổi, luôn luôn được điều chỉnh để thích hợp với nhu cầu bảo vệ hiện tại. Tôi tránh không trưng bày chính xác bộ luật firewall của HVA lên đây vì lý do bảo mật nhưng trên mặt nguyên tắc mà nói thì đa phần HVA bị tấn công từ chối dịch vụ và một phần nhỏ những tấn công dạng brute force để dò account hoặc để "thử nghiệm" các exploits mới từ metasploit hoặc các tools tương tự. Ngoài chức năng "đóng cái gì và mở cái gì", firewall còn kiểm soát các "connection state" để ngăn chặn những dạng exploit ở tầng web (nhưng khá hiếm). Vậy, để bảo vệ từ các nguồn exploits như brute forece và tấn công từ chối dịch vụ, firewall của HVA cần gì? - Cần xác định CHÍNH XÁC đặc điểm của người dùng bình thường (từ tính chất packet cho đến trường độ và cường độ) ---> A. - Cần xác định CHÍNH XÁC dạng tấn công từ chối dịch vụ, brute force, tool scanning..v..v.. có đặc điểm gì (từ tính chất của packet cho đến trường độ và cường độ) ---> B, C, D.... Từ đó mới phân tích sự khác biệt giữa A với B, C, D... để hình thành những thứ gì được "allow". Đó chính là "allow selective" theo đúng nhu cầu thay vì allow trơn, không hạn định. Ngoài tầng IP, mỗi tầng ứng dụng đều có chế độ "allow selective" khác nhau. Ví dụ, Trên tầng web, cụ thể là apache, những khu vực "nhạy cảm" được "allow seletive" như: Code:
<Location /path/to/somewhere>
                AuthUserFile /usr/local/etc/selectiveusers
                AuthName "This is a protected area"
                AuthGroupFile /dev/null
                AuthType Basic
                Require valid-user
                Order deny,allow
                Allow from xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
                Deny from all
</Location>
Thậm chí, ngay trên "application firewall" như mod_security, ấn định: SecDefaultAction "phase:2,deny,log,status:403,t:removeNulls" bắt đầu từ bộ luật cụ thể cho mod_security. Điều này có nghĩa bất cứ những gì không trùng hợp với những luật đã cho phép thì tự động sẽ là error 403. Một lần nữa, "allow selective" ngay trên tầng ứng dụng web cũng đòi hỏi một nguyên tắc: xác định nhu cầu cụ thể cần bảo mật là gì?. Giả sứ, diễn đàn HVA chí mở rộng "context" (URI) là /hvaonline/ để public access thì chỉ có mỗi /hvaonline/ được cho phép và tất cả những thứ còn lại đều không cho phép. Chẳng những vậy, đã cho phép truy cập /hvaonline/ rồi nhưng cho phép cụ thể những điều kiện nào? Đây cũng là một "mục tiêu di động" lúc thư giãn, lúc chặt chẽ... tuỳ tình hình. Chỉ có điều, càng lên cao trên tầng ứng dụng, mọi luật trong khuôn khổ "allow selective" càng cụ thể và đa dạng bởi vì, trên tầng ứng dụng cụ thể là web, mỗi HTTP header, mỗi ứng dụng mở rộng cho phép web từ chỗ "request / response" sang chỗ có session... đều có những vai trò và hiểm hoạ khác nhau. Tất cả mọi chi tiết đều được viết xuống, được phân tích và được "tick" hay "untick" trước khi hình thành một bộ luật cụ thể.]]> /hvaonline/posts/list/43059.html#268946 /hvaonline/posts/list/43059.html#268946 GMT HVA bảo mật như thế nào?

conmale wrote:
diễn đàn HVA chí mở rộng "context" (URI) là /hvaonline/ để public access thì chỉ có mỗi /hvaonline/ được cho phép và tất cả những thứ còn lại đều không cho phép. Chẳng những vậy, đã cho phép truy cập /hvaonline/ rồi nhưng cho phép cụ thể những điều kiện nào? Đây cũng là một "mục tiêu di động" lúc thư giãn, lúc chặt chẽ... tuỳ tình hình. Chỉ có điều, càng lên cao trên tầng ứng dụng, mọi luật trong khuôn khổ "allow selective" càng cụ thể và đa dạng bởi vì, trên tầng ứng dụng cụ thể là web, mỗi HTTP header, mỗi ứng dụng mở rộng cho phép web từ chỗ "request / response" sang chỗ có session... đều có những vai trò và hiểm hoạ khác nhau.  
Nếu muốn xây dựng được một bộ luật như vậy thì chắc phải cần nhiều công sức, thời gian, sự cẩn thận của người làm công tác bảo mật lắm anh nhỉ? Sẵn đây cho em hỏi luôn, nếu một server được xây dựng theo định hướng allow all, deny selective (vì lý do nào đó) thì những lỗ hỗng nào sẽ thường bị bỏ sót, hoặc được phát hiện và deny nhưng không khả thi?]]> /hvaonline/posts/list/43059.html#268983 /hvaonline/posts/list/43059.html#268983 GMT HVA bảo mật như thế nào? 1) bí mật bảo mật cho HVA và 2) không hẳn có thể dùng chính xác những gì HVA ứng dụng để bảo mật cho trường hợp của mình bởi vì mỗi mỗi trường mỗi khác, mỗi nhu cầu mỗi khác. Tuy nhiên, ở mức độ nhất định, chúng ta vẫn có thể khai triển góc độ này. Thử khai triển trên tầng IP trước xem sao? 1. Mở cổng 80: Như đã đề cập lần trước, P (policy) cho INPUT, OUTPUT và FORWARD theo mặc định là DROP. Điều này có nghĩa, nếu có dòng luật: iptables -A INPUT -s any/0 -p tcp --dport 80 -j ACCEPT ---> luật đi vào. iptables -A OUT -d any/0 -p tcp --sport 80 -j ACCEPT ---> luật đi ra. thì có nghĩa bất cứ request nào đi từ đâu (-s any/0) dùng giao thức tcp (-p tcp) mà có cổng đích là 80 (--dport 80) thì accept (-j ACCEPT) nhưng... "mở" như vậy liệu có bảo mật không? Câu trả lời ngay là: KHÔNG. Không là bởi vì ở tầng IP này, nếu ấn định một luật cho phép đơn giản như vậy, firewall chỉ dừng lại ở cấp độ "packet filtering" chớ không còn phát huy được tính chất "statefull firewall" nữa. Hơn nữa, trong trường hợp bị tấn công từ chối dịch vụ, bị brute force và bị những dạng tấn công "nhảy ngang" vào một tcp session thì luật trên hoàn toàn không bảo vệ cái gì hết. Bởi vậy cần những nhóm luật như sau để cản trở những dạng tấn công không nằm trong một "state" nào hết hoặc với những TCP options bất hợp lệ, ví dụ: Code:
# all the bits are cleared
iptables -A INPUT -p tcp -s $NET --tcp-flags ALL NONE -m limit --limit 1/s -j LOG --log-prefix "INVALID_CLEARED_BIT: "
iptables -A INPUT -p tcp --tcp-flags ALL NONE -s $NET -j DROP

# both SYN and FIN are set
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -s $NET -m limit --limit 1/s -j LOG --log-prefix "INVALID_SYN-FIN: "
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -s $NET -j DROP

# both FIN and RST are set
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -m limit --limit 1/s -s $NET -j LOG --log-prefix "INVALID_FIN-RST: "
iptablesS -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -s $NET -j DROP

# only FIN bit is set without ACK accompanying
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -m limit --limit 1/s -s $NET -j LOG --log-prefix "INVALID_ONLY_FIN_NO_ACK: "
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -s $NET -j DROP

# only URG bit is set without ACK accompanying
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -m limit --limit 1/s -s $NET -j LOG --log-prefix "INVALID_ONLY_URG_NO_ACK: "
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -s $NET -j DROP

# all INVALID states should be dropped
iptables -A INPUT -m state --state INVALID -m limit --limit 1/m -j LOG --log-prefix "INVALID_STATE: "
iptables -A INPUT -m state --state INVALID -j DROP
2. Giới hạn cổng 80: Vậy giới hạn cổng 80 là giới hạn như thế nào? Ngoài những giới hạn chung về những malformed packets như trong ví dụ trên, các packets hoàn toàn hợp lệ khác cần được giới hạn như thế nào để chống đỡ với DDoS và brute force? - Syn: hầu như các dạng brute force và từ chối dịch vụ đều khởi đầu bằng gói SYN (ngoại trừ một số dạng reflection sử dụng ACK cực hiếm và không còn tồn tại vì các ISP đã cản lọc hết). Bởi vậy, điểm cần chú ý trước tiên là: SYN. Đối với iptables, SYN được biểu thị bằng --syn (hoặc --tcp-flags SYN,RST,ACK SYN nếu chọn theo option đầy đủ cho --tcp-flags) để match các gói SYN. Match rồi thì phải kiểm soát chúng và kiểm soát bằng "--limit" và "--limit-burst". Tính chất hai options này như thế nào thì tôi không đi sâu ở đây vì nó sẽ lê thê và trật trọng tâm. Cái chính là sẽ dùng "--limit" và "--limit-burst" như thế nào là thích hợp. Thật ra để trả lời câu hỏi dùng "--limit" và "--limit-burst" như thế nào là thích hợp rất khó bởi vì tuỳ trường độ, cường độ SYN. Có những dạng syn flood sử dụng hàng ngàn hoặc hàng trăm ngàn syn và mỗi IP gởi SYN đến cách nhau nhiều giây, thậm chí nhiều chục giây. Bởi vậy, cần phải sniff packets và phân tích để tìm ra tính chất mà điều chỉnh cho "--limit" và "--limit-burst" thích hợp. Ngoài ra, nếu sử dụng nhiều reverse proxies và DNS round-robin để bảo vệ trang web thì các cú SYN có thể đến mỗi reverse proxies theo tuần tự 1, 2, 3, 4..v..v.. và bởi thế thời gian cách khoảng của mỗi gói SYN chạm phải firewall sẽ cách xa ra nữa. Nói tóm lại, trong trường hợp này luật "đi vào" trên trở thành: iptables -A INPUT -s any/0 -p tcp --syn -m state --state NEW -m limit --limit $SYN_TIME_PACKET --limit-burst $SYN_RATE_PACKET --dport 80 -j ACCEPT iptables -A INPUT -p tcp ! --syn -s any/0 -m state --state ESTABLISHED -j ACCEPT trong đó, $SYN_TIME_PACKET chính là gía tri thích hợp cho --limit và $SYN_RATE_PACKET giá trị thích hợp cho --limit-burst. Tính ứng dụng và uyển chuyển cần được áp dụng tuỳ hoàn cảnh, tuỳ mức độ bị tấn công và tuỳ cấu trúc hệ thống có 1 hoặc nhiều máy chủ. - DDoS: DDoS đa dạng và phức tạp vì biến thái của chúng muôn trùng. Những biến thái mới của DDoS thường đẩy mạnh đến chỗ tạo ra các requests hoàn toàn hợp lệ để tránh sự cản trở. Bởi vậy, cách kiểm soát duy nhất có thể thực hiện được là: 1. Gia tăng băng thông. 2. Cản lọc theo số lần truy cập trong một khoảng thời gian nhất định. Việc gia tăng băng thông đòi hỏi gia thăng băng thông trên chính mỗi máy chủ hoặc hàng loạt các máy chủ / các reverse proxies dùng để cản lọc. Cốt lõi của việc ngăn chặn nẳm ở điểm thứ nhì, có nghĩa là phải thực hiện tìm ra A và B, C, D, E như đã đề cập ở bài trước. Tất nhiên, việc giới hạn "syn" như trên là cần thiết nhưng chuyện gì xảy ra nếu vẫn bị "đập" triền miên? Cách duy nhất là cản (null route) hoàn toàn các IP liên tục tấn công. Thử xem, nếu một người dùng bình thường thì trình duyệt của họ cần gởi bao nhiêu cú SYN trong một giây? và bao nhiêu cú SYN trong một khoảng thời gian nào đó? và liên tục gởi SYN trong bao lâu (1 giờ, 10 giờ)? Thử xem nhóm luật sau: Code:
# create a blacklist table to punish over limit requests
iptables -N blacklist
iptables -A blacklist -j LOG --log-prefix "BLACKLISTING: "
iptables -A blacklist -m recent --name BLACKLIST --update --name BLACKLIST --seconds 10 --hitcount 20 --rttl -j ACCEPT

# create synrate to control number of syn
iptables -N synrate
iptables -A synrate -p tcp ! --syn -s $NET -m multiport --dports 80,443 -m state --state NEW -j DROP
iptables -A synrate -p tcp --syn -s $NET -m multiport --dports 80,443 -m state --state NEW -m limit --limit $SYN_TIME_PACKET --limit-burst $SYN_RATE_PACKET -j RETURN
iptables -A synrate -p tcp --syn -s $NET -m multiport --dports 80,443 -m recent --name BLACKSYN --set -j blacklist

# create connrate to control number of connections from 1 IP
iptables -N connrate
iptables -A connrate -i $IF -p tcp ! --syn -s $NET -m state --state ESTABLISHED -m connlimit ! --connlimit-above $CONN_GLOBAL -j RETURN
iptables -A connrate -i $IF -p tcp -s $NET -m multiport --dports 80,443 -m state --state ESTABLISHED -m connlimit --connlimit-above $CONN_GLOBAL -m limit --limit 2/m -j LOG --log-prefix "OVERCONNLIMIT: "
iptables -A connrate -i $IF -p tcp -s $NET -m state --state ESTABLISHED -m connlimit --connlimit-above $CONN_GLOBAL -j DROP
echo "done connrate..."

# Once the synrate is satisfied accept it (from -j RETURN of the synrate rule above)
iptables -A INPUT -i $IF -p tcp --syn -s $NET -m multiport --dports 80,443 -j ACCEPT
echo "done accept syn.."

# Once the connrate is satisfied and ESTABLISHED (from the -j RETURN of connrate above)
iptables -A INPUT -i $IF -p tcp ! --syn -s $NET -m state --state ESTABLISHED -m connlimit ! --connlimit-above $CONN_GLOBAL -j ACCEPT
echo "done accept conn..."

# Once both rules above are accepted, allow OUTPUT
iptables -A OUTPUT -o $IF -p tcp -m multiport --sports 80,443 -d $NET -j ACCEPT
echo "done accept output.."

# If the IP has violated the limit
iptables -t mangle -I INPUT -i $IF -p tcp -m multiport --dports 80,443 -m recent --name BLACKLIST --update --seconds 10 --hitcount 10  -j DROP
echo "done filtering blacklist...."

echo "Start the actual http rule..."
iptables -A INPUT -p tcp --syn -s $NET -m multiport --dports 80,443 -j synrate
iptables -A INPUT -p tcp ! --syn -s $NET -m multiport --dports 80,443 -j connrate
Nhóm luật trên kết hợp 3 chức năng của 3 modules để kiểm soát 3 việc: a. Số lượng SYN (--limit) b. Số lượng SYN request bị quá giới hạn trong khoảng thời gian gần đây (-m recent) c. Số lượng connections đã được tạo ra từ 1 IP. Tôi không giải thích chi tiết mà để vậy để các bạn tự suy luận và tìm hiểu logic của nó.]]> /hvaonline/posts/list/43059.html#269014 /hvaonline/posts/list/43059.html#269014 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#269288 /hvaonline/posts/list/43059.html#269288 GMT HVA bảo mật như thế nào?

LlyKil wrote:
Các mod như recent hay limit mình chưa rõ nó có tác dụng như thế nào đối với kiểu syn flood kết hợp spoof IP. 1. Nếu limit rate thì đối với server thì số lượng packet dành cho mỗi giây đều bị cướp hết. Còn nếu limit rate đối với IP thì liệu nó có hữu hiệu trong khi lượng IP có thể giả mạo tại IPv4 là 4.294.967.296 (2^32) nên thời gian giữa các packet cách nhau rất xa. 2. Phương pháp block IP vĩnh viễn hoặc giới hạn thời gian request của IP dựa trên các mod như recent, ... có khả thi? Ví dụ: website của victim phục vụ cho người Việt Nam (VN) và chắc chắn gần như toàn bộ các IP truy cập sẽ là của VN. Mình syn flood và spoof (giả mạo) IP có range là của VN. Vậy khi block hay limit thì khác nào chặn toàn bộ khách hàng mặc dù server vẫn không bị down. Hai câu hỏi mình đưa ra dành cho trường hợp server sẽ xử lý như thế nào chứ không phải bão hoà. 
Cách tốt nhất là thử ứng dụng và điều chỉnh. Còn hỏi thế nào cũng chỉ là lý thuyết.]]> /hvaonline/posts/list/43059.html#269290 /hvaonline/posts/list/43059.html#269290 GMT HVA bảo mật như thế nào?

LlyKil wrote:
Các mod như recent hay limit mình chưa rõ nó có tác dụng như thế nào đối với kiểu syn flood kết hợp spoof IP. 1. Nếu limit rate thì đối với server thì số lượng packet dành cho mỗi giây đều bị cướp hết. Còn nếu limit rate đối với IP thì liệu nó có hữu hiệu trong khi lượng IP có thể giả mạo tại IPv4 là 4.294.967.296 (2^32) nên thời gian giữa các packet cách nhau rất xa. 2. Phương pháp block IP vĩnh viễn hoặc giới hạn thời gian request của IP dựa trên các mod như recent, ... có khả thi? Ví dụ: website của victim phục vụ cho người Việt Nam (VN) và chắc chắn gần như toàn bộ các IP truy cập sẽ là của VN. Mình syn flood và spoof (giả mạo) IP có range là của VN. Vậy khi block hay limit thì khác nào chặn toàn bộ khách hàng mặc dù server vẫn không bị down. Hai câu hỏi mình đưa ra dành cho trường hợp server sẽ xử lý như thế nào chứ không phải bão hoà. 
Thử táng cái đống bullshit đấy lên HVA xem sao ;)) ]]> /hvaonline/posts/list/43059.html#269553 /hvaonline/posts/list/43059.html#269553 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#269570 /hvaonline/posts/list/43059.html#269570 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#269965 /hvaonline/posts/list/43059.html#269965 GMT HVA bảo mật như thế nào? www.hvaonline.net 2 0.049523 8.8.8.8 192.168.1.100 DNS 125 Standard query response A 76.72.167.122 A 78.46.136.116 A 49.212.135.219 hvaonline.net 53 16.501072 8.8.8.8 192.168.1.100 DNS 105 Standard query response A 76.72.167.122 A 78.46.136.116   Trên đây là kết quả của việc phân giải tên miền www.hvaonline.net và hvaonline.net, chúng ta thấy có tới 3 IP khác nhau, sau khi tra cứ sơ bộ em có thông tin sau:
Host Name: 76.72.167.122 IP Address: 76.72.167.122 Country: United States united states Country code: US (USA) Region: Pennsylvania City: Philadelphia www7445uf.sakura.ne.jp IP Address: 49.212.135.219 Country: Japan japan Country code: JP (JPN) Region: Shimane City: Minami Host Name: hvaonline.net IP Address: 78.46.136.116 Country: Germany germany Country code: DE (DEU)  
3 Server nằm 3 nơi khác nhau em thử nghiệm việc duyệt HVA trên trình duyệt của em, tóm gói tin và xem xét.
GET / HTTP/1.1 Host: hvaonline.net Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 HTTP/1.1 301 Moved Permanently Date: Mon, 12 Nov 2012 08:44:29 GMT Server: Apache mod_jk/1.2.31 Location: / Cache-Control: max-age=300 Expires: Mon, 12 Nov 2012 08:49:29 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 242 Content-Type: text/html; charset=iso-8859-1 Keep-Alive: timeout=4, max=1000 Connection: Keep-Alive ..........mO=O.0...+....vA...M..Z...........c.......,'...utQ=m.kS.....y..m7._"nku.X..|Y...~.eF6v.$...%.c.r]...#.h8t......|...2.{s........z.,......`...B% 6..Mnc....i.v...G..q.\Z.L.. .....6&.0..^..s......b%.%<s.9.NA....!.U..~....{j9........6...  
Ta chú ý thấy đám bên dưới toàn giun dế, anh già khó tánh không muốn chúng ta đọc cái gì của ảnh hết. Chú ý header thấy: Content-Encoding: gzip Giờ ta lược bỏ cái khả năng hổ trợ gzip của ta đi xem ảnh có chiều không ?. Accept-Encoding: gzip,deflate,sdch Em lấy cái request:
GET / HTTP/1.1 Host: hvaonline.net Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3  
Tống vào file hva_pkt_step_1 Rồi thử : $ cat hva_pkt_step_1|netcat hvaonline.net 80
HTTP/1.1 301 Moved Permanently Date: Tue, 13 Nov 2012 02:20:23 GMT Server: Apache mod_jk/1.2.31 Location: / Cache-Control: max-age=300 Expires: Tue, 13 Nov 2012 02:25:23 GMT Vary: Accept-Encoding Content-Length: 310 Content-Type: text/html; charset=iso-8859-1 Keep-Alive: timeout=4, max=1000 Connection: Keep-Alive <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="/">here</a>.</p> <hr> <address>Apache mod_jk/1.2.31 Server at hvaonline.net Port 80</address> </body></html>  
Ít ra anh già cũng không khó tánh lắm, nếu mà ảnh ép dùng gzip thì phải vết 1 cái script nhỏ để decode cái gzip của ảnh. <a href="/">here</a> (-> Giúp googlebot tìm đường, đề phòng trường hợp wwwect bằng header thất bại). Giờ xem www.hvaonline.net nói gì. Tương tự các bước trên bỏ "Accept-Encoding: gzip,deflate,sdch" ta được.
GET / HTTP/1.1 Host: www.hvaonline.net Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 $cat hva_pkt_step_2|netcat www.hvaonline.net 80 HTTP/1.1 200 OK Date: Tue, 13 Nov 2012 02:27:10 GMT Server: Apache mod_jk/1.2.31 Last-Modified: Tue, 02 Aug 2011 04:28:57 GMT ETag: "226db8-18ec-4a97e2fa29440" Accept-Ranges: bytes Content-Length: 6380 Cache-Control: no-store, no-cache, must-revalidate Expires: Mon, 01 Dec 2003 16:00:00 GMT Vary: Accept-Encoding,User-Agent Pragma: no-cache Content-Type: text/html Set-Cookie: __utms=123.19.0.4.1352773630989630; path=/; max-age=900 Keep-Alive: timeout=4, max=500 Connection: Keep-Alive <script> <!-- document.write(unescape("%3CHTML%3E%0A%3CHEAD%3E%0A%3CTITLE%3E.%3A%3A%20H%20V%20A%20O%20n%20l%20i%20n%20e%20%3A%3A.%3C/TITLE%3E%0A%3Cmeta%20name%3D%22robots%22%20content%3D%22index%2Cfollow%22%3E%0A%3Cmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text/html%3B%20charset%3Dutf-8%22%3E%0A%3Cscript%20type%3D%22text/javascript%22%3E%0AaddEvent%28%20window%2C%20%27load%27%2C%20setLinkBehaviours%20%29%3B%0AaddEvent%28%20window%2C%20%27load%27%2C%20relNoFollow%20%29%3B%0A%0A/*%20thanks%20to%20PPK%20www.quirksmode.org%20*/%0Afunction%20addEvent%28%20obj%2C%20type%2C%20fn%20%29%20%0A%7B%0A%09if%20%28obj.addEventListener%29%0A%09%7B%0A%09%09obj.addEventListener%28%20type%2C%20fn%2C%20false%20%29%3B%0A%09%7D%0A%09else%20if%20%28%20obj.attachEvent%20%29%20%0A%09%7B%0A%09%09obj%5B%22e%22+type+fn%5D%20%3D%20fn%3B%0A%09%09obj%5Btype+fn%5D%20%3D%20function%28%29%20%0A%09%09%7B%20%0A%09%09%09obj%5B%22e%22+type+fn%5D%28%20window.event%20%29%3B%20%0A%09%09%7D%0A%09%09obj.attachEvent%28%20%22on%22+type%2C%20obj%5Btype+fn%5D%20%29%3B%0A%09%7D%20%0A%7D%0A%0Afunction%20removeEvent%28%20obj%2C%20type%2C%20fn%20%29%20%0A%7B%0A%09if%20%28%20obj.detachEvent%20%29%20%0A%09%7B%0A%09%09obj.detachEvent%28%20%22on%22+type%2C%20obj%5Btype+fn%5D%20%29%3B%0A%09%09obj%5Btype+fn%5D%20%3D%20null%3B%0A%09%7D%20%0A%09else%20if%20%28obj.removeEventListener%29%0A%09%7B%0A%09%09obj.removeEventListener%28%20type%2C%20fn%2C%20false%20%29%3B%0A%09%7D%0A%7D%0A%0Afunction%20setLinkBehaviours%28%29%20%7B%0A%09var%20Links%20%3D%20document.getElementsByTagName%28%20%27A%27%20%29%3B%0A%09%0A%09for%28%20var%20i%20%3D%200%3B%20i%20%3C%20Links.length%3B%20i++%20%29%20%7B%0A%09%09if%20%28Links%5Bi%5D.className.indexOf%28%27external%27%29%20%21%3D%3D%20-1%29%20%7B%0A%09%09%09Links%5Bi%5D.onclick%20%3D%20function%28%29%20%7B%0A%09%09%09%09var%20FakeLinkWindow%20%3D%20window.open%28%20this.href%2C%20%27target%27%2C%20%27%27%20%29%3B%0A%09%09%09%09return%20false%3B%0A%09%09%09%7D%0A%09%09%7D%0A%09%09%0A%09%09if%20%28Links%5Bi%5D.className.indexOf%28%27download%27%29%20%21%3D%3D%20-1%29%20%7B%0A%09%09%09Links%5Bi%5D.onclick%20%3D%20function%28%29%20%7B%0A%09%09%09%09doUrchin%28this.href%2C%20%27downloads%27%29%3B%0A%09%09%09%7D%0A%09%09%7D%0A%09%7D%0A%7D%0A%0Afunction%20relNoFollow%28%29%0A%7B%0A%09var%20FakeLinks%20%3D%20document.getElementsByTagName%28%27span%27%29%3B%0A%09%0A%09if%28%20FakeLinks.length%20%3E%200%20%29%0A%09%7B%0A%09%09for%28%20var%20i%20%3D%200%3B%20i%20%3C%20FakeLinks.length%3B%20i++%20%29%0A%09%09%7B%0A%09%09%09if%28%20FakeLinks%5Bi%5D.title.indexOf%28%20%27/to%27%20%29%20%21%3D%20-1%20%0A%09%09%09%09%7C%7C%20FakeLinks%5Bi%5D.title.indexOf%28%20%27/to%27%20%29%20%21%3D%20-1%20%29%0A%09%09%09%7B%0A%09%09%09%09FakeLinks%5Bi%5D.className%09%09%3D%20%27fakelink%27%3B%0A%09%09%09%09FakeLinks%5Bi%5D.onmouseout%20%09%3D%20fakelinkMouseOut%3B%0A%09%09%09%09FakeLinks%5Bi%5D.onmouseover%20%09%3D%20fakelinkMouseOver%3B%0A%09%09%09%09FakeLinks%5Bi%5D.onclick%20%09%09%3D%20fakelinkClick%3B%0A%09%09%09%7D%0A%09%09%7D%0A%09%7D%0A%7D%0A%0Afunction%20fakelinkMouseOver%28%29%0A%7B%0A%09this.className%20%3D%20%27fakelink-hover%27%3B%0A%7D%0A%0Afunction%20fakelinkMouseOut%28%29%0A%7B%0A%09this.className%20%3D%20%27fakelink%27%3B%0A%7D%0A%0A%0Afunction%20fakelinkClick%28%29%0A%7B%0A%20%20%20%20%20%20%20%20var%20FakeLinkWindow%20%3D%20window.open%28%20this.title%2C%20%27outbound%27%2C%20%27%27%20%29%3B%0A%7D%0A%3C/script%3E%0A%3Cstyle%20type%3D%22text/css%22%3E%0A%3C%21--%0ABODY%20%7B%0A%09%09background-color%3A%20%23111111%3B%0A%20%20%20%20%20%20%20%20font-family%20%3A%20Verdana%2C%20Geneva%2C%20Arial%2C%20Helvetica%3B%0A%20%20%20%20%20%20%20%20font-size%20%3A%20small%3B%0A%20%20%20%20%20%20%20%20font-weight%20%3A%20bold%3B%0A%20%20%20%20%20%20%20%20text-align%20%3A%20center%3B%0A%09%09color%3A%20White%3B%0A%09%09font-size%3A%2012px%3B%0A%7D%0A%0AA%20%7B%0A%20%20%20%20%20%20%20%20color%20%3A%20White%3B%0A%20%20%20%20%20%20%20%20text-decoration%20%3A%20none%3B%0A%09%09font-size%3A%2012px%3B%0A%7D%0A%0AA%3AHOVER%20%7B%0A%20%20%20%20%20%20%20%20color%20%3A%20FFCC33%3B%0A%20%20%20%20%20%20%20%20text-decoration%20%3A%20none%3B%0A%09%09font-size%3A%2012px%3B%0A%7D%0A%0AA.Link%20%7B%0A%09color%3A%20FFCC33%3B%0A%09text-decoration%3A%20none%3B%0A%09font-size%3A%2012px%3B%0A%0A%7D%0A.style1%20%7Bfont-size%3A%2010px%7D%0A%0A.fakelink%0A%7B%0A%09color%3A%20white%3B%0A%09font-size%3A%2012px%3B%0A%09text-decoration%3A%20none%3B%0A%09cursor%3A%20pointer%3B%0A%7D%0A%0A.fakelink-hover%0A%7B%0A%09color%3A%20%23FFCC33%3B%0A%09font-size%3A%2012px%3B%0A%09text-decoration%3A%20underline%3B%0A%09cursor%3A%20pointer%3B%0A%7D%0A%3C/style%3E%3C/HEAD%3E%0A%3Cbody%3E%0A%3Ctable%20width%3D%22100%25%22%20cellspacing%3D%220%22%20cellpadding%3D%222%22%20border%3D%220%22%20align%3D%22center%22%3E%0A%09%3Ctr%3E%0A%09%09%3Ctd%3E%26nbsp%3B%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%20%20%3Ctd%20width%3D%2250%25%22%20align%3D%22center%22%20valign%3D%22middle%22%3E%3Cimg%20src%3D%22squarehva.gif%22%20alt%3D%22squarelogo%22%20longdesc%3D%22http%3A//www.hvaonline.net/squarehva.gif%22%3E%3C/td%3E%0A%09%3C/tr%3E%0A%20%20%3Ctr%3E%0A%20%20%20%20%3Ctd%20width%3D%2250%25%22%20align%3D%22center%22%20valign%3D%22middle%22%3E%0A%20%20%20%20%20%20%3Cp%20class%3D%22copyright%22%3E%26nbsp%3B%3C/p%3E%0A%09%3Cspan%20title%3D%22/toforum%22%20class%3D%22fakelink%22%3EForum%3C/span%3E%20%7C%20%0A%09%3Cspan%20title%3D%22/toportal%22%20class%3D%22fakelink%22%3EPortal%3C/span%3E%0A%20%20%20%20%20%20%3Cp%20align%3D%22center%22%3E%3Cimg%20src%3D%22vertical.gif%22%20alt%3D%22vert%22%20width%3D%221%22%20height%3D%22300%22%3E%3C/p%3E%0A%20%20%20%20%3C/td%3E%0A%20%20%3C/tr%3E%0A%3C/table%3E%0A%3Ctable%20width%3D%22100%25%22%20cellspacing%3D%220%22%20cellpadding%3D%222%22%20border%3D%220%22%20align%3D%22center%22%3E%0A%09%3Ctr%3E%0A%09%20%20%3Ctd%20width%3D%2250%25%22%20align%3D%22center%22%20valign%3D%22middle%22%3E%3Cspan%20class%3D%22style1%22%3Eh%20v%20a%20o%20n%20l%20i%20n%20e%20.%20n%20e%20t%20%26nbsp%3B%7C%26nbsp%3B%20h%20v%20a%20f%20o%20r%20u%20m%20.%20n%20e%20t%20%26nbsp%3B%7C%26nbsp%3B%20h%20v%20a%20z%20o%20n%20e%20.%20n%20e%20t%20%26nbsp%3B%7C%26nbsp%3B%20v%20n%20h%20a%20c%20k%20e%20r%20.%20o%20r%20g%3C/span%3E%3Cspan%3E%3Ca%20href%3D%22/%22%3E%3C/a%3E%3C/span%3E%20%3C/td%3E%0A%09%3C/tr%3E%0A%3C/table%3E%0A%3C/body%3E%0A%3C/HTML%3E")); //--> </script>  
Chậc Urlencode, chúng ta không được chào đón lắm. Việc này của ảnh ngụ ý là kiểm tra xem cái chúng ta có dùng trình duyệt vào hay không dựa trên những khả năng của trình duyệt như: - Ghi nhớ cookie - Xử lý javascript Bước này chặn mấy anh không phải là browser, có nghĩa là bước bước đó anh già sẽ thả rông googlebot. Nhớ lại vụ Sờ-Ti-Lợ-Entertainment tấn công và giả danh google bot. Sau vụ đó anh già đã thực hiện siết chặt khâu này, là kiểm tra IP của BOT. Ở bước này ta được đánh dấu
Set-Cookie: __utms=123.19.0.4.1352773630989630; path=/; max-age=900  
123.19.0.4.13 -> IP của em, phần đằng sau có lẽ 1 ID được cấp ngẩu nhiên. Thời gian tồn tài của cái này là 15 phút. Tức sau khi bồ nhận cái này bồ có 15 phút để vào cửa trước khi nó hết hạn (suy đoán của em). Giờ ta tập trung vào cái đoạn bị che đi:
<HTML> <HEAD> <TITLE>.:: H V A O n l i n e ::.</TITLE> <meta name="robots" content="index,follow"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <script type="text/javascript"> addEvent( window, 'load', setLinkBehaviours ); addEvent( window, 'load', relNoFollow ); /* thanks to PPK www.quirksmode.org */ function addEvent( obj, type, fn ) { if (obj.addEventListener) { obj.addEventListener( type, fn, false ); } else if ( obj.attachEvent ) { obj["e" type fn] = fn; obj[type fn] = function() { obj["e" type fn]( window.event ); } obj.attachEvent( "on" type, obj[type fn] ); } } function removeEvent( obj, type, fn ) { if ( obj.detachEvent ) { obj.detachEvent( "on" type, obj[type fn] ); obj[type fn] = null; } else if (obj.removeEventListener) { obj.removeEventListener( type, fn, false ); } } function setLinkBehaviours() { var Links = document.getElementsByTagName( 'A' ); for( var i = 0; i < Links.length; i ) { if (Links[i].className.indexOf('external') !== -1) { Links[i].onclick = function() { var FakeLinkWindow = window.open( this.href, 'target', '' ); return false; } } if (Links[i].className.indexOf('download') !== -1) { Links[i].onclick = function() { doUrchin(this.href, 'downloads'); } } } } function relNoFollow() { var FakeLinks = document.getElementsByTagName('span'); if( FakeLinks.length > 0 ) { for( var i = 0; i < FakeLinks.length; i ) { if( FakeLinks[i].title.indexOf( '/to' ) != -1 || FakeLinks[i].title.indexOf( '/to' ) != -1 ) { FakeLinks[i].className = 'fakelink'; FakeLinks[i].onmouseout = fakelinkMouseOut; FakeLinks[i].onmouseover = fakelinkMouseOver; FakeLinks[i].onclick = fakelinkClick; } } } } function fakelinkMouseOver() { this.className = 'fakelink-hover'; } function fakelinkMouseOut() { this.className = 'fakelink'; } function fakelinkClick() { var FakeLinkWindow = window.open( this.title, 'outbound', '' ); } </script> <style type="text/css"> <!-- BODY { background-color: #111111; font-family : Verdana, Geneva, Arial, Helvetica; font-size : small; font-weight : bold; text-align : center; color: White; font-size: 12px; } A { color : White; text-decoration : none; font-size: 12px; } A:HOVER { color : FFCC33; text-decoration : none; font-size: 12px; } A.Link { color: FFCC33; text-decoration: none; font-size: 12px; } .style1 {font-size: 10px} .fakelink { color: white; font-size: 12px; text-decoration: none; cursor: pointer; } .fakelink-hover { color: #FFCC33; font-size: 12px; text-decoration: underline; cursor: pointer; } </style></HEAD> <body> <table width="100%" cellspacing="0" cellpadding="2" border="0" align="center"> <tr> <td> </td> </tr> <tr> <td width="50%" align="center" valign="middle"><img src="squarehva.gif" alt="squarelogo" longdesc="/squarehva.gif"></td> </tr> <tr> <td width="50%" align="center" valign="middle"> <p class="copyright"> </p> <span title="/toforum" class="fakelink">Forum</span> | <span title="/toportal" class="fakelink">Portal</span> <p align="center"><img src="vertical.gif" alt="vert" width="1" height="300"></p> </td> </tr> </table> <table width="100%" cellspacing="0" cellpadding="2" border="0" align="center"> <tr> <td width="50%" align="center" valign="middle"><span class="style1">h v a o n l i n e . n e t  |  h v a f o r u m . n e t  |  h v a z o n e . n e t  |  v n h a c k e r . o r g</span><span><a href="/"></a></span> </td> </tr> </table> </body> </HTML>  
Đây là cái trang gác cửa quen thuộc. <span title="/toforum" class="fakelink">Forum</span> | <span title="/toportal" class="fakelink">Portal</span> Thứ ta tưởng là <a href="/toforum">Forum</a> là <span title="/toforum" class="fakelink">Forum</span> Đây không phải là HTML a tag vì sao thế ?. Anh muốn đuổi tụi BOTs đi, nhớ mấy câu ảnh nói chắc là anh đuổi mấy con nhặng của bọn khựa. Đoạn mã JS này đại khải làm nhiệm vụ là làm một cái fakelink, anh biết là tụi BOTs sẽ bám theo cái "href" cơ. Tôi đợi một lát cho ổng quên tui rồi quay lại, gửi hva_pkt_step_2 tới rồi lấy cookie thế vào hva_pkt_step_3,hva_pkt_step_4 tôi được. hva_pkt_step_3
GET /toforum HTTP/1.1 Host: www.hvaonline.net User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Connection: keep-alive Referer: / Cookie: __utms=123.19.0.4.1352775433230315 cat hva_pkt_step_3|ncat www.hvaonline.net 80 HTTP/1.1 302 Found Date: Tue, 13 Nov 2012 02:57:40 GMT Server: Apache mod_jk/1.2.31 Location: /tof/ Cache-Control: max-age=300 Expires: Tue, 13 Nov 2012 03:02:40 GMT Vary: Accept-Encoding Content-Length: 270 Content-Type: text/html; charset=iso-8859-1 Keep-Alive: timeout=4, max=500 Connection: Keep-Alive <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="/tof/">here</a>.</p> <hr> <address>Apache mod_jk/1.2.31 Server at www.hvaonline.net Port 80</address> </body></html>  
Cái này ai tinh mắt sẽ thấy bị sút về đây khoảng 1/2s, giờ ta thấy ảnh lại tiếp tục dẫn đường cho người và BOTs như bước đầu. hva_pkt_step_4
GET /tof/ HTTP/1.1 Host: www.hvaonline.net User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Connection: keep-alive Referer: / Cookie: __utms=123.19.0.4.1352775433230315 cat hva_pkt_step_4|ncat www.hvaonline.net 80 HTTP/1.1 200 OK Date: Tue, 13 Nov 2012 02:58:19 GMT Server: Apache mod_jk/1.2.31 Last-Modified: Sun, 31 Jul 2011 23:18:57 GMT ETag: "4126e3-696-4a965bd25ba40" Accept-Ranges: bytes Content-Length: 1686 Cache-Control: max-age=300 Expires: Tue, 13 Nov 2012 03:03:19 GMT Vary: Accept-Encoding,User-Agent Content-Type: text/html Set-Cookie: __utmz=123.19.0.4.1352775499633686; path=/; max-age=900 Keep-Alive: timeout=4, max=1000 Connection: Keep-Alive <script> <!-- document.write(unescape("%3Chtml%3E%20%0A%3Chead%3E%20%0A%3Cscript%20type%3D%22text/javascript%22%3E%20%0A%09function%20wwwectUser%28%29%7B%20window.location%20%3D%20%22/hvaonline/forums/list.html%22%3B%20%7D%20%0A%3C/script%3E%20%0A%3Cstyle%20type%3D%22text/css%22%3E%0A%3C%21--%0ABODY%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20background-color%3A%20%23111111%3B%0A%20%20%20%20%20%20%20%20font-family%20%3A%20Verdana%2C%20Geneva%2C%20Arial%2C%20Helvetica%3B%0A%20%20%20%20%20%20%20%20font-size%20%3A%20small%3B%0A%20%20%20%20%20%20%20%20font-weight%20%3A%20bold%3B%0A%20%20%20%20%20%20%20%20text-align%20%3A%20center%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20color%3A%20White%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20font-size%3A%2012px%3B%0A%7D%0A%0AA%20%7B%0A%20%20%20%20%20%20%20%20color%20%3A%20White%3B%0A%20%20%20%20%20%20%20%20text-decoration%20%3A%20none%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20font-size%3A%2012px%3B%0A%7D%0A%0AA%3AHOVER%20%7B%0A%20%20%20%20%20%20%20%20color%20%3A%20FFCC33%3B%0A%20%20%20%20%20%20%20%20text-decoration%20%3A%20none%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20font-size%3A%2012px%3B%0A%7D%0A%0AA.Link%20%7B%0A%20%20%20%20%20%20%20%20color%3A%20FFCC33%3B%0A%20%20%20%20%20%20%20%20text-decoration%3A%20none%3B%0A%20%20%20%20%20%20%20%20font-size%3A%2012px%3B%0A%0A%7D%0A.style1%20%7Bfont-size%3A%2010px%7D%0A%3C/style%3E%0A%3C/head%3E%20%0A%3Cbody%20color%3D%22%23111111%22%20onload%3D%22setTimeout%28%27wwwectUser%28%29%27%2C%201000%29%22%3E%20%0A%3Cbr%3E%0A%3Ch1%20class%3D%22style1%22%3EGoing%20to....%3C/h1%3E%20%0A%3C/body%3E%20%0A%3C/html%3E")); //--> </script>  
Chặng tiếp theo sắp bước vào cửa nhà nên bị đánh dấu thêm một lần nữa, vẫn 15 phút. Set-Cookie: __utmz=123.19.0.4.1352775499633686; path=/; max-age=900 Lúc nãy __utms giờ là __utmz không biết cái đuôi sau có liên quan tới timestamp không nhỉ ?. Để đó đã giờ gở cái urlencode ra.
<html> <head> <script type="text/javascript"> function wwwectUser(){ window.location = "/hvaonline/forums/list.html"; } </script> <style type="text/css"> <!-- BODY { background-color: #111111; font-family : Verdana, Geneva, Arial, Helvetica; font-size : small; font-weight : bold; text-align : center; color: White; font-size: 12px; } A { color : White; text-decoration : none; font-size: 12px; } A:HOVER { color : FFCC33; text-decoration : none; font-size: 12px; } A.Link { color: FFCC33; text-decoration: none; font-size: 12px; } .style1 {font-size: 10px} </style> </head> <body color="#111111" onload="setTimeout('wwwectUser()', 1000)"> <br> <h1 class="style1">Going to....</h1> </body> </html>  
Ổng cho ta vài giây để bước vào hoặc đi luôn, rất có thể ổng sẽ check độ trể ở đây, chẳng hạn bạn kết nối trực tiếp bạn mất 5 giây để bước vào, nhưng khi bạn đi qua proxies thì bạn mất nhiều hơn 5 giây. Vấn đề đặt ra bạn phải bước vào sau 1 giây và trước 5 (<- cái này em đoán). Em thử lấy 2 cái cookie kia nhét vào packet thứ 5
GET /hvaonline/forums/list.html HTTP/1.1 Host: www.hvaonline.net User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Connection: keep-alive Referer: /tof/ Cookie: __utms=123.19.0.4.1352775433230315; __utmz=123.19.0.4.1352775499633686  
Mặc dù tôi mất hơn 3 phút để làm việc đó nhưng ổng vẫn cho tôi vào. HVA đang trong tình trạng thời bình chăng ?.Tới đây chúng ta chính thức đặt chân vào home rồi.
<iframe src="/hvaonline/templates/ping_session.html" height="0" width="0" frameborder="0" scrolling="no"></iframe>  
Đây là liêu thuốc ổng cho mình uống
<html> <head> <meta http-equiv="refresh" content="300"> </head> pong <body> </body> </html>  
5 phút một lần, lúc hỏi thì anh già tiết lộ là để xem "còn sống" không. Chúng ta chuyển hướng qua chổ khác www.hvaonline.net (74.63.219.14 khác 3 IP ở trên).Đây là nơi chứa dữ liệu tĩnh. Thử vào bằng trình duyệt thì thấy.
<html> <head> <title>Hello - Goodbye</title> </head> <body bgcolor="white" text="black"> <center><h1></h1></center> </body> </html>  
Giống thông báo đầu khi chơi Counter Strike (Hello & Goobye =.=). Nếu tiếp tục bắt gói tin của các phiên làm việc tôi lại thấy lạ vì đôi lúc kết nối được tạo rồi lại đóng ngay sau đó. Nó không bị đóng bằng cách RST mà, được đóng rất lịch sự bằng FIN. Ngồi tìm tòi thêm thôi thấy điều sau khi gửi cùng tcp packet tới các IP khác nhau.
76.72.167.122 76.72.167.122 Linux (2.6.X) Last-Modified: Tue, 02 Aug 2011 04:28:57 GMT 49.212.135.219 www7445uf.sakura.ne.jp Cisco embedded Last-Modified: Tue, 02 Aug 2011 04:28:57 GMT 78.46.136.116 hvaonline.net WatchGuard embedded Last-Modified: Tue, 02 Aug 2011 04:28:57 GMT  
Ta thấy Last-Modified trùng khớp, 3 server này chỉ là bao cát để chịu trận thôi, vẫn còn một hoặc nhiều hơn một server đứng đằng sau. Mọi cố gắng đi vào sâu hơn đều vô vọng, hay ít nhất với em là vô vọng. Tới đây em tạm kết luận như sau: - Khảo sát các tầng cần được bảo mật, mỗi tầng đưa ra một biện pháp riêng. - Đảm bảo người dùng và BOT hợp lệ tiếp cận được thông tin, phân loại đối tượng truy cập dựa trên đặc điểm. - Hạn chế các điểm tiếp xúc không cần thiết với internet.]]> /hvaonline/posts/list/43059.html#270939 /hvaonline/posts/list/43059.html#270939 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#270962 /hvaonline/posts/list/43059.html#270962 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#270977 /hvaonline/posts/list/43059.html#270977 GMT HVA bảo mật như thế nào? Host Name: 76.72.167.122 IP Address: 76.72.167.122 Country: United States united states Country code: US (USA) Region: Pennsylvania City: Philadelphia www7445uf.sakura.ne.jp IP Address: 49.212.135.219 Country: Japan japan Country code: JP (JPN) Region: Shimane City: Minami Host Name: hvaonline.net IP Address: 78.46.136.116 Country: Germany germany Country code: DE (DEU) Host Name: ns2.tienve.org IP Address: 74.63.219.14 Country: United States united states Country code: US (USA) Region: Texas City: Dallas   Sau khi post một message trên facebook mục đích là cầu cứu tứ phương, "bác sĩ" sau khi "châm cứu" đã trả bệnh nhân về. Em quyết định lần theo các đầu mối mà trước đây không dùng tới. Whois một cái em có :
Name Server 1: ns2.hvaonline.net ( 74.63.219.13 an alias of ns1.tienve.org ?) Host Name: ns1.tienve.org IP Address: 74.63.219.13 Country: United States united states Country code: US (USA) Region: Texas City: Dallas Name Server 2: ns2.afraid.org Host Name: ns2.afraid.org IP Address: 174.37.196.55 Country: United States united states Country code: US (USA) Region: Virginia City: Ashburn  
Em không biết afraid.org là gì hết em bật trình duyệt và gỏ vào http://afraid.org. Ngay banner em đã thấy thứ mình cần tìm #define afraid.org FreeDNS - Free DNS - Dynamic DNS - Static DNS subdomain and domain hosting Thay vì xây dựng thêm 1 name server là ns1.hvaonline.net ảnh lại dùng một dịch vụ name server mà ảnh tin tưởng. Với gợi ý lần trước ảnh nói, tôi nghĩ đây là một bước phòng hờ cho việc ns2.hvaonline.net gặp trục trặc.
@Chiro: Trong binh pháp tôn tử nói. Việc dụng binh cốt ở xảo trá mà :D @Conmale: he he, anh thì không chơi rơ xảo trá mà anh tính toán rất kỹ  
Nhưng vậy điều này cũng một phần khẳng định cái anh gọi là tính toán kỹ đó, ảnh chuận bị cho trường hợp xấu là ns2.hvaonline.net không còn khả năng phân giản domain, và thậm chí là một server nào đó với tài nguyên hạn chế có thể đảm nhiệm nó. Lần trước em cũng thử sữ dụng nmap scan các open port trên 4 server nhưng kết quả không khả quan lắm. Em cài nmap, bập bẹ đọc usage rồi thử:
# nmap 76.72.167.122 -P0 -sS Not shown: 1677 filtered ports PORT STATE SERVICE 25/tcp open smtp 80/tcp open http 443/tcp open https # nmap 49.212.135.219 -P0 -sS Not shown: 1675 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind 443/tcp open https 3306/tcp open mysql # nmap 78.46.136.116 -P0 -sS Not shown: 1677 filtered ports PORT STATE SERVICE 80/tcp open http 443/tcp open https 8443/tcp open https-alt # nmap 74.63.219.14 -P0 -sS PORT STATE SERVICE 80/tcp open http 443/tcp open https  
Em thử telnet tới: $telnet 49.212.135.219 3306 Host '123.19.31.10' is not allowed to connect to this MySQL serverConnection closed by foreign host. Không dễ ăn chút nào, ảnh sẽ luôn đảm bảo chúng ta thấy thứ mà ảnh muốn chúng ta thấy. Telnet tới một số cổng khác cho dù cổng mở nhưng vẫn không có cơ may nào qua mặt được việc xác thực. Đành để đó tìm xem server chính ở đâu. Giờ thực hiện lookup. Em sử dụng 1 tool mà em tình cờ tìm thấy:
http://network-tools.com/nslook/Default.asp?domain=hvaonline.net&type=255&server=74.63.219.14&class=1&port=53&timeout=5000&go.x=0&go.y=0 hvaonline.net IN SOA server: ns2.hvaonline.net email: hostmaster@hvaonline.net serial: 1347014467 refresh: 16384 retry: 2048 expire: 1048576 minimum ttl: 2560 2560s (42m 40s) hvaonline.net IN NS ns2.hvaonline.net 3600s (1h) hvaonline.net IN NS ns2.afraid.org 3600s (1h) hvaonline.net IN MX preference: 0 exchange: mail.hvaonline.net 86400s (1d) hvaonline.net IN TXT v=spf1 a mx ptr -all 3600s (1h) hvaonline.net IN TXT google-site-verification=9MhFqvu3wTPAlHcVhHaQclmWB7LagxEj4CtZeYXX25A 86400s (1d) hvaonline.net IN A 78.46.136.116 86400s (1d) hvaonline.net IN A 76.72.167.122 86400s (1d) Authority records [none] Additional records name class type data time to live ns2.hvaonline.net IN A 74.63.219.13 86400s (1d) ns2.afraid.org IN A 174.37.196.55 86400s (1d) mail.hvaonline.net IN A 74.63.219.12 86400s (1d)  
Thêm một địa chỉ IP mới là 74.63.219.12.
#nmap 74.63.219.13 -P0 -sS Not shown: 1676 filtered ports PORT STATE SERVICE 25/tcp open smtp 53/tcp open domain 80/tcp open http 443/tcp closed https # nmap 74.63.219.12 -P0 -sS PORT STATE SERVICE 443/tcp open https  
Ta có các server mới là
Host Name: ns1.tienve.org IP Address: 74.63.219.13 Country: United States united states Country code: US (USA) Region: Texas City: Dallas Host Name: hvaonline.net IP Address: 74.63.219.12 Country: United States united states Country code: US (USA) Region: Texas City: Dallas  
Mục đích của chuyến này là tìm ra server nào là server (thật). Em mở hộp thư kiếm lại cái mail kích hoạt tài khoản.
Received: from tienve.org (thutin.tienve.org [74.63.219.12])  
Cái dòng em cần đây tìm là đây, mail.hvaonline.net và thutin.tienve.org đều trỏ tới 74.63.219.12. Xem e-mail tìm thời gian gửi Mon, 23 Aug 2010 20:38:13 -0700 (PDT). Đích thị là anh 74.63.219.12 rồi, kèm thêm port 443 open, các cổng còn lại bị filter thì em khẳng định 60% là thế. Em định dùng OpenSSL thử gửi một request tới 74.63.219.12:443 nhưng rốt cuộc em chưa biết cách sử dụng nó thế nào. Vậy đành tìm cách khác, em mở /etc/hosts thêm vào 2 dòng.
74.63.219.12 hvaonline.net 74.63.219.12 www.hvaonline.net  
Em vào từ trình duyệt https://hvaonline.net, gặp ông gác cổng thấy cũng mừng mừng. Nhưng rồi thấy có thông báo bị chặn (403). Em tính vào đó gửi 1 POST request và xem phản hồi bao nhiêu, sau đó sẽ gửi POST request với "3 ông chịu đấm" kia. Sau khi tính toán nếu thời gian hoàn tất 1 POST request tới server (thật) hẳn sẽ nhỏ nhất. Nghĩ là thế nhưng rốt cuộc không thực hiện được. Hôm nay em thấy những điều sau: - Dữ liệu truyền trên internet (thông qua các tunnel) cần được mã hóa, phân quyền rõ ràng. - Mọi thông tin, trò chuyện của sysadmin, đều có thể "giúp" attacker trong việc can thiệp vào hệ thống. - Đảm bảo an toàn về mặt vật lý của server. - Lập các hệ thống phòng hờ, chịu tải, kịch bản xử lý sự cố. P/S: Trong bài trên có mấy gợi ý của anh conmale, và nhớ lại những sự kiện đã xảy ra với HVA.]]> /hvaonline/posts/list/43059.html#270992 /hvaonline/posts/list/43059.html#270992 GMT HVA bảo mật như thế nào? <span title="/toforum" class="fakelink">Forum</span> | <span title="/toportal" class="fakelink">Portal</span> nhưng lại không có href và được javascript function lo liệu (và sẽ hoạt động bình thường nếu sử dụng với trình duyệt bình thường. Với các loại bots chỉ đơn giản crawl và không có khả năng decode urlencoded text và không có khả năng thực thi javascript blocks thì bó tay). Có một chi tiết rất nhỏ nhưng rất lý thú ngay trên "ông gác cửa" nhưng chiro8x không để ý. Thử tìm xem? ;). PS: đã nói là "mọi sự tồn tại vì một lý do nào đó" mà :-) ]]> /hvaonline/posts/list/43059.html#270998 /hvaonline/posts/list/43059.html#270998 GMT HVA bảo mật như thế nào? <span title="/toforum" class="fakelink">Forum</span> | <span title="/toportal" class="fakelink">Portal</span> mà xuống dưới lại chường cái này ra: <td width="50%" align="center" valign="middle"><span class="style1">h v a o n l i n e . n e t | h v a f o r u m . n e t | h v a z o n e . n e t | v n h a c k e r . o r g</span><span><a href="/"></a></span> </td> :P ]]> /hvaonline/posts/list/43059.html#271055 /hvaonline/posts/list/43059.html#271055 GMT HVA bảo mật như thế nào? Code:
<meta name="robots" content="index,follow">
Cái này mục đích là báo với BOTs trang này cho phép BOTs truy cập và BOTs hãy "follow the white rabbit" (href). Code:
<a href="/"></a>
Khi BOTs theo href đi theo cái này thì nó sẽ sinh ra request: Code:
GET / HTTP/1.1
Host: www.hvaonline.net
Nhờ nhận thêm gợi ý của anh conmale em đánh liều, bấm F5 vài cái xem phản ứng ông gác cổng thế nào.

gaurdian wrote:
Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading from remote server Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request.  
Ông gác cổng đã chặn request GET /. Em ngồi chờ khoảng 5 phút gì đó mới vào lại được. Nhưng đổi trình duyệt thì vào bình thường. Vậy nó sẽ liên quan tới việc ghi nhớ User-agent hoặc Cookie của phiên làm việc đó. Mục đích của em nhỏ <a href="/"></a> là tạo ra một vòng lặp khiến BOTs gửi request tới ông gác cổng. Nhằm phân tích hành vi bất thường và có tính tần số, nhằm loại các request này ngay tại vị trí các ông gác cổng. Em học thêm được một điều: - Cần chặn và loại bỏ sớm các request không hợp lệ ở mỗi tầng, đồng thời phải tính toán kỹ lưỡng để không chặn các request của user. P/S: Chính xác hơn sau 5 lần sẽ bị chặn, nhưng đổi User-agent thì vào lại bình thường.]]> /hvaonline/posts/list/43059.html#271068 /hvaonline/posts/list/43059.html#271068 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#271102 /hvaonline/posts/list/43059.html#271102 GMT HVA bảo mật như thế nào? Cái này mục đích là báo với BOTs trang này cho phép BOTs truy cập và BOTs hãy "follow the white rabbit" (href).   Chính xác. Vì bots dùng để tấn công khai thác khả năng "crawl" qua việc nhận diện "href" cho nên ngoài chuyện "ẩn" href thật đi vào trong forum và portal, anh cố tình để ngỏ một "href" để "dụ" bots mò theo đó. Thứ nhất, nếu "crawl" theo href đó thì chỉ quay ngược lại chỗ của "ông gác cổng". Thứ nhì, nếu cứ gõ cửa "ông gác cổng" nhiều quá thì bị... "khoá cổng". Đây là một dạng trap. Còn chuyện em bị error 502 là do từ lúc em gởi request đến HVA đến lúc proxy chuyển request về hệ thống máy chủ chính quá lâu nên bị 502 (vì proxy đứng trước chờ phản hồi từ hệ thống máy chủ chính quá lâu mà không thấy trả lời) chớ đây không phải là ấn định cụ thể để cản lọc. :)]]> /hvaonline/posts/list/43059.html#271103 /hvaonline/posts/list/43059.html#271103 GMT HVA bảo mật như thế nào?

chube wrote:
hình thức chỉ là 1 phần của chân lý mà ở đây href chỉ là cái hình thức được chường ra để che cái chân lý được đám javascript kia hide đi . Vậy muốn tìm chân lý? Chắc em phải bắt đầu từ cái mớ javascript quá phải không anh ;) ? 
Không phải từ mớ Javascript đó đâu. Đoạn mã đó nhằm xử lý HTML DOM, mục đích phân tích các hành vi tác động lên fakelink và đưa ra đáp ứng. Như onclink, onmouseout, onmuoseover... Điều khó hiểu ở đây là ở line 91: Tại sao: Code:
var FakeLinkWindow = window.open( this.title, 'outbound', '' ); //It'll create new window
Chứ không phải thay thế bằng: Code:
if(window.location.toString().indexOf('/to')==-1)
{
    window.location = window.location + this.title; //Redirect without create new window
}
Tôi nhớ trong một đoạn hội thoại với anh conmale, có bạn hỏi tại sao lại mở cửa sổ mới. Ảnh chỉ nói ẩn ý là "cái gì tồn tại cũng có lí do của nó". Và một đoạn nữa line 52: Code:
if (Links[i].className.indexOf('download') !== -1) {

   Links[i].onclick = function() {
      doUrchin(this.href, 'downloads');
   }

}
Không có HTML elements nào có class name chứa cụm từ "donwload" cả. Tôi vẫn chưa hiểu tại sao nó xuất hiện ở đây. Client side: Mọi thứ được phơi bày rõ ràng, giống như một ván cờ vậy hai bên thấy của nhau. Nhưng để nắm được ý đồ đối phương thì cần phải phân tích.]]> /hvaonline/posts/list/43059.html#271105 /hvaonline/posts/list/43059.html#271105 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#271106 /hvaonline/posts/list/43059.html#271106 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#271353 /hvaonline/posts/list/43059.html#271353 GMT HVA bảo mật như thế nào?

C0denam3 wrote:
@ conmale : Giả sử như mấu chốt vấn đề nhận dạng được bot và client hợp lệ được giải quyết, em có vài thắc mắc về hệ thống của HVA liên quan đến việc cấu hình trên những ông gác cổng. 1. Anh triển khai việc nhận dạng đó trên hệ thống như thế nào ? Theo em thì có lẽ trên những ông gác cổng anh sẽ dùng một IDS, có thể là Snort, vì một khi attacker đã lến đến layer 7 thì em nghĩ là cần phải có một IDS có thể hoạt động ở layer 7, nên em chỉ nghĩ đến Snort và Mod_Security. Mod_Security theo em không khả thi, nên em nghĩ là anh sẽ chọn Snort, đúng không anh ? Và nếu đúng là chọn Snort, thì việc với nhiều ông gác cổng như vậy, thì việc đồng bộ hóa và chỉnh sửa các rules anh thực hiện như thế nào, có cần thông qua một management system nào không hay là thủ công ? hoặc giả sử anh không dùng snort thì anh sẽ dùng gì vào trong trường hợp này ???? 2. Tương tự với Iptable cũng vậy, sau khi IDS nhận ra được attacker, việc tiếp theo là cho attacker này vào trong black list. Với một hệ thống gồm nhiều ông gác cổng như vậy thì việc đồng bộ hóa iptables rules anh sẽ giải quyết như thế nào ? Dĩ nhiên theo em nghĩ thì nếu một trong những ông gác cổng block thì những ông khác cũng phải block theo thì mới hiệu quả. Hoặc giả sử không sử dụng iptables thì anh sẽ sử dụng gì ? 
=> Có khái niệm IDS layer 7?!? => Vui lòng chứng minh vì sao nó không khả thi! => "Đã là cao thủ thì lá có cũng có thể dùng thay kiếm" :P 2. Việc đồng bộ hoá blacklist trên tất cả các Server cũng không thực sự quan trọng lắm. Bởi vì một IP đang tấn công vào Server mà lại clear DNS sau một khoảng thời gian để tấn công đến Server khác thì hiệu quả của cuộc tấn công DDOS đã giảm đáng kể. - Ky0 -]]> /hvaonline/posts/list/43059.html#271372 /hvaonline/posts/list/43059.html#271372 GMT HVA bảo mật như thế nào? => Có khái niệm IDS layer 7?!?   Ý mình là một IDS có thể hiểu các protocol ở layer 7 ấy mà. Trong trường hợp này là HTTP.
=> Vui lòng chứng minh vì sao nó không khả thi! 
Thực ra nếu dùng mod_securty thì vẫn được, về performance thì mình chưa testing trong điều kiện khó khăn như HVA nên chưa biết rõ liệu cái nào hay hơn. Nhưng nếu dùng một application chuyên dùng làm IDS như snort thì sẽ hay hơn, :D]]> /hvaonline/posts/list/43059.html#271377 /hvaonline/posts/list/43059.html#271377 GMT HVA bảo mật như thế nào? # nmap 74.63.219.12 -P0 -sS PORT STATE SERVICE 443/tcp open https   Chỉ có một cổng mở, và chỉ dành cho các request đi qua 3 ông gác cổng. Ở đây lượng request đã bị giảm đáng kể. Tức là những request.method = GET đã được ông gác cổng chăm sóc, số còn lại thường là request.method = POST , kèm theo đó là các yêu cầu đồng bộ từ 3 ông gác cổng (phỏng đoán của em). Nói tới đây chắc hẳn các bạn sẽ nhớ lại "một đám nào đó" đã "dội" vào HVA một tá request.method = POST (trong kí sự các vụ DDoS HVA). Ý sau về mod_security em không dám bàn, vì em chưa tìm hiểu được gì nhiều cho lắm. Em chỉ nhớ có một câu nói thế này và em nghĩ nó cũng thích hợp để nói ở đây. Anh có thể thuê một người dọn dùm anh một mẩu bánh mì bị rơi, Hoặc để tất cả các việc đó cho một đàn kiến mà chẳng tốn kém gì. ^^! Dù sao tư duy bảo mật của nhiều người là dùng dao giết trâu để mổ gà. Trong khi chúng ta có thể chia nhỏ một vấn đề và giải quyết nó đơn giản hơn.]]> /hvaonline/posts/list/43059.html#271387 /hvaonline/posts/list/43059.html#271387 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#271421 /hvaonline/posts/list/43059.html#271421 GMT HVA bảo mật như thế nào?

IT0405 wrote:
@ conmale : Giả sử như mấu chốt vấn đề nhận dạng được bot và client hợp lệ được giải quyết, em có vài thắc mắc về hệ thống của HVA liên quan đến việc cấu hình trên những ông gác cổng. 1. Anh triển khai việc nhận dạng đó trên hệ thống như thế nào ? Theo em thì có lẽ trên những ông gác cổng anh sẽ dùng một IDS, có thể là Snort, vì một khi attacker đã lến đến layer 7 thì em nghĩ là cần phải có một IDS có thể hoạt động ở layer 7, nên em chỉ nghĩ đến Snort và Mod_Security. Mod_Security theo em không khả thi, nên em nghĩ là anh sẽ chọn Snort, đúng không anh ? Và nếu đúng là chọn Snort, thì việc với nhiều ông gác cổng như vậy, thì việc đồng bộ hóa và chỉnh sửa các rules anh thực hiện như thế nào, có cần thông qua một management system nào không hay là thủ công ? hoặc giả sử anh không dùng snort thì anh sẽ dùng gì vào trong trường hợp này ???? 2. Tương tự với Iptable cũng vậy, sau khi IDS nhận ra được attacker, việc tiếp theo là cho attacker này vào trong black list. Với một hệ thống gồm nhiều ông gác cổng như vậy thì việc đồng bộ hóa iptables rules anh sẽ giải quyết như thế nào ? Dĩ nhiên theo em nghĩ thì nếu một trong những ông gác cổng block thì những ông khác cũng phải block theo thì mới hiệu quả. Hoặc giả sử không sử dụng iptables thì anh sẽ sử dụng gì ? 
Ngay từ đầu anh đã nhấn mạnh nguyên tắc: "denied all, allowed selected". Điều này có nghĩa nguyên tắc này áp dụng trên mọi tầng bảo vệ. Vấn đề không nằm ở chỗ snort hay mod_security hay bất cứ công cụ nào trên mỗi tầng giao thức mà ở chỗ: 1. cái gì hợp lệ thì cho vào. 2. cái gì hợp lệ nhưng số lần truy cập quá bình thường thì trở thành bất hợp lệ. Vậy, cái gì thì hợp lệ? Nhiều lắm, nhưng trước tiên đi từ các RFC. Ví dụ, giao thức HTTP gồm có những gì và những gì thì được xem là hợp lệ (cái gì trong từng header's field và giá trị của chúng là gì). Khi nói đến "nhưng số lần truy cập quá bình thường thì trở thành bất hợp lệ" thì có nghĩa tính hợp lệ bị biến thành bất hợp lệ không còn ở cấp độ giao thức và những quy định của giao thức mà đi đến chỗ tính bình thường và hợp lý của một người dùng khác với "tự động hoá". Anh không áp dụng chính xác và trực tiếp việc cản lọc từng lỗi bảo mật hoặc từng biến thái bảo mật mà anh áp dụng: "denied all, allowed selected".]]> /hvaonline/posts/list/43059.html#271511 /hvaonline/posts/list/43059.html#271511 GMT HVA bảo mật như thế nào? Anh không áp dụng chính xác và trực tiếp việc cản lọc từng lỗi bảo mật hoặc từng biến thái bảo mật mà anh áp dụng: "denied all, allowed selected".  Anh nói câu này làm em nhớ đến 1 trường hợp mà anh nói ở loạt bài Rookie: "tạo ra 1 chìa khoá có thể mở được nhiều loại khoá"
<html> <head> <meta http-equiv="refresh" content="300"> </head> pong <body> </body> </html>  
Đoạn này thì cho em hỏi sao mình lại sử dụng cái này mà không sử dụng session hay cookie để quyết định thời gian live của client. Thấy cứ 5 phút cái trình duyệt lại xoay xoay làm em chóng mặt quá P/S: cái trang này bị vỡ khung rồi mấy anh ơi]]> /hvaonline/posts/list/43059.html#273208 /hvaonline/posts/list/43059.html#273208 GMT HVA bảo mật như thế nào?

sasser01052004 wrote:
Anh không áp dụng chính xác và trực tiếp việc cản lọc từng lỗi bảo mật hoặc từng biến thái bảo mật mà anh áp dụng: "denied all, allowed selected". 
Anh nói câu này làm em nhớ đến 1 trường hợp mà anh nói ở loạt bài Rookie: "tạo ra 1 chìa khoá có thể mở được nhiều loại khoá"
<html> <head> <meta http-equiv="refresh" content="300"> </head> pong <body> </body> </html>  
Đoạn này thì cho em hỏi sao mình lại sử dụng cái này mà không sử dụng session hay cookie để quyết định thời gian live của client. Thấy cứ 5 phút cái trình duyệt lại xoay xoay làm em chóng mặt quá P/S: cái trang này bị vỡ khung rồi mấy anh ơi 
Việc kiểm soát và quyết định thời gian tồn tại của session thì đã có nhưng nếu cứ đợi 30 phút (hoặc bao nhiêu lâu đó) mà triệt tiêu session, bất chấp client còn sử dụng thì quá bậy. Bởi vậy, cứ 5 phút thì trình duyệt "ping" 1 phát. Nếu mà client không gởi "ping" thì server chẳng biết client còn đó hay đã tắt máy đi chơi rồi. Còn chuyện 5 phút gởi ping 1 lần mà chóng mặt thì phóng đại hoá và đòi hỏi hơi nhiều đó.]]> /hvaonline/posts/list/43059.html#273217 /hvaonline/posts/list/43059.html#273217 GMT HVA bảo mật như thế nào? Hiding files extensions 2. Disabling or Changing banner server (Do sử dụng server của Apache). Đối với Apache 2.x trong mod_headers trong file httpd.conf để chỉnh sửa lại thông tin banner tại dòng Header set Server "New Server Name" P/s: Server là Apache mod_jk/1.2.31 (cái này em nghĩ có phải đúng như chổ số 2 em nói không nhỉ :-/ ) ]]> /hvaonline/posts/list/43059.html#273245 /hvaonline/posts/list/43059.html#273245 GMT HVA bảo mật như thế nào? http://google.com.vn. Liệu có cách nào khắc phục điểm này? Thử với dòng lệnh: Code:
$curl https://www.hvaonline.net/hvaonline/posts/list/0/44479.html => 403

$curl --referer http://www.google.com.vn https://www.hvaonline.net/hvaonline/posts/list/0/44479.html => đầy đủ nội dung.
]]> /hvaonline/posts/list/43059.html#274478 /hvaonline/posts/list/43059.html#274478 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#274487 /hvaonline/posts/list/43059.html#274487 GMT HVA bảo mật như thế nào? /hvaonline/posts/list/43059.html#274492 /hvaonline/posts/list/43059.html#274492 GMT