Nach Update dis/re connects

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Success
Beiträge: 288
Registriert: 01.06.2013 21:23:15

Nach Update dis/re connects

Beitrag von Success » 13.01.2015 21:27:48

Hallo

Seit dem 10.Jänner hab ich folgende Updates installiert

[np]Start-Date: 2015-01-10 19:42:20
Commandline: apt-get upgrade -y
Upgrade: base-files:amd64 (7.1wheezy7, 7.1wheezy8), libapt-inst1.5:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), apache2-mpm-prefork:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), linux-image-3.2.0-4-amd64:amd64 (3.2.63-2+deb7u2, 3.2.65-1), linux-headers-3.2.0-4-amd64:amd64 (3.2.63-2+deb7u2, 3.2.65-1), apache2-utils:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), apt-utils:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), apache2:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), debian-archive-keyring:amd64 (2014.1~deb7u1, 2014.3~deb7u1), apache2.2-common:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), apt:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), linux-headers-3.2.0-4-common:amd64 (3.2.63-2+deb7u2, 3.2.65-1), apache2.2-bin:amd64 (2.2.22-13+deb7u3, 2.2.22-13+deb7u4), libapt-pkg4.12:amd64 (0.9.7.9+deb7u6, 0.9.7.9+deb7u7), tzdata:amd64 (2014h-0wheezy1, 2014j-0wheezy1), linux-libc-dev:amd64 (3.2.63-2+deb7u2, 3.2.65-1)
End-Date: 2015-01-10 19:43:50

Start-Date: 2015-01-12 00:00:22
Commandline: apt-get upgrade -y
Upgrade: libssl-dev:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), libssl-doc:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), openssl:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14), libssl1.0.0:amd64 (1.0.1e-2+deb7u13, 1.0.1e-2+deb7u14)
End-Date: 2015-01-12 00:00:36

Start-Date: 2015-01-12 21:02:41
Commandline: apt-get upgrade
Upgrade: php5:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3), libapache2-mod-php5:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3), php5-gd:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3), php5-mcrypt:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3), php5-mysql:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3), php5-cli:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3), php5-common:amd64 (5.4.36-0+deb7u1, 5.4.36-0+deb7u3)
[/np]

Jetzt ist mir erst das Problem aufgefallen das mein TS Server in nicht sporadischen Abständen alles kickt und der Server daraufhin nimmer erreichbar ist für paar Sekunden. Selbst ich wurde gekickt und das obwohl ich im LAN bin während die anderen vom Internet aus zugreifen.

Ich hab in der Zeit auch einen 2. WLAN Repeater installiert da die Reichweite sonst nicht ausreicht und das Internet abbricht. Nun die Frage: Wie kann ich analysieren was das Problem ist? In dmesg beginnt der letzte Eintrag mit der Nummer [7148187.802702] falls das was hilft. In der Meldung wurde tatsächlich das Eth Kabel angesteckt. Kann es am Repeater liegen?

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Nach Update dis/re connects

Beitrag von rendegast » 14.01.2015 17:10:31

Die Upgrades liefen fehlerfrei durch?

Code: Alles auswählen

apt-get -s dist-upgrade
dpkg -l | egrep -v "^ii"
Wird denn der Kernel 3.2 überhaupt benutzt?
<-> evtl.weitere kernel, zBsp. 3.16 bpo

Code: Alles auswählen

cat /proc/version
Den vorherigen Kernel kannst Du bei http://snapshot.debian.org bekommen.

Haben apache (http/https) / php Probleme?

Benutzt der TS überhaupt apache / php / openssl?

Vielleicht ein Angriff, der den TS zumindest kurzfristig offline setzen kann?

-> Logs des TS
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Success
Beiträge: 288
Registriert: 01.06.2013 21:23:15

Re: Nach Update dis/re connects

Beitrag von Success » 15.01.2015 16:19:42

Die ersten 2 Befehle hab ich ausgeführt. Weiß zwar nicht was mit den ganzen aufgelisteten Programmen ist aber sieht in Ordnung aus.

/proc/version gab
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.63-2

aus

apache hab ich gar nicht da Teamspeak nicht auf Apache basiert.

Letzte Logdatei (gestartet am 26. Dezember also lange vor dem Problem) https://pastebin.com/sNtmz8kK

Wäre es ein Angriff auf den TS Server, würde ich ja noch über ssh reinkommen in den Server oder?

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Nach Update dis/re connects

Beitrag von rendegast » 15.01.2015 19:32:17


Weiß zwar nicht was mit den ganzen aufgelisteten Programmen ist aber sieht in Ordnung aus.
Ich weiß jetzt auch nicht, aber das ist dann wohl okay.
apache hab ich gar nicht da Teamspeak nicht auf Apache basiert.
Gut daß Du mich aufklärst,
von den obigen Ausgaben hätte ich dann fälschlicherweise einen installierten apache vermutet.

Letzte Logdatei
Die serveradmin-Logins aus der Fremde sind okay?
Wäre es ein Angriff auf den TS Server, würde ich ja noch über ssh reinkommen in den Server oder?
Da Du von TS erzählt hast, schloß ich erstmal "nur" eine bemerkte Beeinträchtigung beim TS-Dienstes.

In der Log: öfter keine DNS-Auflösung, wohl durch fehlende Netzwerkverbindung.
Kein DNS, weil der (wlan-)Router kaputt ist? oder der wlan-Stick?
Was mit 'dmesg'? Routerlogs?

Kann während der Ausfälle noch das wlan gescannt werden? zBsp. sowas wie

Code: Alles auswählen

iwlist wlan0 scan


Sollte der Server per wlan angebunden sein/werden,
tendiere ich generell zum Betreiben mit dem neueren Kernel 3.16 aus backports.

Auch wlan b/g -> wlan n.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Success
Beiträge: 288
Registriert: 01.06.2013 21:23:15

Re: Nach Update dis/re connects

Beitrag von Success » 16.01.2015 17:16:52

so ich glaub ich hab den Fehler. Der Server und der 2. WLAN Repeater kämpften um die gleiche IP Adresse. Lag also doch nicht an dem Update. Was mich in den Logs stört ist halt das Programme wie cron alles zumüllen.

Jan 16 16:51:56 server CRON[21427]: pam_unix(cron:session): session closed for user root
Jan 16 16:56:01 server CRON[21433]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 16 16:56:56 server CRON[21433]: pam_unix(cron:session): session closed for user root
Jan 16 17:01:01 server CRON[21437]: pam_unix(cron:session): session opened for user root by (uid=0)

so geht das die ganze Zeit dahin. Kann also die Logs nicht richtig auswerten immer da ich mich erst durch 4116 Zeilen durchackern muss. Von den 4116 Zeilen sind vielleicht 50 Logins von mir.

Und ja Logins von "fremden" IPs sind ok, da ich mit mit meinem Androiden mobil nach dem Rechten schaue. Ein Hacker kann da soweit ich weiß nicht rein da man nur mit einer gültigen id_rsa einloggen kann. Aber da du es schon ansprichst, kann man bei anderen Logs wie proftpd die IP UND das Land von dem die IP kommt protokollieren? Derzeit kopier ich die IP Adressen und schau sie mir in utrace.de an. Manchmal versuchen welche mit einer .su Domain (China vielleicht?) sich mit dem User Anonymous via FTP anzumelden. Aber nur 3x weil dann bannt fail2ban die jeweilige Adresse.

Antworten