[gelöst] nftables temporär ausgehende Verbindung zulassen

[joe2017]

Hallo zusammen,

ich teste aktuell nftables und hätte eine Frage diesbezüglich.
Angenommen ich habe in einer Table "filter" eine ausgehende Regel für eine Lokale Subnetz Adresse (tcp dport 443 ip daddr 192.168.0.1 accept) und möchte temporär eine zweite Table mit der selben Regen für ausgehenden Internetverkehr zulassen. Wie genau stelle ich das an? Egal was ich mache, ich erhalte keinen Zugriff.

Beispiel (interner DNS Server 192.168.1.254):

Code: Alles auswählen

table ip filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state related, established accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
    chain output {
    type filter hook output priority 0; policy drop;
    ct state related, established accept
    udp dport 53 ip daddr 192.168.0.254 accept
    tcp dport 443 ip daddr 192.168.0.1 accept
  }
}

Jetzt möchte ich temporär den Zugriff ins Internet erlauben.
Ich dachte, dass ich mir hierzu einfach eine neue temporäre Table anlege und diese anschließend wieder lösche.

Code: Alles auswählen

table ip test {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state related, established accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
    chain output {
    type filter hook output priority 0; policy drop;
    ct state related, established accept
    udp dport 53 ip daddr 192.168.0.254 accept
    tcp dport 443 accept
  }
}

ich habe auch schon die priority auf -100 oder 100 gestellt. Leider ändert das nichts. Oder mach ich hier einen Denkfehler?

[TomL]

Das ist kein guter Lösungsansatz. Zum einen braucht es dafür keine 2 Tables, das kann man alles im Table "filter" unterbringen. Das zweite ist, wenn es um einen konkreten Client geht, dem z.B. der Zugang zum Internet verboten sein soll, würde ich das eher über den DSL-Router tun.

Das nächste ist, es ist zwar möglich, die Policies pauschal auf Drop zu stellen, aber damit wird der Client-PC nicht mehr ordentlich im Netzwerk funktionieren. Das System braucht DNS, RA, NDP, NTP, ICMP, *Cast, wasweissich... also haufenweise Ports und Protokolle, um zu funktionieren, was mit solcher Einstellung also nicht mehr möglich ist. Wäre IPv6 im Spiel, wäre IPv6 geradezu getötet.

Das vierte ist, eine explizite lokale Adresse im Filter zu verwenden, hat m.M.n. nur eine fragwürdige Sicherheit. Ich würde also, wenn überhaupt, mich nur auf das Subnetz beziehen, was aber hier für den beabsichtigten Zweck wiederum nicht sinnvoll ist.

Eine einzelne Regel speziell um Internet zu erlauben sieht so aus:

Code: Alles auswählen

nft add rule ip tfilter output tcp dport    80 ip daddr != 192.168.0.0/16 accept
nft add rule ip tfilter output tcp dport   443 ip daddr != 192.168.0.0/16 accept

Damit ist aber wiederum nicht geregelt, dass Anwendungen nicht willkürlich andere unprivilegierte Ports für eine Verbindung ins Internet nutzen können. Also wie gesagt, so funktioniert das am Ende nicht wirklich sicher und auch nicht zufriedenstellend. Außerdem ist die Wirksamkeit solcher Regeln maßgeblich von anderen Aspekten abhängig, deren Relevanz und Beachtung zuerst sichergestellt sein muss.

[joe2017]

Hallo und danke für deine Tipps,

das ich in meinem Netzwerk mehrere Dienste für meinen Clients benötige ist mir durchaus klar.
Da mir diese Informationen vorliegen, ist das jedoch kein Problem. Das ist jedoch wieder ein ganz anderes Thema.

Das mit der zweiten Table war auch nur so eine Idee.
Wenn mein Client z.b. einen Web Zugang (443,80) zum lokalen Subnetz hat, könnte dieser keine Updates aus dem Internet herunterladen.
Hierfür würde ich teporär eine zweite Table anlegen, meine Updates herunterladen und installieren und anschließend die Table wieder löschen.

Ich dachte mir, dass dies die sauberste Lösung ist. Jedoch hab ich Probleme die Freigabe für das Internet einzurichten, da ich diese Ports zuvor nur für eine IP/Subnetz freigegeben habe.

[TomL]

Hierfür würde ich teporär eine zweite Table anlegen, meine Updates herunterladen und installieren und anschließend die Table wieder löschen.

Kann man machen, halte ich aber nicht für sinnvoll. Ich deaktiviere für den Moment des Dist-Upgrade kurzerhand mit einem Flush alle Regeln und starte danach das System neu durch... was auf meinem Server also nicht täglich stattfindet. Nach dem Reboot werden die Regeln automatisch neu gesetzt. Wenn man das System nicht rebootet, muss man nur die vom Upgrade betroffenen Dienste prüfen, ggf. restarten und danach den Filter neu starten. Eine zweite Regel brauchts dafür jeden falls nicht.

[joe2017]

Ja so könnte ich das auch erledigen. Jedoch wäre in deinem Fall dann jeglicher Verkehr eingehend/ausgehnd offen was sicherheitstechnisch eine Katastrophe ist.

Wenn ich meine Clients jedoch mittels cronjob mehrmals am Tag nach neuen Updates suchen lassen, muss ich hierfür mittels Script den ausgehenden Verkehr für diesen Moment genehmigen.
Daher mein Ansatz mit der zusätzlichen Table. Das ist meiner Meinung nach der sauberste Weg.

Jetzt ist nur die Frage, wie ich eine Regel, die in Konflikt mit einer anderen Regel steht erzwinge.
Wenn du mir hierfür eine Antwort hättest wäre ich dir super dankbar.

[TomL]

Ja so könnte ich das auch erledigen. Jedoch wäre in deinem Fall dann jeglicher Verkehr eingehend/ausgehnd offen was sicherheitstechnisch eine Katastrophe ist.

Nein, ist es meiner Meinung nach überhaupt nicht, am allerwenigsten ist das sicherheitstechnisch eine Katastrophe... und schon mal gar nicht, wenn die laufenden Dienste hinsichtlich der Zugänge ordentlich konfiguriert sind. Für die laufenden Dienste ist es nämlich völlig unerheblich, ob der ankommende legale Traffic durch einen Paketfilter erlaubt oder ohne Paketfilter ungeregelt ist. Das Ergebnis ist das gleiche. Ohne Paketfilter gehen die gleichen legalen Pakete durch, wie sonst mit erlaubnis durch den Paketfilter. Und Pakete, für die kein Dienst lauscht, werden eh verworfen. Und wenn keine unnötigen Dienste "lauschen", hat die Abschaltung des Paketfilters lediglich die Auswirkung, dass in dem kurzen Moment des Upgrades ein Flooding nicht gehandhabt werden würde.... was aber schon wieder fragwürdig ist, weil vermutlich nicht jemand da sitzt und genauf auf die Abschaltung des Paketfilters wartet. Außerdem kann man solche Attacken protokollieren (siehe unten), dann sieht man, was in den Tagen zuvor passiert ist und ob das überhaupt ein Problem ist. Abgesehen davon würde ich, wenn ich nach dem Dist-Upgrade kein Reboot durchführen wollte, wenigstens vor dem Upgrade die Dienste stoppen und anschließend neu starten. Und wenn die Dienste gestoppt sind, hat der abgeschaltete Paketfilter sowieso keine negativen Auswirkungen. Und wenn das tatsächlich für ausgehenden Traffic eine sicherheitskatastrophe bedeutet würde, dann muss man also davon ausgehen, dass das System anscheinend kompromittiert ist... in dem Fall empfehle ich sowieso eine umgehende Neuinstallation.

Wenn ich meine Clients jedoch mittels cronjob mehrmals am Tag nach neuen Updates suchen lassen,

Kannst Du eine Quelle benennen, die ein solches Vorgehen empfiehlt? Ich persönlich halte so etwas jedenfalls nicht nur für unnötig, sondern durchaus auch für schlechtes Handling. Das ist aber nur meine persönliche Meinung und dazu wäre es interessant, was die "echten" Admins hier zu solcher Praxis sagen. Ich bin ja gerne bereit, auch dazuzulernen.

Daher mein Ansatz mit der zusätzlichen Table. Das ist meiner Meinung nach der sauberste Weg.

Nein, ist es nicht, sondern der ungünstigste, weil Du damit unnötig die Möglichkeit beseitigst, auf die serielle Abarbeitung der Regeln Einfluss zu nehmen. Und genau da liegt die Lösung.

Jetzt ist nur die Frage, wie ich eine Regel, die in Konflikt mit einer anderen Regel steht erzwinge.

Die Antwort ist ja nun wirklich einfach: Eine erlaubende Regel VOR der verbietenden Regel einfügen und hinterher wieder löschen.
Dafür gibt es statt nft add rule die Kommandos nft insert rule und nft delete rule. Bei diesen Kommandos kann man die Position angeben.

Edit:
Ich bekomme jeden Morgen eine Mail, die mich darüber informiert, wer mich alles unerlaubt besucht hat. Daran erkenne ich auch, wann und wo der Paketfilter eingreift und worauf er keinen Einfluss hat.

Code: Alles auswählen

Netfilter Blacklisted:
ip saddr 71.6.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 84.95.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 139.162.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 184.105.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 185.53.0.0/16 counter packets 1 bytes 44 goto blacklisted
ip saddr 191.96.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 191.101.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 198.108.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 208.93.0.0/16 counter packets 0 bytes 0 goto blacklisted
ip saddr 216.218.0.0/16 counter packets 0 bytes 0 goto blacklisted

Journal accumulation blacklisted IPs with connection attempts at last few days:
139.162.125.159
139.162.125.159
139.162.125.159
139.162.125.99
139.162.200.87
184.105.139.68
184.105.139.76
185.53.88.48
185.53.88.48
185.53.88.48
185.53.88.48
185.53.88.48
185.53.88.82
185.53.91.39
198.108.66.111
198.108.66.182
198.108.66.67
208.93.152.20
208.93.152.20
208.93.152.20
216.218.206.74

Journal accumulation temporarily banned IPs with connection attempts at last few days:
115.238.188.210
115.238.188.210
115.238.188.210

Journal last 24h:
Feb 22 00:39:38 server kernel: Blacklisted IP: IN=eno1 SRC=139.162.125.159 
Feb 22 03:21:36 server kernel: Blacklisted IP: IN=eno1 SRC=198.108.66.111 
Feb 22 11:06:21 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.48 


Journal summary at last few days:
Feb 18 08:02:39 server kernel: Blacklisted IP: IN=eno1 SRC=139.162.125.159 
Feb 18 18:36:22 server kernel: Blacklisted IP: IN=eno1 SRC=184.105.139.76 
Feb 18 23:11:13 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.91.39 
Feb 19 02:37:58 server kernel: Blacklisted IP: IN=eno1 SRC=139.162.125.99 
Feb 19 03:29:32 server kernel: Blacklisted IP: IN=eno1 SRC=208.93.152.20 
Feb 19 05:24:20 server kernel: Blacklisted IP: IN=eno1 SRC=139.162.200.87 
Feb 19 07:21:54 server kernel: Blacklisted IP: IN=eno1 SRC=198.108.66.67 
Feb 19 11:31:22 server kernel: Blacklisted IP: IN=eno1 SRC=208.93.152.20 
Feb 19 13:17:11 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.48 
Feb 19 13:38:17 server kernel: Blacklisted IP: IN=eno1 SRC=139.162.125.159 
Feb 19 17:44:41 server kernel: Blacklisted IP: IN=eno1 SRC=216.218.206.74 
Feb 19 22:40:42 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.48 
Feb 19 23:15:00 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.82 
Feb 20 07:33:32 server kernel: Blacklisted IP: IN=eno1 SRC=198.108.66.182 
Feb 20 10:36:27 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.48 
Feb 20 17:15:39 server kernel: Blacklisted IP: IN=eno1 SRC=184.105.139.68 
Feb 20 17:33:41 server kernel: Temp.banned IP: IN=eno1 SRC=115.238.188.210 
Feb 20 17:33:43 server kernel: Temp.banned IP: IN=eno1 SRC=115.238.188.210 
Feb 20 17:33:47 server kernel: Temp.banned IP: IN=eno1 SRC=115.238.188.210 
Feb 20 17:48:16 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.48 
Feb 21 16:59:08 server kernel: Blacklisted IP: IN=eno1 SRC=208.93.152.20 
Feb 22 00:39:38 server kernel: Blacklisted IP: IN=eno1 SRC=139.162.125.159 
Feb 22 03:21:36 server kernel: Blacklisted IP: IN=eno1 SRC=198.108.66.111 
Feb 22 11:06:21 server kernel: Blacklisted IP: IN=eno1 SRC=185.53.88.48 


Connection attempts today:
46.17.46.87                     22. Feb. 2019   Fri  14:50:51
46.17.46.87                     22. Feb. 2019   Fri  15:26:00
46.17.46.87                     22. Feb. 2019   Fri  16:01:26
46.17.46.87                     22. Feb. 2019   Fri  16:36:22
93.113.124.199                  22. Feb. 2019   Fri  13:38:48
110.101.249.171                 22. Feb. 2019   Fri  14:10:41
176.130.23.5                    22. Feb. 2019   Fri  12:48:13
196.52.43.122                   22. Feb. 2019   Fri  04:01:49

Connection attempts summary last few days:
18.234.218.87                   21. Feb. 2019   Thu  03:53:30
46.17.46.87                     22. Feb. 2019   Fri  14:50:51
46.17.46.87                     22. Feb. 2019   Fri  15:26:00
46.17.46.87                     22. Feb. 2019   Fri  16:01:26
46.17.46.87                     22. Feb. 2019   Fri  16:36:22
46.29.167.33                    17. Feb. 2019   Sun  01:10:20
46.29.167.33                    17. Feb. 2019   Sun  01:46:20
46.29.167.33                    17. Feb. 2019   Sun  02:24:04
74.82.47.2                      21. Feb. 2019   Thu  18:52:57
93.113.124.199                  17. Feb. 2019   Sun  06:56:16
93.113.124.199                  21. Feb. 2019   Thu  17:30:54
93.113.124.199                  22. Feb. 2019   Fri  13:38:48
104.131.145.116                 20. Feb. 2019   Wed  06:14:48
104.131.146.58                  17. Feb. 2019   Sun  06:01:01
104.248.38.79                   18. Feb. 2019   Mon  17:29:50
109.30.212.228                  20. Feb. 2019   Wed  23:40:22
110.101.249.171                 22. Feb. 2019   Fri  14:10:41
123.77.148.249                  21. Feb. 2019   Thu  16:30:37
123.77.223.113                  17. Feb. 2019   Sun  09:21:13
173.255.217.203                 19. Feb. 2019   Tue  22:30:31
176.130.23.5                    22. Feb. 2019   Fri  12:48:13
176.32.33.80                    20. Feb. 2019   Wed  03:01:14
176.32.33.80                    20. Feb. 2019   Wed  03:18:59
176.32.33.80                    20. Feb. 2019   Wed  03:36:31
178.73.215.171                  20. Feb. 2019   Wed  17:04:57
181.48.9.82                     18. Feb. 2019   Mon  01:22:08
196.52.43.122                   22. Feb. 2019   Fri  04:01:49

Connections accept summary at last few days:

[joe2017]

Schönen guten Morgen.

Deiner Meinung nach wäre es nicht unsicher, das gesamte Filtering abzuschalten. Du gehst einfach mal davon aus, dass dein Linux sauber ist. Wenn jedoch durch deine Unwissenheit etwas auf deinem Client oder Server lauscht, wäre deine Methode durchaus unsicher. Aber darüber kann man sich natürlich streiten. Ich versuche einfach dieses Risiko zu vermeiden.

Ich finde es keinen Fehler vorhandene Updates so früh als möglich einzuspielen. Daher ist es sicherlich nicht verkehrt mehrmals am Tag nach neuen Updates zu suchen.

Aber die obigen beiden Themen haben auch nichts mit meiner Frage zu tun. Meine Frage ist ganz simpel. Kann man eine zweite Table anlegen, welche eine zuvor verbotene bzw. eingeschränkte Regel zulässt.

Das mit dem nft insert rule kenne ich natürlich. Jedoch dachte ich, dass es sauberer wäre hierfür eine neu Table anzulegen und diese anschließend wieder zu löschen. Somit kann bei dem anlegen und löschen ganz sicher nichts schief gehen. Das möchte ich einfach verhindern. Wenn dies jedoch technisch nicht funktioniert muss ich auf deine vorgeschlagene Lösung zurückgreifen.

Was vielleicht auch helfen könnte, wäre eine Regel welche lediglich für den Update Service geöffnet wird.
Somit könnte ich auch eine Regel einschränken und nur für den Browser (Bsp. Firefox) das Lokale Subnetz öffnen.

Mich würde jedoch auch sehr interessieren wie du das mit der Mail gelöst hast. Wie sammelst du diese Informationen?
Ich freue mich immer über solche innovative Lösungen.

[joe2017]

Keiner eine Idee wie ich das Ganze sauber mit tables abbilden könnte?

[novalix]

Ich gehe mal davon aus, dass Du Dein ruleset über eine (od. mehrere verlinkte) Konfigurationsdatei(en) startest.
Da sollten üblicherweise solche Zeilen obenan stehen:

Code: Alles auswählen

#!/usr/sbin/nft -f

flush ruleset

Wenn Du jetzt eine zweite Konfiguration mit einer solchen Anweisung für Deine temporären Zwecke anlegst, die über ein script aber nicht beim Systemstart geladen wird, könntest Du das per pre-hook zu Deiner Aktion starten.
Dann brauchst Du noch einen post-hook, der das default ruleset wieder lädt.
Vereinfachtes Muster:

Code: Alles auswählen

script-zum-flushen-des-standard-und-laden-des-temporären-ruleset.sh && DeineAktion && systemctl --mecker-woanders restart ruleset.service

[TomL]

Wenn jedoch durch deine Unwissenheit etwas auf deinem Client oder Server lauscht, wäre deine Methode durchaus unsicher.

Nein, wäre sie nicht... weil solche von Dir gedachten Prozesse -man bezeichnet sie ganz allgemein als Malware- gar nicht lauschen, die öffnen einfach nach Lust und Laune eine Verbindung von innen nach außen auf einem beliebigen unprivilegierten Port, was meistens immer erlaubt ist. Die lauschen nicht, weil das vermutlich viel zu auffällig ist und mit netstat quasi sofort entdeckt werden kann. Und selbst wenn Du alle Ports von 1024-65535 für ausgehende Pakete gesperrt hast, nehmen sie einfach Port 80 oder Port 443. Und auch dann, wenn Du komplett alle Ports sperren würdest, was den PC als LAN-Client geradezu unbrauchbar macht, nehmen sie bei nächster Gelegenheit einfach deinen Root-Account, in dem sie "sudo" abgreifen und richten sich eine eigene Freigabe ein. Und das geht alles mit einfachen Bash-Befehlen.

Aber was diese Malware angeht... dazu hatte ich ja schon gesagt, wenn der Verdacht besteht, solltest Du das nicht über den Paketfilter lösen, sondern diese Schadsoftware entfernen ... schlimmstenfalls eben durch eine Neuinstallation. Malware auf dem Rechner zu belassen und irgendwas stümperhaft drumrumzubauen ist definitiv die schlechteste Lösung. Und sich dabei allein auf den Paketfilter zu verlassen, ist ganz sicher nicht als sachkundig zu bezeichnen.

[joe2017]

Schönen guten Morgen und danke für die Aufklärung. Das war allerdings nicht notwendig, und ich weiß auch nicht warum du deine Vorgehensweise auf Brechen heraus verteidigen möchtest.
Ich habe diese nicht in Frage gestellt und wollte dir nur einen Tipp geben weshalb ich diese nicht als ganz so Sicher sehe. Einfach für den Update Prozess alles abschalten scheint mir der schlechteste Weg zu sein. Aber gut, das ist eben deine Vorgehensweise und du wirst schon noch weitere Maßnahmen getroffen haben.

Und das einfach ein root Zugang verwendet wird und mit einfachen Scrips alles Mögliche angestellt wird, ist dann auch nicht ganz so einfach. Hierzu benötigt dieser erst einmal root Rechte.
Davon, dass ich mein System so weiter laufen lassen möchte, war auch nie die Rede! Gerade so etwas möchte ich vermeiden weshalb ich meine Ports einschränke und diese nur für einen bestimmten Zweck öffne. Das ich mich nur auf meine Paketfilter verlasse habe ich auch nicht behauptet und ich weiß auch nicht wo du dir das jetzt her ziehst?

Ich frage mich auch wie du auf die Idee kommst, dass dies meine LAN-Clients unbrauchbar machen könnten. Wo du doch über keinerlei Wissen meiner internen Anforderungen verfügst.

Ich wollte mich jetzt auch nicht darüber streiten was richtig oder falsch ist, und ich möchte dir sicherlich nicht vorschreiben wie du dein System einrichten sollst. Ich denke hier gibt es jede Menge verschiedene Ansätze und jeder wird den passenden für sich gewählt haben.

Ich habe lediglich nach etwas gefragt worauf ich bis jetzt keine Antwort bekommen habe. Eine zweite Table mit Rules anlegen welche die erst übersteuert.

Ich freue mich immer dazuzulernen und versuche hier auch immer etwas zurück zu geben. Ich habe hier diverse komplizierte Themen bearbeitet und einige davon auch gemeinsam mit euch allen lösen können. Darüber bin ich sehr Dankbar und versuche in jeder meiner Frage eine Lösung am Ende bereitzustellen. Das ist mein Beitrag den ich hier leisten kann. Ich denke, dass sich bestimmt auch schon einige Anwender darüber gefreut haben.

Es geht doch hier nicht darum wer Recht hat oder wer mehr über ein Thema weiß. Wenn es jeder Besser weiß, bräuchten wir ein solches Forum nicht. Und wenn man mal keine passende Antwort hat, ist doch auch nicht schlimm. Es ist keine Schande zu sagen Tut mir leid, aber hier bin ich überfragt. Ich freue mich einfach, dass wir eine solche Plattform haben und jeder etwas nehmen und geben kann. Der eine mehr, der andere eben etwas weniger. In der heutigen Zeit haben wir alle Stress genug, den brauchen wir doch dann hier nicht auch noch.

Trotzdem Danke für deine Sichtweise. Vielleicht hab ich auch etwas übersehen oder nicht bedacht. ich werde noch einmal darüber nachdenken.

Vielleicht hat trotzdem jemand eine Antwort auf die Frage.

Wie kann man mit einer zweiten Table eine vorherige übersteuern.

[TomL]

...ich weiß auch nicht warum du deine Vorgehensweise auf Brechen heraus verteidigen möchtest.
:::
Ich wollte mich jetzt auch nicht darüber streiten was richtig oder falsch ist,
:::
Es geht doch hier nicht darum wer Recht hat

Nun, dann hast du das so missverstanden, wie man das nur missverstehen kann. Sei dir gewiss, ich streite nicht, ich will kein Recht haben, es interessiert mich gelinde gesagt auch nicht, was du tust.

Nur ist es eben so, dass hier auch viele Nichtprofis mitlesen, und ich denke, dass man deshalb auf technische falschdeutungen durchaus auch hinweisen sollte. Und weil mir die Leute hier im Forum, die tatsächlich über Fachwissen verfügen, nicht vehement widersprechen (was sie dankenswerterweise eigentlich immer sofort tun, wenn ich Mist erzähle), denke ich, dass ich so falsch nicht liegen kann. Ich glaube, dass dieses Forum sich nicht dem Niveau eines grünen Windows-Umsteiger-Forums anpassen und lieber auf dem bisherigen deutlich höheren Niveau verbleiben sollte. Und daraus resultiert imho auch die Notwendigkeit einer angemessenne Vorgehensweise. Was du machst, sehe ich bei solcherart Ansprüchen fast als Placebo-Sicherheit. Wenn man es wirklich sicher haben will , verwendet man eine Firewall zwischen drinnen und draußen.... und nicht einen Paketfilter, der hier im Speziellen nur eine zufällige Sicherheit erreicht.

Wie kann man mit einer zweiten Table eine vorherige übersteuern.

Novalix' Antwort nicht als Antwort zu erkennen interpretiere ich als Fundament der zufälligen Sicherheit.

Ich denke , ich tue Dir einen Gefallen , wenn ich mich jetzt hier raushalte. Dann wird das schon klappen, mit der zweiten Tabelle.

[joe2017]

Die Antwort von Novalix habe ich tatsächlich nicht gesehen.

Und nochmal... Ich hab nie behauptet, dass ich nur eine Client Firewall verwende. Das ist nur eine zusätzlich Sicherheit auf meinem Client. Diese möchte ich einfach so streng wie möglich behandeln.
Daher habe ich auch ein default Block und öffne lediglich meine benötigten Ports. Da meine Clients lediglich im lokalen Subnetz den Port 80/443 benötigen, ist dieser auch nur auf dieses Netz beschränkt.
Jedoch muss ich Updates auf den Clients installieren. Somit muss ich auch die beiden Ports für diesen Zweck temporär öffnen.

Ich dachte eben, dass ich hierfür einfach temporär eine zusätzliche Table anlege und diese anschließend wieder lösche. Anscheinend ist das nicht so ohne weiteres möglich weshalb ich dann wohl doch auf insert und delete zurückgreifen werde. Ich wollte einfach versuchen einen Fehler zu vermeiden.

Aber trotzdem Danke.

[dirk11]

Das ist nur eine zusätzlich Sicherheit auf meinem Client.

Nein, das ist eben genau der Fehl-Gedanke, den Du voraussetzt. Das bringt in erster Linie Zeitverschwendung (wie auch eine "mehrmals tägliche" Suche nach updates, die allerhöchstens Strom verbraucht und die Ressourcen durch Deine Anfragen belegt) und - wenn überhaupt - allerhöchstens eine Schein-Sicherheit, aber kein echtes Plus an Sicherheit.

[joe2017]

Für alle welche ein ähnliches Problem lösen wollen, anbei mein Script für das temporäre öffnen und schließen von Ports.

Code: Alles auswählen

varnft80="tcp dport 80 accept"
varnft443="tcp dport 443 accept"
if ! sudo nft list ruleset -nna | grep "$varnft80"; then 
  sudo nft add rule filter output $varnft80
  var80=addrule
fi

if ! sudo nft list ruleset -nna | grep "$varnft443"; then 
  sudo nft add rule filter output $varnft443
  var443=addrule
fi

sudo apt -y update
sudo DEBIAN_FRONTEND=noninteractive apt -y upgrade
sudo apt -y autoremove

if [ "$var80" == "addrule" ]; then 
  delhandle80=$(sudo nft list ruleset -nna | grep "$varnft80" | cut -d "#" -f2)
  sudo nft delete rule filter output $delhandle80
fi

if [ "$var443" == "addrule" ]; then 
  delhandle443=$(sudo nft list ruleset -nna | grep "$varnft443" | cut -d "#" -f2)
  sudo nft delete rule filter output $delhandle443
fi

[mat6937]

..., anbei mein Script für das temporäre öffnen und schließen von Ports.

Code: Alles auswählen

if ! sudo nft list ruleset -nna | grep "$varnft80"; then 
  sudo nft add rule filter output $varnft80

BTW: Warum musst Du "sudo" in deinem Script benutzen?

[joe2017]

Ich hab das in ein Startscript gepackt und das ist wohl aus der Gewohnheit Bzw. das Ergebnis vom kopieren meines vorherigen Tests.
Ist das generell ein Problem? Sollte ich hierbei auf etwas achten?

[mat6937]

Ist das generell ein Problem? Sollte ich hierbei auf etwas achten?

Ich weiß nicht ob das ein Problem ist. Aber wenn Du das Script mit root-Rechten ausführst, sollte sudo m. E. nicht erforderlich sein. Evtl. mal testen.

[joe2017]

Gut zu wissen. Das werde ich mal testen. Aber ein Fehler ist das nicht unbedingt oder?