On Tuesday 02 January 2001 15:12, Frank Becker wrote:
Konrad Rosenbaum (konrad.rosenbaum@gmx.net) schrieb auf LUG-DD
am Die, 02 Jan, 2001; 07:54 +0100:
On Monday 01 January 2001 18:18, Frank Becker wrote:
Ich kenne Leute, die squid oder wwwoffle auf z. B. einem Linux-Kernel als sicheren Proxy auf Anwendungsebene halten. Solch ein Proxy sollte aber einen eigenen TCP/IP Stack haben. Sonst stimme ich Dir mit dem Meeresgrund zu.
Das ist aus der Sicht eines Programmierers grosser Schrott: je mehr ein
Hier stimme ich nicht voll mit Dir überein. Für sehr viele Fälle ist das auch IMHO richtig. Wenn sich allerdings die Anforderungen an eine S/W ändern, so muss das nicht immer so sein. Bitte korrigier(e|t) mich, wenn folgendes völliger Quatsch ist:
Du hast also einen Linux 2.2.X Router mit z. B. squid aktiv. Jetzt Knipst jemand den squid durch einen DoS oder was auch immer aus.
Knippst ihn aus(1) oder läßt ihn für sich arbeiten(2)?
Frage: Was macht der Kernel? Routed er dann die IP Pakete (auch gespooft) nach (innen|außen) oder nicht?
(Ich habe das noch nicht in Gänze getestet, also ist das hier nur das Verhalten wie ich es bisher vom Linux-Kern kenne.)
(alle)gespoofte Pakete werden zum größten Teil sowieso schon herausgefiltert: über REJECT oder DENY Regeln bzw. "martian-detect", normalerweise gehört an den Anfang der input-queue (bei IPChains, bzw. alle 3 queues bei IP-Tables) für jede Netzwerkkarte eine Regel, die alle Pakete ausfiltert, die gar nicht von dieser Karte kommen können (Bsp. Pentacon-Gateway alice: DENY auf 198.168.0.0/16 via ippp0 und umgekehrt: ! 198.168.0.0/16 via eth0). Der Rest ist also eindeutig Internet oder eindeutig User (auch "bösartige").
(1)Die Pakete, die auf dem Proxy ankommen werden mit "Rst" (entspricht Regel REJECT) beantwortet, da auf dem Proxy-Port niemand mehr antwortet. Es kommen keine Verbindungen mehr zu stande. DoS war erfolgreich, aber das war es auch.
(2)Hier wird klar wozu man die 2. Firewall braucht: der Angreifer ist jetzt in der Lage die DMZ zu erforschen und weiter anzugreifen, ausserdem kann der den Proxy-Rechner komplett umkonfigurieren (vorrausgesetzt der Hack hat ihm genug Privilegien gebracht). Der größte Schaden, der angerichtet werden kann ist: er kann detaillierte Persönlichkeitsprofile der User erstellen, indem er die Logs auswertet. Wenn weitere Rechner in der DMZ stehen sind diese jetzt in Gefahr, da zwischen ihnen und dem Proxy keine weiteren Firewalls stehen (so z.B. i.A. der externe Webserver des Unternehmens).
Nachteil eines eigenen TCP/IP Stacks: der Proxy muss (teilweise) mit root-Rechten laufen in Fall 2 hat man also sofort das System unter Kontrolle. Ohne eigenen Stack kann der Proxy nach der Initialisierung (falls ein Port < 1024 gebraucht wird, sonst sofort) auf einen normalen User umschalten.
Da Du eine grosse Fa. angesprochen hast, halte ich auch einen einfachen Paketfilter für nicht wünschenswert. Es kommt natürlich immer darauf an...
Naja, IPTables soll schon einiges mehr an stateful-filtering mitbringen, was da sehr nützlich sein kann...
Schon Erfahrungen gesammelt, oder eine Quelle bekannt?
Es gibt da einiges an Doku dazu. Mal sehen, wann ich Zeit habe.
stammen ca. 80 % aller Angriffe von Innen.
Das ist dann eine Frage der Passworte und der internen security-Policy (Zugriffsrechte, Logs, Privilegien, etc.).
Auch wenn das sehr simpel klingt, stimme ich Dir unter Beachtung des "etc." zu. Ausser vielleicht, ein Mitarbeiter hält sich nicht dran...
Moment mal: Policy wird nicht mit "ein Stapel Zettel, die man zum Monitor aufbocken nimmt" übersetzt (das sind Org-Anweisungen). Eine Policy ist u.a. ein technischer und/oder organisatorischer Schutz, der (für normale User) nur schwer überwunden werden kann. Z.B. Zugriffsrechte: man muss schon das interne Netz cracken um diese Rechte zu überwinden (ich glaube CODA lößt dieses Problem - kennt sich da jemand aus?). Oder sichere Passworte: Prüfung bei der Eingabe, indem man in den PAM-Einstellungen von passwd cracklib einklinkt. Usw. Eventuell wird auch noch ein zusätzlicher Firewall vor jedes System geschaltet, dass von einer Forschungsgruppe genutzt wird (damit nur die Projektdaten sehen können, die das auch dürfen, selbst wenn sie cracken).
Konrad