Vraag Debugger voor Iptables


Ik ben op zoek naar een eenvoudige manier om een ​​pakket te volgen via de iptables-regels. Dit gaat niet zozeer over loggen, omdat ik niet al het verkeer wil loggen (en ik wil alleen LOG-doelen voor heel weinig regels).

Iets als Wireshark voor Iptables. Of misschien zelfs iets dat lijkt op een debugger voor een programmeertaal.

Bedankt Chris

Notitie: Het hoeft geen fraaie GUI-tool te zijn. Maar het moet meer doen dan alleen maar een pakketteller laten zien.

Bijwerken: Het lijkt er bijna op dat we niets kunnen vinden dat de functionaliteit biedt waar om wordt gevraagd. In dat geval: laten we op zijn minst een goede techniek vinden die is gebaseerd op logboekregistratie van iptables - die eenvoudig kan worden in- en uitgeschakeld en die niet nodig is om iptables-regels redundant te schrijven (omdat dezelfde regel moet worden geschreven voor -j LOG en -j ...)


43
2018-03-13 11:00


oorsprong




antwoorden:


Ik kan geen directe oplossing bedenken, maar ik kan een manier bedenken om een ​​pakket te volgen.

  1. Registreer elke regel met een log-prefixrichtlijn (--log-prefix "Regel 34")
  2. Genereer een testpakket of pakketstream met scapy en stel het veld TOS in op iets unieks
  3. grep de uitvoer van het logbestand voor die TOS-instelling en zie welke regels zijn geregistreerd.

9
2018-03-16 12:56



Bedankt voor het idee. Helaas kan ik niet elke regel loggen (op een systeem zou de schijf waarschijnlijk niet snel genoeg zijn om dat te doen.) Op een ander is iptables loggen niet beschikbaar in de kernel.) - Chris Lercher
Gebruik een named pipe als bestand softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml  Maar omdat je je kernel niet kunt inloggen, ben je een beetje SOL - Haakon
Bedankt, het zal mijn probleem waarschijnlijk niet oplossen, maar het is over het algemeen leuk om te weten, dat piping syslog mogelijk zou zijn - zou op een ander moment van pas kunnen komen! - Chris Lercher
Een gerelateerde vraag over logboekregistratie: verwerkt iptables meerdere pakketten tegelijk (zodat logboekitems kunnen worden doorschoten)? In dat geval denk ik dat het TOS-idee een absolute must zou zijn voor veel iptables LOG-analyses! - Chris Lercher
Ik weet het antwoord daarop niet. Ik verwacht dat elke interface tegelijkertijd door iptables wordt behandeld. - Haakon


Als je een recent genoeg kernel en een versie van iptables hebt, kun je het TRACE-doel gebruiken (het lijkt erop gebouwd te zijn op tenminste Debian 5.0). Stel de voorwaarden van uw trace zo specifiek mogelijk in en schakel eventuele TRACE-regels uit wanneer u niet fout opspoort, omdat het veel informatie naar de logs spuwt.

SPOOR
  Dit doel markeert pakketten zodat   de kernel logt elke regel die   overeenkomen met de pakketten als die doorkruisen   de tafels, kettingen, regels. (De   De module ipt_LOG of ip6t_LOG is vereist   voor het loggen.) De pakketten zijn   ingelogd met de tekenreeks voorvoegsel: "TRACE:   tablename: chainname: type: rulenum "   waar type kan zijn "regel" voor gewoon   regel, "return" voor impliciete regel op   het einde van een door de gebruiker gedefinieerde keten en   "beleid" voor het beleid van de gebouwde   geketend. Het kan alleen worden gebruikt in de   ruwe tafel.

Als je regels als deze hebt toegevoegd

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

U zult worden voorzien van uitvoer die er zo uitziet.

# 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)

78
2018-03-25 05:53



Bedankt, dit is geweldig! Het is eigenlijk het beste antwoord, ik wou dat ik het kon accepteren (het was een premie vraag, dus het geaccepteerde antwoord is definitief). Hoewel ik het niet op al mijn systemen kan gebruiken (vanwege kernelbeperkingen), kan ik op sommige systemen dat wel. Dit antwoord verdient upvoting, omdat het echt in de buurt komt van wat ik zocht. - Chris Lercher
Ik vond deze functie gisteravond toen ik de iptables man-pagina opnieuw las, zodat ik een andere vraag kon beantwoorden. Lijkt een relatief nieuwe functie te zijn. Geen zorgen over het niet kunnen markeren als geaccepteerd. Misschien wordt dit na verloop van tijd genoeg gestemd om me een Populistisch insigne te bezorgen. - Zoredache
Dit is echt het canonieke antwoord voor het traceren van pakketten in iptables. Het is jammer dat sommige recente kernels dit standaard niet inschakelen. - Peter Grace
Hier kunt u aanvullende informatie over het thema vinden: adminberlin.de/iptables-debugging - zzeroo
Hoe lang geleden ondersteunt de kernel TRACE? Ik heb met succes CentOS 6.4 gebruikt, maar niet in CentOS 6.2 - sebelk


Drie antwoorden op één post:

1) Foutopsporing op script:

#!/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) Debug door syslog

Van deze website: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) Geen debug, leuke iptables-bewerking:

Dit kan ook nuttig zijn: http://www.fwbuilder.org/


6
2018-03-16 16:49



Bedankt. Punt 1) en 3) hebben niet veel te maken met het volgen van pakketten volgens de iptables-regels, maar het punt over het omleiden van logboekinvoeren op basis van "--log-niveau" kan nuttig zijn, als ik eindelijk echt terug moet vallen naar logging (voor het geval er absoluut geen andere oplossing is). - Chris Lercher


had dezelfde vraag en vond dat Zoredache wijzend naar TRACE / ipt_LOG de oplossing was!

Daarnaast vond ik een script dat log-regels invoegt / verwijdert voorafgaand aan alle huidige actieve iptables-regels. Ik probeerde het uit en vond het een heel leuk hulpmiddel. - Uitgang is vergelijkbaar met de TRACE-oplossing - Voordeel: het werkt op de actieve iptables-configuratie, ongeacht waar het werd geladen. U kunt het loggen direct aan / uit zetten! U hoeft geen firewall-scripts aan te passen die mogelijk zijn gegenereerd door Firewall Builder of tool, ongeacht wat u gebruikt ... - Nadeel: zonder wijziging creëert het script LOG-regels voor ALLE actieve regels. In plaats daarvan, wanneer u TRACE-regels gebruikt, beperkt u waarschijnlijk het loggen tot adressen / services / verbindingen waarvoor u de iptables-verwerking nu wilt onderzoeken.

Hoe dan ook, ik vind het een goed idee :) Een pluim voor Tony Clayton, kijk eens: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Vriendelijke groeten, Chris


2
2018-05-29 17:50





Ik gebruik meestal packets en bytetellers om te zien hoe regels werken en om te vinden wat er ontbreekt of fout is.

Je kunt ze bekijken met "iptables -nvL".


0
2018-03-15 12:14



Ik kan wel zien wat de auteur wil; als je je iptables-regels op een drukke interface probeert te testen, zal het bekijken van tellers niet veel helpen, vooral als het pakket waarschijnlijk op verschillende regels overeenkomt en door de gebruiker gedefinieerde ketens in het proces springt (zoals typisch is wanneer filteren van ongewenste IP-adressen en regels tegen overstromingen). - PP.
@PP: Precies, je leest mijn gedachten. @Vi: Bedankt, dit kan in sommige omstandigheden nuttig zijn, en ik heb dat soms gebruikt. Nu heb ik iets krachtigers nodig. - Chris Lercher


AFAIK Een IP-pakket doorloopt de regelketen tot de eerste overeenkomst. Dus ik zie niet echt wat het probleem hier is. Als je hebt:

  1. regel 1
  2. regel 2
  3. regel 3 LOG

En een pakket maakt het in het log, dit betekent dat regel 3 de eerste matchingsregel is.


-2
2018-03-15 12:39



Niet waar. Pakketten kunnen overeenkomen met meerdere regels, en dat doen ze. Tenzij een regel een actie heeft (zoals -j DROP of -j ACCEPT) het blijft gewoon doorgaan met matchen verderop in de keten. - PP.