Messages posted by: conmale

hvthang wrote:

conmale wrote:

Một cái là "not before", một cái là "not after", có nghĩa là certficate này không giá trị trước ngày 20/03/12 15:14:48 và sau ngày 22/03/13 5:21:33. Hoặc, nó chỉ GIÁ TRỊ trong khoảng thời gian từ 20/03/12 15:14:48 đến 22/03/13 5:21:33.
Có gì đâu mà khó hiểu?

Xài cái này nếu đồng hồ của máy trạm lỗi (sai ngoài khoảng cert có hiệu lực) thì nó cũng sẽ báo lỗi expired.

"Cái này" thì cert nào cũng vậy. Nếu đồng hồ của máy trạm bị lỗi thì chẳng có cách gì fix ngoài việc chính người dùng tự chỉnh cho đúng.

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 ạ

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

quanta wrote:

conmale wrote:

- "Connection is untrusted" với https chỉ khi nào website dùng self-signed certificate hoặc certificate đó hết hạn hoặc certificate đó không match với host/domain name. HVA dùng startssl và CA cert của startssl có trong FF mặc định từ hồi phiên bản 3.x rồi.

Còn lý do nữa anh à . Giờ anh thử xoá certificate của HVA đi rồi thử lại xem, chắc anh cũng sẽ gặp đấy.

Delete certficate của HVA ở đâu em? ở trên máy chủ?

quanta wrote:

@Ky0: từ thông báo trên, nhấp vào "Technical Details" sẽ thấy:

The certificate is not trusted because the issuer certificate has expired.

(Error code: sec_error_expired_issuer_certificate)

- Add Exception
- View Certificate Status
- Details tab
- Chọn www.hvaonline.net trong khung Certificate Hierarchy
- Để ý trường "Not After" bên dưới: quái, 21/3/2013 mới expire mà.

Lý do là gì nhỉ?

Trên khung Certificate Hierarchy, chọn tiếp StartCom Class 1 Primary Intermediate Server CA rồi xem "Not After" bên dưới: expired từ... 22/10/2012 rồi còn đâu:

Một cái là "not before", một cái là "not after", có nghĩa là certficate này không giá trị trước ngày 20/03/12 15:14:48 và sau ngày 22/03/13 5:21:33. Hoặc, nó chỉ GIÁ TRỊ trong khoảng thời gian từ 20/03/12 15:14:48 đến 22/03/13 5:21:33.

Có gì đâu mà khó hiểu?

Ky0 wrote:

conmale wrote:

Đừng có fancy màu mè để phiền.

Cứ vào rồi bấm vào link "forum" hay "portal" để vào. Đừng có thêm thắt https để rồi gặp những trở ngại vô ích. HVA chỉ áp dụng https khi đăng nhập (nếu member muốn đăng nhập xuyên qua https). Cố tình thêm https ngay từ trang bìa sẽ gặp những khó khăn vì http và https là 2 thứ hoàn toàn tách rời.

Em bị tình trạng dùng https trên firefox thì bị báo là "This Connection is Untrusted". Còn dùng Chrome thì lại vào bình thường
Tình trạng bị đẩy vào /null/ cũng thường xuyên bị khi dùng firefox còn Chrome thì lại không bị (Firefox em có dùng NoScript và đặt chế độ allow HVAonline.net)

- "Connection is untrusted" với https chỉ khi nào website dùng self-signed certificate hoặc certificate đó hết hạn hoặc certificate đó không match với host/domain name. HVA dùng startssl và CA cert của startssl có trong FF mặc định từ hồi phiên bản 3.x rồi. Bởi vậy, tình trạng em gặp vì lý do gì anh không hiểu.

- Nếu em dùng Chrome không bị mà dùng FF lại bị thì có cái gì đó không bình thường trên FF của em chớ không phải do HVA.

Nói tóm lại:

1. Điều chỉnh để cho phép trình duyệt được quyền thực thi javascript.

2. Điều chỉnh để cho phép trình duyệt được quyền nhận cookies do HVA set.

3. Đừng táy máy với https. Đối với HVA, https chỉ có giá trị thực thi ở giai đoạn đăng nhập. Cố tình ép trình duyệt sang https để rồi duyệt thì sẽ bị sự cố bởi vì trang không được wwwect và kiểm soát đúng. Nên nhớ: HTTP và HTTPS là 2 thứ HOÀN TOÀN TÁCH BIỆT. Đừng nghĩ rằng đột nhiên mình chuyển từ HTTP sang HTTPS thì mọi thứ cần thiết (như session id, cookies...) đều giá trị và giống nhau.

Đừng có fancy màu mè để phiền.

Cứ vào rồi bấm vào link "forum" hay "portal" để vào. Đừng có thêm thắt https để rồi gặp những trở ngại vô ích. HVA chỉ áp dụng https khi đăng nhập (nếu member muốn đăng nhập xuyên qua https). Cố tình thêm https ngay từ trang bìa sẽ gặp những khó khăn vì http và https là 2 thứ hoàn toàn tách rời.

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?

suxanero wrote:

em sài centos , gõ lệnh uname nó ra như sau:

Code:
uname -a
Linux MCU 2.6.27.21-M1000-MCU-1.0.0 #1 Wed Jan 2 11:20:59 KST 2013 ppc GNU/Linux
uname -m
ppc
giờ em muốn thay đổi từ uname -m từ ppc sang powerpc thì làm thế nào nhỉ? có file nào quy định tên này để chỉnh sửa trực tiếp không ?

nói thêm nữa là em compile lại kernel cho cái này thì trong Makefile , arch em chọn là powerpc chứ không phải ppc >"<

cảm ơn anh chị đã đọc.

Không nên táy máy mấy cái này. Linux chỉ cho phép thay đổi (an toàn) là version. Đổi architecture sai là treo luôn kernel sau khi compile đó.

DNK90 wrote:

mình không xoá gì hết!
chỉ đổi 1 chút trong file index.jsp của ROOT cho nó tự động link thẳng tới trang web của mình, còn nếu ?r=admin thì sẽ chuyển qua trang ROOT
có vậy hà

Nên XOÁ HẾT tất cả trong thư mục "webapps".

Đọc cái này: https://www.owasp.org/index.php/Securing_tomcat

DNK90 wrote:

chào mọi người,

Số là dạo gần đây server của mình hay bị cài vào nhiều webapp lạ, toàn tiếng tàu (jFoler 0.9)
Nên mình đăng bài lên đây muốn hỏi làm sao để bảo mật trong server Tomcat (mình đang làm việc với tomcat 6.0).
Mong mọi người giúp đỡ

Làm sao mà ai đó "cài" vào nhiều webapp lạ được? Ai có quyền kiểm soát tomcat của bồ? Tomcat của bồ có tháo bỏ mấy webapp mặc định (như ROOT, Admin...) hay không?

xmas - new year 2013

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

Lỗi này khiến cho vô khổi em bị thuổng mật khẩu và những thứ khác:

http://nakedsecurity.sophos.com/2012/10/08/skype-worm-spreads/

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

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":
Forum |
Portal

mà xuống dưới lại chường cái này ra:
<td width="50%" align="center" valign="middle">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<a href="/"></a> </td>

smilie

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:

Forum | Portal

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

Xuất sắc!

Tiếp tục đi em smilie

.

Britain risking national security by dealings with Huawei, says ex MoD man

http://www.telegraph.co.uk/news/politics/9625525/Britain-risking-national-security-by-dealings-with-Huawei-says-ex-MoD-man.html

Mỹ và Úc đã ban Huawei. Canada cũng đang nối gót.

m3ty_rud wrote:

Em đang tìm hiểu để biết thêm về Bảo mật. Mong các anh giúp đỡ nhìu nhìu..
Theo em được biết thì bảo mật Web có 2 dạng là Web App và Web Service. Các anh có thể giúp em phân biệt 2 dạng đó không?
Em đọc trên mạng thấy nhiều thông tin về các phương pháp tấn công nhưng em khó phân biệt đâu là phương pháp tấn công cho Web app, đâu là phương pháp cho Web Service. Và càng khó để phân biệt nó tấn công vào tầng nào của mô hình OSI.
Nhờ các anh giúp đỡ thêm thông tin để em có thể tiếp tục tìm hiểu kỹ hơn về vấn đề này!

Có 2 loại:

- Web service dùng để chạy web app, ví dụ Apache là "web service" dùng để chạy một trang web.

- Trang web kia lại cung cấp một loại dịch vụ nào đó và cũng được gọi là "web service".

Một cái "web service" tạo nền tảng cho sự tồn tại của trang web, một cái "web service" khác cung cấp dịch vụ khi trang web kia đã hoạt động.

thaianh_k44 wrote:

Các pro cho mình hỏi có cách nào để mình chạy 1 chương trình viết bằng perl gồm
dữ liệu đưa vào 1 chương trình java tớ muốn lấy dữ liệu ra của chương trình java đó làm dữ liệu vào của chương trình viết bằng perl thì có cách nào không?
help.
cảm ơn nhiều.

Không hiểu bồ muốn nói cái gì nữa.

Bồ thử trình bày lại ý muốn của bồ, chấm phẩy cho rõ ràng xem sao?

Xem kỹ lại thì thấy 10.0.0.13 có source port toàn là 3389. Có thể server này có cung cấp (mở) RDP service và thằng ông nội 10.0.0.66 khởi điểm connects đến cổng 3389 của máy 10.0.0.13.

Có thể đây là một dạng exploit dùng tool như metasploit chẳng hạn.

Dạng này hơi lạ. Toàn là Transport Protocol Data Unit Packet (TPKT) packets. Xem như một dạng packets sử dụng cho VoIP. Không thấy dấu hiệu bị DDoS dựa theo tính chất của TPKT packets ở đây vì packet fields, packet size không có gì bất thường.

Chắc chắn không phải DrDoS vì không thấy hàng loạt ACK packets.

Xem thử trên máy chủ có xài cái gì đụng với VoIP không? Nếu có, coi chừng software đó bị bug.

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.

ga_cum06 wrote:

ngày 01/09/2012 tôi có đăng 1 topic thông báo về việc có nhiều tên miền .vn bị hack. không biết là do lỗi db của hva hay bị ban quản trị xoá vì vi phạm điều luật nào đó. xin có lời giải thích từ ban quản trị .

Phải nó ở đây không?

/hvaonline/posts/list/43298.html

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

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [535:219222]

Nguyên nhân nằm ở màu đỏ.