Messages posted by: crazym

Gói tin sẽ như thế này:

Từ LAN (SRC: INT; DES: EXT) ===> Di chuyển đến SQUID
lúc này sẽ: (SRC: INT; DES: SQUID) ===> DNAT để đổi địa chỉ đích thành SQUID và ép chạy sang DMZIF
tiếp tục (SRC: SQUID; DES: EXT) ==== SNAT để đổi địa chỉ nguồn thành EXTIP và địa chỉ đích giữ nguyên
Xuyên suốt có các rule cho phép từ INT -- SQUID -- EXT. Cụ thể hoá bằng rule trên vẫn chết là thế nào nhỉ??? Sắp phát khùng rồi

Tình hình sau khi nghiên cứu các gợi ý của anh Conmale và các bạn, rule đã đựoc điều chỉnh như sau:

I) Loại bỏ trong TCP_OUT port 80. thêm rule:

1. $IPT -t nat -A PREROUTING -i $INTIF -s $INTNET -p tcp --dport 80 -j DNAT --to $SQUID_BOX:8080

=> Rule này áp dụng đối với traffic đi vào $INTIF (LAN) có port nguồn 80 bất kỳ sẽ phải đổi src thành $SQUID:8080

2. $IPT -t nat -A POSTROUTING -o $DMZIF -s $SQUID_BOX -d $EXTNET -j SNAT --to $DMZIP

=> Tiếp tục đổi địa chỉ nguồn của gói tin đi đến DMZIF(ở đây là SQUID) thành DMZIP
=> Tiếp tục di chuyển, gói tin sẽ đi vào DMZIF để ra EXTIF

3. $IPT -t nat -A POSTROUTING -o $EXTIF -p tcp --dport 80 -j SNAT --to $EXTIP

=> Tiếp tục thay đổi địa chỉ nguồn để gói tin ra ngoài internet

Ngoài các rule trên, bổ sung thêm các rule sau:

4. $IPT -A FORWARD -s $INTNET -d $SQUID_BOX -i $INTIF -o $EXTIF -s $INTNET -d $EXTNET --dport 80 -j ACCEPT

Đã ép được traffic từ LAN đến port 80 bất kì sang SQUID(DMZIF) tuy nhiên client vẫn không thể duyệt web được. smilie

Bế tắc quá smilie

Tớ đang thử viết lại. Thank cậu.

MickyNQN wrote:

crazym wrote:
Hôm nay tiến hành thử 3 kiểu:
Code:
| LAN | Eth0(1.40)---------------- Eth0(1.10) | IPTABLE | Eth1(2.100) ------------- | INTERNET |
========
| Eth2(10.10.10.1)
|
| Eth0 (10.10.10.10)
========
| SQUID |
========
Xin lỗi bữa trước mình không để ý mô hình của bạn Mình correct như sau:

1: Các gói tin qua eth0 được DNAT tới SQUID.
2: Cho phép các gói tin này được chuyển tiếp giữa eth0 và eth2.
3: Cho phép SQUID ra ngoài Internet.

Nhìn lại cấu hình SQUID của bạn nữa: acl src home_work 10.10.10.0/24 , home_work ở đây là LAN chứ phải không bạn ??? Sao bạn lại để dải địa chỉ này !

@crazym: Hình như bạn không nhớ địa chỉ và các interface mà cũng không nhìn mô hình khi viết rule thì phải.

#Tớ có nhớ chứ, vụ home_work thì tớ viết thiếu, phải thêm cả dải của mạng LAN vào nữa smilie

, thực ra tớ biết các mục 1),2),3) bạn đề cập cũng như a Conmale nói rồi nhưng cụ thể hoá nó bằng rule thì thật sự không đơn giản. Thank bạn đã giúp đỡ nhé.
P/S: 1: Các gói tin qua eth0 được DNAT tới SQUID. ==> Eth0 này là INTIF nhỉ smilie

(trên kia có 3 cái Eth0 lận mà).

Em hiểu rồi anh ạ. Em cũng không thích và không muốn "xin Rule". Có điều gợi ý này:

Trọng tâm nằm ở chỗ traffic đi từ LAN đến cổng 80 bất kỳ phải đi xuyên qua DMZ_IF thì mới có thể đến SQUID được. Nếu em không có luật nào để ép traffic như vậy thì nó cứ việc đi thẳng ra ngoài EXT_IF chớ chẳng có lý do gì phải đi xuyên qua DMZ_IF hết. Em cần thiết lập thêm luật.

không đơn giản đối với người vừa bắt đầu tìm hiểu để biến nó thành Rule cụ thể. Điều mà các newbie cần là gợi ý sát sườn để cụ thể hoá thành Rule. Em cám ơn anh đã hỗ trợ em. Rất mong trong tương lai tiếp tục nhận đc sự giúp đỡ của anh và các bạn ở đây.

P/S: bài hướng dẫn của anh coi như là một tutorial nên hoàn toàn có thể copy&paste được chứ smilie

, có điều cần hiểu rõ toàn bộ đoạn copy&paste đúng không ạ. Thanks anh phát nữa.

Đây là dạng DMZ thường thấy. Trong trường hợp mô hình mạng không có DMZ, bạn có thể gắn thêm một NIC thứ ba trên firewall và ấn định một IP thuộc subnet khác cho NIC thứ ba này để nối tiếp với squid cache server bằng cross cable. Đây là một dạng 'mini' DMZ thường thấy ở các công ty nhỏ.

Tôi không đi sâu vào chi tiết thiết kế topology ở đây. Những dạng trên chỉ là các gợi ý tổng quát. Điểm chính yếu bạn cần lưu tâm là firewall server và squid cache server phải liên lạc được với nhau trên căn bản nối tiếp.

Giả định squid đang "lắng nghe" trên cổng 8080 của IP 10.10.10.10, trên một server riêng biệt và được kết nối với firewall server xuyên qua cross cable,

Em cứ nghĩ hướng dẫn trên của anh có sử dụng thêm một card IF(eth2) gắn với SQUID, nếu thế thì nó rơi vào trường hợp SQUID nối tiếp với Firewall và ra mạng Internet hoặc SQUID nằm giữa mạng LAN và Firewall.
# Em hiểu ý anh về vấn đê ép lưu thông đến SQUID từ mạng LAN rồi nhưng a gợi ý thêm cho em về RULE đó một chút nữa được không ạ? smilie

Quyết tâm chờ tin các bác.

Hôm nay tiến hành thử 3 kiểu:
# IPTABLES -F: flush hết các rule trong iptables. từ client tiến hành truy cập một website bằng ip thì Access.log của SQUID đã Gen ra.
# Trong RULE của IPTABLES, -P FORWARD ACCEPT chứ không DROP ==> SQUID đã cache,log, truy cập đến web bằng IP thì ok còn domain thì không được?
# Thử tiếp với rule như trên nhưng tại RULE : $IPT -P FORWARD DROP -> ACCEPT --> SQUID tiếp tục GEN ra access.log, tuy nhiên trình duyệt thông báo Access Denied, mặc dù trong cấu hình SQUID đã thực hiện:

acl src home_work 10.10.10.0/24
acl bhour ......
http_access allow home_work bhour

=> tuy nhiên vẫn không truy cập web đựoc
=> Điều đó chứng tỏ ở FORWARD của hệ thống RULE trên có vấn đề.
Em muốn hỏi anh commale chút là em đã thực hiện cấu hình như đúc của anh nhưng vẫn không vào đựoc, liệu các cấu hình trên có cần bổ sung gì thêm không ạ?

Mô hình của em là như thế này
Code:

| LAN | Eth0(1.40)---------------- Eth0(1.10) | IPTABLE | Eth1(2.100) ------------- | INTERNET |
========
| Eth2(10.10.10.1)
|
| Eth0 (10.10.10.10)
========
| SQUID |
========

chắc là sẽ khác với cấu hình cho mô hình này :http://www.skullbox.net/squid.php đúng không ạ? Rất mong đựoc sự giúp đỡ của anh và các bạn.
P/S: Hiện tại khi chạy script của firewall, xuất hiện report này:
Using intrapositioned negation (`--option ! this`) is deprecated in favor of extrapositioned (`! --option this`).
Hình như là một bug của IPTABLES?

conmale wrote:

crazym wrote:

Theo em hiểu nó sẽ là:

1) Mọi gói tin đi vào $DMZIF (ở đây là eth2 - tiếp diện SQUID của iptables) và có port đích là 80 (request http) thì được chuyển đến port 8080 của SQUID(eth0). Trong đó DNAT để đổi đích của gói tin(từ nội mạng - INTNET - "là một đích http nào đó" thành IP của SQUID

2) Mọi gói tin đi ra từ $DMZIF (ở đây là eth2 - tiếp diện SQUID của iptables) có nguồn là nội mạng ($INTNET) và có đích là IF của SQUID sẽ được thay đổi địa chỉ nguồn(SNAT) trước khi chuyển đến $DMZIP.

3) Theo anh hướng dẫn thì "gói tin từ mạng Lan đến đích mà đích không phải là firewall thì phải qua FORWARD CHAIN" nên cần phải có thiết lập này để chuyển mọi gói tin từ $INTNET đến DMZIF
Như vậy, khi gói tin bắt đầu vào đi vào $INTIF, iptables sẽ check "đích của gói tin" đó. Nếu là http request ---> Bắt đầu đổi đích (ip nào đó) thành IP của SQUID trên port 8080, sau khi đi vào SQUID, SQUID lại đổi nguồn của gói tin này(đang là IP nội mạng --> thành IP SQUID) và đi ra DMZIF.
Đến đây thì em loạn luôn. (.

Và cái gì khiến cho traffic đi từ LAN đến cổng 80 bất kỳ phải đi xuyên qua DMZIF để buộc phải đến SQUID?

#Theo em hiểu là em chưa có rule này trong cấu hình firewall của em smilie

, đúng ko anh?

MickyNQN wrote:

Mình cũng mới tìm hiểu IPtables. Có gì chưa chuẩn bạn correct dùm nhé.

Các dòng bạn nói và rule tại chain POSTROUTING (qua External interface của firewall ) cho phép các gói tin từ toàn mạng LAN (PROXY và clients) được ra ngoài mạng.
Bạn Drop dòng đó thì mặc định toàn bộ gói tin từ trong mạng ra ngoài mạng sẽ bị drop tại chain FORWARD.
Nếu bạn muốn kiểm tra thì chỉ việc ACCEPT các gói tin từ PROXY forward qua firewall thôi. Còn mặc định các gói tin từ LAN ra (trừ PROXY) sẽ bị drop.
Nhưng việc này không cần thiết vì rule cho chain PREROUTING đã ép các gói tin tới proxy rồi. Mình không thạo cách đọc tcp dump, bạn cho mình hỏi, mấy dấu hiệu trên là do bạn ping tới domain nào đó hay là bạn duyệt web ? Bởi vì icmp và request port 53 ở ngoài không bị ép đi qua PROXY.

#Dấu hiệu trên khi tớ duyệt web thì tcpdump trên IF của SQUID xuất ra thế bạn a.

Cấu hình của tớ ở trên, bản thân cấu hình này đã là chuẩn của anh Comale rồi nên chưa biết điều chỉnh như thế nào?
Về ý kiến của bạn tớ thử không đựoc rùi, bỏ hết các điều kiện ở dòng 58,63,68 thì client không vào đựoc mạng luôn.

Theo em hiểu nó sẽ là:

1) Mọi gói tin đi vào $DMZIF (ở đây là eth2 - tiếp diện SQUID của iptables) và có port đích là 80 (request http) thì được chuyển đến port 8080 của SQUID(eth0). Trong đó DNAT để đổi đích của gói tin(từ nội mạng - INTNET - "là một đích http nào đó" smilie

thành IP của SQUID

2) Mọi gói tin đi ra từ $DMZIF (ở đây là eth2 - tiếp diện SQUID của iptables) có nguồn là nội mạng ($INTNET) và có đích là IF của SQUID sẽ được thay đổi địa chỉ nguồn(SNAT) trước khi chuyển đến $DMZIP.

