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

Re: welches Modem fuer (T-)DSL



On Thu, Jan 31, 2002 at 03:11:44AM +0100, Guido Hennecke wrote:
> At 31.01.2002, Jens Benecke wrote:
> [...]
> > Wenn du nicht verstehen willst, ist das dein Problem.
> 
> Jens, Du winkst sehr schnell mit der "du verstehst nicht" Fahne und
> meinst, Du seist ein Held, weil Du ja ach so kompromissbereit bist.

Hallo Guido,

Wir haben m.E. aneinander vorbei geredet.

> 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.

Alles, was ich meine, ist daß die "manuelle" Methode oft - nicht immer,
aber oft - viel FÜR DEN FIREWALLBETRIEB unnötiges  Wissen vorrausetzt.

Wozu muss ich wissen, wie man einen Kernel kompiliert, wie man $EDITOR
bedient, 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?

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. Sie
erlauben eine detaillierte Firewallkonfiguration, mit TCP/IP-Wissen, aber
_ohne_ das ganze "Drumherum". Sie stellen also einen "direkteren" Weg zum
Ziel dar.

Was meinst du, warum Firmen wie Juniper oder Cisco so dick sind? Weil sie
u.a. solche Lösungen anbieten. Firewalls, bei denen man _nicht_ "erst einen
Lötkurs machen muss".

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?

 
> Zweitens will ich _natuerlich_ alles perfekt machen, mir ist aber
> durchaus bewusst, dass das in der Realitaet(tm) nicht immer geht.

Gut!
 
> 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.
 
> 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. 

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. Und nach aussen offen ist ebenfalls rein gar
nichts (von ICMP Echo für 'ping', und ich glaube einem "anonymen" identd,
mal abgesehen).

Wenn man über die Web-Gui dann anfängt und Ports öffnet, kommt ab und an
mal ein Popup "This is a BAD IDEA" und eine Erklärung. (Hab ich allerdings
selbst noch nicht gesehen, sondern mir im IRC sagen lassen.)

Glaubst du ernsthaft, daß ich ein Programm als Firewall empfehlen würde,
was standardmäßig irgendwas kritisches offen hat?
 
> Und genau das ist Schwachsinn. Ausgemachter Schwachsinn sogar. Dieses
> Niveau liegt noch deutlich unter dem von Microsoft.

ACK.
 
> 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.
 
> 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

usw. Dieses Wissen ist, meiner Meinung nach, für den Administrator
lebensnotwendig, aber für einen reinen Firewallbetrieb allerhöchstens
"nice-to-have".
 
> 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.
 
> > 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.
 
> 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.
 

Sind wir uns nun endlich einig?


-- 
mfg, Jens Benecke 
www.jensbenecke.de, www.hitchhikers.de, www.linuxfaq.de

V: Epson Stylus Color 600, 1440dpi, inkl. 4F+4SW-Patronen
V: 2x IBM 4.3GB UW-SCSI Festplatten, hdparm: 10-13MB/sec

Attachment: pgp6PEmunC2rV.pgp
Description: PGP signature


Reply to: