well at least you have a good chance that no real person attacked you and
played around with your data but this was more like an automated attack ..
something like codered =)
http://it.mycareer.com.au/breaking/20010119/A14830-2001Jan19.html
i heart that even the recent sshd versions fall back to ssh1 if the client
requests them to do so .. but this doesn't mean they are vulnerable, does it?
i disabled ssh1 anyway .. better safe than sorry ;-)
----- Original Message -----
From: "Leen de Braal"
I checked with chkrootkit (from a laptop, mounting the server's root dir locally) and this warned for the ramen rootkit. At this moment I am running a backup of the user data (to be sure to have it all) before I am going to do any more. I did get the plug off of the cablemodem (now mailing from the laptop over the phone), so as long as I run the backup, risk is low (isn't it?....). I think I will reinstall with latest software anyway, because I already planned to add a new harddisk in this server. Good moment to do it now ;-)
At 16:16 19-2-2002 -0500, you wrote:
Hallo,
1st do not panick. The crc32 is a known SSHv1 implementation attack and is addressed/defined under the CVE www.cve.mitre.org.
While it is very possible the IP may be attempting to issue a crc32 attack against your SSH daemon it could be a possible false positive
but there is a strange IP in the logs...
alarm. (I was not aware that SSH had provided an alert as so shown below but an IDS such as Cisco or Snort will detect this kind of ssh attack due to its publication in the CVE list.)
Your logs do not show SSH because you most likely do not log what other than you deny. You are allowing SSH and unless you are logging
correct
all connections you will not see this in your logs. Please also review what SSH version and Implementation you have. Temporary block ssh access, upgrade the package, and you can then re-open. Identify
as said, I will upgrade anyway. This is a SuSE 6.4 distro, probably never checked for security issues. This way, I must agree, you have to run into it sooner or later..
the CVE from the above link, use Snort IDS on your eth0 along with this signature rule, and monitor or filter for ssh traffic. You will now be moderately safe but at least in control.
Gruesse, Ryan J.W.Swenson
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here