Neue Angriffsmuster bei Zugriffen auf die Webseite

Mir ist völlig unklar, was es Dir für Vorteile bringt, das alles zu dokumentieren und auch noch zu melden.

Die Betreiber der Botnetze, die das verursachen, werden nie aufgespürt oder gar bestraft werden.

Du hast viel Arbeit und keinerlei Verbesserung.

Wo genau liegt hier mein Denkfehler?

Ich würde auch keine weitere Zeit darauf verschwenden, meine Serverlogs nach solchen Einträgen zu durchforsten und den Focus lieber darauf legen, mich um die generelle Sicherheit des Systems (aktuelle Patchlevel etc.) zu kümmern und darauf zu achten, dass die User keine "Leaks" selbst anlegen.

Wenn man im Nachhinein auf Einträge im Log reagiert, ist es doch eh meist schon zu spät. Oft werden durch derartig erstellte Regeln auch IPAdressbereiche von ganz normalen Usern blockiert.

Besser ist es IMHO z.B. auf dem laufenden zu bleiben, was aktuelle Schwachstellen betrifft und dann z.B. den eigenen Server proaktiv nach Dateien wie "dump.sql" zu durchsuchen, bevor es andere tun etc.

Hallo Thomas,

So viele Versuche mit einer und der selben IP?
Bei mir habe die höchstens zwei Versuche, dann wird geblockt.

Ich habe diesen Monat mehr als 450 unerwünschte Zugriffe registriert

Zitat von Hanabi

Nachtrag: Da das Backup von Zeta-Projekten wahlweise auch im Root-Verzeichnis des Servers gespeichert wird in der Form ***.zip gespeichert wird, besteht hier zumindest theoretisch eine Schwachstelle. Ich suche mal nach einer entsprechenden Sperranweisung für die .htaccess. Falls spontan ein anderer User diese schon griffbereit hat, bitte posten.

Ähm sorry, aber was hat eine Backup-Zip von einem Zeta-Projekt auf einem Webserver zu suchen?

Redundanz (ist optional in den Backup-Einstellungen anwendbar).

Moin,

wenn dir dein Rechner abraucht und du sonst keine Sicherung(en) hast (hier schon oft vorgekommen), dann bist vielleicht froh dass dort ein Backup deines Projektes liegt

Folgendes sollte eigentlich bei Apache Webservern in der .htaccess funktionieren um Zugriffe auf ZP Backups zu unterbinden:

<Files ~ "\.zpautobackup\.zip$">
Order allow,deny
Deny from all
</Files>

Zitat von wurzelsepp

Moin,

wenn dir dein Rechner abraucht und du sonst keine Sicherung(en) hast (hier schon oft vorgekommen), dann bist vielleicht froh dass dort ein Backup deines Projektes liegt

Für den Privatmann mag das vielleicht zutreffen. Dieser wird aber kaum einen eigenen Webserver betreiben, geschweige denn sich irgendwelche Log-Dateien anschauen und die Zugriffsstatistik nach möglichen Angreifern durchsuchen. Daher handelt sich wahrscheinlich um ein nicht privates Umfeld. Und wer dort einen Webserver als Backup-Medium für Zip-Dateien missbraucht und diese dann per .htaccess Dateien gegen unerlaubten Zugriff versucht zu schützen, der sollte sein Konzept zur Datensicherung generell mal überdenken.
Die Projekte werden sicher auf einem Entwicklungsrechner erstellt. Diesem sollte ein Raid-System zu Grunde liegen, welches den Datenbestand spiegelt (1. Sicherung). Weiterhin bieten die meisten Festplattenhersteller eine kostenlose Version von True Image an, welche hervorragend zur Datensicherung auf externe Medien (USB, NAS usw.) geeignet ist (2. Sicherung, gegebenenfalls auch 3. Sicherung außer Haus, wenn die USB-Platte mit nach Hause nimmt bzw. das NAS in einer Zweigstelle stellt). Seine Sourcen kann man jedoch auch mit einer Quellcodeverwaltung bzw. einem Versionssystem wie Subversion gegen Datenverlust schützen, sei es jetzt auf einem Server im eigenen Firmennetz oder via Github oder ähnlichem im WWW (3. Sicherung, außer Haus). Und das schöne daran: dies kann jeder Privatmann auch so machen.

Alle Zeta Producer Nutzer betreiben implizit auch einen Webserver, da die Software ja kein Webhosting beinhaltet… Solchen Kunden hat das schon derart oft das komplette "Neuerstellen" der Website erspart, das können Sie sich nicht vorstellen. Ein Profi sollte natürlich seine Daten anders sichern. Das Sichern auf dem Webserver ist aber eine Option, die man ja nicht zwingend aktivieren muss. Selbst ohne .htaccess-Schutz ist es fast unmöglich die URL einer solchen Backup-Datei zu erraten.

Streiche "fast"

Zitat von Stefan S

Solchen Kunden hat das schon derart oft das komplette "Neuerstellen" der Website erspart, das können Sie sich nicht vorstellen.

Auf Eurem Hosting Server scheint Ihr die Backups aber auch nicht unbedingt zu mögen.

if (information.WantPublishToWebServer &&
    this._targetWriter.CanPublishToWebserver &&
    this._webProject.SettingsPublishing.PublishingServer != null &&
    this._webProject.SettingsPublishing.PublishingServer.WebPublishingProtocol != WebPublishingProtocolType.ProducerHosting)

Man beachte das letzte "!=". Hust.

Schönes WE.

Die Testmöglichkeit auf unserem Hosting ist nicht für den Produktivbetrieb geeignet.

Deshalb soll uns dort auch kein Backup die Server "verstopfen".

Zitat von Uwe Keim

 

Deshalb soll uns dort auch kein Backup die Server "verstopfen".

 

Aha. Bei mir ist es dann aber ok (wenn auch abwählbar)? :wacko:

Bei kleinen Projekten mag es ja noch praktikabel sein, aber nicht für größe Projekte mit einer Größe vom Ausgabeverzeichnis von 300MB und mehr. Die Zip-Datei ist nur unwesentlich kleiner, sprich mit ihr wird das doppelte Kontingent an Webspace verbraten. Und für den Upload sollte man dann schon ne halbwegs fett Leitung haben.

Trotzdem bleibe ich dabei: ein Webserver sollte ein abgeschottetes System sein, welches nur dem Zweck des Hostings der Website dienen sollte. Für Backupzwecke gibt es genug andere Lösungen. Zwei bietet Ihr ja mit Dropbox bzw. OneDrive schon als Option mit an.

Grüße madas

Zitat von Stefan S

Und wie testet man dann die angebotene Option zum "Speichern des Backups auf dem Webserver"?