HVA bảo mật như thế nào?

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Case Studies

HVA bảo mật như thế nào?

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 12:56:06 (+0700) \| #1 \| 267749

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Có rất nhiều bạn hỏi (riêng) với tôi câu hỏi: "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.

What bringing us together is stronger than what pulling us apart.

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 13:43:19 (+0700) \| #2 \| 267753

angel_of_devil
Member

Joined: 23/10/2004 14:57:09
Messages: 154
Offline

This post is set hidden by a moderator because it may be violating forum's guideline or it needs modification before setting visible to members.

Ngoảnh nhìn lại cuộc đời như giấc mộng
Được mất bại thành bỗng chốc hoá hư không

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 13:47:05 (+0700) \| #3 \| 267754

vd_
Member

Joined: 06/03/2010 03:05:09
Messages: 124
Offline

@conmale

anh conmale có chi phí là bao nhiêu?

risks => mitigations
- script injection/sql injection => sử dụng application firewall
- network attack => sử dụng os firewall & ids/ips
- DDOS => load balancing bằng reverse proxy/caching server
- disaster recovery => sử dụng cloud như amazon ec2 hoặc rackspace
- social engineering => chọn mod & admin kỹ lưỡng

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 14:01:29 (+0700) \| #4 \| 267755

sasser01052004
Member

Joined: 20/09/2010 01:27:29
Messages: 150
Location: /home/sasser
Offline

em trước nhé
Em sẽ bàn 1 hệ thống *nix cụ thể là centos nhé

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)

Ask me why, don't ask me what.

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 14:05:23 (+0700) \| #5 \| 267756

Ikut3
Elite Member

Joined: 24/09/2007 23:47:03
Messages: 1429
Location: Nhà hát lớn
Offline

- 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

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 14:05:59 (+0700) \| #6 \| 267757

Ky0
Moderator

Joined: 16/08/2009 23:09:08
Messages: 532
Offline

Thông bá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 -

UITNetwork.com
Let's Connect

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 14:29:04 (+0700) \| #7 \| 267759

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Có lẽ nên khai triển theo góc độ 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.

What bringing us together is stronger than what pulling us apart.

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 15:22:08 (+0700) \| #8 \| 267763

Nowhereman
Elite Member

Joined: 19/11/2003 06:25:42
Messages: 108
Offline

1 ) cần những gì ? = Cần một đội ngũ làm Security Chuyên nghiệp ( những người biết làm sao để không bị mất password, biết update đều đặn những bản vá bảo mật patches, biết đề phòng và dành thời gian cho những vấn đề security máy tính )

2 ) cần một ISP cũng là dân chuyên nghiệp về bảo mật để còn chạy vạy lúc bị tấn công DDOS hoặc không bị hack mất Domains.

em mạn phép nghĩ vậy cũng đủ cái cần để HVA sống khoẻ sống đẹp rồi hì hì smilie

lang thang vẫn mãi không nhà
đôi chân lê bước thê lương tháng ngày
càng đi càng thấy đắm say
tình thương con Chúa lòng này chẳng phai
thời gian cứ mãi miệt mài
lang thang đi tiếp ....rồi bay lên z ời
cúi đầu con lạy Ông Trời
xin thươn

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 16:21:04 (+0700) \| #9 \| 267768

Ky0
Moderator

Joined: 16/08/2009 23:09:08
Messages: 532
Offline

Em cũng bon chen phân tích đôi chút smilie

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 smilie

- 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ị smilie

- 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 smilie

+ 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 smilie

- 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 smilie

UITNetwork.com
Let's Connect

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 17:11:48 (+0700) \| #10 \| 267769

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

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 smilie

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

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 18:18:09 (+0700) \| #11 \| 267773

whatdie15
Member

Joined: 21/06/2012 21:27:01
Messages: 49
Location: Galaxy
Offline

