Ich versuche mal das der Reihenfolge abzuarbeiten:
Das heißt ich benötige die Remote Ports 80, 53UDP, 25, 443 eingehend u. bei 110 ausgehend, oder?
Das hast Du jetzt leider etwas mißverständlich formuliert. Die von Dir genannten Ports sind aber alles Serverports, d.h. Du mußt auf deinem Rechner eine Regel erstellen, so daß dein Rechner entfernte Rechner an deren entsprechendem Port kontaktieren dürfen (das gilt für alle Serverports). En Webserver lauscht auf 80 u. 443, ein Popserver lauscht auf 110, ein SMTP-Server auf 25, ein FTP-Server auf 20/21 (je nach aktiv/passiv), ein DNS-Server lauscht auf 53 (TCP und UDP). Eventuell schmeißt Du lokal freigeben mit lokalem Port noch etwas durcheinander, dazu am Ende noch mehr.
Wenn du sagst, das es nach Reihenfolge geht, heißt das, je höher...
Inwiefern die Reihenfolge wirksam ist, hängt etwas von der Software ab, in der Regel werden Filterregeln aber eine nach der anderen abgearbeitet. Mal ein konkretes Beispiel, wie Du es ja schon genannt hast:
1. Regel: Erlaube Anwendung XY die Verbindung an einen entfernten Rechner auf Port 80
2. Regel: Verbiete alle ausgehenden Verbindungen.
Der Reihenfolge nach würde zwar Anwendung XY zuerst die Kommunikation nach außen erlaubt, wird die nächste Regel erreicht, so wird allerdings allen Anwendungen die Kommunikation nach außen erlaubt. Ergebnis wäre: keine Verbindung (es mag Filter geben, die das anders handhaben).
In Kerio (manual leider in englisch und nicht konkret genug) habe ich jetzt für die Regeln die Möglichkeit mehere Unterordner zu gestalten. Wonach richtet sich dann die Reihenfolge.
Kerio (welche ich recht brauchbar finde) arbeitet Regeln streng hierarchisch ab. Eine nachfolgende Regel kann also eine vorherige aufheben.
Also eingehend werden von den genannten Remote Ports die lokalen Ports oberhalb 1024 verwendet.... bis zu welchem Port denn.
Nicht nur eingehend, auch ausgehend. Dein Rechner startet die Kommunikation von sich aus schon von einem Port jenseits der 1024, da die Ports unterhalb 1024 für bekannte Protokolle frei gehalten sind. Wenn die Verbindung ausgehandelt und etabliert ist, dann läuft die Kommunikation an beiden Enden über hohe Ports.
Literaturtipps hab ich aus dem Stehgreif leider keine zur Hand, vielleicht solltest Du die Frage nach Literatur noch einmal als getrennten Thread auf dem Netzwerkbrett starten.
Jetzt noch etwas Theorie zu Verbindungen. Eine Verbindung wird durch einen Socket beschrieben. Ein Socket wiederrum ist die Kombination aus IPs und Ports, welche eine Verbindung kennzeichnen und in einem TCP/IP Paket im Header (sozusagen der Anschrift und des Absenders bei Briefen sehr ähnlich mit einigen Zusatzinfos) vermerkt sind.
Ein Socket kann also grob umschrieben so aussehen:
QuellIP: 192.168.1.1 Quellport: 1025 (beliebig) -> ZielIP: 192.168.1.2 Zielport: 80 (zwingend)
Dies wäre eine Verbindung des Rechners mit der IP 192.168.1.1 an einen Webserver mit der IP 192.168.1.2. Um so eine Verbindung zu erlauben mußt Du also den Zielport 80 ausgehend freigeben, da Du den Quellport nicht wissen kannst. Diesen wählt nämlich dein Betriebssystem aufgrund der schon benutzten Ports. Windows z.B. rechnet Ports meist stupide hoch ab 1025. Hättest Du also noch keine offene Verbindung, dann wäre der Quellport 1025. Die nächste Verbindung startet dann von 1026, dann 1027 usw (allerdings keine Regel ohne Ausnahme). Der einzige Fixpunkt um alle HTTP-Verbindungen zuzulassen wäre also Port 80 als Ziel frei zu geben. Du könntest natürlich auch deinem Browser einfach alle Verbindungen erlauben, das wäre aber unsauber und mit der groben Kelle. Du könntest auch gezielt nur den Server mit der IP 192.168.1.2 freigeben, das wäre aber anstrengend, da Du jeden Server freigeben müsstest.
Das Stealthtests unseriös sind wollte ich gar nicht sagen, nur ist "Stealth" eben nichts, was in den RFC (Request for Comment, eine Art lockere Normung) zu finden wäre und ob es einen Mehrgewinn an Sicherheit bringt kann man zu Recht bezweifeln. Es wird zwar immer argumentiert, daß ein Rechner, welcher Stealth wäre im Internet unsichtbar sei, aber er ist dann eben zu unsichtbar. Man könnte es mit einem schwarzen Loch vergleichen, das kann man auch dadurch nachweisen, daß da einfach garnichts rauskommt. Rein technisch müsste nämlich eine Fehlermeldung des letzten Routers vor dem Ziel kommen, wenn wirklich kein Rechner vorhanden ist. Kommt ncihts zurück, dann weiß man, daß der Router das Paket zustellen konnte (ergo ist da etwas), das Ziel sich aber einfach tot stellt. Der saubere Weg (und den den viele Admins propagieren aufgrund der Regelkonformität) wäre, daß das Ziel einfach sagt: Nö, ich nehme von Dir nix an, anstatt einfach gar nichts zu sagen. Rein sicherheitstechnisch ist es nämlich gleich, ob der Rechner einfach die Annahme höflich verweigert, oder schlichtweg stumm bleibt, der Angreifer bekommt so oder so weder eine Verbindung, noch ein Indiz über offene Ports, wenn der Filter einfach höflich verweigert. Ein closed Port ist ein closed Port, der Angreifer kann nciht wissen ob der Port closed ist, weil sich kein Dienst dahinter versteckt, oder weil er blockiert wird. Er hat also nicht mehr Erfahrung über das System gewonnen, als wenn das System stealth wäre.
Wenn man ganz genau argumentiert, dann muß man auch noch sagen, daß dieser Stealthmodus den Traffic erhöht (wenn auch marginal), da das Anfragende System aufgrund der fehlenden Antwort die Anfrage über eine gewisse Zeit mehrfach stellen kann abhängig von den Einstellungen. Bei einem höflichen Annahme verweigert würde es einfach aufhören (so das System sauber programmiert ist).
Langer Rede, schwacher Sinn: Stealth ist nicht unseriös, nur in meinen Augen unsinnig und leider ist es sozusagen ein running Merketinggag und kein Hersteller von Software in diesem Bereich kann es sich dank des sagenumwobenen Stealth-Mode mehr erlauben auf diesen zu verzichten.
xafford
Artie
