S: ssh worms FAQ

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

There is many ssh worms in the Internet since this summer.
These worms often try to access
"test", "guest", "admin", "user" and "root" accounts.
See details in http://seclists.org/lists/fulldisclosure/2004/Jul/1243.html

But I didn't find any resource
such worm's [potentional] victims may be pointed to.
Not general morals on UNIX security,
but namely some considerations on ssh security aspects
related to worms vulnerability.
UNIX shell worms appears as poorly documented topic,
compared e.g. to M$XP RPC flaws or mail .EXE winworms.

Namely, I want a text readable by UNIX novices
that ssh is a very powerful remote access method,
that it's extremely dangerous to have
accounts with "default" (set by distro etc.) password
even because of spammers' menace,
that some Linux kernels can be easily rooted
by any [unprivileged] local account
(do_brk flaw up to 2.4.23pre etc.),
that admin should change "default" passwords and delete unused accounts,
that there is some automated scripts (worms) exploiting ssh in the Net,
their traces can be found in /var/log/ ,
that it's good to notify the admin/owner of the originating host(s),
that a lot of outgoing ssh request is very suspicious fact,
that, last but not least, a great army of script kiddies exist...

Do somebody have or read such FAQ?

qq~~~~\    [ IP ]
/ /\   \    [ FAQ you ] at news:local.chainik rules at
\  /_/ /

Re: S: ssh worms FAQ

Quoted text here. Click to load it

Someone should name a distro which does this. None of the big-name ones
I've seen do, yet presumably such stupidities as guest/guest come about
from somewhere...

   19:44:47 up 29 days,  3:20,  1 user,  load average: 0.85, 0.82, 0.53
piglet@stirfried.vegetable.org.uk |And the wind / And the rain
http://spodzone.org.uk/cesspit/ |Falls around

Re: S: ssh worms FAQ

Quoted text here. Click to load it
I don't think there is a step-by-step guide to running and securing ssh,
but I'm not sure there should be. Step-by-step is good for making
something work when you don't understand it, indeed the only way, and if
you miss a step it will not work and you will go back and find what you
did wrong. If you miss a step in securing something it will probably
still work and you won't know you left a hole.

There are several tutorials on ssh, as I'm sure you found when you
looked. None of them seem to contain all the important security bits.
Much of ssh security comes from using hosts.allow and hosts.deny, and
iptables, as well as good general habits concerning users, passwords and
so on. These are not ssh specific and do not really belong in a tutorial
for a particular service.

The success of the current ssh worm is totally dependent on very bad
user and password control, or poor Unix morals as you put it. You
already know the answer to that. You don't need a detailed understanding
of either ssh or worm anatomy to stop it. I could be wrong, but I
believe all the ssh vulnerabilities in the last few years have required
either local access or remote login to a genuine account to exploit
them. A matter of Unix security morals. If the bad guys have got as far
as logging on to your machine, you're already too late.

Probably most of the ssh-specific information is in the sshd_config man
page and the file itself. AllowUsers is probably the single most
important feature here, though an understanding of the various
authentication mechanisms is also necessary. I would suggest that if
these sources and the general ssh tutorials on key pairs are too hard to
deal with, then it is not appropriate to open ssh to the Internet.
There's too much knowledge required for a beginners' FAQ to be of much
use. It would need to contain much of the man page.

Unfortunately, the only simple security instruction for the novice is
not to open any service at all to the Internet until such a time as it
is understood, along with firewall operation and the other general
Linux/Unix security measures. Sorry if that's not what you want to hear,
but the world is full of Windows machines opened to the Net by people
who have no idea about the risks, and how to (try to) avoid them. Their
uncracked life expectancy is currently about 20 minutes.

introduction to ssh worms (draft)

Joe wrote:

Quoted text here. Click to load it

Mm... I don't be interesting in UNIX accounts setup tutorial,
not for me, not for my friends etc.
I'm interesting in _existence_ of that resource (URL),
which we can use in complaints to compromised machine's ISP,
and, of course, to which to point people affirming that:

* Somebody tries to access (via ssh) his machine;

* Somebody "scans" his IP block;

* Somebody says that "he" cracked some host(s),
 but it's a defamation;

* There is a lot of outgoing ssh traffic in his host/network;


I'm sure that even ISP admins are not so familiar with ssh worms _yet_.

Quoted text here. Click to load it

IMHO to run a world-opened sshd isn't a poor moral yet.
Some admins really have many shell users worldwide,
and others may have special public shell-like services.

Quoted text here. Click to load it

Yes, I don't claim that
ssh worms FAQ must give _detailed_ understanding of ssh or worm anatomy.
But it must explain that such _phenomenon_ as ssh worms exist in today's

So you can estimate this effort to create such FAQ with the help of this thread.
There are many speculations and many "general" morals,
but I hope that this text can be used as an introduction to the problem,
at least if improve a little a bad English.

All remarks are gratefully accepted.   Additions also are wanted.
Followup to news:comp.security.ssh is set.
Use that newsgroup except OS-specific notes.

Should I read this?
Why this FAQ?
Is there some patche(s) against this kind of worms?
What means /account/?
What means /good/ or /bad/ passwords?
What is shell access?
What is ssh?
What is sshd?
Do I need sshd???
Why unauthorized shell access is dangerous?
Why ssh access may be dangerous? Ssh is known to be very secure.
What harm can ssh access cause except the shell use itself?
Why ssh access to "root" is disabled in most UNIX systems?
Are ssh worms like the Morris Worm of 1988?
How ssh worms work?
Must a worm have a "root" (privileged account)?
Do worms try empty passwords?
Do worms exploit other ssh vulnerabilities except bad passwords?
So why it works?
What are aims of ssh worms?
What are signs of ssh worms?
I was probed by a worm... what to do?
Can ssh worm jam the network?
I am a host admin.  What should I do to prevent worm intrusion?
Should I move sshd to some TCP port differ from 22?
Are vulnerable ssh accounts really exploited by worm (or bad guys) just after
its detection?
Are there in the Net automated ssh worms?
So what is ssh worms in general sense?
Which hosts are vulnerable?
Some host/network administrators defamatorily accuse me in illegal use of some
ssh accounts.
I'm a host admin and my machine is compromised by such worm. What should I do?
I'm a network admin and there are ssh worm in my network, but I have no
administrative access to compromised OS.  What to do?
I am a user (not admin) of the compromised OS.  What can I do?
Can antivirus programs prevent intrusion, destroy or detect a ssh worm?
Can Windows hosts be sources of ssh worms?
Ssh worms in the future.
I want to hunt these wormy kiddies!

Q: Should I read this?

A: This FAQ is intended to be read by:
 * Host admins who want their hosts to be accessible via ssh;
 * Any people dealing with suspicious network activity on TCP port 22.
 If you are none of the above and have not some special interest in network
 then don't read this.

Q: Why this FAQ?

A: Evidently, ssh-related malicious software is not so harmful yet
 as Windows worms are.
 The present examples of /ssh worms/
 are only semi-automated programs used by script kiddies.
 But ssh attacks threaten to open software OSes.
 Winworms don't except flooding networks.
 It's M$ who will protect Winusers,
 open software users must protect the world of open software themself.
 Today ssh is a core of UNIX-based Internet security.
 Attacks to ssh must be studied, even to discriminate
 more dangerous attacks from less dangerous as this /worms/ are.
 In the future, will be more sshd hosts, more servers, more UNIXes.
 UNIX admins, especially newbies, should know about ssh worms' menace.

Q: Is there some patche(s) against this kind of worms?

A: No patches are known to me and no patches required.
 Edit your system accounts' list
 and disable all such "test", "guest" and "user" accounts,
 or at least set good passwords to them :)

Q: What means /account/?

A: Account is an identity by which operating system (OS) distinguish its users.
 The traditional authentication scheme is login:password scheme.
 Each account have the name (which also known as /username/ or /login/),
 and the password.
 The name is known by other OS users, but the password certainly shouldn't :)
 Using login:password scheme, user can access the OS (/log/ into it) by many
 ssh, telnet, FTP, NetBIOS, POP3, by many other network protocols, locally, via
 all this using the same password per account.
 Practically not all protocols are be available for any account.
 If there is an account to which we can log via ssh, we'll call it a /ssh

 There is some (usually 1) /privileged/ account(s) in an OS,
 which system administrator uses to manage the OS(=host=machine=computer).
 The "guest" account was commonly used in the past
 for an occasional (guest) access to systems by people which haven't own
 This account had no or a very simple password.
 But in modern Internet with an army of bad guys, this practice is deprecated.
 OS also has some accounts for its internal purposes only,
 access to which is restricted or prohibited.
 For the accounts' list, look at /etc/passwd file in UNIX systems.
 There are special GUI tool to manage accounts in Windows NT systems.

Q: What means /good/ or /bad/ passwords?

A: A /bad/ password is a short or easy to guess password,
 like "123", "password" or "test".
 A /good/ password is a non-dictionary text containing at least 7 characters,
 like "kf^nbybwf", "8eG(0)dPa//wd" or "clW4bjl".

Q: What is shell access?

A: Shell access is an ability to run shell commands on target OS.
 It usually means that user can run any program there, including a self-made one,
 and such program will be restricted only by general OS restrictions to this
 Traditionally, shell access was performed locally, by modem or by special wires.
 Such internet technology's means as ssh and telnet are intended mainly for
shell access,
 but the use of telnet for this is now deprecated due to insecurity.
 Shell is quite more powerful than FTP, NetBIOS, POP3 and so on.
 This is normal access method for UNIX systems,
 there are no /UNIX user/ without a shell :)
 Some other OS types also have a shell and sshd software.
 If your have UNIX, you must know what is shell access.
 If your system isn't UNIX and you don't know what is shell access,
 you happily shouldn't know what is ssh :-)

Q: What is ssh?

A: It's a secure replacement for the telnet protocol,
 which was designed to provide a shell access ability over Internet.
 To authenticate an user, ssh can use a login:password, as telnet does.
 There are some other authentication methods than login:password,
 but these methods appears not to be used by worms.
 See http://kimmo.suominen.com/docs/ssh/ as a general ssh description.
[ may be some more links to ssh here ]
 You also can just search the Web ;)

Q: What is sshd?

A: This is a name of ssh service (/ssh-daemon/) on UNIX systems.
 It accepts incoming ssh requests, authenticate users,
 then check whether this access attempt matches some system security rules,
 and opens a shell session if it matches.
 It's normal for sshd to listen the TCP:22 port, because it's a standard ssh
 In this text I'll call /sshd/ any ssh server software.

Q: Do I need sshd???

A: You don't...... if you really asking this.
 So, as you don't need sshd on your host, remove it now.
 To check what TCP services runs your host, use commands
  for Linux:     netstat -tl
  for Windows and FreeBSD:    netstat -a -p tcp
 If you see the word "ssh" in the "Local Address" column,
 then sshd is listening on your host.

 As you don't need sshd, you also don't need telnetd,
 because it is also for shell access.
 Look for "telnet" in the "Local Address" column,
 then remove telnetd if present.

Q: Why unauthorized shell access is dangerous?

A: Normally, OS give almost full network freedom
 to even unprivileged user account.
 Bad guy from Internet can do many bad things with a shell account.
 He can easily:
 * Begin to crack another Internet hosts in a name of your;
 * ... especially hosts in your local network;
 * Send a SPAM (E-mail or in another form);
 * ... especially through your ISP's mailgate;
 * Use your host in DDoS attacks;
 * As consequence of the above, flood your LAN and Internet link.

 Some systems are strongly protected against network intruder,
 but weakly protected against rogue user inside.
 The worst thing bad guy can do is to take over a privileged account
 attacking the system from /his/ unprivileged account.
 If he done it, or if compromised account was originally
 bad guy take a _full_ control over your host and you loose all your game.

Q: Why ssh access may be dangerous? Ssh is known to be very secure.

A: The security of ssh concerns _how_ access is performed, not _who_ does it.
 Account with bad password is unsecure itself, regardless of access protocols,
 because anybody who guessed the password have the /right/ to use it.
 The door of your home also may have very secure locks,
 but if keys hang outside the home near the door, then you door is not so secure.

Q: What harm can ssh access cause except the shell use itself?

A: The so-named /port forwarding/ feature is theoretically very unsecure
 if we assume that bad guy have an ssh account.
 Read details in your sshd's manual.

Q: Why ssh access to "root" is disabled in most UNIX systems?

A: This account is present on any UNIX box and has an absolute power in the OS.
 It's a great temptation for cracker to guess the root's password.
 This restriction doesn't embarrass a legitimate UNIX admin.
 He just logs into his /private/ account, and then says "su",
 enters the root password and become a root.
 But a cracker may even have no knowledge on admin's username,
 as any other usernames in a concrete UNIX box except "root".

Q: Are ssh worms like the Morris Worm of 1988?

A: Don't panic :-)
 The thing that I call /ssh worms/ is only some kiddies' attempt
 to harvest ssh accounts on hosts ruled by *very* lame admins.
 This is *very* weak compared to Morris' sophisticated password fishing
 A /ssh worm/ uses only fixed number of login:password pairs.
 Worms use very common methods,
 perhaps with a use of lot of free published code,
 so I'm even not sure that /authors/ programmed something at all.
 Nevertheless, some signs of /ssh worms/ are now well known to UNIX admins.
 It's this fact that is a threat.

Q: How ssh worms work?

A: Only UNIX software specimens are studied.
 At the first stage, a TCP SYN portscanner looks for sshd hosts in some IP block.
 All hosts where open TCP port 22 is detected, are listed.
 At the second stage, a special program tries
 to log in "test", "guest", "admin", "user" and "root" accounts on each listed
 Some /default/ passwords as "guest" or "test" are used.
 See details in http://dev.gentoo.org/~krispykringle/sshnotes.txt .
 Third stage (a real shell intrusion to accounts found)
 seems not to be automated yet and permormed manually by kiddie-crackers.
 But it's true only for already known worms;
 it's not so difficult to improve worms software to make intrusion automated.

Q: Must a worm have a "root" (privileged account)?

A: A good question...
 We know that the "root" is strongly required for TCP SYN scan in UNIX systems,
 which apparently used in the worm's first stage.
 Where so many of compromised "root" accounts are from,
 is a number of imbeciles having "root" and "123" passwords on "root" really so
 Do crackers obtain "root" from another account due to OS flaws?
 Or /connect/ scan instead of SYN is used under unprivileged accounts?
 Maybe first and second stages can take place on different hosts?
 I don't know anything about this.
 The second worm stage doesn't require special privileges at all,
 so can take place under any "test" or "guest".

Q: Do worms try empty passwords?

A: They never do it yet, perhaps because of defaultly configured sshd's refusal.
 But having accounts with empty passwords is unsecure ;(

Q: Do worms exploit other ssh vulnerabilities except bad passwords?

A: There were some flaws in early implementations of ssh protocol.
There are some potentional cryptographical weaknesses.
But I don't know do worms try to use it or no.
I'm not an expert. Ask experts.

Q: So why it works?

A: Evidently, due to a great number of lazy admins.
 Theoretically, some wide-used badly designed account manager
 could set a lot of "default" passwords,
 but nobody can explicitly name such buggy system administration software,
 there are only rumours.

Q: What are aims of ssh worms?

A: It seems that modern ssh worms
 not only spread over the Net like most of Windows worms.
 They apparently harvest ssh accounts for their masters.

Q: What are signs of ssh worms?

A: Ssh worms have one major sign: many TCP connection attempts to port 22.

 If you detected some incoming ssh connection requests,
 this not always means that your host is probed by a worm.
 If you keep ssh port closed but log any attempts to connect,
 you have no means to distinguish a ssh worm from an usual port scanning.
 But if you have sshd (keep ssh port open)
 and see 5 or more connections from the same IP in few seconds,
 then you see a source of ssh worm.
 Ssh worm scan from few number of different sources weekly
 is usual in today's Internet.

 If you see a lot of _outgoing_ ssh connection requests to different hosts,
 it's no doubt that you have an ssh worm inside.

 If you are logged into a compromised host,
 you probably should see some CPU-consuming process(es)
 owning many TCP sockets destined to port 22.

Q: I was probed by a worm... what to do?

A: Extract source IP address from logs,
 seek abuse or administrative contacts via whois databases
 ( directly with "whois" utility or see
 then inform them politely that they apparently have an ssh worm.
 Don't forget to give a link to this document ;)
 Remember: most of ssh worms victims are UNIXes,
 and all UNIX users should be friendly :)
 If you are lazy, do nothing.
 If you are hazardous or hate spammers/crackers, read at the bottom of this FAQ.

Q: Can ssh worm jam the network?

A: It's difficult to a worm outside to jam _your_ network.
 But if there are compromised machine inside,
 then an active ssh worm in the second stage
 can and should essentially flood your Internet link
 unless you have bandwidth of many Mbps.

Q: I am a host admin.  What should I do to prevent worm intrusion?

A: Set good passwords to all accounts you need,
 and eliminate (disable) all accounts you don't need.
 Read sshd documentation and configure it properly.
 This appears to be a good protection against ssh worms,
 today's and future ones.

Q: Should I move sshd to some TCP port differ from 22?

A: What?  Do you _so_ afraid of these silly worms that want to hide yourself?!

Q: Are vulnerable ssh accounts
 really exploited by worm (or bad guys) just after its detection?

A: For today ssh worms the answer in /no/ :)
 I don't know when and how these accounts are used,
 but it seems reasonable to use it for further worm spreading :)

Q: Are there in the Net automated ssh worms?

A: Probably, fully automated ssh worms exist, but I didn't see so I'm not sure.
 There is a lot of script kiddies though who can
 manually run a script in a shell account,
 manually log in some of gathered accounts,
 manually run the same script from there and so on.
 See more details in http://seclists.org/lists/fulldisclosure/2004/Jul/1243.html

Q: So what is ssh worms in general sense?

A: There are no essential difference between
 automatical ssh scan script initiated by some automated intrusion program
 and ssh scan script controlled by kiddy's interactive shell.
 In both possible cases it's bad guys who gather information on ssh accounts.

Q: Which hosts are vulnerable?

A: Any host that runs sshd may be vulnerable.
 OS type does not matter:
 if you have not UNIX but VMS or even Windows running sshd,
 the worm *can* log in and inform its master that you are vulnerable.
 Although non-UNIX system will unlikely be used for worm spreading,
 the shell account discovered by the worm
 can be used later by spammers or crackers for another /purpose/ :-/

Q: Some host/network administrators defamatorily accuse me
 in illegal use of some ssh accounts.

