[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: welches Modem fuer (T-)DSL



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: pgpjK8SeSDhwk.pgp
Description: PGP signature


Reply to: