I believe a known issue regarding the ssh.com SSH server was released within the past two or three weeks - it's probably being scanned for pretty heavily. Details were on bugtraq. This is probably what this is, if you're running OpenSSH you should be fine. There's also that pesky problem with OpenSSL which affected OpenSSH on a number of platforms compiled using the vulnerable OpenSSL, it could be a scan looking for that as well. I get scanned a good 10 unique times a day, I would assume most people get scanned quite frequently as well, so as long as there're no signs of a system compromise, you shouldn't lose too much hair over it. Go through the motions, check the box for SSHD core files, etc etc, and make sure the box is safe just to be sure. Never does hurt. :-) Also check to be sure that you're using the latest stable versions of everything, especially your SSH servers and anything else [web servers, etc] that may use OpenSSL and make sure that OpenSSL itself is updated, and any binaries linked with it are suitably recompiled to use the correct and safe version and all that good stuff. Bojan Zdrnja wrote: > I suppose this is plain SSHD buffer overflow attack, followed by 'id' > commands. Attacker tryed buffer overflow (which didn't succeed, > according to logs) and after that he tried to execute 'id' commands to > see if his attack worked (ie. If he managed to elevate his privileges). > IIRC, SSH expects protocol identification as first data on the channel - > attacker tried overflow and then 2 commands which SSHD interpreted as > bad protocol identification. > > In-Reply-To: > > <1395.136.159.104.19.1038501745.squirrelat_private> > > > > I wouldn't worry too much about this. These type of log events are > > usually symbolic of some type of network scanner or brute > > force scanner. > > You can duplicate a similar log event by using nc or telnet > > and connecting > > to a 'ssh' server ( nc -vv hostAddress 22 ). However, I would be > > concerned with whatever service you have listening that are > > identified in > > you logs before the ip address of the remote connection ( ie /bin/id > > and /usr/bin/id ...). I would check to see what these > > services are and if > > you don't need them I would disable them as it may be possible that > > someone is trying to exploit that service. > > > > jm > > > > > >Had the following entries in brought to my attention by > > LogWatch this > > >morning. > > > > > >Can anyone guide me to what they might be and if I need to > > be concerned > > >about them? -- /* * * Matt Harris - Senior UNIX Systems Engineer * Smithsonian Institution, OCIO * */ ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Dec 02 2002 - 15:19:51 PST