notwendige Sicherheitsprogramme für sehr stark bedrohten root server

[nimda05]

Hallo!

Ich werde in den nächsten Tagen einen root-Server für eine Webseite konfigurieren müssen. Dazu muss ich sagen, dass diese Webseite mit Sicherheit massiv unter Angriffen jeglicher Art am Anfang leiden wird.
Was muss ich alles installieren damit das ganze wirklich sicher ist?
Bis jetzt steht nur APF und das Anti-DOS Skript auf meiner Liste.
Was brauch ich noch?

Achso: Die ganzen standart ports wie ssh und ftp werden natürlich auf einen anderen Port gelegt. Aber was muss ich noch machen?

Es tut mir unendlich leid wenn diese Frage schonmal gestellt wurde aber ich konnte leider weder mit der Forumsuche noch mit google eine passende Antwort finden.

Vielen, vielen Dank im vorraus!

Nimda05

[sledge0303]

Wie wäre SSH mit Authentifikation mit Key statt Passwort?
Apachen/Lighty ins Jail stecken?
hardened Kernel?

Die Sicherheit fängt bei der Planung an ;)

[elch_mg]

ich find ja

Code: Select all

shutdown

, kombiniert mit den passenden Optionen, sehr schön. Hilft gegen alles, glaub ich. :P

Im Ernst: Sicherheit ist kein Programm, sondern das Resultat eines gut durchdachten Konzeptes. Natürlich gehören da auch Programme zu, aber nicht ausschliesslich, und am besten nicht vorhandene. Soll heissen:

Was muss ich alles installieren damit das ganze wirklich sicher ist?

ist genau falsch rum.

Standard schreibt sich übrigens mit D.

[aubergine]

Um was für eine Seite geht es wenn man fragen darf?

[nimda05]

Hallo!

Erstmal vielen Dank für eure Zeit und eure Beiträge! :-) :-)
Zum Inhalt des Boards kann bzw. darf ich zum jetzigen Zeitpunkt noch nichts sagen. Ich kann nur sagen, dass es sich nicht um Warez oder Pornographie (besonders nicht kinderpornographie) dreht.

@sledge0303

Danke für eine Tipps! Aber wird so ein Authentification Key nicht auf der Festplatte gespeichert? Was ist wenn man sich einen Trojaner einfängt?
Ich finde da ein 32 stelliges Passwort doch sicherer ;-) Oder liege ich falsch?

bei den anderen beiden sachen muss ich erstmal nachgucken was das ist ;-) sogut kenne ich mich dann doch nicht aus. Hast du vieleicht nen link dazu?

@elch_mg:
jaja shutdown -h NOW. schon klar ;) Aber damit ist auch keinem geholfen.
Du hast recht. War Dumm von mir. Ich beschäftige mich schon etwas mit Sicherheit und den Leitsatz "Sicherheit ist kein Status sondern ein fortlaufender Prozess" kenne ich auch :-)
Du sprichst von einem Konzept. Was gehört denn alles zu diesem Konzept? Die grundlegendsten und wichtigsten Aspekte wären schön!

BTW: auf http://www.rfxnetworks.com/ gibt es ein Anti-Bruteforce-Skript. Ist das empfehlenswert?

[Roger Wilco]

Danke für eine Tipps! Aber wird so ein Authentification Key nicht auf der Festplatte gespeichert? Was ist wenn man sich einen Trojaner einfängt?

Dann bist du selbst Schuld. :oops:

Ich finde da ein 32 stelliges Passwort doch sicherer ;-) Oder liege ich falsch?

Üblicherweise sichert man den Private Key mit einer Passphrase (wohlgemerkt kein Passwort) ab.

bei den anderen beiden sachen muss ich erstmal nachgucken was das ist ;-) sogut kenne ich mich dann doch nicht aus. Hast du vieleicht nen link dazu?

http://www.rootforum.org/wiki/howto/all ... sicherheit
http://www.rootforum.org/wiki/howto/gentoo

[nimda05]

Danke für eine Tipps! Aber wird so ein Authentification Key nicht auf der Festplatte gespeichert? Was ist wenn man sich einen Trojaner einfängt?

Dann bist du selbst Schuld. :oops:

Also es ist nur so, dass wir mehrere Admins sind und die meisten davon Windows-User. Und Windows ist denke ich deutlich anfälliger für Trojaner als Linux (ich) (schon klar. wenn linux falsch gekonfigt ist dann ist es auch unsicher). Es ist halt einfach nur ne vorsichtsmasnahme keinen authentification key zu verwenden. Oder birgt der irgendwelche ungahnten Vorteile in sich?
Ich dachte noch eventuell daran den Zugang auf den ssh Port nur von der IP eines anderen root-Servers zu erlauben (selbstverständlich trotzdem mit passwortabfrage). Ist so etwas empfehlenswert oder einfach nur unnütz?

Ich finde da ein 32 stelliges Passwort doch sicherer ;-) Oder liege ich falsch?

Üblicherweise sichert man den Private Key mit einer Passphrase (wohlgemerkt kein Passwort) ab.

Entschuldige bitte meine Unpräzision bei meinen Angaben :-) Sicherlich werde ich nicht "hallo" oder "12345678" als Passwort nehmen ;-)

bei den anderen beiden sachen muss ich erstmal nachgucken was das ist ;-) sogut kenne ich mich dann doch nicht aus. Hast du vieleicht nen link dazu?

http://www.rootforum.org/wiki/howto/all ... sicherheit
http://www.rootforum.org/wiki/howto/gentoo

Danke dir! :-)

[timeless2]

Hier mal nur zwei Links von vielen zum Thema SSH:
http://www.rootforum.org/forum/viewtopic.php?t=43280
http://www.rootforum.org/forum/viewtopic.php?t=39636

Statt FTP kannst du auch noch SFTP/SCP einsetzen. Für die anderen Dienste findest du auch zahlreiche Beiträge über die Forensuche.

[daemotron]

Und damit Du Dich nicht über zu wenig Lesestoff beklagen kannst:
http://www.rootforum.org/forum/viewtopic.php?t=43539
http://www.my-universe.com/linux-und-bs ... r-security

Aus meiner bisherigen Erfahrung heraus würde ich behaupten, dass die Mitigation bereits eingetretener Risiken der bislang in der IT-Welt am stärksten vernachlässigte Faktor ist - insbesondere Konzepte zur Reaktion auf eingetretene Vorfälle können viele Admins leider nicht vorweisen... ("Stecker raus" ist meistens nicht die beste mögliche Reaktion!) Klar ist Prävention besser als Reaktion, aber wer sich nur auf Prävention verlässt, steht schnell mit heruntergelassenen Hosen da, wenn es einem Angreifer gelingt, doch mal durchzubrechen.

[compositiv]

Ich finde da ein 32 stelliges Passwort doch sicherer ;-) Oder liege ich falsch?

Üblicherweise sichert man den Private Key mit einer Passphrase (wohlgemerkt kein Passwort) ab.

Vor allem handelt es sich bei RSA/DSA um ein assymetrisches Verfahren, d.h. auf dem Server liegt nur der PublicKey, den man zur Zeit (bei entsprechender Schlüssellänge) mit endlichem Aufwand nicht benutzen kann um den SecretKey zu gewinnen.

Den SecretKey muss man natürlich geheim halten und nicht auf dem Server speichern.

[daemotron]

Wenn ich den OP richtig verstanden habe, hatte er Bedenken, dass die Client-Rechner, auf denen der private Schlüssel verwendet wird, Opfer eines Angriffs werden könnten. Das ließe sich zwar eingrenzen, indem der Schlüssel
a) durch eine Passphrase gesichert wird und
b) nur temporär auf dem Rechner verfügbar gemacht wird (z. B. per USB-Stick)

Tatsächlich halte ich diese Gefahr aber für nicht unbeträchtlich, da Client-Rechner häufig schlecht gepflegt und gewartet werden und ohne Bedenken alle mögliche Software darauf ausprobiert wird - ob aus seriöser Quelle oder eben auch nicht. Deshalb gehört für mich Grundhygiene und Housekeeping auf der Workstation genauso mit zu einem runden Sicherheitskonzept - und dann spricht auch nichts gegen den Einsatz von Public Key Verfahren.

[EdRoxter]

Wer einen PrivKey ohne Passphrase benutzt, ist ebenfalls selber schuld.

Um das mal einfach zu erklären: Beim AuthKey-Verfahren liegt auf dem Server ein öffentlicher Schlüssel, zu dem ein privater Schlüssel passt (beide hast du generiert, gibt genügen Tutorials), den du vom Server dann tunlichst löschen, dir aber vorher an einen sicheren Ort kopieren solltest.
Dieser private Schlüssel kann obendrein noch mit einer Passphrase gesichert werden. Das heißt also, selbst wenn jemand die Datei mit dem Schlüssel in die Finger bekommt, ist sie für ihn so lange wertlos, wie er diese Passphrase nicht kennt, die du jedes Mal eingeben musst, wenn du den Key benutzt - sprich, dich damit auf dem Server anmeldest.
Wenn du dann noch bei SSH das root-Login verbietest (administrative Arbeiten nur mit su/sudo), die Anmeldung mit Username/Passwort komplett abschaltest und dich per normalen Systemuser mit AuthKey anmeldest, hast du beinah alles getan, was möglich ist, um SSH abzusichern. Du könntest zusätzlich(!!!) noch den SSH-Port verlegen, damit hältst du dann noch deine Logfiles klein.
Das bringt natürlich alles nichts, wenn die anderen Dienste, die da so laufen, nicht auch entsprechend ihrer Angriffsflächen gesichert sind. Beim Apachen würde ich mod_security mit dem Ruleset von gotroot empfehlen sowie eine gut durchdachte Konfiguration. Eventuell sperrst du ihn noch in ein Jail.
SCP statt FTP ist auch eine gute Wahl. Wenn Mails über den Server laufen sollen, den MTA gut gegen Spamversuche abdichten (nur lokales Relay, wenn User nicht authentifiziert sind, SMTP und POP3 via TLS).. Und natürlich: Alle Software/Dienste, die nicht gebraucht werden, rausschmeißen, alle Software auf dem aktuellen Stand halten (insbesondere auch die Forensoftware!), regelmäßige Backups und einen Plan B für den Fall, dass du doch mal infiltriert wirst.

Hab ich was Wichtiges vergessen?

[daemotron]

ein privater Schlüssel [...], den du vom Server dann tunlichst löschen, dir aber vorher an einen sicheren Ort kopieren solltest.

Einspruch - das Schlüsselpaar sollte man lieber auf einem sicheren Rechner generieren, nicht auf einem Server, der in der "roten Zone" steht. Zumal selbst überschreibende Löschtools wie shred auf journalisierenden Dateisystemen nicht 100% zuverlässig löschen...

[nimda05]

Oh mann! Vielen Danke an euch :-D
Ich werde wohl die meisten Ideen umsetzen.
Zwei Fragen bleiben mir jedoch noch:
1. Lohnt sich der Einsatz der BruteForce Detection von http://www.rfxnetworks.com/bfd.php ?

2. Ein Jail ist nur unter BSD möglich, oder? Gibt es eine Alternative für Debian?

[Roger Wilco]

1. Lohnt sich der Einsatz der BruteForce Detection von http://www.rfxnetworks.com/bfd.php ?

Ich kenne das spezielle Programm/Skript nicht, aber grundsätzlich eignen sich solche Sachen wunderbar zum Self-DoS oder um sich selbst auszusperren.

2. Ein Jail ist nur unter BSD möglich, oder? Gibt es eine Alternative für Debian?

RSBAC bringt eigene Jails mit und GrSecurity bietet einige Erweiterungen für den chroot-Systemaufruf. Es gibt also durchaus auch einige Möglichkeiten für Linux.

[nimda05]

Hallo nochmal!

Ich habe mich noch ein bisschen mit dem Thema Jails beschäftigt und das hat mcih doch sehr stark überzeugt :-D
Wie ist das jedoch mit der Geschwindkeit? Läuft der Apache z.B. genauso schnell oder langsamer? Kann da jemand mal einen Erfahrungsbericht abgeben?
Vielen Dank :-)

[daemotron]

Mit Jails unter FreeBSD gibt's kaum Verluste (außer eben dadurch, dass bei mir @home mehrere Server parallel laufen, die natürlich auch alle entsprechend Ressourcen ziehen). Mit RSBAC-Jails habe ich keine Erfahrung, setze auf meinem Server auf gehärtete (grsecurity) chroot-Umgebungen. Overhead entsteht eigentlich nicht außer beim Starten des Servers durch den chroot()-Syscall. Während des Betriebs muss der Kernel natürlich Syscalls von Prozessen auf Legitimität prüfen. Das klaut ein bissl was, aber nicht so, dass ich es wirklich messen könnte.

HTH

[nimda05]

Hallo!

Der server in online!
Allerdings wird der Apache vermutlich mit einem simplen Syn-DDOS Angriff blockiert. Was kann ich dagegen tun?

Vielen Dank

Nimda05

EDIT: Dazu kommt das Problem dass der Apache2 nix in die access.log schreibt. wodran kann das liegen? die error.log wird jedoch beschrieben

[EdRoxter]

U mean SYN-Flood?

Code: Select all

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

[nimda05]

hab ich schon an. die ip ist auch schon mit hilfe der iptables geblockt.
aber trotzdem kommt niemand auf die seite und wenn dann nur extrem langsam