debianforum.de

Verfasst: **25.08.2015 14:02:24**

Hallo Community,

ich habe mich per Buch in die iptables Filterung (Firewall) eingelesen und ein Script erstellt.

touch /etc/init.d/firewall
chmod 755 /etc/init.d/firewall

in der /etc/rc.local vor exit 0

Code: Alles auswählen

. /etc/network/firewall

Soweit ich das verstanden habe, müssten die iptable Logs in der /var/log/messages bzw. syslog zu finden sein.
Da finde ich aber keine entsprechende Logs. Wo sind diese?

BTW: Kann man die Firewall-Logs auch in eine andere (eigene) Log-Datei schreiben lassen - der besseren Übersichtlichkeit wegen?
Ich habe im Netz die Anpassung der /etc/syslog.conf gelesen:

Code: Alles auswählen

kern.warning /var/log/iptables.log

Funktioniert aber auch nicht.

Danke & Grüße
Gersh

Verfasst: **25.08.2015 15:16:06**

Enthält das Script denn Regeln, in denen das Logging eingeschaltet wird (Option '-j LOG')?

Verfasst: **25.08.2015 15:18:22**

Hat Dein Script denn auch -j LOG an den richtigen Stellen?
Dann sollten die Einträge erstmal in /var/log/syslog landen.

Versuchs doch erstmal per Hand:
iptables -I INPUT -j LOG
wget http://debianforum.de
cat /var/log/syslog
iptables -D INPUT -j LOG

Hast Du nur vergessen die Regeln zu posten oder hast Du gar keine angelegt?
Ich hab ja keine Ahnung was da in dem Buch steht, aber nur touch reicht ohne Regelwerk definitiv nicht.

Verfasst: **25.08.2015 15:31:47**

Hallo,

das sind die Regeln:

Code: Alles auswählen

#!/bin/sh
echo "Initialisiere Firewall ..."
# Module laden
# Firewallregeln löschen
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# eigene Chains erstellen
iptables -N MYDROP
iptables -N MYACCEPT
# Loopback Kommunikation
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -J ACCEPT
# Stateful Inspection
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j MYDROP
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# eigene Chains MYDROP und MYACCEPT konfigurieren
iptables -A MYDROP -j LOG --log-prefix "FW-DROP: "
iptables -A MYDROP -j DROP
iptables -A MYACCEPT -j LOG --log-prefix "FW-ACCEPT: "
iptables -A MYACCEPT -j -ACCEPT
# SSH
iptables -A INPUT -p tcp --dport 22 -j MYACCEPT
# ICPM (Ping)
iptables -A INPUT -p icmp -j MYACCEPT
iptables -A OUTPUT -p icmp -j MYACCEPT
# DNS
iptables -A INPUT -p udp --dport 53 -j MYACCEPT
iptables -A INPUT -p tcp --dport 53 -j MYACCEPT
iptables -A OUTPUT -p udp --dport 53 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j MYACCEPT
# SAMBA
iptables -A INPUT -p udp -m multiport --destination-port 137,138 -s 192.168.0.1/24 -j MYACCEPT
iptables -A INPUT -p tcp -m multiport --destination-port 139,445 -s 192.168.0.1/24 -j MYACCEPT
iptables -A OUTPUT -p udp -m multiport --destination-port 137,138 -d 192.168.0.1/24 -j MYACCEPT
iptables -A OUTFUT -p tcp -m multiport --destination-port 139,445 -d 192.168.0.1/24 -j MYACCEPT
#DHCP
iptables -A INPUT -p udp --dport 67 -J MYACCEPT
echo "Firewall ist konfiguriert und aktiv!"
iptables -A INPUT -j LOG -log-prefix "FW-LAST-DROP: "

Ich habe vorhin aber auch ein anderes Script im Web gefunden (darf man Links posten?):
https://wiki.debianforum.de/Einfaches_Firewall-Script

dieses habe ich unter /etc/init.d/firewall.sh abgelegt.
Zunächst habe ich es, wie beschrieben in die /etc/crontab eingebunden:

Code: Alles auswählen

@reboot root /etc/init.d/firewall.sh

wird jedoch nicht geladen.
Dann versuchte ich es mit crontab -e

reboot root /etc/init.d/firewall.sh

Lädt aber anscheinend nanch einem reboot nicht, da ich mit iptables -L immer noch die Standardausgabe erhalte.
Ist natürlich mit chmod 755 freigegeben ...

Verfasst: **25.08.2015 17:21:10**

Versuch mal iptables jeweils durch den vollen Pfad zu ersetzen: /sbin/iptables

Edit: und ja, informative Links sind erwünscht (z.B. Quellenangaben), Werbung nicht

Verfasst: **26.08.2015 10:18:01**

Bei mir zumindest landen iptables-log outputs nicht im syslog sondern erscheinen im output von dmesg. Das überrascht mich jetzt auch nicht weiter - das Ding ist ja im Kernel und kann wohl nicht so einfach in Richtung Userspace loggen; und das dmesg-log ist wo der Kernel normalerweise sein Zeugs hinloggt...

z.B.

Code: Alles auswählen

$ dmesg
[3833108.723066] iptables:  too many conn.IN=eth0 OUT= MAC=... SRC=... DST=... LEN=40 TOS=0x00 PREC=0x00 TTL=113 ID=2560 PROTO=TCP SPT=43455 DPT=8888 WINDOW=16384 RES=0x00 SYN URGP=0 
[3833108.723176] iptables:  too many conn.IN=eth0 OUT= MAC=... SRC=... DST=... LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=2560 PROTO=TCP SPT=43455 DPT=8118 WINDOW=16384 RES=0x00 SYN URGP=0

MfG Peschmä

Verfasst: **26.08.2015 16:57:26**

peschmae hat geschrieben:das Ding ist ja im Kernel und kann wohl nicht so einfach in Richtung Userspace loggen; und das dmesg-log ist wo der Kernel normalerweise sein Zeugs hinloggt...

Mmmh, der Unterschied bei mir von der dmesg-Ausgabe und /var/log/kern.log ist jetzt nicht besonders.
dmesg hat noch ein paar systemd-Meldungen und das kern.log dafür einen absoluten Zeitstempel (und nicht nur für den aktuellen boot),
aber im groben und ganzen more or less equal ...

Verfasst: **26.08.2015 18:21:57**

dufty2 hat geschrieben:dafür einen absoluten Zeitstempel (und nicht nur für den aktuellen boot),

Meinten Sie "dmesg [-T|--ctime]"? Duerfte neu mit dem

util-linux aus Jessie sein.

Der Timestamp im /var/log/syslog etc. stammt uebrigens nicht vom Kernel, sondern bezeichnet den Zeitpunkt, an dem der Logger die Zeile entgegengenommen hat.

Gruss Cae

Verfasst: **26.08.2015 19:11:50**

Cae hat geschrieben:
dufty2 hat geschrieben:dafür einen absoluten Zeitstempel (und nicht nur für den aktuellen boot),
Meinten Sie "dmesg [-T|--ctime]"?

Nö.

Code: Alles auswählen

Aug 26 17:30:25 host kernel: [ 3594.700728] IN=eth0 OUT= MAC=<snip>

Der Teil "Aug 26 17:30:25 host kernel: " kommt vom Logger (vermutlich rsyslogd, welcher es wiederum vom systemd-journald erhalten hat) und hat eine absolute Zeitangabe.
Wohingegen "[ 3594.700728]" der relative Zeitstempel (in Sekunden seit dem Booten) des kernels ist.
dmesg ist auch kein logger im eigentlichen Sinn, sondern nur ein buffer (noch genauer: nur die Ausgabe davon.)

Wer weiß, vielleicht loggt gershwin nur noch über journald und gar nicht mehr über (r)syslogd.

Verfasst: **27.08.2015 09:30:11**

Hallo,

hatte die letzte Tage leider keine Zeit mich um die Sache zu kümmern.

@eggy

Hat Dein Script denn auch -j LOG an den richtigen Stellen?
Dann sollten die Einträge erstmal in /var/log/syslog landen.

Versuchs doch erstmal per Hand:
iptables -I INPUT -j LOG
wget http://debianforum.de
cat /var/log/syslog
iptables -D INPUT -j LOG

Hast Du nur vergessen die Regeln zu posten oder hast Du gar keine angelegt?
Ich hab ja keine Ahnung was da in dem Buch steht, aber nur touch reicht ohne Regelwerk definitiv nicht.

Ich habe ja dieses Muster verwendet: https://wiki.debianforum.de/Einfaches_Firewall-Script
Hierin finde ich kein iptables -I INPUT -j LOG, einzig diese "Logging Options" Zeilen, welche ja anscheinend nicht ausreichend sind:

Code: Alles auswählen

# Logging options.
#------------------------------------------------------------------------------
LOG="LOG --log-level debug --log-tcp-sequence --log-tcp-options"
LOG="$LOG --log-ip-options"

Ich habe es dann händisch mit Deinem Code (s. Quote) probiert und fand in der /var/log/syslog tatsächlich Einträge.

Versuch mal iptables jeweils durch den vollen Pfad zu ersetzen: /sbin/iptables

Das ist in dem Script gemacht (Auszug):

Code: Alles auswählen

IPTABLES="/sbin/iptables"
$IPTABLES ....

Mal zum Verständnis. Die Eingaben:

Code: Alles auswählen

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

löschen ja erstmal die generellen Freigaben.

Wenn ich jetzt im firewall.sh die HTTP/S-Zeilen ausdokumentiere:

Code: Alles auswählen

#$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
#$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
#$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
#$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

... müsste ja wget http://debianforum.de geblockt werden - oder?
Da nicht geblockt, sonder weiter Logs erscheinen, scheint mein Script ja nicht geladen zu sein.
Ich habe dieses unter /etc/init.d/firewall.sh abgelegt und im crontab -e mit:

Code: Alles auswählen

@reboot /etc/init.d/firewall.sh

eingebunden.
Stelle ich mir die Frage, wieso dieses nicht ausgeführt wird und anscheinend noch alle Freigaben aktiv sind

Wenn das Script funktionieren sollte, wo setze ich denn

Code: Alles auswählen

iptables -I INPUT -j LOG

rein? -I stellt die Regel ja nach "oben". Also so hoch als mögl. unter die drei "drops"?
Kann man dann trotzdem noch die iptable-Logs in eine eigene Log-Datei umleiten, damit es übersichtlicher ist?

Danke vielmals!
Gersh

Diese händische Eingabe

Verfasst: **27.08.2015 11:39:44**

gershwin hat geschrieben:-I stellt die Regel ja nach "oben". Also so hoch als mögl. unter die drei "drops"?

Die Policies (-P) werden zuletzt befragt, nachdem keine der spezifischeren Regeln zugetroffen ist. Sie sind in diesem Sinne "ausserhalb" des normalen Regelsatzes, den du mit -I/-A/-D manipulierst.

Da hier einiges nicht zu funktionieren scheint: Wie ist das System an die Hardware bzw. das Netzwerk angebunden? Ist das vielleicht eine komische VM, ein Container, etc.? Hast du schon mal ein umfassendes --flush bemueht und die Regeln komplett neu geladen?

dufty2 hat geschrieben:Wohingegen "[ 3594.700728]" der relative Zeitstempel (in Sekunden seit dem Booten) des kernels ist.

Das ist korrekt. Bei dmesg -T hat man da allerdings einen absoluten, menschenlesbaren Timestamp stehen. Wie oben angedeutet, es ist ein neues (und imho sehr praktisches [1]) Feature, auf das ich hinweisen wollte.

Gruss Cae

[1] noch praktischer ist allerdings dmesg --follow

Verfasst: **27.08.2015 11:59:33**

Hallo Cae,

nein, nix VM o.ä.
Das ist ein ganz neu, schlankes Debian Jessie mit nur Samba und ein paar Tools drauf.
Per Netzwerkkabel an einen Switch und ins Web geht es über einen Netgear-Router mit HW-FW.

iptables -flush hatte ich gemacht.
Bei iptables --list erhalte ich die 3 Standard ACCEPT gelistet
Flushe ich nochmal und reboote, erscheinen bei --list immer noch die 3 ACCEPT.
Mir dünkt einfach, dass die firewall.sh nicht über @root geladen wird.

Wenn ich --list eingebe und das Script geladen wäre, müssten doch die dort angegebenen Regeln aufgelistet werden.

Danke & Grüße
Gersh

Verfasst: **27.08.2015 12:14:57**

Dann starte das Skript mal haendisch, auch wenn der Cronjob-Setup oben eigentlich richtig aussieht. Evtl. hat cron etwas in's Syslog geschrieben? @reboot sollte ein guter Suchstring sein.

Gruss Cae

Verfasst: **27.08.2015 14:33:02**

Ich habe jetzt im syslog gesucht nach:
@reboot

Code: Alles auswählen

Datun Zeitstempel Servername cron[442]: (CRON) INFO (Running @reboot jobs)

firewall.sh

Code: Alles auswählen

Datun Zeitstempel Servername cron[442]: (root) CMD (/etc/init.d/firewall.sh)

dann habe ich das Script manuell gestartet

Code: Alles auswählen

sh /etc/init.d/firewall.sh

danach

Code: Alles auswählen

iptables --list

... immer noch die 3 Standard-Freigaben
Andere manuelle Starts von Crons laufen durch - habe ich getestet.
Also müsste - rein logisch - irgend etwas am Script faul sein - oder?
Sollte ich mal alle Zeilen checken, obwohl ich das 1:1 vom wiki übernommen habe und kein Kommentar bzgl. eines Fehlers zu sehen ist.

Frage nochmal: Wenn das Script laufen würde, dürfte ich bei iptables --list nicht mehr nur die 3 Standard Freigaben sehen - oder?

Danke & Grüße

Verfasst: **27.08.2015 16:25:56**

Das sind keine "Standard-Freigaben".

Das was Du da siehst, ist das aktuelle Regelwerk. Inclusive der sogenannten "Policy". Die Policy ist die Regel die angewandt wird, wenn es keine der anderen Regeln vorher zutraf - oder es noch keine andere Regel gibt.

Schieb Dein (ganzes) Script doch mal nach pastebin.php .
Sonst wär noch zu kläreren: stimmen die Berechtigungen?

Verfasst: **27.08.2015 16:29:45**

pastebin.php?mode=view&s=38762

das Script ist mit 755 freigegeben - wie in der Anleitung beschrieben.

Danke für die Unterstützung!

Verfasst: **27.08.2015 16:48:27**

änder mal die erste Zeile
#!/bin/bash -x
und führ das Script nochmal als root aus, und poste den kompletten Output nach paste.

Verfasst: **09.09.2015 14:23:18**

dufty2 hat geschrieben:
peschmae hat geschrieben:das Ding ist ja im Kernel und kann wohl nicht so einfach in Richtung Userspace loggen; und das dmesg-log ist wo der Kernel normalerweise sein Zeugs hinloggt...
Mmmh, der Unterschied bei mir von der dmesg-Ausgabe und /var/log/kern.log ist jetzt nicht besonders.
dmesg hat noch ein paar systemd-Meldungen und das kern.log dafür einen absoluten Zeitstempel (und nicht nur für den aktuellen boot),
aber im groben und ganzen more or less equal ...

Ja, der Unterschied war mir noch nie ganz klar, in kern.log steht das Zeug bei mir auch, aber nie im Syslog. wobei das sicherlich auch nur eine Konfigurationssache ist...

Verfasst: **09.09.2015 15:06:28**

peschmae hat geschrieben:Ja, der Unterschied war mir noch nie ganz klar, in kern.log steht das Zeug bei mir auch, aber nie im Syslog. wobei das sicherlich auch nur eine Konfigurationssache ist...

Welche Meldungen in welche Datei gelogt werden, steht in /etc/rsyslog.conf und ggfls. in Dateien unter /etc/rsyslog.d, die in /etc/rsyslog.conf inludiert werden (können).

Ich bin auch nicht sehr glücklich mit der Vorkonfiguration von rsyslogd, da aber jeder Anwender seine eigenen Vorzüge hat, kann man es wohl keinem recht machen, die Standardkonfiguration ist immer nur eingeschränkt sinnvoll.

debianforum.de

Wo logged iptables?

Wo logged iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?

Re: Wo Log der iptables?