SYN ATTACK và cách khắc phục ?

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

SYN ATTACK và cách khắc phục ?

[Question] SYN ATTACK và cách khắc phục ?	29/11/2009 09:04:23 (+0700) \| #1 \| 199404

abcd8035
Member

Joined: 15/07/2007 22:14:45
Messages: 10
Location: Nha Trang
Offline

Chào các anh,
Theo nhận định của em, trong vòng vài ngày qua em bị syn attack khiến web không thể chạy được.
VPS dùng Linux CentOS5
Kernel and CPU Linux 2.6.18-164.el5xen on i686
Latest Apache & MySQL
Dùng CSF và Ibtables làm firewall

Một số biểu hiện khi bị "đơ"
CPU load rất cao
Ram sử dụng cạn

Code:

netstat -nap |grep SYN
 0 112.78.8.7:80               79.135.146.30:2394          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2372          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2397          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2393          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2380          SYN_RECV
 0 112.78.8.7:80               84.237.142.11:9769          SYN_RECV
 0 112.78.8.7:80               84.237.142.11:9843          SYN_RECV

Code:

netstat -nap |grep SYN
 0 112.78.8.7:80               79.135.146.30:2394          SYN_SENT 3384/smtp
 0 112.78.8.7:80               79.135.146.30:2372          SYN_SENT 10455/httpd

Vui lòng hướng dẫn em các rule cho iptables để VPS "sống" yên ổn ạ.
Cảm ơn các anh !

[Question] SYN ATTACK và cách khắc phục ?	29/11/2009 09:50:10 (+0700) \| #2 \| 199410

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

SYN Attack ko làm gì nổi CentOS đâu.
Nhưng mở nhiều kết nối và tạo request để làm lụt web server thì có thể, và ứng dụng web của bạn quá tải rồi, nên nó mới ăn RAM/CPU. Xử lý ko kịp mà lượng kết nối về vẫn tăng lên nên SYNC_RECV nhiều như thế.
Bạn thử gõ lệnh:
netstat -ntp | grep ESTA | grep httpd | wc -l
xem ra bao nhiêu?
Bạn nên tuning lại ứng dụng web, có thể giảm bớt số concurrent session trong httpd để tài nguyên ko bị cạn, tuning lại mysql (nếu có sử dụng), giảm time out của httpd, giảm thời gian chờ giữa 2 keep-alive request (nếu keep-alive on).
Một cách khắc phục thêm nữa nếu cái trên chưa ổn, cài fail2ban, monitor apache access log. Nếu 1 IP nào đó request quá 50 lần trong 10 giây chẳng hạn, thì ban nó 5 phút. Tất nhiên fail2ban sẽ tốn CPU/RAM nhưng dù sao nó sẽ đỡ cho bạn khá tốt.

[Question] SYN ATTACK và cách khắc phục ?	30/11/2009 02:30:55 (+0700) \| #3 \| 199432

conmale
Administrator

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

myquartz wrote:

SYN Attack ko làm gì nổi CentOS đâu.
Nhưng mở nhiều kết nối và tạo request để làm lụt web server thì có thể, và ứng dụng web của bạn quá tải rồi, nên nó mới ăn RAM/CPU. Xử lý ko kịp mà lượng kết nối về vẫn tăng lên nên SYNC_RECV nhiều như thế.
Bạn thử gõ lệnh:
netstat -ntp | grep ESTA | grep httpd | wc -l
xem ra bao nhiêu?
Bạn nên tuning lại ứng dụng web, có thể giảm bớt số concurrent session trong httpd để tài nguyên ko bị cạn, tuning lại mysql (nếu có sử dụng), giảm time out của httpd, giảm thời gian chờ giữa 2 keep-alive request (nếu keep-alive on).
Một cách khắc phục thêm nữa nếu cái trên chưa ổn, cài fail2ban, monitor apache access log. Nếu 1 IP nào đó request quá 50 lần trong 10 giây chẳng hạn, thì ban nó 5 phút. Tất nhiên fail2ban sẽ tốn CPU/RAM nhưng dù sao nó sẽ đỡ cho bạn khá tốt.

Hì hì, em chưa đụng "hàng" đó thôi. SYN attack cỡ chừng một chục ngàn cái / 1 giây trở lên thì chết điếng chớ đừng có nói là không làm được gì đâu.

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

[Question] SYN ATTACK và cách khắc phục ?	30/11/2009 03:26:10 (+0700) \| #4 \| 199434

abcd8035
Member

Joined: 15/07/2007 22:14:45
Messages: 10
Location: Nha Trang
Offline

Code:

[root@server ~]# netstat -nap |grep SYN |wc -l
1036

Mình không biết rõ phải tuning thế nào nữa, nhưng làm theo cách bạn nói không có kết quả. Con số mình dính chưởng rất lớn, có khi là 1500 hoăc 2000 chứ không phải 1036. Lượng IP rất lớn như vậy tràn vào theo cấp số nhân. Những lúc đó mình vẫn đăng nhập vào được SSH và vẫn control được webmin, nhưng các ứng dụng truy xuất đến mysql đều teo.

Mình chưa cài fail2ban.
Keep Alive = On
Tunning Mysql thì mình đang tìm tài liệu nghiên cứu xem.
Nhưng mình nghĩ chỉ có con đường cản truy xuất vào Mysql thì mới có thể "pass". Đặc biệt là mỗi khi "bão" đến thì CPU Load Average luôn là:
100, 90, 50

Vẫn chưa làm được, hằng ngày vẫn phải block IP nước ngoài và nghiên "cú" smilie

(

[Question] SYN ATTACK và cách khắc phục ?	30/11/2009 07:21:46 (+0700) \| #5 \| 199436

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

conmale wrote:

Hì hì, em chưa đụng "hàng" đó thôi. SYN attack cỡ chừng một chục ngàn cái / 1 giây trở lên thì chết điếng chớ đừng có nói là không làm được gì đâu.

Cỡ đó em đụng rồi. Nhưng lúc đó, trừ cái backlog full làm cho web server chậm rì, nhưng các client vẫn có thể kết nối và dùng được, dù chậm. Có lẽ do Syn cookie bật sẵn + keep-alive của httpd hay sao đó (lọt 1 connection là cho cả 100 request liền).

@abcd: bạn cài fail2ban đi, nó sẽ giúp bạn hàng ngày không phải chặn, giảm tải cho các query kiểu đó.
Vấn đề mysql của bạn quá tải, việc này các web server từng bị tấn công DoS đều gặp phải. Nếu bạn chạy Joomla hoặc 1 cái tương tự (cái web app mà 1 HTTP request sinh ra vài chục mysql query ấy), thì chắc chắn mysqld của bạn đơ ra là phải.
Phải tìm cách giảm 1 HTTP request chỉ sinh ra 10 query thôi, tắt hết statistics, các tính năng phụ...
Vài tốt nhất, triệt để nhất, thuê 1 ng viết lại cái web app đó, sao cho nó ăn ít resource, hiệu quả hơn.
Vậy thôi.

[Question] SYN ATTACK và cách khắc phục ?	07/12/2009 15:32:07 (+0700) \| #6 \| 200002

Phó Hồng Tuyết
Member

Joined: 20/04/2007 20:02:10
Messages: 275
Location: Nơi Sâu Thẳm Tâm Hồn
Offline

abcd8035 wrote:

Chào các anh,
Theo nhận định của em, trong vòng vài ngày qua em bị syn attack khiến web không thể chạy được.
VPS dùng Linux CentOS5
Kernel and CPU Linux 2.6.18-164.el5xen on i686
Latest Apache & MySQL
Dùng CSF và Ibtables làm firewall

Một số biểu hiện khi bị "đơ"
CPU load rất cao
Ram sử dụng cạn

Code:
netstat -nap |grep SYN
 0 112.78.8.7:80               79.135.146.30:2394          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2372          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2397          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2393          SYN_RECV
 0 112.78.8.7:80               79.135.146.30:2380          SYN_RECV
 0 112.78.8.7:80               84.237.142.11:9769          SYN_RECV
 0 112.78.8.7:80               84.237.142.11:9843          SYN_RECV
Code:
netstat -nap |grep SYN
 0 112.78.8.7:80               79.135.146.30:2394          SYN_SENT 3384/smtp
 0 112.78.8.7:80               79.135.146.30:2372          SYN_SENT 10455/httpd
Vui lòng hướng dẫn em các rule cho iptables để VPS "sống" yên ổn ạ.
Cảm ơn các anh !

CSF hỗ trợ rất tốt nếu bị flood như của bạn.
Bạn nên xem kỹ lại cfs đi sẽ có nhiều thứ để học hỏi lắm.
Nên đọc kỹ files hướng dẫn nhé
Code:

http://www.configserver.com/free/csf/readme.txt

Thân.

"Một người thành công không có ý nghĩ đổ thừa thất bại do ...."

[Question] SYN ATTACK và cách khắc phục ?	07/12/2009 15:49:44 (+0700) \| #7 \| 200007

conmale
Administrator

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

myquartz wrote:

conmale wrote:

Hì hì, em chưa đụng "hàng" đó thôi. SYN attack cỡ chừng một chục ngàn cái / 1 giây trở lên thì chết điếng chớ đừng có nói là không làm được gì đâu.

Cỡ đó em đụng rồi. Nhưng lúc đó, trừ cái backlog full làm cho web server chậm rì, nhưng các client vẫn có thể kết nối và dùng được, dù chậm. Có lẽ do Syn cookie bật sẵn + keep-alive của httpd hay sao đó (lọt 1 connection là cho cả 100 request liền).

@abcd: bạn cài fail2ban đi, nó sẽ giúp bạn hàng ngày không phải chặn, giảm tải cho các query kiểu đó.
Vấn đề mysql của bạn quá tải, việc này các web server từng bị tấn công DoS đều gặp phải. Nếu bạn chạy Joomla hoặc 1 cái tương tự (cái web app mà 1 HTTP request sinh ra vài chục mysql query ấy), thì chắc chắn mysqld của bạn đơ ra là phải.
Phải tìm cách giảm 1 HTTP request chỉ sinh ra 10 query thôi, tắt hết statistics, các tính năng phụ...
Vài tốt nhất, triệt để nhất, thuê 1 ng viết lại cái web app đó, sao cho nó ăn ít resource, hiệu quả hơn.
Vậy thôi.

Bảo đảm syn cookie của linux chẳng tác dụng mấy nếu bị syn flood cỡ trên 10 ngàn / 1 giây. Nếu không tune tcp/ip stack trên kernel mà để mặc định thì cỡ 10 ngàn syn / 1 giây sẽ mất khoảng vài phút đến vài chục phút (tùy tài nguyên của máy chủ) thì server sẽ chết. Đặc biệt khi hết physical mem và kernel bắt đầu swap ra disk (buộc các ứng dụng khác phải dùng virtual mem) thì lúc ấy system load sẽ lên hàng trăm (average) và.... chết cứng.

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

[Question] SYN ATTACK và cách khắc phục ?	07/12/2009 16:44:47 (+0700) \| #8 \| 200010

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

conmale wrote:

Bảo đảm syn cookie của linux chẳng tác dụng mấy nếu bị syn flood cỡ trên 10 ngàn / 1 giây. Nếu không tune tcp/ip stack trên kernel mà để mặc định thì cỡ 10 ngàn syn / 1 giây sẽ mất khoảng vài phút đến vài chục phút (tùy tài nguyên của máy chủ) thì server sẽ chết. Đặc biệt khi hết physical mem và kernel bắt đầu swap ra disk (buộc các ứng dụng khác phải dùng virtual mem) thì lúc ấy system load sẽ lên hàng trăm (average) và.... chết cứng.

Em chưa dính đến 10 ngàn/1 giây. Nên chưa dám nói bừa. Nhưng về mặt lý thuyết mà em biết về TCP/IP và cách Linux implemente nó, em thấy có chỗ ko hiểu?
Bác làm ơn giải thích tại sao lúc bị flood thế, mà tcp/ip của server vẫn làm full mem? Theo em biết, khi đầy back-log buffer là TCP/IP stack sẽ ko nhận thêm gói syn nữa (đúng hơn là nhận đc nhưng discard đi, ko lưu vào đâu cả, cũng ko gửi gói SYN/ACK trở lại).
Theo em biết, lúc đó có Syn Cookie, thì server sẽ ko discard đi ngay mà làm thêm 1 động tác: gửi trả lời SYN/ACK với seq là 1 cookie. Cái này sẽ ko có resend SYN-ACK, nếu may mắn client hàng xịn nhận được gói SYN-ACK đó, có seq, nó sẽ ACK với seq đó. Server nhận được gói ACK, tính toán ra đúng seq là cookie nó gửi đi, thì nó cho thiết lập kết nối ngay, bỏ qua công đoạn lưu vào backlog-buffer (nghĩa là cũng ko tốn mem).
Có đúng vậy ko bác?

[Question] SYN ATTACK và cách khắc phục ?	11/12/2009 05:42:16 (+0700) \| #9 \| 200311

conmale
Administrator

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

myquartz wrote:

conmale wrote:

Bảo đảm syn cookie của linux chẳng tác dụng mấy nếu bị syn flood cỡ trên 10 ngàn / 1 giây. Nếu không tune tcp/ip stack trên kernel mà để mặc định thì cỡ 10 ngàn syn / 1 giây sẽ mất khoảng vài phút đến vài chục phút (tùy tài nguyên của máy chủ) thì server sẽ chết. Đặc biệt khi hết physical mem và kernel bắt đầu swap ra disk (buộc các ứng dụng khác phải dùng virtual mem) thì lúc ấy system load sẽ lên hàng trăm (average) và.... chết cứng.

Em chưa dính đến 10 ngàn/1 giây. Nên chưa dám nói bừa. Nhưng về mặt lý thuyết mà em biết về TCP/IP và cách Linux implemente nó, em thấy có chỗ ko hiểu?
Bác làm ơn giải thích tại sao lúc bị flood thế, mà tcp/ip của server vẫn làm full mem? Theo em biết, khi đầy back-log buffer là TCP/IP stack sẽ ko nhận thêm gói syn nữa (đúng hơn là nhận đc nhưng discard đi, ko lưu vào đâu cả, cũng ko gửi gói SYN/ACK trở lại).
Theo em biết, lúc đó có Syn Cookie, thì server sẽ ko discard đi ngay mà làm thêm 1 động tác: gửi trả lời SYN/ACK với seq là 1 cookie. Cái này sẽ ko có resend SYN-ACK, nếu may mắn client hàng xịn nhận được gói SYN-ACK đó, có seq, nó sẽ ACK với seq đó. Server nhận được gói ACK, tính toán ra đúng seq là cookie nó gửi đi, thì nó cho thiết lập kết nối ngay, bỏ qua công đoạn lưu vào backlog-buffer (nghĩa là cũng ko tốn mem).
Có đúng vậy ko bác?

Em nhận xét đúng về vai trò của syn_backlog nhưng em không đặt để nó vào hoàn cảnh syn-flooding. syn_backlog là buffer cho các cú SYN đi vào những nếu buffer này quá bé nhỏ thì nó sẽ đầy ngay lập tức trong khi syn vẫn tràn vào dồn dập ---> denial of service đã thành công. Bởi thế, trong hoàn cảnh này syn_backlog phải rất lớn để có thể buffer càng nhiều càng tốt và buffer càng lớn thì càng đòi hỏi nhiều physical memory (nên nhớ trên tcp/ip stack, những gì đụng đến memory là physical memory chớ không phải virtual memory). Giá trị ấn định cho syn_backlog riêng nó chỉ là một mảnh của vấn đề. Song song với syn_backlog còn có somaxcon, còn có timeout cho syn.... để có thể tương trợ lẫn nhau nhằm mục đích tối ưu trong hoàn cảnh bị.... dập.

Thử làm một bài toán đơn giản xem. Một gói SYN ít nhất cũng 40 bytes và có thể lớn hơn tùy options kèm theo. Cứ tính trung bình một gói SYN là 60 bytes chẳng hạn thì:

60 x 10000 / 1024 / 1024 = 0.57Mb

Đây chỉ là trong 1 giây (đơn cử trường hợp 10000 syn / s). Nếu timeout cho SYN_RECV là 30s (đợi) thì mất bao lâu SYN được vào backlog sẽ bị triệt tiêu? Để mở cửa cho SYN vào thêm nhằm mục đích hạn chế DoS thì cần buffer có thể chứa bao nhiêu SYN? Bởi thế, trong hoàn cảnh bị DoS (syn flood đang được bàn) thì memory dành riêng để xử lý SYN là một vấn đề trọng yếu.

Riêng với syncookie thì cơ chế này có điểm mạnh và yếu khác nhau. Ngoài overhead phải kiểm tra các gói ACK đi vào (tệ hơn nữa nếu syn flood kèm theo các dạng DoS trên tầng application như HTTP flood), trên thực tế, ở cường độ syn flood cao, syn cookie không kiểm soát hết 100% các cú syn.

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

[Question] SYN ATTACK và cách khắc phục ?	11/12/2009 08:56:41 (+0700) \| #10 \| 200323

rickb
Reseacher

Joined: 27/01/2007 17:47:27
Messages: 200
Offline

myquartz wrote:

SYN Attack ko làm gì nổi CentOS đâu.
Nhưng mở nhiều kết nối và tạo request để làm lụt web server thì có thể, và ứng dụng web của bạn quá tải rồi, nên nó mới ăn RAM/CPU. Xử lý ko kịp mà lượng kết nối về vẫn tăng lên nên SYNC_RECV nhiều như thế.
Bạn thử gõ lệnh:
netstat -ntp | grep ESTA | grep httpd | wc -l
xem ra bao nhiêu?
Bạn nên tuning lại ứng dụng web, có thể giảm bớt số concurrent session trong httpd để tài nguyên ko bị cạn, tuning lại mysql (nếu có sử dụng), giảm time out của httpd, giảm thời gian chờ giữa 2 keep-alive request (nếu keep-alive on).
Một cách khắc phục thêm nữa nếu cái trên chưa ổn, cài fail2ban, monitor apache access log. Nếu 1 IP nào đó request quá 50 lần trong 10 giây chẳng hạn, thì ban nó 5 phút. Tất nhiên fail2ban sẽ tốn CPU/RAM nhưng dù sao nó sẽ đỡ cho bạn khá tốt.

Đọc topic này hơi trễ nhưng vẫn mún tham gia smilie

Mình ko đồng ý với những gì bạn write ở trên

Thứ nhất, bản chất SYN attack là tấn công vào layer 3 của TCP/IP, do đó nó ko liên quan đến "làm gì nổi CentOS" hay làm gì nổi với Web sever

Thứ hai, khi bản chất vấn để ở layer 3 thì bạn ko thể đem 1 solution ở layer 7 giải quết định, do đó việc tuning ứng dụng web là ko hợp lý

Thứ 3, Kỹ thuật SYN Attack thường đi kèm với IP Spoofing, liệu việc ban IP dựa trên request có khả thi ?

Thân,

[Question] SYN ATTACK và cách khắc phục ?	11/12/2009 16:20:07 (+0700) \| #11 \| 200362

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

rickb wrote:

Đọc topic này hơi trễ nhưng vẫn mún tham gia

Mình ko đồng ý với những gì bạn write ở trên

Thứ nhất, bản chất SYN attack là tấn công vào layer 3 của TCP/IP, do đó nó ko liên quan đến "làm gì nổi CentOS" hay làm gì nổi với Web sever

Thứ hai, khi bản chất vấn để ở layer 3 thì bạn ko thể đem 1 solution ở layer 7 giải quết định, do đó việc tuning ứng dụng web là ko hợp lý

Thứ 3, Kỹ thuật SYN Attack thường đi kèm với IP Spoofing, liệu việc ban IP dựa trên request có khả thi ?

Thân,

Bạn đọc nhưng mà bạn quên từ "nhưng".
Post này và như các post sau, tôi nói rằng SYN flooding hiện tại ko thể làm cho web server chạy CentOS bị quá tải, overload CPU và RAM. Nên tôi suy đoán việc bị overload đó ko phải vì syn flooding, mà thực sự là HTTP request flooding, web server là apache ko thể xử lý kịp các request đã nhận, nên ko tiếp nhận thêm kết nối, ko accept, nên các connection dạng SYN_RECV do netstat thông báo nhiều đến vậy. Dù rằng 2 cách flooding sẽ có triệu trứng gần như nhau theo quan sát của admin, tôi mới yêu cầu anh ta cho biết connection đã ESTABLISHED để chuẩn đoán thêm (nhưng anh admin này đưa thông tin khác, số lượng SYN_RECV => chả kết luận đc gì cả).

@comale:
Bác comale đã giải thích rằng kể cả có syn_cookie, thì việc bị overload vẫn xảy ra, theo cái post giải thích của bác ấy. Tôi thì tôi không nghĩ vậy.

Bác cho rằng backlog buffer tăng lên nên hệ thống bị overload. Theo tôi biết thì kích thước backlog buffer của mỗi listening port (hoặc bind port), do ứng dụng server - ở đây là apache - thiết lập khi gọi hàm bind (hoặc ko set thì hệ thống lấy giá trị mặc định). Giá trị này mặc định tôi nhớ ko quá con số vài ngàn, do đó, 40x1000 =~ 40KBytes. Đầy buffer thì OS nó đơn giản là drop cái gói syn đi, ko cho vào backlog. Làm sao có thể làm overload RAM được hả bác? Và dù đầy backlog thì do nhờ syn_cookie bật mặt định nên web server có thể vẫn tiếp nhận được các connection, khởi tạo đủ 3 bước và thực hiện request, nên mục đích syn flooding để đầy backlog buffer ko đạt được mục tiêu.
tính toán dưới đây nhầm mất 1000 lần, do đãng trí, xin lỗi bà con.
Over CPU thì có thể, nhưng khả năng xử lý IP packet của CentOS trên server cũng kinh lắm, có thể đến hàng triệu IP packets/s (tốc độ mạng 1000mbit/s =~ 100MBytes/s => 100M/1500bytes/packet =~ 66 triệu packets, em đã từng chứng kiến con server nó chuyển tải file tốc độ đến 50Mbytes/s qua mạng LAN Gigabit, tương ứng khoảng 30 triệu packet/s). => khả năng số lượng gói syn làm overload CPU phải lớn hơn con số hàng triệu đó.

[Question] SYN ATTACK và cách khắc phục ?	11/12/2009 16:39:12 (+0700) \| #12 \| 200365

conmale
Administrator

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

myquartz wrote:

rickb wrote:

Đọc topic này hơi trễ nhưng vẫn mún tham gia

Mình ko đồng ý với những gì bạn write ở trên

Thứ nhất, bản chất SYN attack là tấn công vào layer 3 của TCP/IP, do đó nó ko liên quan đến "làm gì nổi CentOS" hay làm gì nổi với Web sever

Thứ hai, khi bản chất vấn để ở layer 3 thì bạn ko thể đem 1 solution ở layer 7 giải quết định, do đó việc tuning ứng dụng web là ko hợp lý

Thứ 3, Kỹ thuật SYN Attack thường đi kèm với IP Spoofing, liệu việc ban IP dựa trên request có khả thi ?

Thân,

Bạn đọc nhưng mà bạn quên từ "nhưng".
Post này và như các post sau, tôi nói rằng SYN flooding hiện tại ko thể làm cho web server chạy CentOS bị quá tải, overload CPU và RAM. Nên tôi suy đoán việc bị overload đó ko phải vì syn flooding, mà thực sự là HTTP request flooding, web server là apache ko thể xử lý kịp các request đã nhận, nên ko tiếp nhận thêm kết nối, ko accept, nên các connection dạng SYN_RECV do netstat thông báo nhiều đến vậy. Dù rằng 2 cách flooding sẽ có triệu trứng gần như nhau theo quan sát của admin, tôi mới yêu cầu anh ta cho biết connection đã ESTABLISHED để chuẩn đoán thêm (nhưng anh admin này đưa thông tin khác, số lượng SYN_RECV => chả kết luận đc gì cả).

@comale:
Bác comale đã giải thích rằng kể cả có syn_cookie, thì việc bị overload vẫn xảy ra, theo cái post giải thích của bác ấy. Tôi thì tôi không nghĩ vậy.

Bác cho rằng backlog buffer tăng lên nên hệ thống bị overload. Theo tôi biết thì kích thước backlog buffer của mỗi listening port (hoặc bind port), do ứng dụng server - ở đây là apache - thiết lập khi gọi hàm bind (hoặc ko set thì hệ thống lấy giá trị mặc định). Giá trị này mặc định tôi nhớ ko quá con số vài ngàn, do đó, 40x1000 =~ 40KBytes. Đầy buffer thì OS nó đơn giản là drop cái gói syn đi, ko cho vào backlog. Làm sao có thể làm overload RAM được hả bác? Và dù đầy backlog thì do nhờ syn_cookie bật mặt định nên web server có thể vẫn tiếp nhận được các connection, khởi tạo đủ 3 bước và thực hiện request, nên mục đích syn flooding để đầy backlog buffer ko đạt được mục tiêu.
Over CPU thì có thể, nhưng khả năng xử lý IP packet của CentOS trên server cũng kinh lắm, có thể đến hàng triệu IP packets/s (tốc độ mạng 1000mbit/s =~ 100MBytes/s => 100M/1500bytes/packet =~ 66 triệu packets, em đã từng chứng kiến con server nó chuyển tải file tốc độ đến 50Mbytes/s qua mạng LAN Gigabit, tương ứng khoảng 30 triệu packet/s). => khả năng số lượng gói syn làm overload CPU phải lớn hơn con số hàng triệu đó.

Em nói gì thì nói rồi cũng bỏ qua tình trạng "denial of service". Em muốn không hết mem, không bị CPU overload? Dễ ợt. Em set syn_backlog thật thấp, syn_timeout thật thấp rồi ngồi đó chơi vì chẳng có gì xảy ra (chẳng có packet nào đi đến cổng dịch vụ cả). Nếu em tính 40x1000 = 40K và cho là xong thì.... tiêu vì lúc ấy server của em phục vụ cái gì?

Nếu em muốn còn tạo được dịch vụ và cổng dịch vụ còn nhận được legitimate requests thì con số em đưa ra ở trên chẳng có giá trị gì mấy. Em tính đến hàng triệu packets nhưng chúng đi đâu?

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

[Question] SYN ATTACK và cách khắc phục ?	11/12/2009 20:21:29 (+0700) \| #13 \| 200382

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

myquartz wrote:

...em đã từng chứng kiến con server nó chuyển tải file tốc độ đến 50Mbytes/s qua mạng LAN Gigabit, tương ứng khoảng 30 triệu packet/s

Hì hì, 50MB/s có thật là 30 triệu packet/s không bạn? Có gì đâu, bạn myquartz chắc cũng có mấy con servers hàng khủng, bạn thử "đốt" trong LAN tầm 10000 SYN/s thì biết ngay ấy mà. Mình thì không có máy móc gì cả nên đành chịu, chứ không mình cũng thử phát.

Mind your thought.

[Question] SYN ATTACK và cách khắc phục ?	12/12/2009 09:15:58 (+0700) \| #14 \| 200424

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

Hi bác comale.
Em không nghĩ lý do gì phải set cái backlog buffer thật to cả. Nó không cần thiết cho hoạt động thông thường, với 1 server nhận và tạo mới hàng ngàn connection/s thì con số 1000 cũng quá đủ.
Còn đang bị trạng thái DoS, nếu nguyên bản, ko có syn_cookie thì việc bị DoS chết ngỏm là chắc chắn. Nhưng có cái SK đó, việc đó sẽ ko thành hiện thực, legitimate requests vẫn thực hiện được. Bác cứ thử đi coi.
Cái ví dụ về tốc độ sinh/xử lý packet, chỉ là ví dụ minh hoạ tốc độ xử lý gói IP packet của server, tất nhiên nó khác 1 chút với xử lý gói syn, nhưng load để xử lý 2 cái khá tương đồng nhau.

@SC: các tranh luận lý thuyết này thiếu SC mất vui :-D. (đã sửa chữa) 50MB/s tương đương 33 ngàn packet/s.
Gửi 10 ngàn syn/s thì xử lý được, 100 ngàn chưa biết.

------------------------------------------------------------------------

@all: em nghĩ mọi ng chưa dính vụ syn flooding thực sự, có thể test bằng 1 số tool. 2 máy chạy linux CentOS, 1 đầu (coi là server) chạy netcat (nc) hoặc chạy luôn apache web, chạy nc cho chế độ -l -k, đầu kia dùng hping (có trong repo của centos). Nếu nhiều đầu cùng tấn công 1 đầu cũng được.
Gõ lệnh:

hping -i u1 -S -p 80 dst-host-or-ip

=> Sẽ thấy tải phải gánh trên server nó khác với 1 cái gọi là http request flooding, cũng test được nhờ 1 tool (cài kèm httpd) của apache là ab (apache bench), với lệnh số:

ab -c 1000 -n 100000 -k -r http://dst-host-or-ip:port/uri

(1000 kết nối với 100K request, cái này muốn thành công thì dùng 10 máy tấn công 1 máy, sẽ thấy tác dụng nó thế nào).
uri nên là 1 script hoặc 1 file hợp lệ, nếu là script thực hiện việc gì đó nặng nặng 1 chút càng tốt.

[Question] SYN ATTACK và cách khắc phục ?	12/12/2009 09:40:32 (+0700) \| #15 \| 200428

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

@myquartz: ôi mình nhớ 50MB thì hình như là 50 triệu bytes thì phải.

Mind your thought.

[Question] SYN ATTACK và cách khắc phục ?	12/12/2009 11:53:16 (+0700) \| #16 \| 200440

conmale
Administrator

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

myquartz wrote:

Hi bác comale.
Em không nghĩ lý do gì phải set cái backlog buffer thật to cả. Nó không cần thiết cho hoạt động thông thường, với 1 server nhận và tạo mới hàng ngàn connection/s thì con số 1000 cũng quá đủ.
Còn đang bị trạng thái DoS, nếu nguyên bản, ko có syn_cookie thì việc bị DoS chết ngỏm là chắc chắn. Nhưng có cái SK đó, việc đó sẽ ko thành hiện thực, legitimate requests vẫn thực hiện được. Bác cứ thử đi coi.
Cái ví dụ về tốc độ sinh/xử lý packet, chỉ là ví dụ minh hoạ tốc độ xử lý gói IP packet của server, tất nhiên nó khác 1 chút với xử lý gói syn, nhưng load để xử lý 2 cái khá tương đồng nhau.

Em không cần bảo anh "cứ thử đi coi" làm chi vì anh đã thử nó (cái syncookie) từ lúc nó được implement trên Linux hồi cuối 1997. Anh còn thử nó triền miên trong suốt thời gian HVA bị DDoS từ tháng này sang năm nọ. Em dùng lý thuyết để lý giải một điều em chưa kinh qua nhưng vẫn khăng khăng mình đúng thì rất kẹt bởi vì từ lý thuyết đến thực tế nó khác xa lắm.

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

[Question] SYN ATTACK và cách khắc phục ?	13/12/2009 12:42:37 (+0700) \| #17 \| 200530

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

StarGhost wrote:

@myquartz: ôi mình nhớ 50MB thì hình như là 50 triệu bytes thì phải.

À, đúng, đôi khi có sự nhầm lẫn khi tính nhẩm, đãng trí smilie

. Giảm đi 1000 lần so với mình tính toán. 50 triệu/1,5 ngàn = 50 ngàn/1,5 = 33 ngàn/s.
Sorry bà con, chắc ko tranh cãi thêm về cái trên nữa nha.
Mọi ng đều có gặp vấn đề khác nhau và cách giải quyết khác nhau, tuỳ theo hiểu biết. Tranh cái khi 2 vấn đề gặp phải là khác nhau thì ko ra 1 kết quả chung.
Tôi close việc trả lời của tôi. Xin lỗi vì mất thời gian của bà con.

[Question] SYN ATTACK và cách khắc phục ?	13/12/2009 21:22:12 (+0700) \| #18 \| 200566

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Để ý tới mỗi khi tranh luận mà có chiều hướng không đúng với những bài post trước là myquartz rút lui.

[Question] SYN ATTACK và cách khắc phục ?	13/12/2009 21:48:01 (+0700) \| #19 \| 200568

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

Diễn đàn ít bài nên spam thêm tí tẹo đây.
Tôi đánh giá việc rút lui là hợp lý, vì đơn giản là vấn đề này tôi cũng hết cái để nói, và một số điểm căn cứ tôi đưa ra có sai lạc về tính toán thì việc chứng minh của mình có thể là vô giá trị, ko phải theo đuổi làm gì nữa.
Bác comale chắc chắn sẽ ko thừa nhận ý kiến của tôi là đúng, việc đó thì tùy theo kinh nghiệm + kiến thức để mà chia sẻ, hoặc nhận xét thôi.
Quan điểm của tôi: nếu sau khi tranh luận mọi người đều đi đến 1 ý kiến thống nhất thì ok, ko thống nhất thì bên nào hết lý lẽ thì rút lui, ko cố đấm làm gì khi mình ko thể đưa thêm luận cứ chứng minh và biết chắc chắn không thuyết phục được người khác, khi người ta có thể có kinh nghiệm/sự hiểu biết khác mình và nhất là khi mình đã sai sót. Đây có thể là bài học cho mình hoặc là bài học cho người khác, tùy theo thông tin tranh luận mang lại điều gì.
Close lại khi các bên đã nêu đủ ý, đủ thông tin, vậy là cuộc tranh luận thành công rồi.

P/S: chủ của topic này sau khi hỏi, và chứng kiến sự tranh luận, ko biết có giúp ích gì cho việc khắc phục web server của anh ta rồi. Nếu rồi (có thể ko chỉ giải pháp đã hỏi tại forum), thì đó là điều may mắn, nếu chưa mà vẫn cần sự giúp đỡ của forum, thì chắc là nên đưa thêm thông tin hoặc nhờ cậy riêng bằng PM để đạt được kết quả cuối cùng nếu muốn.
Theo kinh nghiệm của tớ, việc đánh giá sai lầm nguyên nhân hoặc các điểm mấu chốt dẫn đến sự cố, có thể tiêu tốn thời gian theo đuổi các giải pháp khác nhau mà chúng không thực sự xử lý được vấn đề.
Các sự cố kiểu DoS như vậy đôi khi người ta xử lý theo cách hết sức đơn giản, nhanh chóng (nhất là ở các doanh nghiệp lớn): mua hardware có sức mạnh gấp nhiều lần để thay thế, thay vì mò mẫm nguyên nhân và cách khắc phục, chi phí cơ hội bỏ ra không đáng để rủi ro như thế và nhất là trong điều kiện nhân lực CNTT yếu và thiếu như hiện tại.

[Question] SYN ATTACK và cách khắc phục ?	14/12/2009 01:11:29 (+0700) \| #20 \| 200575

abcd8035
Member

Joined: 15/07/2007 22:14:45
Messages: 10
Location: Nha Trang
Offline

Chào anh conmale, myquarzt và mọi người đã quan tâm đến vấn đề của mình. Mình rất vui khi thấy mọi người cùng nhau thảo luận, và vấn đề chính rất tồi tệ, mình không thể kiểm soát được "tình trạng vất vả" này. Nó diễn ra hàng ngày, hàng giờ, và diễn ra một cách .. dã man. Bây giờ là 1h:55 phút sáng, dấu hiệu như sau:

Code:

[root@server ~]# netstat -nap |grep SYN
tcp        0      1 112.78.8.7:36589            67.195.168.31:25            SYN_SENT    12106/smtp
tcp        0      1 112.78.8.7:52981            66.196.82.7:25              SYN_SENT    12111/smtp
tcp        0      1 112.78.8.7:50704            75.101.145.196:80           SYN_SENT    2013/httpd
tcp        0      1 112.78.8.7:36632            75.101.154.43:80            SYN_SENT    6020/httpd
tcp        0      1 112.78.8.7:50052            67.195.168.230:25           SYN_SENT    12110/smtp
tcp        0      1 112.78.8.7:45363            98.137.54.238:25            SYN_SENT    12109/smtp
tcp        0      1 112.78.8.7:41888            75.101.162.204:80           SYN_SENT    2015/httpd
tcp        0      1 112.78.8.7:43558            74.6.136.65:25              SYN_SENT    12108/smtp

Thông tin chính xác của bạn đây, myquarzt

Code:

[root@server ~]# netstat -nap |grep SYN
tcp        0      1 112.78.8.7:36604            67.195.168.31:25            SYN_SENT    12110/smtp
tcp        0      1 112.78.8.7:50716            75.101.145.196:80           SYN_SENT    6020/httpd
tcp        0      1 112.78.8.7:45866            209.191.88.254:25           SYN_SENT    12108/smtp
tcp        0      1 112.78.8.7:37508            75.101.155.168:80           SYN_SENT    2015/httpd
tcp        0      1 112.78.8.7:41914            75.101.162.204:80           SYN_SENT    2013/httpd
tcp        0      1 112.78.8.7:43571            74.6.136.65:25              SYN_SENT    12109/smtp
tcp        0      1 112.78.8.7:43569            74.6.136.65:25              SYN_SENT    12106/smtp
tcp        0      1 112.78.8.7:53875            206.190.54.127:25           SYN_SENT    12111/smtp
[root@server ~]# netstat -ntp | grep ESTA | grep httpd | wc -l
5

Tình trạng VPS

Code:

top - 12:10:53 up  4:35,  2 users,  load average: 0.25, 0.14, 0.10
Tasks: 111 total,   3 running, 108 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.5%us,  0.1%sy,  0.0%ni, 97.9%id,  0.3%wa,  0.0%hi,  0.0%si,  0.2%st
Mem:    393392k total,   383364k used,    10028k free,     4984k buffers
Swap:   786424k total,     3288k used,   783136k free,   150112k cached

-> Full ram , chưa overload.

Đây là lúc mình đã khóa một số IP nước ngoài, có lẽ vì thế nên nó không ảnh hưởng gì mấy ?!
Nhưng ... khi viết reply này thì lại có thêm chuyện ( lúc này mình tạm gỡ khóa các IP nước ngoài để tìm IP Google add vào firewall cho nó làm việc )

Code:

[root@server ~]# netstat -nap |grep SYN
tcp        0      0 112.78.8.7:80               188.112.130.166:3392        SYN_RECV    -
tcp        0      0 112.78.8.7:80               213.180.96.137:1498         SYN_RECV    -
tcp        0      0 112.78.8.7:80               195.244.132.98:54396        SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.198.177.179:2797         SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.226.116.216:52848        SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.131.45:13898          SYN_RECV    -
tcp        0      0 112.78.8.7:80               79.135.137.158:4265         SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.57.178:2140         SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.28.54:50423           SYN_RECV    -
tcp        0      0 112.78.8.7:80               85.234.172.20:3207          SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.207.57:1197           SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.198.151.82:33348         SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.110.6.163:1578           SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.211.78:2982           SYN_RECV    -
tcp        0      0 112.78.8.7:80               83.99.128.17:1988           SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.226.45.210:1066          SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.60.190:3911         SYN_RECV    -
tcp        0      0 112.78.8.7:80               83.99.160.29:1854           SYN_RECV    -
tcp        0      0 112.78.8.7:80               80.233.143.163:2455         SYN_RECV    -
tcp        0      0 112.78.8.7:80               159.148.121.105:2487        SYN_RECV    -
tcp        0      0 112.78.8.7:80               94.194.62.50:1388           SYN_RECV    -
tcp        0      0 112.78.8.7:80               188.220.71.83:62896         SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.89.216:3413           SYN_RECV    -
tcp        0      0 112.78.8.7:80               83.99.210.106:4889          SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.139.8:2171            SYN_RECV    -
tcp        0      0 112.78.8.7:80               62.84.4.111:56390           SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.246.140.9:2042           SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.145.137:3155          SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.198.226.39:4157          SYN_RECV    -
tcp        0      0 112.78.8.7:80               89.248.85.177:1142          SYN_RECV    -
tcp        0      0 112.78.8.7:80               149.254.51.44:12730         SYN_RECV    -
tcp        0      0 112.78.8.7:80               89.254.143.218:1454         SYN_RECV    -
tcp        0      0 112.78.8.7:80               84.245.205.115:4003         SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.110.6.92:2584            SYN_RECV    -
tcp        0      0 112.78.8.7:80               212.93.100.169:32642        SYN_RECV    -
tcp        0      0 112.78.8.7:80               85.15.207.71:52910          SYN_RECV    -
tcp        0      0 112.78.8.7:80               85.15.210.10:1334           SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.199.95:3471           SYN_RECV    -
tcp        0      0 112.78.8.7:80               89.18.194.104:3381          SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.88.71:3743            SYN_RECV    -
tcp        0      0 112.78.8.7:80               212.93.100.169:23796        SYN_RECV    -
tcp        0      0 112.78.8.7:80               192.168.0.101:3364          SYN_RECV    -
tcp        0      0 112.78.8.7:80               83.99.128.17:1981           SYN_RECV    -
tcp        0      0 112.78.8.7:80               91.135.84.65:2629           SYN_RECV    -
tcp        0      0 112.78.8.7:80               195.244.132.178:3925        SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.60.190:3905         SYN_RECV    -
tcp        0      0 112.78.8.7:80               85.15.216.36:4832           SYN_RECV    -
tcp        0      0 112.78.8.7:80               89.201.68.222:3704          SYN_RECV    -
tcp        0      0 112.78.8.7:80               89.201.74.179:4791          SYN_RECV    -
tcp        0      0 112.78.8.7:80               212.93.100.169:45083        SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.74.218:3893           SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.60.190:3933         SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.216.165.114:2889         SYN_RECV    -
tcp        0      0 112.78.8.7:80               149.254.51.44:12871         SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.198.10.43:3121           SYN_RECV    -
tcp        0      0 112.78.8.7:80               80.69.178.17:3398           SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.57.178:2116         SYN_RECV    -
tcp        0      0 112.78.8.7:80               195.216.177.86:1688         SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.198.39.190:2891          SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.14.247:50630          SYN_RECV    -
tcp        0      0 112.78.8.7:80               149.254.51.44:12935         SYN_RECV    -
tcp        0      0 112.78.8.7:80               81.222.185.218:2951         SYN_RECV    -
tcp        0      0 112.78.8.7:80               62.63.165.166:2595          SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.110.36.33:3665           SYN_RECV    -
tcp        0      0 112.78.8.7:80               212.142.83.132:1400         SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.85.222:3744           SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.145.137:3206          SYN_RECV    -
tcp        0      0 112.78.8.7:80               193.41.195.116:62523        SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.70.91:64004           SYN_RECV    -
tcp        0      0 112.78.8.7:80               78.84.161.95:1418           SYN_RECV    -
tcp        0      0 112.78.8.7:80               159.148.159.102:2284        SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.60.190:3936         SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.60.190:3919         SYN_RECV    -
tcp        0      0 112.78.8.7:80               95.68.62.113:2339           SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.60.190:3906         SYN_RECV    -
tcp        0      0 112.78.8.7:80               93.177.217.63:1593          SYN_RECV    -
tcp        0      0 112.78.8.7:80               87.110.201.186:1577         SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.57.178:2131         SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.57.178:2122         SYN_RECV    -
tcp        0      0 112.78.8.7:80               84.245.214.79:3486          SYN_RECV    -
tcp        0      0 112.78.8.7:80               91.190.40.246:3101          SYN_RECV    -
tcp        0      0 112.78.8.7:80               213.180.107.161:43438       SYN_RECV    -
tcp        0      0 112.78.8.7:80               109.106.57.178:2134         SYN_RECV    -
tcp        0      0 112.78.8.7:80               149.254.51.44:12870         SYN_RECV    -
tcp        0      0 112.78.8.7:80               80.232.248.125:2086         SYN_RECV    -
tcp        0      0 112.78.8.7:80               83.99.146.16:2885           SYN_RECV    -

Code:

[root@server ~]# netstat -ntp | grep ESTA | grep httpd | wc -l
200

Gõ lệnh ra thêm buồn, CPU lúc này load khoảng 25 và tăng đều đều.

Mình cũng đồng ý với anh conmale là CPU Overload, Full physical memory.
Hi vọng topic này sẽ giúp một số anh em non nớt như mình ngộ ra điều gì đó để ứng dụng vào việc quản lý web được tốt hơn. Chờ tin các bạn.

[Question] SYN ATTACK và cách khắc phục ?	15/12/2009 14:04:13 (+0700) \| #21 \| 200773

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

Bạn có thể cung cấp thêm các thông tin sau:
- Ứng dụng web trên máy chủ của bạn có chức năng gửi mail hoặc là kết nối tới web server khác hay không, như cái log này đã chỉ ra:
Code:

tcp        0      1 112.78.8.7:41914            75.101.162.204:80           SYN_SENT    2013/httpd
 tcp        0      1 112.78.8.7:43571            74.6.136.65:25              SYN_SENT    12109/smtp

Nếu có thực hiện, thì 2 IP mà server đang kết nối đó có đúng là 2 IP bạn config? Nhất là ứng dụng kết nối tới port 80 lại là httpd. Có phải bạn bật chức năng proxy trên httpd? Bạn chạy PHP trên web server của bạn, PHP script đó có tính năng proxy hoặc kết nối tới web server khác không?

- Theo như thông tin từ VPS, thì máy của bạn đang phải handle 200 kết nối HTTP (do httpd gánh) và tiếp tục nhận được các kết nối. Cái này không phải là syn flood mà có thể là connection flood hoặc http request flood, do kết nối đã hoàn thành (ESTA) rồi. Có thể là tấn công chủ động hoặc đơn giản do web của bạn có nhiều ng vào thời điểm đó.
Bạn có thể cho xem 100 dòng log cuối cùng của httpd, nếu không có gì bí mật, hay lấy khi server bị tăng tải như thế ko?
Lệnh là: tail -n 100 /var/log/httpd/access_log

Mình nghĩ sau khi có mấy thông tin này, có thể đoán ra nguyên nhân mà server bị tăng tải lên.

[Question] SYN ATTACK và cách khắc phục ?	15/12/2009 17:14:49 (+0700) \| #22 \| 200805

abcd8035
Member

Joined: 15/07/2007 22:14:45
Messages: 10
Location: Nha Trang
Offline

Cho mình xin yahoo của bạn nhé. Chúng ta sẽ tiếp tục trao đổi trong yahoo và gửi comment để thảo luận tại forum, như thế vừa giúp ích cho mình mà cũng làm topic trở nên có giá trị.

Go to:

Users currently in here
1 Anonymous