V-Server absichern notwendig?

[mR. bluE]

Hi,
ich hab nen kleinen (im grunde nen winzigen) V-Server angemietet um Psybnc darauf laufen zu lassen, als OS ist Debian 3.1 installiert, ausser Psybnc hab ich nix installiert, denkt ihr es ist notwendig den irgendwie noch zu sichern mit einer Firewall (Da sind die Meinungen ja sehr Unterschiedlcih wenn man mal im Ubuntu Wiki nachschaut) oder über Host rules zbsp.?
Oder ist der eigentlich so gut wie nicht angreifbar da da sonst nix draufläuft?
Also wenn der geknackt werden würde, hätte ich nur Angst das da einer irgendwelche schindluder mit der Kiste treibt und ich ja im Grunde Verantwortlich bin für das Teil. Neuinstalliert ist der ja mit nem Klick

[Tintom]

Oder ist der eigentlich so gut wie nicht angreifbar da da sonst nix draufläuft?

Grundsätzlich ist alles angreifbar, was am Netz hängt. Insofern unbedingt den Server absichern, lieber "paranoide" Sicherheitseinstellugen nehmen für den Fall der Fälle.

als OS ist Debian 3.1 installiert

Du solltest dringend auf Debian 4.0, besser noch nach dem Update von 4.0 auf 5.0 updaten. Für 3.1 (Sarge) gibt es seit längerem keine Sicherheitsaktualisierungen mehr.

Gruß

[mR. bluE]

....lieber "paranoide" Sicherheitseinstellugen nehmen für den Fall der Fälle.....

also doch ne firewall installieren, oder was meinste für Sicherheitseinstellungen, upgrade auf n neues Debian geht leider nicht, selbstständig ein OS installieren kann ich ja net, ich hock ja net davor und n neueres bieten die leider net an (hat mich auch gewundert)

[mR. bluE]

achja zum Thema Firewall hab ich halt das hier gelesen, von daher dacht ich das ich mir das gefummel mit den IP tables sparen kann

[Alternativende]

Darf man wissen warum du meinst kein Update machen zu können?
Wenn du Sarge weiter betreibst dann hast du ja unzählige Sicherheitslücken im Kernel, DNS etc. etc. die bei dir ja nicht gefixt worden sind. Du könntest das natürlich manuell machen, aber das ist wirklich eine Menge Arbeit.

[mR. bluE]

mhhh ja also das mit dem update ist mir auch gerade eingefallen, ich les mich da auch gerade ein wenig ein, kann sein das ich lediglich

Code: Alles auswählen

apt-get update

und

Code: Alles auswählen

apt-get upgrade

und

Code: Alles auswählen

apt-get dist-upgrade

machen muss?

Also Update steht dafür das Sicherheitsupdates eingespielt werden und Upgrade für das Aktualisieren aller Installierten Pakete, und Dist-Upgrade das ich dann zum nächsten stable komme, lieg ich damit etwa richtig? Das scheint mir ja eigentlich viel zu einfach, um wahr zu sein
Sorry aber ich Blick da gerade net so ganz durch die debian_refferenz.pdf ist in dem Bezug auch ein wenig minimalistisch

[Spasswolf]

Du muss auch deine /etc/apt/sources.list entsprechend anpassen (zuerst auf etch). Je nach dem bei dem Vserver verwendeten Kernel ist ein Update auf Lenny auch unmöglich.

[Tintom]

Also Update steht dafür das Sicherheitsupdates eingespielt werden und Upgrade für das Aktualisieren aller Installierten Pakete, und Dist-Upgrade das ich dann zum nächsten stable komme, lieg ich damit etwa richtig? Das scheint mir ja eigentlich viel zu einfach, um wahr zu sein
Sorry aber ich Blick da gerade net so ganz durch die debian_refferenz.pdf ist in dem Bezug auch ein wenig minimalistisch

apt-get bzw. aptitude update updatet dir nur die Paketlisten von apt, aktualisierte Software kommt mit apt-get bzw. aptitude dist-upgrade rein.
Am besten mal im debiananwenderhandbuch[1] nachschlagen, das ist sehr empfehlenswert.

Gruß

--
[1] http://debiananwenderhandbuch.de/apt-ge ... 0Kommandos

[mR. bluE]

ich hatte mich geirrt. es war schon etch installiert.

Code: Alles auswählen

aptitude update

und

Code: Alles auswählen

aptitude dist-upgrade

habe ich erstmal etch auf den neusten stand geholt, war auch dringen nötig wegen der Sicherheitslücke in OpeenSSL

also soweit ich das verstanden habe muss ich jetzt nur noch meine /etc/sources.list

deb http://ftp.de.debian.org/debian etch main
deb-src http://ftp.de.debian.org/debian etch main

deb http://security.debian.org/ etch/updates main contrib
deb-src http://security.debian.org/ etch/updates main contrib

abändern in

deb http://ftp.de.debian.org/debian lenny main
deb-src http://ftp.de.debian.org/debian lenny main

deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib

und danach wieder

Code: Alles auswählen

aptitude update

und

Code: Alles auswählen

aptitude dist-upgrade

und schon hab ich lenny laufen. Ist das wirklich so simple?
Ein Kernel update muss ich dann aber getrennt noch vornehmen, oder?

[Tintom]

und schon hab ich lenny laufen. Ist das wirklich so simple?
Ein Kernel update muss ich dann aber getrennt noch vornehmen, oder?

Ja, ist so "simpel".
Kernelupdate sollte auch installiert werden, um sicherzugehen kannst du das passende Metapaket zu deinem Kernel installieren, das zieht als Abhängigkeit immer den aktuellsten Kernel hinter sich her, der gerade für das Release verfügbar ist.

Gruß

[jeff84]

Kernel ist normal bei V-Servern zentral vom Host gestellt und somit nicht updatebar...

[Alternativende]

Den Reboot nicht vergessen .

[mR. bluE]

das ist ja toll, hat alles geklappt ausser kernel update, danke jungs ich bin immer mehr begeistert von debian

[mR. bluE]

so ich melde mich nochmal zu wort, ich hoffe ich nerve euch nicht, aber bevor ich folgendes mache wollte ich nochmal ein OK hören, nicht das ich mich selbst aussperre

in der /etc/hosts.deny

Code: Alles auswählen

sshd: ALL

und in der /etc/hosts.allow

Code: Alles auswählen

sshd: 88.69.*.*

ich habe nämlich in der /va/log/auth.log gesehen das mehrmals am Tag "jemand" versucht mit sshd zu verbinden, wenn ich das Mithilfe der IP-Range von vorneherein unterbinden könnte und der jenige erst gar net soweit kommt um ein PW auszuprobieren ist das schonmal ein Stückchen mehr Sicherheit

[jeff84]

wenn ich das Mithilfe der IP-Range von vorneherein unterbinden könnte und der jenige erst gar net soweit kommt um ein PW auszuprobieren ist das schonmal ein Stückchen mehr Sicherheit

Allerdings kommst du dann auch nicht mehr von wo anders auf den Server...

[Tintom]

Leg' doch einfach deinen sshd auf einen anderen Port ( einstellbar in der /etc/ssh/sshd_config ).

Gruß

[mR. bluE]

Leg' doch einfach deinen sshd auf einen anderen Port ( einstellbar in der /etc/ssh/sshd_config ).

Gruß

@Tintom das würde man doch mit nem scanner einfach rausbekommen welche ports genutzt werden, abgesehen versucht der Angreifer ohnehin den anderen Port den ich noch nutze durch wie ich im auth.log sehe
@jeff84 das ich dann nicht von ner anderen IP connecten kann ist logisch, das ist ja sozusagen der Sinn des ganzen

also kann ich die allow / deny Einstellungen so vornehmen oder muss da noch was anderes eingetragen werden?? Ich würde nur ungern mich selbst aussperren

[jeff84]

Ich meinte nur, dass du zum Beispiel bei nem Inet-Providerwechsel aufpassen musst. Und du kannst auch nicht schnell mal von unterwegs auf deinen Server...

[mR. bluE]

hi, also ich hab jetzt folgendes in die
etc/hosts.deny

Code: Alles auswählen

sshd: ALL
ALL: 210.200.19.95

etc/hosts.allow

Code: Alles auswählen

sshd: 88.69.*.*

eingetragen und ich bekomem dennoch jede sekunde folgenden LOG

Code: Alles auswählen

Aug 27 18:48:59 v6735 sshd[14210]: Invalid user ruslana from 210.200.19.95
Aug 27 18:48:59 v6735 sshd[14213]: input_userauth_request: invalid user ruslana
Aug 27 18:48:59 v6735 sshd[14223]: warning: /etc/hosts.allow, line 14: missing newline or line too long
Aug 27 18:48:59 v6735 sshd[14223]: warning: /etc/hosts.deny, line 20: missing newline or line too long

ich dachte das ich die IP 210.200.19.95 jetzt gebannt hätte und der gar net bis zur UN Eingabe kommt

[daniel74]

hi, also ich hab jetzt folgendes in die
etc/hosts.deny

Code: Alles auswählen

sshd: ALL
ALL: 210.200.19.95

etc/hosts.allow

Code: Alles auswählen

sshd: 88.69.*.*

eingetragen und ich bekomem dennoch jede sekunde folgenden LOG

Code: Alles auswählen

Aug 27 18:48:59 v6735 sshd[14210]: Invalid user ruslana from 210.200.19.95
Aug 27 18:48:59 v6735 sshd[14213]: input_userauth_request: invalid user ruslana
Aug 27 18:48:59 v6735 sshd[14223]: warning: /etc/hosts.allow, line 14: missing newline or line too long
Aug 27 18:48:59 v6735 sshd[14223]: warning: /etc/hosts.deny, line 20: missing newline or line too long

ich dachte das ich die IP 210.200.19.95 jetzt gebannt hätte und der gar net bis zur UN Eingabe kommt

Die Regeln werden nicht angewendet,da die Dateien nicht korrekt interpretiert werden. Du solltest am Ende der Dateien (hosts.allow/hosts.deny) noch jeweils eine Leerzeile einfügen,damit die obige Fehlermeldung nicht mehr erscheint und die Datei korrekt interpretiert werden können.

[mR. bluE]

hi,
danke Daniel, leider kam deine Antwort zu spät, ich hatte mich schon vom System ausgesperrt, offensichtlich dauert es ein paar Minuten bis das System die hosts.deny / allow dateien einließt ich konnte mich noch bestimmt 20min nach änderung einloggen und dann aufeinmal nicht mehr. Aber dank dir konnte ich über das sehr praktische Rescue System den Fehler gleich beheben ohne lang drüber zu grübeln
Ich Installier mir mal das Packet DenyHosts scheint ganz praktisch zu sein

[novalix]

Hi,

das Umbiegen des Standardports von ssh auf einen unpriviligierten Port bringt Dir zwar keinen direkten Sicherheitsvorteil (im Falle eines gezielten Angriffs), allerdings hilft es ungemein solche gezielten und damit tendenziell gefährlichen Angriffe von denen, die auf das Konto von Script-Kiddies gehen, zu unterscheiden.
Das Umbiegen des Ports (über 40000 bringt schon ne Menge) hält die Logs "sauber". Man gewöhnt sich erst gar nicht an die andauernden Einträge und kann sich somit auf die "echten" Gefahren konzentrieren.

Groetjes, niels