Remote Insight und Sicherheit

T

tremolo2k

Well-Known Member
Hallo Forum,

wie ihr aus meiner Sig. erkennen könnt, habe ich einen Compaq ProLiant ML330 G2. Der Server hat gestern noch ein Remote Insight Board spendiert bekommen. Nun kann ich per Webbrowser meinen Server steuern.

Wie sicher ist das, wenn ich das Web-Interface der Remote Insight aus dem Internet erreichbar mache? d.h. Ich mach einen DynDNS account, und stell den Router so ein, dass dann direkt das Web-Interface der Remote Insight erschein, und ich mich dann einloggen kann. Das Web-Interface ist zwar 128-bit SSL verschlüsselt, aber wie sicher ist das Ganze? Wäre das ganze für Privaten gebrauch vertretbar, oder ist es einfach nur absurd? Wenn jemand das Login und PW kennt, und die Remote Console aktiviert, steht er wieder vor einem Login der FreeBSD konsole. und ohne Login kann man ja nichts ausrichten.

Zusatzfragen:

Wenn ich die Ports von SSH und für die MLDonkey GUI auch aus dem Internet erreichbar mache, erhöhe ich dann Massiv das Sicherheitsrisiko, oder ist es für den Privatgebrauch vertretbar? Es kennt ja niemand meinen DynDNS account... und die IP wechselt Provider bediengt alle 20h.

Sorry wenn ich vielleicht blöde Fragen stelle, aber von Netzwerksicherheit habe ich keine grosse Ahnung und hoffe, dass Ihr mich einwenig unterstützt.
 
Einen Schutz vor Scripdkiddies (security by obscurity) erhältst du indem du einfach nicht die Standardports verwendest. Bei ssh hältst du dir so auch das logfile einigermaßen sauber, denn die meisten Angriffe laufen ausschließlich über Port 22.

Gut, es ist keine wirkliche Sicherheit, aber dennoch eine gute Maßnahme.
 
Das ich Sehr sichere, btw. lange Passwörter verwende ist eh klar. Ist es auch unbedenklich wegen der MLDonkey GUI auf Port 4001 ? Und wenn ich den standart SSH Port 22 wechsle, und mich im Lokalen LAN über SSH einloggen will, muss ich dann jedesmal den neuen port mitangeben? oder kann ich das auch anders lösen? z.b. im Router
 
In der /etc/ssh/ssh_config des Clienten kannst du eintragen auf welchem Port der Server horcht. z. B.:

Host 192.168.xxx.xxx
Port 227

In der /etc/ssh/sshd_config und/oder in der rc.conf (sshd_flags="-p 227") des Servers kannst du eintragen auf welchem Port der Server horcht.
 
Wenn du von extern nicht über den Standardport erreichbar sein willst, musst du natürlich bei jedem Login den Port mitgeben (Oder wie dargestellt in der ssh_config ändern). Per "ssh -p portnummer" sollte das aber nicht wirklich problematisch sein ;)

Was heißt unbedenklich. Unbedenklich ist es sobald der Rechner vom Netz genommen wurde. Je mehr Dienste du anbietest, desto mehr Angriffsfläche bietest du an. Wenn du aber sichere Passwörter hast, kannst du das Risiko schon klein halten.
 
Wenn ich in der /etc/sshd_config
Code: 
PermitRootLogin No
AllowUsers nismo

eintrage, dann kann sich nur noch nismo per ssh anmelden, richtig? Root über SSH sollte gänzlich gesperrt werden.

Mit welcher Syntax kann ich das Verzeichnis /data und alle darin befindlichen Verzeichnisse/dateien für den User nismo volle Zugriffsrechte erteilen? Reicht es, wenn der user nismo in der Gruppe "wheel" ist und alles von RWXR--R-- auf RWXRWXR-- ändere?
 
Richtig, mit "AllowUsers nismo" ist festgelegt, dass nur der auf dem Rechner (Server) schon angelegte user "nismo", per Fernsitzung "ssh", darauf zugreifen darf.

Zusätzlich kannst du in der /etc/ssh/sshd_config auch eintragen, von welchem/n Client(en), sich der user "nismo" per ssh auf dem Server einloggen/anmelden darf, z. B.:

AllowUsers nismo@192.168.156.14 nismo@192.168.156.19

Da der user "nismo" für den Server (... nismo ist ja bereits als user auf dem Server schon angelegt) kein Unbekannter ist, darf er i. d. R. über die Fernsitzung "ssh" all das machen, was er über den direkten Zugriff auch machen kann/darf.
 
Und gibt es irgend eine Möglichkeit dem User nismo die Rechte so zu vergeben, dass er im Verzeichnis /data alles machen kann, was er will, auch rechte verteilen mittels chmod. in diesem Verzeichnis werden auch Dateien angelegt (via smb) deren Besitzer nicht nismo ist?

So quasi das nismo im Verzeichnis /data "root-rechte" hat? Ich denke das wird nicht ohne weiteres gehen. /data ist ein mount-point, falls das was hilft.


Kann ich verhindern, wenn nismo via SSH angemeldet ist, dass der via "su" root werden kann?
 
Zuletzt bearbeitet:
Ein "normaler" user kann nur dann nicht su (also root) werden, wenn er nicht der Gruppe "wheel" angehört. D. h. in deinem Fall darf der user nismo nicht Mitglied der Gruppe "wheel" sein. Damit das nicht umgangen wird, musst du sicherstellen, dass die Datei "/usr/bin/su" nur der Gruppe "wheel" zur Verfügung steht und alle anderen user von deren Benutzung ausgeschlossen werden und auch nicht Mitglied der Gruppe "wheel" sind bzw. werden können.

Rechte verteilen für die Datei su kannst du mit: chmod 4750 /usr/bin/su
Anzeigen der Eigenschaften mit: ls -l /usr/bin/su
-rwsr-x--- 1 root wheel 14268 Jan 04 2007 /usr/bin/su

Eine Möglichkeit dem user nismo (nur) im Verzeichnis /data, quasi "root-rechte" einzuräumen, ist die Benutzung von Quotas. Damit kannst du festlegen wieviel Speicherplatz und welchen Speicherplatz, du dem user nismo überlässt. Wie man Quotas einrichtet (Kernel, rc.conf, /etc/fstab, Quota-Limits, etc.) ist ausführlich im FreeBSD-Handbuch (Kapitel: 18.15. Dateisystem-Quotas) beschrieben. Siehe auch Link: http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/book.html#QUOTAS
 
Zuletzt bearbeitet:
nismo2000]Kann ich verhindern schrieb:
Rechte verteilen für die Datei su kannst du mit: chmod 4750 /usr/bin/su
Zum Vergrößern anklicken....
Das ist unnötig, weil su(1) selbst die Überprüfung veranlasst, siehe Source. Gesteuert wird das über PAM, siehe /etc/pam.d/su:
Code: 
auth            requisite       pam_group.so            no_warn group=wheel root_only fail_safe

morromett schrieb:
Eine Möglichkeit dem user nismo (nur) im Verzeichnis /data, quasi "root-rechte" einzuräumen, ist die Benutzung von Quotas.
Zum Vergrößern anklicken....
Speicherplatzbeschränkungen erlauben doch beim besten Willen keine Ausweitung der Privilegien, das wäre ja fatal.

CommanderZed schrieb:
Am sichersten wäre es natürlich sich per VPN in das Netz einzuwählen, dann brauchst du gar keine Portweiterleitung!
Zum Vergrößern anklicken....
Kann mich nicht erinnern, daß hier irgendwann eine Portweiterleitung erwähnt wurde. Davon abgesehen würde ein VPN aber auf einen Schlag alle Dienste mit einer sicheren Authentifizierung nach außen hin absichern. Mit "blankem" HTTPS ist man halt auf Benutzername und Paßwort beschränkt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben