Re: [cobalt-users] FIX - can't su to root, email stopped working,gui stopped working, postgres database is down, virtual sites disappeared

[Larry Smith <lesmith@xxxxxxxxx>]

INRE Re: [cobalt-users] FIX - can't su to root, email stopped working,gui 
stopped working, postgres database is down, virtual sites disappeared:
> "Jay Summers" <jay@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > Correct me if I'm wrong, but I don't think the SSH1 protocol is anymore
> > unsafe than SSH2 as long as it's the latest stable/secure release. I
> > don't really have any links to back up my claim but I believe that I read
> > this somewhere before. Maybe even this list...
>
> Don't believe everything you read.  <g>  That includes everything I say,
> though in this case my statements weren't unfounded.  Based on what I
> believe to be true, older versions of SSH are vulnerable and newer versions
> of SSH with Protocol 1 enabled are vulnerable.  In any case, even if the
> consensus was that newer versions of SSH were not vulnerable to an attack
> using Protocol 1, I would disable it because I realize that we're all
> really talking about *known* vulnerabilities.  And IMO, it's more likely a
> new vulnerability will be discovered in Protocol 1 than n Protocol 2 so
> I'll take my chances and run Protocol 2 exclusively and recommend that my
> clients use SSH client programs that support Protocol 2.  You might want to
> check out the following article or google for something like "ssh protocol
> 1 vulnerability" (without the quotes).
>
> http://www.stanford.edu/group/itss-ccs/security/news/ssh.html
>
> HTH,

Hmmm, while I _agree_ with everything said inre vulnerabilities and such, I 
believe the "KEY" point is addressed at the bottom of the article referenced:
<EXCERPT>
Note that the attacker needs to make a TCP connection from an IP address for 
which sshd will enter into a key-exchange dialogue. If the attacker's packets 
have a source IP address that is disallowed by (for example) DenyHosts in the 
sshd configuration file, the key exchange will not happen and the attacker 
will not have an opportunity to compose the required exploit data. 
</EXCERPT>

Bottom line being, why would anyone who _is_ security "aware" allow 
un-restricted access of _any_ type - telnet, ssh, or other to their 
box/system/server.  Most of the vulnerabilities in question over the last few 
months have "required" the ability to open a connection to the server - if 
this is "denied" by hosts.deny or server configuration, then "most" of these 
vulnerabilities cannot ever be executed......

Larry Smith
SysAd ECSIS.NET
sysad@xxxxxxxxx