Chống lại Denial of Service Attacks

Phần này đề cập đến kiểu tấn công SYN

- Attacker gởi packet SYN để tạo kết nối
- Máy bên trong mạng (Victim) gởi SYN-ACK và tạo buffer để chờ Attacker gởi dữ liệu
- Attacker không trả lời nữa, mà mở 1 kết nối SYN
Cứ như vậy Attacker sẽ mở rất nhiều kết nối với chỉ 1 packet SYN, làm cho Victim hết bộ nhớ và treo.

Các bạn sử dụng chức năng TCP Intercept để tránh tình trạng này. TCP Intercept có 2 mode:
- Intercept mode: nếu Attacker gởi packet SYN thì router rìa sẽ giữ packet này lại trả lời hộ. Nếu Attacker trả lời thì đây không phải là attacker, lúc này router gởi packet SYN cho máy bên trong vẫn chưa muộn, và dĩ nhiên cần giữ lại packet đầu tiên mà bên trong trả lời.
Còn ngược, Attacker không nói kô rằng thì rõ ràng không nên tiếp tục chơi với nó nữa, ghi nhớ IP này để deny nó.

- Monitor mode: nếu Attacker gởi packet SYN thì router rìa vẫn chuyển cho Victim, nhưng theo dõi kết nối này. Nếu nhận thấy Attacker không trả lời mà lại có nhiều kết nối khác được mở giống như vậy nữa thì router biết rằng máy bên trong đang bị tấn công DoS SYN Attack, nó sẽ ngừng ngay các packet tiếp theo.

Sau đây là ví dụ về việc bảo vệ server 172.16.10.25 khỏi SYN Attack

Code:
NTCRouter#config t
NTCRouter(config)#access-list 151 permit tcp any host 172.16.10.25
NTCRouter(config)#ip tcp intercept list 151
NTCRouter(config)#ip tcp intercept mode intercept
NTCRouter(config)#^Z
NTCRouter# 

Hiện server mình đang bị tấn công SYN FLOOD nặng nề.

Cụ thể như sau :

BOTNET mà attacker dùng để tấn công ~400 Mbps (chia là 200 Mbps mỗi server, 2 server)

Lưu lượng : ~ 200 000 packets/s

Server sử dụng hệ điều hành win server 2k3 sp2, máy ảo sử dụng Linux RH4.

Có sử dụng các rule chống SYN Flood cho iptables ở Linux, nhưng nó không hiệu quả do lượng packets quá nhiều --> cpu tăng cao khi bị tấn công (70-90%), máy ảo hoàn toàn tê liệt.


Attacker sau khi tấn công máy ảo, liền tấn công tiếp vào máy thật, ở máy thật tuy không die, nhưng rất khó khăn chấp nhận kết nối mới và đôi lúc hầu như là không thể.

Không biết còn cách nào có thể chống được SYN FLOOD với lượng lớn như thế này không ?
Mong các bạn giúp đỡ ! 

Bạn vui lòng cho biết mô hình mạng của bạn!
Nếu theo như thông tin màu đỏ ở trên thì các gói tin sẽ đi từ máy ảo vào máy thật?

- Ky0 - 

Hiện server mình đang bị tấn công SYN FLOOD nặng nề.

Cụ thể như sau :

BOTNET mà attacker dùng để tấn công ~400 Mbps (chia là 200 Mbps mỗi server, 2 server)

Lưu lượng : ~ 200 000 packets/s

Server sử dụng hệ điều hành win server 2k3 sp2, máy ảo sử dụng Linux RH4.

Có sử dụng các rule chống SYN Flood cho iptables ở Linux, nhưng nó không hiệu quả do lượng packets quá nhiều --> cpu tăng cao khi bị tấn công (70-90%), máy ảo hoàn toàn tê liệt.

Có thử liên hệ IDC giúp đỡ. Nhưng nếu cấu hình router theo thiết lập dưới đây (sưu tầm trên mạng) thì router die sau 2'

Chống lại Denial of Service Attacks

Phần này đề cập đến kiểu tấn công SYN

- Attacker gởi packet SYN để tạo kết nối
- Máy bên trong mạng (Victim) gởi SYN-ACK và tạo buffer để chờ Attacker gởi dữ liệu
- Attacker không trả lời nữa, mà mở 1 kết nối SYN
Cứ như vậy Attacker sẽ mở rất nhiều kết nối với chỉ 1 packet SYN, làm cho Victim hết bộ nhớ và treo.

Các bạn sử dụng chức năng TCP Intercept để tránh tình trạng này. TCP Intercept có 2 mode:
- Intercept mode: nếu Attacker gởi packet SYN thì router rìa sẽ giữ packet này lại trả lời hộ. Nếu Attacker trả lời thì đây không phải là attacker, lúc này router gởi packet SYN cho máy bên trong vẫn chưa muộn, và dĩ nhiên cần giữ lại packet đầu tiên mà bên trong trả lời.
Còn ngược, Attacker không nói kô rằng thì rõ ràng không nên tiếp tục chơi với nó nữa, ghi nhớ IP này để deny nó.

- Monitor mode: nếu Attacker gởi packet SYN thì router rìa vẫn chuyển cho Victim, nhưng theo dõi kết nối này. Nếu nhận thấy Attacker không trả lời mà lại có nhiều kết nối khác được mở giống như vậy nữa thì router biết rằng máy bên trong đang bị tấn công DoS SYN Attack, nó sẽ ngừng ngay các packet tiếp theo.

Sau đây là ví dụ về việc bảo vệ server 172.16.10.25 khỏi SYN Attack

Code:
NTCRouter#config t
NTCRouter(config)#access-list 151 permit tcp any host 172.16.10.25
NTCRouter(config)#ip tcp intercept list 151
NTCRouter(config)#ip tcp intercept mode intercept
NTCRouter(config)#^Z
NTCRouter# 

Attacker sau khi tấn công máy ảo, liền tấn công tiếp vào máy thật, ở máy thật tuy không die, nhưng rất khó khăn chấp nhận kết nối mới và đôi lúc hầu như là không thể.

Không biết còn cách nào có thể chống được SYN FLOOD với lượng lớn như thế này không ?
Mong các bạn giúp đỡ ! 

# Limit the number of incoming tcp connections
# Interface 0 incoming syn-flood protection
iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -p tcp ! --syn -m state --state NEW -j DROP
iptables -A syn_flood -j DROP

* Tiêp theo bạn bạn đến đường dẫn sau : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters
* Đến đây các bạn tạo các giá trị sau :

* DWORD với tên là "SynAttackProtect" và giá trị là 2
* DWORD với tên là "TcpMaxHalfOpen" và giá trị là 100
* DWORD với tên là "TcpMaxHalfOpenRetried" và giá trị là 80
* DWORD với tên là "TcpMaxPortsExhausted" và giá trị là 5
* DWORD với tên là "TcpMaxConnectResponseRetransmissions" và giá trị là 3 

Cám ơn các bạn đã trả lời.

Mình xin nói thêm trường hợp bị tấn công của mình:

- Dịch vụ mình chạy trên máy ảo. VMW được thiết lập dạng Bridge với máy thật. Khi bị tấn công, thì không quá 1s --> máy ảo die.
Trên máy ảo có cấu hình iptables đoạn như sau : (và có kích hoạt kết nối cơ chế syn cookies)

Code:

# Limit the number of incoming tcp connections
# Interface 0 incoming syn-flood protection
iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -p tcp ! --syn -m state --state NEW -j DROP
iptables -A syn_flood -j DROP

Đoạn code trên tác dụng rất tốt khi trước kia attacker tấn công (Lúc đó attacker tấn công với lượng ít hoặc chỉ dùng duy nhất gói SYN như anh conmale nói)

- Sau khi bị tấn công, do muốn tiếp tục duy trì dịch vụ, nên mình mới chuyển sang thiết lập kết nối dạng NAT giữa máy ảo và thật (nếu không bị tấn công thì mình không dùng dạng này)

Ở trên window có cấu hình một số khoá (sưu tầm trên mạng)

* Tiêp theo bạn bạn đến đường dẫn sau : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters
* Đến đây các bạn tạo các giá trị sau :

* DWORD với tên là "SynAttackProtect" và giá trị là 2
* DWORD với tên là "TcpMaxHalfOpen" và giá trị là 100
* DWORD với tên là "TcpMaxHalfOpenRetried" và giá trị là 80
* DWORD với tên là "TcpMaxPortsExhausted" và giá trị là 5
* DWORD với tên là "TcpMaxConnectResponseRetransmissions" và giá trị là 3 

Với lượng syn flood <100 Mbps thì window vẫn còn nhận kết nối tạm được.
Nhưng hiện tại với lượng lớn như đã nói, thì 100 lần kết nối thì khả năng thành công <1

Không biết với lượng tấn công lớn như vậy thì ta có thể dùng cách nào giảm bớt không ?
Và đó là cách gì ?
Nếu nhờ IDC để giúp đỡ thì nên cấu hình như thế nào ở router ? (đã có nhờ họ, nhưng khi áp dụng rule ở trên mình đã viết thì die router luôn...)
Ở window hay Linux có cấu hình hay cài thêm gì để giảm thiểu tác hại của SYN FLOOD ? 

nên tạo một con Linux server vừa làm firewall, vừa làm reverse proxy đứng trước con web server chạy trên Linux. Con Linux làm firewall phải optimise 100% từ kernel đi lên trên tận reverse proxy level. Cụ thể thế nào thì đó sẽ là một bài viết rất dài. 

Hiện server mình đang bị tấn công SYN FLOOD nặng nề.

Cụ thể như sau :

BOTNET mà attacker dùng để tấn công ~400 Mbps (chia là 200 Mbps mỗi server, 2 server)

Lưu lượng : ~ 200 000 packets/s
 

- Đây không phải syn flood, mà chỉ là gửi thật nhiều request đến app server thôi. Dùng hết 400 Mbps là chiều vào hay ra? Mình đoán là vào thì ít, nhưng máy chủ trả lời ra thì nhiều.
 

- Dùng iptables để giới hạn số conn là cách hiệu quả...
- Bạn chưa tìm hiểu lí do server (ảo, chạy RH4) chết là do đâu? Mình nghĩ không phải do iptables, chỉ đơn giản là do app server không chịu nổi thôi. Chắc khi thiết lập xong cái firewall riêng sẽ rõ ngay.
 

Theo tớ, việc đầu tiên là chạy con server Linux chính hiệu chớ không phải là máy ảo và nếu cần, nên tạo một con Linux server vừa làm firewall, vừa làm reverse proxy đứng trước con web server chạy trên Linux. Con Linux làm firewall phải optimise 100% từ kernel đi lên trên tận reverse proxy level
 

- Ngoài lề tí: app server chạy trên nền tảng ảo hoá là bình thường, mình chưa thấy ai nói là chạy trên máy ảo thì overhead cao (trừ khi chạy mấy giải pháp ảo hoá linh tinh trên desktop, không phải dành riêng cho server).
 

jcisio wrote:

- Đây không phải syn flood, mà chỉ là gửi thật nhiều request đến app server thôi. Dùng hết 400 Mbps là chiều vào hay ra? Mình đoán là vào thì ít, nhưng máy chủ trả lời ra thì nhiều.
 

Mình thấy đoạn màu đỏ với màu cam mâu thuẫn với nhau quá!
 

jcisio wrote:

- Dùng iptables để giới hạn số conn là cách hiệu quả...
- Bạn chưa tìm hiểu lí do server (ảo, chạy RH4) chết là do đâu? Mình nghĩ không phải do iptables, chỉ đơn giản là do app server không chịu nổi thôi. Chắc khi thiết lập xong cái firewall riêng sẽ rõ ngay.
 

Đoạn này đúng! Lý do mọi người đã trình bày ở trên: Server chịu đòn trước khi đến được iptables trên máy ảo! 

jcisio wrote:

- Ngoài lề tí: app server chạy trên nền tảng ảo hoá là bình thường, mình chưa thấy ai nói là chạy trên máy ảo thì overhead cao (trừ khi chạy mấy giải pháp ảo hoá linh tinh trên desktop, không phải dành riêng cho server).
 

Điều này không đúng cho trường hợp của bạn huuduyen
 

Của họ..... (tức là ảnh hưởng hết tất cẩ các server thuê đặt ở đó, trong đó có server của mình)

- Bị die 10' (attacker tấn công 10' kiểu như là cảnh báo) .... 

huuduyen wrote:

Của họ..... (tức là ảnh hưởng hết tất cẩ các server thuê đặt ở đó, trong đó có server của mình)

- Bị die 10' (attacker tấn công 10' kiểu như là cảnh báo) .... 

Chà bị đánh đến bão hoà đường truyền luôn , việc này chứng tỏ có sự giới hạn trong khả năng cung cấp dịch vụ của nhà cung cấp dịch vụ của bồ, họ khá chậm chạp trong việc khác phục tình hình. Các thành phần liên quan tới cơ sở hạ tầng mạng ta đều phải dựa nhiều và nhà cung cấp dịch vụ 

xnohat wrote:

huuduyen wrote:

Của họ..... (tức là ảnh hưởng hết tất cẩ các server thuê đặt ở đó, trong đó có server của mình)

- Bị die 10' (attacker tấn công 10' kiểu như là cảnh báo) .... 

Chà bị đánh đến bão hoà đường truyền luôn , việc này chứng tỏ có sự giới hạn trong khả năng cung cấp dịch vụ của nhà cung cấp dịch vụ của bồ, họ khá chậm chạp trong việc khác phục tình hình. Các thành phần liên quan tới cơ sở hạ tầng mạng ta đều phải dựa nhiều và nhà cung cấp dịch vụ 

Do vậy, nên giờ bị đánh là họ block hết traffic vào IP máy server mình luôn...Chắc vì lý do an toàn cho cả hệ thống nên họ làm vậy...

Hic, giờ đến đâu hay đến đó vậy... Attacker đánh thì chờ nó chán rồi nghỉ chứ biết sao giờ...

Bản thân của window cũng bị giới hạn khi xử lý số lượng lớn packets đó. Config kiểu gì thì việc chấp nhận kết nối mới cũng diễn ra rất khó khăn.

Do không rành về Linux nên cũng chả biết chỉnh gì ngoài việc thử mở cơ chế kết nối syn cookies

Có nhờ IDC giúp đỡ....nhưng thấy không khả quan với lượng BOTNET lớn như vậy.

Không biết có bạn nào biết loại firewall cứng nào có thể chống được lượng BOTNET ~400 ~500 Mbps như đã nói ở trên không ?
 

Nếu được, bồ thử chạy tcpdump trên linux server đó và gởi nó lên một site nào đó rồi PM tớ để cho cái link download:

tcpdump -i eth0 -s0 -w dump

Chỉ capture chứng 60 giây là đủ. Sau đó nhấn ctl-D để ngắt chớ không thì file "dump" có kích thước quá lớn. eth0 giả định là external interface của linux server đó.  

uh, cám ơn bạn đã trả lời
Nhưng dịch vụ của mìinh chạy là server game...

Trước kia đánh chủ yếu là UDP Flood giờ thì SYN flood

Nếu được, bồ thử chạy tcpdump trên linux server đó và gởi nó lên một site nào đó rồi PM tớ để cho cái link download:

tcpdump -i eth0 -s0 -w dump

Chỉ capture chứng 60 giây là đủ. Sau đó nhấn ctl-D để ngắt chớ không thì file "dump" có kích thước quá lớn. eth0 giả định là external interface của linux server đó.  

Mình có chụp bằng wireshark trên window không biết có được không ? 

ok, để mình chụp dạng tcpdump rồi gửi lên. Hiện tại phía IDC block hết traffic vào server mình rồi

tcpdump không biết nó sao, chứ mình dùng wireshark vừa bật lên là nó đơ luôn (do packets quá nhiều)
Cố gắng click stop sau 5s, sau khi click thì wireshark crash luôn..

Phải dùng tính năng auto stop sau xx MB mới chụp được 

Sau mấy ngày ngừng tấn công, đến hôm nay thì bị đánh tiếp.

Link file dump trong 10s : http://up.4share.vn/f/3f0e0b0f0d08090d/dump.rar.file (unrar 45MB)

 

net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 2
net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_mem = 786432 1048576 1572864
net.ipv4.tcp_rmem = 4096        87380   1048576
net.ipv4.tcp_wmem = 4096        16384   1048576
net.ipv4.tcp_max_orphans = 2048

iptables -N syn
iptables -A syn -j ACCEPT
iptables -N SYN_CHECK
iptables -A SYN_CHECK -m recent --set --name SYN
iptables -A INPUT -p tcp --syn -d $IP -m state --state NEW -j SYN_CHECK

iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j LOG --log-prefix "FLOOD: "
iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j DROP

iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 3 --name SYN -j syn
iptables -A INPUT -p tcp ! --syn -d $IP -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s $IP -m state --state ESTABLISHED -j ACCEPT

iptables -t mangle -N blockip
iptables -t mangle -A blockip -j DROP
iptables -t mangle -A PREROUTING -p tcp -d $IP -m recent --name SYN --update --seconds 120 -j blockip

Thanks anh commale. Hiện server đang die.... chả làm gì được. Đành phải chờ attacker ngừng tấn công rồi thử cách này.