| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 00:22:20 (+0700) | #1 | 211505 |
RotO
Member
![[Minus]](/hvaonline/templates/viet/images/minus.gif "[Minus]") |
0 |
![[Plus]](/hvaonline/templates/viet/images/plus.gif "[Plus]")
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
Mình có thuê một máy chủ dedicate của VDC để làm server game tại vnAion.com. Server Linux có cài các phần mềm hạn chế DDoS. Nhưng trong một vài thời điểm trong tháng (hiện tại vẫn bị) lưu lượng đầu vào của server cao đột biến, mà không rõ nguyên nhân. Khi nói với bên kĩ thuật VDC, họ nói có thể là do bị DDoS, tuy nhiên đã kiểm tra bằng iptables, netstat, cài DOS Deflate mà không bắt được IP nào.
Server mình có dùng phầm mềm vnstat để theo dõi băng thông, và thu được các kết quả sau:
Theo giờ: http://www.vnaion.com/vnstat/index.php?if=eth0&graph=large&style=light&page=h
Theo ngày: http://www.vnaion.com/vnstat/index.php?if=eth0&graph=large&style=light&page=d
Để ý là lượng băng thông đầu vào rất cao, trong khi đầu ra rất thấp. Những ngày gặp tình trạng vậy, mạng server rất lag, còn những ngày không bị vậy, mạng rất tốt.
Kiến thức về hệ thống mạng và bảo mật mình còn non kém, nhờ anh em HVA tư vấn giúp. Nếu cần thêm thông tin gì thu thập được ở server, cứ nói mình sẽ cung cấp. |
|
|
 |
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 05:45:27 (+0700) | #2 | 211508 |
![[Avatar]](/hvaonline/images/avatar/089f41810321eefc3f4eef5d4a388e42.png "[Avatar]")
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
RotO wrote:
Mình có thuê một máy chủ dedicate của VDC để làm server game tại vnAion.com. Server Linux có cài các phần mềm hạn chế DDoS. Nhưng trong một vài thời điểm trong tháng (hiện tại vẫn bị) lưu lượng đầu vào của server cao đột biến, mà không rõ nguyên nhân. Khi nói với bên kĩ thuật VDC, họ nói có thể là do bị DDoS, tuy nhiên đã kiểm tra bằng iptables, netstat, cài DOS Deflate mà không bắt được IP nào.
Server mình có dùng phầm mềm vnstat để theo dõi băng thông, và thu được các kết quả sau:
Theo giờ: http://www.vnaion.com/vnstat/index.php?if=eth0&graph=large&style=light&page=h
Theo ngày: http://www.vnaion.com/vnstat/index.php?if=eth0&graph=large&style=light&page=d
Để ý là lượng băng thông đầu vào rất cao, trong khi đầu ra rất thấp. Những ngày gặp tình trạng vậy, mạng server rất lag, còn những ngày không bị vậy, mạng rất tốt.
Kiến thức về hệ thống mạng và bảo mật mình còn non kém, nhờ anh em HVA tư vấn giúp. Nếu cần thêm thông tin gì thu thập được ở server, cứ nói mình sẽ cung cấp.
Server của bồ chạy trên Linux? (bồ có đề cập đến iptables). Vậy thử chờ đến lúc băng thông lên cao hoặc lúc truy cập thấy chậm, thử chạy lệnh:
#/sbin/tcpdump -i eth0 -s0 -w dump
chờ khoảng 1 phút rồi nhấn: ctrl-C để ngắt. Sau đó zip file "dump" đó rồi upload vào đâu đó. PM cho tớ nơi bồ lưu file "dump" (đã được zip). Tớ sẽ xem giúp thử có bị DDoS hay không.
|
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 12:31:43 (+0700) | #3 | 211532 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
| Mình đã làm theo hướng dẫn và gửi tin nhắn diễn đàn cho admin. Cảm ơn admin đã quan tâm giúp đỡ. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 14:19:20 (+0700) | #4 | 211537 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
RotO wrote:
Mình đã làm theo hướng dẫn và gửi tin nhắn diễn đàn cho admin. Cảm ơn admin đã quan tâm giúp đỡ.
Server của bồ bị UDP flood đến cổng 80 rồi.
Đưa rule này vô trong iptables gấp:
iptables -t mangle -I PREROUTING -p udp -d $IP --dport 80 -j DROP
iptables -t mangle -I PREROUTING -p udp -s any/0 --sport 1238 -j DROP
$IP ở đây là IP của máy chủ của bồ đó (123.x.x.x). Nguồn IP "chơi" bồ là từ "netnam". |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 14:51:03 (+0700) | #5 | 211541 |
tuewru
Member
|
|
0 |
|
|
Joined: 23/05/2008 04:17:26
Messages: 126
Offline
|
|
Hay quá
Bây giờ em mới được biết thêm một khái niệm DDOS mới sử dụng UDP Flood
Cảm ơn admin conmale
UDP Flood Attack Mitigation
The UDP Flood Attack can be effectively reduced by deploying Firewalls at critical locations of a network to filter un-wanted traffic and from iffy sources. In addition, the following actions should be taken in your network:
1. Disable and filter chargen and echo services.
2. Disable and filter other unused UDP services.
3. If you must provide external access to some UDP services, consider using a proxy mechanism to protect that service from misuse.
4. Monitor your network to learn which systems are using these services and to monitor for signs of misuse.
|
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 18:43:45 (+0700) | #6 | 211565 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
conmale wrote:
Server của bồ bị UDP flood đến cổng 80 rồi.
Đưa rule này vô trong iptables gấp:
iptables -t mangle -I PREROUTING -p udp -d $IP --dport 80 -j DROP
iptables -t mangle -I PREROUTING -p udp -s any/0 --sport 1238 -j DROP
$IP ở đây là IP của máy chủ của bồ đó (123.x.x.x). Nguồn IP "chơi" bồ là từ "netnam".
Đã thực hiện và đang chờ đợi kết quả. Cảm ơn admin trước. Kết quả thế nào sẽ báo lại ngay tối nay. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
24/05/2010 20:41:26 (+0700) | #7 | 211580 |
tuewru
Member
|
|
0 |
|
|
Joined: 23/05/2008 04:17:26
Messages: 126
Offline
|
|
| Tối nay nó không UDP Flood bạn thì làm sao có kết quả mà báo được |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
25/05/2010 03:33:39 (+0700) | #8 | 211597 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
Đã thực hiện nhưng không thấy kết quả. Lưu lượng đầu vào vẫn rất cao.
Mà có một điều lạ là cái iptables, khi kiểm tra các luật bằng
Code:
iptables -L -v -n --line-numbers -t mangle
Thì có thấy 2 luật udp vừa add vào, nhưng cứ 5 phút nó lại bị reset. Đã thử đặt cronjob 1 phút 1 lần để add lại vào, nhưng không thấy kết quả. Không hiểu nổi tại sao cái iptables lại cứ bị reset, mất hết các luật.
Kết quả là server tối nay đã bị đánh sập hoàn toàn, hiện thời không thể truy cập. SSH cũng chịu luôn.
Hiện giờ đang bế tắc, không biết cách giải quyết sao luôn.  |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
25/05/2010 04:18:11 (+0700) | #9 | 211598 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
RotO wrote:
Đã thực hiện nhưng không thấy kết quả. Lưu lượng đầu vào vẫn rất cao.
Mà có một điều lạ là cái iptables, khi kiểm tra các luật bằng
Code:
iptables -L -v -n --line-numbers -t mangle
Thì có thấy 2 luật udp vừa add vào, nhưng cứ 5 phút nó lại bị reset. Đã thử đặt cronjob 1 phút 1 lần để add lại vào, nhưng không thấy kết quả. Không hiểu nổi tại sao cái iptables lại cứ bị reset, mất hết các luật.
Kết quả là server tối nay đã bị đánh sập hoàn toàn, hiện thời không thể truy cập. SSH cũng chịu luôn.
Hiện giờ đang bế tắc, không biết cách giải quyết sao luôn.
Tất nhiên bồ chỉ có thể cản không cho packets đi vô sâu hơn mà thôi còn "lưu lượng" thì không ngăn được. Chỉ có nhà cung cấp dịch vụ mới có thể ngăn không cho vô từ router bên ngoài.
----> quờ quạng như thế này thì có nước chết. Phải tìm ra nguyên nhân tại sao nó bị reset thay vì tạo cronjob mỗi phút như vậy.
----> Không SSH được thì bó tay con gà quay. Chỉ có thể nhờ nhà cung cấp dịch vụ giúp đỡ restart lại server và cản hết packets từ bên ngoài vô ngoại trừ đến cổng 22 thì mới có thể vô mà điều chỉnh lại. Firewall của bồ được thiết kế như thế nào? |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
25/05/2010 13:23:30 (+0700) | #10 | 211622 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
conmale wrote:
Tất nhiên bồ chỉ có thể cản không cho packets đi vô sâu hơn mà thôi còn "lưu lượng" thì không ngăn được. Chỉ có nhà cung cấp dịch vụ mới có thể ngăn không cho vô từ router bên ngoài.
----> quờ quạng như thế này thì có nước chết. Phải tìm ra nguyên nhân tại sao nó bị reset thay vì tạo cronjob mỗi phút như vậy.
----> Không SSH được thì bó tay con gà quay. Chỉ có thể nhờ nhà cung cấp dịch vụ giúp đỡ restart lại server và cản hết packets từ bên ngoài vô ngoại trừ đến cổng 22 thì mới có thể vô mà điều chỉnh lại. Firewall của bồ được thiết kế như thế nào?
Đã tạm log vào được server. Đã tìm ra nguyên nhân iptables bị reset, là do cái cái APF, mò ra cái cronjob của nó comment đi, nên bây giờ không bị reset nữa.
Đã áp dụng 2 luật trên, + thêm disable luôn tất cả OUTPUT giao thức UDP.
Code:
/sbin/iptables -t mangle -I PREROUTING -p udp -d 123.x.x.x --dport 80 -j DROP
/sbin/iptables -t mangle -I PREROUTING -p udp -s any/0 --sport 1238 -j DROP
/sbin/iptables -A OUTPUT -p udp -j DROP
Kết quả:
Code:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP udp -- anywhere anywhere
# iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DROP udp -- anywhere anywhere udp spt:hacl-qs
DROP udp -- anywhere 123.x.x.x udp dpt:http
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Mạng vẫn cứ lag, vì sức tấn công của kẻ xấu bây giờ tăng lên rất nhiều. VNStat cho thấy Incomming traffic hơn 40G/h (trước chỉ có 15G/h).
Nhờ admin chỉ giúp có cách nào hạn chế hơn được nữa không? |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
25/05/2010 15:24:41 (+0700) | #11 | 211629 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
Firewall gì mà cái gì cũng ACCEPT như vầy là tiêu rồi.
Bồ thử chạy:
netstat -nat | sort
và
netstat -nau | sort
và
iptables -t mangle -L -v -n
rồi gởi kết quả lên xem. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
25/05/2010 21:00:11 (+0700) | #12 | 211646 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
Khi kiểm tra netstat, có thấy bị flood cả cổng 80, tắt HTTP server đi, mà quên ko copy lại netstat.
Trước khi tắt game server:
Code:
# netstat -nat | sort
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:970 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 :::22 :::* LISTEN
tcp 0 0 ::ffff:123.30.181.74:22 ::ffff:117.4.175.46:3121 ESTABLISHED
tcp 0 112 ::ffff:123.30.181.74:22 ::ffff:117.4.175.46:1668 ESTABLISHED
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.161.80.176:58015 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.161.80.176:58019 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.165.166.71:43718 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.166.159.148:1170 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.166.159.148:1235 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.166.159.148:2128 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.169.163.71:47845 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.22.104.84:12879 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.22.1.10:10071 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.22.48.216:14659 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:113.22.54.236:1880 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:115.72.241.94:1213 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:115.72.241.94:1214 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:115.75.57.124:24154 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.68.165.16:2309 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.68.221.67:15944 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.68.8.29:1147 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.68.88.240:3563 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.68.88.240:4695 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.68.98.238:50261 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.69.64.172:63101 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.69.64.172:64607 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.71.19.59:13685 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:118.71.70.228:28137 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.19.132.124:1820 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.20.134.221:1534 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.20.147.189:1844 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.20.251.229:19621 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.20.251.229:21851 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.20.47.18:1938 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:123.21.220.139:4446 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:2106 ::ffff:222.253.171.19:23207 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.161.80.176:58014 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.168.244.128:1990 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10767 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10768 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10770 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10772 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10773 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10775 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10777 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10778 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10779 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10782 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10784 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10785 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10786 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10789 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10791 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10793 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10799 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10800 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10801 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10802 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10803 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10805 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10808 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10810 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10820 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10823 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10827 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10828 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10830 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10831 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10832 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10836 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10837 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10839 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10846 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10849 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10850 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:113.22.205.16:10854 FIN_WAIT1
tcp 0 1 ::ffff:123.30.181.74:7777 ::ffff:222.253.170.48:10065 FIN_WAIT1
Sau khi tắt loginserver(2106) và gameserver(7777):
Code:
# netstat -nat | sort
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:970 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 :::22 :::* LISTEN
tcp 0 128 ::ffff:123.30.181.74:22 ::ffff:117.4.175.46:1668 ESTABLISHED
tcp 0 48 ::ffff:123.30.181.74:22 ::ffff:117.4.175.46:4084 ESTABLISHED
Code:
# netstat -nau | sort
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 0.0.0.0:55694 0.0.0.0:*
udp 0 0 0.0.0.0:631 0.0.0.0:*
udp 0 0 0.0.0.0:964 0.0.0.0:*
udp 0 0 0.0.0.0:967 0.0.0.0:*
udp 0 0 :::37604 :::*
udp 0 0 :::5353 :::*
Code:
# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 875M packets, 131G bytes)
pkts bytes target prot opt in out source destination
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:1238
17 1297 DROP udp -- * * 0.0.0.0/0 123.30.181.74 udp dpt:80
Chain INPUT (policy ACCEPT 781M packets, 124G bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 777M packets, 121G bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 777M packets, 121G bytes)
pkts bytes target prot opt in out source destination
Đang dump tcp lại, sẽ gửi nhờ admin xem sau khi xong. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
26/05/2010 00:17:07 (+0700) | #13 | 211656 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
Đã giải quyết xong! Mất 30p google! Thiết lập các phương án bảo vệ cơ bản nhất là xong. Cảm ơn admin và mọi người giúp đỡ.
Dù tạm thời đã ổn lại. Nhưng thời đại nào cũng có Chí Phèo. Khi gặp rắc rối gì lại mong được mọi người giúp đỡ!
Cảm ơn admin và mọi người. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
26/05/2010 03:26:50 (+0700) | #14 | 211659 |
oranix
Member
|
|
0 |
|
|
Joined: 04/03/2009 23:49:59
Messages: 2
Offline
|
|
conmale wrote:
iptables -t mangle -I PREROUTING -p udp -d $IP --dport 80 -j DROP
iptables -t mangle -I PREROUTING -p udp -s any/0 --sport 1238 -j DROP
trước đây, em thường cho cản/ lọc packets khi nó được đi vào table "filter".
Liệu có khác biệt gì so với table "mangle"? Tại sao anh không cản ngay ở table "raw"?
anh có thể giải thích giúp em được không? |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
26/05/2010 05:05:47 (+0700) | #15 | 211664 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
oranix wrote:
conmale wrote:
iptables -t mangle -I PREROUTING -p udp -d $IP --dport 80 -j DROP
iptables -t mangle -I PREROUTING -p udp -s any/0 --sport 1238 -j DROP
trước đây, em thường cho cản/ lọc packets khi nó được đi vào table "filter".
Liệu có khác biệt gì so với table "mangle"? Tại sao anh không cản ngay ở table "raw"?
anh có thể giải thích giúp em được không?
Khi packets vô tới "filter" thì nó đã đi xuyên qua cơ chế "internal routing" của netfilter rồi. Các luật cản lọc thông thường như block ports, allow ports.... thì không sao nhưng nếu ở tình trạng bị DDoS thì việc xử lý các packets càng sớm, càng ít tốn thời gian càng tốt bởi thế, "mangle" là table tốt cho chọn lựa đối phó với DDoS. "Mangle" cho phép mình thêm những options khác để "match" packets (đúng với nhu cầu cản lọc của mình). Trong khi đó, "raw" phải đi chung với "NOTRACK" target và với "NOTRACK" mọi thông tin liên quan đến "conntrack" và "nat" đều bị mất hết. Bởi vậy, "raw" chỉ thích hợp với việc loại bỏ hoàn toàn công đoạn "conntrack" và nó rất thích hợp cho trường hợp cho phép các packets đi thẳng đến đích nào đó một cách nhanh chóng và không bị "state machine" xử lý nữa. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
26/05/2010 21:42:43 (+0700) | #16 | 211706 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
Xin hỏi mọi người 1 câu nữa. (Dễ là câu cuối cùng trong topic này)
Nếu mình đã cài firewall, chặn tất cả các port UDP, chỉ mở mỗi cổng TCP 22. netstat -anut chỉ thấy mỗi một kết nối SSH của mình. Mà băng thông vẫn bị ngập, có nghĩa là y học bó tay (về phương diện software) rồi phải không?
Có nghe qua về một số kiểu tấn công SYN Floods và ICMP DDoS. Nhưng không biết nhận dạng nó thế nào để chống. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
27/05/2010 04:35:01 (+0700) | #17 | 211711 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
RotO wrote:
Xin hỏi mọi người 1 câu nữa. (Dễ là câu cuối cùng trong topic này)
Nếu mình đã cài firewall, chặn tất cả các port UDP, chỉ mở mỗi cổng TCP 22. netstat -anut chỉ thấy mỗi một kết nối SSH của mình. Mà băng thông vẫn bị ngập, có nghĩa là y học bó tay (về phương diện software) rồi phải không?
Không. Vẫn có cách triệt tiêu các packets đi vô hệ thống nhưng vẫn phải chịu tình trạng packets đi vô bởi vì những packets này không mời nhưng chúng vẫn đến. Chỉ có nhà cung cấp dịch vụ mới có thể cản chúng từ router bên ngoài. Nếu nhà cung cấp dịch vụ không cản thì mình vẫn phải nhận.
DDoS không chỉ trỏ tới một cổng dịch vụ (đang mở) nào đó mà nó vẫn có thể dập tới các cổng đã đóng với mục đích làm nghẽn băng thông (nhận hay không nhận là chuyện khác nhưng packets vẫn tràn vô cái đã).
HVA có sử dụng một "chiêu" để nhận các packets tấn công kia và đưa chúng vô "black hole" một dạo trước đây khi bị UDP flood như sau:
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
vì HVA không cung cấp dịch vụ UDP nào hết và vì bị flood bằng UDP đến các cổng random nhằm mục đích bảo hoà băng thông nên biện pháp xử lý trong trường hợp này là "ra lệnh" cho netfilter / iptables hễ thấy có UDP packets đi vô là wwwect chúng đến cổng 9 (discard) mà không cần cản lọc hay kiểm tra gì hết (cho mất thời gian). Tôi có đề cập khía cạnh này trong loạt bài "Ký sự các vụ DDoS đến HVA".
RotO wrote:
Có nghe qua về một số kiểu tấn công SYN Floods và ICMP DDoS. Nhưng không biết nhận dạng nó thế nào để chống.
Sniff packets và dùng WireShark (Ethereal) để phân tích. Đây là những kỹ năng cần thiết cho bất cứ ai quản lý một hệ thống có gắn liền với mạng. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
27/05/2010 05:37:27 (+0700) | #18 | 211712 |
RotO
Member
|
|
0 |
|
|
Joined: 22/05/2010 23:34:07
Messages: 9
Offline
|
|
conmale wrote:
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
Báo lỗi:
Code:
iptables: Unknown error 4294967295
Google hoài mà chưa ra cách chữa. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
27/05/2010 05:46:16 (+0700) | #19 | 211713 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
RotO wrote:
conmale wrote:
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
Báo lỗi:
Code:
iptables: Unknown error 4294967295
Google hoài mà chưa ra cách chữa.
Trên server của bồ có "discard" service chạy chưa?
Search "discard service Linux". |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
01/06/2010 00:31:25 (+0700) | #20 | 212011 |
rongdennt
Member
|
|
0 |
|
|
Joined: 08/12/2007 10:19:36
Messages: 55
Offline
|
|
em google với từ khoá như trên thì có đọc RFC863, thì hiểu được là khi vào port 9 của discard nó sẽ như rơi vào khoảng không (null)
Nhưng em không tìm thấy cái cài đặt dịch vụ này. Lật lại trong loạt bài kí sự thì có đoạn sau:
Tôi nhớ trước đây tôi đã tạo dịch vụ discard trên firewall của HVA và đã thử nghiệm qua khoản này nhưng chưa đi sâu bởi vì nạn DDoS x-flash ngày ấy (cuối 2005, đầu 2006) không nhằm mục đích saturate đường dẫn như dạng UDP DDoS lần này. Dịch vụ "discard" chỉ có thể access từ trên chính firewall nên không có gì phải ngại. Hơn nữa, nó được chính firewall bảo vệ. Bởi thế, có lẽ nó vẫn còn đó vì tôi nhớ mình chưa hề tắt bỏ nó.
Co em hỏi, anh tạo dịch vụ này sao ạ? hoặc nếu có tài liệu gì anh chỉ giúp em với
Cảm ơn anh |
|
| Cổ nhân dạy: Vĩ nhân bàn ý tưởng, thường dân bàn sự kiện, tiểu nhân bàn con người. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
01/06/2010 04:17:36 (+0700) | #21 | 212016 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
rongdennt wrote:
em google với từ khoá như trên thì có đọc RFC863, thì hiểu được là khi vào port 9 của discard nó sẽ như rơi vào khoảng không (null)
Nhưng em không tìm thấy cái cài đặt dịch vụ này. Lật lại trong loạt bài kí sự thì có đoạn sau:
Tôi nhớ trước đây tôi đã tạo dịch vụ discard trên firewall của HVA và đã thử nghiệm qua khoản này nhưng chưa đi sâu bởi vì nạn DDoS x-flash ngày ấy (cuối 2005, đầu 2006) không nhằm mục đích saturate đường dẫn như dạng UDP DDoS lần này. Dịch vụ "discard" chỉ có thể access từ trên chính firewall nên không có gì phải ngại. Hơn nữa, nó được chính firewall bảo vệ. Bởi thế, có lẽ nó vẫn còn đó vì tôi nhớ mình chưa hề tắt bỏ nó.
Co em hỏi, anh tạo dịch vụ này sao ạ? hoặc nếu có tài liệu gì anh chỉ giúp em với
Cảm ơn anh
"Discard" service thường được inetd hoặc xinetd (mới hơn) quản lý. Nếu em dùng Linux distro dựa trên Fedora, em chỉ cần yum install xinetd là có "discard" đi kèm. "Discard" có 2 hồ sơ cấu hình: 1) cho UDP và 2) cho TCP và các hồ sơ này thường nằm trong /etc/xinetd.d.
discard cho UDP thường có tên là "discard-dgram" và có nội dung:
service discard
{
disable = yes
id = discard-dgram
type = INTERNAL
wait = yes
socket_type = dgram
}
Phần màu đỏ rất quan trọng để "enable" hay "disable" service này và ấn định loại giao thức nào được dùng (trong trường hợp này là datagram - UDP).
discard cho TCP thường có tên là "discard-stream" và có nội dung:
service discard
{
disable = no
id = discard-stream
type = INTERNAL
wait = no
socket_type = stream
}
Tương tự như discard cho UDP, discard cho TCP có cấu hình như trên, chỉ có khác ở "socket_type" là "stream" (TCP).
Khi đã ấn định nội dung của hai cấu hình trên trong /etc/xinetd.d, em chỉ cần restart xinetd (hoặc inetd - tuỳ máy em dùng cái nào). Thông thường các Linux distro hiện đại dùng xinetd là nhiều.
Thử /etc/init.d/xinetd restart
và kiểm tra:
netstat -at | grep LISTEN | grep discard (cái này để kiểm tra discard TCP)
netstat -au | grep discard (cái này để kiểm tra discard UDP) |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
01/06/2010 09:32:53 (+0700) | #22 | 212029 |
rongdennt
Member
|
|
0 |
|
|
Joined: 08/12/2007 10:19:36
Messages: 55
Offline
|
|
| Cảm ơn anh nhiều, em đã thử update xinetd và đã "lòi" ra 2 hồ sơ cấu hình trên. |
|
| Cổ nhân dạy: Vĩ nhân bàn ý tưởng, thường dân bàn sự kiện, tiểu nhân bàn con người. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
17/08/2011 14:24:08 (+0700) | #23 | 245190 |
mapthulu
Member
|
|
0 |
|
|
Joined: 10/06/2011 12:16:42
Messages: 28
Offline
|
|
conmale wrote:
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
Chào anh,
Khi em dùng đoạn này để thử nghiệm thì nhận được thông báo lỗi từ phía máy chủ:
Code:
iptables: Unknown error 18446744073709551615
Dịch vụ Discard đã được khởi chạy cho cả UDP và TCP. Nếu em thay thế REDIRECT --to-ports 9 bằng DROP thì lại được.
Nếu em không dùng mangle mà dùng nat thì bình thường
Code:
iptables -t nat -I PREROUTING -p udp -j REDIRECT --to-ports 9
Em chưa rõ vấn đề do đâu, mong nhận được sự hỗ trợ.
Nội dung cấu hình Discard cho TCP
Code:
service discard
{
disable = no
id = discard-stream
type = INTERNAL
wait = no
socket_type = stream
protocol = tcp
user = root
}
Nội dung cấu hình Discard cho UDP
service discard
Code:
{
disable = no
id = discard-dgram
type = INTERNAL
wait = yes
socket_type = dgram
protocol = udp
user = root
}
Em xin cảm ơn. |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
17/08/2011 16:50:21 (+0700) | #24 | 245199 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
| Em dùng iptables phiên bản mấy? Trên linux host thực sự hay trên VPS? Linux chạy kernel phiên bản mấy? |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
17/08/2011 17:52:12 (+0700) | #25 | 245201 |
mapthulu
Member
|
|
0 |
|
|
Joined: 10/06/2011 12:16:42
Messages: 28
Offline
|
|
Cảm ơn anh hồi âm, đây là 4 con máy chủ vật lý của bên em
Máy 1:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server1 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Máy 2:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server2 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Máy 3:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server3 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Máy 4:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server4 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Em xin cảm ơn |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
17/08/2011 20:03:27 (+0700) | #26 | 245207 |
vd_
Member
|
|
0 |
|
|
Joined: 06/03/2010 03:05:09
Messages: 124
Offline
|
|
@conmale
Xin hỏi thêm ngoài lề anh conmale, việc wwwect udp sang port 9 so với việc drop udp packet thì cái nào sẽ lợi hơn?
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
or
iptables -t mangle -I PREROUTING -p udp -j DROP
|
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
18/08/2011 03:31:50 (+0700) | #27 | 245222 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
mapthulu wrote:
Cảm ơn anh hồi âm, đây là 4 con máy chủ vật lý của bên em
Máy 1:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server1 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Máy 2:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server2 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Máy 3:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server3 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Máy 4:
Code:
#iptables --version
iptables v1.3.5
#uname -a
Linux server4 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Em xin cảm ơn
Kernel và iptables của em quá cũ. Có thể không có target REDIRECT cho netfilter trong kernel. Em nên cập nhật kernel mới hơn và dùng phiên bản iptables mới hơn. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
18/08/2011 04:14:23 (+0700) | #28 | 245223 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
vd_ wrote:
@conmale
Xin hỏi thêm ngoài lề anh conmale, việc wwwect udp sang port 9 so với việc drop udp packet thì cái nào sẽ lợi hơn?
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
or
iptables -t mangle -I PREROUTING -p udp -j DROP
Hello vd_,
Trên mặt nguyên tắc, DROP là coi như... đứt bóng, không có gì khác hơn và không có gì nhanh hơn. Tuy nhiên, trong trường hợp bị DDoS nặng, tớ thấy REDIRECT giúp offload cho server rất nhiều.
Nếu xem source của netfilter handle UDP, đặc biệt trong phần conntrack thì thấy UDP packets đi vô vẫn được contruct đầy đủ, vẫn được tạo buffer và vẫn được xét (trước khi bị truncate [drop] nếu nhận tín hiệu). Có lẽ đây là phần tạo trì trệ nếu dùng DROP. Trong khi đó, nếu REDIRECT đến /dev/null thì netfilter hoàn toàn không cần phải kiểm soát gì hết mà cứ cho nó vô và "discard" cứ âm thầm mà huỷ bỏ. Đối với iptables / netfilter trong trường hợp này là cứ cho vô thoải mái mà không kiểm soát gì hết. Bởi vì UDP là "stateless" cho nên packets cứ vô là vô và số phận nó ra sao thì iptables / netfilter không cần biết đến nữa.
Gần 3 năm trước, có lần HVA bị DDoS bằng UDP rất nặng. Khi đó, nếu tớ dùng DROP thì khoảng 10 phút đầu ok nhưng sau đó kernel báo bị "out of socket memory" và kéo dài hơn nữa thì server bị crashed vì hết mem. Thay vào đó, khi áp dụng biện pháp REDIRECT, đống UDP tràn vô cứ chạy thẳng vô /dev/null thì hoàn toàn biến mất tình trạng "out of socket memory".
Nhân đây, @ mapthulu, em không cần phải dùng xinetd để enable discard stream và datagram mà chỉ cần dùng netcat để tạo listener rồi chuyển thẳng vô /dev/null:
nc -vv -l 9 > /dev/null & (cái này cho TCP)
nc -vv -u -l 9 > /dev/null & (cái này cho UDP, -u switch cho UDP)
trong đó, nếu muốn xem "verbose" information thì thêm -v, còn không thì bỏ và & là cho nó chuyển qua chạy ở background. Dùng netcat gọn nhẹ hơn rất nhiều. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
18/08/2011 06:13:10 (+0700) | #29 | 245224 |
mapthulu
Member
|
|
0 |
|
|
Joined: 10/06/2011 12:16:42
Messages: 28
Offline
|
|
Chân thành cảm ơn về sự hồi âm của anh.
Hệ thống bên em đang chạy kiểu RAID onboard nên chưa thể cập nhật được kernel (đã có phần phát sinh panic, đành phải hiệu chỉnh về bản cũ hơn)
Riêng về biên dịch dựa trên thành phần có sẵn cũng chưa thể vì hệ thống đang chạy dạng hosting.
Chúc anh sức khỏe |
|
|
|
|
| [Question] (Cần giúp đỡ) Băng thông vào server cao đột biến không rõ nguyên nhân. |
25/08/2011 16:32:42 (+0700) | #30 | 245849 |
edge
Member
|
|
0 |
|
|
Joined: 12/07/2010 21:33:41
Messages: 5
Offline
|
|
Sau khi thêm dòng:
iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9
vào iptables, e gặp lỗi sau:
[7258252.635604] x_tables: ip_tables: REDIRECT target: only valid in nat table, not mangle
Trong khi đó trong "man iptables", table mangle có chain PREROUTING:
mangle:
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out)
$iptables --version
iptables v1.4.10
$ uname -a
Linux ubuntu 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux
Em không hiểu sao lại bị lỗi trên, mong anh xem giúp. |
|
|
| Users currently in here |
|
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|
![[Rule]](/hvaonline/templates/viet/images/icon_mini_rule.gif "[Rule]"){kind=icon}
![[Home]](/hvaonline/templates/viet/images/icon_mini_groups.gif "[Home]"){kind=icon}
![[Portal]](/hvaonline/templates/viet/images/icon_mini_portal.gif "[Portal]"){kind=icon}
![[Members]](/hvaonline/templates/viet/images/icon_mini_members.gif "[Members]"){kind=icon}
![[Statistics]](/hvaonline/templates/viet/images/icon_mini_stats.gif "[Statistics]"){kind=icon}
![[Search]](/hvaonline/templates/viet/images/icon_mini_search.gif "[Search]"){kind=icon}
![[Reading Room]](/hvaonline/templates/viet/images/icon_mini_book.gif "[Reading Room]"){kind=icon}
![[Register]](/hvaonline/templates/viet/images/icon_mini_register.gif "[Register]"){kind=icon}
Register![[Login]](/hvaonline/templates/viet/images/icon_mini_login.gif "[Login]"){kind=icon}
Login [
Thảo luận bảo mật
![[Profile]](/hvaonline/templates/viet/images/en_US/icon_profile.gif "[Profile]"){kind=icon}
![[PM]](/hvaonline/templates/viet/images/en_US/icon_pm.gif "[PM]"){kind=icon}
![[Up]](/hvaonline/templates/viet/images/en_US/icon_up.gif "[Up]"){kind=icon}
![[Print Copy]](/hvaonline/templates/viet/images/en_US/icon_print.gif "[Print Copy]"){kind=icon}
![[digg]](/hvaonline/templates/viet/images/digg.gif "[digg]")
![[delicious]](/hvaonline/templates/viet/images/delicious.gif "[delicious]")
![[google]](/hvaonline/templates/viet/images/google.gif "[google]")
![[yahoo]](/hvaonline/templates/viet/images/yahoo.gif "[yahoo]")
![[technorati]](/hvaonline/templates/viet/images/technorati.gif "[technorati]")
![[reddit]](/hvaonline/templates/viet/images/reddit.gif "[reddit]")
![[stumbleupon]](/hvaonline/templates/viet/images/stumbleupon.gif "[stumbleupon]")