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/

Tobias Langner
Ich arbeite seit mehreren Jahren als IT-Administrator, bin ausgebildeter Fachinformatiker für Systemintegration und Studium-„Pausierer“ an der FernUni Hagen

Achtung: Für die Richtigkeit der zur Verfügung gestellten Informationen, Skripte, etc. übernehme ich keine Gewähr. Deren Nutzung geschieht ausdrücklich auf eigene Gefahr!

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

Tobias Langner
Ich arbeite seit mehreren Jahren als IT-Administrator, bin ausgebildeter Fachinformatiker für Systemintegration und Studium-„Pausierer“ an der FernUni Hagen

Achtung: Für die Richtigkeit der zur Verfügung gestellten Informationen, Skripte, etc. übernehme ich keine Gewähr. Deren Nutzung geschieht ausdrücklich auf eigene Gefahr!

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.

Tobias Langner
Ich arbeite seit mehreren Jahren als IT-Administrator, bin ausgebildeter Fachinformatiker für Systemintegration und Studium-„Pausierer“ an der FernUni Hagen

Achtung: Für die Richtigkeit der zur Verfügung gestellten Informationen, Skripte, etc. übernehme ich keine Gewähr. Deren Nutzung geschieht ausdrücklich auf eigene Gefahr!