banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thảo luận mạng và thiết bị mạng Xin trợ giúp về module ASM của thiết bị firewall F5 Big-IP  XML
  [Question]   Xin trợ giúp về module ASM của thiết bị firewall F5 Big-IP 04/01/2013 09:54:54 (+0700) | #1 | 272415
[Avatar]
docphongm41
Member

[Minus]    0    [Plus]
Joined: 02/03/2008 23:47:04
Messages: 10
Offline
[Profile] [PM]
Hi all.
Mình đang cấu hình module ASM của thiết bị F5 BigIP bên phía khách hàng. ASM là một WAF đi kèm theo firewall này. Trong quá trình cấu hình, định kỳ phải gửi các bản scan security hole về cho khách hàng.

Trên ASM, các cấu hình hiện thời đã chặn được các request có dấu hiệu thăm dò XSS, kết quả trả về có dạng sau, là thông điệp cảnh báo của ASM
Code:
<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: 12589574903111794332</body></html>


Tuy nhiên, response trả về sẽ là một tcp RST và Acunetix 8.0 nhận được response header như sau:
Code:
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Pragma: no-cache
Content-Length: 189

Mình nghĩ, với các HTTP code 200 như trên là lý do Acunetix vẫn cho rằng, request fuzzing nó gửi đi thành công và có thể exploit được, do đó trong kết quả nó vẫn liệt kê đó là một sec hole.

Trong báo cáo thì mình muốn nó "sạch", tức là không có report "nhầm" như đề cập ở trên. Các anh/chị hay bạn nào có kinh nghiệm làm việc với F5-ASM thì cho mình chỉ dẫn khắc phục với.
Có thể cấu hình chỉnh sửa HTTP response thành 403 hay không?
Nếu không, có thể drop cái response này không ?
Nếu vẫn không, thì còn có giải pháp nào khác ?

Xin cảm ơn mọi người.
Perfection of sounds is the silence
[Up] [Print Copy]
  [Question]   Xin trợ giúp về module ASM của thiết bị firewall F5 Big-IP 04/01/2013 11:54:05 (+0700) | #2 | 272424
[Avatar]
conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
[Profile] [PM]
Tớ hơi thắc mắc vài điểm.

1. Detect XSS là detect inbound requests thì sao lại xét đến response?

2. Nếu "response trả về sẽ là một tcp RST" thì hơi khó hiểu vì RST là một packet ở IP level thì làm sao lại hình thành được cái response với status 200?


Bồ thử trình bày chi tiết hơn xem sao?
What bringing us together is stronger than what pulling us apart.
[Up] [Print Copy]
  [Question]   Xin trợ giúp về module ASM của thiết bị firewall F5 Big-IP 05/01/2013 13:53:33 (+0700) | #3 | 272467
[Avatar]
docphongm41
Member

[Minus]    0    [Plus]
Joined: 02/03/2008 23:47:04
Messages: 10
Offline
[Profile] [PM]
Hi anh conmale.
Anh thông cảm vì em mô tả hơi vắn tắt ạ.
1. Việc detect XSS được thực hiện bởi các attack-signatures (tương tự như các tập SecRule của ModSecurity). Hiện tại, các attack-signature này hoạt động đúng, tức là phát hiện và chặn được các inbound request, không tới được web server. Thay vào đó sẽ trả về một response page có nội dung như post đầu tiên em trình bày.
Như vậy, em kết luận một cách chủ quan đó là việc chặn các fuzzing request được thực hiện thành công.

Tuy nhiên, với mục tiêu sử dụng Acunetix để có report cho các thủ tục bảo hành/bảo trì thì đòi hỏi tool đó phải không ghi nhận các kết quả alert ở mức High.

Với những request của tool này, em đã từng dùng ModSecurity (cho website khác) thực hiện cản với việc trả về mã 403 Forbidden thì Acunetix nó ghi nhận là test case đó fail, tức là không có lỗi tiềm ẩn ở đó. Tuy nhiên, với việc BigIP ASM trả về thông điệp 200 OK như trên thì Acunetix vẫn xem đó là lỗi.

Trên đây là suy luận của em, còn không có tài liệu nào công khai nói về cách thức Acunetix đánh giá với response như thế nào thì coi là có lỗi bảo mật.

2. Em đã không đọc kỹ và ghi chú lại cái tài liệu đã đọc nên cũng không trình bày lại được về nội dung này. Còn đúng là với trình bày của em ở post 1 thì đúng là vô lý, khi rst đã gửi mà vẫn gửi lại được một http message. Về đoạn trình bày liên quan này em xin anh và mọi người bỏ qua ạ.
Perfection of sounds is the silence
[Up] [Print Copy]
  [Question]   Xin trợ giúp về module ASM của thiết bị firewall F5 Big-IP 08/01/2013 08:45:15 (+0700) | #4 | 272522
[Avatar]
docphongm41
Member

[Minus]    0    [Plus]
Joined: 02/03/2008 23:47:04
Messages: 10
Offline
[Profile] [PM]

conmale wrote:
Tớ hơi thắc mắc vài điểm.

2. Nếu "response trả về sẽ là một tcp RST" thì hơi khó hiểu vì RST là một packet ở IP level thì làm sao lại hình thành được cái response với status 200?

 

Trong response trên, như bác đã thấy, connection: close. Do đó rõ ràng là ASM đã notify rằng kết nối tcp sẽ được đóng ngay khi response này hoàn thành. Như vậy có lẽ là sau khi ASM gửi lại http response trên, firewall sẽ gửi tiếp một tcp RST để ngắt kết nối của client hiện tại này.
Lập luận của em có bị sai không ạ smilie
Perfection of sounds is the silence
[Up] [Print Copy]
  [Question]   Xin trợ giúp về module ASM của thiết bị firewall F5 Big-IP 08/01/2013 12:53:20 (+0700) | #5 | 272527
[Avatar]
conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
[Profile] [PM]

docphongm41 wrote:

conmale wrote:
Tớ hơi thắc mắc vài điểm.

2. Nếu "response trả về sẽ là một tcp RST" thì hơi khó hiểu vì RST là một packet ở IP level thì làm sao lại hình thành được cái response với status 200?

 

Trong response trên, như bác đã thấy, connection: close. Do đó rõ ràng là ASM đã notify rằng kết nối tcp sẽ được đóng ngay khi response này hoàn thành. Như vậy có lẽ là sau khi ASM gửi lại http response trên, firewall sẽ gửi tiếp một tcp RST để ngắt kết nối của client hiện tại này.
Lập luận của em có bị sai không ạ smilie  


Đã gởi một response 200 rồi thì sau khi client nhận được thông điệp thì 2 đầu connnection đóng (bằng FIN) một cách hợp lệ. Lúc đó có gởi thêm RST cũng chẳng để làm gì. Thực sự, gởi RST khơi khơi như vậy bị rơi vào "INVALID" state và client cũng chẳng nhận được.

Còn với comment trên của em thì có 2 chuyện:

1. ASM của thiết bị firewall F5 Big-IP gởi một cái response 200 khi detect XSS.
2. Acunetix dự phỏng nhận 403.

Không may, hai cái trên không liên quan gì nhau và cũng chẳng tích hợp gì với nhau cho nên khó lòng mà thay đổi "thái độ" của một trong hai để thoả mãn cả hai. Nếu muốn dùng một công cụ ngoại biên như Acunetix để đánh giá tính bảo mật trong trường hợp này thì kẹt vì nó chẳng còn ý nghĩa "vulnerability detection" vì ASM đã làm chuyện này rồi. Cách tốt nhất là thu thập kết quả từ chính ASM cho mục đích report.
What bringing us together is stronger than what pulling us apart.
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|