On Thu, Feb 18, 2016 at 10:13:48PM +0100, Chris wrote: > Dear All, > > after the following entry > > Feb 18 17:48:05 jupiter sshd[30204]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.88.177.93 > user=root > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ > > my Jessie Server was down. > > Has anyone seen this?
If you meant "failed ssh connections from CHINANET-GD IPs" - then yes. Iptables works wonders for those - it's not that I plan visiting China anytime soon :) But if you meant "strange line of escape sequences in /var/log/auth.log" - then no. > Went it accidentally down? Surely you know that auth.log is not the best place to search causes of host reboots. I'd start with /var/log/kern.log. Maybe /var/log/messages. > Is this already an libc exploit? Hardly. Recently patched CVE-2015-7547 (glibc getaddrinfo) could be used for arbitrary code execution, but it would require crafted DNS records. Of course, problematic DNS records could be served from whatever DNS this host uses, but for me reverse DNS lookup for 125.88.177.93 ends with NXDOMAIN. Reco