Debitel Spam Mail mit Virus im Anhang

Heute habe ich eine -vermeintlich von Debitel stammende – Spammail erhalten. Diese Spamemail hatte den Anhang Daten.zip.

Nachdem ich in Österreich lebe bzw. kein Debitelkunde bin, kam mir die Sache natürlich sofort komisch vor. Kurzerhand also den Anhang auf www.virustotal.com hochgeladen und schon hagelte es Trojanerwarnungen.

Dabei handelt es sich offenbar um eine weitere Variante des Trojan.Ransomlock.p (Symantec), der den PC sperrt und danach EUR 100,- für eine „Freischaltung“ haben will.

Also bei folgender Email bitte aufpassen, wobei der Inhalt wahrscheinlich variiert:

Sehr geehrter xxx, diese Mail wurde bei der Vertragsunterzeichnung von 1 DebitelE-Plus Mobilfunk Verträgen angegeben. Die Simkarten wurden bei der Unterzeichnung zu Verfügung gestellt.

Sicher ist es Ihnen entgangen, dass die Bezahlfrist der nachfolgenden Rechnung abgelaufen ist. Auf unsere Mahnungsschreiben haben Sie ebenso nicht reagiert. Summe Mai: 942,48 Euro Wir bitten Sie, den Gesamtbetrag in den nächsten 5 Tagen zu überweisen.

Die Handys sollten an Ihre Adresse versendet werden.

Leider waren mehrfache Zustellversuche nicht erfolgreich. Wir bitten Sie uns mitzuteilen was mit den beiden Mobilfunkgeräten (iPhone 4S) gemacht werden soll. In Beilage senden wir Ihnen die Vertragskopie, die Ausweiskopie des Vertrages, Rechnungen so wie den Einzelverbindungsnachweis. Teilen Sie uns bitte mit an welche Adresse die Telefone versendet werden sollen.

Mit besten Grüßen

(..Hier steht dann eine Gmbh..
…die ich entfernt habe … da die damit wahrscheinlich nix am Hut hat)

Fortigate Firewall – L2TP und IPSEC VPN + Einwahl mittels Windows Verbindung

Obwohl im Handbuch der Fortigate sehr gut beschrieben (Fortigate IPSEC Handbuch) folgt hier eine Zusammenfassung der Einrichtung eines L2TP/IPSEC VPN. Grundsätzlich halte ich mich exakt an die Vorgaben des Handbuches, jedoch habe ich bei einigen Bereichen eine etwas ausführlichere Beschreibung hinzugefügt.

Voraussetzung

  • L2TP-Traffic muss erlaubt sein.
  • Clientseitig muss Windows 2000 oder höher eingesetzt werden
  • Firewall ist im NAT Mode

Anlegen eines Users und einer Gruppe

Zuerst legen wir einen User auf der Firewall an. Hierfür loggen wir uns in die Fortigate ein. Dann wählen wir auf der linken Seite :

  • USER -> User
  • dann im rechten Fenster (oben) -> Create New
  • Im folgenden Fenster vergeben wir einen Usernamen. Dieser Name ist dann im VPN Client (Verbindungsfenster von Windows ) als Benutzername einzugeben. Ich wähle hier VPN_User1
  • Im Feld Password wird – wie der Name vermuten lässt – das Passwort eingetragen. Dieses sollte möglichst KEIN erratbares Kennwort sein, Sonderzeichen, Groß- und Kleinschreibung, Buchstaben und Ziffern sind anzuraten! Dieses Passwort wird  (später)  im Verbindungsfenster  der VPN Verbindung (Feld Passwort) eingegeben.
  • Die Fortigate überprüft bei Verbindungsaufbau die oben angegebenen Daten. Allerdings müssen diese VPN User einer Gruppe zugeordnet werden!

Erstellen der Gruppe bzw. Zuordnung des User

Wir gehen im Adminbackend der Fortigate folgendermaßen vor, um eine Gruppe zu erstellen und den User der Gruppe zuzuordnen:

  • USER -> User Group -> User Group
  • dann (wieder oben im rechten Fenster) auf Create New
  • Unter Name kann ein beliebiger Name eingegeben werden. Achtung: Diesen Namen bitte merken (muss später weiter verwendet werden!). Ich nehme hier L2TP_Usergroup als Gruppenname.
  • Unter Available Users sehen wir unseren zuvor angelegten User (VPN_User1)
  • Diesen User klicken wir doppelt an. Er springt dann hinüber in das Fenster Members (der soeben erstellten Gruppe).
  • Wir klicken auf OK und haben somit User und Gruppe angelegt.

Man muss den User NICHT direkt auf der Fortigate anlegen. Es ist auch möglich, einen LDAP Lookup zu realisieren. Darauf gehe ich hier jedoch NICHT ein!

L2TP konfigurieren

Nun müssen wir im „Linuxstyle“ L2TP aktivieren und die IP Range festlegen, die sich einwählende Clients, angeboten bekommen. Linuxstyle deshalb, da man das nur mit der CLI der Fortigate machen kann.

  • Einloggen ins Adminbackend
  • Wir sollten nun am Dashboard sein (Linke Seite oben Dashboard -> Dashboard)
  • Falls keine CLI Konsole angezeigt wird: Im rechten Fenster oben auf -> + Widget klicken.
  • Im folgenden Fenster CLI Konsole wählen und Fenster schließen
  • Nun sollte am Dashboard die CLI Konsole erscheinen
  • Durch Klick in das Fenster aktivieren wir die Konsole

Jetzt brauchen wir den exakten Namen der zuvor erstellten Gruppe. In meinem Beispiel hat die Gruppe L2TP_Usergroup geheissen!

wir tippen in die Console, jede Zeile gefolgt von einem RETURN:

config vpn l2tp
set sip 192.168.1.100
set eip 192.168.1.100
set status enable
set usrgrp „L2TP_Usergroup“
end

Im obigen Beispiel wird dem VPN Client nur eine IP Adresse  – nämlich 192.168.1.100 – angeboten. Wenn man hier will, dass mehrere IPs angeboten werden (da es mehrer externe Clients gibt), setzt man die „set eip“ auf einen anderen Wert z.B.: 192.168.1.150

Adresse bzw. Adressrange der VPN Verbindung auf der Firwall anlegen

Die im vorhergehenden Schritt angelegte Adresse (192.168.1.100) bzw. eine eventuell angelegte größere Range ist in der Fortigate unter:

  • Firewall Objects
  • Address
  • Address
  • rechtes Fenster (oben)
  • Create new

anzulegen.

Als Name vergeben wir Adr_VPN1. Als IP die zuvor erstellte 192.168.1.100 (oder eben die Range (von bis) die man in der Konsole angegeben hat. Ich bleibe hier aber bei 192.168.1.100!

IPSec konfigurieren – Phase 1

IPSec wird vom MS-VPN-Client zur Verschlüsselung verwendet. Zur Konfiguration gehen wir wie folgend vor:

  • Wir gehen ins Adminbackend der Fortigate (falls wir dort nicht schon sind)
  • VPN -> IPSec -> Auto Key (IKE)
  • Klick auf Create Phase 1
  • Unter Name geben wir einen beliebigen Namen für die Verbindung ein (ich nehme hier dial_up_p1
  • Remote Gateway: Dialup User
  • Local Interface: Auswahl des Interfacenamen, das mit dem Internet verbunden ist (meist WAN1)
  • Mode: Main (ID Protection)
  • Authentication Method: Preshared Key
  • Pre-shared-Key: Hier einen Key eingeben (möglichst komplex!). Dieser Key wird unter Windows dann bei den Sicherheitseinstellungen (Eigenschaften der Windows VPN Verbindung -> Reiter Sicherheit -> unten -> IPSec-Einstellungen -> Vorinstallierter Schlüssel für Authentifizierung) verwendet
  • Klick auf Advanced
  • Enable IPSec Interface Mode (Diese Einstellung DARF NICHT aktiv sein!)
  • P1 Proposal: Folgende Verschlüsselungspaar wählen: AES256 – MD5, 3DES-SHA1, AES192-SHA1
  • DH-Group: 2
  • NAT-Traversal: Enable
  • Dead Peer Detection: Enable

 Konfigurieren von Phase 2

  • Wir sind (noch immer) im Adminbackend
  • VPN -> IPSEC -> Auto Key (IKE)
  • Klick auf Create Phase 2
  • Name: Beliebiger Name für die Phase 2 (ich nehme: dial_up_p2)
  • Phase 1: Wählt hier im Dropdownmenü die zuvor erstelle Phase1-Verbindung (dial_up_p1).
  • Klick auf Advanced
  • P2 Proposal: Folgende Paare wählen: AES256-MD5, 3DES-SHA1, AES192-SHA1 (Info: wenn man rechts neben den Paaren auf das + klickt, kann man ein weiteres Paar hinzufügen).
  • Enable replay detection: Enable
  • Enable perfect forward secrecy (PFS): Disable
  • Keylife: 3600 seconds

Nun müssen wir uns nochmals in die CLI Konsole begeben, um den Transportmodus für diese VPN Verbindung zu aktivieren:

  • Wieder ins Fortigate Backend
  • Dashboard -> CLI-Konsole (in das Fenster klicken)
  • danach schreiben wir folgendes:

config vpn ipsec phase2
edit dial_up_p2
set encapsulation transport-mode
end

Konfigurieren der Security Policies

für L2TP über IPSec benötigt man folgende Policies:

  • Eine IPSec Policy – wie bei jedem policy based VPN
  • Eine „ACCEPT“ Policy um den Traffic von L2TP Clients  in das „geschützte“ interne Netzwerk zu erlauben. Anmerkung: Hier ist wahrscheinlich etwas verwirrend, dass die Policy nicht von WAN (EXTERNAL) nach LAN (Internal) zu erstellen ist, sondern von LAN nach WAN! Aber dazu kommen wir gleich.

Wie immer sind wir im Fortigate-Backend und machen folgendes:

  • Policy -> Policy -> Policy -> Create New
  • Source Interface: Internal
  • Source Adress: all, ODER einen ganz speziellen internen Rechner, den man zuvor als Adresse in der Fortigate angelegt hat. Man kann so also den Zugriff auf einen Rechner begrenzen.
  • Destination: WAN1 (bzw. der Port, der eben in das öffentliche Netz (Internet) „geht“.
  • Destination Adress: all, ODER eben auch hier eine Einschränkung falls der Einwahlpunkt mit einer statischen offiziellen IP ausgestattet ist! Zum Testen würd ich jedoch mal auf „all“ bleiben.
  • Service: any oder eben entsprechend einschränken
  • Action: IPSEC
  • VPN Tunnel: Hier wählt man dann den Namen aus, den man bei Phase 1 bei der VPN Erstellung angegeben hat. In unserem Beispiel also dial_up_p1
  • Allow Inbound: Enable
  • Allow Outbound: Enable
  • UTM: Optionale Einstellungen (Virenscan etc)

Nun muss noch eine Policy erstellt werden, die den Verkehr zwischen dem VPN Client (IP 192.168.1.100) und dem internen Netz erlaubt. (Diesmal von WAN1 nach Internal):

  • Fortigate Backend
  • Policy -> Policy -> Policy
  • Create New
  • Source Interface: WAN1
  • Source Adress: Wir suchen unsere am Anfang angelegte ADR_VPN1 und wählen sie aus
  • Destination Interface: LAN (Internal)
  • Destination Adress: all
  • Service: any oder eben entsprechend einschränken
  • Action: Accept
  • UTM: Optionale Einstellungen (Virenscan etc)

Nun sollten also die notwendigen Schritte erledigt sein, um die Fortigate zu konfigurieren. Als nächstes gilt es nur noch, Windows entsprechend zu konfigurieren.

Die Windows Konfiguration

Ich habe hier noch Windows XP laufen. Unter XP ist folgendes zu machen:

  • Start -> Einstellungen -> Netzwerkverbindungen
  • Neue Verbindung erstellen
  • Verbindung mit dem Netzwerk am Arbeitsplatz herstellen
  • VPN-Verbindung
  • Firmenname -> Beliebig
  • Hostname oder IP = offizielle (WAN1) IP der Fortigate die als VPN Server dient

Im Verbindungsfenster gibt man als Benutzername den Benutzernamen ein, den wir auf der Fortigate als User angelegt haben. In unserem Beispiel wäre das: VPN_User1 (achtet auf Groß-/Kleinschreibung!). Das Passwort entspricht dem auf der Forti für den User angelegten Passwort.

Danach klicken wir auf Eigenschaften -> gehen auf Reiter Sicherheit. Die Einstellung sollte auf: Typisch -> Sicheres Kennwort ist erforderlich stehen + Datenverschlüsselung ist erforderlich muss angehakt sein.

Unten rechts klicken wir nun auf IPSEC-Einstellungen. Wir setzen das Häkchen bei Vorinstallierter Schlüssel für Authentifizierung verwenden. Danach geben wir als Schlüssel den Schlüssel ein, den wir für die VPN Verbindung Phase 1 vergeben haben.

Somit ist nun alles erledigt und die VPN Verbindung sollte funktionieren.

 

 

Fortigate Firewall

Hardwarefirewalls  und Appliances gibt es wie Sand am Meer. Jedoch möchte ich hier mit einer Serie zu den Firewalls (Appliances) der Firma Fortinet (Fortigate) starten.

Unbedingt hervorheben möchte ich, dass es bei den Fortigates keine Kostenstaffelung nach Anzahl der – auf der Firewall „hängenden“ – User gibt. Ebenso gibt es generell KEINE Userlimitierung.

Betrachtet man abseits davon noch den Leistungsumfang UND die vergleichsweise günstigen Anschaffungskosten, gepaart mit der doch sehr einfachen Konfiguration, gibt es – zumindest aus meiner Sicht – nichts, was gegen eine Fortigate spricht!

Allgemeine Informationen

Die „Firewalls“ werden normalerweise inkl. einem Abo (genannt Fortiguard Services) verkauft. Diese Services beinhalten:

  • Antivirus (Definitionen)
  • IPS (Definitionen)
  • Webfiltering (Webfilter, Contentfilter nach Ratings, die von Fortinet gewartet werden)
  • Emailfiltering

Ebenso KANN Hardware, Firmware und ein erweiterter Support vorhanden sein.

Wichtige Links

In den kommenden Artikeln werde ich darauf eingehen, wie man  VPN Verbindungen (Site – to – Site mit 2 Fortigates)  und IPSEC / L2TP (Standard Windows VPN) einrichtet.

 

 

ACHTUNG – Sicherheitslücke in Joomla 1.6.0 bis 2.5.2

Eine kritische Sicherheitslücke ist in allen Versionen von 1.6.0 bis 2.5.2 gefunden worden. Es gibt bereits einen Patch, der ohne Probleme eingespielt werden kann, sofern man nicht noch mit einer jetzt unsupporteten Joomlaversion „herumgurkt“.

Da die Lücke bereits öffentlich bekannt ist und somit auch von Laien ausgenutzt werden kann, gilt es das SICHERHEITSUPDATE SOFORT einzuspielen.

Infos hier: http://www.joomlaportal.de/joomla-2-5-joomla-1-7-installation/273605-sammelthread-joomla-version-2-5-3-a-6.html#post1335718

Downloadpaket: http://www.joomla.org/announcements/release-news/5416-joomla-253-released.html

Ich konnte ohne Probleme mittlerweile 7 Webauftritt auf 2.5.3 hochziehen.

Keep patching! 😉

Backscatter – das Geschäft mit den Spamlisten

Gerade heute wurde ich durch einen Freund, der einen Webserver betreibt damit konfrontiert, wie einige Spamlistenbetreiber mit der Listung und Delistung von diversen Servern umgehen, die sich „böse“ verhalten.

Eine gut gewartete Spam-Blacklist gut und schön. Jedoch kommt mir bei einigen Betreibern fast schon das Mittagessen hoch, wenn ich mir die gängige Praxis ansehe.

Die Rede ist im folgenden von backscatter.org. Eigentlich ist backscatter.org keine Blacklist – so zumindest der Betreiber. Auf erwähnter Liste landen Server, die gar zu „gesprächig“ sind.

Was meine ich nun mit gesprächig? (Achtung verwirrend 😉 )

Während der Emailkommunikation „unterhalten“ sich der sendende und der empfangende Mailserver miteinander. Je nach Situation wird hier dann die eigentliche Übermittlung gestartet, oder angehalten.

Backscatter geschieht dann, wenn ein Mailserver eine Email nicht annehmen kann und dem Absender der Mail (mail from:) eine entsprechende Fehlermeldung übermittelt. Alles noch kein Problem, sofern es sich bei dem Absender um keine gefakte Adresse handelt!

Sobald nun aber eine fremde Absendeadresse (die existiert und somit missbraucht wird!) verwendet wird und  eine Email mit einem nicht existierenden  Empfänger an eine existierende Maildomain geschickt wird, bekommt die wirklich existierende Absendeadresse eine Fehlermeldung per Email (oft vom Mailer-Daemon) retour, sofern der Mailserver die Kommunikation nicht schon während der Verbindungsinitialsierung abbricht.

Der Mailserver muss so reagieren, dass er mit einem 550 Recipient not here reagiert und die Kommunikation abbricht, ohne eine Info per Email an den vermeintlichen Absender (der die Email gar nicht gesendet hat) zu übermitteln.

Nimmt der Mailserver aber die Email an und erzeugt eine Fehlermeldung, die er dann an den Absender schickt, haben wir Backscatter.

Hier kommt dann zum Beispiel auch Bounce-Spam zum Zug. Der Vorgang ist hier eigentlich gleich. Der Absender (der sich eine existierende Mailadresse als Absendeaddi schnappt), schickt eine Spammail an einen nicht existierenden Empfänger.

Reagiert der Mailserver nicht mit einem „550 Recipent not here“ sondern schickt eine Fehlermeldung per Email an den  Absender, hätten wir also auch gleich den Spam zugestellt.

Dies nur dann, wenn der Mailserver so konfiguriert ist, dass er bei fehlerhaften Zustellungen die Originalmail an die Fehlermeldung anhängt und an den (wieder vermeintlichen) Absender zurück schickt.

Um es nochmals kurz zu sagen, zitiere ich den Wikiartikel zu dem Thema:

Backscatter bei E-Mails ist Rückstreuung durch Delivery Status Notifications, die auf gefälschte Absenderadressen antworten.

Quelle: Wikipedia

 Zurück zum eigentlichen Thema

Ist der Server mal gelistet, verhält es sich bei einigen Blacklists so, dass man sich „Express delisten“ kann. Will man diese Leistung in Anspruch nehmen, muss man allerdings zahlen. Und das ist oft nicht mal wenig! Die Beträge, die man hier „los wird“, bewegen sich so um die EUR 80,-.

Aber Achtung! Nur weil man danach nicht mehr gelistet ist, heißt das nicht, dass man nicht wieder auf die Liste kommt.

Selbst wenn man wirklich für das Delist zahlt, bekommt man bei einigen Anbietern keine Info darüber, warum man denn eigentlich gelistet worden ist. Naturgemäß fällt dann bei nicht offensichtlicher Fehlkonfiguration eine Analyse schwer.

Die Listen mögen ja teilweise nicht schlecht sein, jedoch sind die Geschäftspraktiken bei einigen Anbietern mehr als zwielichtig. Wenn man schon für das Entfernen von der Spamliste bezahlt, dann soll man VERDAMMT NOCHMAL auch erfahren, weshalb man auf die Liste gekommen ist.

Gerade bei großen Mailservern und tausenden Usern kann es passieren, dass man -aufgrund der Übersensibilität dieser Listen- auf einer solchen landet.

Viele mögen jetzt mit dem Argument kommen: „Wer einen Mailserver betreibt, muss auch dafür sorgen, dass er sicher ist und sich den gängigen RFCs unterwirft!“

Klares JA von mir!

  • Es kann aber nicht sein, dass Server gelistet werden, die lt. gängigen Spamrelaytests und auch Backscatter-Tests weder ein Openrelay sind, noch Backscatter verursachen.
  • Es kann nicht sein, dass der Gelistete keine Information darüber bekommt, weshalb er gelistet worden ist! Schon gar nicht, wenn man für das Delisting etwas bezahlen muss.
  • Wo ist hier die Kontrolle? Wer kontrolliert hier überhaupt, was auf derlei Listen ab geht?
  • Wenn man eine solche Leistung anbietet und dafür noch dazu Geld verlangt, dann sehe ich es als Verpflichtung an, dem Gelisteten entsprechende Infos zukommen zu lassen!

Ganz vorne dabei ist hier meiner Erfahrung nach www.backscatter.org!

  • Undurchsichtig
  • Unfreundlich
  • Übersensibel

Es ist für mich grob fahrlässig, dass große Provider Listen wie backscatter.org eine derartige Gewichtung bei Spambewertungen einräumen, dass Emails dadurch blockiert werden.