Hehyo,
Ich hoffe man kann mir bezüglich Linux/Debian einwenig aushelfen.
Es ist mein HomeServer mit Debian Lenny 64bit "infiziert".
Zwar habe ich vor, ihn neu aufzusetzen und gleich auf Schlüssel zu setzen, anstatt Passwörter mit SSH, aber ich bin doch etwas verwirrt über meine "kleine" Beobachtung.
Sicherheitshalber habe ich den Zugriff auf das Internet dem HomeServer untersagt, sodass keine Gefahr läuft, dass der Hacker es mitbekommt.


Einen Hack konnte ich bemerken, weil manchmal mein Internet lahmte, weil mein NetGear Router ständig mir unbekannte IP-Adressen zeigte (interne Adressen) und weil mir die lastlog bei /var/log gelöscht wurde.
Nun, nach einigen Monaten gehe ich der Sache einwenig auf den Grund, einfach mal aus Neugier, wie weit ich da zurückverfolgen kann.

Meine Netstat ausgabe zeigt mir folgendes:

Yeeeeha:/home/alex# netstat
Aktive Internetverbindungen (ohne Server)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 HomeServer-IP:22 Mein-PC:10760 VERBUNDEN
tcp 0 52 HomeServer-IP:22 Mein-PC:10759 VERBUNDEN
udp 0 0 HomeServer-IP:37840 213.191.92.82:domain VERBUNDEN
udp 0 0 HomeServer-IP:49788 213.191.74.12:domain VERBUNDEN
Aktive Sockets in der UNIX-Domäne (ohne Server)
Proto RefCnt Flags Type State I-Node Pfad
unix 2 [ ] DGRAM 2454 @/org/kernel/udev/udevd
unix 8 [ ] DGRAM 4862 /dev/log
unix 2 [ ] DGRAM 6030
unix 3 [ ] STREAM VERBUNDEN 5806
unix 3 [ ] STREAM VERBUNDEN 5805
unix 2 [ ] DGRAM 5804
unix 3 [ ] STREAM VERBUNDEN 5779
unix 3 [ ] STREAM VERBUNDEN 5778
unix 2 [ ] DGRAM 5777
unix 2 [ ] DGRAM 5181
unix 2 [ ] DGRAM 4988
unix 2 [ ] DGRAM 4884


Die ersten beiden Verbindungen sind normal, dass ist meine SSH Verbindung (einmal Putty und einmal Filezilla).
Die letzten beiden, also:

udp 0 0 HomeServer-IP:37840 213.191.92.82:domain VERBUNDEN
udp 0 0 HomeServer-IP:49788 213.191.74.12:domain VERBUNDEN

Finde ich recht seltsam.
Die beiden Adressen sind Domainserver von Hansenet/Alice.
Lustigerweise war das bis vor kurzem mein Provider, inzwischen zu einem anderen gewechselt.
Allerdings trotz wechsel, der HomeServer will die Domainserver von Hansenet nutzen.
Meine interfaces:

auto lo eth0
iface lo inet loopback

allow-hotplug eth0

iface eth0 inet static
address HomeServer-IP
netmask 255.255.255.0
network 192.168.1.1
broadcast 192.168.1.255
gateway 192.168.1.1
dns 192.168.1.1

Die DNS entscheidet also der Router. (Welche auf den DomainServer von DynDNS verweißt.)
(Internet für HomeServer ist blockiert, wird auch nur geändert, um tests durchzuführen oder wenn er neu installiert wird.)
Könnt ihr mir erklären, wieso er die DNS von Hansenet will?
Ist es denkbar, wenn auch unwahrscheinlich, dass Hansenet bzw. ein Mitarbeiter von denen meinen Homeserver gehackt und somit beobachtet hat?

Vielleicht gibts hier ja ein paar Linuxkenner
Greetz

Gehst du jetzt nur von einem "hack" aus, weil dein Debian den hansenet-DNS-Server nutzen will? Hab ich das richtig verstanden?

Was steht in der /etc/resolv.conf ?

Du hast ein Geheimnis gelüftet, meine resolv.conf:

nameserver 213.191.74.12
nameserver 213.191.92.82

Somit ist Hansenet/Alice fein raus.

Allerdings gehe ich nicht nur von einem Hack aus, ich weiß, dass es gehackt wurde.
/var/log/lastlog löscht sich in der Regel nicht von selbst und "fremde" Software habe ich nicht installiert, mein Fehler war ein sehr schwaches Passwort, da ich einen Zugang von außen garnicht geplant hatte, es aber im Nachhinein gemacht habe.

Der Hack hat sich gezeigt, als ich das Protokoll meines Routers durchging und bemerkt hatte, dass die "Angriffe" aufs interne Netzwerk aufhörten, als ich den HomeServer einige Tage aus ließ.
Beispiel:

[DoS attack: IP Spoof] attack packets in last 20 sec from ip [192.168.1.11], Thursday, Jan 13,2011 19:42:30

Lustigerweise ist diese IP keinem Gerät zugewiesen.
Habe jetzt eine beliebige Protokoll-Mail rausgepickt, nicht ganz aktuell, aber es waren immer verschiedene IP-Adressen, wobei am Ende meine Fritz.Box (die nurnoch als TK-Anlage dient) öfters gespooft wurde.
Leider nimmt der Router nicht die MAC-Adresse mit auf, sonst wäre es eindeutig gewesen.

Wo ich anfangen zu suchen soll, weiß ich garnicht, ich weiß nur, wie man ihn aufsetzt und suche dann Tutorials zur Konfiguration und Beschreibungen zum Verständnis der einzelnen Konfigurationsdateien.
Greetz

/var/log/lastlog löscht sich in der Regel nicht von selbst

Stimmt wo du es erwähnst

Wie war denn SSH konfiguriert? Standardport 22? Erreichbar weltweit, d.h. dementsprechend Portforwarding/Firewall konfiguriert?

Passwort schwach?? Für root??
War in der /etc/ssh/sshd_conf PermitRootLogin no eingetragen?

Die /var/log/auth Logs bist du auch alle durchgegangen?

Den Port habe ich auf eine Vierstellige Zahl erhöht und Root-Login verboten, aber es ist durch einen Portscan schnell zu finden.
Mein root-Passwort besteht aus 12 Zeichen, wobei es "sparsam" gewählt wurde und nur bedingt sicher ist.
Außerdem war (jetzt natürlich nicht mehr) vom Internet aus zu erreichen, um z.B. schnell vom Kumpel aus was nachzuschauen.

Die /var/log/auth habe ich versucht anzuschauen, allerdings sind das über 2000 Zeilen und selbst wenn ich es von den Unnötigen "befreie", sind es weiterhin über 700 Zeilen
Ein Programm zum Durchgehen kenne ich leider nicht, daher kann ich es nicht richtig analysieren.
Ich selbst nutze Windows 7, HomeServer ist veraltet bei Debian Lenny (mit dem Neuinstall würde ich gleich Squeeze drauf machen).
Greetz

Den Port habe ich auf eine Vierstellige Zahl erhöht und Root-Login verboten, aber es ist durch einen Portscan schnell zu finden.

Hm, das verrringert aber stark die Wahrscheinlichkeit, dass jmd über SSH reingekommen ist.
Wie sah es denn mit Updates aus? Hast du immer fleißig Updates per apt-get update && apt-get upgrade eingespielt?

Ein Programm zum Durchgehen kenne ich leider nicht, daher kann ich es nicht richtig analysieren.

Dafür gibt es doch grep

more /var/log/auth.log.1 | grep -i [SUCHBGERIFF]

Updates spielte ich wenigstens einmal im Monat auf, meistens zweimal, selten wartete ich länger als einen Monat.
Wie gesagt, ich gab der Sicherheit weniger Beachtung, da es ein HomeServer ist und das nicht so schlimm wäre, wie bei einem echten Server bei einem Provider.

Jetzt wo du es sagst, fällt mir auch grep ein, allerdings wüsste ich nicht wirklich, wonach ich suchen müsste.
Weiterhin kann ich die Dateien auf meinen PC ziehen und sie bequem mit der Windows-Oberfläche und NotePad++ analysieren.


Was mir aber eben noch einfällt, wenn der HomeServer Internetverbindung hat, geht der Login und NetStat sehr schnell, also "normal".
Wenn ich ihm allerdings die Internetverbindung wegnehme, brauche ich ca. 10 Sekunden, bis er nach dem Passwort fragt und ebenso lange braucht netstat.
Greetz


edit: Hier mal ein kleiner Auszug, der sich über die ganzen auth.log Dateien breit macht:

Sep 10 08:54:59 Yeeeeha sshd[2097]: Server listening on :: port ABCD.
Sep 10 08:54:59 Yeeeeha sshd[2097]: Server listening on 0.0.0.0 port ABCD.
Sep 10 08:55:01 Yeeeeha CRON[2175]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 10 08:55:01 Yeeeeha CRON[2175]: pam_unix(cron:session): session closed for user root

Wobei die letzten beiden Zeilen um ein vielfaches öfter kommen als die ersten beiden.
Was ich nicht auf anhieb verstehe ist, wieso sshd auf die IP 0.0.0.0 hört.
Noch weniger verstehe ich aber, wieso diese cron:session die ganze log zumüllt.


edit#2: Damit ihr nicht denkt, ein hack per SSH sei unwahrscheinlich, ich habe P2P genutzt und ein Programm - welches meinen HomeServer wie einen Root, also einen echten Server aussehen lässt- genutzt. Daher nehme ich an, dass die IP über dem P2P Prog "getippt" wurde und ein Portscan durchgeführt wurde. Beim Portscan fand man den SSH Port und probierte einfache Passwörter, wie kleine Buchstaben.
Allerdings ist mir nicht bekannt, seit wann es gehackt wurde, da der Hacker sich nicht einfach Preisgegeben hat und ich den jetzigen NetGear Router erst seit diesem Januar besitze, sodass ich es nicht ahnen konnte.

Beitrag nicht mehr editierbar...
Aber ich hab was in der auth.log gefunden:

Sep 3 06:25:03 Yeeeeha su[4219]: Successful su for www-data by root

Das ist garantiert nicht geplant... in dem Fall hätte ich die Rechte einschränken müssen, damit www-data nicht mehr suen kann.

Dies habe ich mehr oder minder zufällig am Ende eines der logs gefunden. (Hatte mit regulären ausdrücken die log mit NotePad++ verkleinert, also ganzen Cron-dinger entfernt.)
Jedenfalls ist es möglich, dass ich zu dem Zeitpunkt noch Apache installiert hatte, etwas später bin ich zu lighttpd gewechselt, welches aber ein Memory Leak hatte.
Ich hatte es nicht weiter beachtet, denn er tritt nur auf, wenn man große Dateien über http laden wollte.

Jedenfalls habe ich nun einen Anhaltspunkt, wo und wie ich suchen kann.
Ich kann euch auf dem laufenden halten, wenn ihr wollt, falls nicht, einfach sagen :P

Du kannst alle auth* Logs mal nach "sshd", "www-data" oder "su" durchgreppen. Vllt fallen dir noch ein paar weitere Suchbegriffe ein.
Wenn du magst, kannst du sie auch mal alle hier hochladen, wenn dir mir vertraust. Gerne gepackt und mit einem Passwort geschützt, das schickst mir dann per PN

Was ich nicht auf anhieb verstehe ist, wieso sshd auf die IP 0.0.0.0 hört.

Das bedeutet, dass der sshd nicht nur auf eine IP gebunden ist, er ist "weltweit" erreichbar, deswegen die unbestimmte Adresse 0.0.0.0.
Du kannst einen Daemon ja auch nur auf dem localhost lauschen lassen, dann ist dieser im Netzwerk nur von sich selbst erreichbar.

Es ist seltsam, es scheint, als käme der Hacker nicht immer drauf, eher selten bzw. nur wenn er es "wiederfindet".
Schließlich habe ich einen 24 Stunden Reconnect, wodurch sich die IP täglich ändert (meist nachts).

Aber hier, schau selbst, wieso seltsam:

Sep  3 06:25:02 Yeeeeha su[4214]: Successful su for www-data by root
Sep  3 06:25:02 Yeeeeha su[4214]: + ??? root:www-data
Sep  3 06:25:02 Yeeeeha su[4214]: pam_unix(su:session): session opened for user www-data by (uid=0)
Sep  3 06:25:03 Yeeeeha su[4214]: pam_unix(su:session): session closed for user www-data
Sep  3 06:25:03 Yeeeeha su[4219]: Successful su for www-data by root
Sep  3 06:25:03 Yeeeeha su[4219]: + ??? root:www-data
Sep  3 06:25:03 Yeeeeha su[4219]: pam_unix(su:session): session opened for user www-data by (uid=0)
Sep  3 06:25:03 Yeeeeha su[4219]: pam_unix(su:session): session closed for user www-data
         

Danach beginnt die nächste Log.

In dieser nächten Log wieder dasselbe:

Sep 24 06:25:03 Yeeeeha su[9648]: Successful su for www-data by root
Sep 24 06:25:03 Yeeeeha su[9648]: + ??? root:www-data
Sep 24 06:25:03 Yeeeeha su[9648]: pam_unix(su:session): session opened for user www-data by (uid=0)
Sep 24 06:25:03 Yeeeeha su[9648]: pam_unix(su:session): session closed for user www-data
Sep 24 06:25:03 Yeeeeha su[9653]: Successful su for www-data by root
Sep 24 06:25:03 Yeeeeha su[9653]: + ??? root:www-data
Sep 24 06:25:03 Yeeeeha su[9653]: pam_unix(su:session): session opened for user www-data by (uid=0)
Sep 24 06:25:03 Yeeeeha su[9653]: pam_unix(su:session): session closed for user www-data
         

Danach finde ich in keiner auth.log mehr etwas über www-data.
Immer um dieselbe Uhrzeit (fast auf die Sekunde)... Ich denke nicht, dass mein Wecker bzw. ich so genau den HomeServer wieder hochfahre.
Der Zeitabstand ist sehr hoch, sodass man annehmen darf, dass ich zu seinen ungunsten was verändert hatte (z.B. update).
Andererseits ist die Uhrzeit so genau, als wäre es ein wiederkehrender cronjob, allerdings ist die auth.log voll mit cron-dingern.

Ich kann dir die auth logs schicken, jedoch nicht die logs des http-servers, da diese private Daten enthält und ein Ausschneiden dieser nahezu unmöglich ist, ohne ein paar Stunden Arbeit zu investieren. (Allein fürs Ausschneiden.)

Allerdings bin ich jetzt erstmal wech, später schau ich hier nochmal rein schicke dir ggf. die auth logs.
Greetz

Willst du überhaupt noch weiteranalysieren? Letztenendes entscheidest du dich doch eh für format und Neuinstallation oder nicht?

Der www-data wurde nur vom apache benutzt? Wann hattest du apache nochmal stillgelegt und deckt sich das in etwa mit dem letzten su vom www-data? So genau kenn ich den apache nicht, aber möglicherweise machte der apache das ja

Eigentlich gibt es da nicht viel zu analysieren.
Hätte er mal "www-data+linux" in die Suchmaschine seiner Wahl eingegeben, wäre ihm bestimmt was aufgefallen.

Also ich denke, er wurde nicht gehackt, sondern er kann keine Log's lesen.
Kam mir gleich komisch vor. Zuerst hat er die resolv.conf vergessen, dann ist ihm grep nicht mehr eingefallen - aber einen Homeserver betreiben.

Unglaublich, was manche Leute so veranstalten.

Karaya

Unglaublich, was manche Leute so veranstalten.

Naja, niemand kann alles wissen. Ich wusste es in diesem speziellen Falle auch nicht (genau)

dann ist ihm grep nicht mehr eingefallen - aber einen Homeserver betreiben.

Also, weiter analysieren würde ich nur der Neugier wegen, eine Neuinstallation ist unumgänglich für mich, denn ich weiß nicht, ob etwas weiter infiziert sein könnte, möglicherweise würde ein dist-upgrade es nicht gerade biegen.

Ich habe in die Logs geschaut, zu dem Zeitpunkt hatte ich bereits lighttpd eine Weile im Betrieb, im lighttpd log fand ich nichts, was passend zum Zeitpunkt war, was von Relevanz sein könnte. (Ich schau es mir aber nochmals genauer an.)

@Karaya, Ich gebe zu, dass ich mich mit Linux nicht sehr gut auskenne, mit resolv.conf nie in Berührung kam und dass ich grep so selten nutze, dass es mir nicht gleich in den Kopf kam.

Soviel ich weiß, ist www-data sowohl ein User, als auch eine Gruppe.
Als www-data wird der http-Server betrieben, in dem Fall lighttpd.
Dass www-data "regelmäßig" (nur zweimal) su-et, wäre mir sehr neu, www-data darf aus sicherheitsgründen keine rootrechte bekommen, soviel ist mir klar.
Wenn www-data per su an rootrechte gelangt, ist das zu 100% meine Schuld, denn ich muss das zu verhindern wissen, allerdings möchte ich aus Fehlern lernen und nicht im kalten stehen gelassen werden.
Einen HomeServer auf Linux-Basis habe ich gewählt, weil 1. Windows zuviel Ressourcen verbrät, 2. Windows teilweise sehr undurchsichtig ist und 3. ich ohnehin mal Erfahrung mit Debian machen will.

Ich bin bereit, zu verstehen und zu lernen, aber ich weiß mit sicherheit nicht sehr viel, größtenteils Grundkenntnisse von Debian.
Jedenfalls bin ich mir sicher, dass ich etwas weiter als ein Anfänger bin, wo man für jeden Befehl googeln muss, aber bei manchen Sachen komme ich auch nicht drumrum.

Da ich bisher verschwiegen habe, dass ich nicht allzuviel Ahnung habe, würde ich auch verstehen, wenn ihr keine Lust habt.
Auch kann ich verstehen, wenn ihr auch keine Lust habt, da ich es ohnehin neu installieren werde.
Ich mache das nur um es mal kennengelernt zu haben und es unter (schlechten) Umständen mal anzuwenden.
Greetz


edit: Achja, was für einen Hack spricht, die lange Wartezeit bei der Passwortabfrage beim Login per SSH/Putty, wenn der Homeserver KEINE Internetverbindung hat.
Falls der Homeserver Internetverbindung hat, geht das schnell, keine Verzögerung. (Ich hab einfach mal die Zeit gemessen, es sind ca. 20 Sekunden, nicht 10. Wieso soviel, weiß ich nicht.)
Selbes beim Befehl Netstat, wo er mit Internetverbindung keine Verzögerung hat und ohne Inet ca. 20 Sekunden braucht.