Application-Server Sicherheitsmechanismen

[RuX]

(Gleicher Thread wie >http://www.delphipraxis.net/internal_redirect.php?t=62942< da ich den alten aus Versehen im Falschen Forum erstellt habe, und die Admins wohl mein "bitte verschieben" nicht mitgekriegt haben Insofern kann man den alten bitte löschen!)

:
Ich programmier aktuell an einem Server der später wohl zu intensiveren Einsatz kommen könnte, d. H. schon mehrere hundert bis tausend Anfragen in der Stunde wenns gut läuft. Jetzt wollt ich mich mal erkundigen was man in Sachen Sicherheit für Mechanismen empfehlenswert sind. Vor allem: welche Risiken / Angriffe gibt es alles (ich denk da jetzt z. B. an DoS) und wie kann man sich dagegen am besten sichern (Programmiertechnisch, bezogen auf die Server-Applikation)? Gibs hierfür irgendwelche Best-Practices, oder evtl. Artikel die empfehlenswert sind? Braucht man sowas überhaupt im Server integriert, oder reicht eine gut konfigurierte Firewall? Dachte mir vielleicht hat hier schon jemand Erfahrungen? Fragen über Fragen

Danke schonmal für eure Mithilfe!

[Phistev]

Ersteinmal sollte die Kommunikation einen Header mit Signatur (Zeichenkette, an der man erkennt, obs dein Programm ist, wie 'MZ' bei der Exe) und Hash beinhalten. Damit kann man (einfache) DoS-Angriffe abwehren. Zweitens: Wenn dein Server auf einem eigenen Computer läuft, sollten SYN/ACK-Pakete (TCP/IP) abgefangen und sofort vernichtet werden (ganz fieser DDoS-Angriff, kann evtl. eine Firewall machen). Ansonsten das Übliche wie IP-Tabelle (höchstens x Verbindungen von einer IP, evtl. durch Firewall), kein unsicherer Code (Move, Pointer / Buffer overrun), bei Format (printf unter C) aufpassen. Seriöse Bücher zum Thema "Wie werde ich Hacker?" könnten weitere Informationen geben.

[RuX]

Ahja danke, sind schonmal n paar gute Tipps dabei!
In Sachen Header: Ich kann natürlich bei der Kommunikation ein Header mitschicken. Jetzt ist die Frage: was für einen? Einfach statisch einen immer gleichen Schlüssel als identifikation meines Programms? Ok dadurch würde dann Pakete die an meinem Port ankommen und den falschen Schlüssel haben aussortiert. Allerdings is so eine statische Bezeichung sehr einfach zu fälschen, man muss ja nur 1x mitsniffen und weiß was man senden muss. Dynamisch wäre das ganze doch angebrachter. Erster Gedanke: Asymetrischen schlüssel? Is die Frage, was ist noch hier noch angebracht was total over-designed
Das mit dem max x Verbindungen pro IP is auch ne gute Sache, hilft wohl allerdings bei DDoS Attacken nicht viel. Da müsst ich mal schaun ob das per ipchains konfigurierbar ist (wird einn Linux Server).
Kann man sonst überhaupt irgendwas gegen DDoS Angriffe machen? Auch wenn ich ungültige Anfragen aussortier, so hab ich ja immernoch den aussortier Aufwand, was ja evtl. bereits reichen könnte bei einer gewissen Anzahl von Anfragen, oder?

[Phistev]

Gegen das Mitsniffen (und Fehler) hilft ein Hash (evtl. 2-3 kombinieren). Verschlüsselung wäre hier overkill. Gegen DDoS-Angriffe ist man ab einer bestimmten Größe machtlos. Welche Größe das ist, hängt von der Leistung des Computers und der Effizienz der Aussortierroutine ab. (Hier schreibt ein Webseiten-Besitzer über solche Angriffe)

[RuX]

Wie kann ein Hash gegen mitsniffen helfen? Das is doch grob nur eine Überprüfug auf unveränderte Daten ála CRC?
Intressanter Link.

e: Ich denk mal ich wer trotzdem asymetrisch verschlüsseln, mindestens den Authentifizierungsvorgang, der ist ja nicht groß/lang. Die restlichen Daten sind sowieso recht unsensibel.

e2: SEHR intressanter Link. Toller Text, gut geschrieben. Hilft mir persönlich zwar nicht, aber is schon spannend was bei denen so abgeht

[Phistev]

Wenn man den Hash nochmal hasht (MD5 - SHA1 o. ä.) oder die Strings aneinander hängt, sollte es ausreichend schwer werden, vom Hash-Wert auf das Verfahren zu schließen

[RuX]

du meinst jetzt die kommunikation verschlüsseln mithilfe von hash-verfahren denk ich mal?
<klugscheiß>normalerweise ist ja ein hash nur eine quersumme der daten, die nochmal an die daten angehängt wird, um nach der übertragung zu ermitteln, ob die daten manipuliert oder durch technische gründe verändert wurden, indem man aus den empfangenen daten (exklusive empfangenger hash natürlich) nochmal den hash bildet und mit dem empfangenen hash vergleicht (!?)</klugscheiß>

[Phistev]

Ja, der Trick basiert darauf, dass der Andere nicht weiß, WIE der Hash berechnet wurde. Wenn man das mit einer fortlaufenden Nummer kombiniert, sollte es nur schwer möglich sein, ein abgefangenes Paket noch einmal zu senden oder herauszukriegen, wie das Paket aufgebaut ist.

[RuX]

ok gut, hab jedenfalls n paar anregungen bekommen, danke. ich werd schaun das ich das meiste in die firewall mit reinkrieg, aber bin mir nicht sicher in wie weit man das mit ipchains konfigurieren kann.