OPNsense Forum

Hallo,

kann mir jemand etwa erklären wie die Firewall-Gruppen, in welchen Situationen, verwendet werden?
Ich versuche allgemeine Rules wie ausgehende 80/443 oder DNS aus einzelnen Interfaces zu entfernen, und dort eigentlich nur spezifische Rules haben. Die obigen Ports sind ja auf nahezu allen Interfaces vorhanden.
Macht das Sinn?

Und wenn man dafür Gruppe verwenden würde, wie benennt ihr die Gruppen in etwa? Ich habe gesehen dass für jede Gruppe ein Untermenü entsteht, ich kann mir nur vorstellen dass ich dann einige Gruppen dort entstehen, wie zB. GRP_Web_Surfing, GRP_DNS_Out usw. Einfach alle Interfaces in eine Gruppe zu bündeln wäre mir etwas zu viel, da ich damit nicht genug Freiheit habe.

Aber vielleicht das überhaupt eine falsche Anwendung. Suche hier einfach nach den Anwendungsszenarien.

Danke

Ich muss ja schon sagen, in der Zahl wie du hier die unterschiedlichsten Themen ins Forum postest, finde ich die Aussage "ich brauch keinen Support" schon lustig. Aber warum sollte man Firewall KnowHow auch bezahlen ;)

Interface Gruppen kann man vielfach anwenden, da braucht es gar keine große Phantasie. Sobald man einmal ernsthafter über Security Konzepte und Netzwerk-Architektur nachdenkt und anfängt, sein Firmen-Netzwerk sinnvoll zu segmentieren, ergeben sich automatisch Anwendungsfälle. Und seien es nur so einfache wie Nutzung für Infrastruktur-Regeln, die dann auf alle sie brauchenden VLAN Interfaces gemappt werden.

Gibt natürlich auch Fußangeln bei Blocks/Rejects oder im Cluster aber das ist dann die Abwägung, was man wo an welcher Stelle haben möchte.

Cheers

Quote from: JeGr on June 21, 2021, 06:26:53 PM
Ich muss ja schon sagen, in der Zahl wie du hier die unterschiedlichsten Themen ins Forum postest, finde ich die Aussage "ich brauch keinen Support" schon lustig. Aber warum sollte man Firewall KnowHow auch bezahlen ;)



Cheers

Genau das habe ich mir auch gedacht :)

Moin, moin,

So wie ich die Interface-Gruppen verstehe dienen sie zwei Zielen:

• Durch die Baumstruktur der Interface-Gruppen werden viele Interface (meistens in verschiedenen VLANs) zusammengefasst
• Ich überlege auf unterster Ebene jedem physischem Interface ein eigene Gruppe zu spendieren, damit ich bei Bedarf das Interface tauschen kann, ohne die Regeln anpassen zu müssen (siehe (https://forum.opnsense.org/index.php?topic=23251.msg110483#msg110483)).

Gruß
Thomas

Und ich muss dann ja auch schon sagen, dass ich mich hier manchmal richtig seltsam behandelt und angegriffen fühle.
Dein Post, Jens, hat mich gerade ehrlich gesagt extrem irritiert:

QuoteIch muss ja schon sagen, in der Zahl wie du hier die unterschiedlichsten Themen ins Forum postest, finde ich die Aussage "ich brauch keinen Support" schon lustig. Aber warum sollte man Firewall KnowHow auch bezahlen ;)

Also versuchen wir es nochmal sachlich und im Klartext:
Wo habe ich gesagt "ich brauch keinen Support", wortwörtlich? Meines Wissens nach nie.
Falls ich genau sowas gesagt habe, dann war es durchaus falsch. Ganz im Gegenteil.
Ich habe vor paar Wochen das Budget für paar Umstellungen vorgestellt (wir schaffen neue Internet-Leitung, Firewall und Telefonie an), und dazu auch einen 10Std-Support-Block für die Umstellung der Firewall eingeplant/budgetiert.
Was ich aber ziemlich sicher gesagt habe, ist dass ich einen laufenden Wartungs-Vertrag (=monatliche Kosten) nicht durchbringen kann (und meiner Meinung nach, für unsere Bedürfnisse, nicht brauche). Ist nicht budgetiert, wird nicht genehmigt und ist nicht möglich.

Dass mein KnowHow nicht auf der Ebene von gewissen Personen hier ist (du inkludiert natürlich auch), ist mir schon klar. Ich verstehe aber nicht, warum das eine Erwartungshaltung ist?

Weißt eigentlich, ich bin auf mich selbst eigentlich sehr stolz was ich alles seit 2013 geschafft habe zu lernen, abgesehen davon dass ich damals nicht mal wusste was ein Server oder Netzwerk ist. Geschweige Linux, Open Source, oder ähnliches. Das war der Beginn meiner IT-Karriere.
Teure Kurskosten kann ich mir nicht leisten, die Quellen (Bücher, Videos, CBT, Web...) die ich kannte oder kenne habe ich genutzt und eigentlich nur mit sehr viel Selbstmotivation und Eigeninteresse vorangekommen.
Die Firma bezahlt es auch limitiert, sicher keine Tausenden an Euros um Zertifizierungen zu bekommen.
Ist halt so. Aber sie zahlen mir zumindest aktuell die CBTs die ich selbst nutzen kann um voran zu kommen.
Aber das tolle dahinter: ich hab ein großes Interesse und Affinität für die IT und freue mich ständig neue Sachen gelernt zu haben.
Wäre schön hätte ich ein Umfeld in dem ich von erfahrenen IT'lern lernen könnte, habe ich aber leider nicht.
Nur so viel mal zum Background.

Ihr könntet (müsst aber nicht) das auch positiv sehen, dass ich mich für diese Sachen interessiere und strebe einer Besserung an. Letztendlich, will man dazu nichts beitragen, muss man ja nicht antworten.

Letztendlich, dein zweites Teil des Postings ist wiederum für mich sehr nützlich und etwas was ich in meiner Planung gut einbinden kann.
Das aber was du geschrieben hast, ist eben genau das, was ich schon als Idee in meinem ersten Post geschrieben habe. Ich habe lediglich um Best Practices gefragt, und sehe dabei nichts falsches, definitiv keinen Ansatz für ein solches Posting (Teil1).

QuoteGibt natürlich auch Fußangeln bei Blocks/Rejects oder im Cluster

Ich glaube mein Deutsch reicht nicht das hier genau zu verstehen. Kannst du erklären bitte?

Quote from: thogru on June 21, 2021, 07:04:13 PM
Moin, moin,

So wie ich die Interface-Gruppen verstehe dienen sie zwei Zielen:

• Durch die Baumstruktur der Interface-Gruppen werden viele Interface (meistens in verschiedenen VLANs) zusammengefasst
• Ich überlege auf unterster Ebene jedem physischem Interface ein eigene Gruppe zu spendieren, damit ich bei Bedarf das Interface tauschen kann, ohne die Regeln anpassen zu müssen (siehe (https://forum.opnsense.org/index.php?topic=23251.msg110483#msg110483)).

Gruß
Thomas

Servus!
Jep, VLANs habe ich (zu Hause mehr Spielerei als was anderes, in der Firma eine logische und überlegte Trennung zwischen Bereichen), und genau dafür erstmal eingesetzt. Hab mit simplen Aufgaben angefangen, Web und DNS, aber bin dann irgendwie hängen geblieben, da ich so schnell eine elendlange Liste im Firewall-Menü bekomme... deswegen wollte ich mal eure Überlegungen wie die Interfaces gruppiert werden, nach welchen Regeln... blöd ist es für mich die Gruppe Web_Surfing zu nennen... wahrscheinlich geht es mir rein um das Benennen der Gruppen. Logisch, verständlich, und wofür genutzt, verstehe ich sowieso! Und blöd bin ich nicht, um mir auszudenken wofür ich die verwende (sorry, ist noch etwas "Venting" von vorher dabei...)

Und wie du auch schon in deinem Post erklärt hast... zu Hause habe ich schon etliche Aliase, weil ich VPN mit Firma hab. Wenn ich dann die Migration von Sophos auf OPNsense mache, wird das viel viel länger. Und genau da versuche ich, eine neue Planung mit möglichst viel Ordnung zu machen (und ich rede hier nicht von der technischen Aufstellung, sondern Ordnung in der Firewall).

Aktuell ist es so, dass ich viele Rules kopiert (geclont) habe. Und viele sind bei vielen Interfaces gleich. Aber nicht bei allen. zB. LAN hat NNTP out, aber IoT VLAN nicht.

Quote
Ich glaube mein Deutsch reicht nicht das hier genau zu verstehen. Kannst du erklären bitte?

Sicher. Gruppen stehen in der Reihenfolge der Abarbeitung woanders als Interfaces. Oder Floatings. Floats, Gruppen + Sondergruppen, Interfaces. Ein Block in Gruppen wird also ausgeführt bevor es ins Interface geht. Darum gefährlich wenn man die Reihenfolge nicht im Auge behält. Genauso multiple Gruppen.
Oder bei einem Cluster. Da Gruppen keine Synchronizität haben, werden Änderungen an Interfacezuordnungen dort gerne übersehen.

Zu dem 2. Punkt was Thogru schrieb, wäre ich vorsichtig. Bei Gruppen gehen verschiedene Funktionen verloren. Vor allem wäre ich vorsichtig, WAN Interfaces als Gruppe zusammenzufassen, da sonst ggf. das reply-to für Antwort über das korrekte Gateway verloren geht. VLANs nochmal in Gruppen zu fassen (wo nur sie alleine drin sind) macht keinen Sinn, dafür ist ja genau die Abstraktionsschicht da, die aus bspw. igb0 ein opt3 macht. Eben damit man das Interface tauschen kann.


Zu dem anderen Post enthalte ich mich. Halte nichts von öffentlichem Drama.

Cheers

Verstehe, besten Dank.
Wenn schon, dann hätte ich vor meine LAN+VLAN Intf zusammenzufassen, um die Rules die auf alle gehen auf einem Ort zu halten und die Listen in den Intf selbst kürzer zu halten.
Das schaffe ich zum Teil mit den Aliasen.

Womit kann ich bei Gruppen oder Floating die Destination ersetzen? zB. bei DNS habe ich nur erlauben wenn es auf LAN Intf -> LAN net geht. In Gruppen oder Floats habe ich diese Möglichkeit nicht. Ersetzt "This Firewall" Alias die einzelnen Interface-IP-Adressen und wäre im Falle meiner DNS-Rules einsetzbar? (ich weiß dass "This Firewall" auch WAN-IP beinhaltet, daher die Frage)

QuoteZu dem anderen Post enthalte ich mich. Halte nichts von öffentlichem Drama.

Vielen Dank.

> Womit kann ich bei Gruppen oder Floating die Destination ersetzen? zB. bei DNS habe ich nur erlauben wenn es auf LAN Intf -> LAN net geht. In Gruppen oder Floats habe ich diese Möglichkeit nicht.

Macht für mich gerade überhaupt keinen Sinn. Warum sollte ich "von LAN Int auf LAN net" DNS freigeben? Kommt nie vor.

> In Gruppen oder Floats habe ich diese Möglichkeit nicht.

Richtig, logischerweise, weil es keine definierten Quellen gibt.

> Ersetzt "This Firewall" Alias die einzelnen Interface-IP-Adressen und wäre im Falle meiner DNS-Rules einsetzbar? (ich weiß dass "This Firewall" auch WAN-IP beinhaltet, daher die Frage)

This Firewall enthält immer alle Adressen der Firewall und das ist oft nicht gewünscht. Zumal damit auch Aliase etc. abgedeckt sind.

QuoteMacht für mich gerade überhaupt keinen Sinn. Warum sollte ich "von LAN Int auf LAN net" DNS freigeben? Kommt nie vor.

Vielleicht Missverständnis. Wenn ein Client eine DNS Anfrage an die Firewall machen will, muss ich Port 53 am Firewall-Interface erlauben. Dafür habe ich aber die Destination auf LAN net gesetzt, um sicher zu gehen, dass die Anfragen nicht an externe DNS gehen können. Außerdem ist auch ein NAT Rule gesetzt, der sagt alle DNS Anfragen die nicht an die Firewall (!RFC1918) gehen, auf 127.0.0.1 umgeleitet werden.
Das ist alles bei mir zu Hause, daher nicht kritisch, aber wenn die Firewall in der Firma konfiguriert wird, werde ich jede Funktionalität die ich einbaue, auch genau überprüfen, ob sie funkt so wie angedacht. Dafür habe ich den ganzen Sommer Zeit...

QuoteThis Firewall enthält immer alle Adressen der Firewall und das ist oft nicht gewünscht. Zumal damit auch Aliase etc. abgedeckt sind.

OK, ich glaube ich bin mittlerweile davon überzeugt dass ich weder Floating noch Gruppen wirklich brauchen werde, vielleicht nur für einzelne Rules. Da muss man sich eigentlich echt merken was man in Floating drinnen hat, und nicht gleich neue Rules in den Interfaces erstellen.

Ich nutze floating v.a. für BLOCK rules....

Ahh genau, guter Tipp! Danke!

> Vielleicht Missverständnis. Wenn ein Client eine DNS Anfrage an die Firewall machen will, muss ich Port 53 am Firewall-Interface erlauben. Dafür habe ich aber die Destination auf LAN net gesetzt, um sicher zu gehen, dass die Anfragen nicht an externe DNS gehen können. Außerdem ist auch ein NAT Rule gesetzt, der sagt alle DNS Anfragen die nicht an die Firewall (!RFC1918) gehen, auf 127.0.0.1 umgeleitet werden.

Das macht aber keinen Sinn. LAN net ist doch völlig sinnbefreit. Die Anfrage geht an den DNS Server der per DHCP gepusht wird. Normalerweise also die entsprechende IP der Firewall auf dem Interface. Also LAN Addr und nicht LAN net. Warum sollte ich unnötig das ganze Netz aufmachen. Wenn dann geht die Regel von SOURCE LAN net auf Destination LAN address Port 53. Sonst nix. Und die Redirection Rule greift dann für udp/53 Ziele !(LAN address) damit die umgeschrieben werden auf LAN. Oder localhost, wie man das handhaben will ist egal.

Aber genau sowas kann man dann eben "optimieren" mit nem Alias von allen VLAN Netzen als Source, Destination ist "this firewall" (weil es dann um gezielten Zugriff von udp/53 geht) als Destination und die Regel in ner entsprechenden Gruppe. Genau das war u.a. mit Infrastruktur Regeln gemeint. DNS, NTP, etc. Was aus jedem (V)LAN gehen soll. Was eigene Infrastruktur Grunddienste sind.

> Ich nutze floating v.a. für BLOCK rules....

Kann man ruhig machen, ich halte es für gefährlich weil es viele Leute eben aus den Augen verlieren und sich dann krumm suchen. Die Praxis hat gezeigt, dass die Admins Blocks eher sehen, wenn sie auf dem Interface selbst sind als in Floats. Zudem kann man dann keine Ausnahmen mehr auf dem Interface definieren, weil die Floating davor sitzt und alles wegfrisst. Genau daher meinte ich oben, dass es Fußangeln gibt bei Gruppen wie bei Floating wenn man mit Blocks/Rejects darin rumspielt. Dann bekommt man ruck zuck Komplexität rein, die man vielleicht vermeiden möchte, nur um ein zwei Regeln extra zu sparen. :)

Quote from: JeGr on June 22, 2021, 06:40:10 PM
...
> Ich nutze floating v.a. für BLOCK rules....

Kann man ruhig machen, ich halte es für gefährlich weil es viele Leute eben aus den Augen verlieren und sich dann krumm suchen. Die Praxis hat gezeigt, dass die Admins Blocks eher sehen, wenn sie auf dem Interface selbst sind als in Floats. Zudem kann man dann keine Ausnahmen mehr auf dem Interface definieren, weil die Floating davor sitzt und alles wegfrisst. Genau daher meinte ich oben, dass es Fußangeln gibt bei Gruppen wie bei Floating wenn man mit Blocks/Rejects darin rumspielt. Dann bekommt man ruck zuck Komplexität rein, die man vielleicht vermeiden möchte, nur um ein zwei Regeln extra zu sparen. :)

Aber das ist doch relativ einfach: Die Dinge die ich ÜBERHAUPt nicht will, sind floating, alles Spezifische ist auf den einzelnen Interfaces. Kann man sich doch merken. Selbst in meinem Alter funktioniert das ganz gut...

QuoteDie Anfrage geht an den DNS Server der per DHCP gepusht wird.

Korrekt. Bis man es in der NIC nicht händisch ändert.

QuoteAlso LAN Addr und nicht LAN net.

Korrekt, die Anfragen gehen by default an LAN Addr. Und jetzt sehe ich dass sich im Posting ein Fehler eingeschlichen hat... mein Rule heißt:
IPv4 TCP/UDP   LAN net   *   LAN address   53 (DNS)   *   *   DNS

Also tut mir für die Verwirrung echt leid.

QuoteAber genau sowas kann man dann eben "optimieren" mit nem Alias von allen VLAN Netzen als Source, Destination ist "this firewall" (weil es dann um gezielten Zugriff von udp/53 geht) als Destination und die Regel in ner entsprechenden Gruppe. Genau das war u.a. mit Infrastruktur Regeln gemeint. DNS, NTP, etc. Was aus jedem (V)LAN gehen soll. Was eigene Infrastruktur Grunddienste sind.

Genau! Da sind wir ja doch bei der gleichen Sache doch! Hab das noch gestern gemacht:
FIREWALL: RULES: GRP_GEN_PROTO
       Protocol   Source   Port   Destination   Port   Gateway   Schedule   Description    
        IPv4 TCP/UDP   GRP_Gen_Proto net   *   This Firewall   53 (DNS)   *   *   DNS       
        IPv4 TCP   GRP_Gen_Proto net   *   *   80 (HTTP)   *   *   HTTP       
        IPv4 TCP/UDP   GRP_Gen_Proto net   *   *   443 (HTTPS)   *   *   HTTPS       
        IPv4 TCP/UDP   GRP_Gen_Proto net   *   *   8080   *   *   HTTP Alternate       
        IPv4 UDP   GRP_Gen_Proto net   *   *   123 (NTP)   *   *   NTP       
        IPv4 ICMP   GRP_Gen_Proto net   *   *   *   *   *   Allow ICMP (Echo Req)       

GRP_Gen_Proto ist eben LAN+VLANs.

QuoteAber das ist doch relativ einfach: Die Dinge die ich ÜBERHAUPt nicht will, sind floating, alles Spezifische ist auf den einzelnen Interfaces. Kann man sich doch merken. Selbst in meinem Alter funktioniert das ganz gut...

Mir fällt ehrlich gesagt gar nix ein, was ich blocken müsste. Hab mal Internet am Hyper-V geblockt, aber das war's. Sonst ist eh alles gesperrt, da man nur das erlaubt, was auch nötig ist.
Hast vielleicht ein Beispiel für mich?

Windows telemetry (via Alias), irgendwelche pings, die mein Linux an die Distribution sendet, ipv6 generell. Solche Sachen...

Danke für die Ideen!

Quote
Aber das ist doch relativ einfach: Die Dinge die ich ÜBERHAUPt nicht will, sind floating, alles Spezifische ist auf den einzelnen Interfaces. Kann man sich doch merken. Selbst in meinem Alter funktioniert das ganz gut...

Ich widerspreche dir da ja gar nicht :) Nur zeigt die Praxis, dass das hauptsächliche Arbeiten auf den Interfaces selbst stattfindet und die Menschen dazu neigen, die Floating Rules (wie auch automatisch generierte) zu vergessen und sich dann wundern, warum ihre Regel nicht greift. Darauf zielte auch mein Kommentar ab ;)


> Korrekt. Bis man es in der NIC nicht händisch ändert.

Warum soll ich es ändern wenn ich DHCP mache? Das gibt keinen Sinn. Entweder ich mache DHCP oder ich lasse es aber DHCP machen UND dann noch selbst am Interface fummeln ist doch kontraproduktiv?

> IPv4 TCP/UDP   LAN net   *   LAN address   53 (DNS)   *   *   DNS

So macht es auch viel mehr Sinn, korrekt. UDP würde zudem auch reichen. :)

Nachdem man manuell auch outbound Regeln machen kann, nutze ich Floats fast gar nicht mehr. Damit hat man beim Interface dann einfach immer die komplette Sicht der Dinge und muss nicht im Hinterkopf noch dran denken "da waren noch 2 Blocks, 1 Reject und Co". Aber das macht jeder wie es ihm besser in die Orga passt.

Es gibt User die lokale Admin Rechte haben (= darauf bestehen diese zu haben, ich mich weigere, aber muss mich bücken, da mein Chef?) und er dann vlt. mal auf die Idee kommt in das Feld DNS andere DNS einzutragen, weil ihm sein Kumpel so geraten hat?
UDP ja reicht, aber ich bilde mir ein dass ich mal was darüber gelesen habe, und dann es auf TCP/UDP gesetzt habe. Ich weiß aber nicht wirklich mehr warum... bin halt ehrlich :). Ich werd's aber nochmals untersuchen.

