Neues in der Kategorie Internet

Eventuell ist es manchen schon aufgefallen: Selbst die neueste Firefox-Version (im Test Firefox 33.1.1) ist manchmal nicht in der Lage, Webseiten korrekt darzustellen oder diese sogar überhaupt erst komplett zu laden. Insbesondere betrifft dies Webseiten, die über Captcha-Inhalte aber auch Google Adsense Werbung, etc. verfügen. Generell scheint es so zu sein, dass Webseiten, die externe Inhalte nachladen, einfach nicht richtig dargestellt werden oder aber erst gar nicht richtig geladen werden.

Manchmal hängt dieses Problem schlicht und ergreifend einfach an den installierten Add-Ons, die Firefox daran hindern, seine Arbeit als Webbrowser korrekt durchzuführen. In diesem Fall scheint das Add-On "Avira Browser Safety 1.4.0" der Übeltäter zu sein. Zwar schützt die Safety-Funktion vor unerwünschten Überraschungen auf virenverseuchten Webseiten; jedochbehindert sie auch Inhalte die eigentlich erwünscht sind. Nichts destotrotz lassen sich nach dem Deaktivieren dieses Add-Ons alle getesten Seiten anstandslos aufrufen.

Vor ein paar Tagen haben alle Nutzer von Dyn.com, die einen kostenlosen DynDNS-Account seither genutzt haben, folgende Mail bekommen:

To our Dyn free hostname users:

For the last 15 years, all of us at Dyn have taken pride in offering you and millions of others a free version of our Dynamic DNS Pro product. What was originally a product built for a small group of users has blossomed into an exciting technology used around the world.

That is why with mixed emotions we are notifying you that in 30 days, we will be ending our free hostname program. This change in the business will allow us to invest in our customer support teams, Internet infrastructure, and platform security so that we can continue to strive to deliver an exceptional customer experience for our paying customers.

We would like to invite you to upgrade to VIP status for a 25% discounted rate, good for any package of Remote Access (formerly DynDNS Pro). By doing so, you'll have access to customer support, additional hostnames, and more.

Here's how you get this done in two easy steps:

- Login to account.dyn.com.
- Click here to add Remote Access to your cart at the 25% off VIP rate. The discount will be applied upon checkout.

We thank you for your usage of Dyn through the years, and hope to continue to support you through Dyn Remote Access or other products for years to come. Please visit our FAQ page or this blog post for any additional information.

Mit anderen Worten: Dyn.com stellt seinen kostenlosen Dienst ganz und gar ein. Wahrscheinlich haben sie nämlich festgestellt, dass es keine neuen Kunden bringt, wenn man die kostenlosen User alle 30 Tage den Account manuell reaktivieren lässt. Und nachdem diese Methode nichts gebracht hat, erpresst man die kostenlosen Nutzer nun mit dem Fakt, dass man ja jetzt einen kostenpflichtigen Account weiterführen könne. Die Profitgier macht auch vor solchen Organisationen also nicht halt.

Eine gute Alternative zu Dyn.com stellt http:/www.noip.com dar. Hier kann man sich mit nur wenig Daten und Angaben auf die Schnelle einen neuen DynDNS-Accoutn basteln, der zudem auch noch mit dem Linux-Programm "ddclient" kompatibel ist.

Eine Anleitung wie man "ddclient" für eine noip-DynDNS-Adresse fit macht, findet man unter http://www.cecode.de/cecode/installation-eines-dyndns-clients-mit-no-ip-als-provider/.

Alternativ kann man auch noch http://www.selfhost.de nutzen. Allerdings muss man dort ziemlich viele private Angaben machen und die Konfiguration mit "ddclient" scheint auch nicht so einfach zu sein, wie bei noip.com.

Einige Router von Linksys, Netgear, Cisco und eventuell anderen Anbietern haben an Port 32764 eine Schnittstelle, die genutzt werden kann um sogar zum Teil die Passwörter im Klartext auszulesen. Eine Liste mit bereits getesten Modellen findet sich hier: https://github.com/elvanderb/TCP-32764/blob/master/README.md

Ausführliche Artikel von Heise.de zum Thema, auch wie man testen kann ob man selbst betroffen ist und ein funktionierender Exploit, gibt es hier:
http://www.heise.de/newsticker/meldung/Router-auf-Backdoor-testen-2074844.html
http://www.heise.de/newsticker/meldung/Mysterioese-Backdoor-in-diversen-Router-Modellen-2074394.html

Natürlich kann man auch selbst einen kurzen Test machen und versuchen eine Telnet-Verbindung zu diesem Port am eigenen Router aufzubauen.

Wer einen Mail-Client wie Thunderbird nutzt und seine Mails an den Mailserver über SMTP an den Port 587 verschickt, der kann in Kombination mit den falschen Firewall-Einstellungen am Cisco EPC3208G Probleme bekommen.

Der EPC3208G-Router lässt sich nämlich unter "Security -> Firewall" mit der Option "SPI Firewall Protection" auf vier verschiedene Einstellungen setzen: Off, Low, Medium und High. Aktiviert man dabei "Medium" oder "High", so lässt der Router vom internen Netz her kommend, nur ganz spezielle Ports durch. Leider ist in diesen beiden Einstellungen der Port 587, welcher mittlerweile häufifg für verschlüsselte SMTP-Verbindungen eingesetzt wird, nicht dabei. Dadurch werden alle Verbindungen zu diesem Port nach außen hin blockiert und nur die Verbindungen in der Liste der "Allowed Services" sind noch nutzbar.

Die einzige Möglichkeit das Problem zu Umgehen, ist den Router auf die "Low"-Einstellung zu setzen, was eine leere "Allowed Services"-Liste zur Folge hat und so problemlos alle Verbindungen nach außen aufgebaut werden können.

Ein Versuch die "Allowed Services"-Liste zu manipulieren scheiterte, da ein Zugriff auf den Router per Telnet oder SSH nicht möglich ist und man so auch nur sehr schlecht an die internen Einstellungen kommt. Höchstwahrscheinlich ist diese Liste direkt in der Firmware integriert, so dass nur eine modifizierte Firmware Abhilfe schaffen könnte.

Eine DDoS Attacke auf Port 80 hat in den letzten drei Tagen das Angebot des Undertec Blog lahm gelegt. Aus Sicherheitsgründen wurde deshalb der Webserver für einige Zeit abgeschaltet.

Entdeckt wurde die Attacke am 28. Dezember als von der IP-Adresse 46.105.143.85 mehrere verdächtige Syn-Pakete an Port 80 identifiziert werden konnten. Nach einer ersten erfolgreichen Abwehr kam dann in einer stärkeren Welle ein Angriff am selben Tag von der IP-Adresse 198.245.50.112, welcher bis Montag morgen dauerte.

Beide IP-Adressen sind zugehörig zu einem Hoster namens OVH, welcher auch eine GmbH Niederlassung in Deutschland hat. Die IP-Adressen selbst sind dabei in Frankreich (46.105.143.85) und Kanada (198.245.50.112) angesiedelt.
Eine Beschwerde/Abuse-Mail am selben Tag an die registrierten Kontaktadressen brachte zunächst keinen Erfolg, weswegen die Attacke sich auch bis zum Montag morgen austoben konnte.

Interessanterweise waren auch etliche andere Webhoster betroffen, wie die Listen auf http://www.abusipdb.com zeigen. Dort wird ebenfalls über den schlechten OVH Support geschimpft, der wohl über die Feiertage in keinster Weise reagiert hat, bzw. der wohl nicht in der Lage war einen Techniker zu Beendigung der Attacke bereitzustellen:

http://www.abuseipdb.com/report-history/46.105.143.85
http://www.abuseipdb.com/report-history/198.245.50.112

Das spricht natürlich nicht für OVH, wenn sie nicht mal in der Lage sind, technische Probleme an Feiertagen zu lösen. Mein persönliches Fazit daraus ist, dass ich nie bei OVH Kunde werde, wenn der Service so schlecht ist. Im Übrigen kam auch keine Antwort auf die gesendeten Abuse-Mails.

Wer nicht möchte, dass der Apache Webserver zum Beispiel beim Aufruf einer 404-Fehlerseite bekannt gibt, auf welchem Betriebssystem er läuft, kann zum Beispiel unter Debian diese Signatur unterdrücken. Einfach in der Konfigurationsdatei "/etc/apache2/conf.d/security" folgenden Schalter aktivieren:

ServerSignature Off

Nach einem Neustart des Apache wird in Zukunft keine Signatur ausgeliefert. Zusätzlich kann man nich

ServerTokens Prod

aktivieren. Mehr dazu bei den Links unten.

Mehr dazu auch auf den folgenden Webseiten:
http://netz10.de/2010/10/10/gesprachiger-apache-serversignatur-unterdrucken/
http://kenntwas.de/2011/was-ist/apache-serversignatur-abschalten/
http://www.debianhelp.co.uk/tuning.htm
http://www.petefreitag.com/item/419.cfm
http://blog.techstacks.com/2008/08/apache-configuration-and-pci-compliance.html

Wer unterwegs anonym surfen möchte, der kann sich einfach den PrivacyDongle von Digitalcourage (früher FoeBud) bestellen. Auf diesem USB-Stick findet man die Tor-Software samt einem angepassten Firefox-Browser. Die Software ist Stand-Alone und muss deshalb auf einem fremden Rechner nicht installiert werden, sondern kann dort einfach direkt genutzt werden.

Wer sich einen Stick/Dongle bestellt, unterstützt laut Heise online auch gleich die Aktivitäten von FoeBud, welche für einen aktiven Datenschutz eintreten. Alternativ lässt sich laut Heise wohl aber auch das ganze kostenfrei gestalten, in dem man die Software einfach selbst auf einen USB-Stick zieht.

Hier der Link zur Heise-News:
http://www.heise.de/netze/meldung/PrivacyDongle-Anonymes-Internet-am-Schluesselbund-1918706.html

Hier der Link mit Informationen zu Tor (wichtig ist auch der Kritik/Schwachstellen-Bereich):
http://de.wikipedia.org/wiki/Tor_(Netzwerk)

Der PrivacyDongle direkt auf der Seite von Digitalcourage/FoeBud:
https://www.foebud.org/privacydongle-2013-anonymes-surfen-im-internet

Wer in seinem Weblog oder Content System Webseiten umbenennt (zum Beispiel von einem Unterstrich zwischen Wörtern in Dateinamen zu einem SEO-freundlichen Bindestrich: http://www.undertec.de/blog/2009/09/movable-type-40-bindestrich-statt-unterstrich.html) oder seine ganze Domain unter einen neuen Namen umziehen will, der sollte sich mit den Möglichkeiten einer permanenten Weiterleitung beschäftigen. Diese auch "Redirect" genannte Methoden ermöglichen es dem Browser, wie auch den Bots von Suchmaschinen wie Google und Yahoo, die neue Seite oder die umgezogenen Seiten zu finden.

Dabei gibt es natürlich elegante Methoden wie die Methode mittels .htaccess-Datei und dem Kommando "RewriteRule" oder etwas schlampigere Methoden wie einfach nur ein "Meta-Refresh". Google selbst empfiehlt dabei einen Server-seitigen 301 Redirect (https://support.google.com/webmasters/answer/93633?hl=en), was dem Google Bot dann auch klar macht, dass die Seite permanent (Dies entspricht dem Code 301) umgezogen wurde. Dabei hat dieser Server-seitige 301 Redirect den Vorteil, dass der sogenannte Pagerank mit umzieht. Bei einer schlampigen Implementierung oder einem temporären Umzug (Code 302) wird der Pagerank laut http://suchmaschinenoptimierung.michaelsattler.de/weiterleitung.html nicht mit umgezogen. Dies kann zum Teil natürlich sehr ärgerlich sein, wenn man sich einen hohen Pagerank erarbeitet hat und diesen dann verliert. Zudem werden Redirect-Lösungen mittels Javascript oder "Meta-Refresh" manchmal von Google ignoriert, da hier wohl schon viel Unfug getrieben wurde (http://www.zurwebsite.de/suchmaschinenoptimierung-tipps/weiterleitungen-301-und-302.html).

Aus diesem Grund findet sich im Folgenden auch eine komplette Anleitung wie man einen 301 Redirect für mehrere einzelne Webseiten mittels eines Apache-Servers unter Debian und mittels einer .htaccess-Datei einrichtet.

Zunächst muss man aus dem "mods-available"-Ordner das Modul "rewrite.load" (dies entspricht dem Modul "mod_rewrite") in den Ordner "mods-enabled" kopieren:

cp /etc/apache2/mods-enabled/rewrite.load /etc/apache2/mods-available/rewrite.load

Dann muss man in der "httpd.conf"-Konfigurationsdatei die Option "FollowSymLinks" aktivieren:

<VirtualHost *:80>
ServerAdmin ...
DocumentRoot ...
Servername ...

 <Directory "...">
  Options +FollowSymLinks
  ...
  ...
 </Directory>
</VirtualHost>

Bei den Optionen sollte man immer darauf achten, dass entweder ein + oder ein - vor der entsprechenden Option stehen. Vergisst man zum Beispiel vor ExecCGI das +, so kann es sein, dass man keine CGI-Skripte mehr aufrufen kann.

Alternativ statt "FollowSymLinks" kann man wohl auch "AllowOverride All" setzen und die "FollowSymLinks"-Option erst später in der .htaccess-Datei aktivieren. Dies soll hier im Beispiel aber nicht benutzt werden. Wer mehr dazu Wissen möchte, sollte einmal folgende Seite lesen: http://de.selfhtml.org/servercgi/server/htaccess.htm#erlaubte_anweisungen.

Danach kann man dann mit folgendem Befehl den Apache neustarten:

/etc/init.d/apache2 restart

Jetzt kann man im gewünschten Verzeichnis und das ist meist das Hauptverzeichnis, die .htaccess-Konfigurationsdatei anlegen:

RewriteEngine on

RewriteBase /

RewriteRule ^VERZEICHNIS/alte_Seite\.html$ VERZEICHNIS/neue-Seite.html [R=301,L]

Der Befehl "RewriteEngine on" schaltet dabei die Möglichkeit ein, entsprechende Befehle danach aus dem Modul "mod_rewrite zu nutzen.
Der Befehl "RewriteBase /" kann verwendet werden um die Wurzel für absolute Pfadangaben richtig zu setzen. Dies ist wichtig, da wir hier im Beispiel das [R]-flag später benutzen, welches sonst eine absolute Angabe in "http://"-Form benötigt (siehe dazu auch die Erklärung bei http://stackoverflow.com/questions/11348938/htaccess-rewrite-rule-not-working-properly-redirects-to-absolute-path).
Die Anweisung "RewriteRule" hat es nun ganz schön in sich. Mit dem "^"-Zeichen und dem "$"-Zeichen markieren wir Beginn und Ende unserer alten Url. Zudem machen wir vor den Punkt einen Backslash um ihn als Punkt und nicht als Steuerungszeichen zu deklarieren. Danach folgt die Url auf die neue Seite, gefolgt von "[R=301,L]", welches Flaganweisungen darstellt. [R] oder auch [R=301] stellt dabei einen externen Redirect da, was soviel bedeutet wie das der Browser die angegebene neue Adresse extra lädt. Der externe Redirect erklärt dabei auch, warum wir im Normalfall ohne "RewriteBase /" die "http://"-Form angeben müssten. Das letzte Flag [L] bedeutet, dass nach Ausführung dieser Anweisung keine weiteren Anweisungen ausgeführt werden sollen. schließlich könnten daran nun weitere "RewriteRule"-Anweisungen folgen, wie zum Beispiel mit anderen Seitenaufrufen zu verfahren ist. Mit dieser Methode kann man dann einfach auch mehrere einzelne Webseiten weiterleiten, in dem man einfach die "RewriteRule"-Anweisungen nacheinander hinschreibt.

Problembehandlung:
Wenn es zu Problemen kommt, weil man irgendwo einen Fehler gemacht hat, dann hilft vor allem das Error-Logfile des Apache weiter. Einfach nach den entsprechenden Fehlern, die durch den versuchten Seitenaufruf entstanden sind, googlen, meist findet sich dann auch schon die Wurzel des Übels. Alternativ oder zusätzlich kann man aber noch die "mod_rewrite"-Protokollierung aktivieren. Einfach in der .htaccess-Datei folgendes hinzufügen:

rewriteLog /var/log/apache/redirect.log
rewriteLogLevel 1

Damit sollte man dann in der Lage sein, dem Fehler wirklich auf den Grund zu gehen.

Im folgenden finden sich noch einige Beispiele und Webseiten, die sich ebenfalls mit dem Thema beschäftigen:
http://learnwebtutorials.com/redirect-old-html-page-to-a-new-html-page-using-rewriterule-in-mod_rewrite (Englisch)
http://www.yourhtmlsource.com/sitemanagement/urlrewriting.html (Englisch)
http://www.addedbytes.com/articles/for-beginners/url-rewriting-for-beginners/ (Englisch)
http://mirificampress.com/permalink/beyond_redirect_using_rewriterules_in_htaccess (Englisch)
http://suchmaschinentricks.at/tipps-tricks/mod_rewrite.html (Deutsch)

Kurzübersicht über RewriteRule und auch über andere Methoden wie eine PHP-Weiterleitung oder "Meta-Refresh":
http://www.zurwebsite.de/suchmaschinenoptimierung-tipps/weiterleitungen-301-und-302.html (Deutsch)
http://www.officetrend.de/2914/redirect-permanent-automatisch-weiterleitung-einzelner-urls/ (Deutsch)
http://suchmaschinenoptimierung.michaelsattler.de/weiterleitung.html (Deutsch)
http://www.simonrueger.de/301-Weiterleitung-so-funktioniert-es-richtig.html (Deutsch)

Seo-Tipps zum Domainumzug mit einer Art Checkliste was zu beachten ist (Deutsch):
http://www.echtzeithilfe.de/seo-tipps-domainumzug

wikipedia-Artikel zur Rewrite-Engine, zur Domainweiterleitung und zum cloaking (Deutsch):
http://de.wikipedia.org/wiki/Rewrite-Engine
http://de.wikipedia.org/wiki/Domainweiterleitung
http://de.wikipedia.org/wiki/Cloaking

Apache-Dokumentation zum Modul "mod_rewrite" (Englisch):
http://httpd.apache.org/docs/current/en/mod/mod_rewrite.html
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html

Erklärung der Flags im Modul "mod_rewrite" (Englisch):
http://httpd.apache.org/docs/2.2/rewrite/flags.html

Apache-Dokumentation zum Modoul "mod_alias", welches Aliase setzen kann (Englisch):
http://httpd.apache.org/docs/current/mod/mod_alias.html

Erklärungen zum Unterschied zwischen "mod_rewrite" und "mod_alias" (Englisch):
http://stackoverflow.com/questions/808014/mod-rewrite-or-mod-alias
http://stackoverflow.com/questions/4856193/using-mod-rewrite-and-mod-alias-redirect-301-together-in-htaccess

Interessanter Artikel zum Thema: Schadet eine 301 Weiterleitung dem PageRank? (Deutsch):
http://www.website-boosting.de/blog/2013-02-26/301-weiterleitung-pagerank.html

Und zu guterletzt noch eine passende Diskussion in einem Forum:
http://forum.joergkrusesweb.de/per-301-redirect-verschiedene-seiten-umleiten-t-766-1.html

Aufgrund des aktuellen Skandals um die Überwachungsprogramme PRISM und Tempora erfährt man auch etwas über die Überwachung des Internets durch den Bundesnachrichtendienst (BND). Dabei kann der BND am De-Cix-Hauptknoten in Frankfurt mit einer Regelung bis zu 20% des deutschen Internetverkehrs einfach abschöpfen. Momentan sind es aber wohl eher 5%, was erklären würde, warum der BND aktuell um ca. 100 Millionen Euro aufgestockt werden soll. Dies würde vielleicht auch das Abschöpfen der restlichen 15% ermöglichen.

Hier ein Link zum Thema zu Heise:
http://www.heise.de/newsticker/meldung/NSA-Abhoerskandal-PRISM-Internet-Austauschknoten-als-Abhoerziele-1909604.html

Und hier ein Link zum Thema zu Spiegel Online:
http://www.spiegel.de/netzwelt/netzpolitik/prism-tempora-und-die-bundesregierung-a-908250.html

Vor einiger Zeit gab es die Meldung (http://www.undertec.de/blog/2012/07/hack-bei-gmx---die-gmx-katastrophe.html) das GMX mit einer Hackerattacke zu kämpfen hatte, bei der GMX aber davon ausging, dass es sich nicht um einen Brute-Force-Angriff im großen Stil gehandelt habe (also nicht 300.000 Accounts sondern nur 3000 kompromittierte, siehe auch http://www.heise.de/newsticker/meldung/Ueber-300-000-GMX-Accounts-kompromittiert-1637510.html). Angeblich wurden auch Logins anderer Provider ausprobiert, was darauf schließen lässt, dass die verwendete E-Mail/Passwort-Liste bei einem anderen Angriff erbeutet wurde.

Vor ein paar Tagen ergab sich aber hier der Gegenbeweis dazu. An eine E-Mail-Adresse die nur für eine einzige Mailingliste genutzt wird und bei der mit hundertprozentiger Sicherheit noch nie die im Postfach eingestellte Vornamen/Nachnamen Kombination als "Display name" verwendet wurde, kam eine Spam-Abmahnmail die genau diese Anrede benutzte. Interessanterweise ist diese Anrede nirgends im lokal verwendeten Mail-Client gespeichert und auch nicht in irgendwelchen Einstellungen die extern zu der Mailingliste gehören. Bleibt also die große Frage, wie der Spammer an diese Vornamen/Nachnamen-Kombination gekommen ist? Ein reiner Brute-Force-Angriff ist bei der Schwierigkeit des Passworts des Accounts eher auszuschließen. Viel eher erscheint es, als wenn entweder ein Admin-Konto mit Zugang zur Kundendatenbank oder aber ein Leak für die Offenlegung dieser Adressen bei GMX zuständig scheint.

Auf jeden Fall ist dies ein eindeutiges Zeichen dafür, dass man sein Passwort bei GMX regelmäßig ändern sollte oder sich aber einen neuen Account bei einem anderen Provider zulegen sollte, wobei man heutzutage hier aber ebenfalls mit solchen Problemen rechnen kann.

 

Über dieses Archiv

Diese Seite enthält aktuelle Einträge der Kategorie Internet.

IGEL ist die vorherige Kategorie.

IPSec ist die nächste Kategorie.

Aktuelle Einträge finden Sie auf der Startseite, alle Einträge in den Archiven.

April 2015

So Mo Di Mi Do Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Etter EDV- und IT-Dienstleistungen
Powered by Movable Type 5.04

Google Werbung:

Google Werbung: