17
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
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
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1934335579
Url: https://administrator.de/forum/at-reboot-in-cron-wird-ignoriert-1934335579.html
Ausgedruckt am: 06.04.2025 um 06:04 Uhr
17 Kommentare
Neuester Kommentar
Was soll deiner Meinung nach das root bewirken? Das hat da eigentlich nichts zu suchen.
p.s. das syslog verrät dir ziemlich viel was so im System ab geht und schief läuft
.
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
.
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.
- 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.
Also Script ausführbar: ja
Pfad zu iptables: ja
etc/crontab direkt bearbeit: ja
Und ich lösche auch mal das root.
Werde berichten...
Pfad zu iptables: ja
etc/crontab direkt bearbeit: ja
Und ich lösche auch mal das root.
Werde berichten...
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
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
Beim systemd erstellst Du einen eigenen Service; z.B. unter /etc/systemd/system/firewall.service
Anschließend aktivierst Du den mit
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
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.v6Das 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
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.targetAnschließend aktivierst Du den mit
systemctl enable wol_checkWenn 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
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
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
@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
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
Hallo,
stimmt, da war noch ein Tippfehler
ist natürlich richtig. Vorausgesetzt, die Unit heißt auch firewall.service
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
stimmt, da war noch ein Tippfehler
systemctl enable firewallist natürlich richtig. Vorausgesetzt, die Unit heißt auch firewall.service
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
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.
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.
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
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
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
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
@1915348599:
Diese Regel gehört in die Chain INPUT
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...
@1915348599:
Wo finde ich die Default Regeln. Bei mir steht in der Imput Chain nix von ufw-user-input
Wo finde ich die Default Regeln. Bei mir steht in der Imput Chain nix von ufw-user-input
Oben schon verlinkt ...
Tipps Umstieg ufw zu iptables
Erst wird von INPUT nach 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
Tipps Umstieg ufw zu iptables
Erst wird von INPUT nach ufw-before-input
-A INPUT -j ufw-before-input-A ufw-before-input -j ufw-user-input
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.
Um zu verhindern, dass die F2B Regeln an 1. Stelle stehen, habe ich noch das hier ausgeführt.
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
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 anywhereUm 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>
EOFGebe 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
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
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
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.
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.
