hokaido
Goto Top

At reboot in cron wird ignoriert

Hallo,

ich habe der /etc/crontab als letzte Zeile

@reboot root /etc/init.d/firewall.sh
hinzugefügt.

Dort ist eine iptables Regel drin, die hinzugefügt werden soll. Der Befehl wird aber ignoriert.

Auf einem Testserver mit gleichem System funktioniert es aber.

Woran kann das liegen bzw. gibt es andere Möglichkeiten das Script beim Start zu laden?

Danke

Content-Key: 1934335579

Url: https://administrator.de/contentid/1934335579

Printed on: July 12, 2024 at 16:07 o'clock

Mitglied: 1915348599
1915348599 Feb 17, 2022 updated at 09:59:15 (UTC)
Goto Top
Zitat von @hokaido:
@reboot root /etc/init.d/firewall.sh
Was soll deiner Meinung nach das root bewirken? Das hat da eigentlich nichts zu suchen.
Der Befehl wird aber ignoriert.
Cron-Service läuft nicht/wird beim Boot nicht gestartet? Skript ist nicht als ausführbar markiert (chmod +x script.sh)? Komplette Pfade zu executables im Skript hinterlegt?

p.s. das syslog verrät dir ziemlich viel was so im System ab geht und schief läuft face-wink.
Member: HanTrio
HanTrio Feb 17, 2022 at 09:56:08 (UTC)
Goto Top
Moin,

- Script ist ausführbar? -> chmod +x
- im Script selber: sind die commands mit dem full path eingetragen?

Also wenn im Script zB nur "iptables" drin steht, wird das ggf. nicht funktieren -> da muss explizit "/usr/sbin/iptables" drin stehen.
(den full path für das Command kannst du im Zweifelsfall mit "which iptables" auslesen).

Ansonsten, hast du das file "etc/crontab" direkt bearbeitet?
Sonst versuchs mal mit "crontab -e", dann wird der Cronjob auch gleich installiert.
Oder auch: "systemctl reload cron" im Anschluss an deine direkte Änderung per text editor.
Member: hokaido
hokaido Feb 17, 2022 at 10:06:37 (UTC)
Goto Top
Also Script ausführbar: ja
Pfad zu iptables: ja
etc/crontab direkt bearbeit: jaface-smile

Und ich lösche auch mal das root.

Werde berichten...
Mitglied: 117471
117471 Feb 17, 2022 at 10:35:17 (UTC)
Goto Top
Hallo,

warum das nicht geht - keine Ahnung. Aber das ist eh' Ieh-Bah was Du da vorhast...

Die Regeln speichert man in /etc/iptables/rules.v4 bzw. /etc/iptables/rules.v6

iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

Das automagische Einlesen beim Systemstart hängt ein bisschen von der Distribution ab. Bei Debian, Ubuntu usw. reicht es, das Paket iptables-persistent via apt nachzuinstallieren. Gelegentlich muss auch ein Service installiert und enabled sein (RedHat, CentOS usw.).

Genaueres weiß man hier: Iptables Firewall Regeln dauerhaft speichern (Thomas Krenn Wiki)

Das zum Einen.

Zum Anderen: Wenn Du ein Script beim Systemstart starten willst - lass' den Cron-Quatsch. In dem Fall hängt das davon ab, ob Du tatsächlich noch das alte SystemV-Initkonzept oder den systemd verwendest. Die meisten aktuellen Distris benutzen systemd - es sei denn, der Betreiber weiß, was er tut face-smile

Beim systemd erstellst Du einen eigenen Service; z.B. unter /etc/systemd/system/firewall.service

[Unit]
Description=WOL Zeitfenster prüfen.

[Service]
Type=simple
ExecStart=/etc/init.d/firewall.sh

[Install]
WantedBy=multi-user.target

Anschließend aktivierst Du den mit
systemctl enable wol_check

Wenn Du tatsächlich SystemV Init benutzt, legst Du "wie gehabt" symbolische Links in den Verzeichnissen der jeweiligen Runlevel an. Evtl. hat deine Distribution auch ein Tool, was das automatisch erledigt.

Gruß,
Jörg
Member: hokaido
hokaido Feb 17, 2022 at 16:38:03 (UTC)
Goto Top
Iptables save speichert mir aber alle iptables weg. Ich will aber nur eine Regel hinzufügen, der Fest soll weiterhin mit ufw verwaltet werden.
Und so wie ich es verstanden habe käme sich iptables save dann mit ufw in die quere.

Ich probiere mal den Dienst und die beiden Lösungen oben
Member: hokaido
hokaido Feb 17, 2022 updated at 21:40:47 (UTC)
Goto Top
@1915348599 , @HanTrio:
Hab beides probiert, hat leider nicht funktioniert

@117471:

Hab auch Deine Lösung probiert:
Beim systemd erstellst Du einen eigenen Service; z.B. unter /etc/systemd/system/firewall.service

[Unit]
Description=WOL Zeitfenster prüfen.

[Service]
Type=simple
ExecStart=/etc/init.d/firewall.sh

[Install]
WantedBy=multi-user.target

Anschließend aktivierst Du den mit
systemctl enable wol_check

=> Funktioniert leider auch nicht.

Bist Du Dir mit "systemctl enable wol_check" sicher? Einen wol_check service hab ich nicht. Ich habe "systemctl enable firewall" gemacht...

Bringt aber auch nix, wird nach Reboot nicht geladen
Mitglied: 117471
117471 Feb 17, 2022 at 22:11:19 (UTC)
Goto Top
Hallo,

stimmt, da war noch ein Tippfehler face-smile

systemctl enable firewall

ist natürlich richtig. Vorausgesetzt, die Unit heißt auch firewall.service face-smile

Beide Lösungen funktionieren. Und Du kannst natürlich auch grundsätzlich initiale Regeln setzen und dann im laufenden Betrieb erweitern.

Was ufw macht - keine Ahnung?!? Solche Tools sind eher unüblich - genau so wie deine Cron-Geschichte.

Vielleicht ist es auch dieses ominöse ufw, was Dir die Regeln überschreibt und einfach dich nur vermuten lässt, dass deine Regeln nicht geladen werden?!?

Gruß,
Jörg
Member: hokaido
hokaido Feb 17, 2022 at 22:21:51 (UTC)
Goto Top
Ja, die Unit heißt firewall.service...

Ne, UFW überschreibt hier nix.
Iptables -L sagt eindeutig, dass nix geladen wurde, Script manuell ausgeführt... Schwupp alles, da.

Muss ich wohl weiter auf die Suche gehen. Wie gesagt, Testserver funktioniert sogar die Cron Lösung.
Mitglied: 117471
117471 Feb 17, 2022 at 23:09:52 (UTC)
Goto Top
Hallo,

wie gesagt - ich vermute eher, dass die iptables-Regeln wie gewünscht beim booten geladen und irgendwann (ebenfalls beim booten) von diesem ominösen ufw-Ding überschrieben werden.

Das würde zumindest das von Dir beschriebenen Verhalten erklären.

Ob das Script abgearbeitet wird, kann man ja leicht eingrenzen. Falls Du es denn mit systems machst. Üblich ist wie gesagt iptables-save

Gruß,
Jörg
Mitglied: 1915348599
1915348599 Feb 18, 2022 updated at 06:14:27 (UTC)
Goto Top
Btw. User Regeln sollten bei ufw in die Chain
ufw-user-input geschrieben werden.
Um Regeln zu ergänzen, die liegen hier /etc/ufw zusätzliches Skript also überflüssig, denn sofern man die Regeln gespeichert hat bleiben sie auch da wo sie sind.
Du brauchst also für Blocklistst nur noch ein cron für das regelmäßige Update der ipsets, das muss nicht zwingend beim Reboot geschehen, da ipsets ebenfalls gespeichert werden.
Das regelmäßige Hinzufügen einer iptables Regel beim Reboot ist also vollkommen überflüssig wenn du es richtig machst.

Tipps Umstieg ufw zu iptables
Member: hokaido
hokaido Feb 18, 2022 at 23:19:58 (UTC)
Goto Top
@1915348599:
Diese Regel gehört in die Chain INPUT
Mitglied: 1915348599
1915348599 Feb 19, 2022 updated at 06:50:36 (UTC)
Goto Top
Zitat von @hokaido:

@1915348599:
Diese Regel gehört in die Chain INPUT

Schau dir doch die Default Regeln mal genau an ufw-user-input ist eine Chain die aus der INPUT heraus angesprungen wird! Und genau da legt ufw die vom User generierten Regeln ab...
Member: hokaido
hokaido Feb 19, 2022 at 21:26:01 (UTC)
Goto Top
@1915348599:
Wo finde ich die Default Regeln. Bei mir steht in der Imput Chain nix von ufw-user-input
Mitglied: 1915348599
1915348599 Feb 20, 2022 updated at 09:05:59 (UTC)
Goto Top
Oben schon verlinkt ...
Tipps Umstieg ufw zu iptables

Erst wird von INPUT nach ufw-before-input
-A INPUT -j ufw-before-input
gesprungen, und von dort aus dann in die final ufw-user-input Chain in der die vom User platzierten Regeln für ufw stehen sollten
-A ufw-before-input -j ufw-user-input
Member: hokaido
hokaido Feb 23, 2022 updated at 10:21:24 (UTC)
Goto Top
Danke für Euren Input

Ich hab das ganze jetzt so wie von mir geschildert mit dem Skript hinbekommen. Irgendwas hatte da im System nicht gepasst, nach Backup zurückspielen funktioniert das jetzt.
Regel wird automatisch hinzugefügt.

Wie schon erwähnt soll diese Regel aber an 1. Stelle dert INPUT Chain stehen:
iptables -I INPUT 1 -m set --match-set blacklist src -j DROP

Wenn ich iptables -L INPUT -v --line-numbers mache, sehe ich, dass sie zwar geladen wird, aber irgendwo an Stelle x, nach div. Fail2Ban Regeln.

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      110 14584 f2b-nginx-nowordpress  tcp  --  any    any     anywhere             anywhere
2       46  4623 f2b-roundcube  tcp  --  any    any     anywhere             anywhere             multiport dports http,https
3       46  4623 f2b-nextcloud  tcp  --  any    any     anywhere             anywhere             multiport dports http,https
4      110 14584 f2b-portscan-block  tcp  --  any    any     anywhere             anywhere
5       46  4623 f2b-nginx-noproxy  tcp  --  any    any     anywhere             anywhere             multiport dports http,https
6       46  4623 f2b-nginx-badbots  tcp  --  any    any     anywhere             anywhere             multiport dports http,https
7       46  4623 f2b-webexploits  tcp  --  any    any     anywhere             anywhere             multiport dports http,https
8        9   364 DROP       all  --  any    any     anywhere             anywhere             match-set blacklist src
9       38  3056 f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports xy
10    2985  254K ufw-before-logging-input  all  --  any    any     anywhere             anywhere
11    2985  254K ufw-before-input  all  --  any    any     anywhere             anywhere
12       4   212 ufw-after-input  all  --  any    any     anywhere             anywhere
13       3   160 ufw-after-logging-input  all  --  any    any     anywhere             anywhere
14       3   160 ufw-reject-input  all  --  any    any     anywhere             anywhere
15       3   160 ufw-track-input  all  --  any    any     anywhere             anywhere

Um zu verhindern, dass die F2B Regeln an 1. Stelle stehen, habe ich noch das hier ausgeführt.

tee << EOF /etc/fail2ban/action.d/iptables-multiport.local
[Definition]
actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> 2 -p <protocol> -m multiport --dports <port> -j f2b-<name>
EOF
Leider stehen aber immer noch einige F2B Regeln vor meiner gewünschten Regel.

Gebe ich
iptables -I INPUT 1 -m set --match-set blacklist src -j DROP
ein, steht die Regel an 1. Stelle, wird aber natürlich nach einem Reboot wieder verworfen.

Habt Ihr hier noch einen Tipp?

Danke
Mitglied: 117471
117471 Feb 23, 2022 at 17:57:00 (UTC)
Goto Top
Hallo,

ich habe Dir geschrieben wie man iptables Regeln dauerhaft speichert. Deine Scriptlösung ist für mich nicht nachvollziehbar, insofern kann ich Dir da nicht weiterhelfen.

Übrigens: Regeln von fail2ban gehören natürlich(!) an den Anfang. Eigentlich logisch, oder?

Gruß,
Jörg
Member: hokaido
hokaido Feb 23, 2022 updated at 18:23:54 (UTC)
Goto Top
Fail2Ban Regeln gehören an den Anfang, richtig. Sind sie ja auch.
Blacklist Regeln gehören aber davor.
Weil was generell geblockt werden soll, muss Fail2Ban gar nicht erst durchlaufen

Es geht nicht mehr um das Skript, das funktioniert und die Sache ist längst durch. Siehe oben. Nebenbei hab ich es in der Zwischenzeit mit einem Dienst gemacht. Das Funktioniert auch, bringt aber auch das Ergebnis, dass die Regeln nicht da steht wo sie lt Befehl stehen soll.

Es geht um die Position und wie man sie verändern kann.