Apache Webserver absichern

    • Offizieller Beitrag

    Hallo Leute,

    ich bin langjähriger Linux Nutzer und habe daher schon eine gewisse Erfahrung, jedoch bin ich momentan in der Situation, dass ich zum ersten mal einen Server (>meinen Raspberry Pi) selbst betreibe und völlig selbstständig verwalte und konfiguriere.

    Auf meinem Raspeberry läuft momentan eine Instanz Tiny Tiny Rss und eine Instanz ownCloud.
    Damit diese beiden Programme funktionieren habe ich Apache, Mysql und Php installiert. Desweiteren läuft natürlich noch ssh, das der Pi headless betrieben wird. Ich habe meinen Router so konfiguriert, dass er mit No-Ip kommuniziert, da ich standardmäßig nur eine dynamische IP habe, ferner ist eine Portweiterleitung aktiv. Allerdings ausschließlich für Port 80 d.h SSH ist extern nicht erreichbar.


    Da ich wie gesagt was das Selbsthosten beitrift, gerade erst meine Jungfräulichkeit verloren habe, habe ich die Sorge, dass irgendjemand meinen Server kompromittieren.

    Leider konnte ich hier im Forum noch kein dediziertes Thema finden was sich mit dem Thema Apache-Sicherheit beschäftigt.

    So viel zu meiner Grundsituation - Wie mache ich den Pi jetzt wirklich sicher?

    Ist es sinnvoll iptables so zu konfigurieren, dass erstmal außer der Port 80 für Apache (und eventuell Port 22 für SSH) alles blockiert wird?

    Auf Ubuntuusers bin ich auf folgenden WIki-Artikel gestoßen: http://wiki.ubuntuusers.de/Apache/Sicherheit
    Welche dieser Module sind für mich wirklich sinnvoll? Gerdae mod security erscheint mir recht komplex zu sein, lohnt der Aufwand?

    Macht es sind open_basedir zu verwenden? Wie muss ich es konfigurieren damit TTRSS und owncloud problemlos funktionieren?

    Ferner habe ich bereits in /etc/apache2/conf.d/security ServerSignature Off aktiviert und folgende Apache Module deaktiviert: mod_cgi, mod_status und mod_autoindex.

    Code
    netstat -lpn | grep tcp


    ergibt:

    Zitat


    tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2460/mysqld
    tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 9754/apache2
    tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2168/sshd


    Sieht soweit gut aus oder?

    Über weitere Ansätze um das System zu härten wäre ich sehr sehr dankbar.

    Liebe Grüße :heart::danke_ATDE:


  • Hallo Leute,

    Ist es sinnvoll iptables so zu konfigurieren, dass erstmal außer der Port 80 für Apache (und eventuell Port 22 für SSH) alles blockiert wird?

    Da Du von extern nur ja nur an den Raspberry weiterleitest sollte von extern keiner über ssh oder MySQL zu verbinden. Der MySQL Server lauscht ja eh auf 127.0.0.1 / Localhost und kann selbst von anderen im Netzwerk nicht angesprochen werden.

    Du könntest noch in der /etc/ssh/sshd_config Listen noch auf die interne IP setzen, so das auch der Zugriff, sollte jemand es schaffen SSH extern nach intern auf den PI zu leiten. Ich sag nur uPNP und andere Sicherheitslücken in DSL-/Cable-Routern. Manche werden jetzt vielleicht denken: "Immer diese Paranoia", aber wenn man sich die ganzen Router und andere Geräte im Heimnetzwerken anguckt wird man denen nicht mehr trauen.

    Wenn Du zusätzlich auch noch per iptables blocken willst:

    Code
    iptables -A INPUT -p TCP -s ! 192.168.178.0/24 --dport 22 -j LOG --log-prefix "BLOCKED: "
    iptables -A INPUT -p TCP -s ! 192.168.178.0/24 --dport 22 -j REJECT

    Damit werden z.B. alle SSH Zugriffe von IPs ausserhalb Deines Netzwerkes geloggt und dann rejected. Also falls es jemand schaffen soll die Ports umzubiegen kannst Du es o zusätzlich auch noch mal abfangen. Das Loggen deswegen weil Du es dann wenigstens sehen kannst und durch weitere Tools, Scripte usw. dann auch alarmieren lassen kannst oder weitere Massnahmen, wie z.B. automatischen Panik Shutdown ;)

    Zitat


    Auf Ubuntuusers bin ich auf folgenden Wiki-Artikel gestoßen: http://wiki.ubuntuusers.de/Apache/Sicherheit
    Welche dieser Module sind für mich wirklich sinnvoll? Gerdae mod security erscheint mir recht komplex zu sein, lohnt der Aufwand?

    ls auf /etc/apache2/modules-enabled damit wir sehen welche Module überhaupt geladen werden.

    Sicherheit ist meistens etwas komplexer, das sollte einen aber nicht abhalten es einzusetzen.

    Zitat


    Macht es sind open_basedir zu verwenden? Wie muss ich es konfigurieren damit TTRSS und owncloud problemlos funktionieren?

    Ja, das macht Sinn, damit keiner ausserhalb des Webroots auf Dateien zugreifen oder welche ausserhalb ablegen kann.

    Zitat
    Code
    netstat -lpn | grep tcp


    ergibt:

    Code
    tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      2460/mysqld     
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      9754/apache2    
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2168/sshd


    Sieht soweit gut aus oder?

    Yep, wie schon geschrieben ggf. noch den SSH auf die interne IP binden.

    Zitat


    Über weitere Ansätze um das System zu härten wäre ich sehr sehr dankbar.

    Guck Dir ggf. auch mal so Sachen wie Fail2Ban an. Das kann man auch für den Apache benutzen. Und falls Du irgend wann einmal SSH von extern erreichbar machen willst kann das auch gleich Angriffe gegen SSH auch abfangen.
    Bei SSH Authentification per SSH-Keys mal angucken, wenn der Login per Key klappt auf Key Only umstellen.

    Root Login verbieten und einen extra User anlegen und den bei ssh in AllowUsers eintragen. Dann aber auch sudoers nicht vergessen den User das sudo zu erlauben.

    Code
    PermitRootLogin no
    AllowUsers DEINUSERNAME


    Zitat


    Liebe Grüße

    • Offizieller Beitrag

    Erstmal Danke für die ausführliche Antwort. :danke_ATDE:


    Da Du von extern nur ja nur an den Raspberry weiterleitest sollte von extern keiner über ssh oder MySQL zu verbinden. Der MySQL Server lauscht ja eh auf 127.0.0.1 / Localhost und kann selbst von anderen im Netzwerk nicht angesprochen werden.

    Du könntest noch in der /etc/ssh/sshd_config Listen noch auf die interne IP setzen, so das auch der Zugriff, sollte jemand es schaffen SSH extern nach intern auf den PI zu leiten. Ich sag nur uPNP und andere Sicherheitslücken in DSL-/Cable-Routern. Manche werden jetzt vielleicht denken: "Immer diese Paranoia", aber wenn man sich die ganzen Router und andere Geräte im Heimnetzwerken anguckt wird man denen nicht mehr trauen.

    Wenn Du zusätzlich auch noch per iptables blocken willst:

    Code
    iptables -A INPUT -p TCP -s ! 192.168.178.0/24 --dport 22 -j LOG --log-prefix "BLOCKED: "
    iptables -A INPUT -p TCP -s ! 192.168.178.0/24 --dport 22 -j REJECT

    Damit werden z.B. alle SSH Zugriffe von IPs ausserhalb Deines Netzwerkes geloggt und dann rejected. Also falls es jemand schaffen soll die Ports umzubiegen kannst Du es o zusätzlich auch noch mal abfangen. Das Loggen deswegen weil Du es dann wenigstens sehen kannst und durch weitere Tools, Scripte usw. dann auch alarmieren lassen kannst oder weitere Massnahmen, wie z.B. automatischen Panik Shutdown ;)


    Dabei brauche ich nochmal hilfe. Der Versuch Port 22 auf das Lokale Netzwerk zu begrenzen liefert nur folgendes

    Zitat


    Bad argument `192.168.178.0/24'

    ls auf /etc/apache2/modules-enabled damit wir sehen welche Module überhaupt geladen werden.

    Sicherheit ist meistens etwas komplexer, das sollte einen aber nicht abhalten es einzusetzen.


    Ja, das macht Sinn, damit keiner ausserhalb des Webroots auf Dateien zugreifen oder welche ausserhalb ablegen kann.


    An verwendeten Apache-Modulen wäre da:

    Zu open_basedir, wäre das so richtig?

    Code
    #/etc/php5/apache2/php.ini
    open_basedir = /var/www/:/tmp/
    
    
    php_value open_basedir /var/www/site/:/tmp/


    Guck Dir ggf. auch mal so Sachen wie Fail2Ban an. Das kann man auch für den Apache benutzen. Und falls Du irgend wann einmal SSH von extern erreichbar machen willst kann das auch gleich Angriffe gegen SSH auch abfangen.
    Bei SSH Authentification per SSH-Keys mal angucken, wenn der Login per Key klappt auf Key Only umstellen.

    Root Login verbieten und einen extra User anlegen und den bei ssh in AllowUsers eintragen. Dann aber auch sudoers nicht vergessen den User das sudo zu erlauben.

    Code
    PermitRootLogin no
    AllowUsers DEINUSERNAME

    Fail2Ban sehe ich mir mal an. Was sagst du zu denyhosts?
    Auch um die Geschichte mit dem ssh-Key kümmere ich mich morgen mal.
    Den Tipp bezüglich des Root-Users hatte ich schon umgesetzt.

    Der Befehl

    Code
    netstat -lpn | grep udp


    ergibt übrigens

    Zitat


    udp 0 0 192.168.2.117:123 0.0.0.0:* 2060/ntpd
    udp 0 0 127.0.0.1:123 0.0.0.0:* 2060/ntpd
    udp 0 0 0.0.0.0:123 0.0.0.0:* 2060/ntpd
    udp 0 0 0.0.0.0:64322 0.0.0.0:* 1889/dhclient
    udp 0 0 0.0.0.0:68 0.0.0.0:* 1889/dhclient

    Ist das soweit auch Ok?

    Zitat

    Liebe Grüße


    Ich würd erstmal fragen was Du wovor absichern möchtest ?

    Willst du nur erreichen das du der einzige bist der von Unterwegs auf dein RPI-Webserver zugreifen kann?

    Auch danke für deine Antwort.
    Meine grundsetzliche Zielsetzung ist prinzipiell meinen Raspberry Pi vor missbrauch zu schützen, ferner will ich natürlich auch verhindern, dass irgendjemand an meine ownCloud kommt, bei meinen Feeds wäre mir das noch egal.
    Wenn das als bedeutet, den Raspberry so zu konfigurieren, dass niemand außer mir von unterwegs auf den Raspberry Pi zugreifen kann, dann ist das ein klares Jahr.

    Lieben Gruß:thumbs1:

  • Nunja, ich weiss nicht genau ob man soviel Aufwand betreiben muss wie ihn ruedigerp beschreibt

    Zunächst solltest du die externen Port, also jene die übers Internet angesprochwn werden, nicht auf standard Ports setzen - am besten auf irgendwas ausgedachtes wie zB 12312 ... Dann wäre es schonmal schwieriger für jemand fremden zum einen diesen Port zu finden und zum anderen diesen auch als Web-Port zu identifizieren - weil wenn ich einen Port 80 finde gehe ich erstmal davon aus das es sich um http handelt ;)

    Und dan kann man apache2 auch so konfigurieren das nur der Zugriff von einer bestimmten DynDNS erlaubt ist - über /etc/apache2/sites-enabled/default

    Dann wär die Frage was ausserdem geschützt werden müsste?


    PS: fail2ban ist wesendlich mächtiger als denyhosts da es ua. auch andere Dienste überwachen kann, muss aber auch vernünftig konfiguriert werden


  • Wenn Du zusätzlich auch noch per iptables blocken willst:

    Code
    iptables -A INPUT -p TCP -s ! 192.168.178.0/24 --dport 22 -j LOG --log-prefix "BLOCKED: "
    iptables -A INPUT -p TCP -s ! 192.168.178.0/24 --dport 22 -j REJECT


    Dabei brauche ich nochmal hilfe. Der Versuch Port 22 auf das Lokale Netzwerk zu begrenzen liefert nur folgendes

    Code
    Bad argument `192.168.178.0/24'


    Der Fehler bezieht sich jetzt auf iptables? ok das ! muss vor das -s, alte Gewohnheit das war früher andersrum ;)

    Code
    iptables -A INPUT -p TCP ! -s 192.168.178.0/24 --dport 22 -j LOG --log-prefix "BLOCKED: "
    iptables -A INPUT -p TCP ! -s 192.168.178.0/24 --dport 22 -j REJECT
    Zitat von Lars


    An verwendeten Apache-Modulen wäre da:

    Code
    alias.conf            authz_user.load  mime.conf         reqtimeout.conf
    alias.load            deflate.conf     mime.load         reqtimeout.load
    auth_basic.load       deflate.load     negotiation.conf  rewrite.load
    authn_file.load       dir.conf         negotiation.load  setenvif.conf
    authz_default.load    dir.load         perl.load         setenvif.load
    authz_groupfile.load  env.load         php5.conf
    authz_host.load       headers.load     php5.load

    Benutzt Du Perl? Falls nicht kannst Du das Module deaktivieren. Das wird sehr wahrscheinlich eh nicht angesprochen, aber jedes Modul braucht ja auch Speicher vom RAM, daher kann man das getrost deaktivieren, da der PI ja nicht viel davon hat. Kleinvieh mach auch Mist. Wie gesagt Sicherheit erhöht es jetzt nicht, da standardmäßig keine Directive in der Config Aktiv ist die Perl ansprechen würde.

    Zitat von Lars


    Macht es sind open_basedir zu verwenden? Wie muss ich es konfigurieren damit TTRSS und owncloud problemlos funktionieren?


    Ja, das macht Sinn, damit keiner ausserhalb des Webroots auf Dateien zugreifen oder welche ausserhalb ablegen kann.

    Zitat von Lars


    Zu open_basedir, wäre das so richtig?

    Code
    #/etc/php5/apache2/php.ini
    open_basedir = /var/www/:/tmp/
    
    
    php_value open_basedir /var/www/site/:/tmp/


    [/code]

    Ja kann man so machen, ggf. das /tmp/ noch in /var/www/phptmp anlegen und das konfigurieren. Du könntest auch pro Site/Anwendung noch trennen. Da Du alleine auf dem Server bist kannst Du es aber ruhig für alle Sites allgemein machen. Falls Du mal etwas für andere mit anbieten will, Google Reader ist tot und wenn Dein RSS-Feed-Reader auch für 1-2 Bekannte angeboten werden sollte kannst Du bzw. solltest Du das ggf. dann pro Site machen.

    Zitat von lars


    Fail2Ban sehe ich mir mal an. Was sagst du zu denyhosts?

    Dazu hat Margrafd ja schon was geschrieben.

    Brauchst Du echt einen ntp (Zeitserver auf dem PI)?
    Da dhclientd läuft gehe ich davon aus das Du den PI keine feste IP gegeben hast. Das würde ich noch ändern so das er immer die gleiche hat. Oder falls der Router es kann, dem Router sagen er soll dem PI immer die gleiche zuweisen. Der Router erkennt ihn dann an der MAC-Address.

    Dann kannst Du Dir beide Dienste sparen. 1. wieder wegen Speicher und 2. könnten da auch Sicherheitslücken drin sein die ausgenutzt werden können. Alles unnötige ausschalten.


    Zitat von meigrafd


    Nunja, ich weiss nicht genau ob man soviel Aufwand betreiben muss wie ihn ruedigerp beschreibt

    Wenn man überlegt und es auch kennt was möglich ist und was Angreifer auf Systemen so alles ausnutzen, dann wird man über die Sachen anders denken.
    Man muß ja nicht unbedingt alles davon machen, aber er ist in diesem Bereich gerade neu und daher ist es wohl angebracht Hinweise zu geben was Einfallstore sind und wie man sie nach Möglichkeit schliessen kann. Wenn das Kind in den Brunnen gefallen ist, ist es zu spät. So hat er es wenigstens mal alles gehört und bei Bedarf wird er sich vielleicht dran erinnern und weiß wo er dazu noch mal genauere Infos bekommt.

    Zitat von meigrafd


    Zunächst solltest du die externen Port, also jene die übers Internet angesprochwn werden, nicht auf standard Ports setzen - am besten auf irgendwas ausgedachtes wie zB 12312 ... Dann wäre es schonmal schwieriger für jemand fremden zum einen diesen Port zu finden und zum anderen diesen auch als Web-Port zu identifizieren - weil wenn ich einen Port 80 finde gehe ich erstmal davon aus das es sich um http handelt Icon_wink

    Ich wiederhole mich da gerne noch einmal das ist Security by Obscurity und bringt meistens ... nix.
    Ein Portscann dauert nicht lange, das Ergebnis wird meistens auch nicht viele Ports ergeben. Die Liste Parsen und dann an den offenen genau gucken was dahinter steckt ist simple. Dafür gibt es haufenweise Scripte, die so auf einem offenen Port mehrere Tests machen um die richtige Anfrage an den Dienst dahinter zu senden, der dann bestimmte Ausgaben oder Fehler zurückgibt, die auf den genauen Dienst hinweisen.
    Zur Not sind solche Scripte auch schnell selbst gemacht. Wer eindringen will hat oder macht sich die Werkzeuge dafür.

    Du versuchst nur etwas zu verschleiern, mehr aber auch nicht.

    Zitat von meigrafd


    Und dan kann man apache2 auch so konfigurieren das nur der Zugriff von einer bestimmten DynDNS erlaubt ist - über /etc/apache2/sites-enabled/default

    Er meinst damit Deny/Allow Directiven die in dieser Datei, generell gesetzt für einen vhost, einzeln Location usw. gesetzt werden können.

    Nachteil in Deinem Fall würde ich mal behaupten: Da Du Owncloud benutzt willst Du sehr wahrscheinlich auch Mobil zu greifen. Einige Provider benutzen NAT im Mobilen Netz, sehr viele Clients kommen so über ein und das selbe NAT-Gateway. Heisst: Ein Haufen der Kunden dieses Anbieters kommen mit der gleichen IP. Wenn nicht, dann musst Du eh die kompletten DailUp Netze freischalten und das sind bei einigen Anbietern alleine schon eine Menge. Ok, damit verringert man die Anzahl Möglichen Angreifer, aber dabei sind einige Punkte zu beachten.

    1. Netze verändern sich. Umstrukturierungen bei Anbietern. Anbieter oder Teile werden verkauft, gekauft usw.
    2. Du musst wirklich alle Netze kennen, durch Wachstum eines Anbieters können ein oder mehrere Netzbereiche dazu kommen. Wenn Du es nicht kennst und davon dann auch noch eine IP bekommst sperrt man sich selbst aus.
    3. Viele Angriffe kommen genau aus solchen Netzen.

    usw. usw. Also muss man eh noch andere Sachen machen und selbst Hand anlegen. Dann kann man es auch gleich richtig machen. muß man ja eh. Alles andere ist Pseudo-Security, nur um das Gewissen zu beruhigen. Man verarscht sich nur selbst und möglicherweise andere.

  • Ich finde das trotzdem etwas übertrieben für einen Privaten Internet-Anschluss... Wenn es sich um einen Internet-Server handeln würde, veranstalte ich auch solch einen Aufwand aber nicht zuhause ;)

    Desweiteren versteh nicht wieso du 192.168.178.0/24 rejectest - zum einen erzeugt das unnötig traffic (wegen des rejects also Zurückweisung an den Client, da würd ich stattdessen lieber DROP nutzen) und zum anderen ergibt das ja auch eigentlich kein Sinn weil bei dem sperren von 192.168.178.0/24 dann auch jeder andere Rechner in seinem LAN ausgesperrt wird oder nicht? Wofür dann überhaupt noch SSH nutzen? :-/

    Wenn es keine Portweiterleitung gibt hat ein möglicher Angreifer auch keine Chance in sein LAN einzudringen - ein Router ist sozusagen eine Hardware Firewall die nichts rein lässt solange man das nicht einstellt.. Desweiteren kann niemand (auch nicht über UMTS) die LAN-IPs ansprechen geschweigedenn herrausfinden auf welcher LAN-IP möglicherweise ein RaspberryPI läuft

    Wenn dem so wäre, wären ALLE Internetnutzer weltweit potentiell gefärdert und müssten ebenfals solche Massnahmen durchführen usw was aber irgendwie nicht der Fall ist :huh:


    Will mich da aber auch nicht drüber streiten!


    Nichts gegen deine Kompetenz oder dein Fachwissen oder deine Bereitschaft ausführlich zu helfen, aber trotzdem glaub ich halt dass das etwas übertrieben ist und stattdessen auch leichter geregelt werden könnte


    Wir könn auch gerne ein Test machen: ich geb dir/euch meine aktuelle Internet-IP und derjenige der es schafft mein LAN oder meinen RPI zu hacken dem spendier ich eine Kiste Bier :)
    77.23.31.132
    Es ist nur der Web-Port weitergeleitet, aber eben auf einem beliebigem Port.. Ansonsten keinerlei Schutzmassnahmen (hab das System heute morgen neu geflasht)
    Als Beweis sollte mir derjenige sagen wie die LAN-IP meines RaspberryPI's und meines Windows-PC's sowie der Begrüssungstext vom Webserver ist ;) Nur der Begrüssungstext des Webservers würde nicht reichen um ein "Eindringen" nachzuweisen


    PS: Ich idle auch den ganzen Tag im IRC (oben rechts auf IRC-Channel) falls Fragen oä. sind :)


  • Ich finde das trotzdem etwas übertrieben für einen Privaten Internet-Anschluss... Wenn es sich um einen Internet-Server handeln würde, veranstalte ich auch solch einen Aufwand aber nicht zuhause ;)

    Um es mal deutlich zu fragen. Wo ist der Unterschied zwischen einem "Internet"-Server und einem Server zuhause?
    Es ist in beiden Fällen eine IP erreichbar, auf der Ports offen sind, hinter denen ein Dienst läuft. Wenn beide gleiche Hardware haben, gleiches OS, der Dienst der gleiche ist und auch gleich konfiguriert, dann ist es egal ab es ein Server im Rechenzentrum ist oder in einem Heimnetzwerk hinter DSL. Für einen Angreifer ist es egal, wobei bei solchen Aussagen es sehr wahrscheinlich einfacher ist auf Rechner hinter DSL Anschlüssen einzudringen.


    Desweiteren versteh nicht wieso du 192.168.178.0/24 rejectest - zum einen erzeugt das unnötig traffic (wegen des rejects also Zurückweisung an den Client, da würd ich stattdessen lieber DROP nutzen) und zum anderen ergibt das ja auch eigentlich kein Sinn weil bei dem sperren von 192.168.178.0/24 dann auch jeder andere Rechner in seinem LAN ausgesperrt wird oder nicht? Wofür dann überhaupt noch SSH nutzen? :-/

    Bitte richtig lesen da steht "! -s ..." Alles was nicht 192.168.178.0/24 ist soll rejected werden.
    Und nein, DROP will man da nicht benutzen.
    Konfiguration einer Firewall, so dass Anfragen auf Ports still verworfen (DROP) statt ablehnend beantwortet (REJECT) werden, führen zu einem anderen Ergebnis. nmap oder telnet und guck mal was der Unterschied ist. Beim Drop erkennt man das da etwas sein könnte. Weckt also unter Umständen das Interesse doch noch Weg zu finden.


    Wenn es keine Portweiterleitung gibt hat ein möglicher Angreifer auch keine Chance in sein LAN einzudringen - ein Router ist sozusagen eine Hardware Firewall die nichts rein lässt solange man das nicht einstellt.. Desweiteren kann niemand (auch nicht über UMTS) die LAN-IPs ansprechen geschweigedenn herrausfinden auf welcher LAN-IP möglicherweise ein RaspberryPI läuft

    Wenn dem so wäre, wären ALLE Internetnutzer weltweit potentiell gefärdert und müssten ebenfals solche Massnahmen durchführen usw was aber irgendwie nicht der Fall ist :huh:

    Ich erwähnt mal dezent D-Link DR-XXX, davon waren und sind aktuell noch 12000 Geräte im Netz betroffen. Auf diese DSL-Router einzudringen ist ein Kinderspiel. uPNP und Co sind da immer wieder Einfallstor um sich mal eben eine Weiterleitung von aussen nach drinnen zu Bohren. Einen Telnet Dienst auf diesen, wie auch auf anderen Routern von aussen auf den Kisten aufzuspielen und zu starten ist möglich. Damit dann /var/passwd auslesen, in der das Admin Password leider im Klartext steht und dann über das Webinterface einloggen und schon kann man alles machen.


    Will mich da aber auch nicht drüber streiten!

    Streiten nicht, aber diskutieren ;)


    Wir könn auch gerne ein Test machen: ich geb dir/euch meine aktuelle Internet-IP und derjenige der es schafft mein LAN oder meinen RPI zu hacken dem spendier ich eine Kiste Bier :)
    77.23.31.132
    Es ist nur der Web-Port weitergeleitet, aber eben auf einem beliebigem Port.. Ansonsten keinerlei Schutzmassnahmen (hab das System heute morgen neu geflasht)
    Als Beweis sollte mir derjenige sagen wie die LAN-IP meines RaspberryPI's und meines Windows-PC's sowie der Begrüssungstext vom Webserver ist ;) Nur der Begrüssungstext des Webservers würde nicht reichen um ein "Eindringen" nachzuweisen

    Mach lieber mal ein Update bei Deinem Apache, die eingesetzte Version hat 7 Sicherheitslücken und ja mit der einen könnte man sogar mit einem Request Dein Netz intern Scannen.

  • Ich sehe da is jemand durstig :)


    Der Unterschied zwischen einem Privaten und einem Internet - Server besteht in der Anbindung:

    * Zuhause ist ein Router davor geschaltet, die i.d.R. sicher sind (bisauf sehr seltene Ausnahmen) - was bei einem Internetserver aber nur sehr sehr selten der Fall ist (abgesehen von Firmen-Servern)

    * Desweiteren sind Internetserver wesendlich schneller angebunden, meistens mit 100 MBit teilweise sogar mit 1 GBit oder sogat 10 GBit - damit lässt sich natürlich viel mehr Unfug anstellen als nur mit 1 bis 16 MBit :D

    * Internetserver haben keine Zwangstrennung und werden auch eher sehr sehr selten neu gestartet oder sogar ausgeschaltet, wären also tatsächlich 24/7/365 online - was nochmals die Einsatzmöglichkeit bzw den Unfug-Faktor steigert

  • Zu Routern: Sicherheitslücken in Routern sind leider keine Seltenheit.

    Zur Anbindung:
    Wenn es mit nur darum ginge Rechner dazu benutzen um per dDos anderer Webserver auszunoggen, reicht sogar UTMS aus. Halb offene Verbindungen bis max. Connecttion der Config greift oder bis der IP-Stack nicht mehr kann.

    Zur Zwangtrennung:
    Wenn man eingedrungen ist und erkennt das ein Rechner am DailUp hängt kann man genug Maßnahmen ergreifen um mit zubekommen wie seine neue IP ist.

  • Zu Routern: Von 100 verschiedenen Routern haben meinetwegen 5 ein Sicherheitsproblem - das ist wie ich finde schon eine eher kleine Anzahl

    Zur Anbindung: Hohe Bandbreite bedeutet nicht das man mit der Kiste nur DDoSen will ;) Da gibts etlich andere Dinge die für eine hohe Bandbreite nützlich ist (Stichwort: Warez)

    Zur Zwangstrennung: Klar gibts viele Massnahmen immer die aktuelle IP zu haben aber der Verbindungsabbruch ansich ist das was stören würde :D


    Aber nun gut, das wird hier langsam offtopic

    • Offizieller Beitrag

    Bitte richtig lesen da steht "! -s ..." Alles was nicht 192.168.178.0/24 ist soll rejected werden.
    Und nein, DROP will man da nicht benutzen.
    Konfiguration einer Firewall, so dass Anfragen auf Ports still verworfen (DROP) statt ablehnend beantwortet (REJECT) werden, führen zu einem anderen Ergebnis. nmap oder telnet und guck mal was der Unterschied ist. Beim Drop erkennt man das da etwas sein könnte. Weckt also unter Umständen das Interesse doch noch Weg zu finden.

    Ich hab das ganze so tatsächlich jetzt mal umgesetzt, da mir das auch noch eigener Recherche richtig erschien.
    Leider komme ich jetzt tatsächlich auch vom lokalen Netzwerk aus nicht mehr per SSH auf mein PI.

  • Lars: Das ! ist aber mit drin? Da Du "auch" geschrieben hast, gehe ich davon aus, dass Du es sowohl von außen als auch von innen probiert hast.

    Nur, um hier trotz OT mal ruedigerp zu unterstützen: JEDER Rechner, der von außen erreichbar ist, gehört vernünftig abgesichert. Dazu gehört in der Tat, Privatrechner oder nicht, ein schlüssiges Sicherheitskonzept. Ja, jeder Internetnutzer weltweit ist potenziell gefährdet, ich habe keine Ahnung warum Du das per se ablehnst...

    Alles was vorgeschlagen wurde, ist sinnvoll, richtig und mit verhältnismäßig geringem Aufwand umsetzbar. Portwechsel-Obscurity bringt keinen Schutz im eigentlichen Sinne und gehört definitiv NICHT zu den Vorschlägen, die bei konkreten Nachfragen zum Hardening überhaupt erwähnt werden sollten, da es unerfahrene Nutzer in tatsächlich nicht vorhandener Sicherheit wiegen kann.

    Ich habe übrigens auch am Privatrechner und auch auf Nicht-Standard-Ports monatlich eine niedrige vierstellige Anzahl an Zugriffsversuchen. Böse Zungen behaupten: Wer in den Logs keine auffälligen Einträge in großer Menge sieht, der sieht aus einem ganz bestimmten Grund keine ;)

    Einmal editiert, zuletzt von DCSH (11. September 2013 um 08:43)

  • Ich lehne es nicht ab - ich hab auch nie gesagt das es NICHT abgesichert werden sollte -- ich sagte jegendlich das die Massnahmen aus meiner Sicht übertrieben wären

    Es gibt verschiedene Massnahmen und wenn ihr meine Posts vernünftig lest werdet ihr feststellen das ich vom TE erstmal genauere Details erfragt habe bevor ich detailierter darauf eingehen wollte um hier keinen Roman schreiben zu müssen! Und nachfolgende Beiträge zeigen auch auf wieso ich die Massnahmen als übertrieben empfunden habe...

    • Offizieller Beitrag


    Lars: Das ! ist aber mit drin? Da Du "auch" geschrieben hast, gehe ich davon aus, dass Du es sowohl von außen als auch von innen probiert hast.

    Nur, um hier trotz OT mal ruedigerp zu unterstützen: JEDER Rechner, der von außen erreichbar ist, gehört vernünftig abgesichert. Dazu gehört in der Tat, Privatrechner oder nicht, ein schlüssiges Sicherheitskonzept. Ja, jeder Internetnutzer weltweit ist potenziell gefährdet, ich habe keine Ahnung warum Du das per se ablehnst...

    Alles was vorgeschlagen wurde, ist sinnvoll, richtig und mit verhältnismäßig geringem Aufwand umsetzbar. Portwechsel-Obscurity bringt keinen Schutz im eigentlichen Sinne und gehört definitiv NICHT zu den Vorschlägen, die bei konkreten Nachfragen zum Hardening überhaupt erwähnt werden sollten, da es unerfahrene Nutzer in tatsächlich nicht vorhandener Sicherheit wiegen kann.

    Ich habe übrigens auch am Privatrechner und auch auf Nicht-Standard-Ports monatlich eine niedrige vierstellige Anzahl an Zugriffsversuchen. Böse Zungen behaupten: Wer in den Logs keine auffälligen Einträge in großer Menge sieht, der sieht aus einem ganz bestimmten Grund keine ;)

    Ich bin mir ziemlich sicher dass ich das ! mit drin hatte, ich hab die Regel jetzt erstmal einfach wieder entfernt.

    Nur mal aus Interesse, für was setzt du den Rechner ein?


  • Ich bin mir ziemlich sicher dass ich das ! mit drin hatte, ich hab die Regel jetzt erstmal einfach wieder entfernt.

    Nur mal aus Interesse, für was setzt du den Rechner ein?

    Und nach dem Entfernen funktioniert es wieder? Dann war entweder das ! nicht mit drin, oder der IP-Bereich, aus dem Dein SSH-Zugriff tatsächlich erfolgt, lag nicht im 192.168.178er Bereich?

    Einsatz meines pi - nichts spektakuläres dabei:
    - hosted OwnCloud (allerdings mit nginx statt apache)
    - dient als OpenVPN-Server, damit ich im Ausland und auf Dienstreise eine sichere, verschlüsselte Internetverbindung nutzen kann
    - dient als squid-Proxy für meine Android-Endgeräte im WLAN und filtert dabei zuverlässig Werbung raus
    - dient als NAS und lässt mich über Samba externe Festplatten ansteuern
    - bringt einen alten USB-Laserdrucker via CUPS ins WLAN
    - erledigt nachts stromsparend große/langwierige Downloads via wget-Dateiliste

    Einmal editiert, zuletzt von DCSH (11. September 2013 um 12:10)

    • Offizieller Beitrag

    Ich lasse das Thema hier nochmal wieder aufleben, weil ich in meinem access log was gefunden hab was ich mir nicht erklären kann und mir etwas sorgen macht.

    Zitat


    111.241.35.9 - - [16/Sep/2013:04:26:27 +0200] "GET http://www.google.com/intl/zh-CN/ HTTP/1.1" 404 568 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.$
    111.241.35.9 - - [16/Sep/2013:04:26:27 +0200] "CONNECT mx0.mail2000.com.tw:25 HTTP/1.0" 200 5768 "-" "-"

    Das ganze taucht so oder so ähnlich alles 24 Stunden auf. Was könnte das sein?
    Das ganze sieht ja so aus als würde man versuchen meinen Pi als einen Proxy zu verwenden. Die 200 macht mir sorgen, sollte ja eigentlich eine 403 sein.
    Es geht ja um Port 25 also hat das wohl was mit einem Spammer zu tun oder? Am Router ist Port 25 aber dicht, damit sollte ich doch sicher sein oder?

  • Die Frage "was kann man machen" lässt sich nur genauer beantworten wenn man weiss wie es genutzt wird:

    1)
    Wenn ausschlieslich vertrauenswürdige Personen (wo auch du selber zu gehörst) deinen Webserver übers Internet ansprechen können dürfen, dann sollte man entweder den Zugriff auf die "sites-enabled" vom apache2 über eine DynDNS beschränken; und selbstverständlich dafür sorgen das diese DynDNS niemalsnie irgendwo im Internet erwähnt wird... Oder mithilfe " .htaccess " die Verzeichnisse mit Zugangsdaten schützen

    2)
    Wenn fremde Personen deinen Webserver übers Internet ansprechen können dürfen, weil du zB bei dir Zuhause ein Forum oder Blog o.ä. betreiben willst, bleibt dir nichts anderes übrig als regelmässig das Logfile /var/log/apache2/access.log auf seltsame Einträge zu kontrollieren und fragwürdige IPs mit iptables zu sperren


    In deinem Fall scheint es ja immer die selbe Host zu sein, und fragwürdig ist es auf jedenfall da vom Port 25 eine Verbindung zu deinem Webserver (port 80) aufgebaut wird...


    Wie das im Detail geht:


    Zu 1)
    Dafür gibt es 3 Möglichkeiten:
    a) Über die apache2 Konfigurationsdateien
    b) Über .htaccess ; allerdings müsste man das für jedes Unterverzeichniss auch anlegen (es ginge aber auch ein Symlink)
    c) Über iptables (wäre unabhängig vom eingesetzten Webserver wie apache2 oder nginx etc)


    Zu a):
    Allgemein:
    Apache2 ist so aufgebaut das über den Befehl " a2ensite " sog. Symlinks (Verknüpfungen) der VirtualHost Dateien von /etc/apache2/sites-available/ nach /etc/apache2/sites-enabled/ erzeugt werden...
    Es könnte also sein das ihr mehrere VirtualHosts betreibt weil ihr zB unterschiedliche Ports für unterschiedliche Verzeichnisse nutzen wollt?

    Anyway - um den Zugriff über eine bestimmte DynDNS zu beschränken müsst ihr alle VirtualHost Konfigurationsdateien bearbeiten!
    Also am besten (auch wenn ihr es aktuell nicht nutzt aber später vielleicht vergesst das ihr das auch modifizieren müsstet) alle Dateien in /etc/apache2/sites-available/ bearbeiten:

    Code
    nano /etc/apache2/sites-available/*

    Dort geht ihr dann in die Zeile wo die zweite " <Directory " Regel steht
    In der default Datei wäre das " <Directory /var/www/> " und dort ändert ihr die folgenden Zeilen, die normalerweise wie folgt aussehen:

    Die geänderten Zeilen wären:

    Code
    Order deny,allow
                    deny from all
                    allow from eure.dyndns.org


    Dort müsst ihr natürlich eure eigene DynDNS eintragen ;)

    Sollte dann also geändert so aussehen:

    Spoiler anzeigen

    Wichtig zu erwähnen wäre allerdings das ihr euch im LAN dann aussperrt. Wenn ihr weiterhin aus eurem LAN auf euren Webserver zugreifen wollt müsst ihr eine weitere Zeile " allow from " unter die andere hinzufügen:

    Code
    allow from 192.168.0


    ..um weiterhin aus dem LAN Netzwerkteil 192.168.0.x den Zugriff zu erlauben..


    Anschliesend muss der apache2 noch reloaded oder restarted werden damit die Änderungen übernommen werden:

    Code
    /etc/init.d/apache2 restart


    Zu b):
    Wie bereits erwähnt hätte das den Nachteil das für wirklich jeden Unterordner eine .htaccess angelegt werden müsste.. Ausserdem gilt das auch nicht für Aliases wie sie zB für phpmyadmin angelegt werden! Die phpmyadmin alias-Konfigurationsdatei liegt übriegens hier: /etc/apache2/conf.d/
    Wer aber weder Unterordner noch phpmyadmin ö.ä. nutzt für den könnte diese Möglichkeit einfach sein.. ABER ACHTUNG: .htaccess funktioniert ebenfalls nur für apache2!

    Über .htaccess kann sowohl die aus a) beschriebene "Order deny,allow" Geschichte als auch eine Login-Abfrage eingebunden werden - ich gehe jetzt aber nur grob auf letztes ein sonst wird das zu viel hier:

    Zunächst die .htaccess anlegen:

    Code
    nano /var/www/.htaccess

    Mit folgendem Inhalt:

    Apache Configuration
    AuthType Basic
    AuthName "Zugriff verweigert - Bitte User und Passwort eingeben"
    AuthUserFile /var/.htpasswd
    Require valid-user


    Anmerkungen dazu:
    AuthName könnte auch ' AuthName "Access denied" ' lauten, das ist relativ egal..
    AuthUserFile sollte aus Sicherheitsgründen ausserhalb der apache2 DocumentRoot Verzeichnisse liegen

    Nun erzeugen wir die bei AuthUserFile angegebene Datei mit folgendem Befehl:

    Code
    htpasswd -cs /var/.htpasswd testuser


    Der Parameter -c bewirkt dabei, dass eine neue Datei angelegt wird, der Schalter -s erzwingt eine SHA Verschlüsselung des Passworts.
    Wenn ihr dort mehrere Benutzer eintragen wollt dann lasst bei allen weiteren das -c weg.
    Welche Parameter sonst noch gehen könnt ihr euch über htpasswd --help anzeigen lassen..

    Anschliesend müssen die apache2 VirtualHost Konfigurationsdateien wie in "Allgemein:" von a) beschrieben, bearbeitet und für das Verzeichniss die Regel AllowOverride von None auf All geändert werden.

    Spoiler anzeigen

    Danach apache2 neu starten oder reload'en..


    Zu c):
    ...ich hab jetzt nicht mehr die Zeit das auch noch detailiert zu beschreiben deshalb verlink ich hier erstmal eine andere Webseite und komm hierrauf vllt nochmal zurück:
    http://dave.thehorners.com/content/view/86/65/


    Zu 2):
    Manuell würde das so aussehen:

    Code
    iptables -A INPUT -s IP-ADRESSE -j DROP

    Also zum Beispiel:

    Code
    iptables -A INPUT -s 1.2.3.4 -j DROP

    Um eine IP wieder rein zu lassen (bzw zu löschen):

    Code
    iptables -D INPUT -s IP-ADRESSE -j DROP

    -A bedeutet Add
    -D bedeutet Delete

    Um herraus zu finden welche IP's bereits gesperrt sind kann man folgendes ausführen:

    Code
    iptables -L INPUT

    Ihr könnt euch natürlich auch ein Script basteln um nicht jedesmal diese Befehle eingeben zu müssen:

    Spoiler anzeigen


    nano /sbin/BAN

    Bash
    #!/bin/bash
    ACT=DROP
    [ -z "$1" ] && echo "Usage: $(basename $0) IP (del)" && exit 1
    [ ! -z "$2" ] && iptables -D INPUT -s $1 -j $ACT || iptables -A INPUT -s $2 -j $ACT
    exit 0


    Script ausführbar machen:

    Code
    chmod +x /sbin/BAN

    Um damit eine IP zu sperren einfach

    Code
    BAN 1.2.3.4


    ausführen.
    Um eine IP zu löschen führt ihr stattdessen

    Code
    BAN 1.2.3.4 del


    aus wobei als 2. Parameter irgendwas übergeben werden kann also zB auch

    Code
    BAN 1.2.3.4 d


    oder

    Code
    BAN 1.2.3.4 .


    Da es sonst wieder Diskusionen gibt erwähn ich auch kurz was zu " -j DROP ":
    DROP bewirkt dass das Datenpaket verworfen wird, es wird also darauf nicht geantwortet bzw zurückgewiesen. Einerseits erzeugt das natürlich weniger Traffic weil nichts zurückgeschickt wird, aber andererseits sieht der Client nicht das der Port zu ist, denn normalerweise käme sofort eine Antwort zurück dass der Port zu sei...
    Es würde also quasi die 'timeout' Zeit verstreichen bevor der Verbindungsversuch abgebrochen wird

    Stattdessen kann auch " -j REJECT " genutzt werden, was den Verbindungsversuch dann sofort zurückweisen würde also dem Client sowas ähnliches schickt wie "Du kommst hier nicht rein"..
    Wenn der Client aber im Sekundentakt (oder auch öfters) Anfragen stellt dann kann das eure Leitung killen, da das unheimlich viel Traffic von euch (und dem/den Client/s) erzeugt


    Sowas könnte man ggf auch automatisieren indem man das Paket fail2ban installiert - allerdings funktioniert das nur wenn der Client dann fehlerhafte Anfragen stellt, also zB 3x Logindaten falsch eingibt oder mehrmals nicht existierende Verzeichnisse aufruft... Funktioniert auch nur bei eingeschalteten Logs da fail2ban die Logdateien kontrolliert - Konfigurieren sollte man fail2ban auch ein bischen ;)


    ...ich denke das war alles, oder hab ich noch was vergessen? :s


    EDIT:

    Was auch noch unbedingt beachtet werden sollte ist dass dem WebServer benutzer www-data nicht willkührlich erlaubt wird Befehle mit root Rechten auszuführen - das stellt ein enormes Sicherheitsrisiko dar!

    Einen Sichereren Weg habe ich > hier < genauer erklärt und in folgendem Beitrag gab es dazu auch schon mal eine ähnliche Diskusion: pi mit raspberry-remote und schalten per PHP

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!