Thấy case-studies hay quá nên dù kiến thức hạn hẹp cũng bon chen, chính vì thế mà em chỉ xin bàn về những vấn đề tư tưởng, còn kĩ thuật thì xin…. hihi
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á smilie

.
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 smilie

.
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.

If you fall I’ll catch, if you love I’ll love,
and so it goes, my dear, don’t be scared, you’ll be safe.
This I swear. If you only love me girl!!!!

[Analyzing] HVA bảo mật như thế nào?	31/07/2012 19:20:38 (+0700) \| #12 \| 267777

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

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).

[Analyzing] HVA bảo mật như thế nào?	01/08/2012 09:01:12 (+0700) \| #13 \| 267799

vd_
Member

Joined: 06/03/2010 03:05:09
Messages: 124
Offline

Rồi, kinh phí hạn hẹp, vậy tui chi tiết thêm mấy cái đã viết như sau:

risks => mitigations
- script injection/sql injection => sử dụng application firewall => mod_security + core rule set, pipe audit log sang cho AuditConsole, error log gửi qua central syslog

- network attack => sử dụng os firewall & ids/ips => snort + barnyard đưa fast_error vào central syslog, event đưa vào mysql db cho snorby, iptables chỉ cho port ssh và web, iptables có log

- DDOS => load balancing bằng reverse proxy/caching server => sử dụng nginx đứng trước, forward qua application servers, tất cả image/css/js được đặt trên nginx

- HIDS => sử dụng ossec agent để kiểm tra toàn vẹn dữ liệu.

- ssh sử dụng key => tốn 1 ít mua hardware (pkcs11) key. Tất cả admin web (AuditConsole, snorby, v.v... muốn access phải thông qua ssh tunnel.

- dùng thêm auditd và sử dụng tập rule để kiểm soát các access/execute các syscall quan trọng (read/write vào các file shadow, passwd, các lệnh chmod v.v...)

- đặt nginx, apache, tomcat vào trong linux container

- disaster recovery => sử dụng cloud như amazon ec2 hoặc rackspace, dùng 3 small instance chắc đủ, cái này hơi bị hao nhất.

- social engineering => chọn mod & admin kỹ lưỡng

- sử dụng 1 server riêng làm central syslog, có cài ossec hoạt động active response để khi mod_sec, snort & iptable report error là lock server lại.

[Analyzing] HVA bảo mật như thế nào?	01/08/2012 11:29:47 (+0700) \| #14 \| 267809

kakarottbatdong
Member

Joined: 02/05/2009 19:27:06
Messages: 55
Offline

- script injection/sql injection ==> về vấn đề này HVA không bị dính là bởi vì sql dạng PreparedStatement, thứ hai là HVA dùng jforum, jforum sử dụng toàn cache, toàn bộ dữ liệu trong database sẽ được load vào cache hết...
- về tường lửa ==> iptables + mod security cũng đã lọc kỹ các request không hợp lệ.
...

[Analyzing] HVA bảo mật như thế nào?	01/08/2012 12:35:53 (+0700) \| #15 \| 267814

whatdie15
Member

Joined: 21/06/2012 21:27:01
Messages: 49
Location: Galaxy
Offline

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ơ smilie

Thân!!!!

If you fall I’ll catch, if you love I’ll love,
and so it goes, my dear, don’t be scared, you’ll be safe.
This I swear. If you only love me girl!!!!

[Analyzing] HVA bảo mật như thế nào?	02/08/2012 18:46:51 (+0700) \| #16 \| 267922

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Hì đang mệt nên mình chỉ muốn đề cập qua 1 số cái hay của HVA mà chắc nhiều người vẫn thắc mắc và 1 số thì không chú ý đến smilie

)

Mình là mình chú ý nhất các thao tác khi truy cập HVAOnline.net từ đầu. Mấy lần wwwect và set cookie (để có thể truy cập vào diễn đàn).