A: If your have a box running sshd from where illegal sshes were logged ,
 check "test", "guest", "admin", "user" and "root" ;) accounts for signs of
 It there is not, just look TCP sockets and active processes.
 Check all accounts on your machine for signs of unauthorized use.
 If nothing helps, tell your firewall or sniffer to log all outgoing TCP:22
 For UNIX, "root" can use the following command:
  tcpdump src host suspect_host_address and dst port 22
  tcpdump src host suspect_host_address and dst port 22 -w out_ssh.dump
 to log in the file all ssh attempts.
 A traffic can be sniffed on router box or on suspect host itself.
 If you detected an abnormally high activity,
 look for corresponding active processes and read below.

Q: I'm a host admin and my machine is compromised by such worm.
 What should I do?

A: This is not a FAQ on general network security.
 Read http://www.markusjansson.net/ehacked.html if your box is on UNIX.
[ I don't think that it's a good tutorial, do you know something better? ]
 Ah, you know yourself what to read and to do because you are admin, isn't it?
 After you kicked the intruder out of your system,
 look for evidences left in the compromised account.
 Some binaries may be present, scripts, shell history and lists of probed hosts.
 Try to notify admins of these hosts, but never publish such lists
 because it can be lists of _compromised_ hosts.
 Of course, look to your system logs to identify the origin of the attack.

Q: I'm a network admin and there are ssh worm in my network,
 but I have no administrative access to compromised OS.  What to do?

A: Let the router/firewall drop
 all TCP packets going from the compromised host destined to port 22.
 Check for inbound ssh connections,
 because a /worm/ may be controlled interactively.
 Try to tear it down, blocking the originating IP.
 Contact the host administrator/owner.

Q: I am a user (not admin) of the compromised OS.  What can I do?

A: First of all, look who of OS /users/ are logged on.
 Understand which account is compromised.
 Disconnect the network physically
 if you can and if it isn't a critically important server.
 Contact your system or network administrator as soon as possible in any case.

Q: Can antivirus programs prevent intrusion, destroy or detect a ssh worm?

A: Modern ssh worms use some software components
 which are known as malicious by many antiviruses.
 It's doubtful that antivirus
 can destroy an _active_ worm on UNIX, though.

Q: Can Windows hosts be sources of ssh worms?

A: Today can't, but in the near future can.
 There are too many zombie winhosts remotely controlled by spammers,
 and it's not difficult to build such software for Windows.
 But at the moment [September 2004],
 spammers are not especially interested in ssh attacks yet.
 There are not so many hosts running sshd today.
 But the structure of Internet changes.
 We see more LANs linked to Internet on broadband
 (small offices or home networks),
 protected by UNIX (FreeBSD or Linux) firewalls.
 We see more UNIX servers, also on broadband.
 These UNIX firewalls and servers usually have sshd.
 Taking over a shell account on such system
 gives more profit to spammer or cracker
 than trojan on a home winmachine with thin 128Kbps upstream.
 I'm sure that spammers will start attacks on UNIXes soon.

Q: Ssh worms in the future.

A: IMHO: More versions.  More sources.
 More tries from one source, but perhaps less rapidly.
 Harvested accounts will be *quickly* used for spamming,
 because it's spammers who are most powerful among bad Internet guys.

Q: I want to hunt these wormy kiddies!

  *** DISCLAIMER ***  These recommendations are experimental.
  Use it at your own risk.
  In no event shall author be liable for any direct, indirect, incidental
  or consequential damage resulting from the use of the following material.

A: I think the best way to hunt them is to make the trap.
 Unlike the case of most Windows worms and trojans,
 it's not difficult to make a trap on the worm master, a ssh harvester.
 So, if your have a UNIX box with sshd open to the Internet,
 Certainly, don't give them a real shell access.
 Only a dirty imitation is sufficiant to lead him to the trap.
 I propose a simple C program http://www.comtv.ru/~av95/linux/nullshell.c
 which can imitate normal UNIX shell at the first look.
 Make up all these "test", "guest", "admin", "user" and use nullshell as a login
