Softpicks.Net Deutsch

Hallo,

Bernd Hohmann <nixda [at] nixwill.de> wrote:
> ich muss demnächst eine historisch gewachsene Infrastruktur
> konsolidieren. Sprich: das ist ein Komposthaufen par excellance - und
> der Komposthaufen ist verdammt gross.
> So nach grober Prüfung gehe ich davon aus, dass Netfilter das hinbekommt.
> Die Frage ist nur: finde ich eine GUI, die mir die Konfiguration
> erleichtert oder muss ich doch ans Eingemachte gehen?

Es gibt mehrere, aber ich moechte fast bezweifeln, dass sie dir in diesem
Fall wirklich die Arbeit erleichtern ... Versuch zuerst, eine Struktur da
reinzubringen, versuche die Rechner in Gruppen zusammenzufassen, fuer die
du jeweils separat Regeln aufstellst und erzeuge dir ggfs. einen "Prae-
prozessor" (das kann notfalls auch einfach nur ein Script sein), der dir
aus den "Gruppenzugehoerigkeiten" dann die Firewallregeln erzeugt.
Halte dich fuer die weitere Pflege an das einmal erarbeitete Konzept.
Ansonsten sehe ich fuer den Versuch, eine wartbare Loesung zu erstellen
relativ schwarz (aber ich kann mich da taeuschen ...).

> Die Anforderungen sind etwas "krude" und ich habe auch ehrlich gesagt
> noch nicht so recht den Überblick wie ich es lösen werde.

Plane es zuerst, und zwar so, dass du eine Vorstellung davon hast, wie
das zu loesen ist, *bevor* du anfaengst, Regeln zu bauen.

> Generell arbeitet das gesamte Netzwerk mit öffentlichen Adressen, da ist
> also nix mit Exposed Hosts als Pseudo-DMZ.

Das ist kein Hindernis.

> Von "aussen nach innen" ist es der übliche Kram bis auf das Feature dass
> ich gerne auf Layer 7 paar Sachen machen möchte. Dazu gehört auch die
> Überwachung der Zugriffs auf Legacy-Applikationen. Also so Sachen wie
> "wenn von aussen nach innen zugegriffen wird und 'innen' 2x in 3min
> "login failed" absetzt muss die Absende-IP für 1h in die Blacklist und
> ein Alert abgesetzt werden (Ja, ich *weiss* dass diese Konstruktion böse
> ist).

Fang mit der Implementation solcher Zusatzanforderungen erst dann an, wenn
*alle* *Regeln*, die festlegen, was erlaubt werden soll und was nicht,
bereits stehen und du dir ein Konzeot fuer deren Umsetzung ueberlegt hast.

> Von "innen nach aussen" ist es noch böser, da sollte in Abhängigkeit von
> der Zieladresse und dem Zielport auf bestimmte Interfaces geroutet
> werden. Also etwa "Bist Du http/https/ftp, dann Route das über
> Interface3 heraus wenn die Zieladresse nicht im Bereich
> 123.123.123.0-123.123.123.255 ist; alles andere Route nach 22.22.22.14"

Du benoetigst dafuer "policy-based routing". Mein Tipp: versuche das *nicht*
in der Firewall zu implementieren, wenn die Firewall einigermassen wartbar
bleiben soll.

> Und das Ganze natürlich als Bridge.

Warum? Versuch besser, dem Verantwortlichen die "filternde Bridge" aus-
zureden. Frag ihn nach *Anforderungen*, nicht danach, wie er sich eine
Realisierung vorstellt. Erarbeite *selbst* das Konzept zur Loesung und
lege es ihm als Loesungsvorschlag vor. Ob "filternde Bridge" oder nicht
ist ein Implementierungsdetail, ueber das allein derjenige entscheiden
sollte, der die Loesung zu erarbeiten hat.

> Ja, ich weiss - scheiss Spiel. Von Beileidsbekundungen in Form von "Nimm
> Zonealarm" bitte ich abzusehen.

Ueberlege dir genau, ob du diesen Auftrag wirklich so erfuellen kannst,
dass du guten Gewissens sagen kannst, du haettest eine akzeptable Loesung
erstellt. Wenn du das *nicht* kannst, ueberleg dir, ob du diesen Auftrag
unter diesen Umstaenden wirklich erfuellen willst.

