Máy ảo và thật đều cùng 1 line mà bạn

rút cáp thì chỉ có kỹ thuật trực tiếp tại đó mới xử lý được, chứ mình ở xa, đâu xử lý offline được.

Mà từ file dump đó có thể phân tích được nguồn phát động tấn công không nhỉ ?

Mình muốn biết nguồn tấn công để dùng giải pháp khác nữa, song song với giải pháp kỹ thuật.

p/s : sv vẫn đang die...( 

'net.netfilter.nf_conntrack_tcp_timeout_syn_recv' is an unknown key

 

uhm, lượng botnet quá lớn....đầu hàng thôi.

Cấu hình gì cũng vô ích khi các thiết bị ở ngoài đã chết khi chưa kịp đến server.... 

uhm, lượng botnet quá lớn....đầu hàng thôi.

Cấu hình gì cũng vô ích khi các thiết bị ở ngoài đã chết khi chưa kịp đến server.... 

huuduyen wrote:

uhm, lượng botnet quá lớn....đầu hàng thôi.

Cấu hình gì cũng vô ích khi các thiết bị ở ngoài đã chết khi chưa kịp đến server.... 

Cũng may là cái botnet đó cũng khá đắt tiền và hiếm gặp, không biết ai mà rỗi hơi vậy. Bạn thử đưa log sang bên VNCert họ đối chiếu với log của VNN xem có phải cùng botnet không.

Bên mình đầu tháng 1 cũng bị botnet tấn công 2 ngày (max đường truyền 100 Mbps), và đã được xác nhận ban đầu là cùng botnet với đám tấn công VNN. 

Mình có nhờ người thử liên hệ bên VNCert.

Họ nói lại là bảo đảm chặn được 100%. Nhưng số $ là ~$150 000 bao gồm cả hardware lẫn software...

BOTNET lợi hại quá....đành bó tay thôi

 

2) Chỉnh trên iptables (giả định iptables -P INPUT DROP)

Code:

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

Để bảo đảm, block luôn các IP vi phạm (dùng để tạo SYN flood) 2 phút; sau 2 phút kiểm tra lại, nếu không còn vi phạm thì cho vô. Thêm đoạn này:

Code:

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

 

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 -t nat -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j DNAT --to-destination 192.168.100
 
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 nat -N forwardip
iptables -t nat -A forwardip -j DNAT --to 192.168.1.100
iptables -t nat -A PREROUTING -p tcp -d $IP -m recent --name SYN --update --seconds 120 -j forwardip

Sau khi xem lại cái bảng đường đi của gói tin thì em đã hiểu vì nó lại báo lỗi "iptables: No chain/target/match by that name." tại dòng lệnh
Code:

iptables -t nat -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j DNAT --to-destination 192.168.100

Lý do là DNAT là việc làm khi ở chain PREROUTING. Cho nên khi vào đến chain INPUT để kiểm tra gói tin có vi phạm hay không thì lúc này dùng DNAT là không hợp lý.

Theo em thì dùng chain REDIRECT ở đoạn này là thích hợp. Tuy nhiên phiên iptables của em lại không hỗ trợ REDIRECT đến một host khác. Hiện tại thì em hình dung ra hai hướng sau:

a) dùng chain REDIRECT chuyển hướng packet đến một port nào đó, và dùng một dịch vụ khác để chuyển packet đến host mình mong muốn => Điều này có thể thực hiện được không? và thực hiện như thế nào?
b) Tìm cách làm cho iptables có thể dùng chain REDIRECT để chuyển hướng packet đến host cụ thể. => Hướng này so với hướng trên cái nào tối ưu hơn? hướng nào dễ dàng hơn?
 

@conmale
Kết quả lệnh lsmod đây anh:
Code:

