Wie Skript per Autostart ausführen? (Oder alternativ Firewalld für ein "VPN-Killswitch" konfigurieren?)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema Wie Skript per Autostart ausführen? (Oder alternativ Firewalld für ein "VPN-Killswitch" konfigurieren?) gibt es 13 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Wie Skript per Autostart ausführen? (Oder alternativ Firewalld für ein "VPN-Killswitch" konfigurieren?)

    Neu

    Hallo,

    ich würde gerne ein Bash-Skript bei Systemstart automatisch ausführen lassen.

    Hintergrund:

    Normalerweise möchte ich mich gerne durch einen VPN-Dienst etwas anonymisieren. Dazu ist es mir (absoluter Anfänger! :/ ) gelungen, über den Network-Manager eine openVPN-Verbindung einzurichten und diese wiederum an meine (kabelgebundene) Netzwerkverbindung zu koppeln. Dazu habe ich in den Netzwerkeinstellungen unter Allgemein das Häkchen gesetzt bei "Automatisch mit VPN verbinden, wenn diese Verbindung benutzt wird".
    Das klappt auch soweit ganz gut. Bei Systemstart und auch nach Aufwachen aus Standby wird die VPN-Verbindung wieder aufgebaut.
    Über den Network-Manager kann ich so auch mehrere VPN-Verbindungen einrichten und bei Bedarf auch mal recht einfach von der vorausgewählten Verbindung auf eine andere umschalten.

    Allerdings hätte ich die Verbindung noch gerne "abgesichert". D.h. es soll keine Internet-Kommunikation möglich sein, wenn die VPN-Verbindung aus irgendeinem Grund abbricht. Es soll auch kein Umgehen der VPN-Verbindung möglich sein.

    Dafür habe ich mir ein kleines Bash-Skript gebastelt (hauptsächlich aus dem Internet abgeschrieben, da ich selbst zu sowas gar nicht in der Lage wäre!)
    Das sieht so aus:

    Shell-Script

    1. #!/bin/bash
    2. #Iptables Regeln für VPN:
    3. iptables -t filter -A OUTPUT -o wlan0 -p udp -m multiport --dports 443,53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    4. iptables -t filter -A OUTPUT -o eth0 -p udp -m multiport --dports 443,53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    5. iptables -t filter -A INPUT -i wlan0 -p udp -m multiport --sports 443,53 -m state --state ESTABLISHED,RELATED -j ACCEPT
    6. iptables -t filter -A INPUT -i eth0 -p udp -m multiport --sports 443,53 -m state --state ESTABLISHED,RELATED -j ACCEPT
    7. iptables -t filter -A OUTPUT --dst 192.168.0.0/16 -j ACCEPT
    8. iptables -t filter -A INPUT --src 192.168.0.0/16 -j ACCEPT
    9. iptables -t filter -A OUTPUT --dst 10.0.0.0/8 -j ACCEPT
    10. iptables -t filter -A INPUT --src 10.0.0.0/8 -j ACCEPT
    11. iptables -t filter -A OUTPUT --dst 172.16.0.0/12 -j ACCEPT
    12. iptables -t filter -A INPUT --src 172.16.0.0/12 -j ACCEPT
    13. iptables -t filter -A OUTPUT -o wlan0 -j DROP
    14. iptables -t filter -A INPUT -i wlan0 -j DROP
    15. iptables -t filter -A OUTPUT -o eth0 -j DROP
    16. iptables -t filter -A INPUT -i eth0 -j DROP
    Alles anzeigen
    Quelle:
    Tipps & Tricks: - Linux absichern mit den iptables


    | Perfect Privacy Forum

    Das Ganze habe ich mit Kate erstellt und als vpn.sh abgespeichert.
    Dann habe ich das Skript ausführbar gemacht mit:

    Quellcode

    1. chmod +x /pfad/zu/mein_Skript
    oder auch

    Quellcode

    1. chmod u+x /pfad/zu/mein_Skript
    (Scheint auf's selbe rauszulaufen, das übersteigt im Moment noch meine Fähigkeiten!)

    Jedenfalls habe ich es dann getestet durch:

    Quellcode

    1. ./mein_Skript
    Ich drücke mich mal vorsichtig aus: Es scheint zu funktionieren! Heißt z.B. Internetbrowser läuft. Wenn ich dann die VPN-Verbindung im Network-Manager beende, kriege ich keinen Internetzugang mehr. Also das, was ich will.

    Es gibt bei der ganzen Sache zwar noch einige Unsicherheiten, z.B. bin ich mir nicht sicher, ob sich meine Regeln nicht doch irgendwie mit den schon vorhandenen Regeln von Firewalld beißen. Vielleicht sollte ich z.B. ein iptables -F als erste Regel ins Skript setzen. Nach Ausprobieren scheint das praktisch aber egal zu sein!
    Oder: Eigentlich sollte mein interner Netzwerkverkehr bei diesen Regeln noch funktionieren. Tut er aber nicht, bzw. nur, ohne aufgebaute VPN-Verbindung!

    Wenn ich nun aus irgendeinem Grund doch wieder unlimitierten Internetzugang ohne diese Regeln will, kann ich über die Konsole ein

    Quellcode

    1. firewall-cmd --reload
    absetzen, dann sind die iptables wieder weg, bzw. wurden durch die von firewalld (zone public) ersetzt.

    Apropos Firewalld:
    Ich wäre auch an anderen (evtl. einfacheren) Realisierungsmöglichkeiten interessiert ...
    Z.B. die o.g. iptables-Regeln in eine neu erstellte Zone in Firewalld zu packen und diese Zone dann als Standard-Zone definieren. Dann könnte ich (wenn ich die Regeln mal kurzfristig abwählen will) auch einfach die Zone wechseln (so stelle ich mir das zumindest vor!).
    Aber ich habe mich damit schon tagelang abgemüht (kann auch Threads aus dem Internet nachreichen, in denen andere das schon versucht haben) und im Grunde nur herausgefunden, dass Firewalld wohl nicht mit dem Erstellen direkter Regeln in Zonen klarkommt.
    Stattdessen müsste man sog. Rich-Rules verwenden. Und wie man wiederum die o.g. Regeln in firewalld-konforme Rich-Rules umwandelt, sprengt den Rahmen für mich!

    Da ich wie gesagt normalerweise aber nur mit aktiviertem VPN ins Netz möchte, wäre es bequemer, wenn ich das Skript nicht jedes Mal manuell starten müsste.

    Ich hab das Thema schon gegoogelt (z.B. "opensuse skript automatisch starten"), aber - nun ja - das scheint schon ein sehr weites Feld ... die Suchergebnisse sind teils schon einige Jahre alt und bringen mich irgendwie nicht weiter.

    Ich hatte auch gehofft - und jetzt komme ich endlich zur eigentlichen Frage - dass es vielleicht ganz einfach wäre!

    Es gibt ja in openSUSE Leap 15 (KDE Plasma), wenn ich das Anwendungsmenü öffne, diesen Eintrag "Autostart". Dort gibt es sogar extra die Kategorie "Sriptdatei". Dort kann ich mein Skript, dass in meinem Home-Ordner liegt, auswählen (es erhält dann auch gleich den Status "Aktiviert") und muss mich nur noch entscheiden, was ich punkto "Ausführungszeitpunkt" auswähle. Entweder "vor Sitzungsstart" oder "Anmeldung". Da ich automatisch und ohne Passwort angemeldet werde, dachte ich, dass letzteres womöglich nicht funktioniert. Ich habe aber beides ausprobiert und es funktioniert beides nicht! :(
    Was mache ich falsch?

    Für den Inhalt des Beitrages 123579 haftet ausdrücklich der jeweilige Autor: Neuer1

  • Neu

    Neuer1 schrieb:

    Ich habe aber beides ausprobiert und es funktioniert beides nicht!
    Hier funktioniert es mit Plasma und Systemeinstellungen-----Arbeitsbereich---Starten und Beenden----Autostart.....
    Allerdings nur im Userkontex.....

    iptables ist root....

    Dein Script ist auch ausführbar?

    Befasse dich mit systemd.......
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 123585 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Neu

    "im Userkontext" heißt, dass, wenn sich ein anderer User anmelden würde, dass es dann nicht funktionieren würde?
    Das wäre soweit okay, da es nur einen eingeschränten User gibt, der auch direkt ohne Passwort angemeldet wird.

    "iptables ist root"
    Damit meinst du was?

    Wie könnte ich denn überprüfen, ob mein Skript auch die richtigen Rechte besitzt?

    Ich glaube, systemd ist mir ein paar Nummern zu groß!

    Für den Inhalt des Beitrages 123587 haftet ausdrücklich der jeweilige Autor: Neuer1

  • Neu

    Quellcode

    1. ich@linux64:~> iptables
    2. Absolute path to 'iptables' is '/usr/sbin/iptables', so running it may require superuser privileges (eg. root).
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 123588 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Neu

    Leider sind mir deine Informations-Schnipsel etwas zu knapp.
    Wenn da steht, "may require", dann wird es wohl so sein. Aber was bedeutet das jetzt für mich?

    Ich habe es mal versucht, vor jeden Befehl ein sudo zu schreiben. Zuvor hatte ich es mit einem su - probiert, also, am Beispiel der ersten Zeile so:

    Quellcode

    1. su - iptables -t filter -A OUTPUT -o eth0 -p udp -m multiport --dports 443,53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    Als Antwort kam dann aber für alle Zeilen:

    Quellcode

    1. su: Ungültige Option -- t
    Mit einem sudo vorangestellt, anstelle su - kommt diese Meldung nicht.
    Wenn ich, ein sudo vorangeschickt, dann die Datei ausführe mit:

    Quellcode

    1. ./vpn.sh
    funktioniert es. Also ein Ausführungsrecht hat die Datei wohl. Der letzt genannte Befehl funktioniert aber nur, wenn ich eine Konsole im Home-Ordner öffne. Wenn ich es so versuche:

    Quellcode

    1. ./home/keiner/vpn.sh
    funktioniert es nicht. (Mein Benutzername ist immer noch "keiner"!)

    Sicherheitshalber habe ich aber auch noch mal ein

    Quellcode

    1. chmod +x /home/keiner/vpn.sh
    abgeschickt.


    So, wenn ich jetzt das System neu starte, wobei das Skript

    Shell-Script

    1. #!/bin/bash
    2. #Iptables Regeln für VPN:
    3. sudo iptables -t filter -A OUTPUT -o eth0 -p udp -m multiport --dports 443,53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    4. sudo iptables -t filter -A INPUT -i wlan0 -p udp -m multiport --sports 443,53 -m state --state ESTABLISHED,RELATED -j ACCEPT
    5. sudo iptables -t filter -A INPUT -i eth0 -p udp -m multiport --sports 443,53 -m state --state ESTABLISHED,RELATED -j ACCEPT
    6. sudo iptables -t filter -A OUTPUT --dst 192.168.0.0/16 -j ACCEPT
    7. sudo iptables -t filter -A INPUT --src 192.168.0.0/16 -j ACCEPT
    8. sudo iptables -t filter -A OUTPUT --dst 10.0.0.0/8 -j ACCEPT
    9. sudo iptables -t filter -A INPUT --src 10.0.0.0/8 -j ACCEPT
    10. sudo iptables -t filter -A OUTPUT --dst 172.16.0.0/12 -j ACCEPT
    11. sudo iptables -t filter -A INPUT --src 172.16.0.0/12 -j ACCEPT
    12. sudo iptables -t filter -A OUTPUT -o wlan0 -j DROP
    13. sudo iptables -t filter -A INPUT -i wlan0 -j DROP
    14. sudo iptables -t filter -A OUTPUT -o eth0 -j DROP
    15. sudo iptables -t filter -A INPUT -i eth0 -j DROP
    Alles anzeigen
    immer noch unter Autostart (wie in Beitrag 1 beschrieben) steht, funktioniert es nach wie vor nicht.
    Also, das mit dem sudo vorangestellt scheint nicht die Lösung zu sein.

    Da fiele mir als Lösungsweg höchstens noch ein, mich dauerhaft als root anzumelden (habe aber noch nicht ausprobiert, ob das ginge), aber das ist natürlich auch nicht im Sinne des Erfinders!

    Für den Inhalt des Beitrages 123591 haftet ausdrücklich der jeweilige Autor: Neuer1

  • Neu

    Nimm das sudo aus dem Script.

    Wenn du ein Script als root mit su - (nicht sudo) ausführst, werden alle Befehle in dem Script als root ausgeführt.
    (sudo ist nicht root!!!!!!!)

    Ausserdem solltest du dir angewöhnen, alle im Script aufgerufenen Befehle incl. des kompletten Pfades anzugeben:
    Beispiel:

    Quellcode

    1. /usr/sbin/iptables -t filter -A OUTPUT -o eth0 -p udp -m multiport --dports 443,53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    Vermeidet langwieriges suchen nach Fehlern wegen Pfaden.....
    Hilft dir zwar jetzt nicht aber......


    Neuer1 schrieb:

    Leider sind mir deine Informations-Schnipsel etwas zu knapp.
    Dann sollte man die Finger von solchen Sachen lassen, die man nicht versteht, oder verstehst du den iptables Befehl?


    Übrigens:
    Angst und Geld hab ich nicht.......
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 123593 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Neu

    Mit sudo, so wie es in dem Skript steht, hatte ich es ja eben schon (erfolglos) versucht.

    Jetzt muss ich leider schon wieder dumm nachfragen, wie du das mit dem Pfad meinst ...
    Also der Pfad zu meinem Skript ist:

    Quellcode

    1. /home/keiner/vpn.sh

    Das sollte - am Beispiel der ersten Zeile - in meinem Skript dann aber nicht so aussehen:

    Quellcode

    1. /home/keiner/vpn.sh/iptables -t filter -A OUTPUT -o eth0 -p udp -m multiport --dports 443,53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    Oder?
    Sondern genauso, wie du es oben geschrieben hattest? (Weil die iptables dann letztlich im Ordner sbin liegen?)

    Für den Inhalt des Beitrages 123594 haftet ausdrücklich der jeweilige Autor: Neuer1

  • Neu

    Neuer1 schrieb:

    Sondern genauso, wie du es oben geschrieben hattest? (Weil die iptables dann letztlich im Ordner sbin liegen?)

    Ja.

    Aber noch einmal:
    Lass die Finger von Sachen, die du definitiv nicht verstehst.

    Mit iptables kann man sich wunderbar selbst aussperren.........
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

    Für den Inhalt des Beitrages 123595 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Neu

    Ein wirklich guter Rat: Lösche das Zeuchs sofort und endgültig!

    1. Ohne riesigen Linuxrettungsschwimmersein für Hochsee wirst du nolens, volens dein System unsicherer machen.
      Die Defaults der suseFirewall sind von Haus aus sehr restriktiv.
    2. Das eigentliche Angriffsziel ist dein DSL - Router, hinter dem du diese Kiste betreibst, was ich dir einfach mal unterstelle.
      Dein Netz fällt, nicht die openSUSE Kiste.
    3. Welchen VPN Provider hast du gewählt? Und wie kommst du zu der Annahme, der sei sicher?
      Ich behaupte, genau dort wirst du belauscht, verraten und verkauft.
      Solange du nicht selbst root des VPN Server bist, oder __WIRKLICH__ den root dort kennst und voll vertraust, ist das ein vorsätzliches Sicherheitsloch.
    4. Wenn du wirklich in iptables oder nftables rumfummeln willst, musst du erst das hier im Schlaf, betrunken, rückwärts unter Wasser beherrschen.
      iptables nennt sich die netfilter Familie, eine große Sammlung an Tools, die man als Gesamtheit "Firewall" nennt.
      nftables ist der moderne Nachfolger von iptables. Effektiver, schneller, mächtiger und noch mal komplizierter.
      firewalld ist ein Frontend zu nftables, das die Rules dynamisch (auch über Dbus gesteuert) ändern kann.
      Im Hintergrund der meisten Distris läuft heute sowieso schon nftables, was ja auch die Regeln von iptables aus Kompatabilitätsgründen einfach verwenden kann.
    5. Um diese Regeln ändern zu können, muss man root sein, oder root- Rechte haben. Also wäre für dein Script ein systemd Service/Unitfile zu schreiben. Und dort gibt es kein "autostart", nur Services. Es macht auch wenig Sinn, das Script als User zu starten. Das Netzwerk würde bis zum Einloggen ja ohne diese Pseudorestriktionen laufen. (Und dass du glaubst, es wäre sicher, weil nur du dich anmeldest, ist schon ein offenes Scheunentor in deiner Kiste). Falls du das doch machen möchtest, es gibt hier sogar Tutorials und jede Menge Threads dazu, wie man für ein Script ein Servicefile schreibt. LASS ES DENNOCH!!!


    Ich kapiere auch überhaupt nicht, was du dir da an Sicherheitsgewinn vorlügst. Für mich ist das ein vorsätzliches SIcherheitsloch mit Datenpollution zu __irgendwelchen__ Providern.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 123596 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Neu

    Nein, dass mit dem VPN ist soz. ein "must have". Wenn ich das nicht hinkriege, hat das ganze Thema Linux für mich keinen Sinn. Dann muss ich wohl doch irgendwann mit Windows 10 vorlieb nehmen! :(

    Damit so Sachen wie Aussperren oder so erst mal folgenlos sind, spiele ich das ja auch alles in der virtuellen Maschine durch.
    Wenn ich dann irgendwann quasi eine idiotensichere Prozedur entwickelt hätte und ausreichend durchgetestet, dann würde ich dazu übergehen, mir ein "echtes" System aufzubauen.
    Ich muss nur dieses eine Skript hinkriegen ... oder auch eine andere - für mich umsetzbare - Methode, so ein "Killswitch" zu realisieren.

    Es geht dabei nur darum ein IP-Leak auszuschließen. Es ist auch überhaupt nicht schlimm, wenn dieser IP-Leck-Schutz erst kurz nach dem bei mir wohlgemerkt automatischen Login greift. Es sollen nur ein paar Programme, die ich nachher manuell starte, abgesichert sein. Also, ob jetzt z.B. openSUSE selbst mit meiner echten IP auf den Update-Server zugreift oder nicht, spielt dabei keine Rolle.
    Mein Anbieter ist AirVPN.

    Alternativ bietet AirVPN auch so ein Einwahl-Tool namens "Eddie" an, welches auch über eine Killswitch-Funktion verfügt. Das Tool macht eigentlich auch einen guten Eindruck und funktioniert auch - bedingt: Wenn man es in openSUSE Leap 15 schließen will, friert es mehr oder weniger ein.
    Aber selbst wenn es 100% funktionieren würde (tut es unter anderen Linuxversionen) würde ich mich ungern allein auf so ein Tool verlassen wollen. Weil man ja sieht, dass da schnell mal was nicht mehr rund laufen kann, oder es könnte ja auch sein, dass es irgendwann AirVPN mal nicht mehr gibt oder das Tool einfach nicht mehr weiterentwickelt wird ...
    Außerdem weiß man ja auch nicht so genau, was das Tool macht, also lieber wär's mir schon, ich hätte eine selbst entwickelte (abgeschriebene!) Methode, die dann auf jeden Fall funktioniert.

    Andererseits will und kann ich für diese eine Sache auch nicht erst den - wie du es schön genannt hast - Linuxrettungsschwimmerschein für Hochsee machen.
    Ich mache mich aber auch noch mal auf die Suche, herauszufinden, was es mit dieser systemd-Service-Sache auf sich hat. Das müsste man dann halt auch unkompliziert kurzfristig abwählen können. Ich weiß nicht, ob in dem Fall dann ein

    Quellcode

    1. firewall-cmd --relaod
    reichen würde.
    Ich sehe aber meinen Traum, mich von Microsoft unabhängig zu machen, in einer Seifenblase davonschweben ...

    Und man kann diese Regeln nicht zufällig "einfach" in Rich-Rules ummünzen, die man dann in eine neu definierte Zone reinschreibt?
    So in der Art:

    Quellcode

    1. firewall-cmd --permanent --zone=killswitch --add-rich-rule ...

    Für den Inhalt des Beitrages 123597 haftet ausdrücklich der jeweilige Autor: Neuer1