Auch guter Tipp wegen Outgoing. Danke

Quote from: kosta on June 23, 2021, 02:41:54 PM
Es gibt User die lokale Admin Rechte haben (= darauf bestehen diese zu haben, ich mich weigere, aber muss mich bücken, da mein Chef?) und er dann vlt. mal auf die Idee kommt in das Feld DNS andere DNS einzutragen, weil ihm sein Kumpel so geraten hat?
UDP ja reicht, aber ich bilde mir ein dass ich mal was darüber gelesen habe, und dann es auf TCP/UDP gesetzt habe. Ich weiß aber nicht wirklich mehr warum... bin halt ehrlich :). Ich werd's aber nochmals untersuchen.

Auch guter Tipp wegen Outgoing. Danke

Wenn bei euch die User ihre eigenen DNS Einträge überschreiben läuft meiner Meinung nach was anderes schief, wieso dann überhaupt DHCP wenn die User die Adresse nicht eh selbst hinterlegen können?

Natürlich rennt ein DHCP für die Clients und die User haben keine Admin-Rechte, ergo können sie selbst nichts umstellen!
Aber wenn mir mein Chef mit der Entscheidung kommt, dass ich ihm die lokalen Admin Rechte geben muss, kann ich mich dem nicht widersetzen, sonst bin ich den Job los.
Bestenfalls kann ich ihm auf jegliche Gefahren hinweisen, mich ausdrücklich dagegen aussprechen und damit abgesichert sein. Es entsteht eine ernste Sicherheitslücke, aber ich kann zumindest sagen ich wurde dazu angewiesen, es zu machen (und ja, habe es schriftlich).
Danach habe ich seinen Rechner aus der Domäne rausgenommen, jedoch verwenden wir auch OpenVPN, hier musste ich den Zugriff auch eingrenzen, kein Zugang auf die lokalen Daten (braucht er nicht mehr, hat alles lokal und im Rechenzentrum). Sicherung braucht er keine, kümmert sich selbst drum.
Warum und wieso jetzt OpenVPN, wenn kein Internzugriff, möchte ich jetzt nicht weiterhin erklären, da es etwas komplexer ist, aber glaub mir einfach wenn ich sage, er braucht OpenVPN weiterhin und muss trotzdem DNS der Firma nutzen.

Was ist so schwer daran zu verstehen, wenn er die lok. Admin Rechte hat, sich selbst, aus welchen Grund auch immer, die IP-Daten ändern könnte? Ich will nicht darüber diskutieren ob er das tut, sondern dass er das tun KANN.

> Es gibt User die lokale Admin Rechte haben (= darauf bestehen diese zu haben, ich mich weigere, aber muss mich bücken, da mein Chef?) und er dann vlt. mal auf die Idee kommt in das Feld DNS andere DNS einzutragen, weil ihm sein Kumpel so geraten hat?

Kann er ja versuchen, dafür gibts dann die "geforcte" Umleitung auf den lokalen DNS der Sense. Oder ein Block auf andere 53/udp. Das ist durchaus gängig. Nicht um DNS Umgehung zu blocken, sondern die Leute zu sichern, dass interne URLs aufrufbar bleiben. Und lokale Domains die ggf. nicht im Netz bekannt sind funktionieren eben nicht wenn jemand sich nen externen DNS reinfummelt. Daher wird das normalerweise weggeblockt bzw. umgeleitet.

Aber ja. Wenn jemand mit Admin Rechten am Netzwerk rumfummelt braucht er sich nicht zu beschweren, wenn dann nichts mehr geht. Das ist inklusive bei Admin Rechten. Man kann alles nur soweit absichern und konfigurieren, wie es sinnvoll ist. Wenn halt jemand vorsätzlich anfängt Murks zu machen, kann man das nur blocken/verhindern, aber dass dann eben nicht mehr alles läuft - daran ist die Person dann selbst schuld. :)

Und manchmal reicht es auch sich selbst abzusichern, notfalls einfach mit nem Schriftstück, dass belegt, dass egal wer - ob Chef oder nicht - X genauso haben will wie es gemacht wird und man dann nicht für etwaige Folgeschäden haften/Verantwortung tragen kann.

QuoteKann er ja versuchen, dafür gibts dann die "geforcte" Umleitung auf den lokalen DNS der Sense.

So ist es, das ist genau wovon ich bereits paar Posts früher gesagt hab. Aktuell aktiv zu Hause, nur zum testen, bei mir zu Hause macht keiner den Blödsinn, aber ich werde es auch so in der Firma umsetzen.

Quotesondern die Leute zu sichern, dass interne URLs aufrufbar bleiben.

So kann man es natürlich auch sehen.
Und ja, würde das wer tun, würde einiges nicht funken, korrekt.
Beim Chef ist es aber etwas anders, da er keine internen Ressourcen mehr benötigt. Hat sein Outlook, lokal Office und das war's eigentlich.

Quotedaran ist die Person dann selbst schuld.

Da er nicht sonderlich IT-affin ist, warte ich bereits auf die Support-Anrufe...  ::)

> Da er nicht sonderlich IT-affin ist, warte ich bereits auf die Support-Anrufe...  ::)

Nicht ganz richtig. Support kann ich immer nur liefern, wenn es möglich ist. Wenn sich jemand absichtlich Dinge verbaut weil er die Rechte dazu hat, kann ich weder was dafür noch in hellseherischer Aufopferung dagegen Vorkehrungen treffen. Das geht nur nach bestem Wissen und Gewissen und irgendwo endet das eben.

Wenn sich Chef mit Admin Rechten lokal in seine Hosts Datei bspw. Murks reinschreibt, dann kannst du auch alles menschenmögliche vorher tun - aber bei ihm wirds dann trotzdem nicht klappen und er kann abc.de nicht auflösen weil ers ggf. falsch überschrieben hat. Man kann Leute eben nicht vor sich selbst schützen. ;)

Und Admin Rechte am eigenen Rechner sind jetzt nicht so abenteuerlich, gibts oft in kleinen wie großen Firmen ohne dass einer auf schräge Ideen kommt :D

Die Gefahr ist einfach da. Und ich bin für die Behebung zuständig, so einfach ist es.

Und sorry, ich bin voll gegen jegliche Admin-Rechte auf lokalen Rechnern, sofern umsetzbar. Dazu sperre ich auch alles was geht mit den SRP oder Applocker. User-Erziehung hin oder her, setze ich in der IT auch auf alles was geht.

Ich habe etwas im Bezug zu Interface Groups gesehen...
Wenn man auf Inspect klickt, sieht man ja die States, Packets...
Für mich macht das eben einen Grund, warum ich nicht Intf-Gruppen bauen sollte.
Für die paar Rules die drinnen sind, kann mir das genauso sparen.
Dafür ist das Troubleshooting deutlich klarer, da man pro Intf die States sehen kann.
Daher kommen die Gruppen mal wieder weg.

delete