BSI-Grundschutz

Post by Oliver Schad
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

;-)

Daraus:

| Die SSID sollte keinen Hinweis auf den Inhaber oder den Zweck eines
| WLAN geben. Ebenso sollte die SSID nicht auf "Any" gesetzt sein, da
| sonst jede beliebige WLAN-Komponente an der Kommunikation teilnehmen
| kann.

Das ist wirklich kurz nach der Merkbefreiung verfasst worden ;-)

| Zur Einschränkung der zugelassenen Kommunikationspartner eines Access
| Point sollten Access Control Lists (ACLs) auf MAC-Adress-Ebene verwendet
| werden.

Stimmt, das ist original ComputerBILD-"Niewo".

Aber he, es ist das "Grundschutzhandbuch". Die sind immer erst derart
inkompetent, und nach einiger Zeit kriegen die - geeignete Beschwerden
wohl vorausgesetzt - dann wieder ein Bisschen was auf die Reihe.

Darf man halt nicht ernstnehmen.

Viele Grüsse,
VB.

--
"Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen."

Dr. Wolfgang Schäuble, Bundesinnenminister

Wolfgang Krietsch

2008-11-03 12:48:23 UTC

Post by Volker Birk
Darf man halt nicht ernstnehmen.

Das sagst Du so leicht. Wenn Du mit Datenschützern und sprechenden
Schlipsen darüber dieskuieren musst wird das ziemlich lästig.

Grüße

woffi

Juergen P. Meier

2008-11-03 18:22:03 UTC

Post by Volker Birk
| Die SSID sollte keinen Hinweis auf den Inhaber oder den Zweck eines
| WLAN geben. Ebenso sollte die SSID nicht auf "Any" gesetzt sein, da
| sonst jede beliebige WLAN-Komponente an der Kommunikation teilnehmen
| kann.
Das ist wirklich kurz nach der Merkbefreiung verfasst worden ;-)

Zumal das ausdruecklich gegen die Forderung aus G-WLAN-19
(Gefahrenkatalog WLAN: Vorspiegelung eines gueltigen Accesspoints -
ein Angriff gegen Clients, die bestimmten SSIDs vertrauen und sich
dort automatisch einbuchen. Ein Rogue AP, der vorgibt diese SSID zu
haben (d.h. sie verwendet), und dem Client mit jeden credentials
Zugang bietet, kann dazu verwendet werden, um dem Client weitere
Login-Credentials zu entwenden, z.B.: per Proxy-Auth die Windows
Domaenen-Kennung inkl. Passwort o.ae. die der client teils automatisch
oder der Benutzer unbedarft dem vermeindlich bekannten Servern
im vermeintlich sicheren WLAN-Netz eingibt.)

Clients buchen sich naemlich *bevorzugt* in Netze mit SSID-Broadcast
ein, sofern dieser Passt, erst wenn *garkein* SSID-Broadcastendes Netz
zu sehen ist, dass der Liste bekannter Netze entspricht, versucht ein
Client sich blind einzubuchen (bucht sich also erst dann beim
SSID-"Versteckenden" Netz ein, wenn kein broadcastendes Netz zu sehen
ist).

Je nach Client kann dabei der Angreifer sogar mit *schwaecherer*
Leistung Clients "hijacken", die sich nur deswegen im Netz des
Angreifes einbuchen, weil dieser die SSID broadcastet.

Post by Volker Birk
Darf man halt nicht ernstnehmen.

Ich nehme diesen Punkte deswegen so ernst, weil ich diesen Angriff
(vertrauenswuerdige SSID Vortaeuschen) bereits in der Praxis Live
beobachten konnte. Diese Attacke wird (schon seit ein paar Jahren)
akut ausgenutzt.

Ich habe mein WLAN @home deswegen auch schon vor ein paar Jahren (als
Konequenz daraus) auf Broadcast der SSID umgestellt. Gerade in der
Zeit, wo ich mangels 802.1x-support in einem Endgeraet nur mit PSK
arbeiten konnte...

Juergen

--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Juergen P. Meier

2008-11-03 18:03:40 UTC

Post by Oliver Schad
Heyho,
sagt mal, wer hat eigentlich den BSI-Leuten so in's Hirn geschissen,
dass die die besten Tipps aus Chip oder Computer-Blöd als Absicherungen
empfehlen?
Ich mein vor Jahren hab ich ja schon mit dem Kopf geschüttelt
stellenweise, aber als ich neulich den Baustein Absicherung von APs
studierte, wurde mir schlecht.
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

Ich finde den 6. Punkt wesentlich kritischer, zumal er ganz klar gegen
G-WLAN-19 verstoesst (Gefahrenkatalog WLAN) und damit strenggenommen
ein nach Grundschutz gebautes WLAN gegen die eigenen Grundschutzregeln
verstoesst, und so nicht fuer hohes Sicherheitsanforderungen
zertifiziert werden darf. (Im Massnahmenkatalog ist das sogar eine
eigene "Schutzmassnahme" - Inkonsistenz in Reinform).

Das ist ein grober und eklatanter Fehler im gesamten WLAN-Grundschutz.

Der Rest ist allerdings recht sinnvoll und brauchbar.

(Aus diesem Grunde betrachte ich das Grundschutzhandbuch bzw. den
WLAN-Katalog auch nur als Vorlage).

Post by Oliver Schad
Und das soll ich so einrichten, damit ich nach außen hin behaupten kann,
ich tue was für IT-Sicherheit? HALLO?

Den AP DHCP machen zu lassen ist ja auch eine Dumme Idee[tm].
Allerdings ist es ebenso daemlich, DHCP zu verteufeln. DHCP sollte der
wenn vorhanden ein WLAN Distribution Switch machen, oder ein
dedizierter DHCP Server, den man anders als die meisten APs ordentlich
absichern kann (siehe Rest des Gefahrenkatalogs).
Das allerdings nur in Verbindung mit gegenseitiger Access-Schicht-
Authentifizierung und -Sicherung (802.11i mit EAP-TLS (802.1x) oder
EAP-MS-CHAP+ADS-KERBEROS), nur dann kann der Client sicher sein, mit
nur dem echten DHCP server zu reden, und der DHCP server kann sicher sein,
nur mit dem echten Client zu reden.

DHCP selbst bietet nunmal grundsaezlich keinerlei Schutz gegen
Manipulation, und hat sogar eine ansonsten recht leicht auszunutzende
Angriffsflaeche (Angriff: einfach), wobei das Schaden maximal ist
(Schaden: hoch), woraus ein hohes Risiko resultiert.
So kann ein Netzteilnehmer bei ungeschuetztem DHCP dir als Client
falshce DNS-Server, defaultrouter, WINS-Server, Proxies etc.
unterjubeln, ohne dass du das am Client merkst.

Von daher ist die Forderung des BSI zumindest nachvollziehbar, wenn
hier auch eine deutliche Differenzierung wuenschenswert ist.

Post by Oliver Schad
"Ja, tut mir leid, ich kann sie nicht zertifizieren, ihre APs sind
unsicher, die machen DHCP". Was zur Hölle haben die denn geraucht?

Tja.

Oliver Schad

2008-11-04 09:20:44 UTC

Post by Juergen P. Meier

Post by Oliver Schad
sagt mal, wer hat eigentlich den BSI-Leuten so in's Hirn geschissen,
dass die die besten Tipps aus Chip oder Computer-Blöd als
Absicherungen empfehlen?
Ich mein vor Jahren hab ich ja schon mit dem Kopf geschüttelt
stellenweise, aber als ich neulich den Baustein Absicherung von APs
studierte, wurde mir schlecht.
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

Ich finde den 6. Punkt wesentlich kritischer, zumal er ganz klar gegen
G-WLAN-19 verstoesst (Gefahrenkatalog WLAN) und damit strenggenommen
ein nach Grundschutz gebautes WLAN gegen die eigenen Grundschutzregeln
verstoesst, und so nicht fuer hohes Sicherheitsanforderungen
zertifiziert werden darf. (Im Massnahmenkatalog ist das sogar eine
eigene "Schutzmassnahme" - Inkonsistenz in Reinform).
Das ist ein grober und eklatanter Fehler im gesamten WLAN-Grundschutz.

Äh, wenn man wissen will, ob das auch das richtige Netz ist als Client,
dann kann man das auch einfach gegen $IRGENDWAS prüfen. Normalerweise
braucht man das aber nicht, es sei denn, man macht $SCHEISS.

Post by Juergen P. Meier
Der Rest ist allerdings recht sinnvoll und brauchbar.

Sehe ich ganz anders.

Post by Juergen P. Meier
(Aus diesem Grunde betrachte ich das Grundschutzhandbuch bzw. den
WLAN-Katalog auch nur als Vorlage).

Ich würd den Teil mal komplett in die Tonne kloppen.

Post by Juergen P. Meier

Post by Oliver Schad
Und das soll ich so einrichten, damit ich nach außen hin behaupten
kann, ich tue was für IT-Sicherheit? HALLO?

Den AP DHCP machen zu lassen ist ja auch eine Dumme Idee[tm].

Was soll daran dumm sein?

Post by Juergen P. Meier
Allerdings ist es ebenso daemlich, DHCP zu verteufeln. DHCP sollte der
wenn vorhanden ein WLAN Distribution Switch machen, oder ein
dedizierter DHCP Server, den man anders als die meisten APs ordentlich
absichern kann (siehe Rest des Gefahrenkatalogs).

Es ist eine furchtbar dumme Idee einen WLAN-AP dafür einzusetzen, die
Vertraulichkeit von Kommunikation zu gewährleisten aus meiner Sicht.
Und auf einem WLAN-AP kann auch ein vernünftiger DHCP-Server laufen -
was ist das für eine komische Argumentation von dir?

Post by Juergen P. Meier
Das allerdings nur in Verbindung mit gegenseitiger Access-Schicht-
Authentifizierung und -Sicherung (802.11i mit EAP-TLS (802.1x) oder
EAP-MS-CHAP+ADS-KERBEROS), nur dann kann der Client sicher sein, mit
nur dem echten DHCP server zu reden, und der DHCP server kann sicher
sein, nur mit dem echten Client zu reden.

Es ist in vielen Fällen total Wurst, mit welchem AP man redet als
Client, weil man sowieso immer die Gegenstellen bei kritischer
Kommunikation auf höheren Schichten als Layer 2 prüft.

Post by Juergen P. Meier
DHCP selbst bietet nunmal grundsaezlich keinerlei Schutz gegen
Manipulation, und hat sogar eine ansonsten recht leicht auszunutzende
Angriffsflaeche (Angriff: einfach), wobei das Schaden maximal ist
(Schaden: hoch), woraus ein hohes Risiko resultiert.
So kann ein Netzteilnehmer bei ungeschuetztem DHCP dir als Client
falshce DNS-Server, defaultrouter, WINS-Server, Proxies etc.
unterjubeln, ohne dass du das am Client merkst.

Wenn man das richtig macht, ist das scheiß egal.

Post by Juergen P. Meier
Von daher ist die Forderung des BSI zumindest nachvollziehbar, wenn
hier auch eine deutliche Differenzierung wuenschenswert ist.

Sie ist strunz hohl, aber nachvollziehbar in kleinen Gehirnen. Darauf
können wir uns einigen.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Juergen Ilse

2008-11-05 12:07:29 UTC

Hallo,

Post by Juergen P. Meier
Ich finde den 6. Punkt wesentlich kritischer, zumal er ganz klar gegen
G-WLAN-19 verstoesst (Gefahrenkatalog WLAN) und damit strenggenommen
ein nach Grundschutz gebautes WLAN gegen die eigenen Grundschutzregeln
verstoesst, und so nicht fuer hohes Sicherheitsanforderungen
zertifiziert werden darf. (Im Massnahmenkatalog ist das sogar eine
eigene "Schutzmassnahme" - Inkonsistenz in Reinform).
Das ist ein grober und eklatanter Fehler im gesamten WLAN-Grundschutz.

Da du fuer die Pruefung von $IRGENDWAS i.a. Zeit benoetigst und dein
Rechner waehrend dieser Zeit bereits im ggfs. nicht vertrauenswuerdigen
Netz mit allen Konsequenzen eingebunden ist, waere es schon vorteilhaft,
ggfs. die Wahrscheinlichkeit, mit der man "im falschen WLAN landet" wenn
moeglich zu reduzieren (die Pruefungen kann man ja trotzdem noch vornehmen).
Es ist demnach also sinnvoll (wie Juergen erlaeutert hat), den SSID-Broadcast
auf jeden Fall *ein*geschaltet zu lassen.

Post by Juergen P. Meier
Der Rest ist allerdings recht sinnvoll und brauchbar.

Sehe ich ganz anders.

Welche Punkte haeltst du fuer "nicht brauchbar"? Dass ab einer bestimmten
Komplexitaet des Netzes und vor allem "bei staendig wechselnden Clients"
ggfs. DHCP doch die Methoide der Wahl ist, ist unbestritten. Dass DHCP aber
(sofern jemand einen DHCP-Server "faked") auch eine Sicherheitsluecke dar-
stellen koennte, ist ebenfalls unzweifelhaft. Wenn man DHCP nicht benoetigt,
sollte man IMHO darauf verzichten (ist aber nur meine persoenliche Meinung).
Wenn man es verwendet, taete man ggfs. gut daran, das nicht unbedingt dem
AP zu ueberlassen (es gib, wenn man denn DHCP benoetigt, vermutlich geeig-
netere Geraete im Netz, die diese Aufgabe uebernehmen koennten ...).

Post by Juergen P. Meier
(Aus diesem Grunde betrachte ich das Grundschutzhandbuch bzw. den
WLAN-Katalog auch nur als Vorlage).

Ich würd den Teil mal komplett in die Tonne kloppen.

Was hast du konkret gegen die Punkte 1, 2, 3, 7, 8, 11, 12, 13? Und Punkt 14
ist nun auch nicht unbedingt so falsch (wobei man ggfs. wieder abwaegen muss,
ob das im Einzelfall sinnvoll umsetzbar ist). Das sind immerhin 8 oder 9 von
14 Punkten, die mir durchaus sinnvoll und "zur Erhoehung der sicherheit ge-
eignet" erscheinen, So schlecht ist diese Quote doch gar nicht.

Es ist eine furchtbar dumme Idee einen WLAN-AP dafür einzusetzen, die
Vertraulichkeit von Kommunikation zu gewährleisten aus meiner Sicht.

Deswegen gehen aktuelle Entwciklungen auch dahin, das nicht den AP machen
zu lassen (sogenannte "Light Weight Accesspoiints" und eine zentrale Instanz,
auf der die Verschluesselung,. Authentifizierung, etc. abgewickelt wird,
IMHO fuer ein kleines Heimnetz aber evt. etwas overkill ...).

Post by Oliver Schad
Und auf einem WLAN-AP kann auch ein vernünftiger DHCP-Server laufen -
was ist das für eine komische Argumentation von dir?

Ich sehe dass mit dem DHCP-Server im AP nicht ganz so kritisch wie mein
Namensvetter, wuerde aber dennoch auf DHCP verzichten, wenn ich es nicht
benoetigen wuerde. DHCP *kann* in manchen Faellen ein Schwachpunkt sein,
allerdings erst dann, wenn man einen potentiellen Angreifer bereits im
Netz hat ...

Es ist in vielen Fällen total Wurst, mit welchem AP man redet als
Client, weil man sowieso immer die Gegenstellen bei kritischer
Kommunikation auf höheren Schichten als Layer 2 prüft.

Also auch in deinem abgesicherten WLAN-Netz keinerlei unverschluesselte
Kommunikation mehr, auch im lokalen Netz keinen unsignierten oder mit
nicht vertrauenswuerdigen Schluesseln signier5ten Daten mehr vertrauen?
Das waere IMHO in sehr vielen Faellen eine deutlich ueberzogene Forderung.

Wenn man das richtig macht, ist das scheiß egal.

Sicherheit ist eine Gratwanderung zwischen Benutzbarkeit und Absicherung.
Ein optimal sicheres System ist so gut wie unbenutzbar, ein optimal benutz-
bares System ohne jeglichen Einschraenkungen nicht sicher. Wenn du z.B. dem
per DHCP zugewiesenen Proxy vertraust (mehr doer weniger stark), dann ist
es eine Sicherheitsluecke, wenn die Moeglichkeit besteht, dir einen evt.
"getuerkten Proxy" unterzujubeln ... Selbiges fuer Default-Gateway und
andere aus dieser Quelle erhaltene Informationen. Ich denke, du machst es
dir mit deiner Betrachtungsweise etwas zu einfach, wenn du darin keine Ge-
fahren siehst ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Rainer Sokoll

2008-11-05 12:43:16 UTC

Post by Juergen Ilse
Ich sehe dass mit dem DHCP-Server im AP nicht ganz so kritisch wie mein
Namensvetter, wuerde aber dennoch auf DHCP verzichten, wenn ich es nicht
benoetigen wuerde. DHCP *kann* in manchen Faellen ein Schwachpunkt sein,
allerdings erst dann, wenn man einen potentiellen Angreifer bereits im
Netz hat ...

Ja, eben. Wenn Du auf Layer2 sicher bist, kannst Du doch ganz beruhigt
DHCP auch auf dem WLAN fahren?

Rainer

Juergen P. Meier

2008-11-07 06:36:55 UTC

Post by Rainer Sokoll

Ja, eben. Wenn Du auf Layer2 sicher bist, kannst Du doch ganz beruhigt
DHCP auch auf dem WLAN fahren?

Nein. Denn auf Layer2 sicherst du das *Netz* gegen *Aussenstehende*.

Danach musst du je nach Konzept noch die *einzelnen* *Teilnehmer* des
Netzes *voreinander* schuetzen. Und dabei ist DHCP halt ein Protokoll,
dass nicht wirklich einfach so abgesichert werden kann.

Oliver Schad

2008-11-05 12:53:12 UTC

Post by Juergen P. Meier
Ich finde den 6. Punkt wesentlich kritischer, zumal er ganz klar
gegen G-WLAN-19 verstoesst (Gefahrenkatalog WLAN) und damit
strenggenommen ein nach Grundschutz gebautes WLAN gegen die eigenen
Grundschutzregeln verstoesst, und so nicht fuer hohes
Sicherheitsanforderungen zertifiziert werden darf. (Im
Massnahmenkatalog ist das sogar eine eigene "Schutzmassnahme" -
Inkonsistenz in Reinform). Das ist ein grober und eklatanter Fehler
im gesamten WLAN-Grundschutz.

Äh, wenn man wissen will, ob das auch das richtige Netz ist als
Client, dann kann man das auch einfach gegen $IRGENDWAS prüfen.
Normalerweise braucht man das aber nicht, es sei denn, man macht
$SCHEISS.

Da du fuer die Pruefung von $IRGENDWAS i.a. Zeit benoetigst und dein
Rechner waehrend dieser Zeit bereits im ggfs. nicht
vertrauenswuerdigen Netz mit allen Konsequenzen eingebunden ist, waere
es schon vorteilhaft, ggfs. die Wahrscheinlichkeit, mit der man "im
falschen WLAN landet" wenn moeglich zu reduzieren (die Pruefungen kann
man ja trotzdem noch vornehmen). Es ist demnach also sinnvoll (wie
Juergen erlaeutert hat), den SSID-Broadcast auf jeden Fall
*ein*geschaltet zu lassen.

Wenn das Verbinden allein mit dem falschen Netz sicherheitsrelevant ist,
dann hat man was falsch gemacht, wirklich. Das gehört einfach nicht so.

Post by Juergen P. Meier
Der Rest ist allerdings recht sinnvoll und brauchbar.

Sehe ich ganz anders.

Nur, wenn das Konzept kaputt ist. Wenn falsche Routen für popelige
Netzwerkstationen sicherheitsrelevant sind in sofern, dass
Informationen dadurch öffentlich werden könnten, die nicht öffentlich
werden sollen, dann ist das Konzept dahinter so richtig kaputt. Das
darf einfach nicht.

Post by Juergen Ilse
Wenn man DHCP nicht benoetigt, sollte man IMHO darauf
verzichten (ist aber nur meine persoenliche Meinung). Wenn man es
verwendet, taete man ggfs. gut daran, das nicht unbedingt dem AP zu
ueberlassen (es gib, wenn man denn DHCP benoetigt, vermutlich geeig-
netere Geraete im Netz, die diese Aufgabe uebernehmen koennten ...).

Ich finde DHCP zu verwenden eine ausgesprochen gute Idee in vielen
Fällen.

Post by Juergen P. Meier
(Aus diesem Grunde betrachte ich das Grundschutzhandbuch bzw. den
WLAN-Katalog auch nur als Vorlage).

Ich würd den Teil mal komplett in die Tonne kloppen.

Was hast du konkret gegen die Punkte 1, 2, 3, 7, 8, 11, 12, 13? Und
Punkt 14 ist nun auch nicht unbedingt so falsch (wobei man ggfs.
wieder abwaegen muss, ob das im Einzelfall sinnvoll umsetzbar ist).
Das sind immerhin 8 oder 9 von 14 Punkten, die mir durchaus sinnvoll
und "zur Erhoehung der sicherheit ge- eignet" erscheinen, So schlecht
ist diese Quote doch gar nicht.

Punkt 1: Unsinn, administrativer Zugang muss sicher sein, fertig.

Punkt 2: Regelmäßiges wechseln kommt nicht in Frage, es wird gewechselt
bei Verdacht auf Kompromittierung

Punkt 3: Passt

Punkt 7: Wenn auf dem AP nur geeignete Verschlüsselungsalgorithmen
aktiviert sind, wie können dann WLAN-Clients das umgehen?

Punkt 8: Passwörter werden nur bei Verdacht auf Kompromittierung
gewechselt. PSKs sind im größeren Stil vollkommen ungeeignet, um die
Vertraulichkeit von Kommunikation und Zugangsschutz zu erreichen

Punkt 11: Passt

Punkt 12: Passt

Punkt 13: Passt

Punkt 14: Schwachsinn, entweder ist das Ding auch am WE sicher oder es
gehört abgeschaltet

Post by Juergen P. Meier
Allerdings ist es ebenso daemlich, DHCP zu verteufeln. DHCP sollte
der wenn vorhanden ein WLAN Distribution Switch machen, oder ein
dedizierter DHCP Server, den man anders als die meisten APs
ordentlich absichern kann (siehe Rest des Gefahrenkatalogs).

Es ist eine furchtbar dumme Idee einen WLAN-AP dafür einzusetzen, die
Vertraulichkeit von Kommunikation zu gewährleisten aus meiner Sicht.

Deswegen gehen aktuelle Entwciklungen auch dahin, das nicht den AP
machen zu lassen (sogenannte "Light Weight Accesspoiints" und eine
zentrale Instanz, auf der die Verschluesselung,. Authentifizierung,
etc. abgewickelt wird, IMHO fuer ein kleines Heimnetz aber evt. etwas
overkill ...).

Vielleicht könnte man auch HTTPS, anstatt HTTP benutzen, IMAPS, anstatt
IMAP etc. Dann ist das vollkommen scheiß egal, ob die Kommunikation zum
AP jetzt verschlüsselt ist oder nicht.

Post by Juergen Ilse
Ich sehe dass mit dem DHCP-Server im AP nicht ganz so kritisch wie
mein Namensvetter, wuerde aber dennoch auf DHCP verzichten, wenn ich
es nicht benoetigen wuerde. DHCP *kann* in manchen Faellen ein
Schwachpunkt sein, allerdings erst dann, wenn man einen potentiellen
Angreifer bereits im Netz hat ...

Gehe davon aus, dass dein Angreifer in deinem Netz ist, immer. Dann
baust du ganz andere Konzepte.

Post by Juergen Ilse
Also auch in deinem abgesicherten WLAN-Netz keinerlei
unverschluesselte Kommunikation mehr, auch im lokalen Netz keinen
unsignierten oder mit nicht vertrauenswuerdigen Schluesseln
signier5ten Daten mehr vertrauen? Das waere IMHO in sehr vielen
Faellen eine deutlich ueberzogene Forderung.

Das ist nicht schwer umzusetzen und sehr einleuchtend, dass das eine
gute Sache ist. Mit IPSec beispielsweise kann man prima
Ende-zu-Ende-Verschlüsselung machen, auch im LAN.

Wenn man benutzerbezogen sichern will, muss man halt >= Layer 5 bemühen.

Post by Juergen P. Meier
DHCP selbst bietet nunmal grundsaezlich keinerlei Schutz gegen
Manipulation, und hat sogar eine ansonsten recht leicht
auszunutzende Angriffsflaeche (Angriff: einfach), wobei das Schaden
maximal ist (Schaden: hoch), woraus ein hohes Risiko resultiert.
So kann ein Netzteilnehmer bei ungeschuetztem DHCP dir als Client
falshce DNS-Server, defaultrouter, WINS-Server, Proxies etc.
unterjubeln, ohne dass du das am Client merkst.

Wenn man das richtig macht, ist das scheiß egal.

In der Pauschalheit ist das einfach quatsch. Sicherheit und
Benutzbarkeit stehen nicht zwangsläufig im Widerspruch zueinander.
Mache IPSec zwischen allen Stationen deines Netzwerks, deine Benutzer
werden es nicht merken.

Biete HTTPS an, anstatt HTTP, deine Benutzer werden es nicht merken.

Post by Juergen Ilse
Wenn du z.B. dem per DHCP zugewiesenen Proxy vertraust (mehr
doer weniger stark), dann ist es eine Sicherheitsluecke, wenn die
Moeglichkeit besteht, dir einen evt. "getuerkten Proxy" unterzujubeln

Vielleicht sollte man dem Proxy nicht vertrauen? Vielleicht sollte so
ein Proxy ja auch mehr Zugangsregeln durchsetzen und nicht Dinge tun,
für die er nicht gedacht ist.

Wenn man Angst hat, dass Layer 5 scheiße implementiert ist, dann sollte
man sich auch über die höheren Schichten ernsthafte Gedanken machen,
d.h. die Software gehört vom Netz und ein Proxy nützt da genau viel zu
wenig.

Post by Juergen Ilse
... Selbiges fuer Default-Gateway und andere aus dieser Quelle
erhaltene Informationen. Ich denke, du machst es dir mit deiner
Betrachtungsweise etwas zu einfach, wenn du darin keine Ge- fahren
siehst ...

Aus meiner Sicht sollte man Sicherheit nicht zentralisieren, die einen
elementaren Schutz für die Einzelkomponenten darstellen. Das ist
einfach der Fehler in deiner Denkweise. Härte die Einzelkomponenten,
mache sie möglichst unabhängig von anderen Komponenten und anschließend
maure den Kram nochmal ein bei Bedarf mit zentralen Komponenten. So
herum wird ein Schuh draus, nicht andersherum.

Aus meiner Sicht ist die Idee der zentralen Firewall, die gut von böse
schützt für'n Arsch, wenn ich das mal so salopp formulieren darf.

Es gibt soviele Angriffsmöglichkeiten auf den verschiedensten Schichten,
dass es naiv ist anzunehmen, dass wenn man auf Schicht 1-4 ganz toll
Sicherheit macht nach außen, einem fast nix mehr passieren kann.

Blöd nur, wenn außen auf einmal auf höheren Schichten nach drinnen
kommt, dann ist halt alles am Arsch.

Aus meiner Sicht hat sich schon lange das Konzept der zentralen
Sicherheit überlebt.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Juergen Ilse

2008-11-05 17:45:40 UTC

Hallo,

Post by Juergen Ilse
Was hast du konkret gegen die Punkte 1, 2, 3, 7, 8, 11, 12, 13? Und
Punkt 14 ist nun auch nicht unbedingt so falsch (wobei man ggfs.
wieder abwaegen muss, ob das im Einzelfall sinnvoll umsetzbar ist).
Das sind immerhin 8 oder 9 von 14 Punkten, die mir durchaus sinnvoll
und "zur Erhoehung der sicherheit ge- eignet" erscheinen, So schlecht
ist diese Quote doch gar nicht.

Punkt 1: Unsinn, administrativer Zugang muss sicher sein, fertig.

... und ein Netzwerkkabel laesst sich leichter ueberwahcen als ein WLAN
(das geht allein mit "optischen Mittels" sprich hinsehen in voellig tri-
vialer Weise, beim WLAN ist das mit dem "erkennen durch hinsehen" eher
schwierig ...). Daher ist der Tip gar nicht so verkehrt.

Post by Oliver Schad
Punkt 2: Regelmäßiges wechseln kommt nicht in Frage, es wird gewechselt
bei Verdacht auf Kompromittierung

Regelmaessiges Wechseln ist nicht verkehrt (man muss aber zwischen dem ggfs.
nicht unerheblichen aufwand und dem dadurch evt. erhaltenen Sicherheitsge-
winn abwaegen ...).

Post by Oliver Schad
Punkt 7: Wenn auf dem AP nur geeignete Verschlüsselungsalgorithmen
aktiviert sind, wie können dann WLAN-Clients das umgehen?

Ggfs. Fehler in der Implementierung, schwache leicht zu erratende Schluessel,
unvorsichtige User, die den Schluessel weitergeben, ...

Post by Oliver Schad
Punkt 8: Passwörter werden nur bei Verdacht auf Kompromittierung
gewechselt.

Es ist gaengige Praxis, das anders zu handhaben (und der Sinn davon wird
auch von kaum jemanden ausser dir bestritten ...).

Post by Oliver Schad
Punkt 14: Schwachsinn, entweder ist das Ding auch am WE sicher oder es
gehört abgeschaltet

Es spricht nicht nur "Sicherheit" sondern auch manches andere dafuer,
ein Geraet ggfs. nur dann einzuschalten, wenn es benoetigt wird ...
So falsch ist der Hinweis nicht (evt. nicht so sonderlich notwendig fuer
die Sicherheit, aber zumindest nicht unbedingt falsch).

Post by Juergen Ilse
Also auch in deinem abgesicherten WLAN-Netz keinerlei
unverschluesselte Kommunikation mehr, auch im lokalen Netz keinen
unsignierten oder mit nicht vertrauenswuerdigen Schluesseln
signierten Daten mehr vertrauen? Das waere IMHO in sehr vielen
Faellen eine deutlich ueberzogene Forderung.

Das ist nicht schwer umzusetzen und sehr einleuchtend, dass das eine
gute Sache ist. Mit IPSec beispielsweise kann man prima
Ende-zu-Ende-Verschlüsselung machen, auch im LAN.

Ist aber im LAN i.d.R. overkill, solange man das LAN selbst einigermassen
sinnvoll abgesichert hat. Wenn du in einem LAN-Sement 50 Rechner hat, willst
du doch wohl nicht wirklich auf jedem Rechner 49 VPN-Tunnel terminieren
lassen, oder etwa doch?

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Oliver Schad

2008-11-06 00:59:23 UTC

Punkt 1: Unsinn, administrativer Zugang muss sicher sein, fertig.

... und ein Netzwerkkabel laesst sich leichter ueberwahcen als ein
WLAN (das geht allein mit "optischen Mittels" sprich hinsehen in
voellig tri- vialer Weise, beim WLAN ist das mit dem "erkennen durch
hinsehen" eher schwierig ...). Daher ist der Tip gar nicht so
verkehrt.

"Gar nicht so verkehrt" ordne ich mal ein unter "Es gibt Fälle, in denen
das sinnvoll sein könnte, hatt zwar nichts mit Sicherheit zu tun, aber
was soll's".

Post by Oliver Schad
Punkt 2: Regelmäßiges wechseln kommt nicht in Frage, es wird
gewechselt bei Verdacht auf Kompromittierung

Regelmaessiges Wechseln ist nicht verkehrt (man muss aber zwischen dem
ggfs. nicht unerheblichen aufwand und dem dadurch evt. erhaltenen
Sicherheitsge- winn abwaegen ...).

Der Gewinn sollte verschwindend gering sein, denn sonst ist was ziemlich
verkehrt im System.

Post by Oliver Schad
Punkt 7: Wenn auf dem AP nur geeignete Verschlüsselungsalgorithmen
aktiviert sind, wie können dann WLAN-Clients das umgehen?

Ggfs. Fehler in der Implementierung, schwache leicht zu erratende
Schluessel, unvorsichtige User, die den Schluessel weitergeben, ...

Äh, wenn mein AP nur WPA2 mit AES anbietet, wie passiert das, dass ein
Client WEP benutzt?

Post by Oliver Schad
Punkt 8: Passwörter werden nur bei Verdacht auf Kompromittierung
gewechselt.

Es ist gaengige Praxis, das anders zu handhaben (und der Sinn davon
wird auch von kaum jemanden ausser dir bestritten ...).

Gängige Praxis ist auch PFWs und Virenscanner zu installieren. Das sehe
ich nicht als valides Argument.

Wenn ich meinen Benutzer aufnötige sie mit Sicherheit unnötig zu
konfrontieren, dann mach ich Sicherheit sofort kaputt und das an der
wichtigsten Schnittstelle, nämlich an der Schnittstelle zum Menschen.
Das ist einfach furchtbar dumm, denn letztlich entscheiden die Menschen
im Unternehmen, ob Sicherheit wirklich da ist oder nicht.

Wenn ich das Grundschutzhandbuch wirklich durchziehe, dann versaue ich
es mir mit den Menschen in vielen Fällen. Das kann man nicht bringen,
wirklich nicht.

Das gleiche gilt für Qualitätsmanagement: Wenn das Zeug einem einfach
nur auf den Sack geht, dann kann man so viel managen wie man will, es
kommt ein Haufen Scheiße bei raus.

Post by Oliver Schad
Punkt 14: Schwachsinn, entweder ist das Ding auch am WE sicher oder
es gehört abgeschaltet

Es spricht nicht nur "Sicherheit" sondern auch manches andere dafuer,
ein Geraet ggfs. nur dann einzuschalten, wenn es benoetigt wird ...
So falsch ist der Hinweis nicht (evt. nicht so sonderlich notwendig
fuer die Sicherheit, aber zumindest nicht unbedingt falsch).

Toll, ich dachte, wir reden über Sicherheit und nicht Stromsparen.
Vielleicht sollte so ein Heftchen dann nicht vom BSI kommen, sondern
vom Umweltministerium.

Post by Juergen Ilse
Also auch in deinem abgesicherten WLAN-Netz keinerlei
unverschluesselte Kommunikation mehr, auch im lokalen Netz keinen
unsignierten oder mit nicht vertrauenswuerdigen Schluesseln
signierten Daten mehr vertrauen? Das waere IMHO in sehr vielen
Faellen eine deutlich ueberzogene Forderung.

Das ist nicht schwer umzusetzen und sehr einleuchtend, dass das eine
gute Sache ist. Mit IPSec beispielsweise kann man prima
Ende-zu-Ende-Verschlüsselung machen, auch im LAN.

Ist aber im LAN i.d.R. overkill, solange man das LAN selbst
einigermassen sinnvoll abgesichert hat. Wenn du in einem LAN-Sement 50
Rechner hat, willst du doch wohl nicht wirklich auf jedem Rechner 49
VPN-Tunnel terminieren lassen, oder etwa doch?

Das sind keine Tunnel, es ist Transport-Modus. Und ja, genau dafür ist
IPSec da.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Juergen Ilse

2008-11-06 09:47:26 UTC

Hallo,

Post by Juergen Ilse
Ist aber im LAN i.d.R. overkill, solange man das LAN selbst
einigermassen sinnvoll abgesichert hat. Wenn du in einem LAN-Sement 50
Rechner hat, willst du doch wohl nicht wirklich auf jedem Rechner 49
VPN-Tunnel terminieren lassen, oder etwa doch?

Das sind keine Tunnel, es ist Transport-Modus. Und ja, genau dafür ist
IPSec da.

Trotzdem haettest du entweder dein Netz "vollvermascht" (also auf jedem
Rechner 50 VPN-Peers) oder du brauchst einen VPN-Konzentrator, zu dem jeder
dieser 50 Rechner dann eine VPN-Connection im Transport-Mode (mit nur dem
VPN-Konzentrator als Peer) betreibt. Weder das eine noch das andere ist
oftmals wirklich praktikabel, sondern eigentlich eher overkill ...
Es gibt Szenarien, in denen man genau so etwas will, aber als "Allgemein-
Fall" wuerde ich das wirklich nicht ansehen ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Denis Jedig

2008-11-07 11:57:04 UTC

Post by Oliver Schad
Das sind keine Tunnel, es ist Transport-Modus. Und ja, genau dafür ist
IPSec da.

Trotzdem haettest du entweder dein Netz "vollvermascht" (also auf jedem
Rechner 50 VPN-Peers)

Diese Aussage gilt nur für eine sehr eigenwillige Definition von
"VPN-Peer". Eine Definition, die ein Verständnis von
Transportverschlüsselung nahe legt, welches von IPSEC komplett unberührt
blieb.

Post by Juergen Ilse
VPN-Konzentrator als Peer) betreibt. Weder das eine noch das andere ist
oftmals wirklich praktikabel, sondern eigentlich eher overkill ...

Sowohl das eine als auch das andere *ist* praktikabel, wird in vielen
Szenarien eingesetzt, ist mit zahlreichen RFCs zu IPSEC standardisiert und
in gängigen OSen implementiert.

--
Denis Jedig
syneticon networks GbR http://syneticon.net/service/

Oliver Schad

2008-11-09 03:19:56 UTC

Post by Juergen Ilse
Ist aber im LAN i.d.R. overkill, solange man das LAN selbst
einigermassen sinnvoll abgesichert hat. Wenn du in einem LAN-Sement
50 Rechner hat, willst du doch wohl nicht wirklich auf jedem Rechner
49 VPN-Tunnel terminieren lassen, oder etwa doch?

Das sind keine Tunnel, es ist Transport-Modus. Und ja, genau dafür
ist IPSec da.

Trotzdem haettest du entweder dein Netz "vollvermascht" (also auf
jedem Rechner 50 VPN-Peers) oder du brauchst einen VPN-Konzentrator,
zu dem jeder dieser 50 Rechner dann eine VPN-Connection im
Transport-Mode (mit nur dem VPN-Konzentrator als Peer) betreibt. Weder
das eine noch das andere ist oftmals wirklich praktikabel, sondern
eigentlich eher overkill ... Es gibt Szenarien, in denen man genau so
etwas will, aber als "Allgemein- Fall" wuerde ich das wirklich nicht
ansehen ...

Das Ziel von IPv6 war mit IPSec sogar ein ganzes Internet so aufzubauen.
Ich halte das nicht für Overkill, ich halte das genau für das richtige
Ziel.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Juergen Ilse

2008-11-09 08:31:32 UTC

Hallo,

Post by Juergen Ilse
Trotzdem haettest du entweder dein Netz "vollvermascht" (also auf
jedem Rechner 50 VPN-Peers) oder du brauchst einen VPN-Konzentrator,
zu dem jeder dieser 50 Rechner dann eine VPN-Connection im
Transport-Mode (mit nur dem VPN-Konzentrator als Peer) betreibt. Weder
das eine noch das andere ist oftmals wirklich praktikabel, sondern
eigentlich eher overkill ... Es gibt Szenarien, in denen man genau so
etwas will, aber als "Allgemein- Fall" wuerde ich das wirklich nicht
ansehen ...

Das Ziel von IPv6 war mit IPSec sogar ein ganzes Internet so aufzubauen.

Nein, ein Ziel (dass man mittlerweile wieder fallengelassen hat) war es,
die *Moeglichkeit* IPSEC zu nutzen verpflichtend in den IP-Stack einzubauen.
Es stand nicht zur Diskussion, dass ausschlieeslich im gesamten Internet
alle Kommunikation zwingend verschluesselt sein sollte.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Oliver Schad

2008-11-09 10:36:33 UTC

Post by Juergen Ilse
Hallo,

Post by Juergen Ilse
Trotzdem haettest du entweder dein Netz "vollvermascht" (also auf
jedem Rechner 50 VPN-Peers) oder du brauchst einen VPN-Konzentrator,
zu dem jeder dieser 50 Rechner dann eine VPN-Connection im
Transport-Mode (mit nur dem VPN-Konzentrator als Peer) betreibt.
Weder das eine noch das andere ist oftmals wirklich praktikabel,
sondern eigentlich eher overkill ... Es gibt Szenarien, in denen man
genau so etwas will, aber als "Allgemein- Fall" wuerde ich das
wirklich nicht ansehen ...

Das Ziel von IPv6 war mit IPSec sogar ein ganzes Internet so
aufzubauen.

Nein, ein Ziel (dass man mittlerweile wieder fallengelassen hat) war
es, die *Moeglichkeit* IPSEC zu nutzen verpflichtend in den IP-Stack
einzubauen.

Das wäre mir persönlich neu und aus meiner Sicht ausgesprochen dumm.
Nicht, dass IPSec irgendwie toll wäre, es ist aber wenigstens da.

Post by Juergen Ilse
Es stand nicht zur Diskussion, dass ausschlieeslich im
gesamten Internet alle Kommunikation zwingend verschluesselt sein
sollte.

Natürlich nicht, eben da wo es Kommunikationspartner als nötig ansehen
aber das dann mit jedem Host möglich.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Jens Link

2008-11-10 11:19:52 UTC

Post by Juergen Ilse
Nein, ein Ziel (dass man mittlerweile wieder fallengelassen hat) war es,
die *Moeglichkeit* IPSEC zu nutzen verpflichtend in den IP-Stack einzubauen.

Es gab mal eine Diskussion darueber IPSEC "not mandatory" in IPv6 zu
machen. Die ist aber IIRC im Sande verlaufen und IPSEC ist noch immer
drin. Oder hab ich was verpasst?

Jens

--
***@guug Berlin: http://www.guug.de/lokal/berlin/index.html
------
(Call-for-Papers) 10.-13.03.09 GUUG-Frühjahrsfachgespaech 2009
http://www.guug.de/veranstaltungen/ffg2009/

Lars Rohwedder

2008-11-10 11:59:20 UTC

Post by Jens Link

Post by Juergen Ilse
Nein, ein Ziel (dass man mittlerweile wieder fallengelassen hat) war
es, die *Moeglichkeit* IPSEC zu nutzen verpflichtend in den IP-Stack
einzubauen.

Es gab mal eine Diskussion darueber IPSEC "not mandatory" in IPv6 zu
machen. Die ist aber IIRC im Sande verlaufen und IPSEC ist noch immer
drin. Oder hab ich was verpasst?

Du hast nichts verpasst. Wie der Vorposter auch schrieb: Jeder
IPv6-Host _muss_ IPSEC beherrschen, aber jeder Host _darf_ sich auch
dazu entschließen, mit einem anderen Host ohne IPSEC zu kommunizieren.
Ob der andere Host das dann zulassen muss oder ob jener eine
Nicht-IPSEC-Kommunikation verweigern darf (und dies auf IP-Ebene
mitteilen kann), weiß ich allerdings nicht.

L.

Juergen Ilse

2008-11-10 14:37:15 UTC

Hallo,

Post by Lars Rohwedder

Post by Jens Link

Post by Juergen Ilse
Nein, ein Ziel (dass man mittlerweile wieder fallengelassen hat) war
es, die *Moeglichkeit* IPSEC zu nutzen verpflichtend in den IP-Stack
einzubauen.

Es gab mal eine Diskussion darueber IPSEC "not mandatory" in IPv6 zu
machen. Die ist aber IIRC im Sande verlaufen und IPSEC ist noch immer
drin. Oder hab ich was verpasst?

Du hast nichts verpasst. Wie der Vorposter auch schrieb: Jeder
IPv6-Host _muss_ IPSEC beherrschen,

"haette anc hden urspruenglichen Plaenen beherrschen muessen", aber IPSEC
ist in IPv6 nicht mehr "verpflichtend enthalten" ...

Post by Lars Rohwedder
aber jeder Host _darf_ sich auch dazu entschließen, mit einem anderen Host
ohne IPSEC zu kommunizieren.

Das meinte ich.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Oliver Schad

2008-11-10 15:18:16 UTC

Post by Lars Rohwedder
Du hast nichts verpasst. Wie der Vorposter auch schrieb: Jeder
IPv6-Host _muss_ IPSEC beherrschen,

"haette anc hden urspruenglichen Plaenen beherrschen muessen", aber
IPSEC ist in IPv6 nicht mehr "verpflichtend enthalten" ...

Steht wo?

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Jens Link

2008-11-10 11:23:20 UTC

Post by Oliver Schad
Das Ziel von IPv6 war mit IPSec sogar ein ganzes Internet so aufzubauen.

Irgendwo hab ich neulich in einem Nebensatz gelesen, dass M$ sein Netz
genau so umbauen will. Also keine zentralen Firewalls, sondern
Hostbasierende, IPSEC und IPv6. War in einem Artikel ueber DirectAccess
in Windows 7.

Jens

--
***@guug Berlin: http://www.guug.de/lokal/berlin/index.html
------
(Call-for-Papers) 10.-13.03.09 GUUG-Frühjahrsfachgespaech 2009
http://www.guug.de/veranstaltungen/ffg2009/

Richard W. Könning

2008-11-06 02:48:23 UTC

Post by Oliver Schad
Punkt 2: Regelmäßiges wechseln kommt nicht in Frage, es wird gewechselt
bei Verdacht auf Kompromittierung

Regelmaessiges Wechseln ist nicht verkehrt (man muss aber zwischen dem ggfs.
nicht unerheblichen aufwand und dem dadurch evt. erhaltenen Sicherheitsge-
winn abwaegen ...).

Regelmäßiges Wechseln führt regelmäßig dazu, daß Passwörter mit einem
vergleichsweise einfachen, regelmäßigen, Baumuster verwendet werden.

Post by Oliver Schad
Punkt 8: Passwörter werden nur bei Verdacht auf Kompromittierung
gewechselt.

Es ist gaengige Praxis, das anders zu handhaben (und der Sinn davon wird
auch von kaum jemanden ausser dir bestritten ...).

Oliver steht nicht allein da, ein Ross Anderson schreibt in "Security
Engineering, 2nd ed., p. 34":

|So when our university's auditors write in their annual report each year that
|we should have a policy of monthly enforced password change, my response
|is to ask the chair of our Audit Committee when we'll get a new lot of auditors.

Und auch meine Erfahrung ist, daß häufiges Wechseln zu schlechten
Passwörtern führt.

Post by Oliver Schad
Punkt 14: Schwachsinn, entweder ist das Ding auch am WE sicher oder es
gehört abgeschaltet

Wenn es nichts kostet, dann kann man es machen, es bringt allerdings
auch nicht viel (wäre es anders, dann gäbe es ein gewaltiges, noch
unentdecktes Verbesserungspotential an anderer Stelle). Und das ist
imho ein Problem mit der Auflistung auf der BSI-Website: die Punkte
werden ohne Gewichtung der Reihe nach aufgeführt, so daß die Gefahr
besteht, daß jemand die Qualität seiner Maßnahmen an der Zahl der
erfüllten Punkte mißt. Wenn die Punkte, die nur in seltenen Fällen
einen Gewinn bringen, abgetrennt und entsprechend kommentiert
aufgelistet wären, dann könnte man eher damit leben. So aber kann man
die Risikokompensationsdiskussion, die hier vor Jahren bei
Virenscannern bis zum Erbrechen geführt wurde, wieder aufwärmen.

Wenn das Abschalten minimaler Aufwand ist und nicht verhindert, daß
andere, wichtigere Aktionen unterbleiben, why not? Wenn diese
Randbedingungen aber nicht erfüllt sind, dann kann der Rat leicht
kontraproduktiv werden.
Ciao,
Richard

--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München

Lars Rohwedder

2008-11-07 12:23:56 UTC

Post by Juergen Ilse
... und ein Netzwerkkabel laesst sich leichter ueberwahcen als ein WLAN
(das geht allein mit "optischen Mittels" sprich hinsehen in voellig tri-
vialer Weise, beim WLAN ist das mit dem "erkennen durch hinsehen" eher
schwierig ...).

Bei einem Netzwerkkabel, das von meinem Rechner zu einem anderen
Rechner im gleichen quer über den Fußboden geht: ACK. Da reicht
Hinsehen aus. (Mal von Sniffern in RJ45-Steckern abgesehen)

Aber bei einer strukturierten Cat5-Verkabelung sehe ich nur das Kabel
von meinem Rechner zur Wandsteckdose und dann war's das. Regelmäßig die
Verkleidung der Brüstungskanäle abmachen, Kabel rausfriemeln und auf
Unversehrtheit prüfen, anschließend die Deckenplatten der abgehängten
Decken aufmachen, Kabel prüfen bis zum Schaltschrank und wieder zurück,
falls die Putzfrau während dieser Arbeiten für nen Moment unbeobachtet
im Raum war, das halte ich für nicht mehr wirklich trivial.

Somit kan so ein unbemerkt untergebrachter Sniffer irgendwo in einer
Zwischendecke jahrelang vor sich hinwerkeln, ehe er vielleiiiicht bei
der nächsten Renovierung bemerkt wird.

Lars R.

Paul Muster

2008-11-22 09:08:14 UTC

Post by Lars Rohwedder
Somit kan so ein unbemerkt untergebrachter Sniffer irgendwo in einer
Zwischendecke jahrelang vor sich hinwerkeln, ehe er vielleiiiicht bei
der nächsten Renovierung bemerkt wird.

Die knapp über Mindestlohn bezahlten Kräfte des externen Dienstleisters
werden sich hüten, sowas zu erwähnen. Die Zeit wird ihnen nicht bezahlt,
es gehört nicht zu ihrer Aufgabe.

mfG Paul

Juergen Ilse

2008-11-05 11:40:18 UTC

Hallo,

Post by Oliver Schad
sagt mal, wer hat eigentlich den BSI-Leuten so in's Hirn geschissen,
dass die die besten Tipps aus Chip oder Computer-Blöd als Absicherungen
empfehlen?
Ich mein vor Jahren hab ich ja schon mit dem Kopf geschüttelt
stellenweise, aber als ich neulich den Baustein Absicherung von APs
studierte, wurde mir schlecht.
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

Die meisten Hinweise sind doch voellig korrekt. OK, die Sache mit dem ab-
geschalteten SSID-Broadcast ist natuerlich Bloedsinn (fuehrt ggfs. dazu,
dass manche WLAN-Kartentreiber sich nicht mehr einbuchen koennen, Eindring-
linge werden aber dadurch eher von nichts abgehalten). MAC-Adressfilter
sind eigentlich auch Unfug, aber der Rest sieht doch gar nicht so verkehrt
aus. Der Anteil an Unfug in diesem Text ist also erheblich geringer als in
vielen Zeitschriftenartikeln. Warum kritisierst du den Text denn so hart?

Post by Oliver Schad
Und das soll ich so einrichten, damit ich nach außen hin behaupten kann,
ich tue was für IT-Sicherheit? HALLO?

Viele der Ratschlaege (WPA bzw. WPA2 nutzen, komplexe und lange preshared
keys verwenden, diese regelmaessig wechseln, was ist da denn falsch dran?).

Post by Oliver Schad
"Ja, tut mir leid, ich kann sie nicht zertifizieren, ihre APs sind
unsicher, die machen DHCP". Was zur Hölle haben die denn geraucht?

Gerade bei kleinen Netzen ohne staendig wechselnde Nutzer wuerde ich auch
vorziehen, mit statischer Adressvergabe statt mit DHCP zu arbeiten. Das hat
zwar nicht unbedingt Sicherheitsgruende, aber ...

Ueber MAC-Adressfilter, DHC, abgeschalteten SSID-Broadcast in diesem Hinweisen
sollte man evt. noch einmal nachdenken (ich halte das nicht fuer einen Sicher-
heitsgewinn), aber den Rest halte ich durchaus fuer sinnvoll und Sicherheits-
foerdernd.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Oliver Schad

2008-11-05 12:19:06 UTC

Die meisten Hinweise sind doch voellig korrekt. OK, die Sache mit dem
ab- geschalteten SSID-Broadcast ist natuerlich Bloedsinn (fuehrt ggfs.
dazu, dass manche WLAN-Kartentreiber sich nicht mehr einbuchen
koennen, Eindring- linge werden aber dadurch eher von nichts
abgehalten). MAC-Adressfilter sind eigentlich auch Unfug, aber der
Rest sieht doch gar nicht so verkehrt aus. Der Anteil an Unfug in
diesem Text ist also erheblich geringer als in vielen
Zeitschriftenartikeln. Warum kritisierst du den Text denn so hart?

Es sind 13 Punkte insgesamt, bei 7 Punkten sage ich Schwachsinn. Wieso
sollte ich das dann nicht kritisieren? Das Werk ist zufällig
öffentlichkeitswirksam und viele Unternehmen richten sich danach.

Post by Oliver Schad
Und das soll ich so einrichten, damit ich nach außen hin behaupten
kann, ich tue was für IT-Sicherheit? HALLO?

Viele der Ratschlaege (WPA bzw. WPA2 nutzen, komplexe und lange
preshared keys verwenden, diese regelmaessig wechseln, was ist da denn
falsch dran?).

Ich wechsel die Schlüssel dann, wenn sie als kompromittiert gelten,
vorher nicht.

Post by Oliver Schad
"Ja, tut mir leid, ich kann sie nicht zertifizieren, ihre APs sind
unsicher, die machen DHCP". Was zur Hölle haben die denn geraucht?

Gerade bei kleinen Netzen ohne staendig wechselnde Nutzer wuerde ich
auch vorziehen, mit statischer Adressvergabe statt mit DHCP zu
arbeiten. Das hat zwar nicht unbedingt Sicherheitsgruende, aber ...

Und genau was hat das dann dort zu suchen?

Post by Juergen Ilse
Ueber MAC-Adressfilter, DHC, abgeschalteten SSID-Broadcast in diesem
Hinweisen sollte man evt. noch einmal nachdenken (ich halte das nicht
fuer einen Sicher- heitsgewinn), aber den Rest halte ich durchaus fuer
sinnvoll und Sicherheits- foerdernd.

- WLAN-Komponenten sollen auch regelmäßig abgeschaltet werden, wenn sie
nicht benutzt werden, z.B. an Wochenenden
- Administrativer Zugang per WLAN verbieten
- SSIDs sollen gewechselt werden

Das ist doch einfach Unsinn.

1. Wenn das WLAN nicht den Sicherheitsanforderungen genügt, dann gehört
es nicht nur am Wochenende, sondern auch sonst abgeschaltet

2. Wenn der Administrationszugang unsicher ist, dann gehört er
abgeschaltet, fertig. Wer sagt denn bitte, dass die LAN-Seite keine
Angriffe bringen kann?

3. Informationen verstecken, die für einen Angriff sowieso unerheblich
sind und sich auch noch über andere Kanäle leicht beschaffen lassen,
ist einfach Schwachsinn

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.

Bernd Eckenfels

2008-11-05 16:45:19 UTC

Post by Juergen Ilse
Die meisten Hinweise sind doch voellig korrekt. OK, die Sache mit dem ab-
geschalteten SSID-Broadcast ist natuerlich Bloedsinn (fuehrt ggfs. dazu,
dass manche WLAN-Kartentreiber sich nicht mehr einbuchen koennen, Eindring-
linge werden aber dadurch eher von nichts abgehalten).

Und in einer Umgebung mit mehreren WLANs wird es den Leuten schwer gemacht
Kanal Konflikte zu erkennen und zu beheben.

Post by Juergen Ilse
Viele der Ratschlaege (WPA bzw. WPA2 nutzen, komplexe und lange preshared
keys verwenden, diese regelmaessig wechseln, was ist da denn falsch dran?).

Pre-Shared an sich ist ja schon falsch. Allerdings: wenn man einen VPN Layer
drüberlegt isses egal.

Post by Juergen Ilse
Gerade bei kleinen Netzen ohne staendig wechselnde Nutzer wuerde ich auch
vorziehen, mit statischer Adressvergabe statt mit DHCP zu arbeiten. Das hat
zwar nicht unbedingt Sicherheitsgruende, aber ...

Ach was, wir sind im 21. Jahrhundert. Da gibt es keine Netze ohne wechselnde
User. :)

Gruss
Bernd

Wolfgang Krietsch

2008-11-06 09:04:49 UTC

Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das seine
SSID nicht herausposaunt?

Bye

woffi

--
Mir ist schleierhaft, wieso man ausgerechnet ein Schaf geklont hat, wo die
doch sowieso alle gleich aussehen.

Michael H. Fischer

2008-11-06 09:34:22 UTC

Post by Wolfgang Krietsch
Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das seine
SSID nicht herausposaunt?

Ja.

Michael H. Fischer

--
Freeware und Antworten rund um NT/W2K/XP: http://www.derfisch.de/
Windows Tuning Mythen: http://www.derfisch.de/Tuning-Mythen.html

Jakobus Schuerz (usenet)

2008-11-15 12:20:27 UTC

Post by Wolfgang Krietsch
Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das seine
SSID nicht herausposaunt?

Ja.

Wie?

--
The UNIX way of Sex:
gunzip-strip-touch-finger-mount-fsck-more-yes-umount-sleep

Michael H. Fischer

2008-11-15 12:54:38 UTC

Jakobus Schuerz (usenet) schreibselte am 15.November 2008

Wie?

Kismet. http://www.kismetwireless.net/

Michael H. Fischer

--
Freeware und Antworten rund um W2K/XP/Vista: http://www.derfisch.de/
Windows Tuning Mythen: http://www.derfisch.de/Tuning-Mythen.html

Ulrich Grotehusmann

2008-11-15 13:43:31 UTC

Post by Wolfgang Krietsch
Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das

seine > SSID nicht herausposaunt?
Ja.

Wie?

$ /sbin/iwlist wlan0 scan

Cell 01 - Address: 00:12:BF:4A:35:E3
ESSID:"<hidden>"
Protocol:IEEE 802.11bg
Mode:Master
Channel:11
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
11 Mb/s; 12 Mb/s; 18 Mb/s; 22 Mb/s; 24
Mb/s 36 Mb/s; 48 Mb/s; 54 Mb/s
Quality=86/100 Signal level=-47 dBm Noise
level=-47 dBm IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Preauthentication Supported
Extra: Last beacon: 96ms ago

Ulrich

Juergen Ilse

2008-11-15 16:52:35 UTC

Hallo,

Post by Wolfgang Krietsch
Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das seine
SSID nicht herausposaunt?

Ja.

Wie?

Es ist leicht, solange ueber das WLAN kommuniziert wird (so lange es
wirklich in Benutzung ist).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Juergen Ilse

2008-11-06 09:50:20 UTC

Hallo,

Post by Wolfgang Krietsch

Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das seine
SSID nicht herausposaunt?

Ja, sofern darueber auch Daten transportiert werden. Und wenn keine Daten
darueber transportiert werden, kann man es auch abschalten, und somit jeg-
liche mit dem WLAN theoretisch moegliche angriffsflaeche ausschliessen ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Wolfgang Krietsch

2008-11-06 11:35:42 UTC

Post by Juergen Ilse
Ja, sofern darueber auch Daten transportiert werden.

Wie denn?

Hmm... ich hab ein iPhone und irgendwo mal gelesen, dass das Teil auch
WLANs zum Einloggen anbietet, die ihre SSID nicht publizieren - hab das
aber noch nie ausprobiert. Kann das *so* einfach sein?

Post by Juergen Ilse
Und wenn keine Daten
darueber transportiert werden, kann man es auch abschalten, und somit jeg-
liche mit dem WLAN theoretisch moegliche angriffsflaeche ausschliessen ...

Klar. aber WLAN abschalten ist z. B. für mich unpraktikabel, da ich ja
nicht wirklich "plane", wann ich's brauche und wann nicht; ich denke, dass
das vielen so geht, zumindest im privaten Bereich.

Bye

woffi

--
Die Nichtexistenz eines Beweises ist kein Beweis für die
Nichtexistenz

Juergen Ilse

2008-11-06 17:17:01 UTC

Hallo,

Post by Wolfgang Krietsch

Post by Juergen Ilse
Ja, sofern darueber auch Daten transportiert werden.

Wie denn?

Die SSID wird nicht nur in den SSID-Broadcasts sondern auch in den ueber-
tragenen Datenpaketen mitgesendet ... Genauso wie die MAC-Adressen der
sendenden WLAN-Karten (womit sich dann auch erklaeren laesst, warum MAC-
Adfressfilter kein so dolles Sicherheitskonzept sein koennen ...).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Lars Rohwedder

2008-11-07 12:27:36 UTC

Post by Wolfgang Krietsch
Klar. aber WLAN abschalten ist z. B. für mich unpraktikabel, da ich ja
nicht wirklich "plane", wann ich's brauche und wann nicht; ich denke, dass
das vielen so geht, zumindest im privaten Bereich.

Bei solchen Superduperkombiboxen für Privatleute, z.B. der Fritzbox,
kann man z.B. über sein Telefon, das an der Fitzbox hängt, das WLAN
ein- und ausschalten. Wenn im "Homeoffice" also neben dem PC ein
Telefon steht, hebt man ab, wählt *1234# oder so, und dann läuft das
WLAN, bis man es mit einem 2. Anruf wieder deaktiviert.

Gerade im privaten Bereich ist sowas machbar, im Büro eher nicht, außer
als Scherz um die Kollegen zu ärgern...

Lars R.

Juergen P. Meier

2008-11-07 06:39:51 UTC

Post by Wolfgang Krietsch

Warum eigentlich nicht? Ist es so leicht, ein WLAN aufzuspüren, das seine
SSID nicht herausposaunt?

*Jedes* WLAN Posaunt seine SSID laut heraus.

Diejenigen, die "[X] SSID Verstecken!!!elf" eingeschaltet haben, haben
in ihren Paketen lediglich ein Bit gesetzt, dass Empfaenger anweist
(bitte bitte!), beim auslesen der SSID die Augen fest zuzukneifen.

Soweit die technische Erklaerung, wie SSID-"Verstecken" funktionoiert.
Es wird an jedes WLAN-Paket ein Schild drangepappt, auf dem Steht
"Die SSID in diesem Paket gilt als unsichtbar, bitte als versteckt
betrachten!"

Kein Scheiss, das ist wirklich so. (nachzulesen in IEEE 802.11)

Juergen

Wolfgang Krietsch

2008-11-07 09:13:56 UTC

Post by Juergen P. Meier
Soweit die technische Erklaerung, wie SSID-"Verstecken" funktionoiert.
Es wird an jedes WLAN-Paket ein Schild drangepappt, auf dem Steht
"Die SSID in diesem Paket gilt als unsichtbar, bitte als versteckt
betrachten!"

Demnach ist es also wirklich gut möglich, dass irgendein Gerät (wie z. B.
das iPhone) sich nicht drum schert, die Augen halt nicht zukneift und
"regelwidrig" einfach doch die SSID anzeigt/zum Connect anbietet?

Ulkige Sachen gibt's

Bye

woffi

--
Top Ten Times in history when saying F**K was appropriate:
6) "How the f**k did you work that out?" - Pythagoras

Juergen P. Meier

2008-11-08 08:07:48 UTC

Post by Wolfgang Krietsch
Demnach ist es also wirklich gut möglich, dass irgendein Gerät (wie z. B.
das iPhone) sich nicht drum schert, die Augen halt nicht zukneift und
"regelwidrig" einfach doch die SSID anzeigt/zum Connect anbietet?

Dedizierte WLAN Sniffer gibts fuer ein paar Euro im Versandhandel
oder bei $ELEKTRONIKLADEN in der Stadt (Geraete mit kleinem Display,
die gefudnene SSIDs mit Signalstaerke anzeigen).

Da muss man kein iPhone kaufen (fuer das es natuerlich passende
Software gibt ;-)

Post by Wolfgang Krietsch
Ulkige Sachen gibt's

Ja. Dummerweise ist der Besitz in Deutschland strafbar (StGB §202c).

Das betrifft auch die iPhone-Programme!

Juergen

Thomas Einzel

2008-11-08 11:06:50 UTC

Juergen P. Meier schrieb am 08.11.2008 09:07:
...

Post by Juergen P. Meier
Dedizierte WLAN Sniffer gibts fuer ein paar Euro im Versandhandel
oder bei $ELEKTRONIKLADEN in der Stadt (Geraete mit kleinem Display,
die gefudnene SSIDs mit Signalstaerke anzeigen).

...

Post by Juergen P. Meier
Ja. Dummerweise ist der Besitz in Deutschland strafbar (StGB §202c).

...

aha, gibt es bereits Feststellungen eines Gerichtes die der Vermutung
auf
http://www.jurablogs.com/de/die-vorboten-von-202c-stgb-das-ende-von-kismac

"Denn alleine das Auffinden von Computernetzwerken und deren
spezifischen Informationen (SSID, Frequenz, Signalstärk, Vendor-ID,
Verschlüsselungsart) sind keine tauglichen Tatbestandsmerkmale der §§
202a und 202b StGB."
widersprechen?
Bisher habe ich Hilfsmittel die _nur_ dieses können als
Netzwerkwerkzeuge betrachtet?

Thomas

Wilfried Kramer

2008-11-08 11:42:56 UTC

Ja, eine Einschaetzung die einen DHCP-Request in einem offenen WLAN
so einschaetzte gab es in einem Gercihtsurteil, dass zum Einzug eines
Laptops und einer Verwarnung fuehrte (im Wiederholungsfall waeren es

Nun, in diesem Fall ging es aber nicht um einen (Zahlwort) DHCP-Request.

Wilfried

--
Meine Meinung ist Public Domain.
Jeder darf sie sich zu eigen machen.

Lars Rohwedder

2008-11-08 20:34:01 UTC

Wenn ein DHCP-Request in einem WLAN schon das "abhoeren fernmeldetechnischer

^^^^^^^ ^^^^^^^^

Requests werden (korrigier mich, wenn ich mich irre) ausgesendet, damit
ist das kein passives Abhören mehr, sondern aktives Eingreifen in die
"fernmeldetechnische Anlage".

Ein Scanner ist dagegen rein passiv und sollte, sofern seine ICs nicht
zu viel Störstrahlung aussenden, nicht ins Geschehen eingreifen.

Lars R.

Juergen Ilse

2008-11-08 21:30:24 UTC

Hallo,

Post by Lars Rohwedder

Wenn ein DHCP-Request in einem WLAN schon das "abhoeren fernmeldetechnischer

^^^^^^^ ^^^^^^^^
Requests werden (korrigier mich, wenn ich mich irre) ausgesendet, damit
ist das kein passives Abhören mehr, sondern aktives Eingreifen in die
"fernmeldetechnische Anlage".

... das nur allzu oft aber "unabsichtlich" geschieht (viele Betriebsysteme
versuchen bei aktivieren des WLAN-Interfaces per Default sich in das naechste
erreichbare WLAN einzubuchen und senden dort dann auch einen DHCP-Request,
um mit den erhaltenen Daten das Netzwerk zu konfigurieren ...).

Post by Lars Rohwedder
Ein Scanner ist dagegen rein passiv und sollte, sofern seine ICs nicht
zu viel Störstrahlung aussenden, nicht ins Geschehen eingreifen.

Es wuerde aber vermutlich als "Vorbereitung fuer einen Angriff" ausgelegt
werden koennen (warum sonst sollte man sich ueber die vorhandenen WLAN-Netze
informieren wollen???). Ich weiss, es gibt genug Gruende, vorhandene WLANs
ermitteln zu wollen (z.B. um den am wenigsten belegten Kanal fuer das eigene
WLAN-Netz auszuwaehlen), aber ich sehe das absenden eines DHCP-Requests auch
nicht als Versuch, eine "fernmeldetechnische Anlage abzuhoeren" und eine
RFC1918-Adresse nicht als "personenbezogenes Datum" ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Lars Rohwedder

2008-11-08 21:49:39 UTC

Post by Lars Rohwedder

Wenn ein DHCP-Request in einem WLAN schon das "abhoeren fernmeldetechnischer

^^^^^^^ ^^^^^^^^
Requests werden (korrigier mich, wenn ich mich irre) ausgesendet, damit
ist das kein passives Abhören mehr, sondern aktives Eingreifen in die
"fernmeldetechnische Anlage".

"Mein System führt Flood-Pings auch unabsichtlich aus" ;-)

Es macht aber andere Dinge unabsichtlich, z.B. wenn DHCP fehlschlägt,
versucht es auf gut Glück, ob eine der letzten IP-Adressen, die
zugeteilt wurden, noch valide sind (durch Anpingen des Gateways? keine
Ahnung). :-(

Aber wenn das System unabsichtlich in "fremde fernmeldetechnische
Anlagen eingreift", handelt man vielleicht fahrlässig? Keine Ahnung,
was kranke Juristenhirne da zurechtspinnen können... :-(

Post by Juergen Ilse
Es wuerde aber vermutlich als "Vorbereitung fuer einen Angriff" ausgelegt
werden koennen (warum sonst sollte man sich ueber die vorhandenen WLAN-Netze
informieren wollen???).

ACK, das bestätigt meine Sorge bzgl. kranker Juristenhirne...

Post by Juergen Ilse
[...] aber ich sehe [...]

Damit hast du deine Sichtweise, die Gegenseite vor Gericht mag eine andere
Sichtweise auf die Dinge haben. Wessen Argumenten der Richter dann eher
glaubt, kann man z.B. durch das Werfen einer Münze herausfinden,
zumindest mit 50%iger Wahrscheinlichkeit... Oder man erklärt dem
Richter den Sachverhalt nochmal am Vorabend der Urteilsverkündung in
einem teuren Restaurant und lässt beim Gehen einen Geldkoffer
"unabsichtlich" stehen... Ach nee, sowas macht ja keiner, ich vergaß...

Lars R.

Thomas Einzel

2008-11-09 10:03:52 UTC

Juergen Ilse schrieb am 08.11.2008 22:30:
...

Post by Juergen Ilse
Es wuerde aber vermutlich als "Vorbereitung fuer einen Angriff" ausgelegt
werden koennen (warum sonst sollte man sich ueber die vorhandenen WLAN-Netze
informieren wollen???). Ich weiss, es gibt genug Gruende, vorhandene WLANs
ermitteln zu wollen (z.B. um den am wenigsten belegten Kanal fuer das eigene
WLAN-Netz auszuwaehlen)

Zum Beispiel. Oder um Fehler/Probleme der eigenen APs zu analysieren.

Wann wird eigentlich endlich der Besitz solcher gefährlichen Dinge wie
Multimeter, Oszilloskope oder gar Lötkolben unter Strafe gestellt?

Hilfe...

Thomas

Juergen Ilse

2008-11-09 12:31:08 UTC

Hallo,

Post by Thomas Einzel
...

Zum Beispiel. Oder um Fehler/Probleme der eigenen APs zu analysieren.
Wann wird eigentlich endlich der Besitz solcher gefährlichen Dinge wie
Multimeter, Oszilloskope oder gar Lötkolben unter Strafe gestellt?

Allzulange kann es nicht mehr dauern ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Jakobus Schuerz (usenet)

2008-11-15 12:33:24 UTC

Post by Juergen Ilse
Hallo,

Post by Thomas Einzel
...

Zum Beispiel. Oder um Fehler/Probleme der eigenen APs zu analysieren.
Wann wird eigentlich endlich der Besitz solcher gefährlichen Dinge wie
Multimeter, Oszilloskope oder gar Lötkolben unter Strafe gestellt?

Allzulange kann es nicht mehr dauern ...

Wann kommen endlich die Roboter, die sich selbst bauen und bugfrei
funktionieren. Dann könnten wir endlich auf sämtliche humanen
Lebensformen verzichten, und es könnte uns nichts mehr passieren...

:-(

lg jakob

--
The UNIX way of Sex:
gunzip-strip-touch-finger-mount-fsck-more-yes-umount-sleep

Andreas Kohlbach

2008-11-09 00:13:20 UTC

Post by Thomas Einzel
"Denn alleine das Auffinden von Computernetzwerken und deren
spezifischen Informationen (SSID, Frequenz, Signalstärk, Vendor-ID,
Verschlüsselungsart) sind keine tauglichen Tatbestandsmerkmale der §§
202a und 202b StGB."
widersprechen?

Wenn ein DHCP-Request in einem WLAN schon das "abhoeren fernmeldetechnischer
Anlagen" und darueber hinaus auch noch einen "moeglichen Verstoss des Daten-
schutzgesetzes" darstellt, wuerde mich eine Entscheidung, die einen WLAN-
Scanner als "Hackertool" einstuft, nicht wirklich wundern ...

Wurde es nicht mal angedacht (was ist daraus geworden, wenn?), dass Linux
auch bereits pöhse ist, weil es IIRC einen "Kopierschutz" für CDs gab,
die irgendwie die Autostart-Funktion der CD von Windows verwendeten,
Linux das aber ignoriert?

Irgendwann sind alle Straftäter, die nicht genau ein Windows von der
Stange haben, und ja nichts an Software (oder gar ein anderes, beliebiges
OS) installieren, die nicht von MS und Bundesregierung zertifiziert
wurden.

--
Andreas (PGP Key available on public key servers)
74. I remember the last time I saw it do that...
--Top 100 things you don't want the sysadmin to say

Wolfgang Krietsch

2008-11-08 12:54:19 UTC

Post by Juergen P. Meier
Ja. Dummerweise ist der Besitz in Deutschland strafbar (StGB §202c).
Das betrifft auch die iPhone-Programme!

Ich hatte das so verstanden, dass das iPhone das von Haus aus könne - und
das iPhone ist sicher nicht strafbar. Aber womöglich hat man mir da auch
Unsinn erzählt, oder ich hab's falsch verstanden.

Bye

woffi

--
In fact, the metaphors in this book are more useless than a weasel
in a cardboard shirt.
- Scott Adams, "The Dilbert Priciple"

Gerald Vogt

2008-11-09 09:32:43 UTC

Post by Juergen P. Meier
*Jedes* WLAN Posaunt seine SSID laut heraus.
Diejenigen, die "[X] SSID Verstecken!!!elf" eingeschaltet haben, haben
in ihren Paketen lediglich ein Bit gesetzt, dass Empfaenger anweist
(bitte bitte!), beim auslesen der SSID die Augen fest zuzukneifen.
Soweit die technische Erklaerung, wie SSID-"Verstecken" funktionoiert.
Es wird an jedes WLAN-Paket ein Schild drangepappt, auf dem Steht
"Die SSID in diesem Paket gilt als unsichtbar, bitte als versteckt
betrachten!"
Kein Scheiss, das ist wirklich so. (nachzulesen in IEEE 802.11)

Kannst Du das genauer belegen? Wenn ich meinen Sniffer anwerfe, dann
erscheint die SSID nicht. Die erscheint erst dann, wenn sich jemand
mit dem WLAN verbindet oder bei bestimmten anderen Paketen.

Meines Wissens wird beim Abschalten des SSID Broadcasts die SSID aus
den Beacons entfernt. Da wird also kein Bit im Protokoll gesetzt,
sondern die SSID wird im Beacon gar nicht übertragen. In dem Sinne
wird also auch nichts "herausposaunt". Da die SSID z.B. bei der
Assoziierung mit dem Access Point unverschlüsselt übertragen wird,
muss man nur lange genug warten, bis ein WLAN Client sich verbindet.

Die SSID ist auch nicht Teil jedes WLAN Pakets, sondern nur mancher
Pakete.

Das deckt sich auch mit dem, was ich mit dem Sniffer sehe.

Siehe auch http://en.wikipedia.org/wiki/SSID

Wenn ich nicht irre, kann man die SSID eines Access Points ohne SSID
Broadcast, zu dem keine Clients verbunden sind, nicht herausfinden.

Gerald

Fritz Schoerghuber

2008-11-09 12:24:02 UTC

Post by Gerald Vogt

Kannst Du das genauer belegen? Wenn ich meinen Sniffer anwerfe, dann
erscheint die SSID nicht. Die erscheint erst dann, wenn sich jemand
mit dem WLAN verbindet oder bei bestimmten anderen Paketen.
Meines Wissens wird beim Abschalten des SSID Broadcasts die SSID aus
den Beacons entfernt. Da wird also kein Bit im Protokoll gesetzt,
sondern die SSID wird im Beacon gar nicht übertragen. In dem Sinne
wird also auch nichts "herausposaunt". Da die SSID z.B. bei der
Assoziierung mit dem Access Point unverschlüsselt übertragen wird,
muss man nur lange genug warten, bis ein WLAN Client sich verbindet.
Die SSID ist auch nicht Teil jedes WLAN Pakets, sondern nur mancher
Pakete.
Das deckt sich auch mit dem, was ich mit dem Sniffer sehe.
Siehe auch http://en.wikipedia.org/wiki/SSID
Wenn ich nicht irre, kann man die SSID eines Access Points ohne SSID
Broadcast, zu dem keine Clients verbunden sind, nicht herausfinden.

Er meint wahrscheinlich:

"The SSID must be broadcast with Probe Response frames. In addition, the
wireless access cards will broadcast the SSID in their Association and
Reassociation frames." (Zitat aus tech-faq.com)

Mit dem Fluke-Etherscope und einer WLAN-Karte kannst Du so ziemlich
alles ueber die Accesspoints herausfinden. Auch wenn die SSID
"versteckt" wird. BTST.

http://www.flukenetworks.com/fnet/de-de/products/Etherscope+Series+II/Overview.htm?categorycode=LANH

hth
fritz.schoerghuber

Juergen Ilse

2008-11-09 12:35:22 UTC

Hallo,

Post by Gerald Vogt
Wenn ich nicht irre, kann man die SSID eines Access Points ohne SSID
Broadcast, zu dem keine Clients verbunden sind, nicht herausfinden.

In dem Moment findet keine Kommunikation des WLAN-APs mit der Aussenwelt
statt. Dass man ein "nicht gefuehrtes Gespraech" nicht belauschen kann,
ist nicht sonderlich ueberraschend ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Gerald Vogt

2008-11-09 12:53:21 UTC

Post by Juergen Ilse
Hallo,

Post by Gerald Vogt
Wenn ich nicht irre, kann man die SSID eines Access Points ohne SSID
Broadcast, zu dem keine Clients verbunden sind, nicht herausfinden.

In dem Moment findet keine Kommunikation des WLAN-APs mit der Aussenwelt
statt. Dass man ein "nicht gefuehrtes Gespraech" nicht belauschen kann,
ist nicht sonderlich ueberraschend ...

Der AP schickt immer noch seine Beacons. Man kann aber trotzdem nicht
die SSID herausfinden, solange es keinerlei aktive WLAN Verbindungen
gibt. Das wäre ein Indiz dafür, dass die Aussage von Jürgen nicht ganz
korrekt war. (Das ein einsamer AP ein relativ langweiliges Szenario
ist, ist klar.)

Es ging mir im Wesentlichen darum, dass der AP die SSID eben nicht
"rausposaunt", d.h. nicht bei "jedem WLAN Paket" dabei ist und nur
durch ein einfaches Bit "SSID verstecken" markiert ist. Ganz sooo
leicht ist die SSID also nicht herauszufinden. Es ist in einem aktiven
WLAN zwar immer noch einfach und mit Paket Injection sogar sehr
schnell möglich, aber es ist eben nicht nur ein Bit in einem Paket,
indem die SSID trotzdem drinnen stehen würde. So hätte ich aber Jürgen
verstanden.

Gerald

Richard W. Könning

2008-11-09 21:49:57 UTC

Post by Gerald Vogt
Es ging mir im Wesentlichen darum, dass der AP die SSID eben nicht
"rausposaunt", d.h. nicht bei "jedem WLAN Paket" dabei ist und nur
durch ein einfaches Bit "SSID verstecken" markiert ist. Ganz sooo
leicht ist die SSID also nicht herauszufinden. Es ist in einem aktiven
WLAN zwar immer noch einfach und mit Paket Injection sogar sehr
schnell möglich, aber es ist eben nicht nur ein Bit in einem Paket,
indem die SSID trotzdem drinnen stehen würde. So hätte ich aber Jürgen
verstanden.

Jürgen wird uns sicherlich die entsprechenden Teile von 802.11
vorlesen ;-).
Ciao,
Richard

--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München

Gerald Vogt

2008-11-13 12:37:10 UTC

Post by Richard W. KÃ¶nning

Jürgen wird uns sicherlich die entsprechenden Teile von 802.11
vorlesen ;-).

Das wäre gut. Ich habe den 802.11-2007 durchgeblättert, aber da finde
ich nichts, was auf ein Bit "SSID verstecken" hindeuten würde.
Entweder ist ein SSID Feld im Frame drin oder nicht. An manchen
Stellen muss die SSID im Feld sein, an anderen Stellen wie z.B. dem
Beacon kann das Feld auch leer bleiben.

Gerald

Dennis Herbrich

2008-11-06 14:38:51 UTC

Post by Oliver Schad
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm
Und das soll ich so einrichten, damit ich nach außen hin behaupten kann,
ich tue was für IT-Sicherheit? HALLO?

Das Dokument[1] enthält derart oft das schöne Wörtchen "sollte", dass es
beinahe trivial ist, es in dieser Fassung erfolgreich[1] als
Zertifizierungsgrundlage[1] zu verwenden. Falls jemand tatsächlich derart
merkbefreit ist, dies einzufordern.

Und in dem Moment, wo von der Vorlage inhaltlich abgewichen wird, mit
der Begründung, dass ja bestimmte "sollte"s doch eher zum "muss" werden
müssen, wirft man die kategorische Gültigkeit des unfehlbaren
BSI-Grundschutzes der individuellen Interpretation zum Fraß vor, und man
erstellt doch wieder letzten Endes etwas eigenes und hoffentlich
*sinnvolles* auf der Basis dieses Pamphlets. So baut sich jeder seine
eigene Wahrheit, "basierend" auf den über alle Zweifel erhabenen Dogmen
des BSI, die jeder *echte* IT-Leiter selbstverständlich wortgetreu
rezitieren zu können imstande ist.

Wieso fühle ich mich jetzt plötzlich an Bibelzirkel erinnert?

Gruß,
Dennis

---- footnotes:
[1] - I use this term loosely.

Henning Weede

2008-11-22 22:16:29 UTC

Post by Oliver Schad
sagt mal, wer hat eigentlich den BSI-Leuten so in's Hirn geschissen,
dass die die besten Tipps aus Chip oder Computer-Blöd als Absicherungen
empfehlen?
Ich mein vor Jahren hab ich ja schon mit dem Kopf geschüttelt
stellenweise, aber als ich neulich den Baustein Absicherung von APs
studierte, wurde mir schlecht.
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

Ich versuch gerade mir vorzustellen ich müsste in einem dieser
Saftläden arbeiten, die tatsächlich ohne Rücksicht auf Verluste
diesen ganzen BSI-Schwachsinn 1:1 umsetzen.
- Neuer PC lässt sich nur in einer Körperhaltung wie eine alte Frau
beim Autofahren benutzen. Versuch, große Symbole und große Schrift
einzustellen, scheitert mangels Administrator-Passwort.
- Neuer PC hat auf einmal Office13 statt Office10 drauf - nichts
geht mehr. Versuch, den Zauber in Ordnung zu bringen, scheitert
mangels Administrator-Passwort.
- Beim auswärtigen Meeting mit zwei Partnerfirmen eines Verbundvorhabens
nutzen alle den CVS-Server um die besprochenen Änderungen am
Eclipse-Projekt sofort hochzuladen. Nur ich bin offline. Ein Versuch,
die Netzwerkeinstellungen zu korrigieren, scheitert mangels
Administrator-Passwort. Erst eine Woche später wird mir einfallen,
dass mein Eclipse mit einem "Socks Proxy" eingestellt ist und ich das
hätte wegmachen müssen, wenn ich auswärts, zu Gast bei einer weniger
kranken Firma, versuche online zu gehen.
Im weiteren Verlauf des Meetings wird mir eine interessante
Literaturquelle als PDF angeboten. Darf ich nicht annehmen,
meine Mami^H^H^HLeiter IT hat mir verboten, die USB-Schnittstelle
zu benutzen, und deswegen funktioniert sie auch nicht.
- Für das knifflige Problem eines Kunden hab ich am Wochenende
zuhause etwas passendes programmiert. Versuch, diesen Quellcode
vom USB-Stick zu kopieren, scheitert - USB-Schnittstelle gesperrt.
- Nachdem ich das Zeug wutschnaubend von Hand nochmal eingetippt hab
stell ich fest: MinGW fehlt, ich kann es nicht compilieren.
Versuch, MinGW zu downloaden scheitert - aus irgendwelchen Gründen
funktioniert FTP nicht.
- Nachdem ich MinGW installiert und an meinem Programm weitergestrickt habe,
stell ich am nächsten Tag fest: wie von Geisterhand ist MinGW wieder
verschwunden.
- Vor Frust versuche ich erstmal zu websurfen und bei SPON zu gucken
was es neues gibt. Da sehe ich statt SPON das Firmenlogo meines
Brötchengebers, den Titel "Die Leitsätze unseres Unternehmens" und
einen langen Text.
- Vor Schreck kippe ich meinen Kaffee um. Beim Säubern des Schreibtischs
fällt mir auf, dass das Tastaturkabel mit einem merkwürdigen Knubbel
versehen ist, wie ich ihn noch nie gesehen hab.
- Das Telefon klingelt. Ich soll zum Geschäftsführer kommen.
Mit am Tisch sitzt auch der Leiter IT und jemand vom Betriebsrat.
"Herr Weede, wir hätten da ein paar Fragen an Sie."

Man achte als Ingenieurwissenschaftler darauf, wo man sich anheuern lässt
und wo klugerweise nicht.

Henning

Holger Marzen

2008-11-23 08:10:08 UTC

Post by Oliver Schad
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

Anruf bei der internen IT sollte gnügen. Arbeitsmittel müssen
ergonomisch sein.

Post by Henning Weede
- Neuer PC hat auf einmal Office13 statt Office10 drauf - nichts
geht mehr. Versuch, den Zauber in Ordnung zu bringen, scheitert
mangels Administrator-Passwort.

Wenn das Unternehmen entschieden hat, Office13 auszurollen, wirst du das
als Arbeitsmittel akzeptieren müssen. Wenn du damit deinen Job nicht
machen kannst, stellst du eben eine Sonderanforderung. Am besten achtest
du schon vorher drauf, dass du nicht Probleme statt Lösungen
erarbeitest. Aufwändige, extrem abhängige Makrogebilde für Office-Pakete
ist mit das Schlimmste, was sich eine interne IT vorstellen kann. Das
ist übrigens ein gewichtiger Grund, warum OpenOffice noch nicht
dominiert in den Unternehmen.

Post by Henning Weede
- Beim auswärtigen Meeting mit zwei Partnerfirmen eines Verbundvorhabens
nutzen alle den CVS-Server um die besprochenen Änderungen am
Eclipse-Projekt sofort hochzuladen. Nur ich bin offline. Ein Versuch,
die Netzwerkeinstellungen zu korrigieren, scheitert mangels
Administrator-Passwort. Erst eine Woche später wird mir einfallen,
dass mein Eclipse mit einem "Socks Proxy" eingestellt ist und ich das
hätte wegmachen müssen, wenn ich auswärts, zu Gast bei einer weniger
kranken Firma, versuche online zu gehen.
Im weiteren Verlauf des Meetings wird mir eine interessante
Literaturquelle als PDF angeboten. Darf ich nicht annehmen,
meine Mami^H^H^HLeiter IT hat mir verboten, die USB-Schnittstelle
zu benutzen, und deswegen funktioniert sie auch nicht.

Dein Arbeitgeber hat diese Nutzungsart explizit erlaubt? Vermutlich
nicht. Fordere ein "Sonder-Notebook" mit erweiterten Rechten (und
vermutlich Pflichten) an, wenn es als Arbeitsmittel nicht zu gebrauchen
ist.

Post by Henning Weede
- Für das knifflige Problem eines Kunden hab ich am Wochenende
zuhause etwas passendes programmiert. Versuch, diesen Quellcode
vom USB-Stick zu kopieren, scheitert - USB-Schnittstelle gesperrt.

Ist das vom Unternehmen vorgesehen? Wenn ja, Störungsmeldung. Wenn nein,
Sonderanforderung.

Post by Henning Weede
- Nachdem ich das Zeug wutschnaubend von Hand nochmal eingetippt hab
stell ich fest: MinGW fehlt, ich kann es nicht compilieren.
Versuch, MinGW zu downloaden scheitert - aus irgendwelchen Gründen
funktioniert FTP nicht.

Du möchtest selbst Software auf deinem Dienstnotebook installieren? Das
dürfte kaum vorgesehen und erlaubt sein -> Sonderanforderung.

Post by Henning Weede
- Nachdem ich MinGW installiert und an meinem Programm weitergestrickt habe,
stell ich am nächsten Tag fest: wie von Geisterhand ist MinGW wieder
verschwunden.

Oh, Sondersoftware installiert. Das solltest du gleich melden, sonst
droht Er- oder Abmahnung.

Post by Henning Weede
- Vor Frust versuche ich erstmal zu websurfen und bei SPON zu gucken
was es neues gibt. Da sehe ich statt SPON das Firmenlogo meines
Brötchengebers, den Titel "Die Leitsätze unseres Unternehmens" und
einen langen Text.

Privates Surfen erlaubt? Auch ohne den Firmenproxy?

Post by Henning Weede
- Vor Schreck kippe ich meinen Kaffee um. Beim Säubern des Schreibtischs
fällt mir auf, dass das Tastaturkabel mit einem merkwürdigen Knubbel
versehen ist, wie ich ihn noch nie gesehen hab.
- Das Telefon klingelt. Ich soll zum Geschäftsführer kommen.
Mit am Tisch sitzt auch der Leiter IT und jemand vom Betriebsrat.
"Herr Weede, wir hätten da ein paar Fragen an Sie."

Da du ziemlich viel angestellt hast und abmahngefährdet bist, solltest
Du anbieten, dass das Problem mit der nicht ausreichenden Software und
den nicht ausreichenden Berechtigungen auf organisatorischer Ebene
(Adminkennwort ganz offiziell für dich) gelöst wird und du freiwillig
auf größere Wellen wegen des Eindringens in deine Privatsphäre und der
nicht erlaubten heimlichen Leistungsüberwachung verzichtest.

Post by Henning Weede
Man achte als Ingenieurwissenschaftler darauf, wo man sich anheuern lässt
und wo klugerweise nicht.

Man macht sich kundig, wozu die Arbeitsmittel gedacht sind, und ob sie
ausreichen. Wenn nicht, stellt man offiziell die nötigen Anforderungen.

Ich bin übrigens Ingenieur und arbeite nicht bei der internen IT :-)

Lars Rohwedder

2008-11-23 12:34:10 UTC

Post by Henning Weede
- Neuer PC lässt sich nur in einer Körperhaltung wie eine alte Frau
beim Autofahren benutzen. Versuch, große Symbole und große Schrift
einzustellen, scheitert mangels Administrator-Passwort.

Anruf bei der internen IT sollte gnügen. Arbeitsmittel müssen
ergonomisch sein.

Zumindest, wenn die Firma ein Interesse daran hat, dass die
Angestellten mehr Produktivität haben, als sie kosten. Und anständige
Arbeitsmittel sollten schon dazu dienen, die Produktivität zu erhöhen,
niht, sie zu zerstören.

Post by Henning Weede
- Beim auswärtigen Meeting [...]

ACK. Und zum Thema "ungenügende Arbeitsmittel" siehe oben. :-)

Post by Holger Marzen
[...] Sonderanforderung.
[...] Sonderanforderung.

Puh, klingt ja echt aufwändig. :-(

Privates Surfen erlaubt? Auch ohne den Firmenproxy?

Bei uns gottseidank ja. Allerdings mit einem anderen User-Account, der
spezielle iptables-Regeln hat, dass dieser nicht ins interne Netz darf,
damit nicht der Browser via JavaScript das interne Netz ausspionieren
kann.

Post by Henning Weede
Man achte als Ingenieurwissenschaftler darauf, wo man sich anheuern
lässt und wo klugerweise nicht.

Man macht sich kundig, wozu die Arbeitsmittel gedacht sind, und ob sie
ausreichen. Wenn nicht, stellt man offiziell die nötigen Anforderungen.

Joa, außer man (Mitarbeiter und Firma) ist zufrieden damit, dass man
zwar alle Policies strikt einhält, aber dafür eben nicht mehr seine
Arbeit machen kann. Dann streicht man eben jeden Monat sein Gehalt ein
und macht "Dienst nach Vorschrift", soweit eben möglich. Falls nicht,
tut man eben so.

Lars 'traumtänzer' R.

Henning Weede

2008-11-24 02:02:19 UTC

Post by Holger Marzen
Wenn das Unternehmen entschieden hat, Office13 auszurollen, wirst du das
als Arbeitsmittel akzeptieren müssen.

...

Post by Holger Marzen
Dein Arbeitgeber hat diese Nutzungsart explizit erlaubt? Vermutlich
nicht.

...

Post by Holger Marzen
Ist das vom Unternehmen vorgesehen?
Du möchtest selbst Software auf deinem Dienstnotebook installieren? Das
dürfte kaum vorgesehen und erlaubt sein

...

Post by Holger Marzen
Oh, Sondersoftware installiert. Das solltest du gleich melden, sonst
droht Er- oder Abmahnung.

...

Post by Holger Marzen
Privates Surfen erlaubt? Auch ohne den Firmenproxy?

...

Post by Holger Marzen
Man macht sich kundig, wozu die Arbeitsmittel gedacht sind, und ob sie
ausreichen.

Der letzte, der mir ähnliches vorgetragen hat, hieß Detlef Bosau.

Henning

Holger Marzen

2008-11-24 07:17:42 UTC

Post by Holger Marzen
Wenn das Unternehmen entschieden hat, Office13 auszurollen, wirst du das
als Arbeitsmittel akzeptieren müssen.

...

Post by Holger Marzen
Dein Arbeitgeber hat diese Nutzungsart explizit erlaubt? Vermutlich
nicht.

...

Post by Holger Marzen
Ist das vom Unternehmen vorgesehen?
Du möchtest selbst Software auf deinem Dienstnotebook installieren? Das
dürfte kaum vorgesehen und erlaubt sein

...

Post by Holger Marzen
Oh, Sondersoftware installiert. Das solltest du gleich melden, sonst
droht Er- oder Abmahnung.

...

Post by Holger Marzen
Privates Surfen erlaubt? Auch ohne den Firmenproxy?

...

Post by Holger Marzen
Man macht sich kundig, wozu die Arbeitsmittel gedacht sind, und ob sie
ausreichen.

Der letzte, der mir ähnliches vorgetragen hat, hieß ****** *****.

So ist nun mal die Realität in vielen größeren Unternehmen, in denen
wegen Fusionen Leute landen, die einen viel freieren Arbeitsstil gewohnt
sind, weil sie mal in kleineren Unternehmen gearbeitet haben. Den
geforderten korrekten Umgang mit Arbeitsanweisungen und Arbeitsmitteln
mag man gut finden oder schlecht, aber ich habe gelernt, dass man sich
am besten an die Spielregeln hält (zumal man dafür bezahlt wird).

Ich habe solch eine Entwicklung mitmachen dürfen/müssen, vom
"freischaffenden Künstler", dessen Changemanagement darin bestanden hat,
über dan Gang zu rufen, was man macht, über den genervten Mitarbeiter,
der so etwas wie ein Change-Management-System bedienen muss bis zur
Führungskraft, und ich habe gelernt, dass es keinen Sinn hat, den
Guerilla zu machen. Wenn man Regeln brechen muss, um den Kunden zu
bedienen und die Unternehmensziele zu erreichen, sollte man dies nicht
heimlich tun, sondern an der Verbesserung der Regeln arbeiten.

Damit bin ich ganz gut gefahren, auch wenn es mir nicht immer leicht
gefallen ist.

Wenn man Regeln bricht, braucht man einen, der für einen eintritt. Das
kann der Vorgesetze sein, wobei man nicht weiß, wie lange. Denn keine
Führungskraft darf offen Regeln missachten oder Regelbruch fördern. Und
glaube bloß nicht, dass der Kunde dein Fürsprecher sein wird. Spätestens
bei Problemen wird er ganz erstaunt tun.

Nenn' mich Oberlehrer, vergiss meinen Artikel, oder zieh dir heraus, was
dir sinnvoll erscheint.

Und schau dir linuxusbstick.de an.

Bernd Eckenfels

2008-11-24 21:38:59 UTC

Post by Holger Marzen
Guerilla zu machen. Wenn man Regeln brechen muss, um den Kunden zu
bedienen und die Unternehmensziele zu erreichen, sollte man dies nicht
heimlich tun, sondern an der Verbesserung der Regeln arbeiten.

Und "if you cant change your Organization, change your Organization"

Gruss
Bernd

Stefan Kanthak

2008-11-23 22:34:19 UTC

Post by Oliver Schad
Wer kotzen will, liest auch
http://www.bsi.de/gshb/deutsch/m/m04294.htm

Wenn die GUI diese Einstellungen nicht vom jeweiligen Benutzer in dessen
Benutzerkonto zulaesst, dann ist sie kaputt!
Informiere Deinen Chef und den Verantwortlichen unter Hinweis auf die
Bildschirmarbeitsplatzverordnung.

Post by Henning Weede
- Neuer PC hat auf einmal Office13 statt Office10 drauf - nichts
geht mehr. Versuch, den Zauber in Ordnung zu bringen, scheitert
mangels Administrator-Passwort.

Informiere Deinen Chef und melde dem HelpDesk den Totalausfall.

Die Systemadministration oder Software(de)installation ist in eine
Aufgabe des Endbenutzers?

Also haettest Du das Administrator-Passwort gar nicht gebraucht, sondern
nur (Dein? ach ne: das von Deinem Arbeitgeber installierte) Eclipse
richtig konfigurieren muessen?!
Hat Dir Dein Arbeitgeber gezeigt, wie das geht?
Oder Dir eine entsprechende Anleitung (zum Verhalten in fremden Netzen)
gegeben?
Wenn nicht, dann informiere Deinen Chef und fordere sie unter Hinweis
auf den Missstand an.

Post by Henning Weede
Im weiteren Verlauf des Meetings wird mir eine interessante
Literaturquelle als PDF angeboten. Darf ich nicht annehmen,
meine Mami^H^H^HLeiter IT hat mir verboten, die USB-Schnittstelle
zu benutzen, und deswegen funktioniert sie auch nicht.

"Literaturquelle als PDF" funktioniert nur ueber USB?

Wieso nimmst Du dafuer einen USB-Stick? Du weisst doch schon aus
Deinem vorherigen Schritt sowie von Mami, dass das nicht funktioniert!

Post by Henning Weede
- Nachdem ich das Zeug wutschnaubend von Hand nochmal eingetippt hab
stell ich fest: MinGW fehlt, ich kann es nicht compilieren.

Gehoert es zu Deinem Aufgabenbereich, Software zu kompilieren?
Dein Arbeitgeber hat Dir trotzdem keinen Compiler installiert?
Weise Deinen Chef auf diesen Missstand hin.

Post by Henning Weede
Versuch, MinGW zu downloaden scheitert - aus irgendwelchen Gründen
funktioniert FTP nicht.

Nimm einen anderen erlaubten Weg. Nur: wozu?
Du kannst/darfst doch eh keine Software installieren?!

Post by Henning Weede
- Nachdem ich MinGW installiert

Oben behauptest Du, Du koenntest Software mangels Administrator-Passwort
nicht installieren. Und: woher hast Du MinGW?

Post by Henning Weede
und an meinem Programm weitergestrickt habe,
stell ich am nächsten Tag fest: wie von Geisterhand ist MinGW wieder
verschwunden.

Informiere Deinen Chef.
Rufe den HelpDesk Deines Arbeitgebers an und melde eine Stoerung.

Dann solltest Du diese Leitsaetze ENDLICH lesen und darin die Passage
(zu) finden (versuchen), dass Du SPON nicht gucken darfst.

Das ist nur ein Gordischer Knoten.-)

Post by Henning Weede
- Das Telefon klingelt. Ich soll zum Geschäftsführer kommen.
Mit am Tisch sitzt auch der Leiter IT und jemand vom Betriebsrat.
"Herr Weede, wir hätten da ein paar Fragen an Sie."

Klar. Wieso hast Du auch MinGW irgendwoher beschafft und installiert.

Post by Henning Weede
Man achte als Ingenieurwissenschaftler darauf, wo man sich anheuern lässt
und wo klugerweise nicht.

Du fragst bereits beim Ein^VVorstellungsgespraech nach, welche
"Einschraenkungen" etc. es in der Firmen-IT und auf den Arbeitsplaetzen
gibt?

Stefan
[

--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)

Bernd Eckenfels

2008-11-24 01:18:11 UTC

Post by Stefan Kanthak
Informiere Deinen Chef und den Verantwortlichen unter Hinweis auf die
Bildschirmarbeitsplatzverordnung.

...

Post by Stefan Kanthak
Informiere Deinen Chef und melde dem HelpDesk den Totalausfall.

...

Post by Stefan Kanthak
Wenn nicht, dann informiere Deinen Chef und fordere sie unter Hinweis
auf den Missstand an.

So sehr ich verständnis dafür habe, dass man alles regeln will, so sehr
wundert es mich doch dass es hier tatsächlich menschen gibt die unter
solchen Bedingungen freiwillig arbeiten wollen...

Gruss
Bernd

Holger Marzen

2008-11-24 07:21:35 UTC

Post by Bernd Eckenfels

Post by Stefan Kanthak
Informiere Deinen Chef und den Verantwortlichen unter Hinweis auf die
Bildschirmarbeitsplatzverordnung.

...

Post by Stefan Kanthak
Informiere Deinen Chef und melde dem HelpDesk den Totalausfall.

...

Post by Stefan Kanthak
Wenn nicht, dann informiere Deinen Chef und fordere sie unter Hinweis
auf den Missstand an.

So sehr ich verständnis dafür habe, dass man alles regeln will, so sehr
wundert es mich doch dass es hier tatsächlich menschen gibt die unter
solchen Bedingungen freiwillig arbeiten wollen...

Man muss bereit sein, das System zu verbessern, wenn etwas nicht perfekt
ist. Leute, die diese Richtlinien vorgeben, sind auch nicht perfekt, und
sie tun es nicht, um die Kollegen zu gängeln. Ebenfalls halten sie sich
nicht für unfehlbar, was man ihnen oft unterstellt. Man tut gut daran,
diesen Leuten konstruktive Kritik zukommen zu lassen anstatt die Regeln
zu unterlaufen, dann haben alle Kollegen was davon.

Stefan Reuther

2008-11-24 19:15:25 UTC

Post by Bernd Eckenfels

Post by Stefan Kanthak
Informiere Deinen Chef und den Verantwortlichen unter Hinweis auf die
Bildschirmarbeitsplatzverordnung.

...

Post by Stefan Kanthak
Informiere Deinen Chef und melde dem HelpDesk den Totalausfall.

...

Post by Stefan Kanthak
Wenn nicht, dann informiere Deinen Chef und fordere sie unter Hinweis
auf den Missstand an.

So sehr ich verständnis dafür habe, dass man alles regeln will, so sehr
wundert es mich doch dass es hier tatsächlich menschen gibt die unter
solchen Bedingungen freiwillig arbeiten wollen...

Ich.

Allerdings nicht unter dem hier beschriebenen Extrem (ich gehe gleich
zur IT statt zum Chef, wenn ich was haben will, und bekomme es meistens
auch. Und ich muss nicht erst mit der Bildschirmarbeitsplatzverordnung
drohen. Eine halbwegs plausible Begründung reicht.).

Gewisse Dinge kann ich selber machen. Gewisse Dinge nicht. Hat den
ungemeinen Vorteil: ich muss sie auch nicht machen. Ich hab keinen Bock,
das Windows selber zu patchen, den Virenscanner zu aktualisieren, mich
durch Office-Installationen zu quälen. Ich will meine Arbeit machen, und
ich lass den Admin seine Arbeit machen. Und dann ist mir auch völlig
egal, wenn mal wieder Heise Zeter und Mordio schreit, wenn ein neuer
Wurm unterwegs ist. Soll sich der Admin drum kümmern, dafür ist er da.

Wer als Admin den Nutzern wirklich volle Rechte über die zu verwaltenden
Rechner gibt, kann einfach keinerlei sinnvolle Verantwortung mehr für
die Rechner übernehmen. Der kann sich bestenfalls noch auf Routerpflege
spezialisieren... Den Dienstwagen lässt man doch auch vom Mechaniker
pflegen, und zieht die Winterreifen nicht selber auf.

Stefan

Stefan Kanthak

2008-11-25 14:01:49 UTC

Post by Bernd Eckenfels

Post by Stefan Kanthak
Informiere Deinen Chef und den Verantwortlichen unter Hinweis auf die
Bildschirmarbeitsplatzverordnung.

...

Post by Stefan Kanthak
Informiere Deinen Chef und melde dem HelpDesk den Totalausfall.

...

Post by Stefan Kanthak
Wenn nicht, dann informiere Deinen Chef und fordere sie unter Hinweis
auf den Missstand an.

So sehr ich verständnis dafür habe, dass man alles regeln will, so sehr
wundert es mich doch dass es hier tatsächlich menschen gibt die unter
solchen Bedingungen freiwillig arbeiten wollen...

Nicht jeder kann sich seinen Arbeitsplatz aussuchen.

Und selbst wenn: im Fall einer "kaputten" oder fuer meine Aufgaben
ungeeigneten Konfiguration des von der Firmen-EDV bereitgestellten und
zentral gewarteten Arbeitsmittels "PC" informiere ich natuerlich meinen
Chef und lasse dann das Problem von der Firmen-EDV beheben, bevor ich
ueber andere Schritte nachdenke oder eben zur Selbsthilfe greife und
dabei evtl. gegen die Sicherheitsrichtlinien der Firma verstosse.

Argumentationsverstaerker wie Bildschirmarbeitsplatzverordnung etc.
setze ich dann ein, wenn die Problembeseitigung nicht erfolgt.

Stefan
[

Henning Weede

2008-11-26 14:51:21 UTC

Post by Stefan Kanthak
Nicht jeder kann sich seinen Arbeitsplatz aussuchen.

Und nicht jedes Unternehmen kann sich seine Aufträge aussuchen. Wenn ein
Unternehmen, das Engineering, technische Berechnungen, Messungen,
Untersuchungen, Machbarkeitsstudien, Gutachten etc...etc... anbietet, sein
Leistungsspektrum auf das beschränken würde, was mit am Markt verfügbarer
Software (zu beschaffen, installieren und warten von einer IT- oder
EDV-Abteilung) bewerkstelligt werden kann, dann könnte dieses Unternehmen
nicht mehr als die Konkurrenz und könnte einpacken. Wenn dagegen bei der
Einstellung von Spezialisten jedesmal auch deren Forschungsergebnisse,
Berechnungsverfahren, Berufserfahrung mit akquiriert werden, dann sind
diese Ressourcen nicht nur in deren Köpfen vorhanden, sondern sehr, sehr
physisch als ganzer Sack von Programmen, Libraries, Quellcode usw.
Technologie fließt nicht über die Einkaufsaktivitäten der IT-Abteilung in
so ein Unternehmen, sondern über die Spezialisten, die ihre Software
mitbringen. Erst das macht den Wettbewerbsvorsprung aus gegenüber den
Chinesen, die als Industriekunden kommen und nach dem alten chinseischen
Grundprinzip "wie kann ich das raubkopieren und abkupfern" die bescheuerte
Frage stellen, wie heißt denn das Programm, womit Sie das berechnen (so
als könne man es bei Microsoft oder MediaMarkt kaufen).

Ich habe den Eindruck, das BSI kapiert das nicht und nimmt
den Wettbewerbsvorsprung als Sicherheitsrisiko wahr. Wo kämen wir denn
hin, wenn der dumme Ingenieur auf einmal programmieren dürfte.

Betroffen bin ich selber Gott sei Dank nicht, ich erwirtschafte meinen
Beitrag mit eigenentwickelten Rechenverfahren, die ich als Quellcode
mitgebracht habe, das verbietet mir niemand, aber wenn ich bei
irgendwelchen Meetings einen stellvertretenden Leiter der "Strategic
Research Division" oder einen "Leiter Produktentwicklung" erlebe, die
herumstammeln und sich entschuldigen, dass sie noch nicht einmal ihr
Administrator-Passwort wissen oder nicht auf ihr USB zugreifen dürfen, die
also erkennbar noch nie von früheren Forschungsvorhaben (inkl. der
Promotion) Software mitgebracht haben, dann empfinde ich Mitleid.

Henning

Stefan Kanthak

2008-11-26 22:59:18 UTC

Post by Stefan Kanthak
Nicht jeder kann sich seinen Arbeitsplatz aussuchen.

Und nicht jedes Unternehmen kann sich seine Aufträge aussuchen.

[...]

Post by Henning Weede
Ich habe den Eindruck, das BSI kapiert das nicht und nimmt
den Wettbewerbsvorsprung als Sicherheitsrisiko wahr. Wo kämen wir denn
hin, wenn der dumme Ingenieur auf einmal programmieren dürfte.

Zeig doch mal im GSHB die Stelle, die das Programmieren oder auch das
Compilieren x-beliebigen Quellcodes verbietet!

Post by Henning Weede
Betroffen bin ich selber Gott sei Dank nicht, ich erwirtschafte meinen
Beitrag mit eigenentwickelten Rechenverfahren, die ich als Quellcode
mitgebracht habe, das verbietet mir niemand,

S.o.

Post by Henning Weede
aber wenn ich bei
irgendwelchen Meetings einen stellvertretenden Leiter der "Strategic
Research Division" oder einen "Leiter Produktentwicklung" erlebe, die
herumstammeln und sich entschuldigen, dass sie noch nicht einmal ihr
Administrator-Passwort wissen

Wozu sollen die denn das Administrator-Passwort wissen muessen?

Post by Henning Weede
oder nicht auf ihr USB zugreifen dürfen, die
also erkennbar noch nie von früheren Forschungsvorhaben (inkl. der
Promotion) Software mitgebracht haben,

Kannst Du Software nur per USB auf einen PC uebertragen? Dann hast
Du mein vollstes Mitleid.

Post by Henning Weede
dann empfinde ich Mitleid.

Wenn sich solche Leute nicht zu helfen wissen und von "ihrer" IT
soweit gaengeln lassen: ja. IT ist Dienstleistung FUER die Mitarbeiter.

Mordac doesn't live here any more.-)

Stefan
[

Oliver Schad

2008-11-24 03:17:35 UTC