Moin
Auf Deinem Port 143 lauscht kein IMAP-Server.
Der müsste sich beim telnet melden.
Mordor
Moin
Auf Deinem Port 143 lauscht kein IMAP-Server.
Der müsste sich beim telnet melden.
Mordor
Moin
Installiere Dir im Firefox mal die Live HTTP Headers und protokolliere die Sitzung von der Anmeldung, bis Du wieder rausfliegst.
Die kannst Du mir per E-Mail schicken (E-Mail senden im Profil). Ich schau mir das gerne mal an.
Mordor
Moin
ist Froxlor nun endgültig Geschichte ?
Nein. Die Seite geht mittlerweile wieder.
Nur weil die Seite mal nicht erreichbar ist, heisst das noch lange nicht, daß das Projekt gleich eingestellt ist.
... ich schauen wollte ob die 0.9.29 schon verfügbar ist ...
Ist sie noch nicht.
Mordor
Moin
Das heisst also, ich habe über das netcup Control Panel Terminal-Zugriff auf meinen Server. Unabhängig von meinen iptables-Einstellungen?
Ja.
Zu dem ersten Punkt. Muss ich mir noch um Sicherheitseinstellungen Gedanken machen, wenn alle Zugriffe (außer derer von meiner statischen IP) per iptables deaktiviert sind?
Natürlich musst Du das. Einfach nur einen Server installieren, mit iptables alles blocken und nix weiter machen reicht nicht aus.
Von deinem Rechner aus ist der Zugriff noch möglich (stw. Trojaner) und der Server ist auch nicht nur von Dir erreichbar, sondern von jedem. Nur das er anderen IP-Adressen den Zugriff verweigert.
z.B.: Könnte dein iptables-Skript versagen, oder dein Server wird mit einer gespooften IP-Adresse (Deiner) angegriffen. Auch dann brauchst Du noch immer ein sicheres System.
Und wenn was passiert, solltest Du mindestens belegen können, das Dein System ein vernünftiges Sicherheitskonzept hat (nicht nur iptables).
Mordor
Moin
Das wird ganz sicher nicht möglich sein.
Dazu müsste netcup Zugriff auf deinen Server bekommen. Und das dürfte weder im Interesse von netcup oder ihrer Kunden liegen.
Mordor
Moin
Access Denied deutet darauf hin, das Du die falschen Anmeldedaten verwendest.
Für die Rettungskonsole bekommst Du ein eigenes Passwort.
Im Zweifelsfall mal mit einem eigenen Profil im Putty anmelden und nicht das normale verwenden.
Mordor
Moin
Was steht denn in deinem Fehlerlog (php) drin?
Deine Seite liefert noch einen Teil des Headers aus und bricht dann ab. Da müsstest Du im LOG sehen können, was schief läuft.
Mordor
Moin
Warum ist es da nicht möglich, einen e.V. als Domaininhaber zu deklarieren?
Selbstverständlich kann ein Verein (Organisation, Firma) als Domaininhaber eingetragen werden.
Da kann es höchstens Probleme mit der Vertretungsvollmacht lt. Satzung geben (z.B. keine Einzelvertretungsbefugnis). Das liegt dann aber an dem Domainprovider/Registrar.
Als Admin-C muss in jedem Fall eine natürliche Person eingetragen werden. Das ist aber immer so (auch bei Firmen).
Mordor
Moin
Froxlor hat mit E-Mails selber gar nichts zu tun. Damit erledigst Du nur einen Teil der Verwaltung.
Du musst Postfix so konfigurieren, das es E-Mails von dir (und nur Dir) entgegennimmt und die dann weiterleitet.
Am einfachsten erstellst Du mit Froxlor ein Postfach und läßt dein Postfix alle E-Mails weiterleiten, die mit den Zugangsdaten dieses Postfaches gesendet werden.
Mordor
Moin
falsch, kann man. Undzwar mit su - innerhalb des shellscripts.
Damit änderst Du nur den User für die von su gestartete Subshell.
Für die laufende Shell (das laufende Skript) gibt es keine Möglichkeit, den User zu ändern.
Mordor
Moin
Das sieht so aus, als ob der normale init-prozess angeszogen wird. Der funktioniert auf den vservern nicht.
Gibt es die /etc/rc.d/rc.sysinit.vserver bei Dir?
Mordor
Moin
Die Rückwandlung eines Hashes zum ursprünglichen Klartext ist nicht möglich. Selbst bei MD5 geht das nicht und das ist eines der schwächsten Verfahren.
Es ist nur möglich, per Brute Force einen beliebigen Klartext zu finden, der dann den gesuchten HASH ergibt (Kollision).
Der Salt wird verwendet, um einen Angriff auf die Passworte mit Hilfe von Rainbow Tables zu verhindern (und nur dazu dient meinem Verständnis nach ein Salt).
Also das für eine Liste von Hashes nur einmal ein Angriff erfolgen muss, und dann für alle Hashes ein zugehöriger Klartext aus einer Tabelle abgelesen werden kann.
Denn das würde den Aufwand für einen Angriff deutlich reduzieren, wenn die Zahl der angegriffenen Hashes groß genug ist (wie bei MD5 geschehen).
Damit ein Salt funktioniert, muss jeder Account einen eigenen Salt erhalten, der natürlich bekannt sein muss. Der Salt wird deshalb üblicherweise zusammen mit dem Hash gespeichert.
Hat der Angreifer Zugriff auf den Hash, kennt er normalerweise auch den Salt (oder kann ihn sich verschaffen).
In der Praxis erhält man durch den Salt (vereinfacht gesagt) ein längeres Passwort und dadurch verlängert sich dann auch der Rechenaufwand für einen BF-Angriff (Ich schätze, darauf spielen Sie an).
Der Rechenaufwand wird aber nicht geringer, nur weil der Salt bekannt. Das geht ja trotzdem bei jeden Versuch in die Berechnung mit ein.
Für einen Angriff von außen (regulärer Login, ohne Kenntnis des Hashes) ist der Salt sowieso wertlos. Der berechtigte User meldet sich ja auch nur mit dem Passwort an.
In dem Fall bringt ein Salt also keinen Sicherheitsgewinn und eine Veröffentlichung schadet nicht, da der Salt für die Anmeldung nicht gebraucht wird.
Mordor
Moin
felix: Ein Salt kann problemlos veröffentlicht werden. Das schmälert seinen Wert in keiner Weise.
Da das VCP per https erreichbar ist, braucht es aber eh keine clientseitige Hashfunktion des Passwortes. Die soll ja nur die Klartextübertragung verhindern.
Im übrigen kann man den Salt auch von bekannten Daten ableiten. Er müsste also nicht mal übertragen werden.
Mordor
Moin
Kopiere eine Datei '.test' auf deinen Webspace.
Wenn Du die Datei siehst -> aktiv
Mordor
Moin
Kannst du mir bitte für a) und c) ein Beispiel geben?
zu a) Ein Key ist im Prinzip nur ein langes und sicheres Passwort. Du bekommst also keine höhere Sicherheit, nur weil Du eine Key-basierte Anmeldung verwendest.
Das Verfahren ist in der Praxis nur deshalb sicherer, weil die meisten Menschen eben keine sicheren Passwörter verwenden können/wollen und man beim Key-Verfahren wahrscheinlich (!) keine schlechten Keys erstellen kann. Ein schlecht gesicherter Key (ohne gutes Passwort) auf dem Client, kann die Sicherheit aber leicht aushebeln und dann ist das Key-basierte Verfahren insgesamt auf einmal unsicherer, als ein Login mit
einem guten Passwort.
Oder kurz:
Die Argumentation "Ich verwende jetzt Keys zur Anmeldung und deshalb darf sich root direkt anmelden ohne die Sciherheit zu verringern" ist so falsch.
zu c) Wenn ich einen Shell-Zugang auf einem System habe, finde ich auch eine Möglichkeit um mir irgendwie Root-Rechte zu verschaffen. Dazu muss ich das Passwort für den root-Zugang nicht rausfinden. Wichtig ist daher, das Du den Login-Account genauso gut absicherst, als wäre es der root-Account. Sonst bringt Dir der User-Account keine zusätzliche Sicherheit.
Mordor
Moin
a) Ein key-based-login ist nicht sichererer als ein gut gesicherter Login mit einem komplexen und sicheren Passwort. Die Umstellung auf den key-based Login ist also per se kein Grund den root-login auf einmal zu erlauben zu erlauben.
b) root ist ein bekannter Angriffsvektor. Deshalb verwendet man einen anderen User, dessen User-ID nicht offensichtlich (leicht zu erraten) ist.
Du könntest auch root umbenennen. Damit schaffst Du aber andere Probleme.
c) Wenn ein Angreifer erst mal einen shell-Zugang auf deinem System hat, kann er sich auch zugriff auf den root-Account verschaffen. Du solltest daher alle Maßnahmen ergreifen, damit ein Angreifer keinen Shell-Zugang bekommt.
Meine Empfehlung. Bleib bei key-Login und non-root-User
Mordor
Moin
ich stelle nicht in Abrede das Ihr Verhalten vertragswidrig ist, ...
Ich nehme an, das wolltest Du anders formulieren, oder?
Ein Raidsystem , auch wenn es nur ein Raid 2 ist suggeriert ihren Kunden durchaus das die bei Ihnen gespeicherten Daten sicher sind.
Ein RAID 1.
Kein RAID-System ist sicher. RAID heiß nur, das ein (!) Festplattendefekt nicht zum Verlust der Daten führt. Einen absoluten Schutz vor Datenverlust kann kein RAID-System bieten.
Das sind sie jedoch definitiv nicht , insbesondere wenn so latent mit den Systemen umgegangen wird...
Was willst Du damit denn ausdrücken?
In der Vergangenheit habe ich bei anstehenden Wartungsarbeiten immer ausreichend Zeit gehabt meine Daten zu sichern, dies war dieses mal nicht der Fall, gerade mal 12 Stunden!
Mit einer adäquaten Backupstrategie sind 12h mehr als ausreichend Zeit um die Datensicherung auf den aktuellen Stand zu bringen. Wenn die kurze Vorwarnzeit auf den technischen Defekt zurückzuführen ist (wovon ich ausgehe), kann netcup da auch nichts dran ändern.
Und ich befand mich auf Geschäftsreise.
Das ist Dein Problem.
Also stellen sich mir durchaus berechtigt Zweifel an Ihrer Zuverlässigkeit.
Interessante Schlussfolgerung.
Ein Tipp für die Zukunft. Sowas solltest Du direkt mit der Geschäftsleitung klären und nicht über das Forum.
So lassen sich Probleme meistens schnell aus der Welt schaffen (weiß ich aus eigener Erfahrung mit netcup).
Mordor
Moin
Dann müsstet der Anbieter mir aber auch nachweisen, dass ich ein Produkt bestellt habe bevor ich eine Rechnung/Mahnung bekomme.
Das muss der Anbieter ja auch, wenn Du die Forderung bestreitest.
Aber für den Anbieter ist der Schaden in dem Fall kalkulierbar und liegt nur bei dem Anbieter. Der Kunde hat in dem Fall normalerweise nichts von einer falschen Behauptung.
Bei einer falschen Kündigung liegt der (mglw. hohe) Schaden und damit das finanzielle Interesse beim Kunden, die Beweislast trifft aber den Anbieter.
Mordor
Moin Timon
Es muss auf jeden Fall ein Eintrag im mail.log existieren. Mindestens von der angenommenen Mail.
Poste bitte mal den Auszug aus dem Logfile, wenn Du eine Testmail gesendet hast (von einer Internen und einer externen Mailadresse).
Außerdem main.cf und master.cf (Postfix).
Mordor