Hallo Jens,
At 02.02.2002, Jens Benecke wrote:
> On Sat, Feb 02, 2002 at 12:19:28AM +0100, Guido Hennecke wrote:
[...]
> > 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).
> Für uns beide ist das absolut kein Problem. Richtig. Es gibt jedoch Leute,
> die mögen einfach keine Kommandozeile - genauso wie du keine GUI magst.
Das hat mit "moegen" nichts zu tun. Fuer solche Zwecke ist eine GUI eben
voellig ungeeignet. Oder wie automatisierst Du das Erstellen von Regeln,
die Du 30 Mal brauchst, mit nur je einer kleinen Aenderung bei einer
GUI?
> > Das ist nicht zu viel verlangt und erfordert nicht mehr Aufwand als
> > Smoothwall.
> Wenn man
> mit bash umgehen kann,
> sich in der Verzeichnisstruktur auskennt,
> weiss, was /etc ist und wie man darin was macht,
> sich mit dem init-Konzept auskennt,
> die Syntax von ipchains kennt,
> usw.
Das ist Unsinn.
Erstens _musst_ Du dich mit alledem auskennen, wenn Du den Paketfilter
nicht nur mal eben so einsetzt sondern weil Du Sicherheit willst.
Zweitens ist zwingend notwendig nur die Syntax von ipchains (wie ich nun
schon mehrfach beschrieben und auch vorgefuehrt habe).
> ist das völlig richtig. Das ist genau das Wissen, was du implizit
> vorraussetzt, was aber oft nicht vorhanden ist.
Wenn dieses Wissen nicht vorhanden ist, dann hast Du einen Paketfilter
ohne Sinn.
> > 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).
> Oder gleich ein System als Gateway installieren, welches gar keine
> anbietet.
Das Debian Base System.
> > 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
> Ebent. Daher bin ich auch u.U. für den umgekehrten Weg: erstmal per
> ipchains alles dicht machen. Danach kann man sich in aller Ruhe die Dienste
> angucken und richtig konfigurieren. Denn so hat man für kürzere Zeit ein
> angreifbares System.
Das ist ebenfalls absolut suboptimal und am Thema (Sicherheit) vorbei!
Erstens kann so schon ein winziger Fehler dazu fuehren, dass deine
Ueberlegung voll in die Hose geht und zweitens installiert man nicht
einfach ein paar Dienste, packt einen Paketfilter davor (von dem man am
Ende nichtmal wirklich verstanden hat, was er macht) und faengt dann an
sich um seine Dienste zu kuemmern.
Sein wir doch mal ehrlich! Was passiert da wohl?
Tausend Dienste werden installiert, dann ein sinnloser Paketfilter
davorgerotzt und dann der Kumpel darum gebeten, mal "nmap ip"
einzutippen. Man stellt fest, man ist "sicher", weil man munter alle
Pakete droppt (Sabotage!) und das wars dann. Nix mehr mit Konfiguration
der Dienste.
Richtig macht man es genau anders rum. Man haengt den Rechner
idealerweise nicht ans Netz, installiert _einen_ Dienst, konfiguriert
den anstaendig und verfaehrt dann auch so mit den restlichen Diensten.
> Nur eins der beiden machen ist, wie schon erwähnt, gefährlich.
Ich finde deine ganze Herrangehensweise recht gefaehrlich zumindest aber
wirklich leichtsinnig.
> > > wie man $EDITOR bedient,
> > Du wirst mit keinen Unix System auch nur ansatzweise weiter kommen, wenn
> Ich behaupte, man kann auch ein Unix-System so präperieren, daß jemand ohne
> Interna-Kenntnisse damit einen klar abgesteckten Aufgabenkreis erledigen
> kann (z.B. ein Gateway einrichten). Das ist ja das Ziel dieser ganzen
> "ready-to-run" Systeme.
Dann muss die Konzeption und die Grundkonfiguration von einem
sachkundigen Admin gemacht werden. Wo ist der gleich bei deinen $TOOLZ?
> Meine Erfahrung sagt ferner anderes. Ich kenne mittlerweile mindestens zehn
> Leute (klar: User, keine Admins) in meinem Bekanntenkreis, die haben
> absolut keinen Schimmer von Computern (schon gar nicht Unix), können aber
> mit ihrer SuSE umgehen
Kann wohl nicht ganz sein. Du widersprichst dir in einem Satz selbst.
> und arbeiten damit problemlos ihren Bürokram, surfen
> im Netz und schreiben Mails.
Also koennen sie nicht mit SuSE umgehen sondern mit den
_Anwendungsprogrammen_. User eben.
> Sie richten eigenständig ihre TV-Karte und ihr
> T-DSL ein und installieren sich Programme.
Nein, sie clicken auf $BUTTON und mit etwas _magick_ wird das Ganze dann
eingerichtet.
> Und sie haben keine Angst mehr
> beim Öffnen von Mail-Attachments.
Und das ohne, dass sie sich der moeglichen Gefahren bewusst sind? Ja, so
hat man es natuerlich viel leichter und ist auch entspannter ;-)
> Und eins muss man SuSE lassen: Das mit der Sicherheit haben sie
> mittlerweile wenigstens ansatzweise begriffen:
*bruell*
> Leere Passwörter sind nicht,
> und in einer Standard-Clientinstallation läuft ausser portmap und ssh (kein
> root-login) kein Dienst auf einem non-lo Netzwerkdevice.
Na toll. Und daamit haben wir dann ein sicheres System? Das meinst Du
doch nicht etwas ernst, oder? Schau dir nur mal an, wann von SuSE die
Security Announces aufschlagen.
Doch meist erst Wochen nachdem alle Anderen schon die Patches geliefert
haben.
Und SuSE hat das mit "Sicherheit" verstanden meinst Du? Nichtmal
ansatzweise. Die haben das mit den Scheinchen verstanden. Mehr qaber
auch nicht.
> > Du keinen Editor bedienen kannst. Das kann ja auch KEdit sein. Kein
> > Problem. Du kannst auch Wordpad nehmen.
> Ätsch. Wordpad nicht. :-)
> (hint: CR/LF Problem)
Quatsch. man dos2unix, man ftp, man recode.
> > 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.
> Wie gesagt, ich gehe davon aus, daß in Oberfläche ABC (grafisch) genauso
> viele oder wenig Bugs drin sind wie in Oberfläche XYZ (shell-basiert).
Es geht doch nicht darum, dass Du in einer GUI mehr Bugs hast, als bei
einem normalen UI.
Es geht darum, dass Du mit deiner GUI garantiert die Bugs der GUI _und_
der UI hast.
_Und_ Du musst das Ergebis so oder so ueberpruefen. Und jetzt stelle ich
dir die Frage, welches Ergebnis Du leichter ueberpruefen kannst. Eines,
welches Du dir zusammenclickst und das dann $MAGICK erstellt oder
erines, welches Du selbst geschrieben hast?
[...]
> Wenn du absolute Kontrolle wolltest, müsstest du die Kernelparameter direkt
> checken (am besten über /proc/kmem oder sowas). Damit würdest du dann auch
> Anzeigebugs bei iptables -nL umgehen können.
Quatsch. man Realitaet.
[...]
> > 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, w..
> Ich habe nicht gesagt daß das Teil bugfrei ist. Es ist ja kommerziell. :*)
Das Ding ist kaputt.
Ein Paketfilter, den ich mit _einem_ richtigen Paket praktisch
ausschalten kann, ist Schwachsinn. Ein Paketfilter, der sich selbst
DoSt, wenn man ihm das richtige schickt ist auch Schwachsinn. Und damit
faellt Checkpoint, Pix und iptables raus.
> Ferner, wenn du in deinem ipchains-Skript einen Syntaxfehler hast (nur
> einen!) dann gibts beim Start einen "syntax error" und dann bringen dir
> deine Rules genau gar nichts. Genau das gleiche Resultat, im Prinzip.
Ich rede nicht von einem Syntaxfehler sondern von einer suboptimalen
Regel.
[...]
> > 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.
> OK.
Eben.
> Sagen wir so: Eine Oberfläche *kann* eine zusätzliche Abstraktionsschicht
> darstellen.
Sie _stellt_ eine zusaetzliche Abstraktionsschicht da.
> Sie *kann* damit eine zusätzliche Fehlerquelle darstellen.
Sie _stellt_ somit eine potentielle _zusaetzliche_ Fehlerquelle da.
> Sie
> *muss* nicht.
Programme muessen auch keine BufferOverflow Bugs haben. Was bringt mir
diese Aussage? Richtig, nichts.
> Aber *wenn* sie es tut, dann tun Skripte, Makros,
> Konfigurationsdateien und so weiter das auch.
Ist das eigentlich so schwer zu verstehen? Mit mehr Software und mehr
Komplexitaet wird es nicht sicherer sondern _unsicher_.
> Bevor du jetzt noch was sagst, guck dir bitte _wenigstens_ mal die
> Screenshots von Smoothwall's web-GUI an, und sage nicht "brauche ich
> nicht", denn das würde deine Meinung darüber nicht ernsthaft erscheinen
> lassen.
Wieso sollte mich das Aussehen interessieren?
> > 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.
> Nein! Ich möchte bloss unnötige (nur die! nur die unnötige) Komplexität zu
> verstecken, weil die vom Ziel ablenkt.
Du versteckst Komplexitaet hinter _noch_ _mehr_ Komplexitaet. Toll!
> > Aber mehr Software und erhoehte Komplexitaet steht im krassen Gegensatz
> > zu Sicherheit. KISS.
> Dann dürftest du auch keine Skripte schreiben, denn bash ist ein
> Risikofaktor (wer sagt dir, dass da kein Bug in bash ist, der jede 42.
> Zeile in Skripten bei Halbmond nicht ausführt?)
Und das kannst Du nicht nueberpruefen? Sach mal, hast Du eigentlich mal
mit ipchains gearbeitet? So ohne GUI?
> > > 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.
> Aber klar haben diese Firmen eine Marketingabteilung.
Jo, nur keine Technikabteilung.
> > Was glaubst Du, warum Microsoft so "dick" ist? Weil sie gute Software
> > verkaufen?
> Microsoft spielt in dieser Liga nicht mit. Hier geht es nicht um McDonalds,
> sondern eher schon ums BlockHouse (als Vergleich).
Quatsch. MS und Cisco unterscheiden sich doch nur im Namen ihrer
Produkte.
> > 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.
> Please elaborate. Ich sehe deutliche Vorteile in zustandsbehafteten
> Systemen: rate limiting, Reaktion nicht nur auf den momentanen Zustand,
> sondern abhängig von der Geschichte ("der hat mich jetzt drei mal
> portscanned -> IP-block für 10min" oder sowas) usw.
Toll. Ich portscanne dich mit gefaelschter Source IP von T-Online Proxy
und deine Firewall sperrt Tausende von T-Online Kunden aus. Du hast ja
tolle Konzepte.
Du brauchst gar keine BufferOverflows und Bugs in Software, Du
implementierst die mit deinen Konzepten selbst.
Langsam muss ich mich fragen, ob Du nicht das groesste Problem bei einer
Firewall bist.
> > DoS laesst gruessen und hat auch schon oft genug gegruesst.
> Es gibt - meines Wissens - auch keine wirklich sichere Methode FÜR EINE
> MASCHINE, zu erkennen, ob etwas nun ein DoS ist oder einfach nur eine Menge
> Requests darstellt. Menschen "sehen" sowas (u.U.), das ist aber auch oft
> höchst subjektiv.
Doch, je nach DoS gibt es diese. Schau dir mal an, wie beispielsweise
eine SynFlood Atacke aussieht. Davor kannst Du dich nicht schuetzen? Ja
dafuer brauchst Du mit Linux nichtmal einen Paketfilter.
> > > Weil sie u.a. solche Lösungen anbieten. Firewalls, bei denen man
> > > _nicht_ "erst einen Lötkurs machen muss".
> > Sie suggerieren, dass man auch als DAU Security schaffen kann
> > und das ist schlicht und ergreifend falsch.
> Wäre das so, dürften nur KFZ-Mechaniker Auto fahren.
Nein! Nur KFZ Mechainiker duerfen sie _bauen_ und _reparieren_.
Dieser Vergleich, den Du hier bringst, ist so falsch wie abgenutzt.
> Du glaubst gar nicht,
> wie die Mechaniker oft über ihre "doofen" Kunden herziehen - da ist das,
> was in (d)asr abläuft, noch richtig harmlos gegen.
Und oft auch mit Recht. Was beweist das?
Ein KFZ Mechaniker muss nichtmal einen Fuehrerschein haben um seine
Aufgabe 100% zu erfuellen.
> > > 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
> ZA und FW#1 sind meilenweit voneinander entfernt. Wenigstens vom Preis.
Ja und?
> > 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
> Zu dem "Bedrohungsszenarien ausschalten" fällt mir noch etwas ein. Das ist
> das, was _ich_ unter DAU verstehe. Ich habe vor ca. einem Jahr einem Freund
> einen DSL-Router gebaut. Mit Debian. Lief auch alles prima, und er war
> bereit zu lernen, wie das funktioniert. Bis er Netmeeting (oder
> irgendsowas) haben wollte. Das liessen meine ipchains-rules damals nicht
> zu. Ich habe ihm erklärt, welche Ports er noch aufmachen muss bzw. dass er
> das h323-Modul installieren muss.
>
> Ne Woche später bin ich bei ihm gewesen und habe gesehen daß er die
> ipchains-rules einfach alle gelöscht hatte. Es "hat irgendwie nicht
> funktioniert" und "so geht es ja auch". Aber weil Netmeeting irgendwie
> immer noch nicht funktionierte, und weil ein paar Leute aus dem IRC mit ihm
> "direkt" chatten wollten hat er ihnen "kurz mal" einen Telnet-account
> eingerichtet. (deren $HOME hättest du sehen sollen)
>
> Ich habe ihn an die Wand genagelt, mittels /var/lib/dpkg/info/* die md5s
> aller Dateien prüfen lassen und /etc durchsucht (war nix), ipchains wieder
> aktiviert, ihm versucht begreiflich zu machen was er da getrieben hatte und
> bin gegangen. Etwas später war ich wieder da, da lief auf der Kiste
> plötzlich Wingate. Ihm war das alles mit Linux zu kompliziert. Ich habe ihm
> per Google ein paar Exploits für das Gate vorgeführt - "na und, dann
> installier ich das halt schnell neu".
Ich sehe hier zwar ueberhaupt keinen Zusammenhang, aber ich weiss auch
nicht, was Du mir damit _neues_ mitteilen willst.
> Schau, wie du schon richtig sagtest, es ist nicht MEIN sondern UNSER
> Internet. und *solche* Leute sind es, die den Kiddies ihren Lebenssinn
> geben. Da geb ich denen doch lieber irgendein Programm, was eine sinnvolle
> Basis hat (i.e. schon mal kein Windows) und was sie bedienen können,
> anstatt sie mit der vollen Ladung zu konfrontieren und nur zuschauen zu
> können wie sie abprallen.
Beides ist Unsinn. Meinst Du nicht, mit Smoothwall haette dein Bekannter
exakt das Selbe gemacht, weilo sein Netmeeting nicht ging?
Haettest dir lieber die Zeit genommen und ihm das eingerichtet. So mache
ich das in meinem Bekanntenkreis.
Du hingegen meinst, Du gibst ihm $TOOL mit ebenfalls unsinnigem
Ergebnis, $USER fuehlt sich dann sicher und nutzt munter Netmeeting und
dieses vermaledeite Appsharing Tool.
Was bringt ihm da selbst ein richtig konfigurierter Paketfilter?
Richtig, nichts.
> > 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.
> Es gibt leider nun mal Leute, die kommen gar nicht soweit. Obs nun daran
> liegt daß sie einfach dumm sind, oder weil das Interesse nicht da ist oder
> weil sie keine Zeit dafür haben, ist doch egal.
Dann sollen sie das eben von jemandem machen lassen, der sich damit
auskent.
Was meinst Du wuerde ein richter dazu sagen, wenn jemand eine alte Dame
samt Dackel ueber den Haufen faehrt, weil seine Bremsanlage nicht
richtig funktioniert und dieser dann auch noch dummdreist antwortet, er
hat nunmal weder das KnowHow noch die Zeit, das richtig zu machen?
Richtig, der Richter laesst diesen Idioten aus dem Gerichtssaal
entfernen und ruft ihm hinterher "dann finger nicht an Sachen rum, von
denen Du keine Ahnung hast, Du IDIOT!".
Nur bei Computern meint jeder gehirnamputierte Vollitiot, er braucht
keinen Fachmann und das wo Computer in oeffentlichen Netzen um Laengen
komplexer sind als ein Auto.
> Und diese Leute seh ich lieber hinter einem Firewall mit Oberfläche als
> hinter einer Zeitbombe wie Wingate.
Wo ist der Unterschied? Beides sind Zeitbomben. Paketfilter (nicht
Firewall!) helfen bei I-Love-You nicht, helfen bei Netmeeting nicht,
helfen bei kaputter Software im Allgemeinen nicht und (Ueberraschung)
bei Taubenscheisse auf dem Autodach auch nicht.
[...]
> > 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.
> Jep.
> > 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.
> Sagen wir mal so: Wenn ich dem Anfänger zutraue dabei zu bleiben, dann
> kriegt er eine Debian oder was ähnliches und eine Menge Doku und
> Hilfestellungen. wenn ich ihn so einschätze wie den Typen von oben, dann
> kriegt er lieber was halbwegs vernünftiges zum Klicken, bevor er sich
> selber was vollends schwachsinniges installiert.
Dieses Ding zum Clicken, welches Du empfielst (egal wie gut es ist), ist
schwachsinn in diesem Fall. Das kann doch nun wirklich nicht so schwer
zu begreifen sein!
Und anfangs hast Du noch immer zugestimmt, wenn man sagte, dass ein
Paketfilter (egal mit welcher Oberflaeche) Unsinn ist, wenn man nicht
das notwendige Know How hat. Jetzt behauptest Du, es waere auch in den
Haenden eines DAUs sinnvoll.
Und genau das ist eben Schwachsinn.
[...]
> > > 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.
> Hm. Viele mail- und FTP-Server machen ein ident lookup. Ich sehe darin kein
> prinzipielles Problem, solange der keine "echten" Informationen rausrückt.
Es horcht ein DAEOM, dern kann angreifbar sein und meist brauchst Du ihn
nicht. Ich habe noch nie einen Ident Server benoetigt bei meiner
Netzerei. Komisch, oder?
Und das mit "solange der keine "echten" Informationen rausrückt" setzt
dem Schwachsinn noch die Krone auf. Ueberleg mal, wozu ein Identd
nuetzlich ist und _wem_ er eigentlich _was_ sagen soll.
Hint: http://www.fefe.de/docs/ident.txt
> > > Wenn man über die Web-Gui dann anfängt und Ports öffnet,
> > WebGui? Potentille Angriffsflaeche.
> Genauso wie ssh. :)
Ja genau. Deshalb biete ich ihn auch nur dort an, wo es nicht anders
geht, lasse ihn _nicht_ SUID root laufen, lasse keinen root Login zu,
lasse keine Passwortauthentifizierung zu und lasse den Zugriff auch nur
von dort zu, wo ich es unbedingt benoetige.
_MINIMIEREN_ *nicht* /maximieren/.
> > Und was heisst, Ports oeffnet? Dienste starten? Oder Filter entfernen und
> > dahinter sind gestartete Dienste? Siehe oben.
> Beides.
Quatsch!
Ein geschlossener Port ist ein Port an dem kein Dienst lauscht. Punkt
Komma Schluss.
> > > kommt ab und an mal ein Popup "This is a BAD IDEA" und eine Erklärung.
> > Das ist doch Voodoo.
> Nein. Das ist (IMHO) sinnvoll.
Quatsch!
> Ich wüsste bei irgendwelchen kernel logs
> auch gerne mal, was denn nun eigentlich Port 4728 üblicherweise für ein
> Dienst ist und warum da so viele Anfragen kommen.
Wozu? Wenn kein Dienst dort lauscht, kann dir das Banane sein. Was
interessiert es mich, ob da $REMOTESOFTWARE defaultmaessig drauf horcht?
Und was hat das ueberhaupt mit den aufpoppenden Schutzwall Fenstern zu
tun?
> Wo ist jetzt das prinzipielle Problem, wenn ich genau dieses Log sehe,
> bloss in eine HTML-Tabelle formatiert und u.a. die Port-Nummern sind
> anklickbar und es erscheint dann eine kurze Erklärung?
Dein obiges Beispiel macht etwas voellig anderes.
> > Du hast selbst gesagt, dass man auch bei Smoothwall genau ueber IP
> > bescheid wissen muss.
> "Sollte".
Du windest dich wie ein Aal. Du solltest dich besser mal informieren.
Dann waere diese Diskussion auch viel konstruktiver.
> > 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.
> Man lernt nie aus.
Es wird langsam laecherlich!
> Ich halte Hilfen nicht für sinnlos.
Wo schreibe ich, dass ich Hilfen fuer sinnlos halte? Ich halte _dieses_
fensteraufpopp "Achtung! Boese boese und keine gute Idee" Voodoo Zeusch
fuer sinnlos.
> Wer es weiss, wird
> sie nicht brauchen, sie stören aber auch nicht. Wer *DAS* jetzt gerade
> nicht parat hat, der
Natuerlich stoeren sie! Es geht hier um _Sicherheit_. Alles, was man da
nicht unbedingt braucht, _stoert_!
> > Oder redest Du jetzt doch ueber Hilfen fuer Newbies, dies es doch nicht
> > so genau wissen?
> Ich gehe davon aus, daß selbst ein Profi nicht perfekt ist.
Was Du hier beschreibst sind bitterste Grundlagen.
> Und ich gehe
> davon aus, daß sich selbst Profis von dieser mplayer-Mentalität (*)
> abschrecken lassen bzw. beleidigt fühlen.
>
> (*) "Wir machen die Installation absichtlich nicht einfach, denn wer zu
> doof ist sich Makefiles selber zu schreiben, hat sowieso nicht genügend
> Hirn um unser Programm zu benutzen" ->
> http://www.idg.net/ic_780421_1794_9-10000.html
wget "http://www2.mplayerhq.hu/MPlayer/releases/MPlayer-0.60.tar.bz2";
cd /usr/src
tar -xjf /path/to/MPlayer-0.60.tar.bz2
cd MPlayer-0.60
dpkg-buidpackage -b -rfakeroot
su
dpkg -i ../mplayer-xxx_xxx.deb
Bitte?
Und wie immer bei OpenSource, denken viele Entwickler voellig zu Recht
"WFM".
Und wenn es dir nicht passt, mach es selbst!
Aber im schmarotzen und kostenlos gute Software nutzen, in die jemand
anders viel Arbeit gesteckt hat, und _dann_ auch noch oeffentlich
rummaulen, wenn einem daran was nicht passt, ist ja weit verbreitet.
> > > (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.
> Ich habe es ein paar mal installiert und anderen vorgeführt. Selber
> benutzen tu ich es nicht.
Aha.
[...]
> > > > So, Wo muss man da Shellscripte schreiben koennen? Und irgendeinen
> > > 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.
> Wieso? So geht das - manuell.
Ein DAU weiss nichts von QUS. Du musst auch kein Initkonzept lernen, um
in das _vorhandene_ Netzwerk Init Script den Aufruf
"ipchains-restore < script" zu packen. Du musst auch nicht das Modul
Konzept verstehen und DU musst auch keinen Kernel kompilieren.
Wie oft muss man dir das noch schreiben?
Aber es gilt immernoch: Wenn Du das oben beschrieben nicht kannst, ist
deine "Firewall" fluessiger als Wasser.
> > Du willst QOS machen und weisst nicht, wie man _einen_ Aufruf in ein
> > InitScript packt?
> "Du willst Autofahren können und weiss nicht, wie man einen Zylinder
> austauscht?"
Dieses Beispiel kotzt mich dermasen an, das kannst Du dir nicht
vorstellen. Warum Du staendig Admin/Mechaniker und User/Fahere
durcheinander wuerfelst, ist mir auch nicht klar. Kannst Du am Ende
weder Auto fahren noch reparieren?
> Muss ein Autofahrer IMHO auch nicht.
Ja EBEN!
> > Sorry, aber das ist nicht realistisch. Das geht mit keinem Tool.
> Wie wärs denn mit
> [X] Enable QoS
Und den boesen boesen Kernel neu uebersetzen? Lilo lernen, C lernen,
Compiler lernen, Editor lernen... (deine Worte).
> ? Wo ist jetzt da faktisch der Unterschied zu dem Init-Skript Geraffel, bis
> auf das meine Lösung um Längen einfacher ist?
Deine "Loesung" ist DAUTUM.
[...]
> > Wenn ich jetzt von einem _ordentlich_ und professionell konfigurierten
> > und adminstrierten System ausgehe,
> Reicht es zu sagen, dass _dieses_ spezielle Beispiel ein Studenten-LAN ist,
> wir Studentenwerk dafür zwar viel Lob, aber keinen ¢ kriegen, trotzdem
> unser bestes tun, "nebenbei" noch an Diplomarbeiten etc. werkeln, und seit
> ca drei Monaten ein komplettes Redesign vorhaben (u.a. aus DEN Gründen)?
Nein.
> Ich administriere auch noch andere Netze, wo ich mehr Zeit und Aufwand
> reinstecke, dafür aber auch mehr kriege.
Das rechtfertigt immer noch nicht, den User fuer ertwas verantwortlich
zu machen, an dem der Admin alleine Schuld ist.
> > 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.
> Admin. :-)
Ja Admin.
> Ich darf User-Mail ohne Anlass nicht anfassen ("Befehl von oben"), wegen
> Privatsphäre.
Das ist auch richtig so!
> Und ein von oben akzeptierter Anlass ist "Gefährdung des
> Netzwerkes". Daher: Sperre nur, wie sagt man, postmortem.
>
> Auch das ändert sich hoffentlich bald.
Es gehoert nichts gesperrt. Auch das ist nicht schwer zu verstehen.
> > Ich finde also deinen letzten Satz sehr schlecht und voellig an der
> > Realitaet vorbei. Attachments sind fuer den User zum Anclicken da.
> Können sie machen. Wenn sie was anklicken ohne zu denken, haben sie aber
> auch die Konsequenzen zu tragen.
Dann erklaere Du, oh grosser Security Meister, mir einfachem DAU doch
mal, wie ich ein gutes(tm) von einem boesen(tm) Attachment unterscheiden
kann.
> Ich hätte jetzt eigentlich gedacht, du erwartest von den Usern eine
> Mindestmasse Hirn, weil du ja auch sonst so viel Wert darauf legst, daß
> jeder das volle Programm lernt, der irgendwas benutzen will.
Du kannst von einem User _nichts_ _erwarten_. Du kannst nur hoffen.
> Jemand der nicht wissen will wie man richtig mit Attachments umgeht und was
> die Gefahren dabei sind, soll gefälligst einen Mailclient benutzen, der
> keine Attachments verarbeiten kann.
Siehe oben. Wie siehst Du den Unterschied?
> > 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.
> man virenscanner
Quatsch. Womit wir bei der naechsten urban legend sind "Virenscanner
schuetzen vor Viren".
Wenn dem wirklich so waere, wie kann es dann sein, dass wir staendig
diese Horrormeldungen ertragen muessen, auch von Usern, die einen
_aktuellen_ Virenscanner haben?
Wie unterscheidet ein Virenscanner ein boeses Script:
#!/bin/bash
rm -r ./*
von einem guten Script:
#!/bin/bash
rm /tmp/*~
Na? Und genau dieses Problem hast Du bei jedem Script. Ob das VBS oder
Bash ist, spielt keine Rolle. Fuer Wordmakros etc. gilt das Selbe.
Virenscanner sind Snakeoil.
> man hirn
Kannst Du nicht erwarten.
> man logisches_denkvermoegen
> man warn_mails_von_den_admins
Alles Papperlapapp.
man rubustes_system
man backupkonzept
man rechtekonzept
> > Das kann der Admin. Sein Fehler, wenn das n icht passiert ist.
> Admins sind oft "Hauspersonal". Bessere Hausmeister. Kriegen von den Usern
> aufn Deckel wenn was nicht funktioniert, vom Management wenn die User Viren
> verbreiten, können selber kaum Entscheidungen treffen und haben aber immer
> Schuld, egal ob berechtigt oder nicht.
Ja und? Was aendert das?
[...]
> > > Sind wir uns nun endlich einig?
> > Ich bin nicht sicher. Was meinst Du?
> Hm. Du meinst, jeder muss zum Profi werden.
Nein. Und ich bezweifle langsam, dass Du in der Lage bist, einfach
Zusammenhaenge zu verstehen. Sorry.
> Ich habe Angst, daß viele, die
> man zum Profi trainieren will, abrutschen und sich danach noch mehr Schaden
> zufügen, als wenn man sie nur zum Amateur gebracht hätte.
Und mich kotzt es an, dass auch Leute, die es besser wissen muessten,
immer noch meinen, dass ein Idiot mit einem Tool kein Idiot mehr sei.
> Was ist besser? Kommt auf die Zielgruppe an.
Besser ist _immer_ es von jemandem machen zu lassen, der sich damit
auskennt.
man schadenersatzklage
> > 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>
> ;) Und warum sollte man ihm denn kein Fenster geben?
*seufts*
Ich weiss nicht, ob es Sinn macht, diese Diskussion mit dir weiter zu
fuehren.
Nimm es mir nicht uebel, aber dir fehlen wirklich Grundlagen.
Gruss, Guido
--
I like BOTH kinds of music.
Attachment:
pgp1gJn787ONt.pgp
Description: PGP signature