einmalige Absicherung eines Power-Server gesucht

[Perry_Rhodan]

Hallo,

vorhanden:
PowerServer S bei Strato
Ubuntu 8.04 LTS und Plesk 9.52

gesucht wird jemand, der einmalig den Server auf Schwachstellen untersucht, diese behebt und seine Arbeit dokumentiert.

Bitte mit genauen Preisvorstellung per PN an mich.

Gruß

Ulf

 

[DjTom-i]

Hallo Perry,

deine Anfrage ist nicht mal eben so zu beantworten.

Liegt aktuell ein Problem vor ?

Eine Absicherung des Servers ist kaum möglich. Dafür müsste man allen Benutzern, inkl. dir den Zugriff verweigern und die Internetverbindung kappen.

Was man machen kann sind konkrete Probleme genauer zu analysieren und ggfls dagegen vorzugehen.

Bei einem Plesk System hast du ausserdem eh nicht sooo viele Optionen.

Sinn macht ggfls ein Upgrade auf einen aktuellen Stand sofern Plesk da mitspielt.

 

[matzewe01]

Eine Absicherung des Servers ist kaum möglich.

Naja, ein wenig besser härten kann man das System schon.
Er sollte nur aufpassen, dass er nicht auf scharlatane herein fällt, welche "lediglich" die Firewall von Plesk aktivieren anstatt sinnvolle Dienstabsicherungen / Konfigurationen vor zu nehmen.

Ein Trugschluss im übrigen:
Einmal die Kiste härten und alles ist gut.
-> Später kommen sicherlich noch genug Anwendungen hinzu, die man genau prüfen müsste.

Realistisch wird hier eine Aufwand von bis zu 5 Tagen wobei ein entsprechender Profi gut und gerne ab 500.- EUR / Tag nehmen wird.
Ob allerdings Plesk eine richtig gehärtetest System mag, wage ich zu bezweifeln.

 

[Perry_Rhodan]

Hallo Perry,

deine Anfrage ist nicht mal eben so zu beantworten.

Liegt aktuell ein Problem vor ?

Eine Absicherung des Servers ist kaum möglich. Dafür müsste man allen Benutzern, inkl. dir den Zugriff verweigern und die Internetverbindung kappen.

Was man machen kann sind konkrete Probleme genauer zu analysieren und ggfls dagegen vorzugehen.

Bei einem Plesk System hast du ausserdem eh nicht sooo viele Optionen.

Sinn macht ggfls ein Upgrade auf einen aktuellen Stand sofern Plesk da mitspielt.

Naja, eine Absicherung ist schon möglich. Oder besser eine Optimierung. Und Plesk und Ubuntu sind immer auf den aktuellen Stand. (Naja fast immer, evtl. mal ne Woche nicht geupdatet.)

Folgende Punkte stelle ich mir vor.

- Kontrolle und evtl. Behebung von Fehlern bei mod_evasive
- Kontrolle und evtl. Behebung von Fehlern bei denyhost
- Kontrolle und evtl. Behebung von Fehlern apache2
- Kontrolle und evtl. Behebung von Fehlern php5
- Kontrolle und evtl. Behebung von Fehlern drweb

Desweiteren sollen angeblich von unserem Server sshd-Angriffe gestartet worden sein. Angeblich über einen root-Zugang. Nur kann man erstens mit root gar nicht auf unseren Server und zweitens ist ein Zugang per SSH nur mit Key möglich. Ich finde in den Logs nix auffälliges, aber das muß ja nix heißen.

Als kleine Zusatzaufgabe würde ich mich über ein Blocken von Angriffen auf unseren Server per iptables freuen. Habe dies bisher nie erfolgreich hinbekommen.

Hoffe, damit genau genug gewesen zu sein. Alles weitere könnte man zur Not auch per ICQ, Yahoo, Skype oder wie sie alle so heißen abwickeln. Auch per "altmodischem" Telefon ließe sich da kommunizieren.

Gruß

Ulf

 

[matzewe01]

Desweiteren sollen angeblich von unserem Server sshd-Angriffe gestartet worden sein. Angeblich über einen root-Zugang. Nur kann man erstens mit root gar nicht auf unseren Server und zweitens ist ein Zugang per SSH nur mit Key möglich. Ich finde in den Logs nix auffälliges, aber das muß ja nix heißen.

Vermutlich wird hier eine Brutoforceattacke gegen einen anderen Host gemeint.
-> also ausgehend ssh root@<host>
Das kann mit allem möglichen geschehen unter anderem auch einen phpBackdoor /Remotshellscript.

Als kleine Zusatzaufgabe würde ich mich über ein Blocken von Angriffen auf unseren Server per iptables freuen. Habe dies bisher nie erfolgreich hinbekommen.

Da kommen wir schon zu dem Punkt Scharlatanerie.
Eine sinnvolle Absicherung der Dienste durch gute Konfiguration reicht in 99,9 % aus.
Die restlichen 0,1% kann eine Firewall ala ipTables nicht verhindern.
[/QUOTE]

 

[DjTom-i]

- Kontrolle und evtl. Behebung von Fehlern bei mod_evasive
- Kontrolle und evtl. Behebung von Fehlern bei denyhost
- Kontrolle und evtl. Behebung von Fehlern apache2
- Kontrolle und evtl. Behebung von Fehlern php5
- Kontrolle und evtl. Behebung von Fehlern drweb

Genau durch solche Dinge passieren die wenigsten Server-Hacks.

In der Regel werden unsauber geschriebene Kundenscripte oder bekannte Sicherheitslücken in veralteten CMS ausgenutzt. Aber erzähl mal einem "Typo3 Kunden" das er sein Typo updaten soll... Womöglich macht er es dann auch noch, aber seine ganzen Extensions funktionieren nicht mit der aktuellen Version.

Mit mod_evasive zB. kannst du eher ungeübte Schüler abhalten deinen Apache in die Knie zu zwingen bzw. einen Denial of Service zu provozieren.

 

[Perry_Rhodan]

Vermutlich wird hier eine Brutoforceattacke gegen einen anderen Host gemeint.
-> also ausgehend ssh root@<host>
Das kann mit allem möglichen geschehen unter anderem auch einen phpBackdoor /Remotshellscript.

Da kommen wir schon zu dem Punkt Scharlatanerie.
Eine sinnvolle Absicherung der Dienste durch gute Konfiguration reicht in 99,9 % aus.
Die restlichen 0,1% kann eine Firewall ala ipTables nicht verhindern.

Hallo Matzewe01

zu Punkt 1.
Kann ich ein evtl. vorhandenes Shellscript finden? Dürfte doch nur im Domain-Ordner liegen, oder? Wobei nur... Da gibt es viiiiiele Dateien ...

Aber es muß ja als ausführbar gekennzeichnet sein, korrekt?

zu Punkt 2.
OK, hatte in einigen Posts gelesen, das es evtl. sinnvoll ist, die IP´s bei >3 Fehlversuchen beim Login temporär zu blocken. Daher mein Gedanke mit iptables.

Genau durch solche Dinge passieren die wenigsten Server-Hacks.

In der Regel werden unsauber geschriebene Kundenscripte oder bekannte Sicherheitslücken in veralteten CMS ausgenutzt. Aber erzähl mal einem "Typo3 Kunden" das er sein Typo updaten soll... Womöglich macht er es dann auch noch, aber seine ganzen Extensions funktionieren nicht mit der aktuellen Version.

Mit mod_evasive zB. kannst du eher ungeübte Schüler abhalten deinen Apache in die Knie zu zwingen bzw. einen Denial of Service zu provozieren

An sich schon recht, es heißt ja nicht, wenn man immer alle Updates einspielt, das dann das System sauber ist. Manchmal ist es nach einem Update eher wieder unsicherer.

Ich will auch gar nicht behaupten, das daß verwendete CMS und evtl. genutzte Scripte sauber sind. Wer eine Lücke finden will, wird immer eine finden.

Aber ich habe alle mir bekannten Sicherheitsfunktionen im CMS mehr oder weniger erfolgreich eingebaut und viele Probleme damit behoben. Dies aber schon seit Monaten.

Von daher habe ich hier meine Anfrage gestellt, das sich das mal jemand ankuckt, der mehr Ahnung davon hat als ich.

Ebenso die Bitte mit Dokumentation der vorgenommenen Änderungen.

Lieber gebe ich ein paar Mäuse aus (auch wenns grad sehr weh tut, da ich gerade umziehe ), als daß Starto mir den Server kündigt oder jemand dahergelaufen kommt, der schlimmeres anstellt.

Der vermeintliche Angriff kann, wenn er wirklich von unserem Server kam, nur durch ein Script oder so passiert sein, denn außer ftp ist kein Login auf dem Server möglich, da SSH nur per Key stattfinden kann. Und das sollte ja ziemlich sicher sein.

Also, wer helfen will und kann, darf sich gerne melden. Sollte Er/Sie noch in der Nähe von Berlin seinen Sitz haben, wäre es fast wie ein 6er im Lotto.

Danke Euch beiden schonmal.

Gruß

Ulf

 

[matzewe01]

Hallo Matzewe01

zu Punkt 1.
Kann ich ein evtl. vorhandenes Shellscript finden? Dürfte doch nur im Domain-Ordner liegen, oder? Wobei nur... Da gibt es viiiiiele Dateien ...

Aber es muß ja als ausführbar gekennzeichnet sein, korrekt?

zu Punkt 2.
OK, hatte in einigen Posts gelesen, das es evtl. sinnvoll ist, die IP´s bei >3 Fehlversuchen beim Login temporär zu blocken. Daher mein Gedanke mit iptables.

Punkt 1.
Es reicht schon ein php Script was dort abgelegt wird.
-> Das muss nicht mal offensichtlich erkennbar sein. Also eine austausch einer php Datei durch eine "gepatchte" mit Backdoor reicht.
Ist ein Einbruch erstmal vollzogen, sind auch die Spuren zügig verwischt.
Sprich: Ich warte so lange vor dem Haus, bis da jemand unachtsam aus dem Haus stürmt und hüpfe schnell durch die offene Tür.
Dann besorge ich mir z.B. eine Schlüsselkopie, lehne ein Fenster an etc. etc.
Und kann dann später ohne weitere Sorgen ins Haus kommen.

-> Das läuft meistens auch auf einem Rootserver ab. Der Einbrecher öffnet sich mehrere alternative Wege.

Punkt 2.
Das ist eine der Scharlatanerien.
Ein Scriptkiddie welches man damit wirklich verscheuchen kann, merkt u.U. gar nicht,(weil zu blöd die Ausgabe richtig zu interpretieren) dass es Erfolg gehabt hat.

Ein bemüter Hacker weiss jedoch um solche Tools wird ggf. einmal davon ausgebremst und ändert danach die Strategie.
Sofern er überhaupt so auffällig vor geht.
-> Entsprechend ist zu hinterfragen ob die Passworte sicher genug sind und ob es zu Passwort Anmeldung keine bessere Alternativen gibt.

Bei ssh z.B. auth keys. Wenn man sich nur damit anmelden darf, ist das Risiko extrem gering, dass es zu einem Einbruch kommen kann.
Softwarebugs sind hier dann das grössere Risiko.

 

[Perry_Rhodan]

Hallo Matzewe01,

hmm, es laufen 2 PHP-Sachen auf dem Server, ein CMS und ein Shop.

Da der Server kein erhöhten Traffic hat und der CPU auch nicht höher als normal ausgelastet ist, denke ich mal nicht, das jemand den Server wirklich gehackt hat. Vor allem, da der root-Account deaktiviert ist und ich mich ausschließlich per SSH-Key auf den Server einlogge. Ohne Key ist eine Nutzung von SSH nicht möglich.

Ich danke Dir für Deine Tipps und Hinweise. Sie haben mich schonmal ein Stück weiter gebracht.

Nun werde ich ersteinmal meinen umzug übder die Bühne bringen und danach kümmere ich mich mal verstärkt um den Server. 2 Personen haben mir auch Hilfe angeboten. Mal sehen, ob sich noch jemand meldet und wen ich dann aussuchen werde.

Gruß

Ulf

 

[matzewe01]

Hallo Matzewe01,

hmm, es laufen 2 PHP-Sachen auf dem Server, ein CMS und ein Shop.

Da der Server kein erhöhten Traffic hat und der CPU auch nicht höher als normal ausgelastet ist, denke ich mal nicht, das jemand den Server wirklich gehackt hat. Vor allem, da der root-Account deaktiviert ist und ich mich ausschließlich per SSH-Key auf den Server einlogge. Ohne Key ist eine Nutzung von SSH nicht möglich.

Ja, das mag so stimmen.
Über einen Remotezugang / Remoteshell etc. kann man sowas schnell ändern.
Und auch ein scheinbar ruhiges System muss nun nicht unbetroffen von etwaigen Einbrüchen sein.
Und wie würde der root Account deaktiviert?
Einfach nur /bin/false in der passwd Eintragen unterbindet es nicht, Prozesse als root auszuführen.
Und lediglich per ssh keine root Login zu erlauben verhindert das erst recht nicht.

Will da nun keine Panik verbreiten, sondern lediglich schildern welche Möglichkeiten es gibt und welche Motivationen ggf. existieren.

Zu den Motivationen:
Nicht jeder der ein System knackt, führt auch sofort damit seine "Attacken" etc aus.
Man kann das auch versteckter machen und z.B. sein Zombinetzwerk erstmal aufbauen.
Viele prüfen die Systeme gar nicht oder nur sehr sporadisch.
Dabei gibt es einfach Mittel wie z.B. eine md5sum seiner Dateien zu erzeugen und dieses ggf. wieder zu prüfen, ob sich etwas geändert hat.

Falls ja, prüfen ob das so sein darf und kann.

Wenn mal ein System befallen ist kann man sich i.d.R. auch nicht mehr auf die üblichen tools wie ps, top etc. verlassen. Hat also damit keine ernsthafte Aussage darüber, ob und wie das System ausgelastet ist.

Gerade rootkits gibt es eine ganze Menge, die derzeit aus den meisten chroot/jail Umgebungen ausbrechen können.

 

[Perry_Rhodan]

Hmm... Remote und/oder Shellzugang heißt doch SSH? Das geht, bzw. sollte, nur mit Key. (bzw. so ist es eingestellt und "nur" mit Passwort komme ich nicht rein.)

Ja, root wurde lediglich per passwd und shadow "deaktiviert".

Ich logge mich per SSH-Key ein und wechsle dann mit sudo in den root-modus.

Das reicht dann scheinbar nicht aus.

Die Dateien sind nicht mit einer Prüfsumme versehen. Da werde ich mich mal schlau machen und sehen, was ich da machen kann.

Es hat auch wenig Sinn, den Server einfach nur neu aufzusetzen, wenn ich nicht weiß, ob, wie und wo sich jemand mit einem Script (wenn denn über das CMS denke ich) eingehackt hat.

Du verbreitest übrigends keine Panik, bei mir zumindest nicht. Im Gegenteil, Du hilfst mir mit Deinen Hinweisen enorm.

Hmm, rootkit... ich werde mal nach einem brauchbarem Scanner suchen, falls es sowas für Ubuntu gibt.

Gruß

Ulf

 

[matzewe01]

Ein sehr rudimentäres Dokument zum Thema:

http://wiki.rootforum.de/security/allgemein

Remote / Shellzugriff != ssh
ssh ist lediglich eine Möglichkeit sich Remote zu verbinden.
Da gäbe es dann noch telnet, rsh (wobei ich mir nicht sicher bin ob hier ssh zum einsatz kommt), vnc usw. usw.

Der Trick einer Remote Shell (hat nichts mit einer ssh Verbindung zu tun) ist:
Dass die Auszuführnde Kommandos z.B. per POST an den Webserver / PHP Script gesendet werden und von dort weiter ausgeführt werden. Hat man ein Loch gefunden ggf. direkt oder indirekt in dem die Befehle abgelegt werden und regelmässig ausgeführt werden.

Und diese besagte ganz simple Lösung ist im prinizp sogar ein Einzeiler:

find / -type f | xargs md5sum > checkfile.txt

Von Zeit zu Zeit erstellen und die Erste Version m,it den nachfolgenden per diff Vergleichen.
Dann prüfen, was hat sich geändert und war das i.O. dass sich das geändert. hat.
Idealerweise hat man lokal eine Referenzumgebung die man vergleicht.

Allerdings sollte man die Datei nicht auf dem Host belassen sondern anderweitig aufbewahren und sich natürlich nicht auf das lokal befindliche md5sum verlassen sondern ein eigenes Paket (inkl. aller abhängikeiten) zu jedem Check von extern mit bringen.