IT-Blogger

Niemand, egal ob Student, Azubi oder Schüler, kommt inzwischen ohne das Zeichnen eines Struktogramm durch seine Ausbildung.

Eigentlich kein Wunder, denn Struktogramme sind ne tolle Sache, die das Verstehen eines Programms wirklich erleichtern.

Folgende Software hat es mir inzwischen besonders angetan: Der HUS Struktogrammer

Pro

• super Portable: nur eine exe, mehr nicht.
• Copy und Paste von Programmteilen funktioniert
• er tut (nur) das, was er soll. (Eine Eigenschaft die man bei vielen Programmen inzwischen leider vermisst)
• einfach zu bedienen
• Export zum Clipboard
• Funktioniert unter Linux mit Wine

Contra

• Export als jpg. Will man ein Struktogramm exportieren, muss man es halt über den Export ins Clipboard in ne jpg abspeichern. Das geht, ist aber leider umständlich.

Ein Blick lohnt sich definitiv!

Downloadmöglichkeiten gibt es bei Google zu Hauf. Eine davon:

http://www.phme.de/downloads/programme/09,hus-struktogrammer

Eine interessante Idee hatten die Security-Spezialisten von ha.ckers.org. In ihrem aktuellen Blogartikel schreiben sie über eine Möglichkeit wie man z.B das interne Netz eines Surfers über den Browser auf die existenz aktiver Hosts überprüfen könnte.
Hierzu wird natürlich kein echtes ICMP-Packet durch den Browser generiert, sondern ein so genannter Cross-Origin Request an jeden einzelnen Host abgesetzt. Mit dieser Methode will das W3C den Authoren von Webapplicationen eine sichere Möglichkeit bieten, die so geannte Same Origin Policy zu umgehen.

Wie funktioniert das “ping” sweeping?

Diese Methode bediehnt sich eines einfachen Gedankens: Eine IP hinter der ein Host steckt, kann schneller reagieren als eine IP hinter der kein Host steckt. (Wie denn auch, wer soll da reagieren?)

Das W3C verbietet im Entwurf zu Cross Origin Request ganz deutlich, dass keine Informationen an den User ausgegeben werden dürfen, wenn das status flag nicht auf success steht.

Hosting specifications also need to ensure not to reveal anything until the status flag is set to success to prevent e.g. port scanning.

Indirekt tut es der Browser halt trotzdem:

Hier wichtigste Teil des Javascripts:

1:  function processRequest () {
2:    if (req.readyState == 4) {
3:    var d2 = new Date;
4:    var time = d2.getTime() – d.getTime();
5:         if (time < 18000) {
6:             if (time > 10) {
7:                 log (“Exists: ” + url + ” at ” + time + “ms.”);
8:             }
9:         } else {
10:           log (“Doesn’t exist: ” + url + ” at ” + time + “ms.”);
11:       }
12:  }
13: }

Im vorderen Teil des Skripts (hier nicht abgebildet) wird das neue XMLHTTPRequest-Objekt ( req ) sowie die Startzeit des Skripts ( d ) erzeugt.

Wenn der Request beendet ist (Zeile 2) vergleicht das Skript die Anfangs- und Endzeit (d und d2). Wenn die Hosts innerhalb von 10 – 18000 Millisekunden geantwortet haben, dann werden sie als Online deaklatiert.

Diese unterschiedlichen Zeiten entstehen dadurch, dass jeder aktive Host, egal ob er auf Port 80 erreichbar ist oder nicht, dem Browser schneller eine Reaktion auf die Anfrage liefern kann als ein Host der nicht im Netzwerk vorhanden ist. Wenn ein Host nicht im Netzwerk erreichbar ist, läuft der Browser einfach in einen Timeout. Der dauert natürlich deutlich länger…

Es gibt 3 Möglichkeiten, wie ein aktiver Host auf eine Anfrage durch den Browser reagieren kann:

• Er schickt ein RST/FIN-Paket, weil auf diesem Port kein Dienst lauscht.
• Er lässt eine Verbindung zu, weil ein HTTP-Server auf dem Port lauscht.
• Er verwirft das Paket einfach.

Punkt 1 und 3 sind für das Skript ok und geben den Host als aktiv aus. Punkt 3 verfälscht das Ergebnis allerdings enorm. Dieser Fall entsteht durch eine aktive Firewall , die die Pakete einfach verwirft statt diese mit RST zu beantworten. Die Windows-Firewall (ab SP2 XP) ist z.B. so eingestellt. Genauso kann natürlich auch eine iptables-Firewall unter Linux eingestellt sein…

Link zum Test:

http://ha.ckers.org/weird/xhr-ping-sweep.html

Wer selbst ein wenig rumprobieren will, kann sich die Seite einfach abspeichern und im Quelltext das Array “sites”, entsprechend seiner IP-Range im lokalen Netzwerk, anpassen.

Fast schon 8 Tage ohne Post. Hat einen einfachen Grund: Gestern war Prüfung.

Um etwas genauer zu sein: Abschlussprüfung. Nach zwei Jahren Ausbildung bin ich nun ausgebildete Fachkraft O.o – und zwar Fachinformatiker mit Fachrichtung Systemintegration.

Viele hatten leider nicht das Glück schon gestern “abgefertigt” worden zu sein und sind erst nächste Woche dran. Aber ich bin voller Hoffnung, dass die komplette Klasse besteht. Die Prüfer scheinen ganz in Ordnung zu sein. Auch wenn das Fachgespräch bei manchen etwas ausartet ist – vor allem Richtung BWL. Ich hatte zum Glück nur eine BWL-Frage! :->

Morgen gibts dann nen Post zu meinem Abschlussprojekt – Squid mit Active Directory-Authentifikation über LDAP. Jetzt darf ichs ja veröffentlichen….

… und brav am 14.07 und 16.07 die Däumchen drücken.

Übrigens: Prüfungsort war das bekannte Hotel Adler Ottenbacher in Asperg. Ein 4-Sterne-Hotel-Superior und die Küche hat einen Michelin.

http://www.adler-asperg.de/

Es gibt genug Beispiele für schlechte Software. Fast täglich sehe ich welche. Heute hat sich eine besonders schlechte und damit natürlich erwähnenswerte Software bei mir auf den Rechner geschmuggelt.

Der erste Eindruck ist vielversprechend. GoFTP verspricht SFTP, FTPS und FTP-Support. Genau das was ich will: ein Multitalent. Dazu kommt seine beworbene, fast schon unglaubliche Schnelligkeit: 314% …. moment sich sags nochmal: 314% schneller als vergleichbare FTP-Programme. Ganz klar: Das könnte mein neuer Standard-Client werden.

Also installiert. Auch die Oberfläche sieht ganz akzeptabel aus. Die Software scheint ordentlich strukturiert zu sein und es springt einem kein regenbodenfarbenes Werbefenster an. Klasse.

Während der Eingabe der Daten: “Komisch … irgendwie scheint er während der Eingabe irgendwas zu machen. Da Blinkt ein Fenster mit rotem Hintergrund. ”

Invalid username or password reported by server.

“Klar, ich bin ja auch grad noch dabei das Passwort einzutippen. Wie sollst du dich auch einloggen können.Dummkopf.”

Tja jetzt ratet mal was er im Hintergrund gemacht hat… wer kommt drauf? Ich lasse kurz Bilder sprechen:

Phase 1 GoFTP

Phase 2 GoFTP

Phase 3 GoFTP - Ende.

Vielleicht sagen dem einen oder anderen diese Wireshark-Mitschnitte erstmal nichts. Deswegen nochmal etwas ausführlicher:

Während dem tippen des Passworts noch hat  GoFTP 5 gleichzeitige Verbindungen zum Server geöffnet. Um sich mit diesen 5 Verbindungen am Server zu authentifizieren, nimmt GoFTP einfach den Teil des Passworts, den man bis zu diesem moment im Passwort-Feld eingetragen hat. Egal ob das Passwort zu diesem Zeitpunkt vollständig eingegeben wurde oder nicht. (man tippt ja eigentlich in diesem Moment noch) (Phase 1)

Aber das wars noch nich… nee GoFTP  gibt nicht so leicht auf: Alle dieser 5 Verbindungen hämmern jedes mal an den FTP-Server,wenn der User einen weiteren Buchstaben im Passwort-Feld eintippt. Bei einem 10 Zeichen langen Passwort entstehen mal kurz 50 fehlgeschlagene FTP-Loginversuche.  (Phase 2)

Wer sich jetzt noch etwas auskennt weiß, dass FTP-Server sowas garnich mögen. Früher (und wahrscheinlich jetzt auch noch) wurde oft versucht FTP-Server mit einfachen Brute-Force Attacken zu cracken um darüber illegale Inhalte zu verteilen. D.h. jeder einigermaßen konfigurierte FTP-Server wird nach einigen fehlgeschlagenen Loginversuchen die Quell-IP auf die Blacklist setzen und die Verbindung von dieser Quelle verweigern. (Phase 3)

Damit ist man erstmal ausgeknocked. Auf den Server kommt man in den nächsten Minuten nicht mehr. Fail.