Trình gỡ lỗi cho Iptables


47

Tôi đang tìm kiếm một cách dễ dàng để theo dõi một gói thông qua các quy tắc iptables. Đây không phải là quá nhiều về việc đăng nhập, vì tôi không muốn đăng nhập tất cả lưu lượng truy cập (và tôi chỉ muốn có các mục tiêu LOG ​​cho rất ít quy tắc).

Một cái gì đó giống như Wireshark cho Iptables. Hoặc thậm chí có thể là một cái gì đó tương tự như một trình sửa lỗi cho ngôn ngữ lập trình.

Cảm ơn Chris

Lưu ý: Nó không phải là một công cụ GUI ưa thích. Nhưng nó phải làm nhiều hơn là chỉ hiển thị một bộ đếm gói hoặc như vậy.

Cập nhật: Gần như chúng ta không thể tìm thấy bất cứ thứ gì cung cấp chức năng được yêu cầu. Trong trường hợp đó: Ít nhất hãy tìm một kỹ thuật tốt dựa trên ghi nhật ký iptables - có thể dễ dàng bật và tắt và không cần phải viết các quy tắc iptables một cách dự phòng (phải viết cùng một quy tắc cho -j LOG-j ...)

Câu trả lời:


10

Tôi không thể nghĩ ra một giải pháp trực tiếp, nhưng tôi có thể nghĩ ra một cách để theo dõi một gói tin.

  1. Ghi nhật ký từng quy tắc bằng chỉ thị tiền tố nhật ký (--log-prefix "Quy tắc 34")
  2. Tạo một gói thử nghiệm hoặc luồng gói bằng scacco và đặt trường TOS thành một cái gì đó duy nhất
  3. grep đầu ra tệp nhật ký cho cài đặt TOS đó và xem quy tắc nào đã ghi lại nó.

Cảm ơn ý tưởng. Thật không may, tôi không thể đăng nhập mọi quy tắc (Trên một hệ thống, đĩa có thể sẽ không đủ nhanh để làm điều đó. Trên một hệ thống khác, ghi nhật ký iptables không có sẵn trong kernel.)
Chris Lercher

1
Sử dụng một ống có tên là tệp softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Tuy nhiên, vì bạn không thể đăng nhập vào kernel của mình, bạn là một SOL
Haakon

Cảm ơn, có lẽ nó sẽ không giải quyết được vấn đề của tôi, nhưng nói chung là rất tốt để biết rằng syslog đường ống sẽ có thể - có thể sẽ có ích vào một thời điểm khác!
Chris Lercher

Một câu hỏi liên quan về ghi nhật ký: iptables có xử lý đồng thời nhiều gói không (để các mục nhật ký có thể được xen kẽ)? Trong trường hợp đó, tôi nghĩ rằng ý tưởng ĐKDV sẽ là một điều tuyệt đối bắt buộc đối với rất nhiều phân tích LOG của iptables!
Chris Lercher

Tôi không biết câu trả lời cho điều đó. Tôi hy vọng rằng mỗi giao diện sẽ được xử lý đồng thời bởi iptables ở mức tối thiểu.
Haakon

82

Nếu bạn có một kernel và phiên bản iptables đủ gần đây, bạn có thể sử dụng mục tiêu TRACE (Có vẻ như được tích hợp trên ít nhất Debian 5.0). Bạn nên đặt các điều kiện theo dõi của mình càng cụ thể càng tốt và vô hiệu hóa bất kỳ quy tắc TRACE nào khi bạn không gỡ lỗi vì nó tạo ra nhiều thông tin cho nhật ký.

TRACE
Mục tiêu này đánh dấu các gói để hạt nhân sẽ ghi lại mọi quy tắc khớp với các gói khi chúng đi qua các bảng, chuỗi, quy tắc. (Mô-đun ipt_LOG hoặc ip6t_LOG là bắt buộc để ghi nhật ký.) Các gói được ghi với tiền tố chuỗi: "TRACE: tablename: chainname: type: rulenum" trong đó loại có thể là "quy tắc" cho quy tắc đơn giản, "return" cho quy tắc ngầm ở cuối chuỗi do người dùng xác định và "chính sách" cho chính sách của chuỗi được xây dựng. Nó chỉ có thể được sử dụng trong bảng thô.

Nếu bạn thêm quy tắc như thế này

iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

Bạn sẽ được cung cấp đầu ra trông như thế này.

# cat /var/log/kern.log | grep 'TRACE:'
Mar 24 22:41:52 enterprise kernel: [885386.325658] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325689] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325713] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: nat:nat.1:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_all_c1:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_irc_c2:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)

8
Cảm ơn, điều này thật tuyệt vời! Đó thực sự là câu trả lời tốt nhất, tôi ước tôi có thể chấp nhận nó (đó là một câu hỏi tiền thưởng, vì vậy câu trả lời được chấp nhận là chắc chắn). Mặc dù tôi không thể sử dụng nó trên tất cả các hệ thống của mình (do giới hạn kernel), nhưng trên một số hệ thống tôi có thể. Câu trả lời này xứng đáng được nâng cấp, bởi vì nó thực sự gần với những gì tôi đang tìm kiếm.
Chris Lercher

Tôi đã tìm thấy tính năng này tối qua khi tôi đang đọc lại trang người đàn ông iptables để tôi có thể trả lời một câu hỏi khác. Có vẻ là một tính năng tương đối mới. Không phải lo lắng về việc không thể đánh dấu nó là chấp nhận. Có lẽ điều này sẽ được bình chọn đủ theo thời gian để kiếm cho tôi một huy hiệu Dân túy khác.
Zoredache

Đây thực sự là câu trả lời chính tắc để truy tìm các gói trong iptables. Thật tệ khi một số hạt nhân gần đây không bật nó theo mặc định.
Peter Grace

Hạt nhân hỗ trợ TRACE bao lâu rồi? Tôi đã sử dụng thành công trên CentOS 6.4 nhưng không phải trong CentOS 6.2
sebelk

6

Ba câu trả lời trên một bài:

1) Gỡ lỗi theo kịch bản:

#!/bin/bash
debug() {
    if [ -n "$debug" ]; then
        $@ || echo -e "The command which launched the error:\n$@"
    else
        $@
    fi
}
debug=1
IPTABLES="debug /sbin/iptables"

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
....

2) Gỡ lỗi bằng syslog

Từ trang web này: http://www.brandonhutchinson.com/iptables_fw.html

If you want to make a syslog entry of dropped packets, change:

# Drop all other traffic
/sbin/iptables -A INPUT -j DROP

To:

# Create a LOGDROP chain to log and drop packets
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP


You may also want to configure the --log-level to log dropped packets to a separate file instead of /var/log/messages:

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP --log-level debug


/etc/syslog.conf change:

# Send iptables LOGDROPs to /var/log/iptables
kern.=debug                                             /var/log/iptables

Reload the syslogd service for the change to take effect.
/sbin/service syslog reload

3) Không gỡ lỗi, chỉnh sửa iptables đẹp:

Ngoài ra điều này có thể hữu ích: http://www.fwbuilder.org/


1
Cảm ơn. Điểm 1) và 3) không liên quan nhiều đến việc tuân theo các gói thông qua quy tắc iptables, nhưng điểm về chuyển hướng các mục nhật ký dựa trên "- cấp độ" có thể hữu ích, nếu cuối cùng tôi thực sự phải quay lại đăng nhập (trong trường hợp hoàn toàn không có giải pháp nào khác).
Chris Lercher

2

có cùng câu hỏi và nhận thấy Zoredache chỉ vào TRACE / ipt_LOG là giải pháp!

Ngoài ra, tôi tìm thấy một tập lệnh chèn / xóa quy tắc LOG trước tất cả các quy tắc iptables hiện đang hoạt động. Tôi đã thử nó và thấy nó là một công cụ thực sự tốt. - Đầu ra tương tự như giải pháp TRACE - Ưu điểm: nó hoạt động trên cấu hình iptables hoạt động, bất kể nó được tải từ đâu. Bạn có thể bật / tắt đăng nhập khi đang bay! Bạn không cần sửa đổi bất kỳ tập lệnh tường lửa nào có thể được tạo bởi Trình tạo tường lửa hoặc công cụ bất cứ điều gì bạn sử dụng ... - Nhược điểm: không sửa đổi, tập lệnh tạo quy tắc LOG cho TẤT CẢ quy tắc hoạt động. Thay vào đó, khi sử dụng quy tắc TRACE, có thể bạn sẽ hạn chế đăng nhập vào địa chỉ / dịch vụ / kết nối mà bạn muốn điều tra xử lý iptables ngay bây giờ.

Dù sao, tôi thích aproach :) Kudos cho Tony Clayton, hãy xem: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Trân trọng, Chris


0

Tôi thường sử dụng các bộ đếm gói và byte để xem các quy tắc hoạt động như thế nào và để tìm ra những gì còn thiếu hoặc sai.

Bạn có thể xem chúng bằng "iptables -nvL".


2
Tôi có thể thấy những gì tác giả muốn, mặc dù; nếu bạn đang cố kiểm tra các quy tắc iptables của mình trên giao diện bận rộn, chỉ xem các bộ đếm sẽ không giúp được gì nhiều, đặc biệt nếu gói có khả năng khớp với một số quy tắc và nhảy xung quanh các chuỗi do người dùng xác định trong quy trình (như là điển hình khi lọc ra các địa chỉ IP không mong muốn và các quy tắc bảo vệ lũ lụt).
PP.

@PP: Chính xác, bạn đang đọc suy nghĩ của tôi. @Vi: Cảm ơn, điều này có thể hữu ích trong một số trường hợp và đôi khi tôi đã sử dụng nó. Bây giờ tôi cần một cái gì đó mạnh mẽ hơn.
Chris Lercher

-2

AFAIK một gói IP đi qua chuỗi quy tắc cho đến khi khớp đầu tiên. Vì vậy, tôi không thực sự thấy vấn đề ở đây. Nếu bạn có:

  1. quy tắc 1
  2. quy tắc 2
  3. quy tắc 3 đăng nhập

Và một gói làm cho nó vào nhật ký, nó có nghĩa là quy tắc 3 là quy tắc phù hợp đầu tiên.


Không đúng. Các gói có thể phù hợp với nhiều quy tắc, và họ làm. Trừ khi một quy tắc có một hành động (như -j DROPhoặc -j ACCEPT), nó sẽ chỉ tiếp tục khớp với chuỗi tiếp theo.
PP.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.