Messages

16

Wissenswertes / [Empfehlung] Hardwareauswahl für den PrivatPC

« on: October 12, 2009, 07:44:15 pm »

Wann ist ein PC "ideal"? Wenn er für wenig Geld viel Leistung bringt? Oder wenn er wenig Strom verbraucht und flüsterleise ist? Nein, das hängt in erster Linie von den persönlichen Anforderungen ab.

Ein CAD-fähiger Computer sollte Fähigkeiten von Office-, Multimedia- und Spiele-PC vereinigen. Insbesondere sollte man folgende Punkte beachten:

- guter Prozessor (Doppelkern) mit großem Cache,
- viel Hauptspeicher (RAM) mind. 4 GByte,
- schnelles Festplatten-Subsystem (2 SATA-Laufwerke im RAID-0),
- sehr leistungsfähige Grafikkarte (PCI-Express 2.0, OpenGL 3.x).

Wer etwas mehr Geld ausgeben will, sollte überlegen

- ob eine CAD-zertifizierte Grafikkarte (z.B. nVidia Quadro FX ...),
- ob ein SLI-System (besteht aus zwei Grafikkarten) oder
- ob ein 64-Bit System (bei mehr als 4 GByte RAM)

sinnvoll oder nötig ist. Ein High-End-System ist nicht erforderlich und insbesondere im Grundstudium sinnlos herausgeworfenes Geld. Ein Mittelklasse-System für ca. 700 EUR ist ausreichend. Solidworks läuft im allgemeinen auch auf Computern mit einfacher Hardware. Nur wer ganz sicher gehen möchte, sollte sich eine zertifizierte Grafikkarte kaufen.

17

Erstsemester-Unterstützung / Software - Programme

« on: October 11, 2009, 04:45:56 pm »

Hey Jungs, bevor ihr euch mit Windows 7 den Rest gebt, testet bitte, ob euer System kompatibel ist. Microsoft hat ein Programm namens Upgrade Advisor entwickelt, was mögliche Probleme im Vorfeld erkennt und entsprechende Tipps gibt.

http://www.microsoft.com/windows/windows-7/get/upgrade-advisor.aspx

18

Laberecke / Erdrutsch in Nachterstedt

« on: July 19, 2009, 01:07:53 pm »

Das Haus hat es ja glatt durchgeschnitten! Ich vermute mal, dass der Erdrutsch sehr schnell abgelaufen sein muss. Durch die Trägheit ist die andere Hälfte stehen geblieben. Weiterhin vermute ich, dass sich der unterirrdische Hohlraum durch das steigende Grundwasser gebildet hat. Normalerweise fließt Wasser in Sandböden sehr schnell ab, nicht aber wenn es durch eine geologische Störung gehindert wird. Dann fließt der ganze Mist zur Seite weg. Dass das möglich ist, haben wir ja schon beim Archiveinsturz in Kölln gesehen. Mit Sorge sehe ich, dass eine Seenlandschaft nach der anderen projektiert und genehmigt wird. Ich möchte da nicht wohnen...

@Pittiplatsch: Der Concordia-See ist im Vergleich mit natürlichen Seen zwar ein Winzling, aber als künstlich angelegter See doch schon relativ groß.

19

Laberecke / Datenschutz an der TU Dresden

« on: June 19, 2009, 12:19:19 am »

wie wärs mal mit einer dicken demo zur datensicherheit an der TU Dresden? :cool::cool:

Keine so gute Idee. Der Medienrummel würde nur noch mehr Hacker auf den Plan rufen. Eventuell würden die Entscheidungsträger im ZIH in Aktionismus verfallen und die Server abschalten. Vom ZIH sollte man erwarten können, dass sie das Risiko objektiv einschätzen und geeignete Maßnahmen ergreifen, um die Sicherheit zu erhöhen. Dazu gehören auch solche Maßnahmen, wie z.B. dass man die Nutzer besser über Sicherheitsthemen informiert. Dass die meisten Studenten ihr Home-Directory offen lassen, sei ein Beispiel.

Einen schönen Abend noch...

20

Laberecke / Datenschutz an der TU Dresden

« on: June 16, 2009, 11:59:46 pm »

