Gehackt?? Was ist denn da los???

luusbueb

luusbueb

unverhofft kommt oft
Wollte heute auf meinem Root-Server per ssh etwas installieren.
Dafür musste ich die install-Datei chmodden...
bash: chmod: command not found

chmod gibt's nicht in /bin

Zb. chgrp gibt's, aber die Berechtigungen sind unzureichend
bash: /bin/chown: cannot execute binary file

Und was mich nun so erschreckt: das Datum von diversen Binaries: Oct 8 15:15
????????? Wie kommt das?

Ausserdem wird bei der Ausgabe von ls immer zu erst folgendes ausgegeben.
/bin/ls: unrecognized prefix: do
/bin/ls: unparsable value for LS_COLORS environment variable

Bitte sagt mir, dass das normal ist, und wie ich das Problem beheben kann! :(
 

Anhänge

  • ls.txt
    13,9 KB · Aufrufe: 34
Server im Eimer.
Vom Netz nehmen und neu installieren.
 
Auf jden Fall erstmal vom Netz nehmen. Hast du erhöhten Traffic? Oder macht sich das sonst irgendwie bemerktbar?

Teilweise lassen sich durch php-seiten, hatte das mal mit phpBB, codezeilen ins system schleusen, meistens sind die dann unter tmp zu finden. reboot, bei 1un1 gibts z.B. eine Resttunskonsole über die du dann ran kommst, direkt alles wegsichern, umsehen, vlt. kann man den server retten, besser aber neu-install.
 
Verd... naja, ich habs mir gedacht...

Wird zwar sehr mühselig sein, den Server aufsetzten zu lassen und alles... meine Kunden werden sich über den Ausfall auch nicht gerade freuen! :(

Was kann ich tun, um etwas Prävention zu betreiben? Wenn sich durch ein PHP-Script Zugriff verschafft werden kann, dann nützt eine Firewall ja nicht viel. Da muss ich meine PHP-Scripts nach Sicherheitsaspekten prüfen...

Seht ihr das anders?

Ich komme mir ziemlich hilflos vor!
 
Zuerstmal Cross-Site-Scripting unterbinden. Das schaffst du mit folgenden Zeilen in den VirtualHosts:
Code:
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
Damit werden die TRACE- und TRACK-HTTP-Methoden im Server für das VHost deaktiviert, was XSS-Angriffe enorm erschwert.

Weiterhin solltest du ein IDS wie Snort einsetzen um potentiell schädlichen Traffic auszufiltern und bei einem erfolgreichen Angriff im Nachhinein nachvollziehen zu können, wie der Angreifer in's System gekommen ist.

Mit Tools wie AIDE oder Tripwire kannst du regelmässig die Datei-Integrität überprüfen (z.B. per Cronjob) um Änderungen an Systemdateien schnellstmöglich zu merken und nach einem Angriff nachvollziehen zu können, was genau am System verändert wurde.

Nicht vergessen sollte man, dass bestimmte Angriffstechniken schon durch eine geschickte Manipulation der Dateien im procfs verhindert werden können:
Code:
        ### PROC MANIPULATION ###
        # auf Broadcast-Pings nicht antworten
        echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
        # halt die Klappe bei komischen ICMP Nachrichten
        echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
        # Kicke den ganzen IP Spoofing Shit
        # (Source-Validierung anschalten)
        echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
        # Setze Default-TTL auf 61 (Default fuer Linux ist 64)
        echo 61 > /proc/sys/net/ipv4/ip_default_ttl
        # sende RST-Pakete wenn der Buffer voll ist
        echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
        # warte max. 30 secs auf ein FIN/ACK
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
        # unterbreche Verbindungsaufbau nach 3 SYN-Paketen
        # Default ist 6
        echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
        # unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
        # Default ist 6
        echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

Ausserdem sollte man regelmässig chkrootkit und rkhunter einsetzen um evtl. installierte Rootkits zu entdecken.

Und zu guter Letzt: Die Datei-Rechte auf Servern sollten möglichst stark restriktet werden. Ein Systemuser darf nur an die Dateien kommen, die er auch nutzen soll/darf.

Diverse weitere Massnahmen sind möglich, aber das hier aufgezählte ist in meinen Augen das Minimum an Sicherung, die ein Server erhalten sollte.

Im übrigen finde ich es extrem sch..., dass du mit so wenig Wissen über System- und Datensicherheit einen eigenen Server betreibst. "Deine armen Kunden" kann ich da nur sagen. An deren Stelle würde ich mir einen anderen Admin suchen.
 
Danke für die Tipps...
Werde das nach nem Neu-Install berücksichtigen

Bezüglich unerfahrenheit als Sys-Admin... Da muss ich dir recht geben. So lerne ich aber dazu.
 
Bezüglich unerfahrenheit als Sys-Admin... Da muss ich dir recht geben. So lerne ich aber dazu.

Es wäre nur schön, wenn du deine Lernversuche auf deinem heimischen PC machen würdest und nicht auf einem 100MBitler, der binnen weniger Sekunden zig tausende Spammails durch die Gegend schicken und damit andere Server behindern kann. Über die rechtliche Seite habe ich mich hier im Board ja schon zig Mal ausgelassen. Ich hoffe, dass dir deine Kunden genug Geld zahlen, so dass du im Fall einer Klage gegen dich (wegen Spam, Verteilen von Warez u.ä.) einige tausend Euro als Rücklage hast.
 
Naja, wenn ich einen fertig installierten Root-Server miete, dann darf ich schon davon ausgehen, dass der Server einigermassen gut konfiguriert ist.

Natürlich wäre es optimal, wenn ich ein Unix-Crack wäre. Ich kann einiges, aber ein Crack bin ich nicht, trotzdem miete ich einen Root-Server, trotzdem versuche ich's so gut als möglich zu machen. Ein Risiko ist immer dabei.
 
Naja, wenn ich einen fertig installierten Root-Server miete, dann darf ich schon davon ausgehen, dass der Server einigermassen gut konfiguriert ist.

Nein, darfst du nicht. Die Hoster wollen in erster Linie ihre Server vermieten. Der Kunde selbst ist für die Sicherheit des Servers verantwortlich. Das steht im übrigen auch in den AGBs der meisten Hoster. Wenn dich jemand verklagt, weil dein Server gehackt und zum Verteilen von Spam, Viren, Warez u.ä. missbraucht wird, wirst du dafür zur Verantwortung gezogen. Deinen Hoster interessiert das, gelinde gesagt, einen Scheiss.
 
Da hat theton recht! Ein Root-Server ist DEIN Server und der Hoster übernimmt NULL Verwortung für dein Handeln! Ich teste mein Zeug auch erst lokal bevor es auf den vServer kommt ;)

mfg hex
 
blauäugig, Mr. luusbueb. Dank dir habe ich nun ganz viele Mails in meinem Postfach ;).
 
Ok, ich werd mir mal das Buch "Linux Server Sicherheit" beschaffen.

Danke für euren Rat und eure Direktheit! (Auch wenns schmerzt!) ;(


P.S. Bitte kommt jetzt nicht mit "das reicht nicht" oder "Symptom-Bekämpfung"... ist mir schon klar... Ich versuch nur das beste für den Weiterbetrieb des Servers zu erreichen... meinen Kunden und mir zuliebe.
 
debian.org wurde wurde gehackt, winrar.de CCC etz alles keine newbs und nur weil er nicht den mörderplan hat heulen alle rum... es kann genauso einen von euch treffen da is keiner 100% sicher =) nur würdet ihr es nicht hier reinschreiben
 
Jo, aber es ist immer eine Frage wie einfach es ist. Mein Webserver wurde 2x gehackt, oder besser infiltriert. 2x durch ähnliche lücken, nämlich in den oben angesprochenen phpBB-Lücken, und 2x weil ich zu faul war das dringende Update sofort zu machen und das auf Montags verschoben hatte, naja, Fr-So., und es war zu spät....

Beim ersten Mal hab ich neu installiert, beim zweiten mal reichte ein ein reboot und dann eine offline-Reinigung mit Beseitigung der Lücken aus.

Dein Provider wird dir wenn Du fragst sicher ein paar Tips geben können was du machen kannst, was er empfiehlt. Lücken wirds immer wieder geben, das nicht deine Schuld, nur wenn du diese nicht stopfst muss dir an Kopp packen.....
 
Da mus sich zustimmen.
Ja ich bin zwar auch dafür "zuhause" zu lernen, aber man ist NIE auf alles vorbereitet.

Ich find es daher schön, dass ihr dennoch sehr hilfreiche Tipps zur Bekämpfung und Vorsorge gebt anstatt "nur" zu sagen, "wer keine Ahnung hat, soll keinen Server betreiben".
Das is zwar für manche wohl zutreffend und auch richtig, aber auch nicht wirklich eine Hilfe.
 
Ich versuch nur das beste für den Weiterbetrieb des Servers zu erreichen... meinen Kunden und mir zuliebe.

Das bezweifelt hier niemand, aber wenn sich später herausstellt, dass Deine Kiste als Malwarezschleuder genutzt wurde, siehst Du das sicher nicht mehr so einseitig. Natürlich lässt sich ein server absichern, aber alleine die Interpretation gewisser Fehler und Unregelmäßigkeiten benötigt schon sehr fundiertes Wissen und vor allem Erfahrung. Diese muss man sich natürlich erst mal aneignen, und das geht einfach nicht im www. Üblicherweise tastet man sich zunächst an einen lokal arbeitenden server heran, denn wenn da etwas schiefgeht (und es ist doch fast selbstverständlich, dass irgendetwas schiefgeht), ist wenigstens nur dieses lokale Netz betroffen, ohne, dass dabei tausende von Unbeteiligten mitbetroffen sind und Du mit erheblichen Schadenersatzforderungen, Anwaltskosten etc. rechnen musst.

Aber ich muss schon sagen: ich verstehe, warum viele sich so derart unbedarft einen Server mieten. Serverdienste werden inzwischen in etwa mit der selben Verkaufsstrategie angeboten wie Handy-Klingeltöne, incl. Werbegeschenke (Wasserspritzpistole - "Richtig billig abspritzen!", großartiger Werbespruch) und launigen Apellen an durch den Alltag nicht bediente Kleinjungenfantasien ("Hol' dir jetzt die absolute Root-Power!"). Ein Bisschen Seriösität lässt man noch per "TÜV-geprüftem Rechenzentum" durchschimmern, und fertig ist das angebliche rundum-sorglos-Paket, welches zu handeln andere komischerweise mehrjährige Ausbildungen benötigen.

@luusbueb: Damit will ich umgotteswillen natürlich nicht behaupten, dass Du Dich von billigen Werberamsch hast ködern lassen. Ich will nur aufzeigen, dass das Thema "Server" einen allzu lockeren Anstrich in der Wahrnehmung einiger Leute zu haben scheint. - und offenbar auch bei Dir.
 
Jo, wobei ich sagen muss, das z.B. Vserver.de darauf vorbereitet ist.
Man kann über das Config-Panel eine vorkonfigurierte Firewall einschalten, die auch vernünftig arbeitetund sinnvolle Einstellungen hat.

Ich habe einen davon, der als IRC-BNC und Botserver arbeitet, und es gab noch keine Probleme damit.

Wäre schön wenn zumindest solche Basis-Sicherheitsfunktionen überall verfügbar wäre, aber dann bitte auch mit dem Hinweis, das das nicht reicht und man trotzdem noch was tun muss ;)
 

Ähnliche Themen

Jaunty + Zend + Gdata + xampp

Zurück
Oben