Iptables için hata ayıklayıcı


47

Bir paket iptables kuralları ile takip etmek için kolay bir yol arıyorum. Bu, günlüğe kaydetmeyle ilgili değil, çünkü tüm trafiği günlüğe kaydetmek istemiyorum (ve yalnızca çok az kural için yalnızca LOG hedeflerine sahip olmak istiyorum).

Iptables için Wireshark gibi bir şey. Veya belki de bir programlama dili için bir hata ayıklayıcısına benzer bir şey.

Teşekkürler Chris

Not: Şık bir GUI aracı olmak zorunda değildir. Fakat sadece bir paket sayacını göstermekten daha fazlasını yapması gerekir.

Güncelleme: İstenilen işlevi sağlayan hiçbir şey bulamıyoruz gibi görünüyor. Bu durumda: Let en azından giriş iptables temel alan bir iyi tekniğini bulmak - kolayca açılıp kapatılabilir ve (aynı kural yazmak zorunda yedek olarak yazma iptables kuralları gerektirmez -j LOGve -j ...)

Yanıtlar:


10

Doğrudan bir çözüm düşünemiyorum, ancak bir paketi izlemenin bir yolu olduğunu düşünebilirim.

  1. Her kuralı bir log önek yönergesi ile günlüğe kaydedin (--log-prefix "Rule 34")
  2. Scapy ile bir test paketi veya paket akışı oluşturun ve TOS alanını benzersiz bir şeye ayarlayın
  3. Bu TOS ayarının günlük dosyası çıktısını grepleyin ve hangi kuralları kaydettiğini görün.

Fikir için teşekkürler. Ne yazık ki, her kuralı günlüğe kaydedemiyorum (Bir sistemde, disk muhtemelen bunu yapmak için yeterince hızlı olmazdı. Bir başkasında, iptables günlüğü çekirdeğin içinde mevcut değil.)
Chris Lercher,

1
Softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml dosyası olarak adlandırılmış bir boru kullanın. Ancak çekirdeğinize giriş yapamadığınız için SOL
Haakon

Teşekkürler, muhtemelen sorunumu çözmeyecek, ama genel olarak boru syslogunun mümkün olabileceğini bilmek güzeldi - başka bir zamanda işe yarayabilir!
Chris Lercher,

Günlüğe kaydetmeyle ilgili bir soru: iptables aynı anda birden fazla paketi işliyor mu (böylece günlük girdileri birleştirilebilir)? Bu durumda, TOS fikrinin birçok iptables LOG analizi için mutlak bir zorunluluk olduğunu düşünüyorum!
Chris Lercher

Bunun cevabını bilmiyorum. Her arayüzün en azından iptables tarafından aynı anda ele alınmasını bekliyorum.
Haakon

82

Yeterince bir çekirdeğe ve iptables sürümüne sahipseniz TRACE hedefini kullanabilirsiniz (en azından Debian 5.0'da kurulu gibi görünüyor). İzlemenizin koşullarını mümkün olduğu kadar spesifik olacak şekilde ayarlamanız ve hata ayıklamadığınız zaman herhangi bir TRACE kuralını devre dışı bırakmanız gerekir, çünkü günlüklere çok fazla bilgi harcar.

İZLEME
Bu hedef paketleri işaretler, böylece çekirdek tabloları, zincirleri ve kuralları geçen paketler ile eşleşen her kuralı günlüğe kaydeder. (Kayıt için ipt_LOG veya ip6t_LOG modülü gereklidir.) Paketler string öneki ile günlüğe kaydedilir: "TRACE: tablename: chainname: type: rulenum" burada düz kural için "kural", düz kural için "return" olabilir kullanıcı tanımlı bir zincirin sonunda ve yerleşik zincirlerin politikası için "politika". Sadece ham tabloda kullanılabilir.

Bunun gibi kurallar eklerseniz

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

Buna benzeyen bir çıktı alacaksınız.

# 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
Teşekkürler, bu harika! Aslında en iyi cevap, kabul edebilmeyi isterdim (bir ödül sorusuydu, bu yüzden kabul edilen cevap kesindi). Tüm sistemlerimde (çekirdek sınırlamaları nedeniyle) kullanamıyorum, bazı sistemlerde de kullanabiliyorum. Bu cevap olumlu oyları hakediyor, çünkü aradığım şeye gerçekten çok yakın.
Chris Lercher

Dün gece iptables man sayfasını okuduğumda farklı bir soruya cevap verebilmek için buldum. Nispeten yeni bir özellik gibi görünüyor. Kabul edilmiş olarak işaretleyememe konusunda endişelenmeyin. Belki bu zamanla bana başka bir Popülist rozeti kazanacak kadar oylanacak.
Zoredache

Bu gerçekten iptables'daki paketlerin izlenmesi için kanonik bir cevaptır. Bazı çekirdeklerin varsayılan olarak etkinleştirmemeleri çok kötü.
Peter Grace,

Çekirdek ne kadar zaman önce TRACE'i destekliyor? CentOS 6.4'te başarı ile kullandım ancak CentOS 6.2'de değil
sebelk

6

Bir yayına üç cevap:

1) Kod ile hata ayıklama:

#!/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) Syslog tarafından hata ayıklama

Bu web sitesinden: 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) Hayır hata ayıklama, güzel iptables edit:

Ayrıca bu yararlı olabilir: http://www.fwbuilder.org/


1
Teşekkürler. (1) ve 3) noktalarının iptables kuralları aracılığıyla aşağıdaki paketlerle ilgisi yoktur, ancak "--log-level" 'a dayanarak log girişlerini yeniden yönlendirmekle ilgili nokta, sonunda gerçekten geri çekilmem gerekirse yararlı olabilir. günlüğe kaydetme (kesinlikle başka bir çözüm yoksa).
Chris Lercher

2

aynı soruyu sordum ve Zoredache'ın TRACE / ipt_LOG 'u işaret ettiğini bulduk!

Ayrıca, şu anda etkin olan tüm iptables kurallarından önce LOG kurallarını ekleyen / silen bir komut dosyası buldum. Denedim ve gerçekten güzel bir araç olarak buldum. - Çıkış, TRACE çözümüne benzer - Avantaj: Nereden yüklendiğine bakılmaksızın aktif iptables yapılandırması üzerinde çalışır. Günlüğü anında açıp kapatabilirsiniz! Güvenlik Duvarı Oluşturucusu veya aracı tarafından oluşturulan her türlü güvenlik duvarı komut dosyasını değiştirmenize gerek yoktur… - Dezavantaj: değiştirilmeden, komut dosyası TÜM etkin kurallar için LOG kuralları oluşturur. Bunun yerine, TRACE kurallarını kullanırken, muhtemelen günümüzde iptables işlemlerini araştırmak istediğiniz adreslere / hizmetlere / bağlantılara giriş yapmayı kısıtlayacaksınız.

Her neyse, yaklaşımı seviyorum :) Tony Clayton’a Kudos’a bir göz atın: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Saygılar, Chris


0

Kuralların nasıl çalıştığını ve neyin eksik veya yanlış olduğunu bulmak için genellikle paketleri ve bayt sayaçlarını kullanırım.

Bunları "iptables -nvL" ile görüntüleyebilirsiniz.


2
Yine de yazarın ne istediğini görebiliyorum; iptables kurallarınızı yoğun bir arayüzde test etmeye çalışıyorsanız, sadece sayaçları izlemek, özellikle paketin çeşitli kurallara uyması ve işlem sırasında kullanıcı tarafından tanımlanmış zincirlerin etrafından atlanması muhtemel olması durumunda, sayaçları çokça kullanmayacak istenmeyen IP adreslerini filtreleme ve taşkın koruma kuralları).
PP.

@PP: Kesinlikle, aklımı okuyorsunuz. @Vi: Teşekkürler, bu bazı durumlarda yardımcı olabilir ve bunu bazen kullandım. Şimdi daha güçlü bir şeye ihtiyacım var.
Chris Lercher

-2

AFAIK bir IP paketi kural zincirini ilk eşleşmeye kadar geçer. Bu yüzden burada sorunun ne olduğunu gerçekten göremiyorum. Eğer varsa:

  1. Kural 1
  2. kural 2
  3. kural 3 LOG

Ve bir paket onu kütük haline getirir, yani kural 3'ün ilk eşleşme kuralı olduğu anlamına gelir.


Doğru değil. Paketler birden fazla kuralla eşleşebilir ve yaparlar. Bir kural bir eylemde bulunmadıkça ( -j DROPya da gibi -j ACCEPT), zincir boyunca daha fazla eşleşmeye devam eder.
PP.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.