Hi, ist es möglich unter Ubuntu 18.04 die Iptables dauerhaft zu speichern? Das Packet iptables-persistent gibt es ja nicht mehr.
Iptables für NAT VM dauerhaft Speichern
Anmeldungsdatum: Beiträge: 207 |
|
Ehemaliger
Anmeldungsdatum: Beiträge: 17448 |
Gibt es doch ▶ Link mfg Stefan |
(Themenstarter)
Anmeldungsdatum: Beiträge: 207 |
Interessant. Auf einer Installation lässt es sich installieren, auf einer anderen nicht. Kommt gar nicht zur Auswahl. |
Ehemalige
Anmeldungsdatum: Beiträge: 9490 Wohnort: Bochum |
Dann schau mal, ob da Universe in der sources.list aktiv ist. |
Anmeldungsdatum: Beiträge: 603 |
Warum nutzt Du nicht einfach das, was sowieso an Board ist und verwendest für diese Aufgabe eine Service-Unit? Wenn es sich nur um sehr wenige Regeln handelt, kann man die sogar direkt in die Unit eintragen: cat /etc/systemd/system/set-iptables.service [Unit] Description=set-iptables.service: Setting some open-wlan-accespoint-netfilter-rules [Service] Type=oneshot RemainAfterExit=no ExecStart=/sbin/iptables -F ExecStart=/sbin/iptables -P INPUT DROP ExecStart=/sbin/iptables -P OUTPUT DROP ExecStart=/sbin/iptables -P FORWARD DROP ExecStart=/sbin/iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ExecStart=/sbin/iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ExecStart=/sbin/iptables -A INPUT -i lo -j ACCEPT ExecStart=/sbin/iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset ExecStart=/sbin/iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable ExecStart=/sbin/iptables -A OUTPUT -p icmp -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -j REJECT --reject-with icmp-admin-prohibited [Install] WantedBy=multi-user.target Sind es viele Regeln, startet die Unit alternativ einfach ein Bash-Script, welches die Regeln setzt.Zusätzliche Software zu installieren ist jedenfalls nicht notwendig. |
Ehemaliger
Anmeldungsdatum: Beiträge: 17448 |
iptables-save/restore ist die intelligente Variante, man kann natürlich auch ein Shell Script oder Unit schreiben, was auch sehr zuverlässig dafür sorgen kann das mal was nicht klappt. mfg Stefan |
Anmeldungsdatum: Beiträge: 603 |
Das suggeriert die Botschaft, als wäre der zuverlässige "failed" bei Shell-Scripts die Regel. Woduch wird belegt, dass iptables-restore nicht nur eine intelligentere Lösung ist, sondern auch noch eine stabilere? Für solche Aussagen müsste es ja Beobachtungen oder Aussagen geben, die das untermauern. Warum diese kleine Service-Unit zu einem weniger guten Ergebnis kommen soll, leuchtet mir allein wegen der Behauptung erst mal nicht ein. Und im Ergebnis kann ich auch keinen Unterschied erkennen. |
Ehemaliger
Anmeldungsdatum: Beiträge: 17448 |
Ein Export von iptables, per iptables-save, enthält den kompletten Netfilter State. Dein Script trifft annahmen welche nicht immer zutreffen müssen. Desweiteren kann man iptables-save Exports per iptables-apply auch anwenden, was bei deinem Script ebenfalls nicht geht.
Man nutzt das richtige Tool für den richtigen Job, und versucht selbstgebaute Lösungen zu vermeiden. Gleichzeitig dauert es bei Script/Unit bases iptables eine gewisse Zeit bis die Regeln alle drin und aktiv sind, was bei iptables-restore deutlich schneller geht. Nur teilweise vorhandene Firewall Regeln führen in der Regel zu undefiniertem bzw. unerwartetem Verhalten. mfg Stefan |
Anmeldungsdatum: Beiträge: 603 |
Hallo Danke, dass Du versuchst meine Fragen zu beantworten. Und ganz selbstverständlich respektiere ich Deine Meinung, ohne Frage... nur mangels technisch belastbaren Inhalten sehe ich das allerdings wirklich nur als Meinung. Das ist aber kein Problem und vor allem ist es auch keine Diskussion wert. Trotzdem möchte ich aber noch kurz meinen Standpunkt darlegen.
Ja, richtig. Nach dem Start meiner Unit würde das beim Aufruf von iptables-save nicht anderes sein.
Äh, nein... zum einen ist es KEIN Script, sondern eine systemd-Service-Unit, die als initiale Handlung nach einem System-Start Paketfilter-Regeln setzt. Dazu wird natürlich das Frontend "/sbin/iptables" verwendet. Vor dem Hintergrund der initialen Handlung besteht aber kein Unterschied dazu, wenn (womit, wodurch, von wem auch immer) als initiale Handlung erstmalig Paketfilter-Regeln gesetzt werden. Das ist auf dieser Ebene IMMER gleichrangig zu sehen, zumal vermutlich dabei immer auch von allen das gleiche Frontend verwendet wird. Der einzige (technisch aber irrelevante) Unterschied ist, dass es aus unserer admin-fokussierten Betrachtungsweise mit der Service-Unit eine sich bei jedem Systemstart wiederholende initiale Handlung ist. Ich schätze das jedoch nicht als schlechter ein, als ein iptables-restore... und für die Netfilter-Kernel-Module besteht hier auch kein Unterschied... es werden einfach nur Regeln im Netfilter-Modul bei Verwendung der gleichen Schnittstelle gesetzt. Zum zweiten kann man hier wohl kaum davon sprechen, dass es auf einer Annahme basiert... allenfalls auf der Annahme, dass die Unit von systemd gestartet wird, wenn der Rechner gestartet wird. Diese Annahme scheint mir aber richtig zu sein, weil ich das gleiche ja bei iptables-restore annehmen würde (welches ebenfalls von systemd gestartet wird). Darüber hinaus setzt die Unit einfach nur ganz geradlinig ein paar bestimmte Regeln ... für den Zweck einer Anmeldung an einem offenen fremden WLAN. Und wenn überhaupt wäre eine weitere (hier ebenfalls irrelevante) Annahme, dass es sich als geeignet bei einer Anmeldung an einem fremden WLAN hält und auf grund minimaler Möglichkeiten einen radikalen Schutz gewährt. Deswegen irrelevant, weil der Inhalt der Unit überhaupt keine Lösung auf die Frage des Threads ist, sondern nur ein Hinweis auf Hilfe zur Selbsthilfe ist... denn das, was die Unit tut, hat ja nun überhaupt nichts mit der Fragestellung zu tun. Der Hinweis ist: mit systemd-Units kann man das lösen... aber natürlich nicht mit dem explizit vorbestimmten Inhalt dieser Unit.
Eigentlich wäre es hilfreich, wenn Du den Unterschied zwischen Script und Service-Unit beachten würdest. Mein Beispiel von oben ist KEIN Script und erhebt auch nicht den Anspruch ein Script zu sein. Die tatsächliche Botschaft dieser Unit ist "Wenn es sich nur um eine Handvoll Regeln handelt, kann man das nicht einfacher und nicht mit geringerem Aufwand als mit einer Service-Unit lösen." Und genau diese Feststellung ist der dem Anspruch "intelligente Lösung" gerecht werdende Teil.
Nun, ich persönlich halte iptables-save/restore für eine starre und unflexible Lösung, aus einer Zeit starrer und unflexibler Ansprüche stammend, und ich betrachte es als "das richtige Tool" resp. intelligente Lösung NUR bei der Notwendigkeit einer starren und unflexiblen Rechner-Installation. Bei einer modernen Desktop-Installation, mit der den DUAL-Stack begleitenden täglichen Zwangstrennung und bei Verwendung des besseren TCP/IP-Protokolls mit IPV6, wo sich also auf dem Rechner öffentliche IP-Adressen mit Global Scope (GUA) mit täglich geänderter Site-ID tummeln, betrachte ich iptables-save/restore als diametral gegenüber dem Anspruch "intelligente Lösung" positioniert. Genauso wie ich an gleicher Stelle den Ratschlag positioniert sehen würde, IPV6 zu deaktivieren... wenn ich das lese (IPv6 abschalten) fällt mir immer der Spruch ein "dümmer geht immer" *fg* Ein generisch erzeugter Paketfilter, der auf tägliche (zeitlich unbestimmbare) Änderungen der Site-ID im IPV6-Stack flexibel reagieren muss, ist mit einer überalteten Lösung wie iptables-save/restore nach meinem jetzigen Kenntnisstand kaum zu realisieren. Wenn das trotzdem geht, lerne ich allerdings gerne dazu. Wenn man natürlich den Anspruch reduziert und mit einer halben Lösung zufrieden ist, kann natürlich auch eine solche starre/unflexible Lösung eine intelligente Lösung sein. Aber wie ich schon sage, wir vertreten unterschiedlichen Standpunkt und Meinung... das muss man nicht diskutieren, ich respektiere Deine Meinung... nur teile ich sie momentan aus technischen Gründen überhaupt nicht. |
Ehemaliger
Anmeldungsdatum: Beiträge: 17448 |
Das ist ein Trugschluss. Dein gebastel ignoriert komplett die NAT und Mangle Tables von iptables, fliegt also sehr zuverlässig auf die Fresse wenn damit rumgespielt wurde. Die Standardtable mit der iptables arbeitet ist die Filter Table, welche nur für einen Bruchteil der Funktionen relevant ist. Script/Unit ist kleinkrams, denn du führst ohne den State zu prüfen mehrere iptables Befehle hintereinander aus. Gleichzeitig stoppt das Unit auch wenn ein Befehl in der Mitte der Kette auf die Nase fliegt. Beispiel gefällig? Gerne:
Dein Script/Unit ist eines der typischen 0815-iptables Lösungen die man im Internet findet, und welche schon viele Anwender ausgesperrt hat. Ich hab die letzten Jahren sehr viel Zeit damit gebracht Firewalls zu fixen/optimieren, und das Resultat daraus: iptables-save/restore/apply sind dein Freund, lassen sich komfortabel per Texteditor anpassen und stellen immer einen stabilen State her. Um beim Thema zu bleiben (wo wir übrigens noch sind): iptables-save speichert den Status deiner iptables Regeln zuverlässig, dafür gibt es ein Paket in den Paketquellen. Auf deine weiteren Anmerkungen werde ich nicht eingehen, das hat nichts mit dem Thema zu tun. Du kannst gerne einen neuen Thread aufmachen wenn du derartige Grundlagen ausdiskutieren möchtest. mfg Stefan |
Anmeldungsdatum: Beiträge: 603 |
Äh, Du solltest Dich also schon mit meinen Aussagen befassen und nicht irgendwas völlig abwegiges konstruieren. Ich habe gesagt: "Wenn es sich nur um eine Handvoll Regeln handelt, kann man das nicht einfacher und nicht mit geringerem Aufwand als mit einer Service-Unit lösen." Und da wir ja hier vom Systemstart reden, sind NAT und Mangle bei dem Hintergrund natürlich vorher leer, und nach meiner Unit sind sie das immer noch. Und wenn Du jetzt allerdings im Kopf hast, dass ein Admin mit verschiedenen Werkzeugen zu verschiedenen Zeiten unterschiedliche Regeln setzt, dann ist das in meiner Realität eine grobe Stümperei... einem solchen Admin würde ich allenfalls einen Staubsauger anvertrauen.
Ja und? Was hat das mit meiner oben zitieren Aussage zu tun und der Tatsache, dass keine weiteren Regeln gesetzt werden...?... ich sagte ja "Handvoll".
Weil Du wiederholt ignorierst, dass der Inhalt des Scripts nicht die Lösung ist, sondern der Hinweis eine Service-Unit zu verwenden. Vielleicht hätte es dir besser gefallen, wenn ich stattdessen execstart echo "hier regel1" usw. geschrieben hätte.
Nach dem Systemstart gibt es keine Established-Verbindungen im Conntrack-State... da ist jede Verbindung eine neue und man kommt immer auch remote aufs System. Ich weiss jetzt nicht, ob iptables-save auch solche States sichern würde... keine Ahnung, ich glaube, du hast das erwähnt. Das wäre für mich allerdings das absolute KO-Kriterium, und ich würde das allein aus diesem Grund nie einsetzen.
Die Service-Unit startet nach einem Systemstart und setzt regeln. Was hat ein Kernel-Update aus der vorherigen Bootsession jetzt damit zu tun? Ich sag das jetzt noch mal... Du verbeisst Dich in den Inhalt... die Frage lautet aber "dauerhaft speichern"... der Inhalt der Unit hat mit der Frage nichts zu tun. Meine Antwort auf die Frage war, bei einer Handvoll Regeln geht das mit einer Service-Unit (in der als Beispiel nur irgendwas drin steht). Verstehst Du das?
Du befasst Dich eigentlich nur mit etwas, was NICHTS mit der Frage zu tun hat.... nämlich mit dem Inhalt meiner Unit, dabei war die Unit an sich meine Antwort, und nicht deren Inhalt. Und auch meine weiteren Anmerkungen sind genau auf das Thema bezogen, warum ich iptables-save/restore bei Beantwortung der Thread-Frage durchaus auch als ungeeignet erachte. Ich bitte Dich, etwas aufmerksamer zu lesen, was ich schreibe und nicht irgendwas hinzu zu erfinden. |
Ehemaliger
Anmeldungsdatum: Beiträge: 17448 |
Du gehst wie gesagt von Annahmen aus, diese müssen nicht erfüllt sein. Der TE kann z.B. noch was versehentlich im ufw haben, mal mit Firewall Builder rumgespielt haben oder neulich ein Experiment mit firewalld gewagt haben.
Der TE hat nicht behauptet Erfahrender Admin zu sein, weshalb er wohl auch seine Frage gestellt hat.
Ein Service Unit fliegt auch auf die Nase wenn einer der ExecStart Jobs auf die Nase fällt. Ich weiße darauf hin das ein Unit/Script Probleme machen kann. Aber gut, lassen wir das Thema. mfg Stefan |
Anmeldungsdatum: Beiträge: 603 |
Nein, tue ich nicht, ich habe nur eine Frage beantwortet. Wenn er sich gegenseitig beeinflussende Dinge tut, dann ist das seine Veranwortung. Eine solche Sichtweise kannst Du fortführen, bis hin zum Infragestellen von Maßnahmen wegen möglichem Meteoriten-Einschlag genau auf seinen Rechner... das ist einfach nur absurd.
Meine Antwort hatte zu keiner Zeit die Absicht, ihn vor sich selber zu schützen, sondern ihm einen einfachen Weg für seine Frage bei einer Handvoll Regeln aufzuzeigen. Beispielsweise reicht so eine Unit völlig aus, wenns NUR um diese paar OpenVPN-Regeln gehen würde. Und es gibt viele Szenarien, für die eine Service-Unit völlig ausreichend ist.
Das passiert doch nur bei Syntaxfehlern oder unerfüllten Abhängigkeiten. Beides kann man aber doch bei diesem technisch wirklich amrseligen Hintergrund ziemlich sicher ausschließen... oder unterstellst Du, dass das Frontend beim Bedienen des Kernel-APIs vom Kernel abgewatscht wird, auch wenn keine Syntaxfehler vorliegen...?... wenn ja, wie ich sagte, Meteoriten. BTW, das der Drop als erstes steht, ist nur ein zufälliger Umstand, weil ich die Unit hier manuell und ohne groß über den Inhalt nachzudenken zusammengeschustert habe... ich hatte nämlich nie den Gedanken, dass es um den Inhalt gehen könnte. Ich korrigiere es aber hier gerne, für die, die später drüber stolpern... uns ich weise darauf hin,dass es sich um eine exklusive Lösung handelt, was bedeutet, dass man sich keine Konfliktsituationen schaffen darf.... mit zusätzlichem manuellem Gefummel oder durch Verwendung von einer oder mehreren weiteren Anwendungen, die ebenfalls den Paketfilter verändern. (gut so?). Wobei ich eigentlich immer noch der Meinung bin, dass das völlig irrelevant ist, wenn ich mit dem Laptop bei McCafe sitze oder irgendeinen sonstigen unbekannten AP verwende... und genau da ist der Einsatzzweck dieser wenigen Regeln... möglichst alles verbieten... nur das erlauben, was man zum Surfen braucht. cat /etc/systemd/system/set-iptables.service [Unit] Description=set-iptables.service: Setting some open-wlan-accespoint-netfilter-rules [Service] Type=oneshot RemainAfterExit=no ExecStart=/sbin/iptables -F ExecStart=/sbin/iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ExecStart=/sbin/iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ExecStart=/sbin/iptables -A INPUT -i lo -j ACCEPT ExecStart=/sbin/iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset ExecStart=/sbin/iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable ExecStart=/sbin/iptables -A OUTPUT -p icmp -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT ExecStart=/sbin/iptables -A OUTPUT -j REJECT --reject-with icmp-admin-prohibited ExecStart=/sbin/iptables -P INPUT DROP ExecStart=/sbin/iptables -P OUTPUT DROP ExecStart=/sbin/iptables -P FORWARD DROP [Install] WantedBy=multi-user.target |