Hallo Jens, At 01.02.2002, Jens Benecke wrote: > On Thu, Jan 31, 2002 at 03:11:44AM +0100, Guido Hennecke wrote: [...] > Wir haben m.E. aneinander vorbei geredet. Also versuchen wir es nochmal... > > Vielmehr ist es aber so, dass Du nichtmal ansatzweise verstanden hast, > > was ich an deiner Smoothwall Empfehlung kritisiert habe. > das klingt sachlich. Guter Anfang. Ich versuchs nochmal. Gut. > Alles, was ich meine, ist daß die "manuelle" Methode oft - nicht immer, > aber oft - viel FÜR DEN FIREWALLBETRIEB unnötiges Wissen vorrausetzt. ipchains -P input REJECT ipchains -P output REJECT ipchains -P forward RJECT ipchains -A bla blubb ipchains -A blubb bla ipchains -A trallalla ipchains -A hupposla ipchains-save > /etc/paketfilter Wenn Du dir die Syntax von ipchains ansiehst, ist das vom Aufwand equivalent dazu, die Smoothwall Doku zu lesen. Also das waere kein Argument dagegen, es manuell mit ipchains zu machen. Auch VI und Shellscripte sind nicht notwendig (wie Du siehst). Mit einem ipchains-restore < /etc/paketfilter steht der Paketfilter wieder. Das muss man dann lediglich in ein Initscript verpacken. Waurm nich in ein vorhandenes? In das Netzwerkscript? Das ist nicht zu viel verlangt und erfordert nicht mehr Aufwand als Smoothwall. Du sagst selbst, die Grundlagen IP muss man drauf haben. Nagut, dann hat meine Methode, dass Du _ganz_ genau weisst, was bei der Konfiguration herraus kommt. Bei irgendeiner Oberflaeche muesstest Du das noch ueberpruefen - was schwieriger ist. Aber das Wichtigste ist, _bevor_ man dieses tut, sollte man (siehe anderen Thread) seine Dienste ordentlich konfiguriert haben (ist auch kein Hexenwerk - sehen wir ja gerade). Ein Paketfilter ist im Idealfall (und der ist auch in der Praxis recht leicht erreichbar) unnoetig (man sollte ihn aber trotzdem haben). Er dient lediglich dazu, die Fehlertolleranz zu erhoehen. Sprich: Ich Admin Joe Pech mache einen Fehler und schwupps, horcht mein Squid auf allen Interfaces und die ACLs sind auch offen. Gut, ich habe meinen Paketfilter, der faengt das erstmal ab. Was mich aber nicht davon befreit, den Fehler schnellstmoeglich zu beheben. > Wozu muss ich wissen, wie man einen Kernel kompiliert, Ich weiss es nicht, ich habe das Thema nicht ins Spiel gebracht. Der Debian Kernel bringt die noetigen Module schon mit. > wie man $EDITOR > bedient, Du wirst mit keinen Unix System auch nur ansatzweise weiter kommen, wenn Du keinen Editor bedienen kannst. Das kann ja auch KEdit sein. Kein Problem. Du kannst auch Wordpad nehmen. > wie man was in /etc konfiguriert, wenn ich - GENAUSO wie mit einem > Skript - über irgendeine Oberfläche ebenfalls jeden einzelnen Dienst und > Port konfigurieren kann? Das Problem ist, dass gerade bei Diensten mehr zum sicheren Betrieb gehoert, als es zu schaffen, dass das Biest irgendwie auf einem Port oder einer IP Adresse horcht. Du kommst also so oder so nicht drumrum, dich mit der eingesetzten Software zu beschaeftigen. Siehe Squid und ACLs oder sonstwas. Die Methode mit der Oberflaeche oder dem Tool hat auch immer den Nachteil, dass Du hinterher ueberpruefen musst, was diese Oberflaeche nun genau gemacht hat und ob das auch ok so ist. Machst Du es selbst, hast Du _verstanden_, was Du warum gemacht hast. Und um das Verstaendnis kommst Du nicht rum (deine Worte). > Ich behaupte, nicht jeder braucht dieses Wissen. Was man braucht, ist > Wissen über Netzwerke und TCP/IP. Das braucht man aber in jedem Fall. Und > genau da greifen Programme wie Checkpoint, Smoothwall & Co ein. Ein Wot zu Checkpoint und Co.. Schau mal in die Bugtrackinlisten. Faellt dir was auf? Du hast ein Tool, von dem Du nicht ueberpruefen kannst, was es wirklich macht und wie es funktioniert und bastelst deine Regeln mit dem Ergebnis, dass ein einziges TCP Paket deine Paketfilterregeln ueberfluessig macht und Checkpoint nur ein Router ist.. Das bringt genau was? > Sie > erlauben eine detaillierte Firewallkonfiguration, mit TCP/IP-Wissen, aber > _ohne_ das ganze "Drumherum". Sie stellen also einen "direkteren" Weg zum > Ziel dar. Und genau das sehe ich anders. Der Weg ist nicht diskret sondern er verschleiert. Und Du musst das Ergebnis genau ueberpruefen - was noch komplizierter ist, als selbst erstellte Regeln zu ueberpruefen. Und von direkter kann keine Rede sein. Du versuchst mit deinen Tools (ist jetzt nich boese gemeint!), die Sicherheit zu erhoehen, indem Du mehr Software einsetzt. Aber mehr Software und erhoehte Komplexitaet steht im krassen Gegensatz zu Sicherheit. KISS. > Was meinst du, warum Firmen wie Juniper oder Cisco so dick sind? Das ist leicht, das erlebe ich taeglich im Job. Diese Firmen verkaufen auf Hochglanzprospekten das gute Gefuehl an inkompetente Admins und Manager. Das ist leider so und ist keine Polemik. Was glaubst Du, warum Microsoft so "dick" ist? Weil sie gute Software verkaufen? Die Cisco Pix "Firewall" hatte seit ihrem bestehen schon derart viele _krasse- Sicherheitsprobleme, dass man nicht alle Tassen im Schrank haben kann, wenn man das Teil noch einsetzt. Dei einzigen Leute, die das immer noch einsetzen sind genau die Leute, die immer noch nicht verstanden haben, dass Stateful Paketfilter nur die Komplexitaet aber nicht die Sicherheit erhoehen. DoS laesst gruessen und hat auch schon oft genug gegruesst. > Weil sie > u.a. solche Lösungen anbieten. Firewalls, bei denen man _nicht_ "erst einen > Lötkurs machen muss". Du uebertreibst und weckst niedrige Gefuehle. Leider ohne Hintergrund. Sie suggerieren, dass man auch als DAU Security schaffen kann und das ist schlicht und ergreifend falsch. > Programme oder Tools, die diese detaillierte Konfiguration _nicht_ erlauben > (oder nicht erfordern) - wie z.B. ZA - sind natürlich i.A. Blödsinn und > u.a. sogar "psychologisch" gefährlich, _KÖNNEN_ aber in den richtigen > Händen auch nützlich sein. > > ACK? Nein, ganz im Gegenteil! Programme wie Cisco Pix, Za, Checkpoint Firewall1 und co setzen die Leute mit den "richtigen Haenden" nicht ein. Und die Leute, die es einsetzen, fallen nicht selten damit auf die Schnautze, weil die Versprechungen in den Werbeprospekten leider nicht stimmen. > > Zweitens will ich _natuerlich_ alles perfekt machen, mir ist aber > > durchaus bewusst, dass das in der Realitaet(tm) nicht immer geht. > Gut! Schau dir mal den anderen angesprochenen Thread an. Meinst Du ernsthaft, dass wir da an einer perfekten Loesung bauen? Bei Weitem nicht. Das ganze ist ein einziger Kompromiss, der aber ueberpruefbar zu einem definierten Ergebnis fuehert, welches derjenige, der seine Systeme so konfiguriert aber eben auch verstehen kann. Und so kann er sich auch weiter bilden und an seiner "Loesung" feilen und sie Steuck fuer Steuck weiter perfektionieren. Aber es ist ein _Anfang_ gemacht, der nicht nur _effektiv_ die Sicherheit erhoeht und genau definierte Bedrohungsszenarien _ausschaltet_ und in diesem Bezug zu hundert Prozentiger Sicherheit fuehrt (achtung! Im Bezug auf _dieses_ Bedrohungsszenario!) _und_ derjenige, der dort mitliest, hat gleich den Startpunkt erstanden, der es ihm ermoeglicht, selbst weiter zu machen, eben weil er _verstanden_ hat, was er da genau macht. > > Einem Newbie, der von IP, Netzwerken und dem System, welches er sich da > > installiert hat, keine Ahnung hat, einfach ein Tool vorzuwerfen, von dem > > der User dann glaubt sein Problem loesen zu koennen, ist eine nicht nur > > Dumme Tat sondern auch eine unverantwortliche. > ACK. Schoen, dass wir da einer Meinung sind. Du hast aber (und das war ja der Ausgangspunkt unseres Disputes) einem solchen Newbie empfohlen, sich doch mal Smoothwall anzusehen und das mal zu benutzen. Ich glaube dir, dass Du das durchaus gut gemeint hast (ich halte dich ja nicht fuer ein fieses Aass!) aber Du musst doch aus deiner jetzigen Sicht zugeben, dass es vielleicht doch keine so gute Idee war und dem Anfaenger nicht unbedingt wirklich und effektiv hilft. > > Das scheint aber deine Definition eines Kompromisses in Sachen IT > > Sicherheit zu sein. "Besser nur 2 Dienste, alle Filesysteme im Internet > > preis geben, als 20". > NACK. Das habe ich nie gesagt. Gut, haben wir das geklaert. Ich hatte das so verstanden. > Ich habe sogar mehrfach betont, dass ich SM daher gut finde, weil es halt > "dicht by default" ist. Standardmäßig läuft da so gut wie gar nichts, nur > das was absolut notwendig ist. Wenn Du mit der Base Installation von Debian fertig bist, gilt ueberigens das Selbe. Also wozu Smoothwall (SM klingt so nach sexuellen Praktiken ;-) )? > Und nach aussen offen ist ebenfalls rein gar > nichts (von ICMP Echo für 'ping', und ich glaube einem "anonymen" identd, > mal abgesehen). Der Ident ist meist schon ueberfluessig und ist er ueberfluessig, ist er ein Sicherheitsrisiko. Bei ICMP ist weit mehr als echo request und echo reply wichtig fuer die einwandfreie Funktion eines IP Netzes. Und ein geschlossener Port ist nicht ein Port, den ein Paketfilter filtert (das ist ein gefilterter Port ;-) ) sondern ein Port, auf dem schlicht und ergreifend kein Dienst horcht. Und das hast Du nach der Base Installation von Debian. > Wenn man über die Web-Gui dann anfängt und Ports öffnet, WebGui? Potentille Angriffsflaeche. Und was heisst, Ports oeffnet? Dienste starten? Oder Filter entfernen und dahinter sind gestartete Dienste? Siehe oben. > kommt ab und an > mal ein Popup "This is a BAD IDEA" und eine Erklärung. Das ist doch Voodoo. Du hast selbst gesagt, dass man auch bei Smoothwall genau ueber IP bescheid wissen muss. Ist es nicht so? Jemand, der genau bescheid weiss, der laesst sich doch nicht von einer dahergelaufenen WebGui erzaehlen, was eine gute Idee ist und was nicht. Der _weiss_ es. Oder redest Du jetzt doch ueber Hilfen fuer Newbies, dies es doch nicht so genau wissen? Bei denen ist es besser, sie fragen hier oder im Usenet oder lesen die Doku um zu _wissen_, worum es geht, als einfach auf solche Voodoo Meldungen zu hoehren und sich sicher zu fuehlen, wenn keine Fenster mehr aufgehen. > (Hab ich allerdings > selbst noch nicht gesehen, sondern mir im IRC sagen lassen.) Naja, nimms mir nicht uebel, aber soooo gut, sacheint es mit deinem KnowHow um Smoothwall dann auch nicht bestellt zu sein. (aber bitte, dass soll kein Angriff sein. Ich habe grossen Respekt davor, dass Du es nochmals sachlich und ernsthaft versuchst!) > Glaubst du ernsthaft, daß ich ein Programm als Firewall empfehlen würde, > was standardmäßig irgendwas kritisches offen hat? Auch bei den sogenannten Personal "Firewalls" ist standardmaessig nicht irgendwas "kritisches" offen. [...] > > Eine perfekte Loesung waere, eine echte Firewall zu errichten. Da Du > > anscheinend nichtmal weisst, was das ist, werde ich es extra fuer dich > > mal kurz anreissen: > Ich bin sicherlich nicht das letzte Wort, was Firewalls angeht, aber ich > behaupte mal einen ausreichenden Überblick darüber zu haben, was einen > Firewall ausmachen _kann_. > > (Erklärung) > Prinzipielles ACK. OK. > > So, Wo muss man da Shellscripte schreiben koennen? Und irgendeinen > > Texteditor wird man doch noch bedienen koennen? > Jep. War ja auch nur ein Beispiel. Das geht weiter: > > Wo pack ich dann das danach hin? -> init-Konzept lernen > Wieso funktioniert das dann beim Booten nicht -> modules-Konzept lernen > Wieso kann ich kein QoS/.../etc. machen? -> module fehlen, Kernel kompilieren lernen Also ich finde deine Beispiele etwas Weltfremd. Du willst QOS machen und weisst nicht, wie man _einen_ Aufruf in ein InitScript packt? Und dass, wo Du einen Unix Router mit Paketfilter adminsitrieren willst? Am Ende noch mit Applikation Level Gateways? Sorry, aber das ist nicht realistisch. Das geht mit keinem Tool. Nicht heute und auch nicht in naher Zukunft. Jedenfalls nicht sicher so wie oben beschrieben. > usw. Dieses Wissen ist, meiner Meinung nach, für den Administrator > lebensnotwendig, aber für einen reinen Firewallbetrieb allerhöchstens > "nice-to-have". Zum "Firewallbetrieb" gehoert das Wissen um das System was drunter liegt. Bleibst Du bei Debian bei Stable, beim Default Kernel und dem Base System, musst Du dich auch nicht um die Module kuemmern. Und Firewalls sind nicht Adminarbeit. Firewalls geht weit darueber hinnaus. Ich wuerde sogar sagen, wer eine Firewall konzeptionieren und umsetzen kann, steckt die meisten Admins in die Tasche. Schon alleine deswegen, weil er ja eigentlich alles was der Admin weiss, schon lange wissen muss, weil das alles fuer den Betrieb und die Konzeption einer Firewall unabdingbar ist. Ich habe etwas Probleme mit deiner Definition der Zielgruppe fuer solche Tools. Du schwankst immer so hin und her zwischen DAU und Superprofi (mit allen Zwischenstufen) je nachdem, wie es zu deinem Argument passt. Das ist irgwendwie anstregend fuer mich. > > Was aber derjenige, der ip Filter (in welcher Form auch immer, also auch > > mit einem Bunti Clicky Interface) auf jeden Fall genau wissen muss, ist > > was er da tut und warum er das tut. Und vor Allem, was das fuer folg.. > Endlich hast du mein Argument mal gefunden! Nichts anderes versuche ich dir > seit ca. einer Woche zu erklären. Du, da waren wir uns seit der ersten Mail einig. Ich weiss auch ueberhaupt nicht, warum Du jetzt diese Zwei Zeilen darunter schreibst. > > > In der Theorie und prinzipiell hast du recht, wie ich schon mehrfach > > > gesagt habe (offensichtlich überliest du das immer, > > Nein, dass ueberlese ich nicht. Was zaehlt ist aber die Praxis und ich > > habe ein ganz egoistisches Interesse daran, dass auch der allerletzte > > Newbie seine Systeme sicher konfiguriert. > Dann sind wir uns ja einig. Eben. > > Ein aufgemachtes System ist fuer _alle_ eine Gefahr, die Systeme im > > Internet betreiben (sollte dir das entgangen sein). Denk nur mal an > > Love-Letter etc. Mich hat Love-Letter selbst nicht gestoert, aber dass > > einige Mailserver _ueberlastet_ waren, dass hat mich auch gekratzt. > Leute, die über von mir kontrollierte Rechner Viren verschicken, können > mind. 1 Woche keine Attachments verschicken, im Wiederholungsfall länger > bzw. werden gleich komplett gesperrt. Das ist mittlerweile sogar > automatisiert. Wenn ich jetzt von einem _ordentlich_ und professionell konfigurierten und adminstrierten System ausgehe, dann muss ich sagen, dass der Admin gelartet gehoert, der es moeglich gemacht hat, dass der User sich I-Love-You eingefangen hat und nicht der User. Ich finde also deinen letzten Satz sehr schlecht und voellig an der Realitaet vorbei. Attachments sind fuer den User zum Anclicken da. Sie haben keinen anderen Zweck und der User nicht das KnowHow, Gutes von Boesem zu unterscheiden. Der User kann auch keine Massnahmen ergreifen, Schaden zu verhindern. Das kann der Admin. Sein Fehler, wenn das n icht passiert ist. > Sind wir uns nun endlich einig? Ich bin nicht sicher. Was meinst Du? Gruss, Guido -- ich sehe doch nirgendwo ein Fenster wo ich die Daten von 1&1 eingeben soll damit ich eine Verbindung bekomme. Wie kann ich jetz online gehen? Angeblich Karte Modem usw ist alles ok aber wo finde ich das Anmeldungsfenster??? <3B0BF610.67AF6612@tu-bs.de>
Attachment:
pgprlShgZQI0H.pgp
Description: PGP signature