Textversion
Wer wir sind Was wir tun Aktuelles Know-How Archiv Kunden Datenschutz
Startseite Archiv 2008 - 2011 UTM - Teil I

Archiv


2015 - 2017 2012 - 2014 2008 - 2011 2006 - 2007 2004 - 2005 Download Dokumente Download Tools

PDF infiziert Digitale Signatur Phishing Zahlen steigen Outlook Problem Spamkosten WLAN Sicherheit IT Trends 2010 UTM - Teil I UTM - Teil II E-Mail Archivierung WinLine CRM WinLine SEPA + Unicode OfficeTalk - SSL-Sicherheit Papierloses Büro

Unified Thread Management (1)

|04.07.2010|

1. Einführung

Die heutige IT ist nicht lediglich als Luxus zu sehen, wenn Mitarbeiter mit ihrer Hilfe Daten aus dem Internet abrufen oder per E-Mail kommunizieren. Sie dringt immer mehr in unternehmenskritische Bereiche vor, so dass Probleme mit der IT heute fatale Folgen für das Unternehmen selbst haben können, ja sogar direkt oder indirekt zur Liquidierung eines Unternehmens beitragen können.

Schon aus diesem Grund sind heute Mechanismen zur Kontrolle der IT und der über sie abgewickelten Kommunikation notwendig. Allgemein ist eine angemessene Sicherheit in der IT fast schon zwingend nötig. Da dieses Thema sehr komplex ist, gibt es seit einiger Zeit UTM - Unified Thread Management. Es gilt fast als Wunderwaffe zur Erhöhung der IT-Sicherheit.

2. Warum Sicherheit

In einigen Fällen ist auch heute noch nicht wirklich deutlich, warum Sicherheit in der IT für Unternehmen heute ein sehr wichtiger Punkt ist. Noch viel zu häufig ist die Geschäftsführung der Ansicht, dass ein minimaler Aufwand hierfür (wenn überhaupt) sinnvoll ist - schließlich sei noch nie etwas passiert. Ein Schutz gegenüber möglichen Angriffen aus dem Internet ist oft noch einzusehen, aber auch interne Schutzmechanismen sind notwendig. Dieser Abschnitt gibt kurze Argumente zur Motivation, wobei nicht auf Details der potenziellen Gefahren eingegangen wird.

2.1. Potenzielle Gefahren durch Benutzer

Im „richtigen Leben" lassen sich die Risiken in gewisser Weise beeinflussen. So empfiehlt es sich in der einen oder anderen Stadt nicht unbedingt, nachts alleine spazieren zu gehen. Andere Viertel sind sicherer, und daher empfiehlt sich eher hier der nächtliche Spaziergang, um keinen Überfall erleben zu müssen. In der IT und speziell bei miteinander verbundenen Netzwerken lässt sich das Risiko nicht so einfach steuern. Netzwerke und Server sind heute redundant erreichbar und daher kann im Prinzip jeder Benutzer mit jedem anderen ausfallsicher kommunizieren.

Das klingt positiv, aber auch negative Dinge lassen sich mit der gleichen Ausfallsicherheit durchführen. Natürlich ist jeder einzelne Mitarbeiter im Unternehmen vertrauenswürdig und würde NIE einen Angriff gegen Systeme oder Applikationen durchführen. Bei einer sehr hohen Anzahl von Mitarbeitern ist aber ein potenzielles Risiko vorhanden, mehr noch bei der Nutzung des Internet. Unter der Annahme, dass die fast vernachlässigbare Anzahl von 0,01% der Benutzer Angriffe im Sinn haben - bei über einer Milliarde Benutzern des Internet bleiben damit (mindestens) 100.000 Personen übrig, die potenzielle Angreifer sind. Natürlich ist in den Netzwerken von Unternehmen die Zahl deutlich geringer, aber im Prinzip genügt ein einziger interner Angreifer, um einen ggf. auch hohen Schaden zu verursachen.

Insofern sollte ein Schutz gegenüber Angreifern nicht nur an der Grenze zwischen Unternehmen und Internet, sondern auch innerhalb des internen Unternehmensnetzwerkes umgesetzt werden.

2.2. Potenzielle Gefahren durch Programmcode

Heute weiß fast jeder, dass ein Rechner nie ohne einen gut funktionierenden und vor allem aktuellen Schutz gegen Schadcode betrieben werden sollte. Vorbei sind aber die Zeiten, in denen durch Viren lediglich Zeichen auf dem Monitor gelöscht oder die Standardvorlage für Microsoft Word geändert wurde. Auch ist die Anzahl der sich selbst weiter verbreitenden Würmer im Prinzip rückläufig. Heute ist es einfacher, den Benutzer mit einzubeziehen. Er wird dazu verleitet, einem Link zu folgen oder einfach nur eine Datei herunterzuladen. Als Folge wird möglicherweise Code auf dem PC installiert, z.B. ein Trojaner, der von außen ansprechbar ist oder Daten in das Internet abliefert.

Zum Spaß wird Schadcode heute eigentlich nicht mehr programmiert, von einigen Teenagern, die sich selbst etwas beweisen möchten, einmal abgesehen. Heute lässt sich mit Schadcode durchaus Geld verdienen. Besonders hierfür geeignet sind sog. Bot-Netze, die aus infizierten Systemen bestehen (Beispiel: Storm-Wurm). Die Administratoren der befallenen Systeme merken häufig nicht einmal, dass sie Mitglied eines Bot-Netzwerkes sind. Mit ihnen wird heute ein Großteil der Spam-Mails verschickt, aber auch für effektive Distributed Denial-of-Service Angriffe (DDoS) sind sie geeignet. Der Trend geht heute in Richtung Peer-to-Peer, so dass die zentralen Rechner zur Steuerung der Bot-Netze nicht mehr immer notwendig und die Betreiber von Bot-Netzwerken noch schwerer ausfindig zu machen sind.

Alleine im Storm-Botnetz sind bis zu 40.000 befallene Rechner online, verteilt auf bis zu 200 Länder. Größer noch ist das Kraken-Botnetz, in dem bis zu 400.000 (infizierte) Systeme arbeiten. Kombiniert mit der Ausfallsicherheit und Betriebssicherheit stehen also effektive Angriffsrechner zur Verfügung, die möglicherweise zu mieten und dann für eigene Zwecke einzusetzen sind - „Rent a Botnet".

2.3. Ist Sicherheit wirklich notwendig?

Natürlich könnte jetzt ein Unternehmen meinen, dass IT-Sicherheit mit einer nicht benötigten Versicherung vergleichbar und damit eigentlich überflüssig ist. Auch wenn es nicht alle Leser glauben werden, diese Meinung gibt es bei Unternehmenschefs tatsächlich ab und zu. Schon aus juristischen Gründen müssen sie aber für Sicherheit sorgen. Das fordert unter anderem das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG), das seit ca. zehn Jahren die Vorschriften des Handelsgesetzbuches (HGB) und des Aktiengesetzes (AktG) erweitert.

Hierdurch ist die Haftung der Unternehmensleitung erweitert, ebenso ist ein Risikomanagementsystem vorgesehen. Damit ist ein Früherkennungssystem für Bestand gefährdende Risiken gemeint, dass mit einem Überwachungssystem zu koppeln ist. Entgegen landläufiger Meinung betrifft das KonTraG nicht nur und alle Aktiengesellschaften, sondern auch eine KGaA und viele GmbHs. Neben dem KonTraG fordern auch das schon genannte AktG und das HGB entsprechende Maßnahmen zur Sicherheit, auch im Bereich der IT. So haftet der Vorstand einer AG möglicherweise sogar persönlich, wenn er nicht entsprechende Maßnahmen zur Vorbeugung gegenüber Risiken auch zukünftiger Entwicklungen berücksichtigt. Ebenso muss nach dem HGB der Abschlussprüfer die zutreffende Darstellung dieser Risiken prüfen.

Aber auch nach dem GmbH-Gesetz ist es nötig, dass sich die Geschäftsführung um das Thema Sicherheit und damit auch um IT-Sicherheit kümmert. Der Geschäftsführer einer GmbH muss nämlich die GmbH mit der Sorgfalt eines ordentlichen Geschäftsmannes führen. Dazu gehört auch, dass er mögliche Risiken für sein Unternehmen rechtzeitig erkennt und Maßnahmen zum angemessenen Schutz ergreift bzw. ergreifen lässt. Schließlich hat jeder, auch Privatpersonen, ein Interesse an IT-Sicherheit - wenn auch ggf. nur indirekt. Wer möchte schon, dass seine privaten, persönlichen Daten ohne seine Einwilligung im Internet abzurufen sind? Damit sind nicht Daten gemeint, die im Rahmen des Web 2.0 hinterlegt worden sind (z.B. bei den Lokalisten, studiVZ, XING, MySpace), sondern die von der Festplatte seines PCs.

3. Was ist an Sicherheit notwendig?

Wenn einigen Herstellern geglaubt werden darf, müsste jeder so viel Software und Geräte wie nur möglich kaufen, um dann bestmöglich gegenüber allen Gefahren gewappnet zu sein. Dieser Ansatz ist nicht immer sinnvoll, zumal die mitunter genannten „100% Sicherheit" nicht erreichbar sind. Zudem müssen die einzelnen Komponenten nicht nur gezahlt, sondern auch administriert werden. Insofern ist es wichtig, Sicherheit in einem angemessenen Rahmen zu betreiben. Schon kleine Maßnahmen können die Sicherheit effektiv erhöhen. Ist bereits ein hohes Sicherheitsniveau erreicht, sind zusätzliche Schritte eventuell sehr teuer und damit nicht mehr rentabel.

Die nachfolgenden Abschnitte beleuchten mögliche Schutzmechanismen, die dann auch im Rahmen von UTM in einem Gerät zu finden sind - normalerweise sind hier viele verschiedene Systeme und Applikationen notwendig, was einen erhebliche Aufwand an Administration nach sich zieht. Je aufwendiger die Administration ist, desto fehleranfälliger und damit eventuell auch potenziell unsicherer ist sie.

3.1. Firewall

Vor einigen Jahren war es noch nicht selbstverständlich, dass ein Unternehmen eine Firewall einsetzt. Vor allem war es nicht üblich, im internen und vermeintlich vertrauenswürdigen Netzwerk auch Firewalls einzusetzen. Insofern galten früher Unternehmen, die überhaupt eine Firewall einsetzen, als sehr sicherheitsbewusst. Heute genügt es nicht mehr, lediglich eine Firewall einzusetzen, vielmehr sollte eine Kombination mit weiteren Schutzmechanismen konfiguriert werden.

3.1.1. Personal Firewall


Immer mehr Rechner von Benutzern, heute oft Endpunkte genannt, haben eine Personal Firewall installiert. Sie ist manchmal schon so selbstverständlich wie der Virenschutz. Mit einer Personal Firewall werden für dieses System alle ein- und ausgehenden Verbindungen gegenüber einem Regelsatz kontrolliert und ggf. geblockt. Viele werden einsehen, dass speziell die Kontrolle von außen eingehender Verbindungen sinnvoll und wichtig ist.

Aber auch die genaue Kontrolle ausgehender Verbindungen, auch auf Applikationsebene, ist wichtig. So kann festgestellt und unterbunden werden, dass bestimmte Applikationen Verbindungen über das Netzwerk aufbauen. Auch der Schutz des Netzwerkes gegenüber von Schadcode befallenen Systemen lässt sich mit einer Personal Firewall realisieren. Neben einzelnen und individuell verwalteten Personal Firewalls gibt es von unterschiedlichen Herstellern auch zentral verwaltete Personal Firewalls. Hier kann ein Client beispielsweise nur in das Internet, wenn dieser an die Internet-Firewall gemeldet hat, dass seine Konfiguration in Ordnung ist. Teilweise werden bei solchen Lösungen dann auch Applikationen überwacht, d.h. ein Benutzer kann nur die für ihn freigegebenen Applikationen aufrufen und ebenso nur die für ihn erlaubten Ressourcen (CD, USB-Stick. etc.) nutzen.

3.1.2. Firewall zum Schutz von Netzwerksegmenten

Bereits seit vielen Jahren gibt es Firewalls, die Netzwerke unterschiedlicher Vertrauensstufen voneinander trennen. Hierfür gibt es unterschiedliche Ansätze. Ein statischer Paketfilter ist der klassische Ansatz auf Routern. Hier werden folgende Parameter gegenüber einem Regelsatz, hier meist Access Control List (ACL) genannt, geprüft:

- IP Absenderadresse
- IP Zieladresse
- Absenderport
- Zielport
- eventuell TCP Flags

Die ersten vier Parameter stellen einen sog. Socket dar und beschreiben die Verbindung eigentlich vollständig. Mit Hilfe solcher Filter lassen sich Netzwerkübergänge in gewisser Weise schützen, wobei aber prinzipbedingt bei den erlaubten Verbindungen keinerlei Kontrolle der tatsächlich übertragenen Daten erfolgen kann.

Statische Paketfilter lassen sich auf unterschiedliche Weise austricksen, z.B. durch das Fälschen von IP Absenderadressen oder auch Fragmentierungsangriffe. Weiterhin sind für einige Protokolle wie z.B. FTP oder VolP sehr große Port-Bereiche zu öffnen, so dass die insgesamt erreichbare Sicherheit heutigen Ansprüchen nicht mehr genügt. Besser ist der Einsatz der vom Hersteller Check Point entwickelten Stateful Inspection, die heute bei vielen Routern und Firewalls als Standard zu betrachten ist. Hier erfolgen weitere Untersuchungen im Kernel der Firewall, vor allem werden aber dynamische Tabellen über momentan aktive Verbindungen geführt. Damit lassen sich solche Firewalls nicht mehr so leicht austricksen. Zusätzlich ist meist eine gewisse Intelligenz integriert, so dass z.B. bei FTP die benötigten Ports selektiv und nur bei Bedarf erlaubt werden. Die mit Stateful Inspection erreichbare Sicherheit ist zumindest im Netzwerkbereich relativ gut. Aber je nach Hersteller ist auch hierbei oft keinerlei Kontrolle der tatsächlich übertragenen Daten möglich.

Eine weitergehende Kontrolle erfolgt mit Proxies, die Stellvertreterdienste anbieten. Hier ist keine direkte Verbindung zwischen Client und Server vorhanden. Der Proxy fängt die Anfrage des Clients ab und führt sie dann selbst durch. Die vom Server geschickten Daten werden dann geprüft und an den Client weitergeleitet. Eine solche Lösung setzt voraus, dass die Firewall im sog. Userspace läuft. Damit ist sie also eine normale Applikation, die mehr Ressourcen benötigt als eine im Kernel arbeitende Firewall. Dafür kann aber bei sog. Application Level Gateways das Protokoll sehr genau geprüft und beispielsweise bestimmte Befehle im HTTP oder FTP verboten werden.

Das setzt weiterhin voraus, dass die Firewall das zu untersuchende Protokoll sehr genau kennt. Als Folge wird ggf. für jedes einzelne Protokoll eine eigene Firewall-Software benötigt. Um dieses Problem zu umgehen, gibt es Circuit Level Gateways, oft auch User Defined Proxy genannt. Sie arbeiten in Schicht 6 des ISO/OSI-Schichtenmodells und können die übertragenen Daten nicht interpretieren. Dafür ist aber die Trennung zwischen Client und Server weiterhin möglich, was z.B. effektiv gegen Fragmentierungsangriffe wirken kann.

Heutige Anforderungen an Firewalls sind nicht nur das Blockieren von Verbindungen, sondern auch eine Kontrolle der über erlaubte Verbindungen übertragenen Daten. Diese geschieht heute noch oft mittels Application Level Gateways, die allerdings für hochperformante Firewalls nicht unbedingt geeignet sind. Insofern sind einige Hersteller dazu übergegangen, die Untersuchung der Daten direkt im Kernel durchzuführen. Natürlich kann hier nicht die volle Interpretation der Daten erfolgen, wohl aber eine Paket-übergreifende Mustererkennung. Diese ist schnell und die über eine erlaubte Verbindung übertragener Schadcode, Angriffe oder „komische" Befehle werden erkannt und blockiert.

Darunter fallen dann z.B. auch Angriffe über SQL-Injection oder Cross-Site Scripting. Eine Voraussetzung für den Erfolg dieser Methode ist allerdings, dass der Hersteller die Software pflegt und daher auch aktuelle Angriffe erkannt und verhindert werden.

Ein weiteres Problem dieser weitergehenden Untersuchung kann sein, dass die Einhaltung der geltenden Richtlinien (RFC - Request for Comments) durch eine Firewall zu genau überprüft wird: Ein Grundsatz ist eigentlich, dass je unternehmenskritischer eine Applikation ist, desto weniger die geltenden RFCs eingehalten werden. Insofern muss hier eine genaue Abwägung passieren, weil solche Applikationen speziell im internen Netzwerk weiterhin funktionieren müssen.

3.2. Sichere Datenübertragung mit VPN

Die im Internet bzw. auch im TCP/IP verwendete Technologie sah ursprünglich keine kommerzielle Nutzung vor. Vom Design her konzentriert sie sich auf Ausfallsicherheit und Betriebssicherheit, aber nicht auf eine vertrauliche Datenübertragung. Zwar war bereits in den Anfängen des Internet eine militärische Nutzung geplant, aber hierfür wurden dann eigene, gesicherte Leitungen eingesetzt. Anfang der Neunziger entdeckten Unternehmen das weltweit nutzbare Internet und begannen zunächst mit dem Anbieten von Treibern sowie öffentlichen Supportforen im Usenet.

Schon bald über wollte man auch Geschäfte über das Internet generieren und auch die relativ günstigen Leitungen für die Kommunikation zwischen einzelnen Standorten und zu Partnern bzw. Kunden nutzen. Das Problem der Datenübertragung im Klartext verhinderte dies zunächst. Heute werden bei solchen Anforderungen sog. Virtual Private Networks (VPNs) genutzt. In früheren Zeiten hatte hier jeder Hersteller seinen eigenen „Standard", so dass VPNs zu Kunden oder Partnern manchmal relativ schwierig aufzubauen waren. Heute bieten alle Hersteller IPSec als Protokollbasis, die auch in den RFCs 4301 ff. standardisiert ist. Zwar ergeben sich hier unterschiedlichste Konfigurationsmöglichkeiten, aber wenn sich die Administratoren entsprechend abstimmen, lassen sich VPNs heute herstellerunabhängig aufbauen und nutzen.

Neben den oben beschriebenen VPNs zwischen festen Systemen (Site-to-Site VPN), besteht immer mehr die Anforderung nach VPNs zwischen mobilen Geräten und dem Unternehmensnetzwerk (Client-to-Site VPN). Auch hier werden heute die geltenden Standards eingehalten, wodurch eine sichere und gut authentifizierte Kommunikation möglich ist. Zusätzlich wird meist gefordert, dass der Client den Sicherheitsanforderungen des Unternehmens entspricht. Hierzu gehört z.B., dass eine Personal Firewall und Schutz gegen Schadcode aktiv und richtig konfiguriert ist sowie gewisse Services laufen müssen, während andere nicht laufen dürfen.

Diese Parameter sollte ein Gateway, über das sich Benutzer vom Internet aus mit internen Systemen verbinden, überprüfen können. Nur dann ist die notwendige Sicherheit auch auf Dauer erreichbar.

3.3. Schutz gegenüber Schadcode

In vielen Fällen ist heute ein guter Schutz gegen Schadcode schon selbstverständlich. Das gilt einerseits für die Clients, andererseits auch für Server. Im Serverbereich ist Virenschutz speziell bei Dateiservern oder Mailservern wichtig. Es kann und soll an dieser Stelle das Thema Schadcode nicht in voller Breite behandelt werden. Den meisten Benutzern und Administratoren ist heute bewusst, dass Schadcode ein Problem darstellen kann, wenn er den PC oder interne Strukturen befällt. Insofern ist auch deutlich, dass die Software laufend auf dem aktuellen Stand gehalten werden muss, weil der Schutz sonst nicht mehr gewährleistet ist.

Speziell in größeren Umgebungen mit vielen Servern und Clients ist ein effektiv arbeitendes, übersichtliches und zentrales Management wichtig. Die Zeiten, in denen ein Administrator von PC zu PC gelaufen ist, um eine Software zu aktualisieren, sind endgültig vorbei. Zentrales Management, gekoppelt mit einer zentralen Überwachung der Software und ihres Status ist heute Stand der Technik.

Die meisten Hersteller von Antivirus-Software bieten bei ihren Unternehmens-Lösungen dieses zentrale Management. Oftmals werden verschiedene Antivirus-Engines eingesetzt. Das hat den Vorteil, dass Daten mehrfach geprüft werden, was die Erkennungsrate der Software erhöht. Die Methodik, mit der Schadcode erkannt wird, ist ebenfalls wichtig. Frühere Lösungen orientieren sich ausschließlich an den Mustern von bekanntem Schadcode. Diese sog. Patterns müssen natürlich ständig aktuell gehalten werden. Diese Methode hat heute einen Nachteil: Es gibt einfach zu viel unterschiedlichen Schadcode, so dass sie langsam und auch mit eventuell einfachen Mitteln auszutricksen ist.

Heutiger Stand der Technik sind heuristische Methoden, die unter anderem auch das Verhalten von Code prüfen. Hierzu gehört ggf. auch, dass interne Software-Routinen bewertet werden. Mit solchen Methoden, kombiniert mit der klassischen Mustererkennung, lässt sich auch moderner Schadcode auf Servern und Clients erkennen. Oftmals ist heute gefordert, dass die Untersuchung der übertragenen Daten direkt am Gateway erfolgt. Dies kann selbstverständlich nur bei der Übertragung im Klartext erfolgreich sein. Verschlüsselte Verbindungen lassen sich prinzipiell nicht ohne weiteres prüfen, wenngleich es mit einem SSL-Proxy zu funktionieren scheint. Tatsache ist aber, dass hier das ursprüngliche, vom Client ausgehende VPN terminiert und ein neues, zweites VPN zum Server aufgebaut wird.

Die Untersuchung der übertragenen Daten an einem Gateway setzt weiterhin voraus, dass die Geschwindigkeit ausreichend hoch ist, so dass die Benutzer nicht ungeduldig werden. Das widerspricht aber eigentlich einer sehr gründlichen Untersuchung. Daher sind einige Hersteller solcher „Streaming" Antivirus-Software dazu übergegangen, die Untersuchung nicht mehr auf alle bekannten Muster zu machen. Das Argument hierbei wäre, dass z.B. Schadcode für Systeme unter Windows NT oder 95 auf heutigen Systemen nicht mehr wirken kann - die Untersuchung bezüglich dieser Muster also überflüssig ist, weil kein interner Benutzer mehr diese veralteten Systeme einsetzt.

Was aber bei realen Produkten fehlt, ist ein Schalter, über den der Umfang der Untersuchungen eingestellt werden kann. Ab und zu ist es heute sogar so, dass Hersteller von Antivirus-Software gar nicht mehr genau definieren, welchen Schadcode sie genau untersuchen lassen, lediglich die sehr hohe Untersuchungsgeschwindigkeit wird hervorgehoben. In einem solchen Fall sollte der Administrator hellhörig werden und beim Hersteller genau nachfragen.

3.4. Schutz vor Spam

Das Thema Spam ist heute oftmals schon in der Tagespresse zu finden, weil es inzwischen ein Problem darstellt. 90% aller E-Mails, wenn nicht sogar mehr, sind als unerwünschte Werbung zu bezeichnen, also Spam. Ähnlich wie bei Werbebriefen per Post gilt eine E-Mail als zugestellt, wenn sie von dem Ziel-Mailserver entgegengenommen worden ist. Sollte später erkannt werden, dass es sich um Werbung handelt, könnte ein Administrator auf die Idee kommen, diese Mail zu löschen. Vergleichbar ist dies wiederum mit dem persönlichen Briefkasten, den der Hausmeister nach Werbung durchsucht und diese dann gleich in den Papiercontainer entsorgt. Das ist zwar nett gemeint, kollidiert aber mit dem Briefgeheimnis. Ähnlich verhält es sich bei E-Mail. Auch hier ist das nachträgliche Löschen rechtlich bedenklich. Daher muss die Bewertung, ob es sich um Spam handelt, gleich am ersten Mailserver erfolgen.

Dieser kann die Entgegennahme verweigern, wodurch auch der Absender die Information bekommt, dass die Mail nicht zugestellt werden konnte. Diese Methode ist rechtlich zwar einwandfrei, aber nicht immer durchführbar. Daher wird E-Mail, die als Spam erkannt ist, häufig nur als solche gekennzeichnet, dem Benutzer aber zugestellt. Dieser kann diese E-Mails dann in einem eigenen Ordner sammeln, bewerten und löschen. Auch wenn weiterhin Arbeit für den Benutzer entsteht und damit auch Kosten für den Arbeitgeber, bleibt zumindest sein normaler Eingangsordner von der meisten Werbung verschont.

Wegen der Spam-Problematik nehmen heute gut konfigurierte Mailserver längst nicht mehr jede E-Mail entgegen. Einfache Methoden zur Prüfung, ob eine eingehende E-Mail in Ordnung ist, sind u.a. der Einsatz von Blacklists (und Whitelists) sowie das Verweigern eingehender E-Mail von IP-Adressen, die zu den Einwahlbereichen von Providern gehören. Rechner mit dynamisch zugewiesenen IP-Adressen sind meist einfache Endgeräte bzw. PCs, die normalerweise eine E-Mail nicht direkt verschicken. Es wird aber E-Mail verschickt, wenn das System mit Schadcode infiziert ist. Durch das Verweigern der Annahme solcher Mails ist also ein zusätzlicher Schutz gegen Schadcode vorhanden - der aber die normalen Schutzmechanismen auf keinen Fall ersetzen kann.

Zusätzlicher Schutz gegen Spam lässt sich heute (noch) durch sogenanntes Greylisting erreichen. Hierbei verweigert der Mailserver zunächst die Annahme der E-Mail und fordert den absendenden Server quasi auf, es nochmals zu versuchen. Viele Spammer gönnen aber nur einen Versuch für die Auslieferung der Werbung, insofern wird sie dann nicht zugestellt. Der Einsatz von Blacklists setzt voraus, dass die IP-Adressen der Spam versendenden Mail-Server bekannt sind. Es gibt im Internet solche Listen, die oftmals auch kostenfrei zur Verfügung stehen. Zusätzlich gibt es Listen offener Mail-Relays, die von Spammern genutzt werden können.

Insofern lässt sich die Entgegennahme von E-Mail schon einschränken. Immer weiter verbreitet sich aber die Nutzung von IP-Adressen, die nur genau einmal für den Versand von Spam genutzt werden. Das Problem ist, dass diese Adressen selbstverständlich noch nicht auf einer Blacklist vorhanden sind. Beispiel für solche Server, die Spam versenden, sind Mitglieder von Botnetzen. Speziell das Storm Botnetz ist bekannt dafür, ein erfolgreicher Versender von Spam zu sein. Dabei handelt es sich um „normale" Systeme, die lediglich mit dem Schadcode infiziert sind und die sich zentral steuern lassen.

Druckbare Version