Die Hacking-Frequenz ist in den letzten Monaten stark angestiegen. Besonders viele Daten werden abgegriffen durch Hacks auf Webserver. Sogar der SONY-PSN-Hack nutzte Schwachstellen in einem ungepatchten Apache-Webserver. Deshalb sammele ich hier Ma\u00dfnahmen, die den eigenen Server etwas sicherer gegen Angriffe von au\u00dfen machen k\u00f6nnen. Nat\u00fcrlich bieten auch diese keinen 100%igen Schutz, aber es ist besser, den b\u00f6sen Buben das Spiel ein wenig schwieriger zu machen. Einige der Ma\u00dfnahmen ben\u00f6tigen nur einen minimalen Installations- und Wartungsaufwand. Andere ben\u00f6tigen viel Zeit und Kenntnisse von PHP um zu greifen. Man sollte immer auf das Kosten-Nutzen-Verh\u00e4ltnis bei der Auswahl der Sicherheitsma\u00dfnahmen achten. Es macht keinen Sinn, eine kleine, private Website so abzusichern wie die Federal Reserve Bank. Allerdings k\u00f6nnen wenige gezielte \u00c4nderungen am System bereits ein gro\u00dfes Mehr an Sicherheit bedeuten. Und das sollte man sich schon g\u00f6nnen, bevor es zu sp\u00e4t ist….<\/p>\n
Alle Tipps und Codesnips beziehen sich auf eine aktuelle Debian-Kiste.<\/p>\n
1. Die Firewall – erst einmal alles verbieten<\/strong><\/p>\n Die meisten Linux-Distributionen \u00f6ffnen in ihren Standardinstallationen keine Ports nach au\u00dfen, die nicht unbedingt notwendig sind. Diese Situation kann man jedoch schnell selbst \u00e4ndern, wenn man am Server Dieses kleine Grundger\u00fcst kann man einfach weiter ausbauen und eigene Dienste hinzuf\u00fcgen. Bei Arbeiten an der Firewall sollte man immer f\u00fcr den Fall vorsorgen, dass man sich selbst aussperrt. Besonders bei Remote-Servern, auf die man keinen physischen Zugriff hat, ist es sehr \u00e4rgerlich, durch eine mi\u00dfgl\u00fcckte Firewallregel den eigenen Zugriff zu verlieren. Um diesem Problem aus dem Weg zu gehen, kann man bei Arbeiten an der Firewall einfach tempor\u00e4r einen Cronjob starten lassen, der die Firewall alle paar Minuten zur\u00fccksetzt oder den Server neu startet. Sind die Regeln sp\u00e4ter getestet und geliebt, kann der Cronjob wieder deaktiviert werden und die neuen Regeln bleiben permanent aktiv.<\/p>\n Um herauszufinden, welche Dienste gerade auf dem eigenen Server herumlauschen, kann man netstat benutzen:<\/p>\n Um zu testen ob die Firewall wirklich funktioniert, kann man den eigenen Server von einem anderen Rechner aus portscannen. Hat alles geklappt, sollten im Ergebnis nur die selbst ge\u00f6ffneten Ports auftauchen:<\/p>\n 2. SSH Logins verbieten<\/strong><\/p>\n Am eigenen root-Server hat man uneingeschr\u00e4nkten SSH-Zugriff. Das ist recht praktisch, da man von jedem SSH-Client aus mal eben auf den Server kann um an ihm zu arbeiten. Der Nachteil davon ist, dass das nat\u00fcrlich auch jeder andere kann, der ungl\u00fccklicher Weise irgendwie an das eigene Passwort gelangt ist. Es ist viel sicherer SSH-Logins nur mit einer g\u00fcltigen Schl\u00fcsseldatei zu erlauben. Daf\u00fcr wird der \u00f6ffentliche Schl\u00fcssel des Clients auf den Server kopiert und interaktive Logins per Passworteingabe werden deaktiviert.<\/p>\n Auch hier sollte man Vorkehrungen treffen, um sich nicht selbst auszusperren, falls etwas nicht funktioniert. 3. SSH Bruteforcing verhindern mit denyhosts <\/strong><\/p>\n Falls Tipp 2 nicht praktikabel ist und man den Komfort von passwortgest\u00fctzten Logins nicht aufgeben will, kann man zumindest das automatisierte Passwortraten von Angreifern auf dem Server verhindern. Sehr viele Bots im Internet machen den ganzen Tag nichts anderes als nach SSH-Servern zu suchen und bei Ihnen verschiedenste Passw\u00f6rter durchzuprobieren. Mit einem halbwegs sicheren Passwort ist das kein gro\u00dfes Problem, trotzdem gibt es ein besseres Gef\u00fchl, wenn nicht einmal das m\u00f6glich ist. Au\u00dferdem sch\u00fctzt man so auch seine User, falls auf dem Server auch Useraccounts bestehen. Hier kann man sich nicht darauf verlassen, dass die Benutzer sichere Passw\u00f6rter verwenden. denyhosts \u00fcberpr\u00fcft st\u00e4ndig Logins auf dem ssh und sperrt Benutzer f\u00fcr eine gewisse Zeit, die ihr Passwort wiederholt falsch angegeben haben. Die IP’s dieser Nutzer landen tempor\u00e4r in \/etc\/hosts.deny, so dass f\u00fcr sie kein Zugriff mehr m\u00f6glich ist. Damit wird SSH-Bruteforcing zu einer sehr langwierigen und wenig erfolgversprechenden Aufgabe.<\/p>\n
\nherumspielt und Dinge ausprobiert. Pl\u00f6tzlich lauscht auch der Mediaserver im Internet oder die Datenbank
\nnimmt Verbindungen aus dem Internet entgegen. Deshalb ist es nicht verkehrt sich selbst zu disziplinieren und eine sehr restriktive Firewall aufzusetzen, die grunds\u00e4tzlich erst einmal alle Verbindungen von au\u00dfen verbietet und nur (selbst) ausgew\u00e4hlte Verbindungen gestattet. Zum Gl\u00fcck ist das mit iptables schnell erledigt. Auf diese Art und Weise kann man nicht mehr aus versehen Dienste der Welt zug\u00e4nglich machen, die dort nichts zu suchen haben. Man bezahlt leider mit etwas Komfort – die Firewall muss jedes Mal angepasst werden, wenn man neue Dienste anbieten m\u00f6chte. Trotzdem ist der Aufwand klein und der Nutzen gro\u00df.<\/p>\n#!\/bin\/bash\r\n# Bestehende Tables l\u00f6schen\r\niptables -F\r\n\r\n# Alle eingehenden Verbindungen verbieten\r\niptables -P INPUT DROP\r\niptables -P FORWARD DROP\r\n\r\n# Alle ausgehenden erlauben\r\niptables -P OUTPUT ACCEPT\r\n\r\n# SSH erlauben\r\niptables -A INPUT -j ACCEPT -p tcp --dport 22\r\n\r\n# HTTP erlauben\r\niptables -A INPUT -j ACCEPT -p tcp --dport 80\r\n\r\n# Weiteren Dienst (UDP) erlauben, zum Beispiel Gameserver\r\niptables -A INPUT -j ACCEPT -p udp --dport 4534\r\n\r\n# Alles von Localhost erlauben. (Damit der Server selbst ungehindert auf seine Dienste zugreifen kann,\r\n# zum Beispiel PHP auf die lokale Datenbank\r\niptables -A INPUT -j ACCEPT -s 127.0.0.1\r\n\r\n# Bereits aufgebaute Verbindungen werden an jedem Port akzeptiert\r\n# (Damit Antworten auf Anfragen, die vom Server kommen immer zur\u00fcckkommen k\u00f6nnen)\r\niptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT\r\n\r\n<\/pre>\n
#F\u00fcr TCP-Sockets:\r\nnetstat -lpn | grep tcp\r\n\r\n#Analog f\u00fcr UDP:\r\nnetstat -lpn | grep udp\r\n<\/pre>\n
#F\u00fcr TCP:\r\nnmap -p1-65535 meinserver.de\r\n#F\u00fcr UDP:\r\nnmap -sU -p1-65535 meinserver.de\r\n<\/pre>\n
# Auf dem Client einen \u00f6ffentlichen Schl\u00fcssel erstellen\r\n# Wird bei der Generierung ein Passwort angegeben, ben\u00f6tigt man zum\r\n# einloggen sp\u00e4ter die Schl\u00fcsseldatei UND das Passwort. Ansonsten wird\r\n# nur der Schl\u00fcssel ben\u00f6tigt.\r\n\r\nssh-keygen -t rsa\r\n\r\n# Den erstellten Schl\u00fcssel danach auf den Server kopieren\r\n\r\nssh-copy-id -i ~\/.ssh\/id_rsa.pub root@meinserver.de\r\n\r\n# Danach auf dem Server \/etc\/ssh\/sshd_config anpassen\r\n.\r\n.\r\nPasswordAuthentication no\r\n.\r\n.\r\n\r\n# Danach SSh neu starten\r\n\/etc\/init.d\/ssh restart<\/pre>\n
\nDer Public Key auf einem USB-Stick mit dem dazugeh\u00f6rigen Passwort im eigenen Kopf macht es sehr viel schwerer f\u00fcr b\u00f6se Buben eine Shell zu erhalten.<\/p>\napt-get install denyhosts\r\n\r\n# denyhosts funktioniert direkt nach der Installation. Man kann es\r\n# in der Datei \/etc\/denyhosts.conf feintunen<\/pre>\n