Hi! We've had a strange episode with out servers, maybe somebody has seen something similar. We first had one of those SSH attacks with invalid users. But then something that I had not seen before, but probably nothing serious. Here is some log: Sep 29 08:15:58 server sshd[20976]: Invalid user andreyd from ::ffff:194.51.214.195 Sep 29 08:15:59 server sshd[20976]: reverse mapping checking getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE BREAKIN ATTEMPT! Sep 29 08:16:00 server sshd[20978]: reverse mapping checking getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE BREAKIN ATTEMPT! But then somewhat after that (half an hour) our /var was suddenly turned to read-only. So the logs had a gap for about an hour: Sep 29 09:24:27 syrphus kernel: Additional sense: Invalid field in cdb Sep 29 09:25:01 syrphus /usr/sbin/cron[22405]: (root) CMD (/usr/local/bin/bruschedule) Sep 29 09:25:28 syrphus kernel: st0: Error with sense data: Current st0: sense key Illegal Request Sep 29 09:25:28 syrphus kernel: Additional sense: Invalid field in cdb Sep 29 10:29:15 syrphus syslogd 1.4.1: restart. Sep 29 10:29:16 syrphus SuSEfirewall2: Warning: FW_MASQ_NETS needs FW_MASQUERADE set to yes to work! Sep 29 10:29:16 syrphus nmbd[4536]: [2005/09/29 10:29:16, 0] libsmb/nmblib.c:send_udp(790) Sep 29 10:29:16 syrphus nmbd[4536]: Packet send failed to 10.0.0.255(137) ERRNO=Operation not permitted When something made the /var read-only, we of course had multiple problems. So the first question is: is there some new hole in SSH? We have SuSE 9.2 with open ssh 3.9p1-3.2 which is the newest one from YOU. And we do not have any other ports open to the server. We returned /var and some other stuff from tapes and checked that nothing really is changed. So we do not believe that anybody got in. But how else can the /var become read-only... any ideas? One of the problems that read-only /var caused is that "random" files changed to be owned by root in users home dirs. These included files like: .Xauthority, .DCOPserver_*, .ICEauthority as well as others from .kde. Fixing this was a pain... As we looked at the situation in data files more carefully, it seemed that all the files that had been modified during that time were now owned by root. We think this means that when the users logged in, the setuid didn't work correctly and the processes were left as root - i.e. the users were acting as root. Which, if is true, is kind of scary... -- HG.