Sicherheitsproblem mit Computer

[1GENNADIY]

Hallo!

Auf einem meinen Rechner ist Debian Wheezy installiert.
Ich bin sicher, dass Rechner gehackt wurde.

Ich wünschte mir Ihre Ratschläge, um Näheres rauszufinden.

Auf dem Rechner lief ein BitTorrent-Client und Browser.
Auch war telnet und ein vnc-Viewer zum lokalen Netz freigeschaltet.
Diese locale Freischaltung habe ich mit Iptables realisiert (war damals alles okay).

Der Rechner kam mit pppoeconf zum Netz (manchmal auch über einen anderen Rechner im lokalem Netz).

Wenn ich jetzt auf diesem Rechner nmap auf (ihre eigene, xx.xx.xx.xx) externe IP starte, dann sehe ich keine offene Ports.

Wenn ich aber mit einem anderen Rechner diese IP mit nmap prüfe, dann sehe ich offene Ports (telnetd, vnc).

Ich habe in /var/log geguckt (mit Live-CD) (auth.log, wtmp), aber mein diletantischer Blick sieht nichts Auffäliges.

Was würden Sie raten, was ich unternehmen könnte, um dieser harmvollen Situation näherzukommen?
Mich würde interessieren, wann es (Angriff) stattgefinden könnte.

In einem alten Artikel von 2004 habe ich gelesen, dass dem Angreifer in erster Linie geht darum, die offene Ports zu schließen und Hintertüren einzubauen. Aber hier sieht es nicht so aus (für mich).

MfG, Gennadiy

[eggy]

a) Telnet sendet Passwörter im Klartext - da sollte man, wann immer es geht, die Finger von lassen.
b) Dass Du lokal nichts findest, kann verschiedene Ursachen haben: von "unbedeutend" falsche Iptables Regeln bis "worst case" Rootkit. Netzwerkkabel raus, WlanPasswort am Accesspoint ändern, erst dann mit LiveCD weitersuchen.
c) Wenn Du Dir sicher bist, ALLE Passwörter, die Du jemals auf dieser Kiste eingegeben hast, ändern. Mitbenutzer informieren.
d) Wenn Du in den Logfiles nichts findest, der Zeitstempel des Bittorrentclients könnte ein Hinweis sein (er muss aber nicht stimmen), so der Client denn vom Eindringling installiert wurde. Du kannst auch mal nachsehn, ob ein neuer Account erstellt wurde, falls der ein /home/neueruser hat findet Du da auch Zeitstempel.
e) Installier lieber neu, beim Reparieren übersiehst Du sehr wahrscheinlich was

[1GENNADIY]

In Grobem mache ich es schon so, wie Du sagst (Passwörter neu setzen).
BitTorrent-Client habe ich damals selber installiert.

Abschalten habe ich sofort gemacht. Nur ein Paar mal gestartet, um sich für diese offene Ports zu überzeugen.

Access-Point habe ich nicht. Wie geschrieben, Rechner kommt selber mit pppoeconf ins Internet.

Mich würde interessieren, welche Systemelemente ausgetauscht sind, damit ich den Umfang (grob) feststellen kann.
Neue Benutzer habe ich im Home-Verzeichnis nicht gesehen (/etc/passwd ?)

Ansonsten vielen Dank für Unterstützung!

[1GENNADIY]

Ich konnte nichts finden.
Installieren mache ich es aber neu.

Ich habe die log's noch mal geguckt und nichts (auf mein Blick) Verdächtiges gesehen.
Ja, wenig Hintegrundwissen bei mir (timestamps, Dateigrößen).

Ich habe auch rkhunter laut dieser Anleitung: http://rkhunter.cvs.sourceforge.net/vie ... les/README (unter "STANDALONE INSTALLATION") lokal installiert und ausgeführt. Der hat nichts Verdächtiges gefunden.

Die Hauptfrage, warum diese Ports für Außenwelt offen sind, bleibt.
Oder ich habe etwas nicht verstanden
--

[Inkodiktus]

Wenn du wirklich gehackt wurdest und du nichts zur Sicherheit schon vorher gemacht hast, sprich mindestens richtige Konfig der FW, was eigentlich nicht viel ist, dann bist du eh am Arsch gekniffen.
Neuinstallation mit Formatieren ist da die einzige Lösung.
Vorher sollte man alle mögliche SW gegen Hacker installiert haben und natürlich auch die Logs lesen können.

Und dann hängt es noch vom Hacker ab, wie paranoid er war.

Grüße

[eggy]

Ganz grob vereinfacht:

Der Angreifer installiert ein Tool, das sich tarnen kann.
Du sagst "zeige mir alle offenen Ports". Das Tool sitzt zwischen Deiner Eingabe und der Ausgabe Deines Systems: es entfernt jeden Hinweis auf sich aus der Ausgabe. Lokal siehst Du also nicht, dass es einen Port aufgemacht hat.

Jetzt installierst Du lokal etwas wie rkhunter. Das Tool sitzt aber immer noch zwischen Deiner Eingabe und der Ausgabe. Du startest rkhunter. Das Tool denkt sich "och noe, wozu denn?" und sagt der Ausgabe "hier ist nix".

Deswegen LiveCD.

[DeletedUserReAsG]

Mein erster Schritt wäre, mit netstat zu schauen, ob die Ports wirklich offen sind. Auch wäre die originale Ausgabe von nmap von Interesse. Wärest nicht der Erste, der die Ports in der Ausgabe entdeckt und vor Schreck das „filtered“ übersieht. Bislang sehe ich in diesem Thread ansonsten nichts, was auf „Ich bin sicher, dass Rechner gehackt wurde.“ hindeuten würde, außer der Aussage selbst.

Eine Firewall auf dem zu schützenden Rechner selbst ist in der Regel unnütz und überflüssig.

[1GENNADIY]

Ganz grob vereinfacht:

Der Angreifer installiert ein Tool, das sich tarnen kann.
Du sagst "zeige mir alle offenen Ports". Das Tool sitzt zwischen Deiner Eingabe und der Ausgabe Deines Systems: es entfernt jeden Hinweis auf sich aus der Ausgabe. Lokal siehst Du also nicht, dass es einen Port aufgemacht hat.

Jetzt installierst Du lokal etwas wie rkhunter. Das Tool sitzt aber immer noch zwischen Deiner Eingabe und der Ausgabe. Du startest rkhunter. Das Tool denkt sich "och noe, wozu denn?" und sagt der Ausgabe "hier ist nix".

Deswegen LiveCD.

-ich verstehe Dich ganz voll. Aber rkhunter, z:B., kann ich nicht von Live-CD starten. Dafür gab es eine Option "--rootdir", aber wegen mangelnder Softwareentwiklerunterstützung ist die veraltet und funktioniert nicht mehr. Dieser Weg mit "Standalone Installation" ist der Unabhängigster (vom prüfenden System).

Mein erster Schritt wäre, mit netstat zu schauen, ob die Ports wirklich offen sind. Auch wäre die originale Ausgabe von nmap von Interesse. Wärest nicht der Erste, der die Ports in der Ausgabe entdeckt und vor Schreck das „filtered“ übersieht. Bislang sehe ich in diesem Thread ansonsten nichts, was auf „Ich bin sicher, dass Rechner gehackt wurde.“ hindeuten würde, außer der Aussage selbst.

Eine Firewall auf dem zu schützenden Rechner selbst ist in der Regel unnütz und überflüssig.

- die Ports sind wirklich offen, mit netstat kann ich diese sehen. Aber Iptables-Regeln (sollten!) "danach" arbeiten und diese Ports filtern.
- die originale Ausgabe von nmap auf betroffenem Rechner auf seine externe IP (pppoeconf) zeigt keine offene Ports. Wenn ich aber von einem anderen Rechner (aus diesem lokalen Netzt, aber ohne Bedeutung?) auf diese IP nmap starte, dann sehe ich offene Ports (telnetd, xtightvnc). Ich wiederhole nur, filtered gibt es bei mir nicht, nur closed und open.

[DeletedUserReAsG]

In dem Fall würde ich die Ports schließen (also die betreffenden Dienste beenden), oder die iptables-Regeln fixen. Dafür, dass die Kiste aufgemacht worden wäre, sehe ich immer noch keine Anhaltspunkte.

[1GENNADIY]

In dem Fall würde ich die Ports schließen (also die betreffenden Dienste beenden), oder die iptables-Regeln fixen. Dafür, dass die Kiste aufgemacht worden wäre, sehe ich immer noch keine Anhaltspunkte.

- ich habe sicherheitshalber diese Iptables-Regeln (die sind einfach, nur drei Zeilen) auf einem anderen Rechner reproduziert und die arbeiten korrekt. Aber auf betroffenem Rechner nicht. Oder eben nmap (auf betroff. Rechner) hat Fehler.

[DeletedUserReAsG]

Solange du die, sowie weitere Informationen, als Geheimnis für dich behälst, kann keiner sagen, ob sie nicht doch kaputt sind.

[1GENNADIY]

Solange du die, sowie weitere Informationen, als Geheimnis für dich behälst, kann keiner sagen, ob sie nicht doch kaputt sind.

- ich versuche es nachzuholen.
Ich starte auf drei Rechnern, die in meinem lokalen Netz sich befinden, ein script, der diesen Rechnern gleichzeitig den Zugang zum Internet zu Verfügung stellt. Der Script funktioniert zuverlässig, nur dass er nur beschränkte Funktionalität hat bezüglich debugging und Neustarten/Stoppen.
Dieser Script ist hier: 38348.
Die betroffene Zeile sind:

Code: Alles auswählen

iptables -A INPUT -p tcp --dport 5901 ! -s 192.168.0.0/24 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp --dport 6001 ! -s 192.168.0.0/24 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp --dport 23 ! -s 192.168.0.0/24 -j REJECT --reject-with tcp-reset 

Diese drei Zeilen nur auf diesem betroffenem Rechner, weil der hat(te) BitTorrent-Client am laufen und xtightvnc-Server.
(damit ich nur aus lokalem Netz per telnet und xtightvncviewer auf diesen Rechner zugreifen konnte).