Betrugsmasche mit angeblicher Domain-Registrierung

Eine Mitarbeiterin von einem Unternehmen in dessen Namen die Worte „Mark“, „Office“ und „Trade“ vorkommen rief an und behauptete jemand würde gerade versuchen den Firmennamen meines Arbeitgebers als .net-Domain, die bisher noch frei war, zu registrieren. Angeblich würde man uns wegen eines Vorrechts aufgrund des Firmen- bzw. Markennamens anbieten die Domain „wegzuschnappen“. Da sich die Domain aber nun im Registrierprozess befindet, sei es nicht mehr möglich die Domain normal über einen Provider zu registrieren, sondern man  müsse die nun direkt bei diesem Anbieter übernehmen. Klar, natürlich nur für einen saftigen Obulus von 300 € für eine Laufzeit von 10 oder 15 Jahren. Ob die 300€ jährlich gemeint waren weiß cih an der Stelle agr nicht. Die Domainchecks bei allen gängigen Providern zeigten die besagte Domain aber alle als frei käuflich an.

Hier wird anscheinend darauf abgezielt Firmen die eventuell keine eigene IT-Abteilung haben dazu zu bringen die Domain aus Angst, dass nachher wirklich jemand unter dem Firmennamen eine Domain betreibt, zu kaufen.

Ein ähnlicher Vorfall wird hier bei domain-factory beschrieben:
https://www.df.eu/blog/hinweis-auf-betrugsmasche-und-warnung-vor-angeblichen-anrufen-des-hostproviders/

IPTables, eine DMZ und der Providerwechsel

IST-Zustand:
Es gibt eine auf iptables basierende OpenSuse-Firewall. Diese wird im Normalfall durch den Firewallbuilder administriert. Es gibt eine DMZ mit öffentlichen IP-Adressen. Ob das grundsätzlich so die beste Lösung ist, lasse ich an dieser Stelle außen vor. Eine neue schnellere Internetanbindung bei einem anderen Provider kommt dazu.

SOLL-Zustand:
Da die neue Leitung schneller ist und der Chef meistens ungerne Geld für etwas ungenutztes ausgibt, sollte die Leitung natürlich sofort genutzt werden. Da sich aber bei der Umschaltung der DMZ viele kleine Probleme ergeben können und auch die Domains auf die neuen IPs gewechselt werden müssen, bin ich hier lieber einzeln vorgegangen. Also musste für den anstehenden Providerwechsel die DMZ schrittweise auf ein anderes öffentliches IP-Netz umgestellt werden.

Hier habe ich mal den für dieses Szenario relevanten Teil des Netzes grafisch dargestellt:

Problematik:
Das Intranet auf den neuen Zugang umzustellen kann man relativ unkompliziert machen. Anfragen ins Internet gehen dann über die geänderte Default-Route über den neuen Router und die Antworten kommen über diesen wieder zurück und werden an die Clients im Intranet geliefert:

 

Im Fall der DMZ, oder auch bei Freigaben per Port Forwarding, die noch über eine der alten öffentlichen IPs realisiert werden (wie z.B. oft für Exchange OWA), hat man nun allerdings aufgrund der geänderten Default-Route ein Problem. Die Anfragen kommen über ISP 1 aus dem Internet an, passieren die Firewall und gehen an den entsprechenden Server. Die Antwort vom Server geht aufgrund der Default Route in der Firewall aber an Router 2 und damit unter einer der neuen öffentlichen IPs über ISP 2 raus ins Internet. Das funktioniert so nicht, da der anfragende Computer diese IP in dem Kontext nun gar nicht kennt und die ankommenden Pakete verwerfen wird:

Das Problem besteht also darin, dass für die alte DMZ die neue „Default Route“ der Firewall, laut der Pakete über den neuen Router raus ins Internet geschickt werden, übergangen werden muss. Eine einfache Regel dafür lässt sich leider im Firewallbuilder nicht erstellen. Somit muss man leider drum herum manuell am Routing basteln.

 

Info:
Ebenfalls hilfreich ist die Lösung dieses Artikels wenn man dauerhaft 2 Internetleitungen nutzen möchte, z. B. eine Leitung fürs Surfen und eine weitere für VPNs oder eine DMZ.

 

Lösungsansätze:
Eine Möglichkeit wäre es die entsprechenden Pakete, die von einer bestimmten Source kommen, in diesem Fall aus der alten DMZ, und an ein der Firewall nicht bekanntes Ziel geschickt werden zu markieren und entsprechend dieser Markierung abzufangen und dann an ein anderes als das Default-Ziel umzuleiten. Das war mir aber zu viel des guten.


Die einfache Lösung für dieses Problem nennt sich „Policy Based Routing“ oder in diesem speziellen Fall „Source Based Routing“. Hierbei wird für das Routing nicht nur die Ziel-Adresse berücksichtigt, sondern auch die Quell-Adresse. Wie es sich für einen Nerd gehört kam ich nachts um 3 Uhr auf diese Lösung, als ich übelst krank gewesen bin und habe direkt nachts die Testumgebung dafür hochgezogen 😉

Meine Testumgebung besteht aus 5 virtuellen Maschinen auf denen OpenSuse läuft:

 

Auf die Einrichtung der iptables-Firewall soll dieser Artikel nicht eingehen. In der Test-Firewall steht nicht viel drin. Für den Live-Betrieb ist diese natürlich nicht verwendbar, da ich einfach alles zulasse.

Unter /etc/firewall habe ich das iptables-Skript firewall.fw abgelegt und in der
/etc/init.d/boot.local für den automatischen Start beim Systemstart eingetragen.

Für das Routing habe ich zwei Regeln erstellt, um die Default Route entweder über Router 1 oder Router 2 zu realisieren. Durch das Aktivieren der jeweils anderen Regel kann man hier leicht hin- und herwechseln.

In der Datei /etc/iproute2/rt_tables werden die Routing-Tabellen, die beim Systemstart aufgebaut werden, festgelegt. Entweder kann man einen neuen Eintrag für eine weitere Routing-Tabelle direkt in die Datei schreiben oder mit folgendem Befehl hinzufügen:

Diese Routing-Tabelle muss nun nur noch mit Regeln gefüllt werden. Da diese nach einem System-Neustart wieder flöten gehen, legt man dafür am besten ein eigenes Skript an. Ich habe dafür unter /etc/firewall das Skript dmz.sh erstellt und ausführbar gemacht. Auch dieses Skript wird in der /etc/init.d/boot.local für den automatischen Start beim Systemstart eingetragen.

Die erste Regel die benötigt wird gibt an wann die Routing-Tabelle genutzt werden soll. In diesem Beispiel bei Traffic aus dem Netz 192.168.3.0/24:

In diese Tabelle kommt nun noch die Default Route über den alten Router:

Das reicht aber noch nicht. Es fehlen noch die Routen für die anderen Netze, ansonsten sind diese von dieser Routing-Tabelle aus nicht mehr erreichbar:

 

Quellen:
http://www.marcosorfila.com/site/firewall-builder-with-multiple-isp-connections
http://www.marcosorfila.com/site/wp-content/uploads/Firewall-Builder-with-multiple-ISP-connections/ip_rules
http://wiki.linux-club.de/opensuse/Policy_Based_Routing
http://www.cyberciti.biz/faq/howto-linux-configuring-default-route-with-ipcommand/
http://www.linuxjournal.com/content/linux-advanced-routing-tutorial?page=0,3
http://superuser.com/questions/784331/hooking-linux-machine-to-secondary-router-isp-how-to-setup-routing-correctly
http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming/23345#23345
http://opensuse.14.x6.nabble.com/yast2-advanced-routing-td3083578.html
http://www.rjsystems.nl/en/2100-adv-routing.php
http://www.linuxhorizon.ro/iproute2.html

SBS Server: POP3-Mailabruf über zweite Leitung

Wenn man eine zweite Internet-Leitung hat, die über einen weiteren Router aus dem Netzwerk nutzbar ist, lässt sich der POP3-Mailabruf auf einem Small Business Server im Notfall oder zur Lastverteilung über diesen umleiten. Dies ist zwar kein optimales Setup, aber in einer kleineren Umgebung durchaus eine vorübergehende „Absicherung“ wenn eine der Leitungen ausfällt.

Als erstes benötigt man die IP-Adressen des POP3-Servers:

Den Traffic an diese IP-Adressen leitet man dann an den zweiten Router:

P steht für „persistant“ und sorgt dafür, dass die Routen dauerhaft, also auch nach einem Neustart, bestehen.

Um die Routen wieder loszuwerden, benötigt man nur folgenden Befehl für die beiden Adressen:

Wenn man sich diese Befehle in Batch-Dateien speichert kann man so recht einfach zwischen den beiden Leitungen hin und her wechseln.

Nutzbar wäre dies z.B. auch für den Mail-Versand über SMTP oder den Abruf von Updates über den WSUS.

Migration von POP3- oder IMAP-Konten auf einen Exchange-Server

Wenn eine überschaubare Anzahl von extern gelagerten E-Mail-Konten auf einen Exchange-Server verschoben werden soll, lässt sich dies recht leicht mit Hilfe von Outlook bewerkstelligen. In diesem Fall war ein Großteil der Konten von vornherein schon auf dem Exchange und eine Hand voll Außendienstmitarbeitern hatten ihre Konten direkt vom Provider auf ihren Geräten eingebunden.

Nach der Anlage des entsprechenden Benutzers und seines Mail-Kontos im Active Directory holt man sich als Administrator die vollen Rechte für das Mail-Konto und bindet dieses als Zusatzkonto in Outlook ein.

Am besten ist es, wenn sich die Konten per IMAP einbinden lassen, was heutzutage bei jedem halbwegs vernünftigen Provider kein Problem darstellen sollte. Zusätzlich zum Exchange-Konto bindet man nun das extern gelagerte Postfach per IMAP in Outlook ein. Natürlich nur ausgehend davon, dass der betroffene Mitarbeiter dieser Aktion zugestimmt hat bzw. das Mail-Konto ausdrücklich nur beruflich genutzt werden darf!

Nun verschiebt man alle Mails aus dem Posteingang, Gesendete Elemente, etc. in das Exchange-Konto. Nachdem alle Elemente verschoben sind kann man bei Nutzung eines POP3-Connectors auf dem Exchange-Server dort nun das Konto für den automatischen Abruf hinzufügen. Der Grund warum man dies nicht von vornherein machen sollte liegt an dem anfallenden Traffic zu dem es kommen kann, wenn man den Abruf aller alten E-Mails über den Connector laufen lässt. Da dies unter Umständen einige Zeit in Anspruch nehmen kann, ist die Zustellung von E-Mails an bereits auf dem Exchange-Server befindliche Mail-Konten sonst mit einer längeren Wartezeit verbunden.

Hat der betroffene Mitarbeiter seine Mails bisher per POP3 abgerufen, ist zu beachten, dass je nach Einstellung beim Client eventuell bereits alle Mails auf dem Server gelöscht wurden. Außerdem liegen die gesendeten Elemente dann nur auf dem Client. Wenn möglich sollte man das Exchange-Konto in diesem Fall auf dem Endgerät des Mitarbeiters hinzufügen und den Mail-Transfer dort vornehmen.

 

Unbedingt beachten: Wenn man schon längere Zeit bevor man die Exchange-Konten aktiv nutzen will diese auf dem Exchange-Server anlegt muss man vorerst einen abweichenden E-Mail-Alias eintragen als den tatsächlich zu nutzenden. Ansonsten hat man das Problem, dass alle intern geschickten Mails an den Mitarbeiter schon im Exchange-Postfach landen und nicht mehr an das externe Mail-Konto zugestellt werden können. Zusätzlich sollte man in den Eigenschaften des Postfachs die Mail-Adresse in der Exchange-Adressliste ausblenden. Ansonsten besteht ebenfalls die Gefahr, dass Outlook-Nutzer versehentlich schon E-Mails an das neue Exchange-Konto senden.

Nachdem alle Konten umgestellt sind, sollte man sich, sofern man eine eigene Domain besitzt, dann komplett vom POP3-Connector trennen und die Mails direkt per MX-Eintrag an einen sogenannten Smart-Host, z.B. einen Postfix-Server, schicken und von dort an den Exchange-Server weiterleiten.

Speicherverschwendung durch Installer-Dateien

Der Ordner „C:\Windows\Installer“ beinhaltet Dateien, die eventuell für die Deinstallaton von Software benötigt werden. Besonders schön kann man so eine Speicherverschwendung mit der Freeware WinDirStat visualisieren.

Dieser Ordner war bei mir mittlerweile 24 GByte groß. Den Ordner einfach zu löschen ist allerdings eine schlechte Idee, da sich dort Dateien befinden könnten die zu noch installierten Programmen gehören. Stattdessen kann man das Programm PatchCleaner verwenden um diese Dateien zu beseitigen.

Das Programm zeigt die löschbare Datenmenge an. Bei mir waren es schon beachtliche 16 GByte:

Statt die Dateien direkt zu löschen kann man diese erst einmal verschieben, was auch so vom Hersteller der Software empfohlen wird:

Nach ein paar Tagen ohne Probleme habe ich die Dateien dann endgültig gelöscht.

 

Quelle:
http://techmixx.de/windows-10-ordner-installer-loeschen/

 

Telefonie an einem Zyxel Speedlink 5501 funktioniert plötzlich nicht mehr

An einem „Zyxel Speedlink 5501“ funktionierte plötzlich die Telefonie mittels Voip nicht mehr. Die Internetverbindung war aber aufgebaut. Da die Telekom Stunden gebraucht hat um nichts herauszufinden habe ich mal einen Blick in die Routerkonfiguration geworfen. Bei den Voip-Anschlüssen der Telekom ist eigentlich keine Konfiguration der Telefonie nitwendig, da die Einwahl automatisch stattfindet. Allerdings gab es plötzlich eine auffallende Änderung bei der Rufnummernkonfiguration:

Aus irgendeinem Grund wurde bei der automatischen Einwahl die Vorwahl nicht mehr übermittelt. Unter Telefonie > Rufnummern > Voip-Konten kann man die Vorwahl eintragen, Danach läuft wieder alles einwandfrei.

Warum kein VDSL geht obwohl der Verteiler es kann

Nach viel Hin und Her scheint es aussichtslos eine schnellere Anbindung als die bisherige 16 MBit-Leitung zu bekommen und das obwohl unser Verteilerkasten definitiv ausgebaut worden ist. Die Telekom hat es sich auch nicht nehmen lassen dafür im vergangenen Jahr groß Werbung zu machen und auf alle Kästen die hässlichen pinken Werbebanner zu spannen. Man hat uns sogar deshalb angerufen und uns die schnellere Leitung angeboten. Schade nur, dass man dann erst herausgefunden hat, dass wir über einen sogenannten „Indoor DSLAM“ angebunden sind. Das bedeutet man ist über einen Port in der Vermittlungsstelle angebunden. Für VDSL, also Geschwindigkeiten jenseits von 16 MBit, müsste man aber über „Outdoor DSLAM“, einen Port direkt im Verteilerkasten, angebunden sein. Super. Da sich daran laut den technikern auch nichts ändern wird, ist das ganze wie immer auf Eis gelegt.

Würde man in Österreich wohnen hätte man hingegen kein Problem beim Ableger eines ehemals deutschen Staatsunternehmens eine LTE-Flatrate OHNE Volumen-Begrenzung, also eine wirklich vollwertige Flatrate, zu einem absoluten Hammerpreis zu bekommen: http://www.t-mobile.at/internet-zuhause-myhomenet/

Selbst die 16 MBit-Leitung ist hier teurer als der LTE-Lite Tarif! Die Kündigung an die Telekom ist deshalb raus, für 16 MBit gibt es auch günstigere Anbieter -.-

Small Business Server: Benutzer versehentlich über Active Directory-Konsole angelegt

Mittlerweile dreimal ist es mir passiert, dass ich, vermutlich aus Macht der Gewohnheit, einen neuen Benutzer für die Windows-Domäne direkt im Active Directory angelegt habe und nicht über die SBS-Konsole des Small Business Servers. Dadurch fehlt der Benutzer dort und steht z.B. auch nicht für den POP3-Connector zur Verfügung. Ich habe mir diesmal die nötigen Schritte zusammengeschrieben um diesen Benutzer nachträglich auch in die SBS-Konsole zu prügeln.

Dazu muss man in der SBS-Konsole die „Benutzer und Gruppen“-Verwaltung öffnen. Dort wählt man unter Tasks den Punkt „Benutzerrolle für Benutzerkonten ändern“. (siehe rechts)

Im sich öffnenden Dialog wählt man die Rolle aus, die den Benutzern zugewiesen werden soll, also im Regelfall „Standardbenutzer“. Die entsprechenden Einträge sollte man auf jeden Fall hinzufügen, sofern man den Benutzer schon in Gruppen etc. zugeordnet hat:

Danach muss man die Benutzerkonten auswählen. Da diese in der Übersicht nicht auftauchen muss man „Alle Benutzerkonten im Active Director anzeigen“ anhaken. Es werden zudem nur aktive Benutzerkonten aus dem AD angezeigt:

Nach einem Klick auf „Benutzerrolle ändern“ ist man durch.

Quelle:
http://microlinc.homeip.net/index.php?lev1=3&lev2=16&id=140

Beitrags-Revisionen löschen

Mit der Zeit bläht sich die WordPress-Datenbank unnötig auf, da von jedem Beitrag automatisch verschiedene Revisionen während der Erstellung und der nachträglichen Bearbeitung abgelegt werden. Bei mir waren das teilweise 50 Revisionen pro Beitrag.

Mit folgendem SQL-Befehl haut man konsequenzenlos alle Revisionen aus der Datenbank:

Dies sollte man nur anwenden, wenn man sich sehr sicher ist, dass man die alten Versionen nie wieder braucht. In meinem Fall ist die Datenbank von über 7 MByte auf gerade einmal 1,6 MByte geschrunpft und die Seite fühlt sich wieder etwas schneller an. Dass man vor solchen Aktionen ein Backup der Datenbank anlegt sollte jedem klar sein 😉