Nach Hackerangriff - Security Check

vogelll89 · 29. Januar 2016

Guten Tag zusammen,

Ende Dezember wurde meine Joomla Seite gehackt und es wurden Phishing Mails darüber verschickt. Leider hatte ich damals Joomla nicht up to date.
Ich habe dann ein Backup eingespielt und Joomla aktualisiert, Kennwörter geändert etc. Nach einer Woche war die Seite wieder gehackt.

Nun nahm ich mir die Zeit und habe folgendes gemacht:

Gesamte Filestruktur komplett gelöscht im WWW Ordner
Alle Datenbanken gelöscht
Neue Joomla Installation
Joomla Admin umbenennt / unnötige Admins gelöscht
Joomla Admin Passwort > 32 Zeichen
Joomla Updates
Unser Template installiert
Nicht verwendete Templates deinstalliert
.htaccess File von joomla-security.de eingespielt
- Hier musste ich die Zeile 26 „## Options All –Indexes“ auskommentieren, ansonsten lief die Website nicht. ( Siehe *Fehlermeldung) Ist das eine grosse Sicherheitslücke?
Spezifizierte htaccess Dateien in Subfolders (Siehe spezifizierte htaccess Files**)
Datei- & Ordnerberechtigung wurden angepasst.0444
- index.php
- configuration.php
- /administrator/index.php
- /templates/Ihr Template/index.php
- Alle „.htaccess“-Dateien
Vorerst verwende ich nur Standard Joomla PluIns/Komponenten etc.

*Fehlermeldung:
Serverfehler!Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten.Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.Error 500infbat70.chThu Jan 21 16:10:37 2016Apache/2.2.31 (FreeBSD)**

spezifizierte htaccess Files
---------------------------------------------------------
<Files "*.*">Deny from all</Files> <FilesMatch "\.(js|css|png|jpg|jpeg|gif|ico|flv|swf|woff|woff2|eot|ttf)$">Allow from all</FilesMatch>
---------------------------------------------------------
/administrator/components
/administrator/help
/administrator/modules
/administrator/templates
/components
/images
/media
/modules
/plugins
/templates
---------------------------------------------------------

<Files "*.*">Deny from all</Files>/administrator/cache
---------------------------------------------------------
/administrator/includes
/administrator/language
/administrator/manifests
/bin
/cache
/cli
/includes
/language
/layouts
/libraries
/logs
/tmp
---------------------------------------------------------

Nun bin ich natürlich paranoid die Website wieder Online zu nehmen
Habt Ihr noch einen guten Tipp? Gibt es eigentlich gute Anbieter, welche eine Joomla Seiten auf die Sicherheit überprüft?

skodi · 29. Januar 2016

Zitat

Ich habe dann ein Backup eingespielt und Joomla aktualisiert, Kennwörter geändert etc. Nach einer Woche war die Seite wieder gehackt.

Dass die Seite wieder gehackt wurde, liegt vermutlich daran, dass du vermutlich nicht die Lücke gefunden hast über welche der Angreifer die Kontrolle übernehmen konnte.

Entweder hast du ein infiziertes Backup eingespielt, oder du hast die Lücke einfach nicht geschlossen (Erweiterungen?) oder der Angreifer kam über einen anderen Weg (FTP?)

Das ist ja gerade das "schwierige" bei einem Hack, wenn man Gewissheit haben will - muss man die Lücke finden und Logfiles wälzen. Danach weiß man, wo konkret man ansetzen muss.

Deine Maßnahmen, sind im Grunde alle nicht verkehrt (diese erweiterte .htacess, naja - da gibts geteilte Meinungen drüber).
Aktuell wird nichts passieren - du lädst ein frisches Joomla auf einen frischen Webspace, da kanns im Prinzip keine Altlasten geben.

Wer glaubt, dass ihm das hilft der kann auch noch Zwei-Faktor Authentifizierung benutzen, eine Joomla-Firewall installieren, ein 50-Zeich langes Passwort nehmen, sich jedes Mal aus einer virtuellen Maschine heraus einloggen usw. - das alles bewahrt einen aber nicht vor dem eigentlich Wesentlichen: Updates & Backups machen.

kitepascal · 29. Januar 2016

Zitat von vogelll89

