Beiträge von KB19

Zitat von Apollon

Ich hätte jetzt gerne noch das (de|legal) durch ein Wildcard ersetzt, damit es auch für beliebige andere Domains geht, sorge mich aber, dass dann nicht mehr klar ist, wo die Verzeichnisse und Parameter beginnen ($).

Welche Verzeichnisse? In HTTP_HOST steht sowieso nur die Domain (und maximal der Port).

Wenn Du keine Third-Level-Domains (z.B. co.uk, co.at, …) hast, könntest Du es mal damit versuchen:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(.+\.)?[^.]+\.[^.]+(:[0-9]+)?$
RewriteRule ^(.*)$ http://%1campusjustiz.de/$1 [L,R=301]

Ist allerdings ungetestet!

Zur Erklärung: Mit [^.]+ holst Du alles, solange darin kein Punkt vorkommt. Du kannst solche regulären Ausdrücke übrigens z.B. mit regex101.com testen.

Zitat von mainziman

wenn ein Anti-Virus so richtig Hardcore Paranoia veranstaltet, dann würde er fast das ganze Web blockieren,

weil die Seiten, die beim CSS/HTML-Validator korrekt validieren sind rar; und alle anderen können Sicherheitsprobleme verursachen;

Wie viele Sicherheitslücken wurden eigentlich nur durch HTML & CSS ausgenutzt und wie viele mittels irgendwelcher JavaScript APIs?

Letzteres hat mit validem Code soviel zu tun, wie eine Ölraffinerie mit Umweltschutz.

Gute Lösung für 2FA, dann hat jeder User die freie Wahl.

Die App ist auch super geworden, die werde ich wohl installiert lassen. Hat durchaus einen Mehrwert, nicht nur unterwegs.

(Und ich gehe jetzt mal mein SCP-Passwort ändern. Das habe ich seit der Einführung von 2FA bzw. dem Autologin im CCP nicht mehr angerührt…)

Der Cronjob sollte allerdings schon laufen. Was hast Du schon versucht bzw. wo genau kommst Du nicht weiter?

Wenn man glaubt, man hat schon jede Art von Spam gesehen, kommen solchen Typen daher:

Zitat

Tired of spam?

If you read these words, your domain is in a global database of less-than-honest marketers who spam forms on public web pages for backlinks or trying to sell some product you dont need. You should have noticed that the process of collecting leads, growing an email list, and giving people opportunities to contact you has spam back, which might be frustrating. More than that, it may hurt your business because, in a pile of garbage, essential messages get lost sometimes. Its vital to stop spam form entries. Here we can help! We are Safe Intelligence Digital Marketing Agency who guarantee to rid you of this scourge or at least significantly reduce the number of spam messages to help save your time, money, and mental resources. So you could pay more attention to essential things as working with your clients, instead of reading garbage and fighting spambots. Please visit http://*****.xyz to get professional help.

Spam für Spamschutz? Ok, das ist mal was Neues!

Zitat von Sysop

So jetzt nach fast 3h ist es behoben.... Durch wen oder was auch immer ....

Afaik gibt es da ein (hohes) Timeout bei der Neuinstallation. Irgendwann wird das SCP somit auf jeden Fall wieder "entsperrt". Wurde glaube ich mal im Forum irgendwo erwähnt.

Solche Dinge rechtfertigen meiner Meinung nach aber auf jeden Fall einen Anruf beim Notfallsupport. Wenn das SCP auch nach zig Minuten nicht mehr bedienbar ist, ist das kein Benutzerfehler. (Mal abgesehen von Snapshots oder Speicheroptimierungen, die auch mal länger laufen können.)

Zitat von Proctrap

Wie komme ich eigentlich an das SCP Passwort mit den Login-Daten vom CCP ?! Ich muss ja für einige Aktionen das Passwort vom SCP angeben, obwohl ich einen auto-login via CCP habe. Bei einem neuen Kunden-Acc wurde aber nie ein SCP Passwort mitgeteilt !?

Wenn Du nicht mehr danach gefragt werden willst, gibt es die "Einfaches Passwort" bzw. "Sicherheitsmodus" Optionen: https://www.netcup-wiki.de/wiki/Server_Co…Einstellungen_3

Oder "Passwort vergessen" und ein neues Passwort setzen: https://www.netcup-wiki.de/wiki/Server_Co…swort_vergessen

Zitat von Proctrap

Und wieso läuft der ISO upload eigentlich via ftp statt sftp ab..

