Das Zwischennetz heißt DMZ (Demilitarisierte Zone). In ihm befinden sich Vermittlungsrechner für alle Protokolle/Dienste, die von einem Netz zum anderen funktionieren sollen. Solch einen Vermittlungsrechner nennt man Proxy, da er im Auftrag handelt (wie ein Sektretariat). Proxies arbeiten auf Anwendungsebene, d.h. sie verstehen die über sie laufende Kommunikation.

Eine Sonderstellung nimmt die »grafische Firewall« ein, die die Arbeitsplatzsysteme nur noch zur Bildschirmdarstellung und als Eingabesystem benutzt. Die Anwendungen laufen auf einem zentralen System, auf dem die Schwachstellen von Anwendungssoftware und Konfiguration zentral in Angriff genommen werden können. Dies entspricht dem klassischen IBM-Hostsystem der fünziger Jahre.

Ein Netzscan ist die höfliche und formgerechte Abfrage von ausgewählten Diensten über eine ganze Rechnergruppe. Es ist im praktischen Leben vergleichbar mit der Betrachtung einer Straße auf der Suche nach einem offenen Laden.

Ebenso wie ein Betrachter eines Hauses einen Einbruch planen kann, kann ein Scan einen Angriff vorbereiten. Allerdings ist dieses Indiz praktisch sehr schwach.

Ein etwas tiefer gehender Scan ist der Bannerscan. Dabei wird jeder öffentlich angebotene Dienst kontaktiert und die Server-Software incl. Versionsnummer ermittelt. Auch dies ist legal.

Kein Scan ist notwendigerweise eine Angriffsvorbereitung und schon gar kein Angriff.

Eine Desktop-Firewall kann Dir helfen, mehr über Dein System zu lernen. Sie kann Dir aber nicht ohne weiteres helfen, sicherer zu sein. Besser ist es präventiv aktiv zu werden, wie in "Ich habe offene Ports, wofür sind die?" und "Wie kann ich sehen was auf meinem Interface/Netzwerk passiert?" beschrieben.

Wer glaubt, die unverstandene Sicherheitslösung hätte irgendeinen Effekt, wird unbewußt diesen mit einer gewissen Laxheit kompensieren, weil ihn das System ja schützt.

Wer nicht glaubt, daß das Firewallsystem wirksam sei, muß sich fragen lassen, warum er es dann installiert.

Viele sogenannten Desktop-Firewalls melden jedes ankommende Paket erstmal als Angriff. Das verursacht Panik beim Nutzer und das wohlige Gefühl, sein Geld richtig angelegt zu haben. Außerdem können die Bekannten ja auch nicht ohne diesen perfekten Schutz leben, also sofort anrufen ...

In den meisten Fällen sind die gemeldeten Pakete aber nur die Antworten auf Anfragen, die man selbst generiert hat, bspw. als man eine Webseite betrachten, seine Post lesen oder einfach nur rumdaddeln wollte.

Bei einer Einwahl mit dynamischer Adressvergabe (wie bei den meisten Providern üblich), ist es wahrscheinlich, daß man nach der Einwahl noch die Pakete von Verbindungen seines Vorgängers bekommt. Das ist nichts schlimmes und schon gar kein Angriff.

Wenn Du einen Trojaner installiert hast, so hast Du das absichtlich getan. Davor konnte Dich die Firewall nicht schützen. Und es ist sowieso zu spät.

Wenn Du keinen Trojaner installiert hast, so wird die Anfrage an diesen Port zurückgewiesen. Die Firewall macht genau das Gleiche. Wo ist da der Nutzen?

Sicher, ein Firewall kann helfen. Auch eine Desktop-Firewall. Vorausgesetzt, sie ist richtig durchdacht und gewartet. Allerdings bleibt die Frage offen, warum Du nicht einfach die Fehler behebst. Schließlich werden die Patches i.d.R. mit der Ankündigung veröffentlicht.

Andererseits: Warum kaufst Du bekanntermaßen defekte Technik? Wenn Du diesen Fehler erst nach dem Kauf bemerkst, hast Du rechtlich die Möglichkeit, auf Wandlung oder Geldrückzahlung zu bestehen. Fehler zu machen ist nicht schlimm, sie nicht einzusehen, dagegen unverzeihlich.

Wenn irgendetwas nicht funktioniert, lerne, was diese Software wirklich braucht und warum. Dann schalte es bei Bedarf frei.

Nochmals: Schalte nichts frei, von dessen sachlicher Notwendigkeit Du nicht von Grund auf überzeugt bist.

• Anleitung der "Firewall"-Software
• Tanenbaum, Andrew S.: Computer Networks
• Comer, Douglas / Droms, Ralph: Computer Networks and Intranets
• Comer, Douglas: Internetworking with TCP/IP
• Stevens, Richard W.: TCP/IP Illustrated
• Cheswick, William R. / Bellovin, Steven M.: Firewalls and Internet Security
• Chapman, Brent D. / Zwicky, Elizabeth D.: Building Internet Firewalls
• comp.security.firewalls FAQ: http://www.interhack.net/pubs/fwfaq/
• http://www.rfc-editor.org/
• http://www.w3.org/Security/Faq/
• http://www.bsi.bund.de/gshb/
• http://www.sicherheit-im-internet.de/
• http://www.cert.org/tech_tips/
• http://www.home.pages.at/heaven/sec.htm
• http://www.cert.dfn.de/
• http://www.uni-siegen.de/security/
• http://www.microsoft.com/security/default.asp
• http://www.koehntopp.de/kris/artikel/websec/
• http://www.koehntopp.de/kris/artikel/unix_security/
• http://www.stokely.com/unix.sysadm.resources/security.html
• http://nic.com/~dave/SecurityAdminGuide/
• http://www.securityportal.com/
• http://www.securityfocus.com/
• http://www.psionic.com/papers/attacks/
• http://sites.inka.de/lina/freefire-l/

Empfehlenswerte Lernreihenfolge: Grundlagen IP, ICMP, UDP und TCP. Danach die Protokolle der Reihe nach durch. Beginnen mit DNS über UDP (alle Richtungen) und dann telnet. Als nächstes POP3. Danach SMTP und HTTP. Nach FTP kann man sich mit SSH und HTTPS befassen. Zum Einstieg ist http://www.netzmafia.de/skripten/netze/netz8.html und folgende Kapitel gut geeignet.

Einige einleitende Bemerkungen und Beispiele findet man auch beim BSI: http://www.bsi.bund.de/literat/doc/sinetdoc/sinetstd.htm.

1. Wurde mein System in irgendeiner Weise kompromittiert?

   Nein

   weiter bei 2

   Ja

   Gerät vom Netz trennen und Kompromitierung festellen, dokumentieren, archivieren und beseitigen und weiter bei 2

2. Ist mir ein Schaden entstanden?

   Nein

   weiter bei 3

   Ja

   Feststellung des Schadens und weiter bei 3

3. Kann dieser "Angriff" in Zukunft verhindert werden?

   Nein

   Evaluation der Alternativen, Alternativen umsetzen

   Ja

   Massnahme(n) durchführen

4. Ist der Aufwand gerechtfertigt eine Anzeige zu erstatten?

   Nein

   Zurücklehnen

   Ja

   Anzeige erstatten, den richtigen ISP benachrichtigen.

Alternativ kannst Du auch mit telnet whois.thur.de 43 Deine Anfrage stellen. Einfach im Telnet lostippen.

Natürlich ist niemand verpflichtet, sich an diese Liste zu halten. Wenn also ein Trojaner einen Server installieren will, so wird er sinnvollerweise bekannte Ports benutzen. So ist er von den bekannten Diensten erstmal ununterscheidbar. Die sogenannten Trojanerports stammen aus den letzten Jahren. Sie liegen meist über 1024 und sind somit ohne besondere Berechtigungen auf einem Unix zu eröffnen. Alle Internetanwendungen tun dies, um zu kommunizieren. Die meisten sogenannten Trojaner sind keine Trojaner sondern normale Fernwartungsserver, die eben nicht zugewiesene Ports benutzen. Ein allgemeines Lauschen an einem bestimmten Port - also Serverdienste -sind selten, bspw. FTP, Napster, Gnutella, ICQ, ... benutzen diese Technik mit zufällig gewählten Ports.

Welche Programm momentan auf welchen Ports lauschen kann man mit lsof -i, welche Kommunikationsstränge gerade aktiv sind mit netstat -tu und welche Server gerade aktiv sind mit netstat -lp herausbekommen. Unter Windows kann auch TDIMon helfen: http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml.

Obwohl man eigentlich einen zweiten Rechner braucht, um ein möglicherweise befallenes System zu kontrollieren, ist es zu Lernzwecken schon sinnvoll mal den Normalbetrieb zu untersuchen. Unter den Unix-Derivaten gibt es tcpdump mit dem man Netzwerkverkehr beobachten kann. Für die Windows-Derivate findest Du Informationen unter: http://netgroup-serv.polito.it/winpcap/. Ein brauchbaren Einblick in die Netzgeschehnisse liefert Ethereal.

Für eine längerfristige Überwachung des Netzverkehrs ist Snort http://www.snort.org/ einen Blick wert.

Als DENY bezeichnet man das kommentarlose Wegwerfen der Verbindungsanfrage. Damit läuft der Anfragende in einen Timeout.

Admins, die sich über Script Kiddies ärgern, glauben oft, diese durch DENY aufhalten zu können. Dies ist jedoch falsch. Es ist problemlos möglich, viele tausend Scans gleichzeitig zu starten und so auf alle Timeout gleichzeitig zu warten. Ein Scanner wird so nicht gebremst. Andererseits bremst man mit DENY alle legitimen Nutzer und Server massiv aus. Das betrifft insbesondere die ident Anfragen.

Ident dient dazu, dem Admin eines ordentlich gepflegten Systems eine Hilfestellung bei der Identifizierung seiner, sich daneben benehmenden Nutzer zu geben. DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen Servern nicht mehr aufgezeichnet werden. Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst, nimm DENY.

Sieh das Ganze doch so, wie in einer offenen Beziehung:
Es ist besser seinem Partner direkt zu sagen, daß man über ein bestimmtes Thema nicht sprechen möchte (REJECT): Der Partner weiß sofort, was Sache ist und und kann dann ohne Zeitverzögerung seine Entscheidung darüber treffen, ob er die Beziehung fortsetzen möchte oder nicht.

Geht man auf ein Thema allerdings gar nicht ein (DENY) und stellt die Ohren auf Durchzug, kostet das a) einem selber Zeit dem Geschwafel des Partners zuzuhören und b) dem Partner ebenfalls Zeit; er möchte nämlich ein für ihn wichtiges Thema/Problem loswerden, und hätte das dann ja wohl besser woanders getan.

Ein anderes Beispiel aus dem Leben:
Du gehst durch die Einkaufstraße deiner Stadt, und irgendein "Penner" quatscht dich an, und will 'nen Euro. Hier könnte man sagen "Ach ne, habe selbst kein Geld" (REJECT) oder einfach die fortgesetzte Bettelei ertragen.

Es bleiben so nur die Möglichkeiten des LART gegenüber dem Anwender, oder die Einrichtung von Weißlisten, d.h. es dürfen nur als gutartig im Sinne der Policy bekannte Gegenstellen erreicht werden. Von einem Internet-Zugang kann jetzt natürlich keine Rede mehr sein.

Man muß sich darüber klar sein, daß es unmöglich ist soziale Probleme technisch zu erschlagen, egal wieviel Geld man auf das Problem wirft.

Proto  Local Address           Foreign Address         State      
tcp    217.17.192.37:1213      217.17.192.67:119       ESTABLISHED 
tcp    0.0.0.0:1213            0.0.0.0:*               LISTEN

Damit der FTP-Server weiß, wohin er eine Datenverbindung aufbauen soll, wird ein PORT-Kommando zum Server geschickt. Diese enthält die IP und Port-Adresse des Nutzersystems. Das Gefährungspotential hier ist offensichtlich. Eine Firewall muß dieses aktive FTP analysieren, das PORT Kommando bei Bedarf im Transport umschreiben und die eigenen Filterreglen dynamisch anpassen.

Deswegen sollte man grundsätzlich versuchen, nur passives FTP zu benutzen.

• IETF
  • RSVP (Ressourcenverwaltung für QoS)
  • SIP (Verbindungsaufbau)
  • SAP (Verbindungsankündigungen - für öffentliche Verbindungen)
  • SDP (Verbindungsbeschreibungen - für öffentliche Verbindungen)
  • MGCP (Endgeräteverwaltung, Nachfolger von SGCP)
  • "skinny" station protocol (proprietäre Form von MGCP)
  • RTP (Sprach/Bild-Datenstrom)
  • RTCP (End-2-End Steuerungkanal für RTP)
  • Codecs werden von ITU-T übernommen
• ITU-T (H.323 Protokollfamilie):
  • H.235 (Steuerungskanal u.a. für Sicherheit und Abrechnung)
  • H.225 (Verbindungsaufbau der Signalisierung)
    • H.225.0 (Signalisierung nach Q.931)
    • RAS (Rufnummern-, Bandbreitenverwaltung)
    • RTP Initialisierung
  • H.245 (Verbindungsaufbau des Sprach/Bild-Datenstrom, Codec-Abgleich)
  • H.450 (Zusatzdienste wie Halten, Weiterleiten, Verbinden, Konferenz)
  • T.120 (Sonstiger Datenverkehrs)
  • RTP (Sprach/Bild-Datenstrom)
  • RTCP (End-2-End Steuerungkanal für RTP)
  • Codecs: G.711(a/ulaw), G.729(a)(b), G.723.x, ... (audio), H.26x (video)

Bei besonders obskuren Problemen kann man auch in der Newsgruppe de.comp.security.firewall fragen. Hierbei ist zu beachten, daß man eine möglichst detailierte Protokollbeschreibung mitliefert (Verweise auf irgendwelche Unterlagen per URL), das Problem (insbesondere den zu konfigurierenden Paketfilter) exakt schildert und erkennen läßt, welche Schritte zur Problemlösung bereits ergriffen wurden. Auch aktuelle Workarounds sind aufzählenswert.

Es ist sehr nützlich, darzulegen, warum dieser Dienst benutzt werden soll und in welchem Umfang die Nutzung durch die Policy gedeckt wird. Ohne diese Angabe ist der Ratschlag, den Paketfilter komplett zu entfernen, angemessen.

Für einige Systeme gibt es Webseiten, die das Problem einkreisen:

• http://www.kimmeringer.de/kaune/w2k/
• http://www.kimmeringer.de/kaune/xp/
• http://cert.uni-stuttgart.de/
• http://www.cert.org/tech_tips/ CERT Hinweise zu verschiedenen Themen
• http://nsa1.www.conxion.com/ Hinweise für Cisco und Win2000
• http://www.linuxsecurity.com/docs/ Linux Security Documentation
• http://usmcug.usm.maine.edu/papers/linux_security_guide.html Linux Security Guide
• http://www.linuxdoc.org/ Linux Documentation Project
• http://www.freebsd.org/security/ FreeBSD Security Information
• http://www.sabernet.net/papers/True64, HP-UX, Solaris, Windows NT 4
• http://www.microsoft.com/security/ Microsoft Security
• http://www.sans.org/newlook/publications/ntstep.htm NT Security Step by Step
• http://www.microsoft.com/technet/itsolutions/security/prodtech/prodtech.asp Microsoft TechNet Security by Products

Mit der Zeit sind dann die schon länger mitdiskutierenden Fachleute genervt, insbesondere wenn deutlich wird, daß ein Frager zu wenig eigene Anstrengungen unternimmt, um die von ihm gewünschte Information zu recherchieren. Dies führt gelegentlich bei den Experten bzw. Expertinnen zu einer sarkastisch wirkenden Schreibweise.

Vom Fragenden ganz unbeabsichtigt liest sich der Beitrag eines Anfängers aus der Sicht einer Fachperson leider nicht selten so: "Mein Haus steht an einer öffentlichen Straße. Ich möchte nicht, daß man das Haus von dort aus sehen kann. Ich habe gehört, daß man mit Hilfe von Taschenlampen auch bei ausgeschalter Sonne, Mond und Beleuchtung mein Haus sehen kann. Wie kann ich mich nun schützen?"

Die Antwort, die Du hören willst lautet: "Es gibt da extrem coole Folien mit dem Aufdruck 'Das ist kein Haus.', die man in die Fenster kleben kann. Kostenlos und besonders bunt sind die von Zonealarm."

Diese FAQ soll dazu beitragen, dass derartige offenkundig unerfüllbare Wünsche seltener oder am besten gar nicht an die Gruppe herangetragen werden. Sie soll zum Nachdenken anregen.

Merke: Bei ICMP ist keine Antwort gleichbedeutend mit "ich bin hier". Weil wenn Du nicht da wärst, würde jemand anderes sagen "Der ist nicht da". Nämlich der nächste Router. (Der steht bei Deinem Provider und Du hättest kein Internet.)

Anderseits sind Softwarefirewalls dank des höheren Marktdrucks aktueller und haben mehr Features. (Verkaufte Hardware bindet Kunden längerfirstig.) Der Nachteil besteht in einer höheren Fehlerquote in der größeren Codebasis.

Schließlich gibt es noch Hardwarefirewalls ohne Software. Diese nutzen physikalische Effekte aus. Bspw. genügen zwei Zentimeter Luft, um einen PC vor Netzangriffen zu schützen.

Für mobile Nutzer wird oft IKE mit shared key Authentifizierung benutzt. Welche Parameter sind sonst noch eingestellt? DES/3DES, SHA1/MD5, DH-Group1/2? Wird beidesmal das gleiche shared Secret verwendet (evtl. Gruppenpasswort genannt) oder geht's über Zertifikate? Werden die IKE-IDs auf Namen oder Addressen aufgebaut? Evtl. muß man als Peer-Addresse (wenn die dynamisch ist) 0.0.0.0 oder besser eine Netzmaske angeben.

Kannst Du den IKE-Managementtunnel aufgebaut sehen? Debugausgaben? Wenn der steht, hast Du fast gewonnen.

Um jetzt einen Client konfigurieren zu können werden (noch nicht genormte) Protokolle wie Uauth (Wer ist der Anfragende?) und Mode-Config (Welche IP, DNS, WinS, ... bekommt er?) ausgeführt. Scheitert es daran? Wenn ja, bleibt Dir kaum etwas anderes als über den IPSec Tunnel PPP zu legen. Willst Du dann auch noch Broadcasts übertragen (Windows :-/), dann legst Du über diesen PPP Tunnel auch noch L2TP. Und dann gehst Du kotzen.

Hat auch Mode-Config geklappt, brauchst Du die IPSec Tunnel. Dort werden zuerst mal IDs ausgetauscht, die den interessanten Traffic definieren. Das muß passen! Und dann natürlich die Algorithmen für jeden Tunnel. Ist es Transport oder Tunnel-Mode? Nur bei Tunnel-Mode kannst Du ganze Netze erreichen! Wird ein Authentication Header eingefügt, darf der Paketheader unterwegs nicht angefaßt werden! Minimal solltest Du mit ESP und einem einfachen Chipher anfangen. AH solltest Du meiden, das bekommst Du stabiler mit ESP und einer HMAC hin.

NAT ist praktisch immer sehr schädlich für IPSec, da kann schon IKE auf die Nase fallen. weil der Absendeport nicht stimmt.

Der Begriff Sicherheit bezieht sich auf ein bestimmtes Szenario und ist dort binär: Entweder ein System ist gegenüber genau diesem Szenario sicher oder eben nicht.

Trotzdem hört man immer wieder davon, etwas "sicherer" zu machen. Dies bezieht sich auf die Gesamtmenge aller denkbaren Szenarien und versucht den Prozentsatz der Szenarien zu ermittlen, in denen das System sicher ist. Da aber ein unsicheres Szenario genügt, um ein System zu kompromittieren, ist diese Denkweise höchst gefährlich. Es gibt überabzählbar unendlich viele Szenarien, man kann sich aber nur gegen konkrete Szenarien schützen. Das Maß der so entstehenden Gesamtsicherheit ist aber nicht zwangsweise Null, da man sich gegen Sicherheitsklassen schützen kann (Pufferüberläufe, Rechner wegtragen, Stromausfall bis zu einer Stunde).

Erstes Fazit: Man braucht eine Liste von Szenarien, in denen man Sicherheit erreichen will. => Ein Konzept.

Was ist aber nun sicher? Es gibt viele Antworten, meine ist: "Sicher ist ein System genau dann, wenn die Kosten des Angriffs den erzielbaren Nutzen niemals unterschreiten." Diese Definition gestattet es, die Sicherheit von Systemen zu ermitteln, da man theoretische Untergrenzen des Aufwandes ermitteln kann und somit weiß, wieviel Wert man einem solchen System anvertrauen kann. Z.B. ist der Wert einer Pressemitteilung auf die Zeit vor deren Veröffentlichung begrenzt. Ein Schutz, der mit einem Aufwand von einer Mio EUR nicht unter einem Monat zu brechen ist, reicht also, um wöchentliche Meldungen zu schützen, aus denen man weniger Nutzen ziehen kann.

Andere Definitionen befassen sich mit der Wahrscheinlichkeit möglicher Schäden und setzen das in Verhältnis zum getriebenen Aufwand. Dies ist besonders in der Versicherungsbranche üblich und eine rein betriebswirtschaftliche Kalkulation über die Menge aller möglichen Szenarien. Es ist keine Aussage zur Sicherheit in einem Szenario, sondern Eine zur Gesamtsicherheit. Viele Industrieversicherer bieten eine von den Schutzvorkehrungen abhängige Prämie. Dies ist einer der besten Tests für eine Firewall.

Wenn man ein IP Paket auf die Reise schickt, dann kann es passieren, daß unterwegs die Leitungs-MTU kleiner wird und das Paket nicht mehr durchpaßt. Normalerweise zerlegt der Router, dem das passiert, das IP Paket in Fragmente und schickt die durch. Einfach, trival, funktioniert.

Manchmal will man das nicht, so daß man ein "Don't Fragment" Bit im IP Header setzen kann, wenn das Paket nicht zerlegt werden darf. In dem Fall schickt der Router, dem das trotzdem passiert, ein ICMP 'Destination unreachable: Fragmentation needed, but DF set.' an den Absender zurück. Der weiß nun, daß es nicht geklappt hat.

Nun hat jemand sich vor einigen Jahren gedacht, daß es prima wäre, den Routern die Arbeit zu erleichtert. Er hat nun alle Pakete mit gesetztem DF Bit gesendet. Kam von einem Router eine ICMP Fehlermeldung zurück, dann hat er die in der Fehlermeldung mit angegebene maximale Größe der Strecke genommen und nur für diese Verbindung kleinere Pakete gesendet. Das Ganze nennt man PMTUD.

Darüberhinaus gibt es Buffergrenzen, die ein IP-Stack vorhält, wenn er TCP-Segmente verarbeitet. Um der Gegenseite mitzuteilen, welche maximalen Segmentgrößen er verträgt, setzt er beim Verbinungsaufbau (SYNC) die Option TCPMSS (TCP Maximum Segment Size).

Irgendwann beobachtete jemand anderes, daß die "dünneren" Leitungen, die also kleinere MTUs haben, meist beim Endpunkt einer Verbindung stehen und dachte sich, man könne die Buffergrenzen des TCP Stacks ebenfalls als Obergrenze der MTU interpretieren. Der Gedanke allein ist derartig schwachsinnig, daß es schmerzt: Hier wurde Kausalität und Korrelation verwechselt. Man setzt nämlich die Puffergrenzen so, daß sie in der lokalen Umgebung sinnvoll sind, und das ist zufällig die LeitungsMTU am nächsten Interface, weil ja einkommende Pakete eh' nicht größer sein können. Das sagt natürlich gar nichts über die MTU der Leitungen zwischen den Endgeräten aus, besonders, da die allerletzte Strecke meist ein "dickes" Ethernetinterface ist.

Kurz gesagt hat sich der Letztgenannte also eine Modifikation des TCP/IP Stacks dahingehend einfallen lassen, daß der den TCPMSS Parameter als Startwert für PMTUD nimmt.

Neu in dem Szenario sind jetzt die strunzdämlichen Paketfilter-Admins, die ICMP als Angriff werten und abschalten. Danach geht nichts mehr, wenn einer von beiden PMTUD probiert. Die Pakete können grundsätzlich nicht durchkommen, weil die Fehlermeldungen weggeworfen werden. Und anstatt nun einfach PMTUD abzuschalten, so daß es gar keine Fehlermeldungen mehr gibt, setzt man die MTU auf dem Interface so geschickt niedrig, daß die ausgehenden Pakete grundsätzlich klein genug sind, um überall durchzukommen. Außerdem signalisiert man mit TCPMSS der Gegenstelle, doch bitte kleine Pakete zu senden. Das ist zwar ineffizient, aber es gibt keine Fehlermeldungen mehr, die von dem strunzdämlichen Paketfilter-Admins des Serverproviders weggeworfen werden könnten.

Anstatt den Wunsch der betreffenden Firma zu respektieren und die Webseiten links liegen zu lassen, setzen die Leute ihre MTU auf den Interfaces herab und produzieren so kleinere Buffer im TCP-Stack, der von anderen Systemen bequem überschrieben werden kann, so daß man sich selbst eine Sicherheitslücke baut und von der Kommunikation mit anderen Systemen ausschließt. Es sei denn, man sagt die kleinere MTU /allen/ Geräten im lokalen Netz, auch dem Server. Oder man sagt seinem Außenrouter, er möge doch bitte die TCPMSS Optionen, so sie mal gesetzt sind, an die MTU der Außenleitung anpassen. Das nennt man MSS-Clamping. Es funktioniert dann aber nur für TCP Verbindungen, die man selbst mit TCPMSS Optionen begann. UDP und andere Protokolle sind davon unberührt.

• http://webscan.security-check.ch/ scant den Anfragenden, ist leicht verständlich und durchaus gehoben.
• http://check.lfd.niedersachsen.de/start.php
• http://www.linux-sec.net/Audit/nmap.test.gwif.html basiert auf nmap und man kann in Grenzen eigene Optionen angeben.
• http://mirror.ping.de:8888/#portscan bietet nmaps TCP-, SYN- und NULL-Scan.
• http://www.securityspace.com/sspace/index.html Unter "Free Trial Audit" gibts einen sehr umfangreichen Scan gegen E-Mail-Adresse einmal gratis.
• https://freescan.qualys.com/ scant beliebige IP-Adressen gegen E-Mail-Adresse, verschweigt in der kostenlosen Version allerdings Details über gefundene schwere Sicherheitslücken.

Die meisten Anwendungen verwenden nicht allein eine Verbindung, die von dem Surfersystem zum jeweiligen Server aufgebaut wird, sondern eine Vielzahl von unterstützenden Diensten und damit auch unterschiedlichen Protokollen. Die Richtung dieser unterstützenden Verbindungen ist dabei oft auch vom Server zum Client(Surfer).

Erreicht einen NAT-Router ein Paket für eine umgesetze Adresse, so wird er versuchen, irgendwie den eigentlichen Empfänger zu erraten und das Paket zuzustellen. Das gilt insbesondere dann, wenn der NAT-Router keine intime Protokollkenntnis der Anwendung hat. Oft besteht keine Chance für den NAT-Router, selbst bei Kenntnis des Protokolls, den Empfänger sicher zu ermitteln. Dann wird mittels einer Heuristik der Empfänger erraten. Dies gilt insbesondere bei verschlüsselten Verbindungen und verbindungslosen Protokollen.

Ein NAT-Router ist deswegen keine Sicherheitskomponente.