Hier musste ich die Zeile 26 „## Options All –Indexes“ auskommentieren, ansonsten lief die Website nicht. ( Siehe *Fehlermeldung) Ist das eine grosse Sicherheitslücke?

Nein, eher nicht. Oft ist das Directory Browsing ohnehin schon serverseitig deaktiviert - im Zweifelsfall testen.

Die spzifierten .htaccess Files in den Unterverzeichnissen kannst du dir sparen. Über die .htaccess im root lässt sich eigentlich alles steuern.

Relevanter part aus der J!-Security beta htaccess:

Spoiler anzeigen

########## Begin - Advanced server protection - paths and files by Nicholas K. Dionysopoulos
## Back-end protection
## This also blocks fingerprinting attacks browsing for XML and INI files
RewriteRule ^administrator/?$ - [L]
RewriteRule ^administrator/index\.(php|html?)$ - [L]
RewriteRule ^administrator/index[23]\.php$ - [L]
RewriteRule ^administrator/(components|modules|templates|images|plugins)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov)$ - [L]
RewriteRule ^administrator/ - [F]

## Explicitly allow access only to XML-RPC's xmlrpc/index.php or plain xmlrpc/ directory
RewriteRule ^xmlrpc/(index\.php)?$ - [L]
RewriteRule ^xmlrpc/ - [F]

## Disallow front-end access for certain Joomla! system directories
RewriteRule ^includes/js/ - [L]
RewriteRule ^(cache|includes|language|libraries|logs|tmp)/ - [F]

## Allow limited access for certain Joomla! system directories with client-accessible content
RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*([^/.]+\.)+(jp(e?g|2)?|png|gif|bmp|css|js|swf|html?|mp(eg?|[34])|avi|wav|og[gv]|xlsx?|docx?|pptx?|zip|rar|pdf|xps|txt|7z|svg|od[tsp]|flv|mov|eot|ttf|woff)$ - [L]
## Uncomment this line if you have extensions which require direct access to their own
## custom index.php files. Note that this is UNSAFE and the developer should be ashamed
## for being so lame, lazy and security unconscious.
# RewriteRule ^(components|modules|plugins|templates)/([^/]+/)*(index\.php)?$ - [L]
## Uncomment the following line if your template requires direct access to PHP files
## inside its directory, e.g. GZip compressed copies of its CSS files
# RewriteRule ^templates/([^/]+/)*([^/.]+\.)+php$ - [L]
RewriteRule ^(components|modules|plugins|templates)/ - [F]

## Disallow access to rogue PHP files throughout the site, unless they are explicitly allowed
RewriteCond %{REQUEST_FILENAME} \.php$
RewriteCond %{REQUEST_FILENAME} !/index[23]?\.php$
## The next line is to explicitly allow the forum post assistant(fpa-xx)script to run
RewriteCond %{REQUEST_FILENAME} !/fpa-[a-z]{2}\.php
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^([^/]+/)*([^/.]+\.)+php$ - [F]

########## End - Advanced server protection - paths and files

vogelll89 · 1. Februar 2016

Noch eine kurze Frage,

Normale Beiträge können kaum eine Sicherheitslücke sein oder?
Vorallem wenn z.B. eine automatische Link Weiterleitung in einem Beitrag integriert ist.

html>
<head>
<meta http-equiv="refresh" content="1; URL=http://google.ch">
</head>
<body>
<h1>Diese Seite existiert nicht, Sie werden weitergeleitet.</h1>
<p>Falls Ihr Browser keine automatische Weiterleitung unterstützt, <a href="http://google.ch" >klicken Sie hier</a>!
</body>
</html>

Die habe ich nämlich zuletzt vor dem Angriff eingerichtet. Wird aber wohl kaum die Ursache sein ;)?

flotte · 2. Februar 2016

Nein das ist keine Sicherheuitslücke!

Untersuche die Logs, auch FTP-Logs! Nur damit findest du raus was passiert ist. Alles andere ist rumstochern im Nebel.

vogelll89 · 2. Februar 2016

Ja mein Hoster konnte mir damals kaum Logs zur Verfügung stellen. Naja habe jetzt ja alles frisch aufgesetzt
Werde diese Woche die Seite wieder Online nehmen und im vorhinein schauen, dass der Hoster alle Logs mir zur Verfügung stellen kann.

Danke für Ihre Tipps.