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?	02/09/2012 13:26:28 (+0700) \| #31 \| 268983

whatdie15
Member

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

Đọc bài của anh connale thấy rất thầm mặc dù còn nhiều điểm chưa biết nó là cái gì chứ chưa nói đến hiểu.

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?

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?	04/09/2012 09:58:09 (+0700) \| #32 \| 269014

conmale
Administrator

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

Nhiều bạn thắc mắc "rốt cuộc HVA allow selective là allow như thế nào?" và đây là câu hỏi trọng điểm nhưng cực khó trả lời bởi vì có 2 lý do: 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ó.

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

[Analyzing] HVA bảo mật như thế nào?	11/09/2012 08:21:33 (+0700) \| #33 \| 269288

LlyKil
Member

Joined: 22/01/2008 18:33:58
Messages: 16
Offline

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

[Analyzing] HVA bảo mật như thế nào?	11/09/2012 09:04:30 (+0700) \| #34 \| 269290

conmale
Administrator

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

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.

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

[Analyzing] HVA bảo mật như thế nào?	20/09/2012 16:03:50 (+0700) \| #35 \| 269553

phanledaivuong
Member

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

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 smilie

)

[Analyzing] HVA bảo mật như thế nào?	20/09/2012 22:24:44 (+0700) \| #36 \| 269570

Zombie
HVA Friend

Joined: 13/12/2002 03:27:34
Messages: 77
Offline

Chốt hạ cách secu của HVA là xếp 1 em chân dài ngồi duyệt từng "connect i/o" smilie

.
Connect nào có "ok" thì pass smilie

[Analyzing] HVA bảo mật như thế nào?	07/10/2012 20:34:15 (+0700) \| #37 \| 269965

sasser01052004
Member

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

Thấy nhiều khi em "chân dài" này hoa mắt quăng mấy anh "đẹp trai" vào null

Ask me why, don't ask me what.

[Analyzing] HVA bảo mật như thế nào?	13/11/2012 12:07:55 (+0700) \| #38 \| 270939

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Em tự hỏi mọi người ngồi đây đoán trời đoán bể vậy sao không thử đi thực tế nhỉ ?. Mặc dù sức không có nhưng em cũng ráng xem theo được tới đâu.

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>

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

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

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

while(1){}

[Analyzing] HVA bảo mật như thế nào?	14/11/2012 08:07:49 (+0700) \| #39 \| 270962

conmale
Administrator

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

Xuất sắc!

Tiếp tục đi em smilie

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

[Analyzing] HVA bảo mật như thế nào?	14/11/2012 14:45:26 (+0700) \| #40 \| 270977

TQN
Elite Member

Joined: 29/06/2006 22:28:01
Messages: 888
Location: Biết làm chi ?
Offline

Hì hì, good job, chiro !

[Analyzing] HVA bảo mật như thế nào?	15/11/2012 00:13:51 (+0700) \| #41 \| 270992

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Người Việt vẫn cái luật vào 3 ra 7, anh comanle mời thì em tiếp vậy. Chén này thứ 2 mà uống xong chắc em lăn quay.
Sau bài viết ở trên em cũng hơi đuối chút, tại vì bắt đầu đến đoạn bí nên em không ráng lần mò gì thêm nữa.
Em tìm cách để biết cái gì thực sự sau "các server chường mặt chịu đấm" kia. Điểm danh lại ta có:

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

while(1){}

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

conmale
Administrator

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

Tóm lại, phần phân tích thứ nhất của chiro8x có những điểm sau:

1. Trực tiếp truy cập vào diễn đàn sẽ bị cản vì không thoả mãn yêu cầu của "ông gác cửa".

2. Hiện thời có 3 "ông gác cửa" nằm ở 3 vị trí khác nhau.

3. Các "ông gác cửa" đều được trang bị y như nhau và có nhiệm vụ y hệt nhau. Nhiệm vụ chính yếu là chỉ cho phép các trình duyệt và truy cập hợp lệ đi vào. Bots bất hợp lệ (kể cả sình tờ lợn) cũng bị cản vì chúng chỉ có khả năng tìm cái href để tiếp tục mò vào (bởi vậy mới obsfucated bằng urlencode).

Có hai link đi vào diễn đàn và portal:

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

.

PS: đã nói là "mọi sự tồn tại vì một lý do nào đó" mà smilie

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

[Analyzing] HVA bảo mật như thế nào?	16/11/2012 12:23:52 (+0700) \| #43 \| 271055

conmale
Administrator

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

30 tiếng rồi mà không thấy ai lên tiếng về cái "điểm lý thú" nên chắc phải gợi ý thêm 1 tí:

Tại sao cần cái này để giấu cái "href":
<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>

smilie

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

[Analyzing] HVA bảo mật như thế nào?	17/11/2012 05:09:14 (+0700) \| #44 \| 271068

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Không phải là không để ý đâu anh, cái trang này em cũng soi kỹ soi đi soi lại rồi. Tại chưa có căn cứ không dám nói xàm.
Chắc em phải nói ra cái ngu ý của em vậy:
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.

while(1){}

[Analyzing] HVA bảo mật như thế nào?	18/11/2012 00:28:36 (+0700) \| #45 \| 271102

chube
Member

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

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 smilie

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

[Analyzing] HVA bảo mật như thế nào?	18/11/2012 06:53:28 (+0700) \| #46 \| 271103

conmale
Administrator

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

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

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

[Analyzing] HVA bảo mật như thế nào?	18/11/2012 08:24:51 (+0700) \| #47 \| 271105

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

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.

while(1){}

[Analyzing] HVA bảo mật như thế nào?	18/11/2012 10:32:33 (+0700) \| #48 \| 271106

chube
Member

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

- À chiro nói đúng đặc điểm khó hiểu chỗ script rồi . Thiệt ra ông gác cổng đó có nhiệm vụ là phân loại đối tượng thôi mà tự vì
+ 1 là nếu mình vô hva theo cách của 1 user bình thường thì chắc chắn không bao giờ nhìn thấy được cái href giấu ở dưới góc phải trang(không nói đến view source - mà co view cũng ko thấy được smilie

- hoặc dùng addon web developer)
+ 2 là nếu đã thấy href ở dưới mà vẫn cứ bám theo dù biết là chỉ dừng mãi ở trang đó thì có thể xác định đối tượng thứ 2 này là ai

Bởi vậy mình mới nghĩ nên bắt đầu từ đoạn xì ríp đó ví dụ như trên dòng dowload 1 tí là indexOf("external") chẳng hạn hay là hàm doUrchin được gọi từ đâu và getElementByTagName('A') với ngụ ý gì ...! hehe

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

[Analyzing] HVA bảo mật như thế nào?	27/11/2012 00:49:00 (+0700) \| #49 \| 271353

IT0405
Member

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

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

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?	27/11/2012 12:59:51 (+0700) \| #50 \| 271372

Ky0
Moderator

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

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

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 -

UITNetwork.com
Let's Connect

[Analyzing] HVA bảo mật như thế nào?	27/11/2012 14:53:42 (+0700) \| #51 \| 271377

IT0405
Member

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

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

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?	28/11/2012 08:18:46 (+0700) \| #52 \| 271387

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Mình đọc mà thấy hoa hết cả mắt, nào là protocol và layer 7 rồi IDS,....Dưới đây là nhận xét riêng của mình.

- "Protocol ở layer 7" : Nếu theo dõi topic bạn sẽ thấy là hệ thống 3 ông gác cổng làm nhiệm vụ :
cân bằng tải, cản lọc, cache, đồng bộ với main server. Từ yêu cầu đó ta thấy các ông này sẽ có những đặc điểm như,
tối giản các dịch vụ, chịu được lượng kết nối lớn. Trên 3 ông này ngoài những config của anh conmale thì hầu như
không có gì đáng giá. Vì mọi request (tới nội dung dộng) được chuyển tiếp tới nơi khác thông qua một TLS tunnel.
Việc cài các hệ thống cồng kềnh để lọc một vài request ở đây cần thiết hơn, hay sử dụng tài nguyên đó để tăng số lượng
request mà server gánh chịu là tốt hơn ?.

Bây giờ ta nhìn về phía cuối của TLS tunnel

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

while(1){}

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

vd_
Member

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

Bổ sung ý nhỏ vì thấy nhiều bạn chưa phân biệt rõ snort và modsec

- snort là IDS chạy ở cấp network, quét nội dung packet để tìm pattern tấn công -> chạy nhanh, nhưng sẽ không đủ để xử lý HTTP, vốn là 1 application protocol (layer 7), chưa kể là nếu access thông qua https thì snort không thể xử lý được.
- modsec chạy trong 1 http server (apache, nginx, hoặc IIS) nên là application ids. Data khi đến được modsec đã qua hết các network layer nên packet assembly, fragmentation,v.v... đều đã được xử lý. modsec xử lý HTTP GET, POST, URL, http response v.v... chứ không quan tâm đến packet

[Analyzing] HVA bảo mật như thế nào?	03/12/2012 05:07:38 (+0700) \| #54 \| 271511

conmale
Administrator

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

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

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

[Analyzing] HVA bảo mật như thế nào?	30/01/2013 23:51:55 (+0700) \| #55 \| 273208

sasser01052004
Member

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

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

Ask me why, don't ask me what.

[Analyzing] HVA bảo mật như thế nào?	31/01/2013 08:34:18 (+0700) \| #56 \| 273217

conmale
Administrator

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

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

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

[Analyzing] HVA bảo mật như thế nào?	01/02/2013 00:06:49 (+0700) \| #57 \| 273245

minhhath
Member

Joined: 22/11/2010 10:03:38
Messages: 91
Location: Team unknow
Offline

Theo kiến thức hạn hẹp của em em thấy những điểm bảo mật của Hva như sau:
1. Sử dụng 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ỉ smilie

)

[Analyzing] HVA bảo mật như thế nào?	29/03/2013 00:24:24 (+0700) \| #58 \| 274478

ShellingFox
Member

Joined: 22/04/2005 18:58:44
Messages: 20
Location: Đăk Lăk
Offline

Gần 1 năm nay mình không thể vượt qua được "ông gác cổng", toàn bị chuyển hướng về /null/. Do đó mình tìm cách đi vào nhà mà không cần phải đi qua ông gác cổng này.

Một lần sau khi tìm tài liệu trên Google, có đường dẫn tới bài trên hva và truy cập được trực tiếp vào luôn chứ không phải đi qua "ông gác cổng" và cũng không gặp lỗi 403.

Từ đó tới giờ mình toàn vào hva bằng cách đặt referer là 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.

[Analyzing] HVA bảo mật như thế nào?	29/03/2013 08:38:04 (+0700) \| #59 \| 274487

kakarottbatdong
Member

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

Đương nhiên HVA phải cho referer từ google, bing v.v.v vào chứ, nếu không thì các thành viên sẽ la ó lên là tại sao em search bằng google, sau đó click vào link hva thì lại trỏ về null thì sao smilie

[Analyzing] HVA bảo mật như thế nào?	29/03/2013 09:41:47 (+0700) \| #60 \| 274492

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Tuỳ mỗi trời điểm mà ông gác cổng phản ứng khác nhau. Rất có thể với kịch bản "thời bình", thì người dùng tìm kiếm từ google sẽ được ưu tiên. Nhưng trong khi HVA bị tấn công mọi chuyện sẽ khác, lúc đó mọi truy vấn có thể sẽ bắt buộc đi qua ông gác cổng, cũng như việc check các feild trong HTTP header sẽ gắt gao hơn. Những gì mình nói ở trên HVA check 1 request khá kỹ lưỡng.

Có lẽ bạn nên đợi lúc HVA bị tấn công và kiểm chứng nhận định của mình smilie

while(1){}

Go to:

Users currently in here
3 Anonymous