Tschuess,
Juergen Ilse (juergen [at] usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
.

Hallo,

Andreas Beck <becka-news-nospam-2008-05 [at] bedatec.de> wrote:
> Mal ehrlich: Ein Schnitzel kann man in einem fremdsprachigen Supermarkt
> auch noch mit Händen und Füßen (GUI) bestellen. Aber wenn Du einen
> Benzinrasenmäher mit genau 43cm Schnittbreite im Gurkenglasdesign und
> Einzelradaufhängung als Sonderanfertigung willst, wäre es evtl.
> sinnvoll, lieber die Sprache (Commandline) zu lernen.

Ja, es ist sehr schwer, bei einem komplexeren Geraet alle Moeglichkeiten
der Kommandozeile einigermassen brauchbar in ein GUI zu packen ...

> Die meisten GUIs versagen kläglich, wenn die Anforderung komplex wird.
> Schließlich muß der GUI-Ersteller ja quasi alle Verrücktheiten ahnen,
> die irgendein User mal wollen wird.

Was mich z.B. am "ASDM" von PIXOS 7.0 momentan ziemlich stoert, ist
das das GUI nicht mit "Gruppen in Gruppen" klar kommt. Es geht aber
immer noch, da das GUI *bemerkt*, wenn versucht wird, eine solche
Gruppe per GUI zu aendern und den Versuch mit einer Fehlermeldung
und dem Verweis auf die Kommandozeile quittiert, statt eine ehemals
funktionierende Konfiguration zu zerstoeren ...

Tschuess,
Juergen Ilse (juergen [at] usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
.

Hallo,

maliwi <lars [at] maliwi.it> wrote:
> meiner erfahrung nach kommen *doch* immer wieder irgendwelche
> anforderungen, die man einbauen muss. bei den ciscobüchsen sind wir
> doch immer wieder ertaunt, welche beschränkungen es da gibt (die dann
> auch der cisco-support nicht beheben kann).

Welche Anforderungen? Ich kenne zwar einige Einschraenkungen bei der
GUI-Konfiguration (anscheinend unterstuetzt das GUI keine "group-objects"
in "group-objects", per Kommandozeile kann man so etwas aber durchaus
konfigurieren ...

>> Bei einer "Eingenbauloesung"
>> wuerde ich definitiv einen hoeheren Wartungsaufwand erwarten.
> nach einiger zeit erfahrung mit Cisco ASA und reichlich erfahrungen
> mit Iptables würde ich sagen: definitiv nicht.

Trotz Erfahrungen mit beidem komme ich zum gegenteiligen Schluss. Fehlt
dir vielleicht Erfahrung mit Cisco PIX und Cisco ASA?

> ganz grob würde ich sagen: für eine lösung a la cisco oder anderen
> musst du erstens trotzdem wissen, was du tust,

Das musst du bei *jeder* Firewallkonfiguration, wenn etwas brauchbares
dabei herauskommen soll.

> zweitens A eine menge geld für das system ausgeben, zweitens B noch
> viel mehr geld, wenn du das ding einrichten und warten *lässt* und
> wirst drittens bei anforderungen an weitere features schnell an die
> grenzen des eingekauften / machbaren geraten.

Welche Grenzen? Nenne doch mal eine Grenze, an die du bereits im
produktiven Betrieb gestossen bist. Was wolltest du konfigurieren,
was mit der ASA nicht ging, mit Linux und iptables aber schon?

> mit den lösungen im OpenSoure-bereich sind wir flexibler bei erheblich
> geringeren anschaffungskosten und vergleichbarer stabilität bzw.
> wartung.

Wie kommst du auf "flexibler"? Die geringeren Anschaffungskosten nehme
ich dir ja vielleicht noch ab, aber den Rest?

> in einem der von mir betreuten netze haben wir aufgrund einer
> entscheidung "von oben" auf eine ASA umgestellt und würdens nicht
> nochmal machen.

Warum nicht? Wo liegen die Probleme?

Tschuess,
Juergen Ilse (juergen [at] usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
.

Hallo,

Bernd Eckenfels <ecki [at] lina.inka.de> wrote:
> Juergen Ilse <ilse [at] usenet-verwaltung.de> wrote:
>> Wie kommst du darauf? Ein erheblicher Teil ist allein schon durch passende
>> Verteilung der security-Levels auf die Interfaces zu erschlagen (Faustregel:
>> ohne weitere Konfiguration geht "vom hohen zum niedrigen Security-Level
>> alles" und "vom niedrigen zum hohen Security-Level nichts"
> Das ist eine beliebte Vereinfachung - aber seien wir doch mal Ehrlich: was
> hat die Richtung des Verbindungsaufbaus mit dem Datenfluss zu tun.

Betrachten wir mal den Fall mit nur zwei Interfaces (inside und outside).
Wenn von inside unerwuenscht Daten nach aussen fliessen, ist der Host von
dem aus die Daten fliessen, vermutlich kompromittiert (mal von "nicht ver-
trauenswuerdigen Benutzern" abgesehen). Wenn du kompromittierte Rechner im
internen Netz hast, hat die Firewall in diesem Netzsegment nichts mehr zu
schuetzen, es ist also *ZU* *SPAET*!

Wenn von inside dagegen nicht unerwuenscht Daten nach aussen fliessen,
ist die Richtung des Verbindungsaufbaus sehr wohl relevant: Wenn man ins
Netz fragt, moechte man die Antworten auch bekommen (sonst wuerde man die
Frage ja nicht stellen). Wenn allerdings jemand "von aussen" nachfragt,
soll er doch bitte schoen (solange man diese Anfrage nicht ausdruecklich
erlaubt hat) doch bitte schoen druassen bleiben ...

> Würmer die Server Ports exploiten sind zwar bekannt und weit verbreitet,
> aber wirklich ärgerlich ist es, wenn man Clients von unrusted Servern aus
> kompromittiert. Daten fliessen nun mal bei TCP in beide Richtungen.

Natuerlich fliessen Daten in beide Richtungen. Deswegen koennen (je nach
Protokoll) transparente Proxies ggfs. manche Exploits abfangen (solche
sind fuer eine Reihevon Protokollen auch in der PIX/ASA implementiert).
Ansonsten hilft da schlicht "keine exploitbare Software auf dem Client
benutzen" oder "Verbindung kappen". Etwas anderes ist ansonsten nicht
wirksam. Von den moeglichen wirksamen Methoden deckt die PIX/ASA mit dem
Konzept der unterschiedlichen Security-Leveln eine ganze Menge relativ
problemlos und ohne allzu viel Aufwand ab. Ein weiterer wichtiger Bereich
wird durch aktuell halten der Software und Verzicht auf bekanntermassen
unsichere Software abgedeckt. Was dann noch an Luecken verbleibt, bekommst
du nicht wirklich mit filtern von Netzwerktraffic in den Griff.

Tschuess,
Juergen Ilse (juergen [at] usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
.