Re: Konvertierung ipchains -> iptables

Andre Beck <beck@xxxxxx> wrote:


> > Das mag bei einer Unternehmensfirewall durchaus sinnvoll sei. Im Fall
> > eines ISP, der die Regelwerke von mehr als 100 Hosting-Kunden in seiner
> > Firewall umsetzen muss, ist das leider nicht so einfach.
>
> Die Kunden werden Dir kaum opaque ipchains-Zeilen geliefert haben, die
> dann blind umgesetzt wurden. Vielmehr wird es auf einige triviale Sachen
> wie "lasse incoming X/tcp zu server Y durch" hinauslaufen, die dann erst
> von Euch in Regeln umgesetzt wurden.

Richtig.


> Man kann diesen Schritt auch erneut
> gehen, es sei denn die Wünsche der Kunden müssen jetzt aus dem Script
> reverse engineered werden. Aber selbst das ist bei hinreichender Kommen-
> tierung noch machbar. Im Übrigen sollte man sowas vielleicht in Makro-
> artige Aliases oder Shell-Prozeduren verpacken, damit die Formulierung
> hinreichend abstrakt bleibt.

Auf der einen Seite hast du recht. Auf der anderen Seite würde das die
Fehleranfälligkeit wohl noch erhöhen. Gerade bei Komplexen Regelwerken
ist keep it simple angesagt. Zusätzliche Shell-Prozeduren und Scripte
oder gar ein zusätzlicher Abstraktionslayer würden die Sache weiter
verkomplizieren.

> > Die bestehende ipchains-Firewall ist im laufe der Jahre (seit 2001)
> > gewachsen und stellt momentan exakt die gewuenschten Regeln unserer
> > Kunden dar.
>
> Das tut sie höchstwahrscheinlich nicht, da ipchains stateless war.

Da wir bislang keine Stateful-inspektion angeboten haben, entspricht der
Ist-Zustand exakt dem Auftrag des Kunden.

Die Firewallkonzepte meiner Kunden dürften in den meisten Fällen wohl
auch kaum das Gesamtkonzept darstellen. Unser vorgeschalteter
Paket-Filter ist nicht mehr als ein externen Zusatzschutz. Kunden, die
statefull filtern wollen, betreiben in der Regel eigene Paketfilter auf
ihren Maschinen.

> Die
> Regel, die oben erwähntes "incoming X/tcp zu Y" implementiert, wird
> bei ipchains notwendigerweise implizit "outgoing 1024-65535/tcp von Y:X"
> aufreißen, obwohl der Kunde das nicht wirklich wollte.

Wenn er das nicht will, muss er momentan selbst dafür sorgen. Wir bieten
derzeit outgoing nur eine positiv-Liste von geblockten Ports an. D.h.
der Kunde kann gezielt ausgehende Verbindungen blocken. Default-mässig
ist outgoing alles offen.

> Von der für FTP
> nötigen Regel, die implizit jeden oberen Port aufmacht, wollen wir gar
> nicht reden. Der Wunsch des Kunden lässt sich mit iptables besser oder
> überhaupt erst korrekt implementieren, also sollte man das nutzen und
> nicht stateless ipchains-Regeln transliterieren. Das Resultat mag formal
> identisch sein, aber es ist nicht *gut*.

Naja, genaugenommen ist auch das Resultat formal _nicht_ identisch. Der
Unterschied zwischen einem Paketfilter der statefull filtert und einem,
der das nicht unterstütz ist mir und meinen Kunden durchaus bewusst.
Momentan halte ich eine zentrale Statefull-Filterung aus
organisatorischen Gründen für nicht sinnoll. Hier wäre es sinnvoller,
eine kleine Firewall-Bridge vor jeden Switchport des Kunden zu hängen,
den der Kunde dann aber ein Webinterface selbst verwalten kann. So wird
das bei grösseren Hostern wie z.B. den Kollegen bei Schlund+Partner
gehandhabt, AFAIK.

> > Ohne Ruecksprache/Genehmigung der Kunden darf ich da nichts
> > eigenmaechtig aendern.
>
> Das ist verständlich. Aber wie gesagt, die Absprache mit den Kunden wird
> sich kaum auf konkrete ipchains-Regeln erstrecken sondern eher auf Konzepte
> wie die Erreichbarkeit bestimmter Dienste. Und die implementiert man bei
> iptables am besten stateful neu, wonach man schon mal halb so viele Regeln
> hat wie vorher (plus ein bis drei "pass everything stateful" Rules).

ja, da gebe ich dir recht... aber das geht in diesem Fall einfach schon
einen Schritt zu weit. Ich habe mir angewöhnt immer nur einen Schritt
nach dem anderen zu machen. Im ersten Schritt würde ich gerne das
bestehende Regelwerk auf eine neue Technik abbilden. Im zweiten Schritt
kann ich mich dann damit beschäftigen, welche neuen Möglichkeiten sich
durch die neue Technik bieten, und kann diese neuen Features dann
zunäcshte mal testweise mit 2 oder 3 Kunden nach vorheriger Absprache
testen. Wenn das klappt kann man ggf. eine komplette Überarbeitung in
Angriff nehmen. Wahrscheinlich wird es aber darauf hinauslaufen, dass
wir für eine Zeit einfach zweigleisig fahren. Also z.B. zukünftige
Subnetz über eine neue Firewall mit Iptables und Statefull-Regeln zu
routen, und dann auf Kundenwunsch nach und einzeln Hosts oder Netze von
der alten Firewall auf die neue umziehen.

Das ist dann genau der Kompromiss aus "never change a running system"
und "offen für neue, verbesserte Techniken sein", der sich bei uns in
der Vergangenheit als tauglich erwiesen hat.

> > Die Umstellung von ipchains auf iptables hat rein technische Gruende. An
> > den aktuellen Poliecie kann und soll nichts geaendert werden. Daher ist
> > es mir wichtig in irgendeiner Form eine 1:1 Umsetzung der bestehende
> > Paketfilter-Regeln zu erreichen.
>
> Ein ipchains-Script ist keine Policy, es ist die Implementation einer
> Policy mit den Mitteln von ipchains. Das ist ein wesentlicher Unter-
> schied.

eben, genau das wollte ich ja damit sagen. Die aktuelle Policy kennt
keine statefull inspection. Da ich an der aktuellen Policy nichts ändern
will, darf dann auch die neue Implementation (iptables) zunächst keine
statefull inspection anwenden. Tut sie es doch, dann habe ich (ohne es
zu wollen) nicht nur die Implementation sondern auch die Policy
geändert.

> Gegenüber ipchains bringt netfilter/iptables zwei deutliche
> Paradigmenwechsel:
>
> 1) State
> 2) Vollständig geänderte Rollen von INPUT/OUTPUT vs. FORWARD
>
> Während man 1) notfalls komplett ignorieren kann, fällt das für 2) sehr
> schwer, zumindest ist es fast unmöglich automatisch umzusetzen. Man
> *will* aus dem bestehenden Regelwerk die intentierte security policy
> herausdestillieren¹ und mit iptables from scratch neu implementieren.
> Alles andere ist Stückwerk. Wenn Du das unbedingt vermeiden willst,
> bleib bei ipchains und verzichte auf neue Kernel.

naja, wie gesagt: Ich werde auf der alten Maschine auch zunächste bei
Ipchains bleiben und einfach eine langsame step-by-step-Migartion durch
eine zweite Iptables-Maschine durchführen, bzw. bei zukünftigen Hosts
bei Bedarf/Interesse die neue Firewall inkl. der neuen Features
anwenden.



--
Gruß,
Jörn

.

Relevant Pages

  • Re: Firewall software.
    ... Most modern Linux systems come with firewall installed with reasonable ... bridge or something that selectively lets packets through it. ... ipchains has been largely replaced by iptables. ...
    (comp.os.linux.networking)
  • Re: Firewall software.
    ... Most modern Linux systems come with firewall installed with reasonable ... bridge or something that selectively lets packets through it. ... ipchains has been largely replaced by iptables. ...
    (comp.os.linux.setup)
  • Re: iptables logging
    ... > I've just switched over to iptables from ipchains. ... > I got the new Linux firewall book by Ziegler. ... iptables uses the DROP target not DENY, and you cant have two targets ...
    (comp.os.linux.security)
  • Re: Firewall software.
    ... Install a firewall. ... ipchains has been largely replaced by iptables. ... binary and name of the program along with the protocol and port allowed. ...
    (comp.os.linux.networking)
  • Re: Firewall software.
    ... Install a firewall. ... ipchains has been largely replaced by iptables. ... binary and name of the program along with the protocol and port allowed. ...
    (comp.os.linux.setup)