SSH absichern
Die Fernwartung eines eigenen Root Servers ist wohl das wichtigste, (fast) alle Server Administratoren setzten dazu SSH ein. Da heutzutage schon alle Server nur die Ports offen haben die genutzt werden (Web, eMail usw.) konzentrieren sich die Angreifer auf den SSH Zugang. Hier möchte ich euch nun zeigen wie ihr euren SSH Login am besten absichert, dies kann man mit ein paar einfachen Schritten erledigen.
Dazu legen wir einen neuen Benutzer an der keine Rechte besitzt außer sich einzuloggen und den Benutzer mit su zu wechseln.
adduser --home /home/.suonly suonly
Dies legt zugleich auch eine Gruppen Namens suonly an. Man wird aufgefordert ein Passwort einzugeben, dort sollte man ein sich ein sicheres ausdenken. Als nächstes vergeben wir dem Benutzer suonly eine Restricted Bash – Login Shell, so können wir den Benutzer in seinen Rechten einschränken.
chsh -s /bin/rbash suonly
Um den Benutzer suonly in sein Home Verzeichnis einzusperren, übergeben wir alle Rechte des Verzeichnisses dem User root.
chown root:root /home/.suonly cd /home/.suonly
Als nächstes erstellen wir im Home Verzeichnis ein Unterverzeichnis Namens bin. Und erzeugen eine symbolischen Link zu /bin/su
mkdir bin ln -s /bin/su /home/.suonly/bin/su
Die Dateien .bash_profile und .profile werden gelöscht, und es wird jeweils ein symbolischer Link auf .bashrc gesetzt.
rm -f /home/.suonly/.bash_profile rm -f /home/.suonly/.profile ln -s /home/.suonly/.bashrc /home/.suonly/.bash_profile ln -s /home/.suonly/.bashrc /home/.suonly/.profile
Mit folgendem Befehl löschen wir den kompletten Inhalt der .bashrc Datei und legen zugleich die PATH Variable fest.
echo "PATH=/home/.suonly/bin" > /home/.suonly/.bashrc
Da der User so gut wie überhaupt keine Rechte besitzen soll, außer sich einzuloggen und den Benutzer zu wechseln, müssen wir die .bashrc Datei wie folgt editieren.
PATH=/home/.suonly/bin unset _xmms _usergroup installed_alternatives _user_at_host _update_rc_d _update_alternatives _umount _uids _tar _sysctl unset _ssh _signals _services _service _scp _route _root_command _rmmod _rl_enabled _renice _python _pon _poff unset _pkg_config _pids _pgrep _pgids _perlmodules _perldoc _perl _openssl_sections _openssl _ooexp_ _ntpdate _mount unset _modules _mkisofs _man _make_kpkg _make _look _longopt _known_hosts _killall _kill _java_path _java_packages unset _java_find_sourcepath _java_find_classpath _java_classes _java _jar _iptables _invoke_rc_d _insmod _info _ifupdown _id unset _iconv _gzip _gpg _gids _getent _gcc _function _find _filedir_xspec _filedir _export _expand _dselect _dpkg_source unset _dpkg_reconfigure _dpkg _dpatch_edit_patch _dhclient _dd _dcop _cpio_format _cpio _count_args configured_interfaces unset _configure_func _complete _comp_dpkg_installed_packages _command _chsh _chown _chgrp _cdrecord _cd _cancel unset _bzip2 _available_interfaces _aspell_dictionary _aspell _apt_get _apt_cache _alias _ PAGER MAILCHECK MAIL HISTFILE
Dadurch ist es für den User .suonly nur noch möglich sich einzuloggen und den Benutzer mit su zu wechseln.
SSH Config
Folgende Zeilen müssen in deiner /etc/ssh/sshd_config editiert werden.
Port 23457
AllowGroups suonly
AllowUsers suonly
PermitRootLogin noErläuterung der Änderungen:
Der Port sollte ein anderer als 22 sein, da Hacker oder Script Kiddies immer zuerst diesen versuchen, wichtig ist auch das man einen sehr hohen Port wählt über 10000, da die meisten dort nicht mehr danach suchen. Mit AllowGroups erlauben wir nur einer bestimmten Gruppen den Zugang mit AllowUsers schränken wir den Zugang noch weiter (nur auf einen Benutzer) ein. Mit PermitRootLoign no sagen wir dem SSH Server das sich der Benutzer root nicht einloggen darf.
Um das ganze zu testen starten wir den SSH Server neu, die Aktuelle Verbinung mit dem Server wird nicht getrennt, das ist auch gut so! Wir öffnen eine weitere Verbinung zum Server und lassen die alte Verbindung UNBEDINGT bestehen, so können wir evtl. die Einstellungen wieder rückgängig machen, und sperren uns so nicht aus.
SSH Server neustarten
/etc/init.d/ssh restart
Nachdem Neustart stellen wir eine neue weitere Verbingung zum Server her, und versuchen uns mit dem neuen Benutzer einzuloggen, und wechseln dann mit su root zum User root.
Wenn alles geklappt hat können wir getrosst die alte Verbindung kappen und mit der neuen weiter arbeiten.
weitere Links zum Thema:
