Beiträge von moses

Glaube habe heute das 1. Mal eine aussagekräftige (ob das Stimmt was drinsteht ist wieder was andres) Antwortmail erhalten:

<Empfänger@hotmail.com>: host    hotmail-com.olc.protection.outlook.com[104.47.8.33] said: 550 5.7.1    Unfortunately, messages from [37.120.179.XXX] weren't sent. Please contact    your Internet service provider since part of their network is on our block    list (S3150). You can also refer your provider to    http://mail.live.com/mail/troubleshooting.aspx#errors.    [AM5EUR03FT047.eop-EUR03.prod.protection.outlook.com] (in reply to MAIL    FROM command)

Weiß netcup was davon oder ist das nur eine faule Antwort von denen?

Zur Info für andere:

Habe diesen Thread gefunden hier im Forum und es versucht. "fstrim -a" hat bei mir erst nach einem Neustart funktioniert (vorher hatte ich den Fehler "FITRIM ioctl failed: Eingabe-/Ausgabefehler" erhalten). War in ca. 1 Std. durch und verkleinerte meine 625GB HDD von 406GB genutzen Speicher auf 205GB.

Für mein Debian 8 gibt es sogar einen fstrim.timer für systemd - habe den jetzt eingeschalten. Auch für andere Systeme HIER beschreiben.

Sehr vorbildlich Hr. Preuß, super Service!

Kämpfe mit dem Problem schon seit Jahren und bin froh, dass es wieder aufgegriffen wird! Vielleicht kommt ja noch was dabei raus...

Zur Info für Andere: nach 17h nun abgeschlossen

Hallo janxb,

danke - werde ich versuchen. Mache immer einen Snapshot bevor ich Updates einspiele und daher ist eine Defragmentierung von Zeit zu Zeit leider nötig (ca. alle 6-12 Monate). Die Partition zu verkleinern ist eine idee, auch die Möglichkeit mit SCSI war mir noch nicht bekannt.

Defrag läuft leider immer noch (16h...)

Hallo Hr. Thoma,

danke für die Antwort. Meine Defragmentierung auf einer 625GB HDD läuft nun schon seit 14Std. - so lange hat es noch nie gedauert. Haben Sie evtl. Erfahrungswerte wie lange eine Defrag. dauern kann? Wäre sicher auch hilfreich für andere, um das zu Planen. Hätte diesmal extra mehr Zeit eingerechnet (bis zu 12h) aber da ich nun damit auch nicht auskomme, sind wir zZ per Mail nicht erreichbar, was ziemlich doof ist...

Warte auch gerade auf die defragmentierung seit 3 1/2 Stunden, eine %-Anzeige wäre wirklich hilfreich!

WOW - Super Service, das müsste netcup nicht machen. Vielen dank an das Team!

Vielleicht hilft es ja jemanden weiter:

bei mir war nur SSH und sonst nichts erreichbar, obwohl die Dienste liefen. Nach einem manuellem reload der iptables (die ja beim Neustart auch automatisch gestartet werden) funktionierte es. Wenn ich neu startete, wars wieder das selbe - ich musste meine iptables-Regeln neu abspeichern für den Neustart - jetzt wirds auch beim Neustart wieder geladen.

Wäre interessant, was das verursacht hat, denn ich habe gerade im letzten Monat öfters neu gestartet, da ich die Distri upgegradet habe und da hats da auch keine Probleme gegeben.

Finds auch gut, wenn netcup Sicherheutslücken schnell schließt - wenns dabei nur bei einem Kurzfristigem Neustart bleibt.

Sitzt jetzt sicher schon 1 Stunde dran und versuch herauszufinden, an was es hakt. Komm, wenn der Server gestartet ist, mit ssh drauf, Port 80 und 443 laufen aber nicht obwohl der apache2 Dienst auf diesen Ports laut netstat -tulpen | apache2 lauscht ebenso wie auf dem ssh-Port mit netstat -tulpen | ssh. Weiters: netstat domain.de 443 oder netstat domain.de 80 geht nicht, auf netstat domain.de 22 komm ich aber auf ssh... Dass das nun an meinem System liegen soll, find ich komisch, wenn auf einmal nur mehr der SSH geht und er Apache nicht und das genau nach dem Neustart.

Hab zufällig gerade vor 3 Stunden ein neues SSL Zertifikat eingespielt und getested - da ists noch einfwandfrei gegangen.

Also bitte Klartext reden und nichts schönreden, mit dem können wir hier nichts anfangen und es geht ein Haufen (Frei)zeit drauf mit Testen. Dann bis morgen!

Habe das Script auch in meinen Server eingespielt, hierzu aber eine Verständnisfrage:

Hätte versucht, das Script direkt in /etc/network/if-up.d/iptables zu legen, das funktionierte aber nicht. Als ich nur den Aufruf

#!/bin/bash
iptables-restore < /etc/firewall-rules
exit 0

reingeschrieben und die Rechte gesetzt habe ging es einwandfrei. Woran liegt das?

Okay - gibt es eine andere Möglichkeit der Wiederherstellung?

Liebe netcup-Gemeinde,

unglücklicherweise löschte ich mir einige Daten auf meinem Server, welche zwar nicht kritisch sind, von denen es aber doch eine Erleichertung wäre, sie wieder zu sehen.

Ich stieß in meiner suche nach einem Recovery-Programm auf extundelete. Ich installierte es und stehe nun dabei an, den laufwerksbuchstaben (lt. df ist das /dev/hdv1) anzugeben. Der wird von dem Programm aber nicht gefunden.

Ich führe es aus mit

extundelete /dev/hdv1 --restore-directory /pfad/zum/geloeschtem/Ordner

und es kommt die Fehlermeldung

"extundelete: No such file or directory /dev/hdv1
extundelete: No such file or directory when trying to open filesystem /dev/hdv1"

bei einem ls in /dev erscheint die Partition auch nicht.

Stehe ich auf der Leitung oder ist dies auf meinem vServer nicht möglich?

Liebe Grüße und vielen Dank im Voraus!

Zitat von vmk

Wer erzählt so etwas? Steht das nicht im Widerspruch zu http://en.wikipedia.org/wiki/Shellcode?

Muss sagen, von dem habe ich noch nie was gehört, aber genau deswegen finde ich den Thread so interessant, vielen dank für deinen Beitrag!

Soweit ich mich da jetzt eingelesen habe, kann ein solcher Angriff nur durchgeführt werden, wenn ein Zugriff auf die Maschine besteht bzw. wenn eine verwendete Software einen Fehler aufweist und einen Exploit ausführen kann. Das stimmt soweit oder?

Natürlich ist es in diesem Fall hilfreich, wenn ein untentdeckter Fehler ausgenützt wird. Dann wird dieser durch die Firewall blockiert.

Ich war auch ganz verwundert als mir mal wer sagte: Du brauchst keine Firewall, denn wo nix lauscht da kann nix rein. Hat damals meine ganze Welt zusammengehauen - ist aber wahr hab ich mittlerweile festgestellt

So, endlich nun auch den letzten Server dem Update unterzogen. Hatte zusätzlich zu dem MySQL-Reinstall-Problem noch das problem, dass ich die Config-Datei /etc/mysql/my.cnf anpassen musste und zwar, den Befehl "skip-db" kommentieren:

# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
#skip-bdb
#
# * InnoDB

Dann ließ sich der Server wieder ohne die Meldung "failed" starten.

lg

Danke an netcup für die nette Mail!

Bei mir wurde auf meinem Debian lenny folgendes aktualisiert:

apache2 apache2-mpm-prefork apache2-utils apache2.2-common - denke das dürfts gewesen sein.

Danke gadox für die Idee, sicher eine Überlegung wert!

danke für den Tipp, gleich mal schaun wie das geht

Hatte am nächsten Tag eine neue IP bekommen (LEASE abgelaufen) und mit der funktionierte dann wieder alles wie vorher - sehr komsich dass das von der IP abhängt...