Xin lỗi, mình hỏi thêm trong topic này: Hiện tại mình dùng iptables để match string nhưng vẫn không lọc được các request mang các string "lạ", ví dụ mình dùng:
Code:

iptables -A INPUT -p tcp --dport 80 -m string --string "string" -j DROP --algo bm

Nhưng các request với dấu hiệu trên vẫn vô tư vào tới apache mà không hề bị cản lọc. Mình đã kiểm tra modprobe ipt_string và nó đã được tự động loaded.


Vậy xin cho hỏi lí do vì sao iptables ko match được string trên? Liệu ipt_string của mình có quá cũ (Centos 5.2, Kernel 2.6.18-92.1.22.el5-x86_64).

Chân thành cảm ơn.  

Xin lỗi, mình hỏi thêm trong topic này: Hiện tại mình dùng iptables để match string nhưng vẫn không lọc được các request mang các string "lạ", ví dụ mình dùng:
Code:

iptables -A INPUT -p tcp --dport 80 -m string --string "string" -j DROP --algo bm

Nhưng các request với dấu hiệu trên vẫn vô tư vào tới apache mà không hề bị cản lọc. Mình đã kiểm tra modprobe ipt_string và nó đã được tự động loaded.


Vậy xin cho hỏi lí do vì sao iptables ko match được string trên? Liệu ipt_string của mình có quá cũ (Centos 5.2, Kernel 2.6.18-92.1.22.el5-x86_64).

Chân thành cảm ơn.  

Hi Secmask,
Mình chỉ được quản lí một server thôi , chắc bạn thắc mắc vì thấy iptables không match được string, và trong rule mình không chỉ định Destination IP.

Sau khi sử dụng discard service, dùng rule của anh conmale, kết quả:


Code:

# iptables -t nat -L -v -n 
Chain PREROUTING (policy ACCEPT 661K packets, 33M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   661K   33M REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 STRING match "muviet" ALGO name bm TO 65535 www ports 9 
........
........

String mà mình match là muviet
Khá là hoàn hảo. 

@Conmale,StarGhost: Cám ơn 2 anh, em cũng phần nào hiểu được cơ chế hoạt động của PREROUTING, và "match string" rồi.

Riêng về phần xác định offset của string để em tìm hiểu, sẽ cố gắng trả bài sau. Nếu được anh cho em một ví dụ thì sẽ học được nhanh hơn . Trước giờ em toàn giới hạn offset theo kiểu đoán và "mò" không .
 

À, em còn câu hỏi đầu bài chưa tìm ra lời đáp, vì trong trường hợp này, nếu không có dấu hiệu để nhận biết bằng match string, thì em nghĩ giải pháp null routing là rất khả dụng. Liệu cách đó có thể thực hiện được không?
 

Anh,

Đầu năm có vẻ anh ăn chơi thả cửa nhỉ
 

Nhìn vào đoạn script iptables của anh, công đoạn được thực hiện theo cách thức: log sau đó dựa vào log để drop. Và hầu như tất cả các rules anh đưa ra đều có những giá trị được anh "pre-define" cụ thể từ trước, mà những giá trị này không phải ông System Admin nào cũng biết rõ và đưa ra những con số ngay được.

Đoạn rule của anh là kết quả của quá trình nghiên cứu các phương thức tấn công, và...có lẽ anh trải nghiệm nhiều trong việc đối phó với tấn công từ chối dịch vụ, ví dụ như em nếu gặp trường hợp bị A tấn công bằng phương thức 1, em chỉ cố găng bằng cách nào đó đưa ra những rule để đối phó với A, mà nếu tiếp theo có ông B thì cách thức dùng để đối phó với A trở nên vô dụng với B, em lại mày mò cách đối phó với B. Nói chung em không có kế hoạch rõ ràng, và không tính đến một bài toán mang tính toàn vẹn...như anh.
 

Điều em thắc mắc là rõ ràng ta không thể cùng một lúc vừa log vừa drop, nên anh chỉ định các user-define-table, list, log-prefix để dựa vào đó lọc ra các packet "vi phạm". Nhưng liệu việc ghi log như thế có thực sự bền bỉ? Vì cũng như anh từng nói việc ghi log liên tục như thế chiếm dụng rất nhiều tài nguyên của server, cho dù anh có đưa ra giá trị --limit-burst, theo em con số này có vẻ khá quan trọng trong đoạn iptables script của anh. Em chưa nghĩ ra anh đặt là bao nhiêu, trước giờ em toàn không ấn định cụ thể (5).
 

Và những rule bên trên cũng không thể chống đối với dạng tấn công liên tục từ rất nhiều nguồn, làm bão hoà đường truyền. Tác vụ ghi log làm firewall tốn khá nhiều thời gian, và nếu như em đặt ra một rule thế này:

iptables -A INPUT -p tcp --syn -m limit --limit 1/s –j ACCEPT

thì em kiểm tra, có lúc chính nó làm server load tăng vọt, có khi hoàn toàn trì trệ. Vậy log + drop sẽ chậm hơn rất nhiều và tác vụ xử lí sẽ tốn server load hơn so với chỉ drop, phải không anh?
 

Đọc xong đoạn rule của anh em nghĩ mình phải học lại kiến thức căn bản về iptables, nhiều rule em đọc xong google từng option mới mườn tượng ra được cách thức hoạt động của nó. Em đang đọc phần conntract:
http://www.faqs.org/docs/iptables/theconntrackentries.html
 

Hiện tại server bên em được bên cung cấp đặt sau lưng con Pix firewall, nhưng chả hiểu bên đấy config thế nào packet vẫn vào như nhà không cửa .
 

Em thử áp dụng script của anh lại gặp phải lỗi iptables:
Code:

#iptables -A INPUT -p tcp -d $myip --dport 80 -m state --state ESTABLISHED -m connlimit --connlimit-above 4 -j DROP
iptables: Unknown error 18446744073709551615

 

Có lẽ em nên post vào box khác hợp lí hơn. Cám ơn anh rất nhiều, đang bị bội thực kiến thức  

mong năm mới anh conmale cho thêm vài đoạn nữa. 

Mr. Bi thân mến,

Mấy hôm nay anh "bị" liên hoan triền miên, xỉn triền miên nên không vào diễn đàn nên không hồi báo sớm hơn.

"Vấn nạn" của em gặp phải cũng là vấn nạn mà HVA gặp phải trước đây. Kỹ thuật "detect" dấu hiệu bị tấn công phụ thuộc vào những điểm đặc thù để dựa vào đó mà xử lý. Lần trước, điểm đặc thù em có thể tìm thấy là string "muviet". String này có thể sẽ thay đổi thường xuyên, thậm chí thay đổi random trong mỗi request. Bởi thế, khi chọn lựa một thứ "vũ khí" để chống đỡ, em cần suy nghĩ đến biên độ rộng nhất mà "vũ khí" này có thể bảo vệ em.

Trong trường hợp không còn "string" (dấu hiệu cụ thể) nào cả thì cần xét kỹ hơn: điểm nào là điểm đặt thù của các packets trên? Nếu em chọn dấu hiện referer www.yahoo.com thì em vô tình cản luôn các request hợp lệ chuyển từ trang tìm kiếm của yahoo vào site của em. Đây là cách không tối ưu.

Hãy xét xem, tâng số của các requests tấn công em khác các request bình thường thế nào? Các request bình thường (đi từ 1 IP) có khi nào gởi liên tục 10, 20, 30, 40 requests trong 1 giây không? --> đây cũng là điểm đặc thù em có thể dùng để chọn "vũ khí" mới để tự vệ vậy.

Anh giới thiệu em một đoạn "adaptive" rule dùng module recent để "trị" dạng DDoS không có dấu hiệu (string) gì ngoài tầng số tấn công:

Code:

# create an incoming table to control packets base on recent rules
iptables -N incominghttp

# create a conn table to control maximum connection per IP
iptables -N conn
iptables -A conn -j DROP

# create a blacklist table
iptables -N blacklist
iptables -A blacklist -j LOG --log-prefix "BLACKLISTING: "
iptables -A blacklist -m recent --name BLACKLIST --set -j DROP


# create a httpnormal to control normal flow of http if above is satisfied
iptables -N httpnormal

# now add rules into it (httpnormal)
iptables -A httpnormal -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport 80 -m state --state NEW -m limit --limit 1/m -j LOG --log-prefix "NEWNOTSYN_HTTP: "
iptables -A httpnormal -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport 80 -m state --state NEW -j DROP

iptables -A httpnormal -p tcp --syn -s $NET -d $IP --dport 80 -m limit --limit 10/m --limit-burst $BURST_ME -j LOG --log-prefix "SYNFLOOD: "
iptables -A httpnormal -p tcp --syn -s $NET -d $IP --dport 80 -m state --state NEW -m limit --limit $SYN_ME --limit-burst $BURST_ME -j ACCEPT
iptables -A httpnormal -p tcp --syn -s $NET -d $IP --dport 80 -m state --state NEW -j ACCEPT
iptables -A httpnormal -p tcp --syn -s $NET -d $IP --dport 80 -m limit --limit $SYN_ME --limit-burst $BURST_ME -j LOG --log-prefix "OVER_BURST: "
iptables -A httpnormal -p tcp --syn -s $NET -d $IP --dport 80 -m limit --limit $SYN_ME --limit-burst $BURST_ME -j conn

iptables -A httpnormal -p tcp -s $NET -d $IP --dport 80 -m state --state ESTABLISHED -m connlimit --connlimit-above $GLOBAL -m limit --limit 2/m -j LOG --log-prefix "OVERCONNLIMIT: "
iptables -A httpnormal -p tcp -s $NET --sport $HI_PORTS -d $IP --dport 80 -m conntrack --ctstate INVALID -j LOG --log-prefix "INVALID: "
iptables -A httpnormal -p tcp -s $NET --sport $HI_PORTS -d $IP --dport 80 -m conntrack --ctstate INVALID -j DROP
iptables -A httpnormal -p tcp -s $NET --sport $HI_PORTS -m state --state ESTABLISHED -d $IP --dport 80 -m connlimit ! --connlimit-above $GLOBAL -j ACCEPT
iptables -A httpnormal -p tcp -s $NET --sport $HI_PORTS -m state --state ESTABLISHED -d $IP --dport 80 -m connlimit --connlimit-above $GLOBAL -j conn
echo "connlimit is defined"

# After defining INPUT, only allow OUTPUT as ESTABLISHED state
# There should be no SYN packet from port 80 of HTTP server
# Using own server to initiate request to other sites is impossible
iptables -A OUTPUT -p tcp -s $IP --sport 80 -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT

# then allow all ESTABLISHED INPUT without SYN
# Once the connection is ESTABLISHED (passed all the rules above) - should not restrict rate to maximise performance
iptables -A httpnormal -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport 80 -m state --state ESTABLISHED -j ACCEPT

# rate limiting on incoming http packets and keep a blacklist for 60 seconds
# this rule drops *any* packet if the IP is in the blacklist
iptables -A incominghttp -m recent --name BLACKLIST --update --seconds 60 -j DROP

# all *established* http connections are allowed to continue
iptables -A incominghttp -p tcp --dport 80 -m state --state ESTABLISHED,RELATED -j httpnormal

# all *new* http connections are all put into a list 'httpconn'
# if there are 20 SYN packets in 30 seconds (as defined in variables SECS and HITS above)
# we send the package to chain 'blacklist ' which puts the IP in the blacklist
iptables -A incominghttp -p tcp --dport 80 -m state --state NEW -m recent --name httpconn --rcheck --seconds $SECS --hitcount $HITS -j blacklist

# if we have seen less then 20 such packets in the last 30 seconds we accept
# and direct the packets to the normal http chain httpnormal
iptables -A incominghttp -p tcp --dport 80 -m state --state NEW -m recent --name httpconn --set -j httpnormal

echo "Start the actual http rule..."
$IPTABS -A INPUT -p tcp -s $NET -d $IP --dport 80 -j incominghttp
echo "The HTTP service is provided"
}

Em xem và suy nghĩ về đoạn rule trên và cho anh biết em đã đúc kết được những gì nhá? . 

root@i3network:/etc/init.d# sh entry-conmale
iptables: Chain already exists
iptables: Chain already exists
iptables: Chain already exists
iptables: Chain already exists
Bad argument `limit'
Try `iptables -h' or 'iptables --help' for more information.
Bad argument `ACCEPT'
Try `iptables -h' or 'iptables --help' for more information.
Bad argument `conn'
Try `iptables -h' or 'iptables --help' for more information.
connlimit is defined
Start the actual http rule...
entry-conmale: 65: -A: not found
The HTTP service is provided

Phó Hồng Tuyết wrote:

mong năm mới anh conmale cho thêm vài đoạn nữa.



Vài đoạn gì em?