Beiträge von TPIT-Service

Da versucht einer mit vielen Anfragen, Zugangsdaten auf Deinen IMAPD-Server zu bekommen.
Ob das nun ein PHP-Script ist oder aber eine andere Methode kann man daraus nicht erkennen.

Du kannst die IP über die Firewall im VCP blocken, indem Du

Richtung: input - Quelle IP: 216.144.251.118 - Protikoll: any - Ziel IP: any - Aktion: DROP

definierst.

Danach sollte zumindest über diese IP Ruhe sein, ändert sich natürlich, sobald der Angreifer seine IP ändert.
Für fail2ban musst Du mal schauen. Hier im Forum gibt es einige Scripte die bei solchen Dingen dafür sorgen, dass solche Attacken automatisch in der Firewall landen. Warum das bei Dir nicht funktioniert, kommt einer Glaskugel gleich.

Hier kannst Du das testen: Mail relay testing

Zitat

Ubuntu liefert weitaus schneller / häufiger Updates aus als Debian, also
was da nun "dauernde upgraderei" gemeint ist, ist im Vergleich bei
Debian sogar eher wenig.

Für diesen Umstand nutzt man dann einfach ein paar andere Repos, z.B. die von DotDeb. Vor allem werden dort Sicherheitsupdates wesentlich schneller umgesetzt.
Ich habe keine Problem damit, wenn ich eh auf der Konsole bin, mal eben nach Updates zu schauen.

Ich kann zu CentOS auch nicht viel sagen, bisher war ich zu faul, mich damit zu beschäftigen. Reingeschaut habe ich schon mal und man muss sich halt an andere Befehle gewöhnen. Ansonsten haben hier wohl einige CentOS laufen, vielleicht gibt Dir da auch diese Woche noch einer Antwort.

Zitat

Welches der oben genannten OS bietet denn die bessere Community? Zurzeit
tendiere ich eher zu Ubuntu LTS, einfach weils von der Kommandozeile
eher an Debian erinnert.

Nicht weiter verwunderlich, ist es doch ein Ableger von Debian.

Ursache gefunden!
So trivial, wie auch leicht zu übersehen.

In der .htaccess stand folgende Anweisung, die ich jedes mal, vor lauter Bäumen, übersehen habe. Nennt man wohl Betriebsblindheit.

<FilesMatch "\.(png|gif|jpe?g|js|css|ico|php|xml|csv|txt|gz|swf|flv|eot|woff|svg|ttf|htm)$">
	RewriteEngine Off
  </FilesMatch>

PHP muss hier natürlich entfernt werden, im Prinzip also doch ein kleiner Schalter, mit großer Auswirkung.

Danke Dir, für Deine Mühe.

Danke Dir erst mal.
Aber das ist nicht nötig, meine Anweisungen funktioniert auf anderen Servern ja.
Genau das ist ja das Unverständliche dabei.

Hallo, da draußen!

Nun habe ich mal ein kleines Problem damit, den Aufruf von index.php auf eine Umleitung zu schicken.

Ich habe folgenden Code in die htaccess geschrieben:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ 
  RewriteRule ^index\.php$ http://www.domain.xyz/ [R=301,L]

Normal sollte das einwandfrei funktionieren, tut es aber nicht.

Eine Anweisung wie:

RewriteCond %{HTTP_HOST} ^domain\.xyz [NC] 
  RewriteRule ^(.*)$ http://www.domain.xyz/$1 [R=301,L]

funktioniert dagegen einwandfrei und die Adresse wird auch passend umgeschrieben.

Zusätzlich habe ich in den DNS-Einstellungen statische Subdomains angelegt (static1.domain.xyz), die auch korrekt für statischen Inhalt auf die Hauptdomain zeigen.
Wenn ich diese mit:

RewriteCond %{HTTP_HOST} ^static[0-9]\.domain\.xyz [NC]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule .* - [R=404,L]

, bei Direktaufruf, in ein 404 laufen lassen möchte, funktioniert das ebenso wenig.

Gibt es irgendwo in den Weiten der Häuptlingskonfiguration, Schalter die die Umleitung von index.php verhindern können?
Wenn ja, wo finde ich die?

Ich habe bei meiner Recherche keine Hinweise finden können, vielleicht habe ich auch nach den falschen Dingen gesucht.

Hast Du dem Konto, im Thunderbird auch mitgeteilt, dass es sich am SMTP mit den Benutzerdaten anmelden muss?

Kontoeinstellungen - *Benutzername und Passwort aktivieren* ankreuzen

So hieß das, glaube ich.
Wenn das nicht gleich funktioniert, auch mal die Verschlüsselung auf NIE setzen.

Bei Outlook nennt sich das - Der Postausgangsserver (SMTP) erfordert Authentifizierung. Dort muss man anhaken, dass Outlook sich mit den selben Daten wie Posteingangsserver anmelden soll. Bis jetzt musste ich das bei allen getesteten Images so machen, bei Froxlor war das, glaube ich, auch so.

Wenn das auch nicht hilft, könnte Dein Mailserver etwas verbogen sein. Da hilft nur Fehlermeldung bei Google eingeben und recherchieren.

Zitat

Was ist bei mir falsch: ich h abe btw Froxlor ATP als Image und da sollte eigentlich schon alles richtig sein?

Nein, auch andere Menschen machen Fehler, vergessen etwas oder es ist nicht zu 100% konfiguriert.

Man muss bei allen Images noch selber Hand anlegen. Jeder hat auch da eine andere Philosophie, die Netcup gar nicht alle abdecken kann.
Du kannst also davon ausgehen, dass Du nur einen Server mit Grundfunktionen hast. Die lassen sich im Produktiveinsatz zwar meistens nutzen, heißt aber nicht, dass der Server dann auch entsprechend Fehler frei läuft. Vor allem ist die Sicherheit längst nicht gegeben, was aber wieder ein anderes Thema ist.

Zunächst handelt es sich bei der Meldung nur um den Hinweis, dass das System die Tabellen kontrolliert und auf Fehler prüft.
Die Wortwahl ist für uns Deutsche etwas missverständlich, beinhaltet aber keinerlei Fehlermeldung.
Die Meldung ist bei Debian eine Standardmeldung und muss erst beachtet werden, wenn wirklich Fehlermeldungen kommen.

Was phpmyadmin anbelangt!?
Hast Du mal in die Logs geschaut, was Dein Häuptling dazu sagt?

Ich könnte in den blauen Dunst raten!
- MYSQL mag bestimmte Sonderzeichen nicht, da hilft Maskierung oder nicht verwenden in Passwörtern
-- dadurch dann falsches Passwort
- falsches Passwort generell
- falscher Benutzername
- phpmyadmin ist nicht richtig konfiguriert
etc.

Alles Dinge, die Dir Deine Log-Dateien verraten können.
Fehlermeldungen sind auch wichtig, um das Problem vielleicht einzugrenzen.

Sollte gehen.

Hehe, ich habe mich gerade auf die vHosts gestürzt, das funktioniert logischer Weise auch.

Ich habe hier easyscp laufen und da musste ich erst mal etwas suchen, bis ich die richtigen Dateien gefunden hatte.
Nu wird alles gut, bzw. ist alles gut.

Wenn ich nicht immer die Angewohnheit hätte vor dem Aktivieren des Hirns Fragen zu stellen.

Danke Dir trotzdem.

In den DNS-Einträgen dürfte eine Wildcard dafür eingerichtet sein, das ist hier Standard.

* - A - IP_des_Servers

Guten Morgen!

Mache ich dazu einen Denkfehler?

Ich bin davon ausgegangen, dass man Subdomains über einen CNAME-Eintrag auf die Hauptdomain zeigen lassen kann:
--> test CNAME domain.etc

Das funktioniert hier aber im CCP scheinbar nicht.
Ich habe vor weit mehr als 48 Std. Subdomains angelegt, die immer noch nicht auf die Domain zeigen.

Könnte es sein, dass ich an dieser Stelle noch etwas vergesse?

Vielen Dank für Eure Hilfe.

Momentan funktioniert das Backup tatsächlich nicht!
Ein Ticket dürfte unnötig sein, einige werden das sicherlich schon festgestellt haben.

Warum aber dieser Uraltthread ins Leben zurück geholt wird, entschließt sich mir nicht?

Da ist was verschluckt worden?

Zitat

RewriteEngine on

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^http://(www.)?exampleDomain.com(/.*)?$ [NC]

RewriteRule .(gif|jpg|GIF|JPG|png|PNG)$ http://www.exampleDomain.com/forbidden.jpg

Alles anzeigen

Das forbidden.jpg kannst Du natürlich durch jegliche Grafik ersetzen.
Und ROOT ist schon richtig.

Du kannst auch die letzte Zeile mit dieser ersetzen:

Zitat

RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]

dann sollte eine 404-Fehlermeldung kommen.

Eigentlich sollten die Bilder auf der Seite angezeigt werden. Erst wenn Du sie auf einer Fremdseite versuchst zu verlinken, sollte das nicht funktionieren.

Zitat

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www.)?exampleDomain.com(/.*)?$ [NC]
RewriteRule .(gif|jpg|GIF|JPG|png|PNG)$ http://www.exampleDomain.com/forbidden.j

Google hätte Dir das aber auch in den ersten Ergebnissen verraten.

Ich habe eine Umschulung zum FiSi gemacht und kann im Nachhinein abraten.
Ohne Vitamin B geht in der IT-Welt fast nichts.
Es gibt einfach zu viele 3 Wochen Lehrgangsadministratoren, die für billiges Geld den Firmen zum Sparen verhelfen.

Heute bin ich der Meinung, wäre ich lieber in die Softwareentwicklung gegangen. Bei den heutigen Jobangeboten drängt sich dieser Gedanke immer mehr auf.

Ich möchte Dich keineswegs verunsichern und Du sollst den Weg gehen, den Du möchtest, es stellt lediglich meine Erfahrung mit FiSi dar.
Wir waren damals 26 Umschüler von denen gerade mal 5 in der IT-Welt arbeiten. Und wenn Du den IT-Arbeitsmarkt etwas studierst, wird Dir der Mangel an FiSi-Stellen auffallen. Ein Blick ins Arbeitsmarktportal sagt da schon alles.

Solltest Du Dich aber für FiSi entscheiden, such Dir eine Firma, die ausbildet und keine Schule. Die Erfahrung in der Firma wiegt weitaus mehr, als ein paar Wochen Praktikum im Betrieb.
Oft bilden diese Firmen Bedarfs mäßig aus und die Chancen danach übernommen zu werden sind weitaus höher.

Lass Dich nicht unter kriegen. Du stellst die Weichen für Deine Zukunft und die sollte wohl überlegt sein.
Viel Glück.

Zitat

Ich hatte bisher keine Probleme und mir sind die Sicherheitsaktualisierungen auch schnell genug.

Mag sein, aber das kann schneller kommen als man denkt.
Nichts für Ungut, mir ist es egal, was ein anderer Admin mit seinem Server anstellt, es sei denn, dadurch wird meiner auch komprimitiert.
Auch diese Möglichkeit gibt es durchaus und kann einen Schwanz von Ärger hervor rufen.

Falsches Sicherheitsdenken und nur ein Teil von einer Sicherheitsstrategie!

Es gibt auch ganz andere Einfallstore, die teilweise sehr lange von Debian nicht gefixed werden. Und genau das meine ich. Hier geht es ja nicht nur um Debian selber, sondern die Pakete, die zur Verfügung gestellt werden. Dotdeb reagiert um ein Vielfaches schneller las Debian selber.

Auch wenn ich generell etwas mit der Aktualität der Kernels Probleme habe, sorgt Netcup doch zumindest bei Sicherheitsfragen für schnelle Reaktionen.
Ich erinnere auch nochmal daran, dass der Serverbetreiber selber für Sicherheitsfragen am Server verantwortlich ist.

Zitat

Stimmt vermutlich, ich denke nur man sollte den Mirror von Netcup nehmen wegen Geschwindigkeit/Kosten:

Wie kommst Du denn auf den Gedanken?

Die Debian-Pakete hinken sehr oft Wochen oder Monate lang hinterher.
Ich verwende die Dotdeb Repos und auch das Sicherheits-Repo.
Dotdeb ist oft wesentlich schneller und vor allem aktueller und das gilt nicht nur für den Server und das Sicherheits-Repo halte ich ebenso für wichtig, da dort Lücken sehr schnell geschlossen werden, die bei Debian eben warten lassen.

Jeder sollte selber wissen, was für ihn das Beste ist und ich finde das verallgemeinern etwas unsicher.
Allerdings darf man gerne seine Erfahrungen und Meinungen sagen.

Über eine schwere Sicherheitslücke in PHP 5.3.9 lässt sich Code einschleusen und ausführen, auch von entfernten Rechnern. Mit der Sicherheitserweiterung Suhosin lässt sich die Lücke schließen.

Über einen schweren Fehler in der Skriptsprache PHP 5.3.9 lässt sich auch über das Netzwerk Code einschleusen und ausführen. Ein Patch ist in der Entwicklerversion von PHP bereits eingeflossen, steht aber in der stabilen Version noch aus. Zunächst wird eine reparierte Version über die Snapshot-Server snaps.php.net und windows.php.net zur Verfügung gestellt. Ob der Bug auch in älteren Versionen behoben wird ist ebenfalls unklar. Bislang gibt es noch keine offizielle Beschreibung vomPHP-Team. Ein Workaround ist ebenfalls noch nicht bekannt.

Die Lücke entstand durch einen Patch, der eine weitere Sicherheitslücke schließen sollte, die Denial-of-Service-Angriffe über Hash-Kollisionen verhindert. Um solche DoS-Angriffe zu verhindern, wurde der Wert von max_input_vars in php_variables.c auf 100 herabgesetzt. Allerdings schlich sich bei der Implementierung dann der aktuelle Fehler ein.

DieSicherheitserweiterung Suhosin soll von der Lücke nicht betroffen sein.Der Suhosin-Patch bietet weniger Sicherheit. Laut Suhosin-Entwickler Stefan Esser kann vorübergehend die Variable max_input_vars auf einen hohen Wert gesetzt werden, etwa 1 Milliarde. Dann sei PHP wieder anfällig für DoS-Angriffe, könne aber nicht durch Schadcode kompromittiert werden.

Quelle: golem.de