Dann nimm halt FTPS

Zitat von vmk

KB19 Wo ist dein Endpunkt?

Angeblich tserv6.fra1, aber die Adresse des Endpunktes (216.66.80.30) löst auf tserv1.fra1 auf.

Zitat von vmk

Frankfurt hat immer wieder sporadisch sehr hohen Packet Loss bzw. im Schnitt um die 1%.

Da bist Du eh noch gut dran. Mein Test-Tunnel von HE auf einem netcup VPS kommt auf 5-6%

smokeping.png

Vom selben Smokeping-Host aus zu anderen IPv6-Zielen habe ich normalerweise keinen Packet Loss.

Ich würde es lieber anders machen, wie bereits oft im Forum vorgeschlagen: Domain auf einen eigenen Ordner zeigen lassen und dort mittels .htaccess-Datei umleiten. Dann hast Du für die ursprüngliche Domain bei Bedarf sogar HTTPS über Let's Encrypt

Die Weiterleitungsoptionen in Plesk sind zwar für den schnellen Einstieg recht nett und praktisch, aber im Endeffekt schränkt man sich damit nur unnötig ein.

Im SSH-Chroot wird GPG nicht verfügbar sein. Über HTTP/FCGI sollte es normalerweise aber schon in /usr/bin/gpg liegen. Dafür muss aber garantiert exec() für PHP erlaubt sein. (Standardmäßig bei neuen Accounts/Domains der Fall.)

Zitat von voja

Deswegen immer schön das Monitoring monitoren. ?

Einfach jede Minute eine Warnmail für einen Dummyservice verschicken lassen!!!!111elf

Wenn die einmal nicht ankommt, weißt Du sofort Bescheid, dass das Monitoring nicht mehr arbeitet.

Whoami Die CCP-DNS-API unterstützt keine TTL je Record. Es gibt nur eine TTL für die ganze Zone. Ob man die überhaupt auf niedrige Werte wie 300 setzen kann, weiß ich jetzt gar nicht. Bzw. wäre das nur bedingt sinnvoll.

Bedenken sollte man auch, dass DNS-Updates bei netcup im schlimmsten Fall auch mal 10-20 Minuten brauchen. Selbst bei einer TTL von 300 Sekunden landet man da schnell bei einer Verzögerung von bis zu 25 Minuten! Das wäre mir persönlich deutlich zu hoch.

Da erscheint mir ein Service, wie der von vmk verlinkte, durchaus sinnvoller zu sein. Die Subdomain bei netcup verknüpft man dann einfach mittels CNAME-Record.

Zitat von irgendeiner Abuse Abteilung (Autoreply)

Please note that due to security concerns we will not open attachments under any circumstance. You must provide any necessary information in plaintext in the body of your report.

Soll ich jetzt ernsthaft die ganze Nachricht inkl. Header in den Body kopieren?

Dann soll deren Kunde halt weiterhin Phishing verschicken, mir ist es eigentlich wurscht…

whoami0501 Hast Du eigentlich schon eine Antwort vom Support erhalten?

Viele Pakete sind es bei mir nicht, normalerweise würden die im Grundrauschen untergehen.

    8   356 LOG_DROP   all  --  *      *       10.0.0.0/8           0.0.0.0/0
    9   360 LOG_DROP   all  --  *      *       100.64.0.0/10        0.0.0.0/0
    5   224 LOG_DROP   all  --  *      *       172.16.0.0/12        0.0.0.0/0
    9   428 LOG_DROP   all  --  *      *       192.168.0.0/16       0.0.0.0/0

     12 PROTO=TCP DPT=445
      9 PROTO=TCP DPT=443
      3 PROTO=TCP DPT=2323
      2 PROTO=TCP DPT=5555
      1 PROTO=UDP DPT=50761
      1 PROTO=TCP DPT=80
      1 PROTO=TCP DPT=23
      1 PROTO=TCP DPT=15612
      1 PROTO=TCP DPT=139

Mittlerweile spielt auch 10:0e:7e:26:f1:c0 (gw01.netcup.net [37.221.196.2]) mit.

Es handelt sich nicht mehr nur um SYN-Pakete, es sind auch RST-Pakete oder gar UDP dabei.

Zitat von killerbees19

Spannend! Ich verfolge jetzt auch mal die Packet-Counter meiner Firewall.

Ein paar dieser seltsamen IPv4-Pakete habe ich mittlerweile ebenfalls gesehen…

    2    92 LOG_DROP   all  --  *      *       10.0.0.0/8           0.0.0.0/0
    1    52 LOG_DROP   all  --  *      *       172.16.0.0/12        0.0.0.0/0
    2   104 LOG_DROP   all  --  *      *       192.168.0.0/16       0.0.0.0/0

[Aug16 20:18] […] SRC=172.29.1.11   […] LEN=52 TOS=0x08 PREC=0x60 TTL=112 […] DF PROTO=TCP SPT=57861 DPT=445 […]
[Aug17 00:06] […] SRC=10.7.250.145  […] LEN=52 TOS=0x00 PREC=0x00 TTL=117 […] DF PROTO=TCP SPT=56843 DPT=445 […]
[Aug17 01:00] […] SRC=192.168.1.3   […] LEN=52 TOS=0x00 PREC=0x00 TTL=117 […] DF PROTO=TCP SPT=46353 DPT=445 […]
[Aug17 01:01] […] SRC=192.168.1.3   […] LEN=52 TOS=0x00 PREC=0x00 TTL=117 […] DF PROTO=TCP SPT=46353 DPT=445 […]
[Aug17 01:28] […] SRC=10.255.32.160 […] LEN=40 TOS=0x00 PREC=0x00 TTL=51  […]    PROTO=TCP SPT=3199  DPT=80  […]

Alle kommen angeblich von 2c:6b:f5:a0:77:c0 (gw02.netcup.net [37.221.196.3]). Das Ziel ist sowohl meine primäre, als auch zusätzliche IP-Adresse. Gemeinsam haben sie nur, dass versucht wird auf TCP-Port 445 (SMB) und TCP-Port 80 (HTTP) zuzugreifen. Bis auf SYN scheint da (in der Vergangenheit) aber nichts zu kommen, da die Antworten vom Handshake wohl nicht mehr ankommen.

/cc @___  whoami0501

Zitat von mainziman

jetzt weißt wieso der Lappen futsch is; und kein Fahrverbot z.B. in Tempo 30 km/h-Zonen erteilt wird,

nur weil man dort gröber zu schnell war ...

Man kann Gerüchten zufolge auch ohne Führerschein noch fahren. Bei einem gesperrten Abonnement Plesk aufzurufen könnte schwierig werden

Zitat von H6G

fopen und fwrite haben klare Fehlerzustände und auch einem MySQL User können die Rechte auf Create und Update Queries verweigert werden.

Klar, aber viel Spaß bei der typischen PHP-Software, die so im Umlauf ist. Da ist das Geschrei dann groß, wenn am Ende "Datenverluste" zu beklagen sind.

Die jetzige Lösung ist zwar auch nicht optimal, aber ich kann das durchaus nachvollziehen, dass es (für netcup) das kleinere Übel ist.

Zitat von tab

Zumindest sollte dann aber sofort eine Benachrichtigung raus. Meinetwegen mit einer angemessenen Frist, bis zu der man Zeit hat, die notwendigen Massnahmen durchzuführen.

Eventuell habe ich den Beitrag von Bensen missverstanden, aber ich glaube das sollte bereits der Fall sein. Außer man überschreitet die Limits massiv. Benachrichtigung sollte es natürlich immer geben, klar.

Zitat von tab

Da würde ich aber nicht den ganzen CCP/WCP-Zugang sperren, sondern nur die Websites oder Mail-Accounts, je nachdem welcher Speicherplatz überläuft.

Das wird nicht machbar sein, Du musst immer einen Webhosting Tarif als Ganzes sperren. Andernfalls könntest Du über andere Domains z.B. noch Datenbanken füllen oder Dateien in anderen Ordnern ablegen, wenn exec() & Co. erlaubt ist.

Zitat von H6G

Warum muss denn da gesperrt werden? Es gibt hinreichende Möglichkeiten Schreibvorgänge zu blockieren.

Wenn man HTTP(S) aktiv lassen würde, endet das in vielen Fällen unschön. Viele (PHP) Anwendungen sind nicht ausreichend darauf vorbereitet, dass Dateien nicht mehr geschrieben werden können. Und was ist mit MySQL?

Ich finde die Sperrung durchaus nachvollziehbar. Blöd ist nur, dass man dann keine Möglichkeit hat, irgendwelche Daten zu löschen, um Speicherplatz freizugeben. Wenigstens der Dateimanager in Plesk sollte noch benutzbar sein. Ob Plesk so eine Möglichkeit vorsieht, weiß ich allerdings nicht.