Module                  Size  Used by
tcp_lp                  1779  0 
iptable_nat             3945  1 
nf_nat                 16298  1 iptable_nat
ipt_LOG                 4243  0 
xt_recent               6622  0 
bluetooth              73233  0 
vboxnetadp              5534  0 
vboxnetflt             16051  2 
vboxdrv               173274  3 vboxnetadp,vboxnetflt
cpufreq_ondemand        7262  2 
acpi_cpufreq            6285  1 
mperf                   1141  1 acpi_cpufreq
ip6t_REJECT             3470  2 
nf_conntrack_ipv6      14441  4 
ip6table_filter         1207  1 
ip6_tables              9929  1 ip6table_filter
ipv6                  229581  18 ip6t_REJECT,nf_conntrack_ipv6
fuse                   51648  9 
uinput                  5228  0 
snd_hda_codec_idt      45770  1 
arc4                    1085  2 
snd_hda_intel          20151  2 
ecb                     1595  2 
snd_hda_codec          71701  2 snd_hda_codec_idt,snd_hda_intel
snd_hwdep               4795  1 snd_hda_codec
b43                   144940  0 
snd_seq                43435  0 
r852                    8298  0 
sm_common               3104  1 r852
nand                   28994  2 r852,sm_common
nand_ids                2730  1 nand
nand_ecc                3460  1 nand
snd_seq_device          5056  1 snd_seq
mac80211              188716  1 b43
b44                    21854  0 
cfg80211              110951  2 b43,mac80211
mtd                    15282  2 sm_common,nand
snd_pcm                61769  2 snd_hda_intel,snd_hda_codec
dell_wmi                2763  0 
snd_timer              15435  2 snd_seq,snd_pcm
mii                     3578  1 b44
snd                    47365  12 snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
soundcore               5088  1 snd
ssb                    42089  2 b43,b44
dell_laptop             5433  0 
snd_page_alloc          6180  2 snd_hda_intel,snd_pcm
wmi                     6667  1 dell_wmi
iTCO_wdt                8960  0 
iTCO_vendor_support     2070  1 iTCO_wdt
rfkill                 13652  4 bluetooth,cfg80211,dell_laptop
i2c_i801                9016  0 
uvcvideo               49189  0 
videodev               60378  1 uvcvideo
joydev                  7306  0 
dcdbas                  6608  1 dell_laptop
microcode              11067  0 
sdhci_pci               6246  0 
sdhci                  15685  1 sdhci_pci
mmc_core               53194  3 b43,ssb,sdhci
firewire_ohci          17697  0 
firewire_core          37873  1 firewire_ohci
crc_itu_t               1235  1 firewire_core
nouveau               360960  4 
ttm                    45014  1 nouveau
drm_kms_helper         22278  1 nouveau
drm                   139248  6 nouveau,ttm,drm_kms_helper
i2c_algo_bit            4197  1 nouveau
video                  17730  1 nouveau
output                  1625  1 video
i2c_core               21445  6 i2c_i801,videodev,nouveau,drm_kms_helper,drm,i2c_algo_bit

- Ky0 - 

Chào anh commle !

Em đang nghiên cứu lại cách phòng chống SYN Flood của anh, nhưng có một số thắc mắc như sau, mong nhận được sự giải đáp:

Em hiểu rằng khi một gói tin có state là NEW đi đến firewall thì sẽ được chuyển vào chain SYN_CHECK, khi đó chain này sẽ đưa IP này vào một danh sách (A) để kiểm tra tính hợp lệ, các rule sau sẽ kiểm tra:
iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j LOG --log-prefix "FLOOD: "
Nếu IP đó gửi >= 10 packet có state NEW trong vòng 1 phút sẽ được LOG lại và DROP bở rule
iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j DROP
Nếu không thoải mãn sẽ tới rule tiếp theo là:
iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 3 --name SYN -j syn
Ý nghĩa của rule trên là những gói tin vào tồn tại trong danh sách A và có hitcount >= 3 mơi dc ACCEPT
Như vậy, nếu 1 IP hợp lệ chỉ gửi một gói tin trong 1 phút như vậy sẽ không match rule nào hết và bị chặn (Điều này hơi vô lý), đó là thắc mắc đầu tiên của em ?
 

1. iptables -N syn
2. iptables -A syn -j ACCEPT
3. iptables -N SYN_CHECK
4. iptables -A SYN_CHECK -m recent --set --name SYN
5. iptables -A INPUT -p tcp --syn -d $IP -m state --state NEW -j SYN_CHECK
 
6. iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j LOG --log-prefix "FLOOD: "
7. iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 10 --name SYN -j DROP
 
8. iptables -A SYN_CHECK -m recent --update --seconds 60 --hitcount 3 --name SYN -j syn
9. iptables -A INPUT -p tcp ! --syn -d $IP -m state --state ESTABLISHED -j ACCEPT
10. iptables -A OUTPUT -p tcp -s $IP -m state --state ESTABLISHED -j ACCEPT

Thắc mắc thứ 2:
Đối với Rule:
iptables -t mangle -A PREROUTING -p tcp -d $IP -m recent --name SYN --update --seconds 120 -j blockip

Nó sẽ xét xem gói tin đó có trong danh sách (A) hay chưa, nếu có sẽ ban trong vòng 120s, vậy làm sao Firewall có thể phân biệt được sự khác nhau giữa những gói tin của IP hợp lệ và IP không hợp lệ.

Mong được sự giải đáp của anh và mọi người ^^ 

Apr 25 08:43:51 webbbp kernel: dst cache overflow
Apr 25 08:43:51 webbbp kernel: printk: 1078 messages suppressed.

Apr 27 13:13:43 webbbp kernel: ip_conntrack: table full, dropping packet.
Apr 27 13:14:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.
Apr 27 13:15:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.
Apr 27 13:17:35 webbbp last message repeated 2 times
Apr 27 13:18:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.
Apr 27 13:19:20 webbbp kernel: ip_conntrack: table full, dropping packet.
Apr 27 13:19:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.

Apr 28 15:02:35 webbbp mod_evasive[5656]: Blacklisting address 117.0.128.159: possible DoS attack.

$IP chính là IP được bound trên external interface trên máy chủ Linux của bồ. 

Mình theo dõi topic này và rút ra nhiều điều bổ ích vì server mình hiện tại cũng đag bị SYN FLOOD.
Mình đã làm theo hướng dẫn của các bạn, mình muốn hỏi xem như nếu file log ghi như thế này thì có phải là thành công trong việc chống syn food chưa

Những ngày bị DDOS

Code:

Apr 25 08:43:51 webbbp kernel: dst cache overflow
Apr 25 08:43:51 webbbp kernel: printk: 1078 messages suppressed.

Apr 27 13:13:43 webbbp kernel: ip_conntrack: table full, dropping packet.
Apr 27 13:14:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.
Apr 27 13:15:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.
Apr 27 13:17:35 webbbp last message repeated 2 times
Apr 27 13:18:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.
Apr 27 13:19:20 webbbp kernel: ip_conntrack: table full, dropping packet.
Apr 27 13:19:35 webbbp kernel: possible SYN flooding on port 80. Sending cookies.

 

Và như thế này là ổn rồi phải ko ta

Code:

Apr 28 15:02:35 webbbp mod_evasive[5656]: Blacklisting address 117.0.128.159: possible DoS attack.

 

$IP chính là IP được bound trên external interface trên máy chủ Linux của bồ. 

Làm sao biết được IP này ? ( sr, mình newbie )  

[root@webbbp ~]# cat /etc/*release*
CentOS release 5.6 (Final)
[root@webbbp ~]# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 34576

[root@webbbp ~]# sysctl -w net.ipv4.netfilter.ip_conntrack_max=90000
net.ipv4.netfilter.ip_conntrack_max = 90000

Kernel and CPU	Linux 2.6.18-238.9.1.el5 on x86_64
Processor information	Intel(R) Xeon(R) CPU E5606 @ 2.13GHz, 4 cores
RAM 8G

Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15

StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000

[root@webbbp ~]# echo `/sbin/ifconfig eth0 | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
112.78.7.xxx

Thắc mắc thứ 2:
Đối với Rule:
iptables -t mangle -A PREROUTING -p tcp -d $IP -m recent --name SYN --update --seconds 120 -j blockip

Nó sẽ xét xem gói tin đó có trong danh sách (A) hay chưa, nếu có sẽ ban trong vòng 120s, vậy làm sao Firewall có thể phân biệt được sự khác nhau giữa những gói tin của IP hợp lệ và IP không hợp lệ.

Mong được sự giải đáp của anh và mọi người ^^ 

Thắc mắc của em ở đoạn này rất hữu lý. Dòng màu đỏ ở trên thiếu 1 phần đó là --hitcount 10, nếu không, nó sẽ block IP ấy ngay từ sau khi thiết lập IP ấy trong bảng theo dõi ở dòng số 7 ở trên rồi . 

Code:

[root@webbbp ~]# cat /etc/*release*
CentOS release 5.6 (Final)
[root@webbbp ~]# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 34576

Mình setup Centos final mà sao kenerl vẫn là loại cũ vậy ?
 

Mình Update lên 90000
Code:

[root@webbbp ~]# sysctl -w net.ipv4.netfilter.ip_conntrack_max=90000
net.ipv4.netfilter.ip_conntrack_max = 90000

90k liệu có đủ chưa ?
 

Với cấu hình máy là
Code:

Kernel and CPU	Linux 2.6.18-238.9.1.el5 on x86_64
Processor information	Intel(R) Xeon(R) CPU E5606 @ 2.13GHz, 4 cores
RAM 8G

Và cấu hình httpd.conf như thế nào cho hợp lý với Syn Flood

Đây là cấu hình httpd của mình.
Code:

Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15

StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000

 

Code:

[root@webbbp ~]# echo `/sbin/ifconfig eth0 | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
112.78.7.xxx

Hóa ra là IP của web. ^^

Đây là Network traffic trong ngày bị ddos , liệu có phải do SyN food gây ra hay chỉ là sai lệch nào đó?
 

longvnit wrote:

Thắc mắc thứ 2:
Đối với Rule:
iptables -t mangle -A PREROUTING -p tcp -d $IP -m recent --name SYN --update --seconds 120 -j blockip

Nó sẽ xét xem gói tin đó có trong danh sách (A) hay chưa, nếu có sẽ ban trong vòng 120s, vậy làm sao Firewall có thể phân biệt được sự khác nhau giữa những gói tin của IP hợp lệ và IP không hợp lệ.

Mong được sự giải đáp của anh và mọi người ^^ 

Thắc mắc của em ở đoạn này rất hữu lý. Dòng màu đỏ ở trên thiếu 1 phần đó là --hitcount 10, nếu không, nó sẽ block IP ấy ngay từ sau khi thiết lập IP ấy trong bảng theo dõi ở dòng số 7 ở trên rồi . 

Vậy --hitcount thêm vào trước --name SYN phải không?
Như là : iptables -t mangle -A PREROUTING -p tcp -d $IP -m recent --hitcount 10 --name SYN --update --seconds 120 -j blockip 

OK. IP của bồ bị SYN Flood với cường độ khoảng 41 ngàn SYN / 1 giây từ các IP thuộc VN (100% là của VN). Mỗi IP chỉ gởi tối đa 1 SYN trong mỗi 2 giây (nhiêu IP chỉ gởi 1 SYN trong 4 - 5 giây) và cổng bị dập là 33443 và 34444. Bởi vậy, cách chống SYN Flood bình thường không tác dụng vì khoảng cách mỗi củ SYN đi từ 1 IP cách nhau khá xa. Bồ thử dùng biện pháp sau:
 

conmale wrote:

OK. IP của bồ bị SYN Flood với cường độ khoảng 41 ngàn SYN / 1 giây từ các IP thuộc VN (100% là của VN). Mỗi IP chỉ gởi tối đa 1 SYN trong mỗi 2 giây (nhiêu IP chỉ gởi 1 SYN trong 4 - 5 giây) và cổng bị dập là 33443 và 34444. Bởi vậy, cách chống SYN Flood bình thường không tác dụng vì khoảng cách mỗi củ SYN đi từ 1 IP cách nhau khá xa. Bồ thử dùng biện pháp sau:
 

Cho e hỏi, làm sao mình có thể biết được những thông tin như vậy từ file dump?