Mỗi lần wwwect đó, đường link mỗi lần lại chứa những cụm IP khác nhau (load balancing) mà biết đâu sau đó nginx lại proxy rồi đưa đến server khác phía sau nữa (?), nhưng cái mình đề cập đến không phải là load balancing mà cái trick HVA dùng để đánh lừa Bot để phân biệt người truy cập hợp lệ. Cho đến cách HVA chia lưu lượng mạng smilie

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

Ở đâ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ì đó (...)
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ề :-"

Trash from trash is the place for new good things ~

[Analyzing] HVA bảo mật như thế nào?	02/08/2012 22:39:01 (+0700) \| #17 \| 267940

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline

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-đó smilie

) 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

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline

[Analyzing] HVA bảo mật như thế nào?	03/08/2012 09:36:42 (+0700) \| #18 \| 267955

chube
Member

Joined: 22/10/2010 02:34:04
Messages: 105
Location: ░░▒▒▓▓██
Offline

Mình xin đưa ra 1 số ý kiến :

- 1 trong những vấn đề lớn nhất trong việc bảo mật mạng ngày nay đó là người quản trị mạng thường hay suy nghĩ bảo mật là 1 cái gì đó được thực hiện ngay sau khi network đã được thiết kế. Cho nên đây có lẽ là điểm cần khắc phục đầu tiên.

- Vulnerable, Threats hay Exploits luôn mở đường cho những cuộc tấn công. Chúng dẫn đầu trong danh sách những phương pháp tấn công mạng và là 1 vấn đề không dễ để tìm được 1 giải pháp giải quyết triệt để . Việc ta hạn chế những hành động gây được sự đỗ vỡ trong 1 hệ thống không dễ dàng nhưng không phải là không thể.

- Chúng ta cứ track down và hạn chế tối đa toàn bộ lỗ hổng bảo mật có thể có trong hệ thống, bởi vì kẻ xâm nhập chỉ cần 1 lỗ hổng và khai thác nó. Và trong vài trường hợp, kẻ xâm nhập có thể khai thác dựa trên 1 phần cụ thể của phần mềm, misconfiguration hoặc cấu hình device 1 cách lỏng lẻo hay có lẽ là những điểm yếu trên giao thức, TCP/IP là 1 ví dụ.. Phương thức này được phát triển từ lâu khi người thiết kế không nhìn trước được những vấn đê liên quan đến bảo mật mà chúng ta phải gặp ngày nay. Ví dụ những thiếu sót trong giao thức dẫn đến các attack vector như IP Spoofing, source routing, syn flood, smurf attack, application tunnelling và nhiều hơn nữa.

Trước khi nhìn gần hơn vào khía cạnh technique của mitigation, Chúng ta cần phân loại rõ ràng các hình thức tấn công :
Có thể chia các cuộc tấn công thành 3 loại đặc trưng mà diễn đàn hva đã, đang và sẽ gặp trong tương lai :

* Trinh sát : (Reconnaissance) : là loại tấn công được xem như là bước đầu tiên của quá trình thăm dò mục tiêu như unauthorized discovery và mapping hệ thống, các dịch vụ hoặc lỗ hổng trên mục tiêu. Kĩ thuật discovery và mapping phổ biến được biến đến nhiều nhất là Scanning và Enumeration với các công cụ dòng lệnh và tiện ích phổ biến được sử dụng cho việc scan và enumeration như là ping, telnet,nslookup, finger, rpcinfo, file explorer, srvinfo, và dumpacl. Những thirdparty khác như Sniffer,Satan,saint,nmap,netcat,wirkshark..vv hoặc những custom script được tạo ra để sử dụng cho tiến trình này.

* Đạt quyền kiểm soát(gain access): tấn công chiếm quyền truy cập nghĩa là thao tác với dữ liệu không được chứng thực(unauthorized data) nhằm giúp cho attacker quyền truy cập hệ thống hoặc leo thang đặc quyền trên máy nạn nhân hoặc thỏa hiệp 1 host. Unauthorized data đơn giản là các hành động reading, writing, copying và moving những file không được cho phép hoặc đã được authorize bởi attacker. Một số hành động thực hiện trong giai đoạn này như exploiting pass, accessing confidential information, exploting poorly configuration hoặc unmanaged service, acess remote registry hay ip source routing và file sharing...vv

* Denial of servie : Đây là loại tấn công xảy ra nhằm khóa, vô hiệu hóa hoặc phá hủy mạng, dịch vụ hệ thống với mục đích là từ chối dịch vụ người dùng hợp lệ. Những cuộc tấn công này gây cản trở nguồn tài nguyên có sẵn làm cho người dùng hợp lệ bị crash hệ thống hoặc truy cập chậm . ví dụ phổ biến là tcp syn flood, icmp ping flood, buffer overflow...vv

Những loại tấn công trên đều chung mục đích là đạt quyền truy cập đến tài khoản người dùng , leo thang đặc quyền và khai thác hệ thống nạn nhân để sử dụng cho việc tấn công hệ thống khác hay với 1 mục đích khác ...!

Mình xin trình bày 1 số attack vector nhưng mitigation thì xin cùng các bạn thảo luận vì có những attack vector đòi hỏi kiến thức sâu về 1 mảng mà kiến thức mình thì giới hạn !

Trước hết ta cần hiểu attack vector là những phương thức được sử dụng nhằm lấy được quyền kiểm soát máy tính hoặc hệ thống mạng để cho attacker có thể lợi dụng.
có thể chia làm các loại như sau :

++Viruses : là những phần mềm độc hại hoặc những đoạn mã nhằm phá hủy dữ liệu hoặc lây nhiễm vào hệ thống

++Worm : sâu máy tính là phần mềm độc hại có khả năng tự nhân bản, tương tự virus, sâu và virus có thể tồn tại trong bộ nhớ của hệ thống và có khả năng tự phát tán đến các máy khác trong mạng. Worm thường được thiết kế để exploit các lỗ hổng well-know cũng như undocument trên máy tính

++Trojan : là những malicious program làm ra vẻ là 1 ứng dụng hiền lành, nhưng thực chất ẩn chứa bên trong những hành vi độc hại như keystroke logger hoac capture all pass và thông tin nhạy cảm mà ko cần sự đồng ý của user

++Pass cracking : là loại tấn công pass bao gồm bruteforce, ip spoofing and packet sniffer.

++Buffer overlow: buffer là vị trí bộ nhớ trong hệ thống được sử dụng để chứa dữ liệu và thường chỉ chứa được 1 kích thước cố định được định nghĩa từ trước. Buffer overflow xảy ra khi chương trình thử chứa dữ liệu trong buffer, mà nó lớn hơn kích thước mà buffer được cung cấp. Giống như là mình đổ đầy 1.5 lít nước vô 1 cái ly(buffer) chỉ chứa dc 1 lít nước (data).

++Ip spoofing : xảy ra khi kẻ xâm nhập cố gắng ngụy trang bản thân bằng cách giả dạng là 1 nguồn địa chỉ IP đáng tin cậy để đạt được nguyền truy xuất đến 1 tài nguyên trên 1 host nhất định.

++Address Resolution Protocol (ARP) spoofing: ARP spoofing xẩy ra khi kẻ xâm nhập cố gắng ngụy trang 1 địa chỉ MAC – là hiện thân cho 1 hosted trust -. Đây là 1 bước quan trọng để mở màng cho các cuộc tấn công khác.

