Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

SSH bruteforce on its way...

Subject: SSH bruteforce on its way...
Date: Wed, 19 Oct 2005 21:47:10 +0200
Greetings!

In the last days I observed a rising number of SSH bruteforce attempts
against my servers, trying to find valid user names. One distiguishing
feature is a typo in the used names: "deutch" (instead of "deutsch",
which is directly following its english translation "german"). It seems
to work in 3 phases: a portscan, followed half a day later with a user
name scan, which probably(*) followed by a passwort attack against 
harvested user names.

From what I was told the bot installs files into /var/tmp/.bash/, among
them an IRC-Bouncer. Entry to the infected system was gained via a
successful SSH bruteforcing. (Un)fortunately I have to rely on
second-hand reports on this worm, as I only have seen SSH bruteforce
attempts increasing quite noticably on the last few days.


My recommendations to discourage/prevent this SSH bruteforcing:

1.) Use key authentication and disable plain password logins. This 
    way password bruteforcing itself is practically impossible. 

2.) Running SSH on a port NOT tcp/22 - okay, that's just obfuscation, 
    but false connects/scans dropped from a some attacking hosts an 
    hour to zero.

3.) Another possibility to prevent (or at least: seriously delay)
    bruteforcing to be done successfully is to inhibit multiple 
    connects within a given timeframe. See
    http://www.debian-administration.org/articles/187

4.) And of course: monitoring! Especially for illegal user logins or
    unsuccessful passwords.


On the other side: has anyone been infected and/or had the chance to
inspect the rootkit and/or the aims the people running the botnet try 
to achieve?

Thanks

Volker


(*) Well, I was myself not affected, but often saw the connects. Alas
    only the first few ones before the transgressors were shut out for 
    a few hours (see recommendation 3)...   ;-)

-- 

Volker Tanger    http://www.wyae.de/volker.tanger/
--------------------------------------------------
vtlists@wyae.de                    PGP Fingerprint
378A 7DA7 4F20 C2F3 5BCC  8340 7424 6122 BB83 B8CB

<Prev in Thread] Current Thread [Next in Thread>