3) Theo anh hướng dẫn thì "gói tin từ mạng Lan đến đích mà đích không phải là firewall thì phải qua FORWARD CHAIN" nên cần phải có thiết lập này để chuyển mọi gói tin từ $INTNET đến DMZIF
Như vậy, khi gói tin bắt đầu vào đi vào $INTIF, iptables sẽ check "đích của gói tin" đó. Nếu là http request ---> Bắt đầu đổi đích (ip nào đó) thành IP của SQUID trên port 8080, sau khi đi vào SQUID, SQUID lại đổi nguồn của gói tin này(đang là IP nội mạng --> thành IP SQUID) và đi ra DMZIF.
Đến đây thì em loạn luôn. smilie

(.

Vẫn đang chờ tin các bác smilie

Liệu có phải nó đã "used" và "transparent" không nhỉ? Vì thực tế khi kiểm tra trên eth2(card nối tiếp với SQUID của IPTABLES) bằng:
#tcpdump -i eth2
thì thấy dấu hiệu gói tin chạy qua đây khi client duyệt web:
Code:

14:21:46.331585 IP6 fe80::76ea:3aff:fe86:22ba.mdns > ff02::fb.mdns: 0 PTR (QM)? 200.1.1.10.in-ddr.arpa.(41)
14:21:46.449230 IP6 fe80::76ea:3aff:fe86:22ba.mdns > ff02::fb.mdns: 0 PTR (QM)? 99.142.148.180.in-addr.arpa. (45)
14:21:47.450055 IP6 fe80::76ea:3aff:fe86:22ba.mdns > ff02::fb.mdns: 0 PTR (QM)? 99.142.148.180.in-addr.arpa. (45)
14:21:48.332715 IP6 fe80::76ea:3aff:fe86:22ba.mdns > ff02::fb.mdns: 0 PTR (QM)? 200.1.1.10.in-addr.arpa. (41)
14:21:49.451613 IP6 fe80::76ea:3aff:fe86:22ba.mdns > ff02::fb.mdns: 0 PTR (QM)? 99.142.148.180.in-addr.arpa. (45)

Bên hướng SQUID server, TCPDump cũng bắt gói tin như vậy. Tuy nhiên check access_log và cache_log của SQUID lại không có gì???

Mô hình của em thế này:

LAN (A) ----- (eth0) iptables(C) (eth1) ----- Internet (D)
===========||(eth2)
---------------- ||
---------------|| squid (B)

@Conmale: Thanks anh. Bản Squid em install có complied "--enable-linux-netfilter". Hiện tại Squid đã listen ok ở port 8080.
Có một điều em muốn hỏi, em đã cấu hình như mô hình QUANTA đưa ra, về rule thì gần giống anh hứong dẫn nhưng sau khi cài đặt tất cả xong, Em duyệt client ra mạng internet nhưng cảm thấy vẫn "bình thừong"
và hình như gói tin không bị "ép" chạy qua proxy. Liệu em có làm sai ở đâu không anh? Rất mong hồi âm của anh
============
Đây là bảng định tuyến smilie

trên firewall Iptables + Trên này em có config DHCP cấp ip cua nội mạng)
Code:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
10.10.10.0 * 255.255.255.0 U 0 0 0 eth2
10.1.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 0 0 0 eth1

============
Cấu hình ITABLES RULE:
Code:

#!/bin/sh
IPT="/sbin/iptables"
echo "1" > /proc/sys/net/ipv4/ip_forward
INTIF="eth0"
INTIP="10.1.1.10"
INTNET="10.1.1.0/24"
LOIF="lo"
LOIP="127.0.0.1"
EXTIF=`/sbin/route | grep -i 'default' | awk '{print$8}'`
EXTIP=`/sbin/ifconfig $EXTIF | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
EXTNET=any/0
DMZIF="eth2"
DMZIP="10.10.10.1"
SQUID_BOX="10.10.10.10"
OK_ICMP="0 3 4 8 11"
TCP_OUT="80 110 443 5000 5010 5100 8800 8081"
UDP_OUT="53"
OK_MAC="00:23:8b:3d:f1:50"
NOTOK_MAC="90:FB:A6:90:434"
HI_PORTS="1024:65535"
DNS="208.67.222.222 208.67.220.220"
$IPT -F
$IPT -F -t nat
$IPT -F -t filter
$IPT -F -t mangle
$IPT -t mangle -X
$IPT -t nat -X
$IPT -X
$IPT -Z INPUT
$IPT -Z OUTPUT
$IPT -Z FORWARD
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
#$IPT -A INPUT -i $INTIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# Allow firewall to access Internet
$IPT -A OUTPUT -o $EXTIF -p tcp -m state --state NEW,ESTABLISH,RELATED -j ACCEPT
$IPT -A INPUT -i $EXTIF -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
#Allow client to access FIREWALL
$IPT -A INPUT -i $INTIF -p tcp -s $INTNET -d $INTIP --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o $INTIF -p tcp -s $INTIP --sport 22 -d $INTNET -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i $LOIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o $LOIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
for dns in $DNS; do
$IPT -A INPUT -i $EXTIF -p udp -s $dns --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o $EXTIF -p udp -d $dns --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i $EXTIF -p udp -s $EXTNET --sport 53 -d $EXTIP --dport $HI_PORTS -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o $EXTIF -p udp -s $EXTIP --sport $HI_PORTS -d $EXTNET --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i $INTIF -p udp -s $INTNET --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o $INTIF -p udp -d $INTNET --sport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i $LOIF -p udp -s $INTNET --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o $LOIF -p udp -d $INTNET --sport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
done
for icmp in $OK_ICMP; do
$IPT -A FORWARD -p icmp --icmp-type $icmp -i $INTIF -o $EXTIF -s $INTNET -d $EXTNET -j ACCEPT
echo "Allowed ICMP types: $icmp"
done
for ports in $TCP_OUT; do
$IPT -A FORWARD -p tcp -i $INTIF -o $EXTIF -s $INTNET -d $EXTNET --dport $ports -j ACCEPT
echo "Allowed forward port $ports"
done
for ports in $UDP_OUT; do
$IPT -A FORWARD -p udp -i $INTIF -o $EXTIF -s $INTNET -d $EXTNET --dport $ports -j ACCEPT
echo "Allowed forward port $ports"
done
for macs in $OK_MAC; do
$IPT -A FORWARD -p tcp -i $INTIF -o $EXTIF -m mac --mac-source $macs -d $EXTNET --dport 20:22 -j ACCEPT
echo "Allowed forward mac $macs to ftp"
done
for banmac in $NOTOK_MAC; do
$IPT -A FORWARD -p tcp -i $INTIF -o $EXTIF -m mac --mac-source $banmac -d $EXTNET -j REJECT
echo "Banned MAC adddress $banmac is applied"
done
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP
#DANH CHO SQUID
$IPT -t nat -A PREROUTING -i $DMZIF -p tcp -s !$SQUID_BOX --dport 80 -j DNAT --to $SQUID_BOX:8080
$IPT -t nat -A POSTROUTING -o $DMZIF -s $INTNET -d $SQUID_BOX -j SNAT --to $DMZIP
$IPT -A FORWARD -p tcp -s $INTNET -d $SQUID_BOX -i $DMZIF -o $DMZIF --dport 8080 -j ACCEPT
$IPT -A INPUT -i $INTIF -j LOG --log-prefix "BAD_INPUTS: "
$IPT -A INPUT -i $INTIF -j DROP
$IPT -A OUTPUT -o $EXTIF -j LOG --log-prefix "BAD_OUTPUTS: "
$IPT -A OUTPUT -o $EXTIF -j DROP
$IPT -A FORWARD -i $INTIF -o $EXTIF -j LOG --log-prefix "BAD_FORWARD_OUT: "
$IPT -A FORWARD -i $INTIF -o $EXTIF -j DROP
$IPT -A FORWARD -i $EXTIF -o $INTIF -j LOG --log-prefix "BAD_FORWARD_IN: "
$IPT -A FORWARD -i $EXTIF -o $INTIF -j DROP

====================================================
Cấu hình SQUID:
Hiên tại đang defaule, em chỉ để mỗi:
http_port 8080 transparent

Lại phải up cái bài này lên.
khi cấu hình Squid theo mô hình như Quanta "vẽ" ở trên, tớ config Squid như hướng dẫn của anh Commale nhưng xuất hiện lỗi như sau:

parseConfigFile: unrecognized 'httpd_accel_host virtual'
parseConfigFile: unrecognized 'httpd_accel_port 80'
parseConfigFile: unrecognized 'httpd_accel_with_proxy on'
parseConfigFile: unrecognized 'httpd_accel_uses_host_header on'

Squid 2.7 stable9 cài trên DEBIAN SQZ:
+ Các cài đặt thì apt-get install squid
+ Vào config thêm các dòng trên của Anh Commale và thêm cái visible_hostname thôi.

Đọc một số hướng dẫn và comment:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377950 -> ở đây nói là bị bug ở versions trước 2.6
We believe that the bug you reported is fixed in the latest version of squid
+ Mặc dù đã điều chỉnh như: http_port 8080 transparent nhưng khi restart services Squid vẫn bị thông báo lỗi như trên.
Ý nghĩa của các thông số trên:
+ httpd_accel_host virtual: Squid will use the request header information to figure out what server the user wants to access and Squid will behave as a web server when dealing with the client.
+ httpd_accel_port 80 configures Squid to send out requests to origin servers on port 80, even though it may be receiving requests on another port, 3128 for example.
+ httpd_accel_with_proxy on allows you to continue using Squid as a traditional proxy as well as a transparent proxy.
+ httpd_accel_uses_host_header on tells Squid that it should figure out what server to fetch content from based on the host name found in the header. This option must be configured this way for transparency.

Rất mong đựoc sự hỗ trợ của các bạn.

Diễn đàn bảo trì lâu quá không pm được.
Nói như Secmask đây không phải là Sync flood vậy thì nó là một kiểu attack gì? Hay là giả mạo User-agent.

Tớ hiểu ý Secmask rồi và cũng biết là SYNC flood attack sẽ chỉ có các kết nối chưa hoàn thành. Vậy:

#Phía máy Attack(1 client):

TCP ***-xp:1930 10.1.1.60:http SYN_SENT
TCP ***-xp:1931 10.1.1.60:http SYN_SENT
TCP ***-xp:1932 10.1.1.60:http SYN_SENT
TCP ***-xp:1933 10.1.1.60:http SYN_SENT
TCP ***-xp:1934 10.1.1.60:http SYN_SENT

#Phía máy server:

C:\Documents and Settings\home>netstat -a | find /C "TIME_WAIT"
1345
Nếu nói không liên quan nhau sau số TIME_WAIT lên vùn vụt vậy và phải chăng tool tớ đang test không phải là SYNC flood, thôi tớ đưa link tool luôn nhé http://www.mediafire.com/?giykj25zizg)
===============================
Một ít log apache server.
===============================
10.1.1.101 - - [29/Jul/2011:09:04:42 +0700] "GET / HTTP/1.1" 500 626 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; .NET CLR 1.0.3705)"
10.1.1.101 - - [29/Jul/2011:09:04:42 +0700] "GET / HTTP/1.1" 500 626 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; .NET CLR 1.0.3705)"
10.1.1.101 - - [29/Jul/2011:09:04:42 +0700] "GET / HTTP/1.1" 500 626 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; .NET CLR 1.0.3705)"
=> "GET / HTTP/1.1" 500 626 " => Cái này do mình chặn bằng mod_security (SecRule Request header) vì mình nghĩ nó fake USER-AGENT

Đoạn này thực sự là tớ rối lắm, Secmask nếu rảnh thì hướng dẫn cụ thể tớ phát nhé.

secmask wrote:

@crazym: Vấn đề bạn test thử sync flood và TIME_WAIT có vẻ không ăn nhập với nhau lắm.
sync flood thông thường thì bạn chỉ cần enable sync cookie lên là được rồi, TIME_WAIT thì kết nối đã hình thành rồi, không còn liên quan đến sync flood nữa, TIME_WAIT khoảng 1000 như của bạn nhưng nếu ổn định không tăng và hệ thống vẫn chạy thông suốt thì không cần phải lo lắng.

@Secmask: Tớ đã enable SynAttackProtect lên rồi nên mới giảm xuống ý chứ. Bạn Secmask giải thích hộ tớ phát này cái.
=>TIME_WAIT thì kết nối đã hình thành rồi => cái này chuẩn
=> không còn liên quan đến sync flood nữa => là sao? Không liên quan tức là "SYN flood cứ đến" và "TIME_WAIT" sinh ra nhiều là 2 vấn đề khác nhau à?
Vì tại máy client tớ test vẫn bắn ầm ầm vào server và lượng TIME_WAIT cứ vọt lên xuống liên tục. Nếu có gì chưa đủ thì góp ý tớ nhé.

mfeng wrote:

TIME_WAIT là trạng thái cuối cùng của một kết nối tcp trước khi đóng kết nối chủ động (chủ động gửi FIN). Hiện tượng nhiều TIME_WAIT thực ra không phải lỗi của OS hay TCP/IP stack mà nguyên nhân thường bắt nguồn từ tốc độ mở socket mới quá nhanh so với tốc độ giải phóng socket: mỗi socket sẽ đợi ở tình trạng TIME_WAIT 1 khoảng thời gian là 2 *MSL (thông thường là 120s, trên CentOS là 60s).

Để khắc phục vấn đề này có các hướng sau:
- Điều chỉnh tcp/ip stack nhằm giảm thời gian time_out để đóng socket time_wait và tái sử dụng socket: như quanta và secmask đang làm.

- Xem xét ở tầng app xem tại sao client sinh ra nhiều socket tới server tới vậy (thường là do lỗi lập trình). Ở đây là kết nối http, thử xem xét vấn đề về keep-alive để tiết kiệm số sockets xem sao.

- Search google: có một số giải pháp ở tầng TCP hoặc HTTP cho phép chủ động đóng bớt TIME_WAIT (Client chủ động gửi RST; thêm method CLOSE ở giao thức HTTP), nhưng có vẻ là khó triển khai với trường hợp này.

Sory vì mình có *khơi* vấn đề này lên. Hệ thống của mình run webserver Apache trên w2003. Với ipfw và mod_security được build cùng. Mình test thử bằng SYN Flood tool mà chỉ với 2 client thôi, server của mình đã vọt lên 7-10%cpu, socket time_wait lên tới vài nghìn (2000-3000) (không ngờ server thảm thế).
Mình đã điều chỉnh theo các hướng:
+ Giảm time_out -> vẫn bị
+ Điều chỉnh trên OS: http://technet.microsoft.com/en-us/library/cc938209.aspx theo phương pháp enable SynAttackProtect -> Vẫn bị
+ Trên ipfw có cách limit connection/ip(tớ cũng đã làm) nhưng cũng chỉ là phương pháp thiếu chủ động, dù có giảm xuống 4-8 connection/ip nhưng nếu clientAttack tăng lên thì vẫn die?
Bạn Mfeng và các AE hỗ trợ mình phát này với nhé. Thanks.
P/S: Sory AE vì trong phân mục cho Linux mà hỏi về windows vì vấn đề này giống với tình trạng tớ đang gặp quá.

Thanks Quanta nhiều nhiều. Vậy là đầu óc thông thoáng hơn rùi. he he.

Thanks Quanta nhiều.

- Tớ biết cái tớ hỏi không thuộc phạm trù trong bài viết của anh Conmale smilie

nhưng tớ tìm hiểu thêm một tí thôi.

- nếu gói tin đi từ mạng LAN đến điểm đích mà đích này không phải là firewall chúng ta đang thiết lập thì gói tin này phải đi qua FORWARD chain.
===> Câu này mở mang được nhiều vấn đề rồi.

Nhưng Quanta cho tớ hỏi thêm câu nữa, đúng là gói tin từ mang LAN đến điểm đích mà đích không phải là firewall(nằm giữa) thì gói tin phải đi qua FORWARD chain, vậy những INPUT chain và OUTPUT chain thì có ảnh hưởng đến gói tin đi qua FORWARD chain không? Vì tuy nó là đi từ A -> C, nhưng nó vẫn phải input vào B rồi output ra C. Hay iptables đã ấn định với gói tin dạng như thế sẽ chỉ đi qua FORWARD chain thôi.

Có gì mở mang cho tớ đoạn này với nhé. Sory vì hỏi hơi ngu tí. Thanks Quanta phát nữa.

Quanta không trả lời post của mình với nhỉ. Mình đang bí đoạn này bạn ơi. Mô hình của mình không có Squid smilie

Bài lâu quá rồi nhưng anh Conmale và các bạn cho em hỏi:
+ Em muốn từ EXTNET ssh vào webserver(INTNET) đặt sau firewall Iptables thì rules phải như thế nào ạ? Rules này em áp dụng nhưng không được.

$IPT -A INPUT -i $EXTIF -p tcp -s $EXTNET -d $INTIP --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
=>Mọi gói tin đi vào $EXTIF từ mạng $EXTNET đến đích là $INTIP(ip của webserver trong nội mạng) với port là 22 thì được phép

$IPT -A OUTPUT -o $EXTIF -p tcp -s $INTIP --sport 22 -d $INTNET -m state --state RELATED,ESTABLISHED -j ACCEPT

$IPT -A FORWARD -s 0/0 -i $INTIF -p tcp -o $EXTIF -d 192.168.0.xxx --sport 22 -j ACCEPT
Rất mong được anh giúp đỡ.
Em cám ơn ạ.

Dạo này có một xu hướng mới rất lạ trong việc quản lí web và network là thảo luận và ứng dụng rất nhiều về Iptables, smilie

. Đặc biệt chuyên dùng để test. Lạ quá chăng?

Một số link bạn có thể tham khảo:

http://vnexperts.net/bai-viet-ky-thuat/nix/793-vi-d-v-cach-cu-hinh-iptables.html
http://congdongit.org/linux-unix/1215-cau-hinh-cho-iptables-firewall.html

Đặt biệt là:
/hvaonline/posts/list/105.html
/hvaonline/posts/list/154.html
/hvaonline/posts/list/25676.html
Các tiểu tiết khác như làm thế nào để chạy script rules cho iptables thì chắc là bạn biết rùi. Chúc thành công.

Mô hình như bạn thì cũng ko quá khó để thực hiện nhưng đòi hỏi phải đọc qua tài liệu về Routing và iptables.
Tớ góp ý thế này(dựa theo kinh nghiệm từ các bác ở đây hướng dẫn):
#Bạn có 2 mạng:
192.168.1.0/24(INTNET)
172.16.1.0/24(EXTNET)
Yêu cầu đặt ra, máy ở EXTNET có thể truy cập các dịch vụ tại máy cài dịch vụ ở INTNET.
Đầu tiên phải cho 2 mạng thông nhau tức là bạn phải NAT để 2 mạng "nhìn thấy nhau". Sau đó
mới tính chuyện truy cập dịch vụ này, dịch vụ kia. Vậy tìm hiểu về NAT bằng iptables đi nhá.
Thân

Em hiểu ý anh rồi. Thanks anh rất nhiều.

Không biết là câu hỏi của mình dở hơi, hay ntn mà dù view 75 nhưng không một ai comment trả lời cả. Mình biết hvaonline là nơi giúp đỡ trao đổi nhau rất tận tình nên mình post bài lên đây để được các bạn hỗ trợ.
Hi vọng bài post này đến tay được mod hoặc admin.

Thực ra mình ko cần phải chỉ dẫn từng câu lệnh, cái mình cần là các bạn có thể giải thích mình sẽ phải làm ntn, cần những gì để cấu hình được như thế! Thanks all.

Up lên cho các bác giúp đỡ