++Man-in-the-middle attack (TCP hijacking): man-in-the-middle (MITM), ngoài ra còn được biết với cái tên như là TCP hijacking, là 1 cuộc tấn công well-known mà trong đó attacker có thể chặn những gói tin qua lại giữa 1 giao tiếp hợp lệ từ 2 điểm và có thể dễ dàng thay đổi hoặc điều khiển TCP seion mà không cần sự biết đến giữa người gửi và nhận của session đó. TCP hijaking là 1 exploit trên những mục tiêu như telnet,ftp,smtp hoặc http session. Attacker ngoài ra có thể sniffing để theo dõi gói tin qua lại giữa 2 bên.
Ping sweeps: hay còn có 1 tên khác là Internet Control Message Protocol (ICMP) sweep, là kĩ thuật quét sử dụng để xác định 1 host(computer) có còn sống hay không trong 1 mạng . Bao gồm ICMP echo request gửi đến nhiều host tại 1 thời điểm. Nếu host còn sống thì sẽ send lại 1 gói ICMP echo.

++Port scanning: Port scanning là phương thức được sử dụng để liệt kê các dịch vụ đang chạy trên hệ thống. intruder sẽ gửi ngẫu nhiên các request trên các port khác nhau và nếu host trả lời lại request đó, intruder sẽ xác nhận port đó đang active và trong chế độ lắng nghe ( listen mode), attacker có thể lên kế hoạch để exploit những vulnerabilities đã được biết đến qua các trang chuyên về khai thác lỗ hổng. Đây là kĩ thuật chính dc sử dụng để thăm dò dịch vụ và tiến hành.

++Sniffing:Là hành động bắt gói tin do 1 phần mềm chuyên dùng để bắt gói – sử dụng card mạng trong chế độ promiscuous để passively capture toàn bộ gói tin được vận chuyển xuyên qua mạng-.

++Flooding: Flooding xảy ra khi số lượng dữ liệu không mong muốn được gửi đi quá mức cho phép và kết quả dẫn đến sự đổ vỡ của tính chất data availability.

++DoS/DDoS: Đây là loại tấn công mà hva đang thường xuyên phải đối mặt.Nó tước đoạt sự truy cập hợp lệ của người dùng, flooding nạn nhân với những gói tin quá mức cho phép (excessive volume of packet)và có những dấu hiệu bất thường .

Về phần mitigation thì mình thấy những post ở trên rất giá trị, mình sẽ tiếp tục tìm tòi và sau khi đã hiệu chỉnh toàn bộ các ý và câu văn sẽ post lên sau. Bài viết không thể tránh khỏi sai sót. Thân !

.-/ / )
|/ / /
/.' /
// .---.
/ .--._\ Awesome Season to hack :') Dont you think so? xD
/ `--' /
/ .---'
/ .'
/

[Analyzing] HVA bảo mật như thế nào?	03/08/2012 10:26:52 (+0700) \| #19 \| 267958

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

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).

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>.

What bringing us together is stronger than what pulling us apart.

[Analyzing] HVA bảo mật như thế nào?	03/08/2012 17:29:59 (+0700) \| #20 \| 267985

IT0405
Member

Joined: 06/07/2012 07:40:28
Messages: 33
Offline

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.

Dạo này có nhiều vụ hài quá, toàn gặp võ sĩ mồm.

[Analyzing] HVA bảo mật như thế nào?	04/08/2012 01:03:07 (+0700) \| #21 \| 268007

chube
Member

Joined: 22/10/2010 02:34:04
Messages: 105
Location: ░░▒▒▓▓██
Offline

@C0denam3 :

- 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 ?

Lưu ý rằng đối tượng anh male dùng để khai triển cho nguyên tắc thứ 2 rất cụ thể là các CHUỖI MÁY CHỦ và các DỊCH VỤ chứ không phải là "một đố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é , lấy ví dụ, bạn phải cài 1 antivirus thì antivirus đó có nhiều chức năng như update, protect ...vv- . Vì vậy khi install những đối tượng này, quan trọng như anh male đề cập :

"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ó. "

.-/ / )
|/ / /
/.' /
// .---.
/ .--._\ Awesome Season to hack :') Dont you think so? xD
/ `--' /
/ .---'
/ .'
/

[Analyzing] HVA bảo mật như thế nào?	04/08/2012 07:17:45 (+0700) \| #22 \| 268012

IT0405
Member

Joined: 06/07/2012 07:40:28
Messages: 33
Offline

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.

Dạo này có nhiều vụ hài quá, toàn gặp võ sĩ mồm.

[Analyzing] HVA bảo mật như thế nào?	04/08/2012 07:33:13 (+0700) \| #23 \| 268015

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

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" smilie

What bringing us together is stronger than what pulling us apart.

[Analyzing] HVA bảo mật như thế nào?	04/08/2012 15:13:23 (+0700) \| #24 \| 268038

9aa6
Member

Joined: 08/01/2012 21:50:50
Messages: 30
Location: bờ đê lộng gió ,,,,
Offline

HVA nhà mình bảo mật trên máy chủ host hay tập chung chủ yếu ở mã nguồn web vậy.

Đừng tưởng xinh gái mà vội kiêu
có tý nhan sắc vẫn chưa siêu
mà này anh bảo cho mà biết
khi nào mát trời anh sẽ yêu

[Analyzing] HVA bảo mật như thế nào?	04/08/2012 17:54:07 (+0700) \| #25 \| 268045

whatdie15
Member

Joined: 21/06/2012 21:27:01
Messages: 49
Location: Galaxy
Offline

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.

If you fall I’ll catch, if you love I’ll love,
and so it goes, my dear, don’t be scared, you’ll be safe.
This I swear. If you only love me girl!!!!

[Analyzing] HVA bảo mật như thế nào?	07/08/2012 15:37:46 (+0700) \| #26 \| 268173

9aa6
Member

Joined: 08/01/2012 21:50:50
Messages: 30
Location: bờ đê lộng gió ,,,,
Offline

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 có tận 4 hay 5 cái server riêng ạ. Nếu mà thuê máy chủ thuê host thì làm sao mà bảo mật đc trên máy chủ (cái này phải do nhà cung cấp dịch vụ chịu trách nhiệm đúng ko ạ) .ý e là thế

Đừng tưởng xinh gái mà vội kiêu
có tý nhan sắc vẫn chưa siêu
mà này anh bảo cho mà biết
khi nào mát trời anh sẽ yêu

[Analyzing] HVA bảo mật như thế nào?	07/08/2012 18:14:54 (+0700) \| #27 \| 268177

whatdie15
Member

Joined: 21/06/2012 21:27:01
Messages: 49
Location: Galaxy
Offline

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 đó.

If you fall I’ll catch, if you love I’ll love,
and so it goes, my dear, don’t be scared, you’ll be safe.
This I swear. If you only love me girl!!!!

[Analyzing] HVA bảo mật như thế nào?	09/08/2012 12:20:56 (+0700) \| #28 \| 268228

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

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ý smilie

, 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

[Analyzing] HVA bảo mật như thế nào?	18/08/2012 04:00:25 (+0700) \| #29 \| 268525

Sangdth
Member

Joined: 22/05/2008 02:10:41
Messages: 25
Offline

Xin phép nói ngoài lề một chút, mặc dù những nguyên tắc mà anh conmale nói là dành cho bảo mật, nhưng mình lại thấy nó hoàn toàn có ích ngay cả cho nghề design của mình.

Thú thật là mình chỉ vào đây để xem tin tức và học hỏi cách suy nghĩ và tiếp cận vấn đề thông qua những bài "châm cứu" của anh conmale. Xin được bày tỏ sự ngưỡng mộ và cảm ơn anh. Chúc anh nhiều sức khoẻ và bình an.

(Nếu thấy bài gây loãng, các mod có thể delete, xin lỗi.)

Yết-đế , yết-đế , Ba-la yết-đế . Ba-la-tăng yết-đế Bồ-đề tát-bà-ha

[Analyzing] HVA bảo mật như thế nào?	01/09/2012 12:08:02 (+0700) \| #30 \| 268946

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

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ể.

What bringing us together is stronger than what pulling us apart.

Go to:

Users currently in here
1 Anonymous