shell for it.
 Your /etc/passwd should look like this:
  guest::405:99:dummy decoy:/home/guest:/bin/nullshell
  user::405:99:dummy decoy:/home/guest:/bin/nullshell
  test::405:99:dummy decoy:/home/guest:/bin/nullshell
  admin::405:99:dummy decoy:/home/guest:/bin/nullshell

 Configure your sshd to allow all of them log in.
 Also disabling port forwarding for these accounts may increase your security.
 Set to "guest" and "test" passwords "guest" and "test" respectively.

 Then... wait for tests and guests :)))
 When the first log occurred, it should be a test only, not a real intrusion.
 But your address is now written to bad guy's list.
 Probably someday he will _interactively_ come in,
 that would be an unauthorized access,
 possibly traceable by involved hosts admins' or ISPs.
 What to do after that, I don't know.  I am not a lawyer.

qq~~~~\ [ IP ]
/ /\   \        [ FAQ you ] at news:local.chainik rules at
\  /_/ /

Re: introduction to ssh worms (draft)

Quoted text here. Click to load it

I went looking for my pet peeve but this is worded very well. Thank you.
Gandalf  Parker

Re: introduction to ssh worms (draft)

Quoted text here. Click to load it

A very recent ssh worm (which looks for a large lists of accounts)
*does* try empty passwords, at least for "user" account :-P


Quoted text here. Click to load it

They successfully "logged" to my hosts from at least 4 different sites last 39
but these were only tests.
No actions were requested after successful login while guessing accounts,
no specific "third stage" logins were detected yet.
My guess is that, because intrusion process is not automated,
_they_ already have much more accounts than time to use its :)
I think we need more traps to observe the "third stage".

qq~~~~\ [ IP ]
/ /\   \        [ FAQ you ] at news:local.chainik rules at
\  /_/ /

Re: S: ssh worms FAQ

Quoted text here. Click to load it

Ahh... such as?

Anyone with half a brain completely locks out unused default accounts.
Sun's Security Toolkit (JASS) does this and there are couple of
automated Linux hardening tools that do the same.


P.S. cross-posting and then having multiple groups in your followup-to
is not only pointless, but bad netiquette. :)

Paul Day      Web: www.bur.st/~paul      GPG Key ID: 7FF655A8

Re: ssh worms FAQ

Innocenti Maresin wrote:
Quoted text here. Click to load it

Interesting. I've seen these access attempts in my logs but never thought
too much of it.

Out of curiosity, I downloaded the file mentioned in that article
(http://frauder.us/linux/ssh.tgz ). As soon as I did, my antivirus software
started complaining about "Linux.RST.B", "Hacktool.Slice" and

Does anyone know whether this worm is just trying default passwords or if it
is using an SSH server vulnerability? It can't be brute forcing because I
only see one or two access attempts per attack in my logs...

Re: ssh worms FAQ

On Thu, 16 Sep 2004 21:52:15 GMT, "Dale Richards"

Quoted text here. Click to load it

I don't _know_, but I've read that the attempts are directed at some
version of Linux that had well-known passwords on the "test" and
"guest" accounts.  However, the attacking software, maybe a different
one, also tries "root" occasionally.

In general, it seems to try each of those accounts a couple of times,
then buggers off in search of an easier victim.  I sorta figgered that
machines with SSH exposed were being logged, though.

I'd seen the attempts for several weeks; then, last week, something
tried to log in as "root" over 3,000 times on my exposed host.  I
expect that if I hadn't wandered into the room and seen the console,
he'd be trying still.  My LART to the responsible network went

Bottom line?  You can't count on this thing's being just a superficial
attack on a couple of accounts.  I'm no security expert, but I'd
suggest either moving SSH to a different port, or limiting the
networks who can even see your machine, or both.  I'm assuming you've
already limited the accounts with SSH priviledges, ensured strong
passwords, etc.  

Personally, I've changed my methods of allowing access.  Rather than
filtering out the known "bad guys" and allowing the rest of the world
to see my network, I'm blocking the world at the packet level, on all
ports, and only allowing access to specific ports from known entities.
This has the beneficial side effect of shortening my ipfilters
configuration file from 8,900 lines to 200.  This won't work for
everyone, of course, but it's worth considering for certain ports.


Re: S: ssh worms FAQ

Isn't portsentry a good thing against these?

Re: S: ssh worms FAQ

Quoted text here. Click to load it

Not really. The whole point of this worm is that it seems to be testing for
a couple of predictable user accounts; why don't you just be sure your sshd
is uptodate, remove these accounts or at least check they don't have a
password set, and let the scans pass you by, watching them happen in the
log-file with barely a raised eyebrow of interest?

The same static-firewall approach applies just as much when it's ssh and
user-guessing tactics as when it's any other port and attack method. No
point. Secure the services you supply, and otherwise leave them alone.

no se encuentra el sistema operativo        |piglet@stirfried.vegetable.org.uk
(seen mid-windows 98 installation)          |http://spodzone.org.uk/cesspit

Re: S: ssh worms FAQ

Quoted text here. Click to load it

Ah yes, I see. But anyway: Is there any script available, which totally
blocks any machine trying to log in as user test (e.g.)?

The discussion about this
(http://seclists.org/lists/fulldisclosure/2004/Jul/1243.html and
http://dev.gentoo.org/~krispykringle/sshnotes.txt ) suggests, that there is
more on this than only password guessing ...

Re: S: ssh worms FAQ

Quoted text here. Click to load it

Considering that ssh traffic (including the username) is encrypted, it
should be rather hard to filter ssh traffic by username anywhere other
than in sshd itself. (The other possible filtering point would be the
ssh client, but obviously you don't always have control over that.)

You'd need a script hook in the authentication process, which would
get triggered when someone attempts to log in using a certain (set of)
username(s). You'd probably want the login to be always refused at
that point. Offhand, I see three ways to do this:

- Patch sshd to add the possibility to call an external script at the
  appropriate point.
- If you're using PAM, see if there's a PAM module which would be suitable.
  If not, build your own.
- Create a script that parses the syslog messages generated by sshd
  and checks the usernames and source IP addresses. (This will give
  slower reaction times than the other methods.)

Regardless of the method you choose, this kind of auto-blocking
may actually open new DoS opportunities: consider what happens if
the login attempt _seems_ to be coming from, say, your DNS server? Or
your main database server? Or your default gateway?


Re: S: ssh worms FAQ

Quoted text here. Click to load it

As has already been pointed out in this thread, OpenSSH supports
AllowUsers & AllowGroups.  Why on earth would you do any of the above

  Richard Silverman

Re: S: ssh worms FAQ

Quoted text here. Click to load it

I guess the original poster wanted to automate the complete and utter
blocking of networks that originate these ssh attacks.

Atro Tossavainen (Mr.)               / The Institute of Biotechnology at
Systems Analyst, Techno-Amish &     / the University of Helsinki, Finland,
+358-9-19158939  UNIX Dinosaur     / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

Re: S: ssh worms FAQ

On Fri, 17 Sep 2004 11:43:42 +0000, Stephan Goeldi wrote:

Quoted text here. Click to load it
What would be nice is a script that checks the logs and through IPTABLES
blocks multiple login attempts by the same IP.
Anyone know of such a script?


Re: S: ssh worms FAQ

On Fri, 08 Oct 2004 21:48:24 -0400, microcheap wrote:

Quoted text here. Click to load it
Try psad. Not a script but checks your logs and optionally (but not
recommended by psad) blocks the offender.

http://www.cipherdyne.com/psad /


Re: S: ssh worms FAQ

On Sat, 09 Oct 2004 10:53:29 +0200, Jos wrote:

Quoted text here. Click to load it
Thanks. I will give it a try.

Re: S: ssh worms FAQ

Quoted text here. Click to load it

Thank you. Why isn't it recommended?

Site Timeline