Das E-Mail Spam ein Problem ist, muss ich kaum erzählen. Grundproblem sind die tiefen Kosten für den Versand, vor allem aber die “Offenheit” von SMTP. Es ist sehr einfach eine beliebige Absenderadresse zu fälschen.

So gibt es viele Vorschläge, wie sich Absender authentifizieren müssten mit dem Ziel Spam zu verhindern. Bei allen Vorschlägen handelt es sich im Kern um DNS-Erweiterungen, die nun in der IETF-Arbeitsgruppe MARID diskutiert werden:

- Reverse MX (RMX)

- Microsoft Sender ID

- Client SMTP Validation (CSV)

- Designated Mailers Protocol (DMP)

- Designated Relays Inquiry Protocol (DRIP)

- Flexible Sender Validation (FSV)

- Sender Policy Framework (SPF)

Interessante Fragen sind beispielsweise wie E-Mail-Forwards behandelt werden sollen und ob es für Spammer nicht (zu) einfach ist, gültige Adressen zu beschaffen. Im Grundsatz sind sich die Gruppen auch nicht einig ob es genügt die Header-Daten zu prüfen, oder ob das Mail Envelope geprüft werden muss und zu welchem Zeitpunkt die Prüfung zu erfolgen hat.

Interessiert? Die Links sind oben…

Bereits das Vorhandensein eines offenen Netzwerkports (z.B. für ftp) lädt zum Ausprobieren und Lauschen ein und ist damit ein potentielles Sicherheitsproblem. Nehmen wir an, wir wollen einen Port für SSH, den wir für Fernwartung benötigen, schützen.

Zuerst schützen wir alle Ports mit einer SW-Firewall (resp. lassen diese zu). Nehmen wir eine LINUX-Kiste an, so schützen wir mit iptables. Somit ist der Rechner von aussen bspw. bei einem Port-Scan “dicht” und zwar auf allen Ports.

Nun wählen wir eine beliebige Port-Range und lassen einen Port Knock-Server daran lauschen oder genauer gesagt an der Log-Datei der Firewall.

Verbindet nun ein Client zu einer vordefinierte Reihenfolge von Ports, so ist das erfolglos und die Firewall schreibt die Versuche in ihre Logdatei. Diese wiederum wird vom Port Knock-Server mitgelesen. Erkennt der Server ein vordefiniertes “Klopfzeichen”, so öffnet er in unserem Falll den SSH-Port und die “Türe” für die Fernwartung ist nun offen (und wird nach Gebrauch wieder geschlossen).

Selbstverständlich sollten das Klopzeichen wegen einer Replay-Attacke nicht immer identisch sein. Dagegen tut es bereits ein einfacher Timestamp, doch sind kompliziertere Versionen mit kryptographischen sicheren Sessions-Key beliebig möglich.

Ich finde das genial: www.portknocking.org und ein Artikel im Linux Journal.