
Ich habe chmod 777
rekursiv weitergemacht /var/
und konnte keine Verbindung mehr über SSH herstellen. Ich habe gelesen, dass das chmod 600
das Problem beheben würde. Ich konnte danach zwar eine Verbindung herstellen, aber das war keine gute Idee.
Gibt es eine Möglichkeit, die Standardmodi für die Ordner herauszufinden /var/
oder das Problem zu beheben?
Läuft unter Debian-Squeeze.
Antwort1
Dies ist ein sehr häufiger Fehler bei Benutzern, die von einem Betriebssystem kommen, in dem das Berechtigungskonzept fehlt. Viele
sudo chmod -R 777 /
und dergleichen wurden vielleicht in guter Absicht herausgegeben, aber es ist auch mehr oder weniger der einzige Benutzerfehler, der mich dazu veranlassen könnte, bei einem *nix-System „einfach neu installieren“ zu empfehlen.
Wenn Sie nur chmod -R 755
, dann werden Sie unter anderem geben lesen undAusführungBerechtigung für jede Datei für jeden. Wenn man einfach die Ausführung für jede Datei entfernt (Verzeichnisse brauchen sie, um durchsuchbar zu sein), dann entfernt man das Ausführungsbit für einige Dateien, dieangeblichausführbar sein, und so weiter.
In diesem Fall ist es vielleicht nicht so schlimm wie -R /
, aber in zB /var/log
gibt es viele Dateien, dienichtsollte Leserechte für jeden haben. Ein kleiner Auszug:
-rw-r--r-- alternatives.log
drwxr-x--- apache2
drwxr-xr-x apt
-rw-r--r-- aptitude
-rw-r----- auth.log
-rw-r----- boot
-rw-rw---- btmp
drwxr-xr-x ConsoleKit
drwxr-xr-x cups
-rw-r----- daemon.log
drwxr-xr-x dbconfig-common
-rw-r----- debug
-rw-r----- dmesg
-rw-r--r-- dpkg.log
-rw-r--r-- duplicity-backup.0
drwxr-s--- exim4
-rw-r----- fail2ban.log
-rw-r--r-- faillog
-rw-r--r-- fontconfig.log
drwxr-xr-x fsck
drwxr-xr-x hp
drwxr-xr-x installer
-rw-r----- kern.log
-rw-rw-r-- lastlog
-rw-r--r-- lpr.log
-rw-r--r-- mail.err
-rw-r--r-- mail.info
-rw-r--r-- mail.log
-rw-r--r-- mail.warn
-rw-r----- messages
drwxr-x--- mrtg
drwxr-s--- mysql
-rw-r----- mysql.err
-rw-r----- mysql.log
drwxr-sr-x news
-rw-r--r-- popularity-contest
-rw-r--r-- pycentral.log
-rw-r--r-- rssdler.log
drwxr-xr-x samba
-rw-r----- shorewall-init.log
-rw-r----- syslog
drwxr-xr-x unattended-upgrades
-rw-r----- user.log
-rw-rw-r-- wtmp
-rw-r--r-- Xorg.0.log
Das Wiederherstellen ist nicht einfach. Und das war nur ein Verzeichnis.
Alles in allem: Selbst wenn Sie SSH wieder zum Laufen gebracht haben, haben Sie einige nicht unerhebliche Berechtigungsinformationen verloren. Wenn es sich um einen rein persönlichen Server handelt, sind die Folgen wahrscheinlich nicht so schlimm, aber die Berechtigungen sind aus gutem Grund so restriktiv wie möglich eingestellt. In den oben erwähnten Protokolldateien können beispielsweise vertrauliche Informationen gespeichert sein, und jetzt reicht es für einen Exploit mit regulären Benutzerrechten aus, dies herauszufinden und noch mehr Informationen für Root-Berechtigungsangriffe zu erhalten.
Das letzte Mal habe ich gestern in einem lokalen Forum jemanden den chmod -R 777
Tipp „Tu das!!!“ geben sehen. Vertraue nicht dem Internet! :-)