Den Server richtig absichern

Ohne deine installierten Programme und Konfigurationen zu kennen wird man darauf keine Antwort geben können. 100% Sicherheit gibt es aber sowieso nie, egal was wir dir hier antworten werden. Was mir sonst noch einfällt: DenyHosts wäre z.B. auch nicht schlecht.

MfG Christian

"Image-Hosting-Script"
Selbstgecodet oder ein fertiges ?

Zitat von Mo3;14157

Aufgesetzt auf dem Server ist ein Image-Hosting-Script - auch hier konnte ich keine Sicherheitslücken entdecken, das Hochladen beschränkt sich auf Bild-Dateien und die Rechte sind sinnvoll gesetzt.

Tipp: Dem User niemals ermöglichen den Dateinamen des hochgeladenen Bildes festzulegen, immer zufällige Zeichenfolgen als Dateiname verwenden. Eine Überprüfung auf den vom Browser gesendeten Mime-Typ ist ebenfalls falsch, ideal ist die Überprüfung bzw. sogar Konvertierung mit den image* Funktionen von PHP, da dann garantiert nur Bilder hochgeladen werden. Und die hochgeladenen Bilder niemals mit include oder require einbinden, dafür gibt es readfile oder file_get_contents - sofern PHP dafür verwendet wird

MfG Christian

Damit keiner auf die Idee kommt, z.B. die ShellC99.php hochzuladen und auszuführen.

und damit es nicht passieren kann, dass ein Bild schon existiert....

Was man machen kann ist die /home/<username>/.bash_history read-only zu schalten (400).

Das ist zwar ggf. ein Komfort-Verlust, vermeidet aber, daß irrtümlich eingegebene sicherheitsrelevante Daten (z.B. Passwörter) dort im Klartext zu finden sind. Kein sehr großes Risiko, da ja eigentlich nur genau dieser User das lesen darf, aber naja....

Ansonsten ist sämtliche Standardsoftware ein typisches Einfalltor. Also z.B. CMS und Forensoftware. Insbesondere, wenn diese nicht mehr aktuell ist und Sicherheitslücken bekannt sind.

Daher sämtliche Standard-Software, wenn immer möglich über die Distribution installieren. Das gilt z.B. auch für Perl-Module (deren Installation per CPAN natürlich auch recht bequem ist, aber nicht den Update-Mechanismen unterliegt). Ein Problem stellen also auch Zusatzmodule für Standard-Software dar, sofern diese keinen eigenen Update-Mechanismus mitbringt.

In Sachen SPAM ist natürlich die Konfiguration des Mail-Servers relevant. Ein Open-Relay schafft da keine Freunde. Aber auch sämtliche Anwendungen mit Formularen und E-Mail Versende-Funktion (z.B. Kontaktformulare, Bestätigungsmails, Forensoftware) sind anfällig, um ggf. für SPAM-Zwecke benutzt zu werden. Auch Stellen an denen Anwender eigene Links bereitstellen können (z.B. Gästebücher) sind problematisch, da hier ggf. auf Malware verlinkt werden kann.

Schön, Michi!

Für mich ist das größte Sicherheitsleck ein möglicher Exploit bei meinen Websystemen.
Apropos: phpmyadmin und solcher Kram gehört zum einen auf ein anderes Alias (wegen Brute-Scripts), auf jeden Fall nur per https erreichbar und am besten auch .htaccess-geschützt.

Zitat von Mo3;14130

• SSH Port ist verlegt auf einen fünfstelligen Port
• Root-Login ist verboten, Einloggen nur mittels normalem User
• Dieser normale User hat ein Passwort mit 18 Zeichen, bestehend aus Zahlen, Ziffern und Sonderzeichen

Zitat von Artimis;14192

Apropos: phpmyadmin und solcher Kram gehört zum einen auf ein anderes Alias (wegen Brute-Scripts), auf jeden Fall nur per https erreichbar und am besten auch .htaccess-geschützt.

Hallo,

Ich würde empfehlen, in beiden Fällen noch einen Schritt weiterzugehen: Grundsätzlich keinen SSH-Zugang ohne die Verwendung von Schlüsseldateien erlauben (die Verlegung des Ports reduziert die Größe der Logdateien und schadet natürlich nicht, bietet aber keinen Schutz gegen Portscans). Dasselbe gilt für alle Dienste, welche nicht direkt öffentlich verfügbar sein müssen (phpMyAdmin, IRC-Bouncer, Datenbanken für Wordpress o.ä.): Bindet diese an ein privates Loopback-Interface (eine 192.168.x.y-Adresse o.ä. ist über den Support erhältlich, wenn sie nicht bereits vorkonfiguriert war) und tunnelt diese über eine SSL-Verbindung nach außen (entweder temporär mittels OpenSSH oder dauerhaft mittels Stunnel).

Ad astra, Markus

Jep, so mache ich das auch mit sicherhheitsrelevanten Webends.
Allerdings leider der Komfort darunter erheblich und ich denke mal, dass die Lösung schon paranoid ist.
Aber wenn man entsprechende Tools benutzt, sollte es passen.
Auf jeden Fall notwendig für per se unsichere Dienste wie SQL.

Zum SSH-Login:
Klar sind Schlüsselpaar deutlich sicherer, aber ein (für den Cracker) unbekannter User mit einem 18-Stelligen Passwort sollte schon sehr sicher sein.

Ich selbst arbeite zwar prinzipiell mit PKI, jedoch habe ich auch noch ein Passwort für ältere Anwendungen drin, die ich nicht missen möchte.

Zitat von Artimis;14192

Apropos: phpmyadmin und solcher Kram gehört zum einen auf ein anderes Alias (wegen Brute-Scripts), auf jeden Fall nur per https erreichbar und am besten auch .htaccess-geschützt.

Ideal wäre ein anderer Port (vhost) und den dann per Firewall für externen Zugriff sperren, wenn man Zugriff braucht kann man dann einfach über Putty einen Tunnel bauen lassen so problemlos zugreifen. Die Tunnel-Einrichtung dauert max. ne Minute unter Windows sodass man sie auch mal schnell auf nem andern Rechner neu einrichten kann.

Zitat von Artimis;14192

phpmyadmin und solcher Kram

http://www.sim4000.de/phpmyadm…a_ordner_sperren,135.html

Ich nutze das Stichwort noch mal als Schleichwerbung für meinen Security Hack.
Habe irgendwie noch keine Rückmeldung ob gut oder schlecht bekommen.

Wo kann man denn die Logs finden, wer sich versucht hat einzuloggen ?

IMHO erledigt das programm "logwatch" diese Arbeit wunderbar. Es können neben auth.log auch noch andere logs ausgewertet werden.