flaschenkind
Well-known member
- 20 April 2006
- 4.507
- 337
Zufällig den Port geändert? 
Ich komme nicht mehr auf meinen vServer
- Ersteller Killerbear
- Erstellt am
Killerbear
Well-known member
- 20 April 2006
- 819
- 40
DelphiKing
King with a crown
- 20 April 2006
- 6.554
- 729
Killerbear
Well-known member
- 20 April 2006
- 819
- 40
jo ich weiß ^^
Aber wenn wir schonmal dabei sind.
Scheinbar laufen bei mir die cron jobs ja nicht einfach, wenn ich sie in den jeweiligen Ordner kopiere.
Wie ich letztens schon geschrieben habe, hatte ich gelesen, dass man das automatische Starten aus den Ordner vorher im crontab festschreiben muss.
Ist das bei dir Xot nicht so? oder wie sieht bei der crontab aus?
Außerdem wollte ich mal fragen ob die Sicherheitsmethode mit den Fingerprints schon jemand ausprobiert hat.
Funktioniert das? Lohnt sich das überhaupt oder würde es vielleicht bloß reichen das root login zu verbieten und den Port zu ändern.
ich hab auch was vom verbieten des ssh logins gelesen.
Aber wenn ich den ssh login verbiete. Wie komm ich denn dann auf den server?
Wie hab ihr denn eure Server abgesichert?
Kann man irgendwas empfehlen?
Aber wenn wir schonmal dabei sind.
Scheinbar laufen bei mir die cron jobs ja nicht einfach, wenn ich sie in den jeweiligen Ordner kopiere.
Wie ich letztens schon geschrieben habe, hatte ich gelesen, dass man das automatische Starten aus den Ordner vorher im crontab festschreiben muss.
Ist das bei dir Xot nicht so? oder wie sieht bei der crontab aus?
Außerdem wollte ich mal fragen ob die Sicherheitsmethode mit den Fingerprints schon jemand ausprobiert hat.
Funktioniert das? Lohnt sich das überhaupt oder würde es vielleicht bloß reichen das root login zu verbieten und den Port zu ändern.
ich hab auch was vom verbieten des ssh logins gelesen.
Aber wenn ich den ssh login verbiete. Wie komm ich denn dann auf den server?
Wie hab ihr denn eure Server abgesichert?
Kann man irgendwas empfehlen?
Du hast anfangs schon geschrieben, das du keinen Plan von Servern usw. hast, dementsprechend und von dem was du schreibst, hast du genausoviel Ahnung von Linux. Ich würde dir daher empfehlen deinen Provider zu bitten den Server auf Windows umzustellen.
Das hat in erster Linie den Hintergrund, dass du (möglicherweise) ein besseres Verständnis von Windows hast als von Linux und es dir dort leichter fällt, vorinstallierte Dienste zu konfigurieren.
Generelles Sicherheitsverständnis entwickelt sich bei jedem anders und ist immer ein potenzielles Streitthema, empfehlen kann man dir da nichts. In erster Linie dadurch, dass du nicht die nötigen Vorraussetzungen hast, die Empfehlungen umzusetzen und uns die Rahmenbedingungen nicht bekannt sind die du benötigen würdest. So Spielereien wie fail2ban usw. sind zwar lustige Spielzeuge, aber keine ernstzunehmenden Anwendungen.
Wenn du dir autodidaktisch den Umgang mit Linux beibringen möchtest, solltest du auf deinem Hauptrechner eine Linux Distri die gut dokumentiert ist installieren und damit arbeiten. Empfehlen kann ich debian z.B. als mini-install, nicht empfehlen kann ich ubuntu, SuSE, gentoo, fedora/redhat.
Zudem solltest du bei einer Server Distri die direkt am Netz hängt auf Stable setzen und die unstable oder gar testing branches nur im LAN nutzen.
Aktuelle Statistiken von Symantec legen zugrunde, dass ~90% der mit Würmer und Trojanern infizierten PC's ein Windows System als Betriebssystem haben und 90% des Spamaufkommens von gekaperten oder schlicht falsch konfigurierten Linux Systemen stammen. Welches mögliche Übel du mit einem erhöhtem Nichtwissen über Server in Kauf nehmen möchtest überlasse ich dir.
Plattformübergreifend, kann ich dir empfehlen dich mit dem Thema Netzwerktechnik auseinander zu setzen, zusätzlich solltest du ein Grundwissen haben zu Themen wie Routing, Ports, Protokolle, Dienste.
Den Port des SSH zu ändern hat übrigens nicht den Zweck irgendetwas zu sichern, sondern um kein Rauschen mehr im auth.log zu haben. Das deaktivieren des root-Logins soll dabei das Konzept hervorheben, als user zu arbeiten und nicht als root. Beides bringt dir, auch wenn es aus o.g. Gründen sinnvoll ist, nicht mehr Sicherheit.
Grüße
Sebastian
flaschenkind
Well-known member
- 20 April 2006
- 4.507
- 337
Verhindert immerhin, dass niemand per Bruteforce das Passwort knackt
Und wieso nicht? Sind die unsicherer als Debian?
Sicherheit liegt jawohl immer in der Hand des Administrators, und wenn der mit einem Gentoo System umgehen kann, wieso nicht? Für Anfänger ist das natürlich nichts, falls du das meintest...
Aber, dass du Ubuntu nicht empfehlen kannst, versteh ich auch nicht. Für Anfänger ist die Distribution doch optimal und deutlich einfacher als z.B. Debian. Es basiert auf Debian, hat viele Gemeinsamkeiten, und es gibt sogar eine Serverversion. Durch die strikte Nutzung von sudo für Root-Aktionen, bekommt der Nutzer so auch viel besser ein Gefühl dafür, was man als Root machen muss, und was nicht. Bei Debian haste sofort alles oder nichts und musst erstmal verstehen, warum du jetzt den Account wechseln musst.
Für den Produktiven Server Einsatz würde ich Ubuntu auch nicht verwenden, da die Pakete zu oft geupgraded werden und nciht so ausführlich getestet sind, wie bei Debian. Zum lernen aber vllt auch gar nicht so schlecht. Außerdem gilt auch hier, wer Ahnung von dem hat, was er tut, kann auch einen Ubuntu Server sinnvoll und sicher betreiben.
Naja, doch ein bisschen. Sollte jemand eine Bruteforce Attacke auf den root-Login machen, wird er niemals erfolg haben. Da er den Login-Account auch nicht kennt, kann er auf diesem Wege nicht in das System kommen.
Wenn das Passwort per Brute-Force knackbar ist, das hat derjenige ganz andere Probleme als fail2ban.Verhindert immerhin, dass niemand per Bruteforce das Passwort knackt
Das hat nichts mit der Sicherheit zu tun, er ist wie du erwähnt hast Anfänger, ubuntu und Gentoo sind Debian Forks, bei Gentoo kompilierst du dir einen Wolf und ubuntu ist klicki-bunti + Plug&Play per default, SuSE hat ein scheiss Image und redhat/fedora hat eine vergleichsweise kleine Community.
Wenn du Bruteforce als mögliche Angriff auf deinen Server siehst, solltest du dir vielleicht mal Gedanken machen dein Passwort zu wechseln. Jemand der bei einem Server Login ein Passwort nutzt das man Bruteforcen kann oder über ein Wörterbuch herausfindet, der ist ist mit einem Server komplett falsch beraten.
Grüße
Sebastian
ice-breaker
return void
- 27 April 2006
- 6.257
- 585
Hingegen hast du bei Debian eben auch Pakete die mehrere Jahre alt sind und für die es schon hunderte Nachfolger mit noch mehr Bugfixes gibt.
Hat alles seine Vor- und Nachteile.
Also ich persönlich unterscheide zwischen Sicherheitslücken und funktionalen Fehlern. Da du darüber so pauschal sprichst, wäre es schön wenn du genauer werden würdest. Ein Fehler in GIMP oder fluxbox wäre mir ziemlich egal, wenn ich beides nicht nutze.
Und komplett unabhängig von der Distri hat man ja immer die Möglichkeit des selber-bauens.
ice-breaker
return void
- 27 April 2006
- 6.257
- 585
das spielt in diesem Falle keine Rolle. Es gibt genug Softwarepakete in den Debian-Repos die unendlich alt ist und die Software inzwischen aus beiden Gründen upgedated wurde, dies jedoch nicht in den Debian-Repos auftaucht.
natürlich, aber irgendwer wird es trotzdem nutzen. Nur die Beispiele sind schlecht gewählt, da beides keine Programme sind, die auf einem Server laufen sollten.
Als Beispiel: in Debian ist momentan PHP 5.2.6 drinne, aktuell ist jedoch 5.2.14. Und da werden in jedem Release Sicherheitslücken behoben, alle paar Release sogar mal schwerwiegende Fehler, wie die Möglichkeit aus den Schutzfunktionen ausbrechen zu können.
natürlich gibt es die Möglichkeit immer, aber dann müsste man so ziemlich jede Software, die man installiert manuell kompilieren.
stable oder testin + unstable
Hallo
Ich kan die Philosphie von die hinter Debian-stable steckt für server nachvollziehen.
@icebreaker schrieb
klar die von 5.2.6 sind geschlossen, aber welche offenen in 2.6.14 gibt es!
wäre esd a nicht besser 5.2.6 zu nehmen, deshalb die altbackenen Paket in unstable.
Klar für den Desktop nicht prickelnd, aber davon reden wir nicht (ich selbst nutze lokal nur Sid).
Nur kompilieren von neueren Sachen bringt es ja auch nicht, aber @40073 hat da wohl auf den Desktop abgehoben.
wer einen Servr betreiben will, sollte sich Debian lokal installieren, schließlichj laufen wohl die meisten Server mit Debian.
Und das Abschotten eines Servers hört nicht bei fail2ban oder knockd auf. Außerdem muß fundiertes Wissen von Linux, Netzwerk, Webserver, ports, ect vorhanden sein, was aber die wenigsten user, die einen "Rootserver" betreiben, haben.
Die könne gerade mal ne ubuntu-Installation hinlgenbe und dan ist hängen im Schacht, schon das neusetzen des Rootpaßwortes , oder die reinstallation von grub in den MBR ist eine Hürde.
Wie soll so Jemand einen server sicher betreiben ?
Hallo
Ich kan die Philosphie von die hinter Debian-stable steckt für server nachvollziehen.
@icebreaker schrieb
ok, aber welceh Sicherheitslücken, ungefixt hat php 5.2.14 !!
klar die von 5.2.6 sind geschlossen, aber welche offenen in 2.6.14 gibt es!
wäre esd a nicht besser 5.2.6 zu nehmen, deshalb die altbackenen Paket in unstable.
Klar für den Desktop nicht prickelnd, aber davon reden wir nicht (ich selbst nutze lokal nur Sid).
Nur kompilieren von neueren Sachen bringt es ja auch nicht, aber @40073 hat da wohl auf den Desktop abgehoben.
wer einen Servr betreiben will, sollte sich Debian lokal installieren, schließlichj laufen wohl die meisten Server mit Debian.
Und das Abschotten eines Servers hört nicht bei fail2ban oder knockd auf. Außerdem muß fundiertes Wissen von Linux, Netzwerk, Webserver, ports, ect vorhanden sein, was aber die wenigsten user, die einen "Rootserver" betreiben, haben.
Die könne gerade mal ne ubuntu-Installation hinlgenbe und dan ist hängen im Schacht, schon das neusetzen des Rootpaßwortes , oder die reinstallation von grub in den MBR ist eine Hürde.
Wie soll so Jemand einen server sicher betreiben ?
Das stimmt so nicht.
Das Sicherheitskonzept von Debian verbietet es, Software ungetestet in einen Stable Zweig zu bringen. Daraus resultiert, das weiterhin PHP 5.2.6 auf debian in dem Stable Branch per installiert wird. Manuell kann man natürlich auch die debian Pakete oder die Sourcen des aktuellsten PHP installieren, das lohnt sich aber nur, wenn man auch auf die weiteren Änderungen von PHP 5.2.14 angewiesen ist.
Um es kurz zu machen, derzeit hat das aktuelle PHP Paket die Bezeichnung "5.2.6.dfsg.1-1+lenny9" welche aussagt, dass es das 9. Security Update ist. Alle Sicherheitslücken die in PHP 5.2.14 gefixt sind, sind in PHP 5.2.6.dfsg.1-1+lenny9 auch gefixt.
Server in einer Produktionsumgebung sind meist auf dieses Vorgehen angewiesen. Das VMS 1.2.4 wird z.B. mit PHP 5.3 nicht mehr funktionieren, da es auf folgende Funktion zurück greift. https://php.net/manual/en/function.ereg.php
Näheres zu den Sicherheitsupdates findest du hier
https://packages.debian.org/changelogs/pool/main/p/php5/php5_5.2.6.dfsg.1-1+lenny9/changelog
Im übrigen ist nicht zwingend jeder Bug der in 5.2.14 behoben ist in 5.2.6 überhaupt vorhanden.
Papslf58 du sprichst mir aus der Seele
Ich verwende sid bei mir im Netzwerk als Server für interne Dienste und Lenny auf Servern die auch öffentlich erreichbar sind.
ice-breaker
return void
- 27 April 2006
- 6.257
- 585
natürlich, das kann ich auch, ich wollte eben nur anmerken, dass es auch nicht immer optimal sein muss.
meine Anmerkung bezog sich schon auf erfahrene Serveradmins, und da spielt es keine Rolle ob du Debian, Ubuntu oder Gentoo nimmst. Du kannst mit allen das gleiche erreichen.
Unter Ubuntu hast du aber eben den Vorteil, dass du weniger selbst kompilieren musst, weil das Repo aktuelle Versionen hat.
Ich muss mittlerweile jegliche Software für meinen Debian-Server manuell kompilieren, weil die Versionen im Repo veraltet sind, von daher werde ich in Zukunft wahrscheinlich mal auf Ubuntu Server migrieren.
gut, das war dann ein schlechtes Beispiel
Ich verstehe auch das Konzept von Debian, keine Angst.
Selbst wenn alle Sicherheitsupdates eingespielt werden, bleibt es aber eben trotzdem, dass auf Grund der Debian-Philosophie kein Pakete auf neue Versionen upgedatet werden, was eben in vielen sehr alte Softwareversionen endet.
Also es geht mir nicht nur um Sicherheitsupdates, sondern vor allem auch darum, dass die Software einfach hoffnungslos veraltet ist.
Ich habe mir den Changelog zw. 5.2.6 und 5.2.14 angeschaut.
Der einzige Bugfix der für mich möglicherweise interessant sein könnte, wäre
Code:
Fixed bug #50255 (isset() and empty() silently casts array to object). (Felipe)Der Rest, betrifft im großen und ganzen PHP im Zusammenhang mit Apache, Windows, redhat, PostgreSQL, PDO, SOAP oder AIX.
Das kommt bei mir alles nicht zum Einsatz.
Ich bin aber gespannt, welche Änderungen dich betreffen, wodurch du mit 5.2.6 Probleme hattest, die mit 5.2.14 behoben sind.
Grüße