Trojaner-Board

Trojaner-Board (https://www.trojaner-board.de/)
-   Alles rund um Mac OSX & Linux (https://www.trojaner-board.de/alles-rund-um-mac-osx-linux/)
-   -   Debian möglicher Trojaner? (https://www.trojaner-board.de/96757-debian-moeglicher-trojaner.html)

boggn 23.03.2011 16:28

Debian möglicher Trojaner?
 
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

cosinus 23.03.2011 20:48

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 ?

boggn 23.03.2011 21:05

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

cosinus 23.03.2011 21:44

Zitat:

/var/log/lastlog löscht sich in der Regel nicht von selbst
Stimmt wo du es erwähnst :pfeiff:

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?

boggn 23.03.2011 22:13

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

cosinus 23.03.2011 22:20

Zitat:

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?

Zitat:

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]

boggn 23.03.2011 22:40

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.

boggn 24.03.2011 04:09

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

cosinus 24.03.2011 09:51

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 ;)

cosinus 24.03.2011 10:54

Zitat:

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.

boggn 24.03.2011 18:40

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:
Code:

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:

Code:

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

cosinus 24.03.2011 19:26

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 :D

Karaya 24.03.2011 22:30

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

cosinus 24.03.2011 22:40

Zitat:

Unglaublich, was manche Leute so veranstalten.
Naja, niemand kann alles wissen. Ich wusste es in diesem speziellen Falle auch nicht (genau)

Zitat:

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

boggn 25.03.2011 00:47

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.

cosinus 25.03.2011 01:17

boggn, du hast einige gute Grundkenntnisse. Mich wundert aber, dass du bestimmte Sachen weißt aber IMHO eher grundlegenere Sachen wie grep oder die /etc/resolv.conf zB nicht. Naja. Deswegen jetzt jmd. seinem Homeserver madig machen zu wollen finde ich übertrieben. Windows ist auch für alle da und nicht nur für die, die sich mit Win "ultragut" auskennen.

Hast du nun mal die vorgeschlagene Googlesuche gemacht? Vllt geht dir ein Lichtchen auf ;)

boggn 25.03.2011 02:57

Nun, ich glaube nun zu verstehen, was Karaya meinte.
Es wurde vom root zu www-data ge-su-t. (Nicht andersrum, wie ich anfangs annahm.)
Dann wurden rechte vergeben, wobei ich nicht verstehe, wozu + ??? ist, root:www-data ist user:group.
Dies könnte man so auffassen, dass der www-data Gruppe irgendwo Berechtigungen gegeben wurden, aber mit einer + ??? kann ich selbst bei google nicht weit kommen.

Dann bin ich wieder am Anfang. Jedenfalls wurde die lastlog gelöscht, was darauf schließen lässt, dass gehackt wurde. (Ja, da habe ich gegoogelt, ich habe nur Beiträge gefunden, wo zu einer Neuinstallation geraten wurde, da "eingebrochen" wurde. Es wurde geschrieben, dass kein "normaler" Admin die lastlog löscht, denn es wäre wie dort oft erwähnt, unsinnig. Ich jedenfalls habe sie nicht gelöscht, zumindest wüsste ich nicht, wieso ich sowas machen würde.)
Greetz


edit: Achja, wegen deiner Verwunderung, anfangs habe ich Tutorials gefolgt, wie man SSH sichert, wie man apache konfiguriert, mySQL, phpMyAdmin etc. pp.
Irgendwann habe ich mir Ubuntu auf mein Notebook installiert, damit gefolgt von Problemen mit WLAN, wodurch ich die interfaces kennengelernt habe.
Die Logs wurden in späteren Tutorials erwähnt, weshalb ich mir mal ansah, was für Logs es gab. Hauptsächlich nutze ich zum editieren nano, zum ausgeben kurzer Dateien cat.
more ist neu für mich, aber ist ähnlich zu cat, hat den Vorteil, dass man "blättern" kann. grep wurde in nahezu keinem Tutorial verwendet, daher ist es mir größtenteils unbekannt.
Mit dem WLAN Problem auf dem Notebook habe ich dann grep erstmals benutzt, wobei es eher ein Kernelproblem ist, aber das tut hier nichts zur Sache.
Ich selbst gehe davon aus, dass ich einen Server betreiben kann und einige Grundlegende Sicherheitsmaßnahmen durchführen kann, allerdings muss ich wie viele andere entweder auf Tutorials zurückgreifen oder ich lese mir stundenlang die Beschreibungen der einzelnen Konfigurationsdateien durch. Das ist anstrengend und irgendwann ist man zu unkonzentriert und macht Fehler.
Naja, ich weiß noch nicht, wie man Rechte zuweißt (das nächste wichtige, was ich lernen muss), dafür verstehe ich aber das Prinzip von chmod/chown bzw. Zugriffsrechte.
Ich verstehe sogar einwenig, wie su arbeitet, dass es keine neue Konsole eröffnet, welches man für screen braucht.
Also einige Einzelheiten, die ein Anfänger nicht weiß, aber einiges Fehlt mir hier sicherlich.
Jedenfalls versuche ich aus Fehlern zu lernen, was mir auch gelingt, solange ich die Fehler natürlich erkenne. Die Logs "richtig" zu lesen ist noch eine kleine Schwäche, aber das wird sicher noch.

boggn 25.03.2011 04:15

Wieder zu lange getippt >.<
Hier mein Zusatz:

hm... es erscheint mir tatsächlich ein CronJob zu sein -> hxxp://www.linuxquestions.org/questions/linux-security-4/understanding-auth-log-696155/
Allerdings ist es recht seltsam, dass es "auf einmal" aufgehört hat. Ich habe lighttpd bereits 2 Monate vorher drauf gehabt, apache dabei deinstalliert.
Weiterhin seltsam, im dpkg log fehlt ein großer Zeitraum. Selbiges im Access.log von lighttpd.
access.log.1 letzter Eintrag: [21/Aug/2010:13:30:40 +0200]
access.log erster Eintrag: [24/Sep/2010:13:24:22 +0200]
dpkg.log.1 letzter Eintrag: 2010-07-21
dpkg.log erster Eintrag: 2010-10-14
Wobei es beim dpkg nachvollziehbar wäre (nicht geupdatet)
Der error.log hat über den fehlenden Zeitraum Einträge, weswegen man nicht davon ausgehen kann, dass ich lighttpd einfach aus hatte...
Greetz

Karaya 26.03.2011 17:32

@boggn, zuerst dachte ich, du bist ein Troll. Zu groß war mir der Unterschied von Wissen zu Nicht-Wissen. Okay, bist du nicht. :pfeiff:

Ich hatte da letzens in einem anderen Forum mit jemandem zu tun der glaubte er müsse unbedingt einen Virus haben. Es war das tägliche logrotate ausgelöst durch ein Cronjob.

Natürlich ist niemand mit Unix/Windows-Wissen auf die Welt gekommen, sondern in aller Regel muss man sich dieses Wissen - zu Teil sehr schmerzhaft - erarbeiten. Ich habe z.B. Apache noch nie installiert, weil ich es noch nie brauchte. Und madig will ich dir deinen Homeserver auch nicht machen.
Zum Thema Homeserver hier ein Link (wenn du es noch nicht kennst) hxxp://www.linux-home-server.de/

Ich bin übrigens nach wie vor der Meinung, du wurdest nicht gehackt.
Also, nichts für ungut.

Karaya

boggn 26.03.2011 20:41

Inzwischen muss ich sagen, dass ich mir auch unsicher bin...
Scheinbar ist ntpdate für die Verbindungen zu den DNS-Servern verantwortlich. (Konnte ich inzwischen in den Logs rausfinden ^^)
Allerdings weiß ich immernoch nicht, was die Verzögerung beim Login vom SSH verursacht.

Deinen Link werde ich mir zu gemüte führen, allerdings tippe ich nicht einfach ab, mir ist es wichtig, zu wissen, was ich eintippe...
Also einiges, was ich lesen müsste, zusätzlich zur eigentlichen Seite.

Apache bzw. einen http-Server installiere ich im Grunde deshalb, weil das im Internet recht "üblich" ist, sowas wie ein "must-have" bzw. "must-know" wie ich finde.


Das mit dem Troll nehm ich dir aber auch nicht übel, ein Neuankömmling, der denkt, sein Linux-System ist infiziert, stehts mit dem Wortlaut, "ich wurde gehackt"...
Ich würde es nicht anders sehen :D

Das System werde ich aber nichtsdestotrotz neu installieren, denn ich kann nicht sagen, was ich bisher dort gemacht habe, es ist mehrere Jahre alt, inzwischen weiß ich besser, wie ich es administriere, als vor 2 Jahren.
Z.B. habe ich noch vnstat installiert (wie ich es aus den Logs entnahm), aber weiß nicht mehr, wie ich es installiert hatte, der Sourcecode ist nicht mehr drauf, ein Entfernen ohne Sourcecode zu haben, weiß nicht wie.
Wenn ich aber jetzt innerhalb einer Woche keinen weiteren Ansatz finde, werde ich es ohne Analyse neu installieren. Ich behalte aber die Logs, um mal reinzuschauen, wenn es mal notwendig sein sollte.
Greetz

cosinus 26.03.2011 20:49

Zitat:

Scheinbar ist ntpdate für die Verbindungen zu den DNS-Servern verantwortlich. (Konnte ich inzwischen in den Logs rausfinden ^^)
NTP hat was mit DNS zu tun? :confused:
Von welchem Zeitserver greift ntpdate denn die Zeit ab?

boggn 26.03.2011 20:52

Nun, NTP versucht ins internet zu connecten, aber der Server hat einen leeren DNS-Cache.
Entsprechend wird eine Namensauflösung versucht, welche die DNS-Server dazu nehmen, das sind IPs in der resolv.conf (wenn ich mich nicht irre).
NTP versucht also ins Internet zu verbinden, welches durch meinen Router durch eine IP Sperre Unterbunden wird.
Daher hatte ich diese DNS-Server bei Netstat manchmal gesehen.
Bin jetzt aber wech, weitere Fragen beantworte ich gerne später :P
Greetz

cosinus 26.03.2011 21:21

Ok ist klar :D
Ein DNS-Query kann aber von fast allem ausgelöst worden sein.

boggn 27.03.2011 00:15

Im Grunde schon, aber um mal zu schauen, ob es das ist, werde ich es mal deinstallieren.
Dann schauen, was noch einen DNS-Query auslösen kann. Allerdings muss ich noch begreifen, wie ich das rausfinden soll >.<
Greetz

boggn 27.03.2011 03:50

Achja, fast vergessen, um euch einwenig zu ärgern, wieso ich doch so überzeugt davon bin, dass mein HomeServer gehackt wurde (Erste Log per Mail):

Code:

[DoS attack: IP Spoof] attack packets in last 20 sec from ip [192.168.1.101 <- DHCP IP, Unterschiedlich vergeben (Meist Handy oder Konsole)], Friday, Jan 14,2011 20:19:05
[DoS attack: STORM] attack packets in last 20 sec from ip [69.10.30.13], Friday, Jan 14,2011 16:42:25
[DoS attack: STORM] attack packets in last 20 sec from ip [69.10.30.13], Friday, Jan 14,2011 16:38:23
[DoS attack: STORM] attack packets in last 20 sec from ip [69.10.30.13], Friday, Jan 14,2011 16:01:34
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [178.199.186.115], Friday, Jan 14,2011 14:49:21
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Friday, Jan 14,2011 04:51:32
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Friday, Jan 14,2011 04:51:10
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Friday, Jan 14,2011 04:50:50
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [192.168.1.11 <- Nicht vergeben], Thursday, Jan 13,2011 19:42:30
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [78.51.43.13], Thursday, Jan 13,2011 15:25:05
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Thursday, Jan 13,2011 04:39:13
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Thursday, Jan 13,2011 04:38:52
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Thursday, Jan 13,2011 04:38:31
[DoS attack: STORM] attack packets in last 20 sec from ip [95.104.107.166], Thursday, Jan 13,2011 02:32:10
[DoS attack: STORM] attack packets in last 20 sec from ip [69.10.30.12], Wednesday, Jan 12,2011 19:58:41
[DoS attack: STORM] attack packets in last 20 sec from ip [69.10.30.12], Wednesday, Jan 12,2011 19:57:31
[DoS attack: STORM] attack packets in last 20 sec from ip [84.40.123.234], Wednesday, Jan 12,2011 17:49:05
[DoS attack: STORM] attack packets in last 20 sec from ip [84.40.122.238], Wednesday, Jan 12,2011 17:49:05
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [192.168.1.3 <- Nicht vergeben], Wednesday, Jan 12,2011 15:46:45
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [192.168.1.3 <- Nicht vergeben], Wednesday, Jan 12,2011 15:46:15
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [192.168.1.3 <- Nicht vergeben], Wednesday, Jan 12,2011 15:45:48
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Wednesday, Jan 12,2011 04:14:07
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Wednesday, Jan 12,2011 04:13:44
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Wednesday, Jan 12,2011 04:13:22
[DoS attack: STORM] attack packets in last 20 sec from ip [HomeServer-IP], Wednesday, Jan 12,2011 04:13:01

Diese IP Spoof/Storm Meldungen hörten auf, als ich den HomeServer einige Tage lang aus ließ.
Ich bin mir absolut sicher, dass ich diese Log lesen kann und weiß auch, was IP Spoof bedeutet. (Storm nehme ich an zu wissen, weiß es aber nicht 100%.)
Ich habe sämtliche DHCP, UPnP, Admin login, Zeitsynchronisationen und Internet Connect sowie Disconnect-Meldungen aus dem Log entfernt.
Ich habe noch viele weitere Logs in meinem kleinen Mail-Archiv.
Greetz

PS: Inzwischen Analysiere ich jede Log, die mir mein Router schickt. Gelegentlich prüfe ich auch die Einstellungen dessen.
Momentan sagt er mir nur, dass er sämtlichen Verkehr vom HomeServer blockiert, sonst keine PortScans oder sonstige Angriffe.

boggn 27.03.2011 23:48

Nun fühl ich mich veräppelt...
Mein Netgear Router schickt mir heute wieder eine Log mit IP-Spoof der FritzBox IP. (Angemerkt, der Router hat falsche Uhrzeit, habs eben nachgebessert bzw. in den Logs verbessert)
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [Fritz!Box-IP], Sunday, Mar 27,2011 16:35:21
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [Fritz!Box-IP], Sunday, Mar 27,2011 20:34:16
[DoS attack: IP Spoof] attack packets in last 20 sec from ip [Fritz!Box-IP], Sunday, Mar 27,2011 21:34:19

Demnach Spooft der HomeServer gelegentlich von selbst, ohne dass es der "Herr" befiehlt.
Ich lasse ihn nun wieder aus und mache ihn ggf. an.
Bemerkenswert ist, dass die Zeitpunkte recht ähnlich sind. Also xx:34/xx:35 Uhr.
Könnte sich also um einen Cronjob handeln (was sonst würde man sagen).
Die Zeiten würden eigentlich zu den Cron-dingern im auth.log passen, allerdings hat er alle 5 Minuten einen Cronjob, sodass es etwas paranoid wäre zu sagen, dass es definitiv ein Cronjob wäre.
Allerdings habe ich crontab -l eingegeben und er sagt mir, es gäbe keine crontabs.

Weiterhin (vergessen zu erwähnen), fam war installiert.
Dieses Programm informiert einen, wenn sich Dateien/Ordner geändert habe. Dies wird haupsächlich in Desktop-Umgebungen genutzt, zumindest wird bei KDE der Konqueror erwähnt.
Ich habe jedoch nie KDE/Gnome oder sonstwas installiert, es ist ein reiner Konsolen-/Kommandozeilen-server.
Ich nehme an, dass dies zur Beobachtung installiert wurde, ich werde demnächst die apt-logs durchgehen, vielleicht kann ich da was entziffern bzw. ob es nicht doch bei einer meiner Experimente installiert wurde.
Greetz


edit: Blöd. Weder in den aptitude, noch den apt logs finde ich die Installation von fam. entweder wurde es manuell entfernt oder aber es ist von Anfang an da gewesen, als ich mit weniger Wissen den HomeServer installierte. Auch die dpkg Logs sagen nichts über fam, keinerlei Installationsdatum.
ls -l sagt folgendes:
-rwxr-xr-x 1 root root 1046 6. Dez 2009 /etc/init.d/fam
Dürfte also mit installiert worden sein... Jedoch scheint jede Log bei mir ein halbes Jahr später zu beginnen, also entweder dem 30.06. oder aber dem 04.07. alles 2010...
Ich bin verwirrt und zu müde von dem ganzen, jetzt erstmal schluss mit analysieren. :P


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:23 Uhr.

Copyright ©2000-2025, Trojaner-Board


Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131