Re: Firewallkonfiguration (was: Re: Kein Internetverbot bei CIPux)
Am Donnerstag, den 30 November hub Florian Reitmeir folgendes in die Tasten:
Hi!
> > Ich antworte trotzdem mal in Bezug auf Alff, vielleicht kommen ja ein
> > paar spannende Ideen dabei heraus :)
> eben.. genau so war es auch gedacht.
Schoen :)
> > > - Services per Host
> > Alff kennt Services. ;)
> > Dabei ist egal ob Du fuer einen Service einen oder mehrere Server
> > eintraegst.
> Kann man auch Services an Kerberos binden?
Was hat das mit der Firewall zu tun?
> Oder XSupplicant mit Radius verwenden?
> Zeitlicheabhaenigkeiten definieren?
Noe.
> > > - Host Gruppen
> > A la "Wir fassen die Kisten a,b,c und d unter dem Namen 'ganz boese Rechner'
> > zusammen"?
> Verschachtelt natuerlich,
> Host A -> Services
> Host B -> Services
> HostGruppe X -> Host A, Host B
> verhaelt sich aus der Sicht der Firewall wie ein Host, man sollte dann aber
> zusaetzliche Regeln fuer die Gruppe definieren koennen.
Hmm.
> > Sowas gibts schon.
> > Du kannst Netze zu 'Sicherheitsklassen' zusammenfassen und diese spaeter
> > fuer Zugriffskontrolle der Services nutzen.
> Zonen muessen nicht unbedingt etwas mit Sicherheit zu tun haben, hier z.b.
> hab ich das Problem dass sie ca. 10 Firmen ein Ethernet teilen, verbunden nur
> durch DSL Leitungen sind.. ueber mehrere Stationen. Und um es ganz einfach zu
> machen teilen die sich dann aber doch ein paar Rechner, und zwar nicht nur
> Linux Server.
> Ds waere es schoen z.b. dem Backupserver immer wenn er ein Backup machen will
> die Rechte dafuer zu geben, ansonsten aber nicht...
Und im Restore-Fall musst Du erst die Firewall umkonfigurieren?
> > > - syntax check
> > Gibts bald grundlegend auch, da es ein Tool geben wird, was die
> > iptables-Regeln in das 'iptables-restore' Format konvertieren wird, weil
> > das bei unseren ~4000 Regeln um Faktor 10 schneller laed.
> dann hab ich den sematic Check vergessen
Ok, Du willst also die rundum sorglos Loesung.
> > > - echter erreichbarkeits Check von Services, z.b. indem man intern einen
> > > Graphen aufbaut...
> > Interessante Idee.
> verschiedenen Services muessen/sollten ja immer funktionieren, z.b. DNS/DHCP
Waere wohl besser.
> > Meiner Meinung nach sollte es immer eine zentrale Verwaltungseben geben
> > in der auch die verschiedenen Versionsstaende per Revisions Kontroll
> > System getrackt werden.
> > Das laesst sich bei Alff leicht mit nem hook und GIT loesen. (Wird bei
> > uns praktiziert).
> Ich faende es eleganter es wie die Cisco/HP Router zu machen, also aendern
> wie man will. Und dann ein Commit das die Dinge fixiert wie sie sind.
Bei HP mag das ja sein, aber bei Cisco bin ich mir ziemlich sicher, dass
sie genau das *nicht* haben.
Mal davon abgesehen heisst das, dass Du die Regeln von $n Geraete backupen
willst?
> > > das Problem an den META Sprachen/Projekten ist, dass sie zwar den Syntax
> > > "vereinfachen" wie man iptables anwendet. Aber es nicht mehr nachvollziehbar
> > > ist was das ganze Ding tut wenn es wirklich mal mehr regeln werden.
> > Durch die Plugin-Architektur kannst Du Dir anschauen, was jedes Plugin
> > an Regeln "hinten raus" wirft. (Landet in nem Cachedir als "Testdatei"
> > mit den Regeln.) Wenn Du willst kannst Du auch jedes Plugin per Hand
> > anfeuern. (Die regeln landen dann auch fd3, den Du halt vorher umbiegen
> > musst.)
> aber genau das interessiert mich doch nicht, wozu verwende ich eine Meta
> Sprache, wenn ich den echten Syntax dann auch noch kennen muss?
Ok, hier unterscheiden sich unsere "Ideologien".
Ich erwarte von jemandem, der sich Firewalladmin nennt, dass er genau
das *kann*.
Was soll er denn tun, wenn das Tool[tm] mal nicht 100%ig funktioniert?
Soll er dann sagen, "tut mir leid, ich habe keine Ahnung von meinen
Firewalls. Es geht grad nicht"?
[x] dagegen.
Aber das ist halt ne Frage der Ideologie.
> > Bei uns in der Uni fallen (ohne eingeschaltete Optimierung auf
> > moeglichst wenig Regeln) ~4000 Regeln unten raus.
> > Ich finde, dass es auch da noch recht uebersichtlich ist, durch die
> > Aufteilung in kleine Haeppchen. Wenn du natuerlich viele Netze has und
> > da nicht optimieren laesst wird das schnell sehr viel...
> Ah ich hab mich schon laenger mit iptables beschaeftigt und man kann z.b. mit
> MARK erstaunlich viel optimieren..
> > > Es ist
> > > zwar toll einen einfachen Syntax fuer die Erzeugung der Regeln zu haben, es
> > > macht aber keinen Sinn das Debuggen danach mit "iptables -vnL" zu machen.
> > Jo. Wenn die Regeln schon geladen sind ists ggf. schon zu spaet.
> > Daher werden die bei Alff (und vielen anderen auch) erst generiert und
> > dann ge'push'ed.
> Wenn ich so ein Tool verwende, will ich mit iptables gar nix mehr zu tun
> haben muessen. Und ich will sicher sein dass alles OK ist, z.b. waere es cool
> etwas zu haben wie:
> check HostA -> HostB:TCP:90
> als CLI Tool, und es sagt mir dann ob das in meinem Netz funktioniert..
*Das* waere allerdings nen schickes Feature.
Summa summarm denke ich, dass wir beide eher nicht auf einen Nenner
kommen, da wir das Problem verschieden angehen :)
Ciao
Max
--
Follow the white penguin.
Reply to: