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?
Nach Update dis/re connects
Re: Nach Update dis/re connects
Die Upgrades liefen fehlerfrei durch?
Wird denn der Kernel 3.2 überhaupt benutzt?
<-> evtl.weitere kernel, zBsp. 3.16 bpo 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
Code: Alles auswählen
apt-get -s dist-upgrade
dpkg -l | egrep -v "^ii"
<-> evtl.weitere kernel, zBsp. 3.16 bpo
Code: Alles auswählen
cat /proc/version
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")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Nach Update dis/re connects
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?
/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?
Re: Nach Update dis/re connects
Ich weiß jetzt auch nicht, aber das ist dann wohl okay.
Weiß zwar nicht was mit den ganzen aufgelisteten Programmen ist aber sieht in Ordnung aus.
Gut daß Du mich aufklärst,apache hab ich gar nicht da Teamspeak nicht auf Apache basiert.
von den obigen Ausgaben hätte ich dann fälschlicherweise einen installierten apache vermutet.
Die serveradmin-Logins aus der Fremde sind okay?Letzte Logdatei
Da Du von TS erzählt hast, schloß ich erstmal "nur" eine bemerkte Beeinträchtigung beim TS-Dienstes.Wäre es ein Angriff auf den TS Server, würde ich ja noch über ssh reinkommen in den Server oder?
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")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: Nach Update dis/re connects
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.
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.