Neuer URL bei GooglePlus!


Seit eben ist unsere Seite bei Google+ unter der wunderschönen Adresse https://www.google.com/+HBZBranseGmbHBarth zu erreichen. Zum Merken reicht allerdings auch schon die kurze Variante http://google.de/+HBZBranseGmbHBarth aus – den Rest erledigt der jeweilige Webserver in Googles Serverfarm umleitungstechnisch dann selbst. Ist doch hübsch, oder? ;-) ;-) ;-)

Sorry!


Entschuldigung! Aber wir müssen unsere Follower bei Twitter wohl um Verzeihung bitten… Wahrscheinlich kam es um den 29.09.2013 zu Spam-Versand in unserem Namen.

Twitter-Panne 2

Ein derartiges Feedback ist uns zwar (zum Glück) nicht zugegangen, trotzdem ist uns aber leider zumindest ein Fall bekannt, in dem am 29.09. eine Twitter-Direktnachricht mit einem Link zu einer schädlichen Website über den HBZ-Twitter-Account abgesetzt wurde. Natürlich hat HBZ Branse den Versand dieser Mitteilung nicht initiiert!

Twitter-Panne 2

Return-Path: <b097718779dinfo=XXXXXXXXXXX@bounce.twitter.com>
Delivery-Date: Sun, 29 Sep 2013 13:54:22 +0200
Received-SPF: pass (mxeu1: domain of bounce.twitter.com designates 199.59.148.231 as permitted sender) client-ip=199.59.148.231; envelope-from=b097718779dinfo= XXXXXXXXXXX@bounce.twitter.com; helo=ham-cannon.twitter.com;
Received: from ham-cannon.twitter.com (ham-cannon.twitter.com [199.59.148.231])                 by mx.kundenserver.de (node=mxeu1) with ESMTP (Nemesis)

HBZ-Branse.de @hbz_branse_de
I advise this site  =E2=80=A6
29. Sep 13 11:54 vorm
.

Eine Überprüfung des Absenders ergab folgendes:

General IP Information
IP:                         199.59.148.231
Decimal:                    3342570727
Hostname:                   ham-cannon.twitter.com
ISP:                        Twitter
Organization:               Twitter
Services:                   None detected
Type:                       Corporate
Assignment:                 Static IP
Geolocation Information
Country:                    United States
State/Region:               California
City:                       San Francisco
Latitude:                   37.7697  (37° 46’ 10.92” N)
Longitude:                  -122.3933  (122° 23’ 35.88” W)
Area Code:                  415
Postal Code:                94107

Da sich der Versender als Twitter und somit als authentisch herausstellte, bleibt eigentlich nur noch die Möglichkeit, daß sich jemand Zugriff auf unseren Account verschafft hat. Obwohl wir ein „starkes“ bzw. komplexes Paßwort (Länge, kein Wörterbuch-Eintrag, Klein- und Großbuchstaben, Ziffern, Sonderzeichen) benutzt hatten, war es einem Hacker irgendwie gelungen, sich dieses zu verschaffen, wobei wir aber die Möglichkeit eines installierten Keyloggers auf dem Rechner, über den der Account betreut wird, ausschließen können. Er muß es also per Brute Force geschafft haben, was allerdings mit Sicherheit Twitter aufgefallen wäre und andererseits höchstens von einem ganzen Rechnerverbund in annehmbarer Zeit zu schaffen gewesen wäre.

Interessanterweise hatten wir (höchstwahrscheinlich vor „unserem“ Spamversand) selbst eine solch dubiose Nachricht bei Twitter erhalten. Allerdings  haben wir den Link aber weder geöffnet, noch zu der Zeit überhaupt zur Kenntnis genommen. Die Nachricht fiel erst heute auf, da die entsprechende E-Mail-Benachrichtigung dafür ausgeschaltet war und heute im Zusammenhang mit dem Spam-Versand geprüft wurde, ob – und wenn ja, welche – Nachrichten sich dort angesammelt haben.

Twitter-Panne 3

Welcher URL wurde hier verbreitet?

http://210.172.48.53/com/_www.youtube.com_index.html?kitowafisivo=52549846&lugonyr=14115

Und das war der Link in unserer Spam-Nachricht:

http://necklaceall.com/pages/www.facebook.com_page_.html?afozinu=93147462&vehatu=88448

In beiden Fällen ist der URL identisch aufgebaut. Ein Unterordner (zumindest scheinbar), dann die Adresse einer bekannten Site, an die gleich eine HTML-Seite angehängt wurde – und das alles wird ergänzt mit einem Querystring, der aus 2 Wertepaaren besteht. Zufall? Nein, eher eine ganze Welle. Immerhin war „unsere“ Spam-Website bei Twitter bekannt, man hat ihr sogar eigens eine Warnung gewidmet:

Twitter-Panne 4

Kann es sein, daß sich irgendwas bei Twitter durchs System frißt? Zumal weder in unserem Account noch im Account des uns bekannten Empfängers „unseres“ Spams die Nachricht zu finden war. Hat der Hacker etwa nach dem Versand aufgeräumt?

Apps scheinen prinzipiell in der Lage zu sein, Direktnachrichten zu verschicken. Zumindest soll man sie verdächtigen, wenn man sich auf einmal selbst Nachrichten schickt:

Wenn du DMs (Direktnachrichten) von dir selbst erhältst:
Bitte führe folgende Maßnahmen durch:
1) Wenn Du eingeloggt bist, besuche den Applikationen-Tab in deinen Einstellungen. Widerrufe den Zugriff für jede Drittapplikation, die Du nicht erkennst.

2) Wenn du dieses Problem immer noch hast, nachdem du den Zugriff unerwünschter Applikationen widerrufen hast, oder du dieses Verhalten nicht erwartet hast, als Du diese Verbindung zugelassen hast, kontaktiere uns.

Diese Aussage ist so zumindest auf der Seite https://support.twitter.com/articles/161379-direktnachrichten-dms-senden-und-loschen# zu finden.

Nun ja, wir haben auch einigen Apps Zugriffsrechte gewährt. Allerdings handelt es sich dabei nicht um Apps von dubiosen Wald- und Wiesen-Anbietern, sondern um Applikationen großer, bekannter Seitenbetreiber. Falls diese aber in irgend einer Form kompromittiert wurden, hätten Hacker somit evtl. ein Einfallstor für zahlreiche Twitter-Seiten gefunden…

Was genau am 29.09. abgelaufen ist, wird wohl nur Twitter anhand der Logs ermitteln können.

Daher haben wir vorsichtshalber das Paßwort nochmals verstärkt, was Twitter anfangs irgendwie gar nicht witzig fand:

Twitter-Panne 5

Eigentlich hätte es nämlich sofort so aussehen sollen:

Twitter-Panne 6

Jedenfalls werden wir in Zukunft die Twitter-Aktivitäten etwas stärker im Auge behalten.

Hinweis: Sofern es sich nicht um Antworten auf Anfragen, die wir über diesen Kanal erhalten, handelt, versenden wir auch in Zukunft definitiv keinerlei Direktnachrichten bei bzw. über Twitter!

Es tut uns leid, falls Sie zu denjenigen gehörten, die diesen Spam von uns erhalten haben und vielleicht sogar dadurch Unannehmlichkeiten hatten.

06.04.2013 – GARDENA Promotiontag


Es wäre uns ja FAST durch die legendären, sagenumwobenen Lappen gegangen: Wir haben ja noch gar keinen Beitrag zum super gelaufenen GARDENA-Promotiontag verfaßt… Das wird natürlich schleunigst an dieser Stelle nachgeholt!

Getreu dem Motto “Ein Bild sagt mehr als 1000 Worte” lassen wir einfach Fotos sprechen – und lehnen uns entspannt zurück (Und ehrlich: Nach DEM Tag haben wir uns das auch verdient!) … ;o)

Fotostrecke 

2. HBZ-Baustoff-Forum Tiefbau – ein voller Erfolg!


Gestern fand, wie angekündigt, im „Hotel Speicher Barth“ das 2. HBZ-Baustoff-Forum mit dem Schwerpunkt Tiefbau statt. Mit über 50 Gästen konnten wir eine rege Teilnahme verzeichnen, wofür wir uns an dieser Stelle recht herzlich bei allen Teilnehmern bedanken möchten.

Baustoff-Forum, Hotel Speicher Barth

Ein weiteres Dankeschön geht an die Vertreter der Unternehmen Magnaplast GmbH, BERDING Beton GmbH, ACO Tiefbau Vertrieb GmbH und Meyer-Polycrete GmbH, die den Nachmittag überhaupt erst ermöglichten und diesen mit ihren Fachvorträgen interessant und kurzweilig gestalteten. Darin ging es u.a. um Rohre, Schächte, Straßenabläufe und Pflasterung. Vieles wurde anhand von Beispielen, Modellen und Bildern veranschaulicht.

Baustoff-Forum, Hotel Speicher Barth

Das Team des Speicher-Hotels darf an dieser Stelle natürlich auch nicht vergessen werden; wir bedanken uns für die gute gastronomische Betreuung und vor allem für das leckere Abendessen!

Baustoff-Forum, Hotel Speicher Barth
Baustoff-Forum, Hotel Speicher Barth

Wir freuen uns schon auf das nächste Mal! Vielen Dank.

Ihr HBZ-Team

2. HBZ-Baustoff-Forum Tiefbau


Alle, die beruflich etwas mit Tiefbau zu tun haben, sind herzlich zum 2. HBZ-Baustoff-Forum Tiefbau eingeladen, das am 26.02.2013 in Barth stattfindet. Es erwarten Sie sehr interessante Fachvorträge der folgenden namhaften Unternehmen:

Firmen-Logos: Magnaplast GmbH, Meyer-POLYCRETE GmbH, ACO Tiefbau Vertrieb GmbH, BERDING BETON GmbH
Wir würden Sie gern an diesem Tag ab 13.30 Uhr zum Warm-up im Hotel “Speicher Barth” begrüßen, bevor wir dann um 14.00 Uhr beginnen. Nach den Fachvorträgen möchten wir Sie herzlich zu einem gemeinsamen Abendessen einladen. Bitte senden Sie Ihre Antwort* bis zum 14. Februar 2013 an die genannte Faxnummer oder E-Mail-Adresse. Anmeldungen bitte NUR per Fax oder E-Mail !!!

* Antwort: http://www.hbz-branse.de/2013/baustoff-forum/antwort.pdf
Programm: http://www.hbz-branse.de/2013/baustoff-forum/programm.pdf

Nichts als heiße Luft…


Nachdem wegen angeblicher Fehler im Online-Shop der HBZ Branse GmbH viel heiße Luft durch einen BSD-User abgelassen wurde und wir  hier und hier darauf eingingen, lief viel Wasser den Berg hinunter – immerhin haben wir die haltlosen Vorwürfe über ein Vierteljahr unkommentiert gelassen.

Wir erinnern uns kurz: Die “Startseite” http://shop.hbz-branse.de/shop erzeugte einen Fehler 404. Der Gag dabei: Das ist nicht die Startseite! Und es existiert auch keine Umleitung, die diesen Aufruf erzeugt! Für uns war klar: Der Fehler sitzt vor dem Monitor in Schicht 8 des siebenschichtigen OSI-Modells. Immerhin war der BSDler stolz auf seine “speziellen Einstellungen”. Nun war es aber an uns, herauszufinden, was mit “normalen Einstellungen” (bzw. bei “normaler Nutzung”) passiert. Was geschieht also, wenn man den Browser bestimmungsgemäß verwendet und nicht einfach irgendwelche Phantasie-URLs zu nicht existenten Seiten eingibt?

Erstens hätten wir zum Testen mit besagter BSD-Edition ein 64Bit-System gebraucht. Davon gibt es bei uns zwar etliche – als Fätt-Boys haben wir schließlich 2 DiMuX(e) im Einsatz. Doch die sind logischerweise tabu. “Never touch a running system” vs. Live-Stick… Nö – beim besten Willen nicht. Nicht wegen derartigen Unsinns… Privat steht beim Kollegen Klein auch etwas 64bittiges herum – er hat aber auch noch etwas anderes zu tun; und das nicht zu knapp. Private Kisten oder Rechner mit anderer Bestimmung a la DiMuX sind ohnehin irgendwie tabu. Außerdem: Bei EiTiCo bin ich der Web-Onkel – aber meine 64er Test-Kiste war leider gerade “out of order”. Seit über 3 Monaten lag das Ding in auseinandergeschraubten Einzelteilen irgendwo hier und dort verteilt umher, weil es nicht so wollte, wie es sollte. Endlich habe ich auch in einer ruhigen Minute die Fehlerquelle gefunden: Eine meiner heißgeliebten M-Audio Delta 1010LT war verstorben. Rien ne va plus – nichts geht mehr! Ok, kurz getrauert; alles zusammengefriemelt, dann fix den originalen, “popeligen” Realtek-HD-Sound@NVIDIA aktiviert – und dat Ding löppt allwedder…

Zweitens: Ich hatte die Ruhe weg! Denn SERVERSEITIG heißt SERVERSEITIG! Und kraft meiner Wassersuppe habe ich im Vollbesitz meiner geistigen Fähigkeiten SERVERSEITIGE UMLEITUNGEN per .htaccess erstellt. Also konnte der besagte Fehler gar nicht auftreten – es sei denn, der Feuerfuchs der betreffenden BSD-Edition macht, was er will und kreiert nach Belieben URLs, die er dann aufruft. Doch dann wäre er komplett Schrott und nicht nutzbar; das würde dieses System komplett disqualifizieren. Daher war dieser Teil der Kritik (SSL-Kritik ist berechtigt! Liegt aber nicht in meiner Hand!) von Anfang an einfach nur in die Kategorie BLÖDSINN einzuordnen.

Drittens: Die einzige Möglichkeit, die (neben mutwilliger URL-Falscheingabe seitens des testenden “anonymen BSD-Users” (kurz: “ABU”)) zu einem Auftreten des Fehlers führen könnte, wäre ein von mir irgendwo eingebauter, falscher Link, der keine Umleitung auslöst und direkt auf den falschen URL zeigt. Doch ich bat ja den ABU, mir mitzuteilen, wo er den URL her hätte (um diesen etwaigen Fehler dann auszumerzen). Bislang ist diesbezüglich nichts erfolgt. Also bleibt mir nur die Annahme, daß er diese Adresse höchst-selbst und eigenhändig eingetippselt hat.

Doch DANN ist alles ok – wie erwartet. Nicht existente Seiten liefern nun einmal einen 404er; das soll so, muß so und ist auch richtig so. Das weiß eigentlich sogar der ABU. Die serverseitigen Umleitungen funktionieren alle perfekt – wie erwartet. Und nun kann ich auch reinen Gewissens sagen, ich hätte es mit BSD getestet:

Sowohl alle Verlinkungen auf der Homepage als auch die Direkteingabe von  http://shop.hbz-branse.de/, http://www.hbz-shop.de/ oder http://www.hbz-branse-shop.de/ führen erwartungsgemäß zur richtigen Seite. Lediglich ein Flash-Element wird vom “Gnash”-Player unter BSD nicht verarbeitet. Aber Flash ist ohnehin (spätestens seit HTML5 und Apple-Smartphones) out und stirbt demnächst sowieso.

Aber von einem 404er ist weit und breit nichts zu sehen – der tritt erst auf, wenn ich Phantasie-URLs wie /shop oder /wurstbrot eingebe. Doch so was mache ich nicht - ich bin schließlich kein ABU!

Wie gesagt: Falls ich den (übrigens logischerweise natürlich auch in anderen Browsern einen Fehler 404 erzeugenden) URL irgendwo so, wie es kritisiert wurde (http://shop.hbz-branse.de/shop), fälschlicherweise verlinkt haben sollte, ist mir das echt entgangen. Gefunden habe ich jedenfalls nichts. Doch so lange sich der ABU in Schweigen hüllt, muß ich eben annehmen, daß er seine hyperaktiven Fingerchen bei der Adreßeingabe nicht im Griff hatte. Doch mit Verlaub – das ist dann einzig und allein SEIN Problem und interessiert mich nicht die Bohne.

Nach wie vor bin ich aber gern bereit, das (angebliche) Problem hier im Blog zu diskutieren oder ggf. zu reproduzieren. So lange man mir aber nicht den geheimen und gut versteckten Link auf die angebliche Startseite zeigt, bleibe ich um so standhafter bei meiner Meinung, daß alles so ist, wie es sein soll.

Offizielles Fazit: Der kritisierte Fehler existierte nie und ist nur heiße Luft - mehr nicht! Und alles, was zu der Annahme dieses Fehlers führte, basierte auf falschem Umgang mit dem Rechner – so leid es mir auch für das Ego des BSD-Nerds tut.

Update: Ich habe gerade festgestellt, daß neben dem, was im Blog niedergeschreiben steht, noch eine weitergehende Diskussion stattfand und mir doch vom ABU mitgeteilt wurde, in welcher Situation der Fehler auftritt – das war mir in Anbetracht der verstrichenen Zeit tatsächlich entfallen. Wenn ich ihn richtig verstanden habe, tritt der 404er auf, wenn man in der Navigationsleiste der Homepage auf Shop klickt. Daher habe ich sämtliche Verlinkungen nochmals getestet – und zwar für alle als Video sichtbar und nachvollziehbar.