VPS absichern unter Verwendung von Fail2ban mit Docker-Apps

MrDeluxe

Enthusiast
Thread Starter
Mitglied seit
01.04.2006
Beiträge
1.470
Hallo liebe Gemeinde,

ich bin seit ca. 1 Woche umgezogen von 1und1 nach Contabo. Ich habe mir den kleinsten VPS bestellt und soweit eingerichtet. Auf dem vServer vom 1und1 lief noch alles dediziert, nun möchte ich die Applikationen mit Docker isolieren. Bisher habe ich einen Apache2.4 mit SSL zum fliegen gebracht im Docker-Container. Die Webseite ist mit htaccess-Digest abgesichert. Um nun Brute-Force-Attacken entgegenzuwirken habe ich fail2ban eingerichtet. Dazu habe ich die Logging-Daten vom Apache2.4 vom Host einbinden lassen (-v), außerdem gebe ich dem Container die Zeit des Hosts darüber mit.
sudo docker run -v /var/log/Docker/apache2:/var/log/apache2 -v /etc/localtime:/etc/localtime --name apache2ssl -p 80:80 -p 443:443 -d apache2ssl


Soweit so gut, und es läuft. Was nicht läuft ist fail2ban für den Container. Fail2ban schlägt beim SSH-Zugriff auf dem HOST zu, wie es soll. Wenn ich aber mehrere Male das Kennwort bei htaccess falsch eingebe, wird im Log von Fail2ban angezeigt, dass ich gesperrt werde, iptables sagt es auch ABER ich werde nicht gesperrt, wieso auch immer. Also kurzum ssh-Sperre klappt auf dem Host, die Sperre mit dem Container leider nicht.

Hier schön zu sehen, dass meine IP gesperrt wurde. Dennoch habe ich weiteren Zugriff auf die Webseite, was nicht sein dürfte.

Fail2ban Log
2016-07-11 09:02:52,064 fail2ban.actions[5092]: WARNING [apache-multiport] Ban 192.XX.XX.XXX
2016-07-11 09:02:52,067 fail2ban.actions[5092]: WARNING [apache] Ban 192.XX.XX.XXX

Iptables -L
#sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-apache-multiport tcp -- anywhere anywhere multiport dports http,https
fail2ban-apache-badbots tcp -- anywhere anywhere multiport dports http,https
fail2ban-apache-nohome tcp -- anywhere anywhere multiport dports http,https
fail2ban-apache-overflows tcp -- anywhere anywhere multiport dports http,https
fail2ban-apache-noscript tcp -- anywhere anywhere multiport dports http,https
fail2ban-apache tcp -- anywhere anywhere multiport dports http,https
fail2ban-ssh tcp -- anywhere anywhere multiport dports 99XX

Chain FORWARD (policy ACCEPT)
target prot opt source destination
DOCKER-ISOLATION all -- anywhere anywhere
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain DOCKER (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.17.X.X tcp dpt:https
ACCEPT tcp -- anywhere 172.17.X.X tcp dpt:http

Chain DOCKER-ISOLATION (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain fail2ban-apache (1 references)
target prot opt source destination
REJECT all -- 192.XX.XX.XXX anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere

Chain fail2ban-apache-badbots (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain fail2ban-apache-multiport (1 references)
target prot opt source destination
REJECT all -- 192.XX.XX.XXX anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere

Chain fail2ban-apache-nohome (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain fail2ban-apache-noscript (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain fail2ban-apache-overflows (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere


Fail2ban-Regex
#sudo fail2ban-regex /var/log/Docker/apache2/error.log /etc/fail2ban/filter.d/apache-auth.conf

Running tests
=============

Use failregex file : /etc/fail2ban/filter.d/apache-auth.conf
Use log file : /var/log/Docker/apache2/error.log


Results
=======

Failregex: 1226 total
|- #) [# of hits] regular expression
| 6) [668] ^\[[^]]*\] \[:-)?error|\S+:\S+)\]( \[pid \d+:-)\S+ \d+)?\])? \[client <HOST>:-)\d{1,5})?\] (AH0179[24]: )?(Digest: )?user .*?: password mismatch: \S*(, referer: \S+)?\s*$
| 7) [558] ^\[[^]]*\] \[:-)?error|\S+:\S+)\]( \[pid \d+:-)\S+ \d+)?\])? \[client <HOST>:-)\d{1,5})?\] (AH0179[01]: |Digest: )user `.*?' in realm `.+' (not found|denied by provider): \S*(, referer: \S+)?\s*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
| [2274] WEEKDAY MONTH Day Hour:Minute:Second[.subsecond] Year
`-

Lines: 2283 lines, 0 ignored, 1226 matched, 1057 missed
Missed line(s): too many to print. Use --print-all-missed to print all 1057 lines




Was habe ich übersehen? :/

- Danke für jegliche Hilfe!
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
http://www.iptables.info/files/tables_traverse.jpg - die Pakete für den Docker werden geroutet und landen daher nicht in der Input-Chain, d.h. du musst sie in der PREROUTING-mangle/nat Tabelle blocken? (würde ich jetzt sagen)

Außerdem: warum nimmst du denn nun Docker? Das interessiert mich, weil ich jetzt auch einen VPS habe, aber dort jetzt doch auf die Verwendung von Containern verzichte, da ich nicht genau weiß, was ich davon habe. Klar ist das Teil erstmal isoliert, aber bei jeder Sicherheitslücke ist Root im Docker (immer noch?) Root am Host (bzw. dürfte es nicht zu schwierig sein, das zu schaffen) und da man (man sieht es bei dir ;)) dann i.d.R. auch zu bequem ist, die FORWARD-rules entsprechend anzupassen, hat ein Einbrecher sowieso im Docker die Möglichkeit, sein Botnet zu betreiben... Außerdem muss ich für jede Webapp (Baikal, Lesezeichenserver) einen eigenen Docker-Container anlegen (oder selber Dockerfiles erstellen und auch innerhalb des Dockers noch die Zugriffe absichern..., ist dann aber auch nicht mehr die Docker-Philosophie) und bei einem Sicherheitsupdate darf ich dann alle Images neubauen, d.h. also aus einem Patch werden 5-10-Docker-Patches... Wo da für den Privatmann, der jeden Dienst nur in einfacher Ausfertigung, auf einem Gerät braucht, der Vorteil liegt, weiß ich nicht (und für nicht-Roots sollte die Datensicherheit ja auch durch die geeigneten Nutzer gegeben sein).

Zu deinem Hoster (ich bin bei Hetzner, da ich gerne eine deutsche IP haben wollte und bei realistischer Schätzung meiner Leistungsanforderung (bis jetzt hat mir als Server ein Nas mit 500MB gereicht...) die Sache über den Absolutpreis lief): ich finde ja lustig, wie die vServer mit unendlich RAM/"Computereinheit" ziemlich günstig sind und die ded. Server (die vmtl. ja den Hardwarepark spiegeln) einfach richtig unattraktiv sind (da kostet dann ein Sandy-i7 mit GBit fast doppelt soviel, wie ein Skylake-Xeon bei Hetzner)... Berichte mal ;).
 
Hi flxmmr,

danke für deine Reaktion :). Leider stecke ich nicht so massig in IPTables drin, um dagegen oder dafür etwas zu sagen. Ich hatte mir durchaus gedacht, dass es was mit dem Routing sein könnte aber wie es nun realisiert wird ist mir immernoch schleierhaft und vor allem wie ich die Konfig im fail2ban anpasse :/ Da muss ich wohl noch weiter recherchieren. Aber auch lustig, wie es bis dato noch keine ähnlichen Fälle dazu gibt oder bin ich wieder zu doof zum googlen? :hmm: Kann doch nicht, sein das ich der einzige bin der versucht seinen Container mit fail2ban abzusichern ODER die machen es alle schlauer als ich ^^

Hehe, ja und die Sache mit der Docker-Philosophie. Ich bin auch auf gut Glück aufs Boot aufgesprungen, das gebe ich zu. Mir kamen die selben Gedanken, wieso ich denn Docker einsetzen sollte, welchen Mehrwert es für mich hat etc. pp. Letzten endes habe ich mich für Docker auch entschieden, um zu lernen, wie man damit umgeht. Für mich war es vorher Neuland (thöhö) und ich habe jetzt auch nicht ultra-wichtige Sachen auf meinem vServer gehabt, sodass ich eben mich ausprobieren konnte. Zum anderen finde ich es sehr bequem, Updates einzuspielen oder zu migrieren. Nehmen wir beispielsweise Owncloud/Nextcloud. Es war immer ein Chaos ein Update einzuspielen. Jetzt kann man einfach schnell das Image bauen und die Daten extern auf der verschlüsselten Host-Partition lassen. Schon hat man die aktuellste Debian-Version mit aktuellsten Owncloud in ein paar Minuten und man muss nicht mal groß etwas konfigurieren dazu (soweit bin ich aber noch nicht gekommen^^). Ich finde das als hohen Komfortgewinn. Außerdem ist es gerade schwierig zu sagen, was mit Owncloud wird. Ich werde noch solang es geht Owncloud nutzen aber wenn das offizelle Image von Nextcloud da ist, werde es ich es mir definitiv zu gemüte führen. Aber aktuell ist mir das das zu früh und unausgereift bei Nextcloud. Das macht eben den Charm aus, man kann ein Image schnell einspielen und testen und bei Nichtgefallen einfach wegschmeißen ohne den Host zu beschmutzen. Schnell löscht man mal die python-bibliothek o.Ä. und der Host muss komplett neu aufgesetzt werden. Diese Gefahr besteht dann eben nicht mehr.
Und klar, Sicherheitsprobleme sind immer vorhanden. Egal was man nutzt. Dennoch ist gibt es eine zusätzliche Schicht, die der Angreifer erstmal erkennen und aushebeln muss. Zum Thema Docker-Security kann ich dir das Paper hier wärmstens empfehlen:
https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.11.0_Benchmark_v1.0.0.pdf
Kurzum, klar muss man den Container entsprechend härten, um der Komprimittierung Herr zu werden ;)

Zu dem Hoster: Ich habe einfach den Preis-Leistungs-König gewählt. 8€ im Monat mit 500GB, 6RAM war einfach unschlagbar mit Domain. Vor allem der große Speicher war mir wichtig, da ich eben Owncloud drauf laufen lassen möchte :)



Die Edit war hier: Ich hab es dann hinbekommen. Natürlich war ich zu doof zum googlen. Wie konnt ich nur behaupten, dass ich der einzige mit diesem Problem wäre^^
Hier hab ich den Lösungsweg gefunden:
http://scorban.de/2016/05/25/fail2ban_und_docker/
 
Zuletzt bearbeitet:
Also schon die Forward-Chain (könnte man dann ja auch im Prerouting lösen, dann kann der auch keine Host-Ports mehr erreichen/scannen) :).
Hm, für größere Softwarepackages mag Docker schon seinen Nutzen haben, aber für mich habe ich dann da auch keinen großen Unterschied mehr gefunden, ob ich jetzt die Konfigfiles im Docker ändere, wenn was im Standardimage nicht passt, oder bequem im Hostverzeichnis (bspw. Owncloud theoretisch muss man nur die Daten umhängen, aber dann fehlt eine Konfigdatei und die dann aus dem Docker rauszukramen und in den neuen reinzubauen - cp /var/www/ownclod /var/www/next geht halt immer). Zumindest bei Python, Node, PHP und ruby sind auch die Dependencies kein Problem, da man die einfach projektweise installieren kann und damit das System nicht vollmüllen muss.

Und Contabo ist ja schon billig und hat erstaunlich viele und gute Google-Bewertungen (dafür, dass sie sonst 0 visibility haben), allerdings auch für die ded. Server, die halt einfach P/L-mäßig unterirdisch sind und überall wird 1000mal Contabo erwähnt, von Leuten die weit weg von München ihren Wohnsitz haben und die Website hat noch nicht mal mehr 'ne Sprachoption... Preislich sollte das mit abgeschriebenen Nehalems auf jeden Fall hinkommen, also berichte doch mal, wie's so läuft.
 
Ich weiß nicht so recht, was du jetzt für eine Rezension erwartest. Ich bin nicht mal einem Monat bei Contabo daher kann ich über Ausfälle z.B. gar nichts sagen. Der Kontakt und Service ist einwandfrei und Leistungsprobleme kann ich auch nicht beklagen bis dato.
 
Ist klar, daher einfach mal in einem halben Jahr an den Thread denken ;). Irgendwie vertraue ich nämlich jemandem, der in diesem Forum seit 10 Jahren aktiv ist und mit einer sehr speziellen Problemstellung eine Frage stellt, bei der der Hoster erwähnt wird, deutlich mehr, als wütenden Russen und Amerikanern, die "Probleme" hatten, oder gegenteilig den überaus zufriedenen Asiaten, die in jeder Zeile Contabo erwähnen.
 
Ich fühl mich ja fast schon geschmeichelt ;) Dabei wollte ich die Info sogar weglassen, dass ich nach Contabo umgezogen bin, da es eigentlich unerheblich bezogen auf die Problemstellung ist. Ich werde ein Update Posten. Ansonsten kannst du mich auch persönlich kontaktieren.
 
Ist jetzt nichts zum Problem des TE, aber da flxmmr nach Contabo gefragt hat:

Bin seit (glaube ich, müsste nachschauen) 3 Jahren bei Contabo und kann bisher nichts negatives berichten. Als ich da meinen vServer gekauft habe (ebenfalls der kleinste), hatte dieser "nur" 200GB HDD, ebenfalls für 8€ im Monat. Leider gabs keine Preissenkung mit dem neuen Modell, finde ich aber nicht tragisch. Für die gebotene Leistung bekommt man viel denke ich. Der Speicherplatz wird zwar gnadenlos überprovisioniert sein, aber das ist nicht mein Problem.

Mit dem Support habe ich bisher auch gute Erfahrungen gemacht. Einmal hing meine VM aus irgendeinem Grund beim Reboot fest und lies sich auch per Webinterface nicht neustarten (VNC konnte ich da gerade nicht nutzen) und einmal hatte ich ominösen packetloss von und zu meinem vServer. In beiden Fällen antwortete der Support schnell und löste auch mein Problem sehr fix.

Unangekündigte Ausfälle gab es bei mir bisher keine. Wartungsarbeiten gab es, aber die wurden mir angekündigt und im Anschluss lief alles wieder wie vorher.

Da habe ich mit anderen Anbietern schlechtere Erfahrungen gemacht (wenn auch für weniger Geld und nur mit dem Backup-vServer).
 
So Freunde der Sonne, für mich hat es sich doch ausgedockert. Nachdem ich glücklich einen Web-Container mit einer Webseite gebaut hatte und der Zweite eben auch auf Port 80 und 443 lauschen sollte, ist mir die Hutschnur geplatzt.
Es gibt 3 Optionen, mehrere Webapps laufen zu lassen unter Docker:

a) für jede Web-App einen seperaten Port öffnen --> natürlich nicht, will ja kein offenes Scheunentor
b) Alle Web-Apps in einem Container --> nope, Flexiblität geht total verloren
c) Ich lasse einen Reverse Proxy auf den Host laufen --> noch beste Lösung aber Komplexität und Verwaltungsaufwand steigt und letzten Endes läuft noch ein Dienst auf dem Host

Also Docker mag seine Raffinessen und Charme haben aber für mich ist es leider nichts (mehr).
 
deckt sich in etwa mit meinen Überlegungen. Wobei ich Punkt a) noch nicht verstehe? – ist doch egal, ob du das jetzt mit vhost oder Docker machst? (musst natürlich die default-config in jedem Container anpassen ;)).
 
Sry wenn ich die Leiche wieder aus dem Keller hole ABER ich muss im Docker jedem Container einem Port zuweisen, den ich entweder per Reverse Proxy an den Webserver weiterleite ODER ich für jeden Webdienst einen Port öffne. Also Website XY kriegt 80, Nextcloud 8080, Blog 8081 usw. darauf hab ich keine Lust. Per vhost ist das ganze eleganter und weniger anfällig für Portscans u.a. denn da wird eben nur der Name zugeordnet zum Service und nicht eben der Port.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh