Posts mit dem Label Sicherheit werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Sicherheit werden angezeigt. Alle Posts anzeigen
Eigender Anonymer Onion Router (Tor)
Die Installation von Tor unter Ubuntu,BT5R2 und anderen Abkömmlingen
Schritt: 1
sudo add-apt-repository ppa:ubun-tor/ppa
sudo apt-get update
sudo apt-get install tor tor-geoipdb privoxy vidalia
Schritt: 2
sudo nano /etc/privoxy/config
Append the following line :
forward-socks5 / 127.0.0.1:9050 .
sudo /etc/init.d/privoxy start
sudo /etc/init.d/tor start
Schritt: 2a (Optional)
Wenn du hinter einer Firewall oder NAT sowie dem Router seid, dann solltet ihr die folgende Zeile an der konfigurieren Datei anhängen.
forward 192.168.*.*/ .
Schritt: 3
Geh auf die Offizelle Tor seite und downloade und installiere den Tor button für Firefox.
https://www.torproject.org/dist/torbutton/torbutton-current.xpi
(A2) Windows 7
Downloade die aktuelle version des Tor Browser Bundle 2.2.35-8.
https://www.torproject.org/dist/torbrowser/tor-browser-xxx.exe
Installiere sie und lege ein Verknüpfung auf den Desktop.
Part B - Installation für xChat
(B1) Ubuntu or BackTrack 5 R2
Schritt: 4
dig +short irc.tor.freenode.net cname
Das Resultat ist :
p4fsi4ockecnea7l.onion.
sudo nano /etc/tor/torrc
Hänge folgende Zeile an.
mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion
Schritt: 5
sudo /etc/init.d/tor restart
sudo apt-get install xchat
Schritt: 6
Wenn Du bereits ein Benutzername bei Freenode hast, dann kannst du diesen Schritt auslassen.
/msg nickserv register [password] [email]
/msg nickserv set hidemail on
Schritt: 7
xChat, gehe zu den "Settings" | "Preferences" | "Network" | "Network setup" | "Proxy server", enter :
Hostname : 127.0.0.1
Port : 9050
Type : Socks5
Use proxy for : IRC Server Only
Schritte: 8
Erstelle ein neuen Server "TorifiedFreenode" und melde ihn an die xChat Server-Liste.
Press "Add"und dann fülle es als "10.40.40.40". aus.
Schritt: 9
Downloade:
cap_sasl_xchat.pl at http://lwsitu.com/xchat/cap_sasl_xchat.pl and save it at ~/.xchat2 und make und ausführbar.
Schritt: 10
Die Status-Fenster von xChat:
/sasl set TorifiedFreenode [your_Freenode_Nickname] [your_Nick_password] PLAIN
Schritt: 11
Blocke CTCP und DCC commandos und Anfragen die gesandtwerden an deine IRC client software :
/ignore *!*@* CTCP DCC
/ignore * CTCP DCC
/set irc_hide_version ON
/set dcc_auto_chat 0
/set dcc_auto_resume OFF
/set dcc_auto_send 0
(B2) Windows 7
Schritt: 12
Downloadede xChat http://www.silverex.org/download/ und installiere ihn.
Schritt: 12a
Geh ins Vidalia Control Panel, select "Settings" | "Advanced" | "Edit current torrc", und hänge folgende Zeile an :
mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion
Schritt: 13
Downloade, die Aktuelle Perl Version, 5.12.4.1205
http://www.activestate.com/activeperl/downloads/thank-you?dl=http://downloads.activestate.com/ActivePerl/releases/5.12.4.1205/ActivePerl-5.12.4.1205-MSWin32-x86-294981.msi
Schritt: 14
Downloade die xcperl5.12.1.dll bei http://lwsitu.com/xchat/xcperl5.12.1.dll
Und Speichere es unter c:\Program Files (x86)\X-Chat 2\plugins. und lösche die xcperl.dll danach.
Schritt: 15
Folge dem obengenannten Schritten 6 bis 11.
Part C - Installation für Filezilla
(C1) Ubuntu und BackTrack 5 R2
Schritt: 16
sudo apt-get update
sudo apt-get install filezilla
Schritt: 17
Öffne Filezilla, geh zu "Edit" | "Settings" | "Generic proxy" :
Select "Socks5"
proxy host : 127.0.0.1
proxy port : 9050
(C2) Windows 7
Schritt: 18
Downloade die neuste Windows version :
http://filezilla-project.org/download.php?type=client
Dann folgt ihr schritt 17
Part D - Verwendet du in der Konsole
Ubuntu und BackTrack 5 R2 only.
Schritt: 19
sudo apt-get update
sudo apt-get install proxychains elinks
Schritt: 20
sudo nano /etc/proxychains.conf
Änderne die folgende Zeile:
socks4 127.0.0.1 9050
zu :
socks5 127.0.0.1 9050
Schritt: 21
Usage -
proxychains nmap google.com
proxychains elinks cmyip.com
proxychains elinks www.wieistmeineip.de
PHP gegen Attacken absichern
Grob geschätzt 80 Prozent aller erfolgreichen Angriffe von außen auf einen Server passieren über das PHP-Modul des Webservers. Lese hier, wie du PHP sicherer machen kannst.
PHP kann Dateien auf den Server schreiben, ausführbaren Code von Webadressen nachladen oder Linux-Systemkommandos mit den Rechten des Webservers ausführen. Meist sind diese Möglichkeiten nützlich und notwendig. Doch viel zu oft lässt sich, dank Fehlern, eine Funktion von außen missbrauchen, um Schädlingsprogramme auf dem Webserver zu installieren.
Deshalb sollte sich jeder Webserver-Administrator dringend mit den Konfigurationsmöglichkeiten von PHP4 beziehungsweise PHP5 vertraut machen, und nur so viele Funktionen zulassen, wie auf dem Server auch tatsächlich benötigt werden. Die dafür zuständige Datei heißt php.ini und liegt, je nach Version von Webserver und PHP, in einem der folgenden Verzeichnisse:
Nach jeder Änderung empfiehlt sich ein
oder
Erst mit dem Neustart werden die Änderungen wirksam. Das graceful-Kommando des Skripts apachectl reicht dazu nicht immer aus.
Gehe die folgenden Anweisungen Schritt für Schritt durch und setze den vorgeschlagenen Wert in deine php.ini. Setze den Wert auch, wenn er die Voreinstellung (default) ist. Denn die jeweils gültigen Voreinstellungen ändern sich des öfteren von PHP-Version zu PHP-Version. Angegeben sind die Defaults für PHP5, bei PHP4 sind sie sehr versionsabhängig.
Und das sind die Befehle:
verhindert, dass beliebige Variable im PHP-Code durch GET- oder POST-Parameter überschrieben werden können. Beim Aufruf der URL http://server/page.php?login=true ist beispielsweise der Wert in der Variablen $_GET["login"] abgelegt. Mit
wird zusätzlich alleine über den URL-Parameter die PHP-Variable $login gesetzt. Dieser Parameter sollte darum heutzutage unter keinen Umständen mehr auf on gesetzt werden.
begrenzt den Speicher (in Megabyte), der bei jedem einzelnen Aufruf eines Skripts verbraucht werden darf. So wird beispielsweise verhindert, dass eine versehentlich programmierte Endlosschleife den kompletten verfügbaren Speicher belegt. Viele PHP-Anwendungen sind recht speicherhungrig, so dass der Wert eventuell höher gewählt werden muss. Das CMS Typo3 benötigt beispielsweise eine Grenze von mindestens 16MB.
begrenzt die Zeit, die ein Script für die Ausführung bekommt. Auch das verhindert Probleme mit versehentlichen Endlosschleifen. Allerdings darf der Wert nicht zu niedrig sein - schließlich soll auch bei voller Serverlast etwa eine aufwendige Datenbankabfrage ohne Fehlermeldung bearbeitet werden.
begrenzt die Zeit, die ein Script mit dem Einlesen der übergebenen Parameter verbringen darf.
begrenzt die Zeit, die PHP bei der Übertragung von Streams auf die Gegenseite wartet.
Defaultmäßig erlaubt es PHP, bei allen Befehlen, die Dateien öffnen, statt eines lokalen Dateinamen auch eine URL anzugeben. Das betrifft beispielsweise die Befehle require, include oder fopen. Setze diesen Wert nur auf on, wenn du diese Funktionalität unbedingt benötigst. Denn schon ein include($_GET["filename"]) stellt ein erstklassiges Sicherheitsrisiko dar. Hier sind allerdings auch die PHP-Programmierer gefragt. Denn solche Konstruktionen sind leichtsinnig.
Dieser Parameter schränkt das Öffnen von Dateien weiter ein. PHP läßt nur noch den Zugriff auf solche Dateien zu, die in oder unterhalb der angegebenen Pfade gespeichert sind. Allerdings solltest du hier nicht zu restriktiv sein: Liegt ein PHP-Programmpaket, wie etwa phpMyAdmin, in einem Pfad außerhalb des üblichen www-Verzeichnisses, muss dieser Pfad mit aufgeführt werden, sonst wird das Programmpaket nicht mehr funktionieren.
gibt das Verzeichnis an, in dem PHP seine Session-Informationen ablegt.
Aus Sicherheitsgründen sollte dafür nicht das Standard-Tempverzeichnis genutzt werden.
gibt das Verzeichnis an, in dem PHP hochgeladene Dateien ablegt. Auch dafür sollte keinesfalls das Standard-Tempverzeichnis verwendet werden.
begrenzt die Größe der Dateien in Megabyte, die via PHP-Funktionen hochgeladen werden können. Der ideale Wert hängt davon ab, für welche Anwendungen PHP eingesetzt wird. Du kannst auch einen größeren Wert, etwa 20M wählen, nur unbegrenzt sollte die Dateigröße nicht sein.
Die Standardeinstellung aktiviert den PHP-Befehl dl(), der PHP-Extensions im Programmcode nachlädt. So verlierst du aber die Kontrolle, welche Extensions auf deinem Webserver verwendet werden. Stelle diesen Parameter also besser auf off und lade Extensions über die php.ini, etwa
PHP-Parameter individuell einstellen
Aufwendiger wird die Einstellung, wenn nicht für den Webserver einheitliche Werte gelten sollen, etwa, weil der Server unter verschiedenen URLs verschiedene PHP-Anwendungen anbietet. Doch auch dann ist es möglich, sichere Einstellungen zu erreichen. Dazu setzt man zunächst in der php.ini alle global geltenden Werte. Alles Weitere passiert dann in den Config-Dateien des Apache-Werbservers. Dafür gibt es zwei Config-Befehle:
Diese beiden Befehle können auch innerhalb eines
Blocks verwendet werden, so dass sie für einen virtuellen Server gelten.
Beispiel:
Beachte die Schreibweise ohne =-Zeichen.
Wenn auf Apache mehrere virtuelle Server laufen, solltest du open_basedir, session.save_path und upload_tmp_dir für jeden Host getrennt setzen.
Achtung, Fußangel
Nicht alle Beschränkungen, die du in der php.ini setzt, können in der Apache-Config wieder aufgehoben werden. Ist in der php.ini etwa allow_url_fopen auf off gesetzt, bleibt es auf off, was auch immer du in Apache einstellst.
Verwende in diesem Fall folgenden Trick:
innerhalb des Virtualhosts, der diese Funktion benötigt. Um zu überprüfen, welche Einstellungen innerhalb eines Hosts tatsächlich gelten, verwende ein kurzes Skript mit dem Befehl phpinfo().
Noch mehr Sicherheit für PHP
Darüber hinaus gibt es weitere Parameter, um PHP noch stärker abzusichern, etwa
Setzt man allerdings diese Parameter auf sichere Werte, schränkt man die Funktionalität von PHP so stark ein, dass viele Anwendungen nicht mehr oder nur noch eingeschränkt funktionieren. Wer diese Parameter ändert, sollte deshalb danach seine Anwendungen ausführlich testen.
PHP kann Dateien auf den Server schreiben, ausführbaren Code von Webadressen nachladen oder Linux-Systemkommandos mit den Rechten des Webservers ausführen. Meist sind diese Möglichkeiten nützlich und notwendig. Doch viel zu oft lässt sich, dank Fehlern, eine Funktion von außen missbrauchen, um Schädlingsprogramme auf dem Webserver zu installieren.
Deshalb sollte sich jeder Webserver-Administrator dringend mit den Konfigurationsmöglichkeiten von PHP4 beziehungsweise PHP5 vertraut machen, und nur so viele Funktionen zulassen, wie auf dem Server auch tatsächlich benötigt werden. Die dafür zuständige Datei heißt php.ini und liegt, je nach Version von Webserver und PHP, in einem der folgenden Verzeichnisse:
/etc/php4/apache/
/etc/php4/apache2/
/etc/php5/apache/
/etc/php5/apache2/
Nach jeder Änderung empfiehlt sich ein
apachectl restart
oder
apache2ctl restart
Erst mit dem Neustart werden die Änderungen wirksam. Das graceful-Kommando des Skripts apachectl reicht dazu nicht immer aus.
Gehe die folgenden Anweisungen Schritt für Schritt durch und setze den vorgeschlagenen Wert in deine php.ini. Setze den Wert auch, wenn er die Voreinstellung (default) ist. Denn die jeweils gültigen Voreinstellungen ändern sich des öfteren von PHP-Version zu PHP-Version. Angegeben sind die Defaults für PHP5, bei PHP4 sind sie sehr versionsabhängig.
Und das sind die Befehle:
register_globals = off ;(php5-default: off)
verhindert, dass beliebige Variable im PHP-Code durch GET- oder POST-Parameter überschrieben werden können. Beim Aufruf der URL http://server/page.php?login=true ist beispielsweise der Wert in der Variablen $_GET["login"] abgelegt. Mit
register_globals=on
wird zusätzlich alleine über den URL-Parameter die PHP-Variable $login gesetzt. Dieser Parameter sollte darum heutzutage unter keinen Umständen mehr auf on gesetzt werden.
memory_limit = 12M ;(default: 8M)
begrenzt den Speicher (in Megabyte), der bei jedem einzelnen Aufruf eines Skripts verbraucht werden darf. So wird beispielsweise verhindert, dass eine versehentlich programmierte Endlosschleife den kompletten verfügbaren Speicher belegt. Viele PHP-Anwendungen sind recht speicherhungrig, so dass der Wert eventuell höher gewählt werden muss. Das CMS Typo3 benötigt beispielsweise eine Grenze von mindestens 16MB.
max_execution_time = 60 ;(default: 30)
begrenzt die Zeit, die ein Script für die Ausführung bekommt. Auch das verhindert Probleme mit versehentlichen Endlosschleifen. Allerdings darf der Wert nicht zu niedrig sein - schließlich soll auch bei voller Serverlast etwa eine aufwendige Datenbankabfrage ohne Fehlermeldung bearbeitet werden.
max_input_time = 60 ;(default: 60)
begrenzt die Zeit, die ein Script mit dem Einlesen der übergebenen Parameter verbringen darf.
default_socket_timeout = 60 ;(default: 60)
begrenzt die Zeit, die PHP bei der Übertragung von Streams auf die Gegenseite wartet.
allow_url_fopen = off ;(default: on)
Defaultmäßig erlaubt es PHP, bei allen Befehlen, die Dateien öffnen, statt eines lokalen Dateinamen auch eine URL anzugeben. Das betrifft beispielsweise die Befehle require, include oder fopen. Setze diesen Wert nur auf on, wenn du diese Funktionalität unbedingt benötigst. Denn schon ein include($_GET["filename"]) stellt ein erstklassiges Sicherheitsrisiko dar. Hier sind allerdings auch die PHP-Programmierer gefragt. Denn solche Konstruktionen sind leichtsinnig.
open_basedir = /var/www/:/usr/share/pear/ ;(default:nicht gesetzt)
Dieser Parameter schränkt das Öffnen von Dateien weiter ein. PHP läßt nur noch den Zugriff auf solche Dateien zu, die in oder unterhalb der angegebenen Pfade gespeichert sind. Allerdings solltest du hier nicht zu restriktiv sein: Liegt ein PHP-Programmpaket, wie etwa phpMyAdmin, in einem Pfad außerhalb des üblichen www-Verzeichnisses, muss dieser Pfad mit aufgeführt werden, sonst wird das Programmpaket nicht mehr funktionieren.
session.save_path = /var/tmp/www ;(default: nicht gesetzt)
gibt das Verzeichnis an, in dem PHP seine Session-Informationen ablegt.
Aus Sicherheitsgründen sollte dafür nicht das Standard-Tempverzeichnis genutzt werden.
upload_tmp_dir = /var/tmp/www ;(default: nicht gesetzt)
gibt das Verzeichnis an, in dem PHP hochgeladene Dateien ablegt. Auch dafür sollte keinesfalls das Standard-Tempverzeichnis verwendet werden.
upload_max_filesitze = 2M ;(default: 2M)
begrenzt die Größe der Dateien in Megabyte, die via PHP-Funktionen hochgeladen werden können. Der ideale Wert hängt davon ab, für welche Anwendungen PHP eingesetzt wird. Du kannst auch einen größeren Wert, etwa 20M wählen, nur unbegrenzt sollte die Dateigröße nicht sein.
enable_dl = off ;(default: on)
Die Standardeinstellung aktiviert den PHP-Befehl dl(), der PHP-Extensions im Programmcode nachlädt. So verlierst du aber die Kontrolle, welche Extensions auf deinem Webserver verwendet werden. Stelle diesen Parameter also besser auf off und lade Extensions über die php.ini, etwa
extension=mysql.so
PHP-Parameter individuell einstellen
Aufwendiger wird die Einstellung, wenn nicht für den Webserver einheitliche Werte gelten sollen, etwa, weil der Server unter verschiedenen URLs verschiedene PHP-Anwendungen anbietet. Doch auch dann ist es möglich, sichere Einstellungen zu erreichen. Dazu setzt man zunächst in der php.ini alle global geltenden Werte. Alles Weitere passiert dann in den Config-Dateien des Apache-Werbservers. Dafür gibt es zwei Config-Befehle:
php_admin_flag
php_admin_value
Diese beiden Befehle können auch innerhalb eines
Blocks verwendet werden, so dass sie für einen virtuellen Server gelten.
Beispiel:
(...)
php_admin_flag allow_url_fopen off
php_admin_value memory_limit 10M
php_admin_value open_basedir /home/ vserver1/:/usr/share/ pear/
Beachte die Schreibweise ohne =-Zeichen.
Wenn auf Apache mehrere virtuelle Server laufen, solltest du open_basedir, session.save_path und upload_tmp_dir für jeden Host getrennt setzen.
Achtung, Fußangel
Nicht alle Beschränkungen, die du in der php.ini setzt, können in der Apache-Config wieder aufgehoben werden. Ist in der php.ini etwa allow_url_fopen auf off gesetzt, bleibt es auf off, was auch immer du in Apache einstellst.
Verwende in diesem Fall folgenden Trick:
allow_url_fopen = on
in der php.ini.
php_admin_flag allow_url_fopen off
in der globalen Apache-Konfiguration. Und dann wiederum
php_admin_flag allow_url_fopen = on
innerhalb des Virtualhosts, der diese Funktion benötigt. Um zu überprüfen, welche Einstellungen innerhalb eines Hosts tatsächlich gelten, verwende ein kurzes Skript mit dem Befehl phpinfo().
Noch mehr Sicherheit für PHP
Darüber hinaus gibt es weitere Parameter, um PHP noch stärker abzusichern, etwa
safe_mode =
disable_functions =
Setzt man allerdings diese Parameter auf sichere Werte, schränkt man die Funktionalität von PHP so stark ein, dass viele Anwendungen nicht mehr oder nur noch eingeschränkt funktionieren. Wer diese Parameter ändert, sollte deshalb danach seine Anwendungen ausführlich testen.
IP-Adressen vom Zugriff sperren
Beim Betrachten deiner Log-Dateien ist dir aufgefallen, dass von einer bestimmten IP-Adresse, besonders viele Seiten abgerufen werden? Dann sperren wir die IP einfach. Falls du ein Apache benutzt und rooot oder der Administrator dir die passenden Rechte eingeräumt hat, geht das am einfachsten über die Datei .htaccess.
Schreib dort zunächst die Zeile
hinein. Das bedeutet: Zunächst einmal ist der Zugriff auf deine Seite allen erlaubt. IP-Adressen, die nicht zugreifen dürfen, müssen explizit ausgeschlossen werden.
Trage danach die IP-Adressen ein, die du ausschließen willst,
Beispiel:
deny 123.255.1.2
deny 251.10.28.148
und so weiter.
Achte aber darauf, das du nicht versehentlich Suchmaschinen auszusperrest.
Schreib dort zunächst die Zeile
order allow,deny
hinein. Das bedeutet: Zunächst einmal ist der Zugriff auf deine Seite allen erlaubt. IP-Adressen, die nicht zugreifen dürfen, müssen explizit ausgeschlossen werden.
Trage danach die IP-Adressen ein, die du ausschließen willst,
Beispiel:
deny 123.255.1.2
deny 251.10.28.148
und so weiter.
Achte aber darauf, das du nicht versehentlich Suchmaschinen auszusperrest.
SSH - Daemon gegen Attacken sichern
Immer wieder sehr beliebt bei pubertären Script-Kiddies scheinen Attacken auf den Secure-Shell-Daemon sshd zu sein. Dabei werden innerhalb von Sekunden hunderte von Login-Versuchen mit Standard-Usernamen wie root, ftp, admin etc. und Passworten aus dem Wörterbuch ausprobiert - frei nach dem Motto: Irgendwo wird's schon klappen.
Solche Attacken sind nicht nur lästig, sie kosten durch die schiere Menge der Anfragen auch Netzwerk-Bandbreite und Rechenkapazitäten. Mit einfachen Mitteln kann man die eigene Secure Shell gegen solchen und ähnlichen Unfug sichern. Alle Einstellungen gehören in das sshd-Configfile, das normalerweise sshd_config heißt und im Verzeichnis /etc/ssh liegt.
Wir müssen bevor wir loslegen ein neuen User anlegen, bevor wir es losgeht.
Wir öffnen die Config Datei und bearbeiten sie.
1. Das ursprüngliche SSH-Protokoll Version 1 ist veraltet und hat einige bekannte Sicherheitsmängel. Deswegen sollte Ihr Server nur Protokoll-Version 2 zulassen. Die Zeile
sorgt dafür.
2. Lange nicht alle Benutzer eines Servers müssen sich per SSH anmelden können. Der Parameter AllowUsers definiert, welche Nutzer erlaubt sind. Alle nicht genannten bleiben ausgesperrt. Beispiel:
Ob man den root-Login per SSH überhaupt zulässt, ist Glaubensfrage. Meiner Meinung nach spricht nichts dagegen, solange man ein solides Passwort für root definiert hat.
3. Kein Benutzer braucht ewig, um sich einzuloggen, also Benutzername und Passwort einzugeben. Jeder gestartete sshd-Task braucht aber Speicher und Rechenzeit. Also gibt man mit
eine Minute Timeout vor. Hat sich 60 Sekunden nach Verbindungsstart noch niemand korrekt eingeloggt, wird der Task beendet.
Vorsicht: Natürlich ist hier auch ein noch kürzerer Wert möglich. Aber berücksichtigen Sie immer, daß Ihr Server auch einmal überlastet sein kann und die Kommunikation mit dem sshd deshalb verzögert wird. Da kann es äußerst lästig werden, wenn der Timeout zu schnell zuschlägt.
4. Um zu verhindern, daß durch einen Hackversuch hunderte sshd-Tasks gleichzeitig gestartet werden, gibt es einen sehr nützlichen Parameter. Fügen Sie dazu die Zeile
in das Configfile ein.
Diese Beschränkung ist äußerst effektiv, aber etwas kompliziert zu verstehen: Die Werte im Beispiel bedeuten, daß 2 (= 1. Wert minus 1) "unauthenticated" (also im Login-Stadium befindliche) sshd-Verbindungen immer erlaubt sind. Ab der 3. (= 1. Wert) Verbindung wird mit einer Wahrscheinlichkeit von 30% (2. Wert) die Verbindung abgelehnt. Diese Wahrscheinlichkeit steigt linear an, bis bei 10 (3. Wert) offenen Verbindungen jeder weitere Verbindungsversuch zu 100% abgelehnt wird.
Achtung: Bereits eingeloggte Nutzer zählen nicht zu diesen Werten! Die angegebenen Beispielwerte sollten also für jeden kleineren bis mittleren Server ausreichend sein. Haben Sie sehr viele SSH-Nutzer, können höhere Werte angebracht sein, etwa
Jenseits dieser Config-Parameter ist das A und O der Server-Sicherheit natürlich ein sicheres Passwort.
Solche Attacken sind nicht nur lästig, sie kosten durch die schiere Menge der Anfragen auch Netzwerk-Bandbreite und Rechenkapazitäten. Mit einfachen Mitteln kann man die eigene Secure Shell gegen solchen und ähnlichen Unfug sichern. Alle Einstellungen gehören in das sshd-Configfile, das normalerweise sshd_config heißt und im Verzeichnis /etc/ssh liegt.
Wir müssen bevor wir loslegen ein neuen User anlegen, bevor wir es losgeht.
adduser zwerg
Wir öffnen die Config Datei und bearbeiten sie.
nano /etc/sshd_config
1. Das ursprüngliche SSH-Protokoll Version 1 ist veraltet und hat einige bekannte Sicherheitsmängel. Deswegen sollte Ihr Server nur Protokoll-Version 2 zulassen. Die Zeile
Protocol 2
sorgt dafür.
2. Lange nicht alle Benutzer eines Servers müssen sich per SSH anmelden können. Der Parameter AllowUsers definiert, welche Nutzer erlaubt sind. Alle nicht genannten bleiben ausgesperrt. Beispiel:
AllowUsers root zwerg crew
Ob man den root-Login per SSH überhaupt zulässt, ist Glaubensfrage. Meiner Meinung nach spricht nichts dagegen, solange man ein solides Passwort für root definiert hat.
3. Kein Benutzer braucht ewig, um sich einzuloggen, also Benutzername und Passwort einzugeben. Jeder gestartete sshd-Task braucht aber Speicher und Rechenzeit. Also gibt man mit
LoginGraceTime 60
eine Minute Timeout vor. Hat sich 60 Sekunden nach Verbindungsstart noch niemand korrekt eingeloggt, wird der Task beendet.
Vorsicht: Natürlich ist hier auch ein noch kürzerer Wert möglich. Aber berücksichtigen Sie immer, daß Ihr Server auch einmal überlastet sein kann und die Kommunikation mit dem sshd deshalb verzögert wird. Da kann es äußerst lästig werden, wenn der Timeout zu schnell zuschlägt.
4. Um zu verhindern, daß durch einen Hackversuch hunderte sshd-Tasks gleichzeitig gestartet werden, gibt es einen sehr nützlichen Parameter. Fügen Sie dazu die Zeile
MaxStartups 3:30:10
in das Configfile ein.
Diese Beschränkung ist äußerst effektiv, aber etwas kompliziert zu verstehen: Die Werte im Beispiel bedeuten, daß 2 (= 1. Wert minus 1) "unauthenticated" (also im Login-Stadium befindliche) sshd-Verbindungen immer erlaubt sind. Ab der 3. (= 1. Wert) Verbindung wird mit einer Wahrscheinlichkeit von 30% (2. Wert) die Verbindung abgelehnt. Diese Wahrscheinlichkeit steigt linear an, bis bei 10 (3. Wert) offenen Verbindungen jeder weitere Verbindungsversuch zu 100% abgelehnt wird.
Achtung: Bereits eingeloggte Nutzer zählen nicht zu diesen Werten! Die angegebenen Beispielwerte sollten also für jeden kleineren bis mittleren Server ausreichend sein. Haben Sie sehr viele SSH-Nutzer, können höhere Werte angebracht sein, etwa
MaxStartups 10:30:50
Jenseits dieser Config-Parameter ist das A und O der Server-Sicherheit natürlich ein sicheres Passwort.