Zuerst die guten Nachrichten:

Und wen man jetzt ein sinnlos Passwort wählt, wie abcdef1! oder so, was jeder schnell raten kann, kann auch jeder schnell ide hash-summe dafür bilden, und nachschauen ob die irgendeiner bei sich im Telefonbuch stehen hat!

1. Das Gute an einem kryptologisch starken Hash ist, dass man "auf den ersten Blick" nicht erkennen kann, ob sich dahinter - ich nenn's mal - ein Trivalkennwort versteckt oder ob es schon komplizierter ist. Beispiel für einen klassischen Unix-Hash (DES 56 bit):

Code: [Select]

crypt("abcdef1!") => "5x62etk8wXfiQ"Der Hashwert eines Trivialkennworts hat schon die Qualitäten eines sehr guten Kennworts. Aber diesen Buchstaben- und Ziffernsalat kann sich kein Mensch mehr merken.

2. Das Gute an der Implementierung ist, dass in die Berechnung des Hashwertes noch eine "Zufallskomponente" (Salt, z.B. Systemzeit) einfließt. Dadurch liefert ein nochmaliger Aufruf der crypt()-Funktion mit dem gleichen Kennwort einen anderen Hash:

Code: [Select]

crypt("abcdef1!") => "GjVaG6aNWXic6"3. Hashfunktionen sind Einwegfunktionen, d.h. es gibt im mathematischen Sinn keine Umkehrfunktion.

Trotzdem ist das noch kein Grund, sich sicher zu fühlen. Jetzt das Schlechte:

Hashfunktionen sind verwundbar gegenüber Kollisionsangriffen (Geburtstagsangriff). Kollision bedeutet, dass zwei unterschiedliche Kennwörter auf den gleichen Hashwert abgebildet werden. Falls Kollisionen "oft" genug passieren, kann man sie ausnutzen und erreicht dadurch, dass ...

... die nötige Zahl an Variationen nur noch etwas größer als die Quadratwurzel der benötigten Anzahl beim naiven Angriff (Brute force) ist.

Durch die gestiegende Rechenleistung und neue, verbesserte Algorithmen kann man einen Angriff auf Basis gesammelter Hashwerte in immer kürzeren Zeiten realisieren. Etwa aller 18 Monate verdoppelt sich die Rechenleitung bei annähernd gleichen Kosten. Insbesondere kommt durch leistungsfähigere Grafikkarten (nVidia CUDA-Technologie) ein enormer Leistungsschub im PC-Bereich dazu.

Systemlösungen, die noch vor 10 Jahren als (absolut) sicher galten, können schnell zu einem Risiko für die gesamte IT-Landschaft werden (Identitätsdiebstahl). Es besteht also ein akuter Handlungsbedarf. Ob man einen neuen Verzeichnisdienst einführt oder das bestehende System modifizieren kann, wird sich zeigen. Es bleibt also mit Sicherheit spannend!

21

Laberecke / Datenschutz an der TU Dresden

« on: June 16, 2009, 12:54:39 am »

Hat da jemand die Haustür offen gelassen?

Das ist etwas spekulativ. Ob es einen kausalen Zusammenhang zwischen den beiden Ereignissen gibt, wissen wahrscheinlich nur die Admins im innersten Kreis der Hölle :-)

Hey, das klingt nach einem großen Selbstbedienungsladen...
... Da muss doch eine Grundeinstellung vermurxt sein. Ich kann mir nicht vorstellen, dass 80% der Studenten freiwillig die Haustür offen lassen...

Ich muss hier mal (ausnahmsweise) dem Hausmeister2001 recht geben, die meisten Nutzer lassen ihr Home Directory offen (siehe Bildchen). Die Vermutung, dass da die Grundeinstellung nicht so genial ist, liegt ziemlich nahe. Was kann man tun?

Per SSH (Secure SHell) unter Unix anmelden und wenigstens dafür sorgen, dass andere Benutzer das Home Directory nicht mehr auslesen können:

Code: [Select]

chmod 711 $HOME
Die sensibelsten Dateien befinden sich unter "Eigene Dateien". Also:

Code: [Select]

chmod 700 "$HOME/Eigene Dateien"
Falls mann eine eigene Webseite im Ordner "public_html" betreibt:

Code: [Select]

chmod 755 $HOME/public_html
Für die Freaks: chmod setzt die Zugriffsrechte für Verzeichnisse und Dateien. Aber Achtung! Der 3-stellige Ziffernkode muss mindestens mit einer 6 (Dateien: rw-) oder einer 7 (Verzeichnisse: rwx) beginnen, damit ihr euch nicht selbst aussperrt.

22

Laberecke / Datenschutz an der TU Dresden

« on: June 15, 2009, 09:56:24 pm »

Brutforcen lässt sich der Server nicht, da er wie oben schon erwähnt, min 0,1 sec zum antworten braucht, mal 82Bil kommt da einiges zusammen.

Ich glaube nicht, dass sich ein Hacker beim Finden der richtigen Kennwörter gleich mit einem lebenden System anlegen würde.

Ganz anders sieht das ganze aus wenn man unsichere Passwörter benutzt, weil dann schafft es jeder einigermaßen brauchbare infostudent, über den shadow-file  quasi rückwärts über die hash-codes die Passwörter zu raten (die file ist übrigens sehr wohl geschützt und kann nur aus dem innersten Kreis (admins) "geklaut" werden).

NIS ist ein Verzeichnisdienst. Stell Dir das am besten wie ein Telefonbuch vor, in dem jeder Benutzer nach Herzenslust :-) blättern kann. Einer der wohl größten Schwachstellen ist, dass in diesem Telefonbuch auch die Hashwerte der Kennwörter zu finden sind. Zum Blättern und Lesen braucht man kein Admin zu sein. Man muss nur den richtigen Server anzapfen. Wenn keine Firewall die Sache verbietet, kommt man an die heiß begehrten "Telefonnummern" ran.

23

Laberecke / Datenschutz an der TU Dresden

« on: June 14, 2009, 11:47:47 pm »

Da frage ich mich, ersteinmal wieso die SZ eher bescheid wusste ...

Also, im SZ-Artikel vom 08.06.2009 steht nur, dass es eine Sicherheitslücke im TU-Netz gibt und dass darüber die Zugangsdaten leicht ausspionierbar sind. Über einen aktuellen Sicherheitsvorfall steht da nichts drin. Ich denke mal, dass der genannte Doktorand das Know-How für sich behalten hat; er würde sonst seinen Arbeitsplatz riskieren. Bestimmte Kreise könnten diesen Artikel aber als Auftrag verstanden haben. Wann der Sicherheitsvorfall wirklich eingetreten ist, lässt sich nicht eindeutig definieren. Man könnte annehmen, dass er am 10.06.2009 war.

Warum das ZIH nicht schon früher die Nutzer informierte, ist nicht zu verstehen. Immerhin bestand das Sicherheitsloch seit 2007.

P.S. Pittiplatsch hat den Kommentar zum Artikel vom 08.06.2009 im SZ-Archiv gefunden. Der war auf der gleichen Seite, nur ganz rechts versteckt.

@Pittiplatsch: Woher wusstest Du überhaupt, dass etwas im SZ-Archiv zu finden ist? Im Warnhinweis zur Kennwortsicherheit vom Herrn Syckor steht darüber nichts. Der Kobold muss noch eine andere Quelle gehabt haben...

24

Laberecke / Airfrance 447 Absturz

« on: June 14, 2009, 01:38:09 am »

Da ist ein Generator zur Überbrückung von einigen Stunden viel billiger.

Bis der Diesel-Generator einer Notstromanlage auf seine volle Leistung hochgelaufen ist, vergehen einige Sekunden. In dieser Zeit wären die Server in einem Datacenter längst abgestürzt. Also benötigt man sehr wohl noch einen Akku mit Wechselrichter, um diese Zeit überbrücken zu können. In einem großen Rechenzentrum sind somit alle drei Stromquellen notwendig.

Redundanz bedeutet, dass man mehrere unabhängige Systeme hat. Da Akkus  irgendwann wieder nachgeladen werden müssen, stellen sie allein keine unabhängige Stromversorgung dar. Wenn es mehrere akkubetriebene USV-Geräte gibt, kann man von einer "gewissen" Redundanz sprechen. Dabei müssen die USV-Geräte nicht unbedingt baugleich sein. Die Anschlusswerte (Spannung, max. Stromstärke, Frequenz) müssen natürlich stimmen.

Streng genommen bilden Akkus und Diesel-Generator ein gemeinsames Stromversorgungssystem (Notstrom), was unabhägig vom öffentlichen Stromversorgungsnetz ist.

25

Laberecke / Datenschutz an der TU Dresden

« on: June 14, 2009, 12:18:55 am »

Wie oft sollte man sein Kennwort ändern? Jeder Woche oder einmal im Monat?

Das hängt ganz von Deinem persönlichen Schutzbedürfnis ab. Es gibt Firmen, bei denen die Angestellten ihre Kennwörter (unter Windows) einmal im Monat erneuern müssen.

Nach Bekanntwerden des Sicherheitsvorfalls sollte jedoch jeder Nutzer möglichst sofort ein neues Kennwort verwenden. Insofern kann ich das Verhalten im ZIH nicht ganz nachvollziehen. Muss denn erst das Kind in den Brunnen fallen?

Warum sind die Kennwörter auf 8 Zeichen begrenzt?

Weil wahrscheinlich das Verfahren für die Hashwerte nicht geändert werden kann.

Das NIS an sich ist nicht daran schuld. Das Problem liegt vielmehr daran, dass zum einen ein Sicherheitsvorfall eingetreten ist (begünstigender Umstand, lässt sich nicht vollständig verhindern) und dass zum anderen der Wertevorrat für die verwendeten Hashwerte und damit auch für die Kennwörter (max. 8 Zeichen) zu gering ist. SHA-2 wäre eine sinnvolle Alternative, weil es je nach Sicherheitsanforderung skalierbar ist.

SHA-2 bildet eine Familie von Algorithmen, die sich durch die Länge des Hashwerts unterscheiden. Damit kann eine Abwägung zwischen Rechenaufwand und Sicherheit getroffen werden.

26

Laberecke / Datenschutz an der TU Dresden

« on: June 13, 2009, 09:56:20 pm »

Gelingt es einem Angreifer an die Hashwerte der Kennwörter im NIS heranzukommen (Sicherheitsvorfall), kann er diesen Angriff durchführen. Im Mittel wird er dabei nach 43 Tagen auf einer Playstation 3 mit Brute Force erfolgreich sein und könnte dann in einen Account einbrechen. Werden intelligentere Techniken eingesetzt, wird sich der Erfolg höchst wahrscheinlich früher einstellen.

Ein derartiger Angriff lässt sich nach einem Sicherheitsvorfall verhindern, wenn man noch vor dem Einbruch (!!!) sein Kennwort gewechselt hat. Man sollte also die Kennwörter in regelmäßigen Abständen erneuern.

Da dem Angreifer die geknackten Kennwörter im Klartext vorliegen, hilft es relativ wenig, ein eigenes Schema für die Kennwort-Erneuerung anzuwenden. Der beste Schutz ist daher ein völlig zufällig gewähltes Kennwort.

27

Laberecke / Datenschutz an der TU Dresden

« on: June 13, 2009, 08:36:43 pm »

In Abhängigkeit des verwendeten Verschlüsselungsverfahrens und der Schlüssellänge kann man den Aufwand zum Knacken abschätzen. Dafür gibt es verschiedene Techniken: Brute Force ist die wohl universellste, aber aufwändigste Technik. Ein Kennwort gilt geknackt, wenn man im Mittel 50% aller potentiellen Kombinationen durchprobiert hat (bestimmte Kennwörter sind leicht zu knacken, andere sind dagegen schwieriger zu finden). Intelligente Verfahren nutzen die individuellen Schwächen des verwendeten Verschlüsselungsverfahrens aus. Im NIS werden die Hashwerte der Unix-Kennwörter hinterlegt. Dazu wird traditionell DES mit einem 56 Bit langem Schlüssel verwendet. Andere mögliche Verfahren sind MD5, Blowfish und SHA (mehr Infos im wiki). Im Skript von Prof. Pfitzmann wird G-DES im Abschnitt 3.7.7 erläutert. Für das Jahr 1995 wird der Aufwand abgeschätzt mit:

Für 10^5 US$ kann man also eine Maschine bauen, die in 35 Stunden einen Schlüssel ermittelt, für 10^6 US$ dauert es nur noch 3,5 Stunden, usw. In der Vergangenheit verdoppelte sich die Rechenleistung bei gleichen Kosten etwa alle 18 Monate.

Verwendet man die Brute-Force-Technik (ohne Wortlisten und ohne Ausnutzung der Schwächen des DES-Verfahrens), würde das Knacken eines Unix-Kennworts auf einer PLAYSTATION 3 (vielen Dank an Pittiplatsch, Kosten: ca. 400 EUR) im Mittel (nur) 43,1 Tage  dauern. Einen Wert, den ich so auch nicht erwartet hätte. Hier meine Nebenrechnung:
 
[latex]n = 82,676,835,418,112 \\v = 11,100,000 s^{-1}$ \\ $t_{mittel}$ = 0.5 \cdot \frac{n}{v} \\ $t_{mittel}$ \approx 3,724,181 s \\ $t_{mittel}$ \approx 1,034.5 h \\ $t_{mittel}$ \approx 43.1 d[/latex]

28

Laberecke / Datenschutz an der TU Dresden

« on: June 13, 2009, 08:04:38 pm »

Um sich ein Bild von der gegenwärtigen Sicherheit zu machen, sollte man zunächst über die Anzahl der möglichen Kennwortkombinationen nachdenken. Das Alphabet (Zeichenvorrat) besteht aus zwei Gruppen. Gruppe a: Klein- und Großbuchstaben (52 Zeichen); Gruppe b: Ziffern und Sonderzeichen (32 Zeichen). Siehe auch: Formular zur Kennwort-Änderung Das Kennwort hat eine Länge von 8 Zeichen, dabei muss mindestens ein Zeichen aus Gruppe a und b vorhanden sein.

[latex]a = 52 \\b = 32 \\n = a \cdot b \cdot (a^6$ + a^5$ \cdot b + a^4$ \cdot b^2$ + a^3$ \cdot b^3$ + a^2$ \cdot b^4$ + a \cdot b^5$ + b^6$) \\n = 82,676,835,418,112 \\n \approx 8.268 \cdot 10^{13}$ [/latex]

Es gibt also gut 82 Billionen verschiedene Kennwortkombinationen. Einige davon sind ungültig, weil sie Bestandteile aus bekannten Wortlisten enthalten. Wieviel das wirklich sind, kann ich nicht sagen. Ich denke, dass es nicht mehr als ein paar Millionen sind.

29

Laberecke / Datenschutz an der TU Dresden

« on: June 11, 2009, 09:34:53 pm »

Hallo Leute,

habe den Post von Pittiplatsch zuerst für einen schlechten Scherz gehalten, musste dann aber doch im Zeitungsstapel nach der entsprechenden Ausgabe suchen und habe den eigentlichen Artikel gefunden. Da stehen auch mehr technische Details drin.

Einen schönen Abend noch...

30

Prüfungen/Testate 1./2. Sem. / Veränderung bei Solidworks/CAD?

« on: March 01, 2009, 02:29:04 pm »

Wenn ich mich in eure Debatte einschalten darf, sei zu
 

1 Byte = 8 Bit --> 0-255
2 Byte = 1 Integer = 16 Bit --> -32768 - 32767

noch folgendes anzumerken: Bit und Byte sind unabhängig von der Programmiersprache definiert. Beim Integer ist das nicht der Fall.
 
Ich kann da nur euren Freund xanthos bezüglich der Programmiersprache C unterstützen. Dort gelten folgende Definitionen:
 
char = kleinste addressierbare Einheit (1 Byte)
int = Verarbeitungsbreite des Prozessors (mit Vorzeichen)
 
int auf einer 16-Bit CPU: 2 Byte
int auf einer 32-Bit CPU: 4 Byte
int auf einer 64-Bit CPU: 8 Byte
 
Daher meine Empfehlung: Orientiert euch am Skript aus der Vorlesung!