Re: Firewallkonfiguration (was: Re: Kein Internetverbot bei CIPux)
Am Mittwoch, den 29 November hub Florian Reitmeir folgendes in die Tasten:
Hi!
> <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 :)
<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>
> Ein kurzer Blick in den Source zeigt wie das ganze entwickelt wird..
> man nehme die eigenen iptables shell skripte, und baue makros..
Ganz so einfach ist das dann doch nicht.
> 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.
> (und ich habe glaub ich selber min. 3-4 solcher Projekte angefangen)
> 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.
> - Services per Host Gruppe
Was meinst Du damit genau?
> - Host Gruppen
A la "Wir fassen die Kisten a,b,c und d unter dem Namen 'ganz boese Rechner'
zusammen"?
> - Zoneneinteilung
Sowas gibts schon.
Du kannst Netze zu 'Sicherheitsklassen' zusammenfassen und diese spaeter
fuer Zugriffskontrolle der Services nutzen.
> - 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.
> - echter erreichbarkeits Check von Services, z.b. indem man intern einen
> Graphen aufbaut...
Interessante Idee.
> - 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).
> ...
> - Anzeige der Firewallstrukturen..
> 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.)
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...
> 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.
Ciao
Max
--
Follow the white penguin.
Reply to: