Discussion:
Verträglichkeit SQL-Server - Virenscanner
(zu alt für eine Antwort)
Gunter Scholtz
2003-08-13 13:18:24 UTC
Permalink
Hallo,

ich habe eine Frage zur Installation von Virenscannern auf MS SQL-Server2000
SP3 auf einem Windows2000 Server SP3.

Unsere Systemadministration installiert auf allen W2K-Servern das
Antivirusprogramm "NAI Virus Scan Enterprise 7.0.0" und den "Epo-Agent
3.1.0.211".

Ich wollte Fragen, ob mir jemand vielleicht sagen kann, ob es bei dieser
Software Probleme mit dem SQL-Server gibt, bzw. was für Einstellungen
vorgenommen werden müssen.

Und ist es überhaupt sinnvoll mdf- und ldf-Dateien auf Viren zu scannen?

Für eine Antwort oder einen Rat wäre ich dankbar.

Grüße,
Gunter Scholtz
Guido Stepken
2003-08-16 18:02:01 UTC
Permalink
Hallo, Olaf !

Die Tendenz, alle Daten im SQL Server zu speichern ist offensichtlich.
Insbesondere, wenn man die äußerst schnelle Fulltext Suche verwendet,
die MySQL, PostgreSQL und SQL Server 2000 mit SP2+ unterstützt.

Oft kann man nicht genau sagen, über welche Wege die Dateien in die
Datenbank gekommen sind, von einer Workstation, via Upload im Browser,
also den IIS, oder via ACCESS, Excel, OpenOffice ...
Virenscanner auf den Workstations sind oft nicht aktuell, und - laut
Tests in c't und iX werden nach 3 Monaten ca. 30% der Signaturen wieder
herausgenommen und nach 6 Monaten werden nur noch 60& aller Viren
erkannt. Virenscanner auf WS sind also ein Minimum, jedoch auch nicht
sicher.
Viren sind oft gezippt. Wenn ich z.B. eine Datei erzeuge, die 1 Gbyte
groß ist und hinten einen Melissa - Virus anhänge, diese dann mit BZIP2
(LINUX) komprimiere, dann kommt eine Datei heraus, die ca. 1400 Byte
groß ist. (dd if=/dev/zero of=/test bs=1024 count=1000000; cat < virus
/test; bzip2 /test)
Wenn ich davon einige dutzend via Mail in ein Netzwerk sende (Größe
immer halbieren), dann ist irgendwann die Firewall zu, oder der
Fileserver völlig überlastet.

Virenscanner ist also weder ein Schutz, noch kann man etwas verhindern
damit, wie lovesan gezeigt hat.
Man sollte einfach alles abschalten, was Microsoft so an Makro's
eingebaut hat, und einmal täglich nach Viren alles durchforsten, damit
der Sorgfaltpricht genüge getan ist, IMHO.

Dank Linux hatte ich noch nie einen Virus, wohl aber einige Trojaner auf
Fileservern im Internet, die auch nur eindringen konnten, weil die
Updates nicht eingespielt waren. Linux hat keine Ausbreitungsmechanismen
für Viren....heheeeee.

Gru/3, Guido Stepken
Olaf Pietsch
2003-08-17 10:18:22 UTC
Permalink
Hallo Guido,
Post by Guido Stepken
Hallo, Olaf !
Die Tendenz, alle Daten im SQL Server zu speichern ist offensichtlich.
Insbesondere, wenn man die äußerst schnelle Fulltext Suche verwendet,
die MySQL, PostgreSQL und SQL Server 2000 mit SP2+ unterstützt.
Oft kann man nicht genau sagen, über welche Wege die Dateien in die
Datenbank gekommen sind, von einer Workstation, via Upload im Browser,
also den IIS, oder via ACCESS, Excel, OpenOffice ...
Virenscanner auf den Workstations sind oft nicht aktuell, und - laut
Tests in c't und iX werden nach 3 Monaten ca. 30% der Signaturen wieder
herausgenommen und nach 6 Monaten werden nur noch 60& aller Viren
erkannt. Virenscanner auf WS sind also ein Minimum, jedoch auch nicht
sicher.
Viren sind oft gezippt. Wenn ich z.B. eine Datei erzeuge, die 1 Gbyte
groß ist und hinten einen Melissa - Virus anhänge, diese dann mit BZIP2
(LINUX) komprimiere, dann kommt eine Datei heraus, die ca. 1400 Byte
groß ist. (dd if=/dev/zero of=/test bs=1024 count=1000000; cat < virus
/test; bzip2 /test)
Wenn ich davon einige dutzend via Mail in ein Netzwerk sende (Größe
immer halbieren), dann ist irgendwann die Firewall zu, oder der
Fileserver völlig überlastet.
Virenscanner ist also weder ein Schutz, noch kann man etwas verhindern
damit, wie lovesan gezeigt hat.
Man sollte einfach alles abschalten, was Microsoft so an Makro's
eingebaut hat, und einmal täglich nach Viren alles durchforsten, damit
der Sorgfaltpricht genüge getan ist, IMHO.
Dank Linux hatte ich noch nie einen Virus, wohl aber einige Trojaner auf
Fileservern im Internet, die auch nur eindringen konnten, weil die
Updates nicht eingespielt waren. Linux hat keine Ausbreitungsmechanismen
für Viren....heheeeee.
Gru/3, Guido Stepken
so ganz verstehe ich Dich nicht, was Du mir mit Deiner Antwort auf meinen
Beitrag sagen möchtest (?).

Wie Daten in eine Datenbank gelangt sind, wird man im allgemeinen nicht
sagen können. (Der Client könnte auch ein Bügeleisen mit ODBC-Schnittstelle
gewesen sein.) Bei Anwendung einer Application Role sähe das dann allerdings
etwas besser aus, dann könnte man eher auf den Client zurückschließen.

Eine Uploadmöglichkeit von Dateien auf einen Server ist grundsätzlich immer
ein Problem hinsichtlich der Sicherheit vor eingeschleppten Viren. Wer den
Uploadvorgang nicht mit einen Virenscanner oder eine Viruswall überwacht,
ist aus meiner Sicht mutig ;-).

Wer schreibt denn vor, dass man Datei-Uploads in einer SQL-Serverdatenbank
als Blobs speichern muss? Man kann diese doch auch im NT-Filesystem ablegen
und da kommt der Virenscanner auf dem Server leicht heran.

Aus meiner Sicht sollte man sich nicht ausschließlich auf den Schutz durch
Virenscannern verlassen, es sind immer übergeifende Sicherheitskonzepte
notwendig, wie z. B. Einsatz von Routern, Firewalls, Viruswalls,
Virenscanner usw.

Sicherheitslücken gibt es nicht nur in der Microsoft Welt, Beispiel vom Okt.
2002 ...

<Zitat>
Post by Guido Stepken
Das CERT Stuttgart warnt vor Sicherheitslücken in aktuellen
Kernel-Versionen von Linux, durch die lokale Nutzer Root-Rechte
erlangen können. Betroffen sind laut CERT alle Kernel vor den
Versionen 2.2.22 und 2.4.20.
Laut CERT wurden im Kernel 2.4.19 stillschweigend einige dieser Fehler
behoben, dennoch sei für diesen Kernel noch ein zusätzlicher Patch
erforderlich, der in der Datei kernel-2.4.19-sec bei The Free World's
Information and Software Repository erhältlich ist. Zu der
ungewöhnlichen Vorgehensweise über freeworld.net merkt das CERT an,
dass auf Grund der Problematik mit dem US-Copyright-Gesetz DMCA
"US-Amerikanern Details zu diesen Schwachstellen offenbar nicht
zugänglich gemacht werden können"; daher seien auch "öffentlich
verfügbare Details etwas rar".
Neben der Möglichkeit, lokal Root-Rechte zu erlangen, seien auch
Denial-of-Service-Angriffe und das Auslesen des /proc-Verzeichnisses
möglich. Das CERT Stuttgart empfiehlt in einem Advisory, das System
auf Kernel 2.2.22 beziehungsweise 2.4.20 zu aktualisieren. Vom Kernel
2.4.20 gibt es bislang auf dem Linux-Kernel-Archiv allerdings bislang
lediglich die Version pre11. Dazu merkt das CERT, ebenfalls unter
Bezugnahme auf den DMCA, an: "Da die stillschweigende Korrektur und
verzögerte Bekanntgabe von Sicherheitsproblemen in Linux mittlerweile
regelmäßig vorkommt, sollte versucht werden, möglichst aktuelle
Kernel-Versionen zu verwenden, auch wenn dies natürlich mit Risiken
für den Produktionsbetrieb verbunden ist." Ein ähnlich
stillschweigendes Vorgehen brachte übrigens Microsoft schon heftige
Kritik ein.
Inwiefern künftig jemand für die Weiterentwicklung der Software oder
Behebung von Sicherheitslücken bei Linux in die Verantwortung genommen
werden kann, ist nicht überschaubar, wenn überhaupt beantwortbar.
Einer der großen Nachteile dieses kostenlosen Betriebssystems.
--
Thomas K.H. Bittner
Senior Consultant, Online GmbH
Microsoft Servers und Windows 2000 MVP
Microsoft Windows 2000 Certified Professional
</Zitat>

Gruß Olaf
Guido Stepken
2003-08-17 10:45:36 UTC
Permalink
Hallo, Olaf !

Oh, da stimme ich Dir zu, man muß Daten nicht in Blobs speichern. Aber,
wenn Du es nicht tust, dann ergeben sich schnell Probleme, weil die
Links in der SQL Datenbank immer auf die richtige Stelle auf dem
Filesystem zeigen müssen. Ich brauche dann sowas wie einen verifier oder
link-checker, oder sogar indexer.

Naja, das Problem mit dem zentralen Virenscanner und DoS (Denial of
Servce = Stillegen) habe ich ja geschildert.

Das Beispiel von K.H. Bittner finde ich ganz witzig. Nach meinem
Verständnis hat er nicht von Viren geredet, sondern von einem
Zugriffsproblem auf /proc, welches ein Abbild der Kernel - Parameter in
dem Filesystem zur Laufzeit darstellt. PROC erlaubt es, durch einfaches
hineinschieben von Daten in die 0 Byte großen Dateien (ähnlich Pipes ,
so kann man sich das vorstellen) den Kernel wärend der Laufzeit zu
manipulieren echo "100000" > /proc/sys/fs/file-max erhöht die Zahl der
maximal gleichzeitig offenen Files auf 100.000. Diese Probleme waren da,
das ist korrekt, die sind aber seit OpenWall Patches und GRSecurity
(siehe http://www.freshmeat.net) nicht mehr da. Leider ist SuSE so doof,
und implementiert es nicht.

Und zu der Haftungsunsicherheit bei Linux. Wer sich die EULA
durchgelesen hat, weiß, daß Microsoft auch nicht haftet, für garnix.
Microsoft maßt sich sogar an, seit XP den Usern verbieten zu wollen, GNU
Software auf XP zu installieren, und hat diese Änderung der EULA sogar
recht versteckt über die Servicepacks untergeschoben.
Herr Gates hat außerdem in einem Interview gesagt, daß noch nie in der
Geschichte Software releases oder Updates wegen Fehlern verkauft wurden,
sondern immer nur wegen neuen Features, auf die die Leute heiß waren.
Die Philosophie von MS ist halt so, die wollen in allen Zeitungen im
Gespräch bleiben, über perfekte Software redet niemand und regt sich
auch keiner auf, wie man bei Digital UNIX, NOVELL, IRIX, u.s.w. bemerken
konnte. Da sind die Admins schon in Rente, und keiner merkt es....;-))

Die Microsoft Businness Leute machen hier Propaganda, leider alles
falsch. Ich habe jedenfalls noch nie einen Virenscanner für Linux
gebraucht, wohl aber Sicherheitskorrekturen und Updates. Dank apt-get
für Redhat, Debian und SuSE inzwischen wohl auch, habe ich immer
kostenlose Updates, jede Stunde holt der sich die automatisch. Seit dem
habe ich keine Probleme mehr mit Linux, Hackern, Trojanern, u.s.w.

Gru/3, Guido Stepken
Post by Guido Stepken
Inwiefern künftig jemand für die Weiterentwicklung der Software oder
Behebung von Sicherheitslücken bei Linux in die Verantwortung genommen
werden kann, ist nicht überschaubar, wenn überhaupt beantwortbar.
Einer der großen Nachteile dieses kostenlosen Betriebssystems.
--
Thomas K.H. Bittner
Senior Consultant, Online GmbH
Microsoft Servers und Windows 2000 MVP
Microsoft Windows 2000 Certified Professional
Olaf Pietsch
2003-08-17 13:48:08 UTC
Permalink
Hallo Guido,
Post by Guido Stepken
Hallo, Olaf !
Oh, da stimme ich Dir zu, man muß Daten nicht in Blobs speichern.
Aber, wenn Du es nicht tust, dann ergeben sich schnell Probleme, weil
die Links in der SQL Datenbank immer auf die richtige Stelle auf dem
Filesystem zeigen müssen. Ich brauche dann sowas wie einen verifier
oder link-checker, oder sogar indexer.
Naja, das Problem mit dem zentralen Virenscanner und DoS (Denial of
Servce = Stillegen) habe ich ja geschildert.
Das Beispiel von K.H. Bittner finde ich ganz witzig. Nach meinem
Verständnis hat er nicht von Viren geredet, sondern von einem
Zugriffsproblem auf /proc, welches ein Abbild der Kernel - Parameter
in dem Filesystem zur Laufzeit darstellt. PROC erlaubt es, durch
einfaches hineinschieben von Daten in die 0 Byte großen Dateien
(ähnlich Pipes , so kann man sich das vorstellen) den Kernel wärend
der Laufzeit zu manipulieren echo "100000" > /proc/sys/fs/file-max
erhöht die Zahl der maximal gleichzeitig offenen Files auf 100.000.
Diese Probleme waren da, das ist korrekt, die sind aber seit OpenWall
Patches und GRSecurity (siehe http://www.freshmeat.net) nicht mehr
da. Leider ist SuSE so doof, und implementiert es nicht.
Und zu der Haftungsunsicherheit bei Linux. Wer sich die EULA
durchgelesen hat, weiß, daß Microsoft auch nicht haftet, für garnix.
Microsoft maßt sich sogar an, seit XP den Usern verbieten zu wollen,
GNU Software auf XP zu installieren, und hat diese Änderung der EULA
sogar recht versteckt über die Servicepacks untergeschoben.
Herr Gates hat außerdem in einem Interview gesagt, daß noch nie in der
Geschichte Software releases oder Updates wegen Fehlern verkauft
wurden, sondern immer nur wegen neuen Features, auf die die Leute
heiß waren. Die Philosophie von MS ist halt so, die wollen in allen
Zeitungen im Gespräch bleiben, über perfekte Software redet niemand
und regt sich auch keiner auf, wie man bei Digital UNIX, NOVELL,
IRIX, u.s.w. bemerken konnte. Da sind die Admins schon in Rente, und
keiner merkt es....;-))
Die Microsoft Businness Leute machen hier Propaganda, leider alles
falsch. Ich habe jedenfalls noch nie einen Virenscanner für Linux
gebraucht, wohl aber Sicherheitskorrekturen und Updates. Dank apt-get
für Redhat, Debian und SuSE inzwischen wohl auch, habe ich immer
kostenlose Updates, jede Stunde holt der sich die automatisch. Seit
dem habe ich keine Probleme mehr mit Linux, Hackern, Trojanern, u.s.w.
wenn man solche Fragen diskutiert, dann sollte man m. E. nicht
ausschließlich schwarz weiß malen. Denn es gibt noch einen ganz anderen
Faktor, das sind m. E. wir, die Anwendungsentwickler.

Ich kann mich bei Unix daran erinnern, dass für die Entwicklung nur 777 im
Filesystem verwendet und dagegen getestet wurde. Schließlich ist der
Administrator später beim Betrieb der Anwendung für die
Sicherheitseinstellungen zuständig. Nur das ist nicht immer gut gegangen.

Ein ganz anderes Beispiel, ich musste vor kurzem in einem Unternehmen mit
vielen hundert Usern eine Lösung mit einführen, die auf einer
zweischichtigen C/S-Lösung beruhte, fat Client mit lokaler MSDE und Merge
Replikation zu einem zentralen Datenbankserver. Die erste Diskussion mit dem
Entwickler der Lösung ergab sich, wieso SP3 für die MSDE nicht installiert
werden sollte. Dann stellte sich heraus, dass die MSDE mit mixed security
betrieben werden musste. Und siehe da, die Anwendung griff auf die Datenbank
per sa zu. Nur leider durfte anfangs der sa kein Passwort haben, weil die
Anwendung das Passwort nicht an die MSDE richtig übergab. Weiterhin waren
die User als SQL-Server Login eingerichtet und hatten volle
Datenänderungsberechtigung auf den Tabellen. Die User mit Access hatten sich
gefreut und konnten ungeschützt auf dem Datenbestand rum hacken. Das ist
dieses Jahr passiert! Die Anwendung wurde schließlich nicht eingesetzt.

Heute sollte man aus meiner Sicht doch wirklich mehr Sicherheitsbewußtsein
auch von den Anwendungsentwicklern erwarten. Was nutzen da
Sicherheitsfeatures, die von den Herstellern ersonnen werden und einfach
nicht beachtet oder implementiert werden.

SQL-Injektion ist aus meiner Sicht ein weiter Problemkreis innerhalb der
Anwendungsentwicklung, der nach meiner Einschätzung vom Betriebssystem und
dem verwendeten Datenbanksystem unabhängig ist.

Es kann aber auch nicht die Lösung sein, jede "Woche" einen neuen
Security-Patch herauszugeben. Die Adminstratoren schaffen es in Unternehmen
einfach nicht, die Patches zeitnah auszurollen. Das liegt nicht daran, das
dieses nicht technisch durchführbar wäre, sondern die Patches müssen erst
gegen die vorhandenen Anwendungen auf Verträglichkeit getestet werden. Das
kostet Zeit. Und bei manchen Patch haben wir schon gestaunt, was alles nicht
mehr geht. (Das lag nicht immer am Patch sondern auch schon mal an der
Anwendung.) Ich habe auch Administratoren erlebt, die sich für solche Fragen
überhaupt nicht interessieren.

Haftungsfragen zu diskutieren überlasse ich den dafür ausgebildeten
Juristen.

Bzgl. der der Speicherung von Dokumenten aussserhalb der SQL-Datenbank ist
nicht so problematisch, wie Du es darstellst, solange der User keinen
direkten Zugriff auf die Files hat. (Dann können Dokumente nicht so einfach
verschwinden.) Die Datensicherung muss auch gut geplant werden. Du hast aber
damit vollkommen recht, es sind 2 Storages vorhanden, die nichts voneinander
wissen - alles hat so seine Vor- und Nachteile.

Gruß Olaf
Guido Stepken
2003-08-17 17:05:22 UTC
Permalink
Hallo, Olaf !

Ich bin erschüttert. SQL Server auf jedem Desktop, die mit einem
zentralen SQL Server mit merge-replikation synchronisieren. Könnte es
sein, der Schwachsinn bei MS Developern langsam überhand nimmt ? Die
Administrationskosten und Lizenzgebühren sind ja horrend. Woran lag es,
daß diese Lösung gewählt wurde ? Doch nicht an den
Lock/Transaktionsproblemen, ober die ich vor Kurzem geschrieben habe ?

Gru/3, Guido Stepken
Post by Olaf Pietsch
Ich kann mich bei Unix daran erinnern, dass für die Entwicklung nur 777 im
Filesystem verwendet und dagegen getestet wurde. Schließlich ist der
Administrator später beim Betrieb der Anwendung für die
Sicherheitseinstellungen zuständig. Nur das ist nicht immer gut gegangen.
Ein ganz anderes Beispiel, ich musste vor kurzem in einem Unternehmen mit
vielen hundert Usern eine Lösung mit einführen, die auf einer
zweischichtigen C/S-Lösung beruhte, fat Client mit lokaler MSDE und Merge
Replikation zu einem zentralen Datenbankserver. Die erste Diskussion mit dem
Entwickler der Lösung ergab sich, wieso SP3 für die MSDE nicht installiert
werden sollte. Dann stellte sich heraus, dass die MSDE mit mixed security
betrieben werden musste. Und siehe da, die Anwendung griff auf die Datenbank
per sa zu. Nur leider durfte anfangs der sa kein Passwort haben, weil die
Anwendung das Passwort nicht an die MSDE richtig übergab. Weiterhin waren
die User als SQL-Server Login eingerichtet und hatten volle
Datenänderungsberechtigung auf den Tabellen. Die User mit Access hatten sich
gefreut und konnten ungeschützt auf dem Datenbestand rum hacken. Das ist
dieses Jahr passiert! Die Anwendung wurde schließlich nicht eingesetzt.
Gruß Olaf
Olaf Pietsch
2003-08-17 18:51:54 UTC
Permalink
Hallo Guido
Post by Guido Stepken
Ich bin erschüttert. SQL Server auf jedem Desktop,
nein nicht SQL-Server sondern MSDE !
Post by Guido Stepken
die mit einem zentralen SQL Server mit merge-replikation synchronisieren.
Könnte es
Post by Guido Stepken
sein, der Schwachsinn
Mir ist es bisher nicht in den Sinn gekommen, Menschen Schwachsinn deswegen
nachzusagen, weil sie Software für eine bestimmten Plattform entwickeln.
Post by Guido Stepken
bei MS Developern langsam überhand nimmt ? Die
Administrationskosten und Lizenzgebühren sind ja horrend.
da solltest Du Dich bzgl. der Lizenzen einmal informieren
Post by Guido Stepken
Woran lag es,
daß diese Lösung gewählt wurde ? Doch nicht an den
Lock/Transaktionsproblemen, ober die ich vor Kurzem geschrieben habe ?
Wie speicherst Du denn Daten lokal auf einem Laptop, wenn dieser auf Reisen
ist. Verwendest Du dafür die guten alten ASCII-Files? Oder nimmst Du doch
ein Datenbanksystem? Oder muss für Dich der Laptop immer online mit der
Zentrale verbunden sein wie das gute vt100 Terminal?

(Bisher habe ich mich bemüht, freundlich und sachlich mit Menschen zu
diskutieren. Aber für mich sprengt Dein Stil diesen Rahmen nun.)

Olaf
Ralf Dietrich
2003-08-18 18:38:37 UTC
Permalink
Hallo Guido,

Du fängst langsam an unsachlich zu werden und wieder mit Halbwissen zu
glänzen.
:-(
Vielleicht denkst Du mal über den Spruch nach:
"Was ich selbst denk' und tu' trau ich auch den andern zu."
Ich finde Deine Meinung - die Entwickler bei Microsoft betreffend - einfach
anmaßend und frech.

CU Ralf
Post by Guido Stepken
Hallo, Olaf !
Bitte verzeihe mir noch einmal eine kleine Spitze, Ihr MS Leute wißt oft
nicht, was ihr eigentlich tut, bzw. was hinter den ganzen Paketen von M$
Extend the enterprise data storage functionality of SQL Server 2000 to
your desktop, small workgroup, and low-volume Web applications with
Microsoft SQL Server 2000 Desktop Engine (MSDE 2000), a data engine
built on core SQL Server technology.
Das ist eine SQL Server Engine, wie MS selber auch sagt, ansonsten macht
MERGE Replikation ja auch keinen Sinn.
Du hast bei Eurem Projekt einen riesigen Cluster aus SQL Servern
aufgebaut, die sich gegen einen SQL Server abgleichen. Herzlichen
Glückwunsch.
Mit freundlichen Grüßen, Guido Stepken
Post by Olaf Pietsch
Hallo Guido
Post by Guido Stepken
Ich bin erschüttert. SQL Server auf jedem Desktop,
nein nicht SQL-Server sondern MSDE !
Post by Guido Stepken
die mit einem zentralen SQL Server mit merge-replikation
synchronisieren.
Post by Guido Stepken
Post by Olaf Pietsch
Könnte es
Post by Guido Stepken
sein, der Schwachsinn
Mir ist es bisher nicht in den Sinn gekommen, Menschen Schwachsinn deswegen
nachzusagen, weil sie Software für eine bestimmten Plattform entwickeln.
Post by Guido Stepken
bei MS Developern langsam überhand nimmt ? Die
Administrationskosten und Lizenzgebühren sind ja horrend.
da solltest Du Dich bzgl. der Lizenzen einmal informieren
Post by Guido Stepken
Woran lag es,
daß diese Lösung gewählt wurde ? Doch nicht an den
Lock/Transaktionsproblemen, ober die ich vor Kurzem geschrieben habe ?
Wie speicherst Du denn Daten lokal auf einem Laptop, wenn dieser auf Reisen
ist. Verwendest Du dafür die guten alten ASCII-Files? Oder nimmst Du doch
ein Datenbanksystem? Oder muss für Dich der Laptop immer online mit der
Zentrale verbunden sein wie das gute vt100 Terminal?
(Bisher habe ich mich bemüht, freundlich und sachlich mit Menschen zu
diskutieren. Aber für mich sprengt Dein Stil diesen Rahmen nun.)
Olaf
Loading...