Re: Firewallkonfiguration (was: Re: Kein Internetverbot bei CIPux)
Hallo,
On Mit, 29 Nov 2006, Maximilian Wilhelm wrote:
> > <wichtig>nimm das bitte nicht als persoenliche kritik..</wichtig>
>
> Jo.
> Ich antworte trotzdem mal in Bezug auf Alff, vielleicht kommen ja ein
> paar spannende Ideen dabei heraus :)
eben.. genau so war es auch gedacht.
> <Praeambel>
> Ich moechte hier Alff nicht als Loesung aller
> Paketfilter-Management-Probleme verkaufen. Ich kenne einige Faelle fuer
> die Alff sicher nicht die Loesung[tm] ist. Das war aber auch nie die
> Intention. Es loest dafuer einige andere Faelle IMO ganz gut. :)
> Mir geht es hier in erster Linie um Denkanstoesse, was vielleicht noch
> pfiffige Features waeren
> </Praeambel>
> > und gewinnt dabei aber nur kurzfristig etwas.
>
> Hmm.
> Wir verwalten damit seit einiger Zeit unsere Institutsfirewalls an der
> Uni mit ~20 interene Netzen und 50 Diensten auf ~30 Servern.
> Und das - moechte ich mal behaupten - ziemlich schmerzfrei.
Yepp, das will ich auch gar nicht anzweifeln. Ich denke nur wenn man das
Problem grundlegender angehen wuerde, wuerde das viel viel mehr Nutzen noch
bringen.
> > Was ich mir mal wuenschen wuerde, waere ein echtes Firewall Regelwerk, also
> > etwas wo man beginnt zuerst mal die Struktur zu definieren. Was es braucht
> > waere z.b.
>
> > - 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? Oder XSupplicant mit Radius
verwenden? Zeitlicheabhaenigkeiten definieren?
> > - 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.
> > - Zoneneinteilung
> 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...
> > - 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
> > - 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
> > - nur zu definieren wie Host Gruppen miteinander reden, reicht im allgemeinen
> > nicht, normal will man noch eine "Route" haben z.b. einen speziellen Host
> > der als Proxy dient, oder auch nur ein spezielles iptables Module.
> > - direkte Manipulation von der CLI ohne Neustart also wie
> > addhost <HOST> <HOSTGROUP> oder
> > addhostgroup <GROUP> <HOST> <HOST>
> > listhosts <GROUP>
> 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.
>
> > 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?
> 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..
--
Dipl.-Inf. Univ. Florian Reitmeir http://net.multi24.com/
Josef-Schweinester-Str.1 Tel: +43 526 266166
6412 St. Georgen / Austria Fax: +43 526 266166 -10
Reply to: