Original geschrieben von asg
Da es im weiteren Sinne hier um security geht, habe ich jails erwähnt und wie man einer DoS Attacke mttels Obergrenze der forks beim Apache, etwas herr werden kann.
Jedoch gilt dies natürlich nur für den Port 80/443 bzw. http/https.
Alle anderen Ports die auch offen wären (je nach Konfiguration), müssten mit einer anderen Technik (oder Kombinationen der Techniken) speziell geschützt werden.
Und das steigert natürlich den Arbeitsaufwand.
Auch portsentry wäre in dem verbund noch zu nennen, da scans auf ports dann eben dynamisch geblockt werden.
Portsentry hat leider den gravierenden Nachteil, dass sie erst
nachdem die vermeintliche Attacke passiert ist, die Alarmglocke lauten lässt. Und ein PacketFilter in Verbindung mit einem Fingerprint soll zeitgleich reagieren und die jeweilige Aktion (je nach Verbindungs-/Angriffs-Szenario) starten.
Folgende Aktionen wären denkbar (ich bitte um Erweiterung bzw. Verbesserung):
--------------------------------------------------------------------------
1.) Umleitung auf Honeypots (also nicht-existente Rechner)
2.) Umleitung auf andere Server (wenn also keine Attacke, sondern eine Belastung durch User --> Stichwort: Microsoft-Attacke durch Lovesan ... da hat man alle Euro-IPs umgeleitet)
3.) Umleitung einiger Connections auf einen speziell präparierten Host für die weitere (forensische) Analysen
4.) Direktes Blocken der Malicious-IPs und das am-Leben-Lassen der wohlbekannten IPs, um trotz einer vermeintlichen Attacke die Servicedienste nicht unterbrechen zu müssen (weil man z.B. keine Ausfallserver hat o.ä.)
-----------------------------------------------------------------------------
Es wird beispielsweise eine IPFW Rule hinzugefügt die alle Anfragen von der IP Adresse sofort blockt. Aus Ende.
IPs können sich ändern.
Außerdem können Attacken auch aus dem Inneren des Netzes kommen.
Man sagt ja (es gibt auch Belege dafür), dass ca. 60-70% der Attacken (aller Art) im Innern passieren (also nicht so sehr durch böse Hacker
Diese IP wird dann auch noch in einer DB abgelegt.
Prima, jedoch kann man über 4 Milliardem IPs theoretisch haben.
Und ein wirklich versierter Angreifer wird oft seine wahre IP verschleiern und (was noch schlimmer ist), einen anderen Rechner übernehmen und von dort aus attackieren.
DDoS-Attacken laufen so z.B. ab.
Desweiteren natürlich Programm wie aide oder tripwire nutzen.
Natürlich, denn 95% der Attacken werden ja erst gar nicht erkannt. Leider!
Daher sollte man sich wegen ein paar Filter, IDSe u.ä. nicht in Sicherheit wähnen.
Wobei viele den Fehler machen die erstellte DB auf dem Rechner liegen zu lassen, man sollte dies schon von dem Rechner wegschaffen, hier bietet sich eine Floppy an (ja, die Dinger sind sogar zu gebrauchen).
Oder aber einen Host aufsetzen und mit einem Script per ssh die Daten rüberscheffeln.
So habe ich es mit meinen Firewall-Logdateien gemacht.
Da habe ich eine fette Platte in die Logmaschine eingebaut und per ssh von den Firewalls die Logs geholt, sodass die Firewall nicht einmal die Logs auf ihre Platte zwischenspeichern sollte.
Alles ging direkt vom logischen pflog0-Device (mit 100Mbit per ssh) auf die Logmaschine rüber.
Dies ist natürlich nur eine der viele, guten Möglichkeiten.
Eine Firewall seiner Wahl ist Pflicht, logisch.
So selbstverständlich, wie das Amen in der Kirche.
Oder den secureleve hochsetzen, das keine kernelmodule geladen werden können,... .
OpenBSD zumindest läuft out-of-the-box mit Securelevel 1.
Ich habe auf einer Website einige gute Skripte gefunden, die dann systemwichtige Dateien auf schg setzen und Seclevel 2 einschalten.
Da kann man nix mehr ändern.
Bei interesse, kann ich ja die Webseiten posten (sind aber sehr OpenBSD-zentrisch)
Nicht zuvergessen die Dateien mit schg flag zu versehen....
Yepp!
Und, logs anschauen. Logs anschauen.
Aber bitte auf der Logmaschine
In diesem Verbund mach sich dann natürlich noch der von Dir genannten fingerprint bemerkbar.
Genau das war meine Intention.
Nicht ein Allheilmittel, sondern eine Komponente mehr, die weder fett und träge ist, noch die das System, so wie man es kennt, zu stark ändert oder schlimmstenfalls bloated macht.
Es gibt viele Tools, die zwar viel versprechen, jedoch auch viel zu bloated sind.
Eine zusätzliches Sicherheitsfeature. Je mehr desto besser so lange das System noch zu gebrauchen ist und die logs die angelegt werden von der Masse nicht überhand nehmen das man diese nicht mehr liest.
Daher läuft ja auch diese Technik fest im PF drin. Dadurch wird der Fokus nicht auf ein neues Tool oder Modul, sondern vielmehr auf eine neue Option, eine neue Möglichkeit im PF gerichtet.
Und wenn man schon vorher Logs auf die Logmaschine geschickt hat, dann schickt man jetzt dieselben Logs, mit mehr Informationen (mehr Details also), weil man eben dieses neue Feature aktiviert hat.
Und auf der Logmaschine wartet ein freundliches, kleines Tool, dass daraus html, pdf, xml oder txt Dateien generieren kann.
Auf OpenBSD gibt es ein Tool, das PF-Logs so verarbeiten kann.
Unter FBSD müsste es bestimmt sogar mehrere geben.
Mann, da beneide ich FBSD-User
Interessant wäre in diesem Zusammenhang sicher ein thread oder howto von Free- Open- NetBSD was security angeht. In dem unbedarften Usern gesagt wird was zu machen ist.
Das ist doch eine gute Sache und bringt uns allen was.
So, das waren meine Meinungen dazu ... nochmal: es waren nur Meinungen, denn ein Problem hat (zum Glück) meistens mehrere Lösungsmöglichkeiten.
Gruß
CW