Highway to Dell, part six

(Continued from Highway to Dell, part five.)

Yesterday I noticed a problem with ssh on the Dell Inspiron 1525: I could ssh in any direction between the laptop and other computers on the same wireless network, but not to a computer outside of the wireless network. The issue was already reported as Bug #237894: I cannot connect to any server. Conection hangs up at "channel 0: open confirm rwindow 0 rmax 32768". The solution – as documented in the comments to the bug report – is easy but a bit unexpected: Disable the wl driver and use ndiswrapper for the wireless network interface! As I already had ndiswrapper working in Ubuntu 7.10, i only had to reboot after disabling the wl driver and the ndiswrapper was used instead and ssh worked!

Amazon Web Services used for ssh login attempts

I get ssh login attempts almost daily, mostly from DSL, asian or eastern european IP addresses but this one caught my eye:

 Illegal users from these:
    75.101.221.220 (ec2-75-101-221-220.compute-1.amazonaws.com): 210 times
       admin/password: 16 times
       test/password: 15 times
       tester/password: 15 times
       testing/password: 15 times
       guest/password: 14 times
       adm/password: 6 times
       administrator/password: 5 times
       .
       .
       .

It comes from Amazon Web Services! I thought that "cloud computing" for these attackers meant "bot network", but maybe that is not the case?

Let’s see what their abuse support says!

 

Domain-name based ssh login attempts

The last few weeks I have noticed some illicit ssh login attempts that uses parts of the reverse DNS domain name as user name when it tries to login. The last attempt looked like this in my LogWatch summary:

Illegal users from these:
    195.38.107.55 (aquila.euroexpert.tvnet.hu): 9 times
       root/password: 4 times
       cenara/password: 2 times
       ip-83-209-13-88/password: 2 times
       ip-83-209-13-88.cenara.com/password: 1 time

As you can see, the secondary and tertiary domain name, along with the full domain name, was tried as user name when attempting to login. I guess that the attack script tries with a blank password and also with the same password as user name.