Re: Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)

[Henrique de Moraes Holschuh]

On Mon, 13 Jul 2009, Maik Holtkamp wrote:
> I decided to follow this and on the weekend iptables blocked about 70
> IPs. I am afraid that after some time the box will be DOSed by the
> crowded INPUT chain.

The only _real_ fix for that is to use IPSET (patch for netfilter) to deal
with IPv4, and config portsentry to run a script that just adds IPs to the
proper set you used to block stuff.  You can even add them with a builtin
"expire" time, so that they get unblocked three days after they were
inserted, or whatever...

I really wish IPSET was merged upstream, but it must be lacking something
fundamental to earn that right (IPv6 support, perhaps?), since it has been
around for a long time now, and it is fully maintained.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Marcin Gomulkiewicz]

Roger Bumgarner wrote:

ALLOW rules and SSH-keys. Using a non-standard port will stop the
majority of automated attackers, but a dedicated attack will find
you're SSH server: it only takes 20-30mins to portscan 1-65535.


Not necessarily:

http://jengelh.medozas.de/documents/Chaostables.pdf

I've included something like:

iptables -N deceive
iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT 
--reject-with icmp-proto-unreachable
iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT 
--reject-with icmp-net-prohibited
iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT 
--reject-with icmp-host-prohibited
iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT 
--reject-with icmp-port-unreachable
iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT 
--reject-with icmp-host-unreachable
iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT 
--reject-with icmp-net-unreachable
iptables -A deceive -p tcp -m statistic --mode random --probability 0.003 -j 
REJECT --reject-with tcp-reset
iptables -A deceive -j DROP

then some ALLOW rules:

...

iptables -A INPUT -p tcp --dport $SSH_PORT -m hashlimit --hashlimit-name sshlimit --hashlimit-mode srcip --hashlimit-upto 25/minute 
--hashlimit-burst 25 --hashlimit-htable-expire 12 -j ACCEPT


and then:

iptables -A INPUT -j deceive

That causes full portscan w/ nmap to take a week or so.

Apart from that I use portsentry and fail2ban.

Rgds,

Marcin


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)

[Maik Holtkamp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Maik Holtkamp wrote/schrieb @ 13.07.2009 11:12:


> tail -n -20 | sed "s/^-A/-D/" | \

s/tail/head/

Sorry.

- --
- - bye maik
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Signature of Maik Holtkamp

iEYEARECAAYFAkpbA7wACgkQz3bq6aadmI9geQCbBsEOUXW1Gv7TqnFJjaB/f9nA
O3kAnj958UiIghGGg2ZbJDyGHmPCGGkK
=ULYK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)

[Maik Holtkamp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Clemens Pfaffinger wrote/schrieb @ 07.07.2009 23:23:

> this is standard for me. I always change the port of the openSSH-server.
> 
> My (current) solution is:
> Portsentry listens on port 22, while openSSH-server has another port.
> Every port scan attempt will result in a ban via iptables and every
> connection to port 22 will also result in a ban via iptables.

I decided to follow this and on the weekend iptables blocked about 70
IPs. I am afraid that after some time the box will be DOSed by the
crowded INPUT chain.

As I didn't find any mechanism in Lenny's portsentry package to
automatically de-block the IPs I would try following cron script:

- ---cut---
#!/bin/bash

/sbin/iptables-save | grep "^-A INPUT" | \
tail -n -20 | sed "s/^-A/-D/" | \
while read line; do
iptables $line;
done

/etc/init.d/portsentry restart
- ---cut---

Which will keep the last 20 entries and skip everything else before
restarting portsentry.

However, I would greatly prefer a "straight forward Debain way" to
smoothly delete the portsentry rules. Any ideas?

TIA

- --
bye maik
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Signature of Maik Holtkamp

iEYEARECAAYFAkpa+okACgkQz3bq6aadmI/PIQCeIm1E8e7jMoUGfxOq63///ERP
9ZYAn1bWCL6y91Y19ITvqiwZXPV9nkoU
=V2tw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:

> hmmm, although i have set supported enctypes
>   supported_enctypes = aes256-cts:normal
> and restarted kdc nothing seens to have changed.
>
> After calling "kinit" klist -5e show me:
> Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc
> mode with HMAC/sha1

It sounds like removing something from supported_enctypes in the KDC may
not turn things off to quite the degree that I thought it would and if
only old keys are available, old keys are still used.

You'll need to change your krbtgt key in order to get newer enctypes for
your ticket-granting tickets.  You'll want to use -keepold unless you
can afford a flag day that invalidates all existing ticket caches.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Fri Jul 10 2009 19:24:52 GMT+0200 (CEST):
> Peter Jordan  writes:
>> Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST):
> 
> 
>> But for new installations a change is not a bad idea?
> 
> Yeah, for new installations it's generally best to start the master key
> at the strongest supported key type.  MIT 1.7 supports rekeying, though,
> which makes things much simpler.
> 
> 
>> How can i see that the change has worked?
> 
> klist -e will show you the enctypes of the tickets in your cache.  You
> can also check the enctypes of the tickets issued by the KDC in the KDC
> logs, although those are numeric and a bit less easy to understand.
> 

hmmm, although i have set supported enctypes
supported_enctypes = aes256-cts:normal
and restarted kdc nothing seens to have changed.

After calling "kinit" klist -5e show me:
Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc
mode with HMAC/sha1

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:
> Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST):

>> Yes.  The master key isn't used on the network and changing it is
>> very difficult in lenny.

> But for new installations a change is not a bad idea?

Yeah, for new installations it's generally best to start the master key
at the strongest supported key type.  MIT 1.7 supports rekeying, though,
which makes things much simpler.

>> Correct.  Clients will negotiate the strongest available encryption key
>> automatically.

> How can i see that the change has worked?

klist -e will show you the enctypes of the tickets in your cache.  You
can also check the enctypes of the tickets issued by the KDC in the KDC
logs, although those are numeric and a bit less easy to understand.

> It seems to work without renewing old keys (host/nfs). How can i see
> which enctypes the keys have.

kadmin examine on those principals.

> btw. if i list the principal for me in kadmin.local there are no
> values for Last successful authentication / Last failed authentication
> and ailed password attempts although the EQUIRES_PRE_AUTH Attribute is
> set:

Those fields aren't actually maintained in the database.  (There is code
to do so, but it's ifdefed out and has serious problems.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST):
> Peter Jordan  writes:
> 
>> Let the option
>>  master_key_type = des3-hmac-sha1
>> as it is?
> 
> Yes.  The master key isn't used on the network and changing it is very
> difficult in lenny.

But for new installations a change is not a bad idea?

> 
>> No change in /etc/krb5.conf required?
> 
> Correct.  Clients will negotiate the strongest available encryption key
> automatically.

How can i see that the change has worked?

> 
>> should i renew all host keys?
> 
> Ideally, yes, since that will get them on AES only.  If you have any
> existing keys that don't have AES keys, you do need to list fallback
> enctypes as supported until you've rekeyed them or you won't be able to
> authenticate to them.
> 

It seems to work without renewing old keys (host/nfs). How can i see
which enctypes the keys have.

btw. if i list the principal for me in kadmin.local there are no values
for Last successful authentication / Last failed authentication and
ailed password attempts although the  EQUIRES_PRE_AUTH Attribute is set:

get_principal peter
Principal: pe...@example.com
[...]
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

Do you know what is wrong?

thank you very much!

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Bastian Blank]

On Fri, Jul 10, 2009 at 07:31:33AM -0700, Russ Allbery wrote:
> Peter Jordan  writes:
> > We use NFSv4.
> I think the current version may have that same problem.

Urgs, yes.

Bastian

-- 
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

"Boyd Stephen Smith Jr."  writes:
> Russ Allbery wrote:

>> But yes, you don't want to get Kerberos tickets on an insecure system.

> I thought tickets only lasted for a small period of time, and could be
> expired early if need be so that you could use them on insecure
> machines.

True, you can get limited-lifetime tickets, which is a bit safer since
any attacker would have to use them right away.  If you can get them
without exposing your key material (using PKINIT, for instance), that
could be a possible solution.

You obviously don't want to get password-based tickets from an untrusted
machine.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Boyd Stephen Smith Jr.]

In <87ws6gppyi@windlord.stanford.edu>, Russ Allbery wrote:
>Peter Jordan  writes:
>> Russ Allbery, Fri Jul 10 2009 00:56:57 GMT+0200 (CEST):
>>> Not without applying custom patches that are rather a hack.  You can,
>>> however, do PKINIT, which lets you use smart cards that can do X.509
>>> authentication (some of which are quite inexpensive these days).
>>> We're evaluating the DESfire cards for our purposes.
>>
>> hmmm, that does not solve the problem, when i have to login from a
>> insecure computer (ie Internet cafe) . I know, you have not connect to
>> your network from insecure computers, but sometimes you have not the
>> choice.
>
>But yes, you don't want to get Kerberos tickets on an insecure system.

I thought tickets only lasted for a small period of time, and could be 
expired early if need be so that you could use them on insecure machines.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/



signature.asc
Description: This is a digitally signed message part.

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:
> Russ Allbery, Fri Jul 10 2009 00:56:57 GMT+0200 (CEST):

>> Not without applying custom patches that are rather a hack.  You can,
>> however, do PKINIT, which lets you use smart cards that can do X.509
>> authentication (some of which are quite inexpensive these days).
>> We're evaluating the DESfire cards for our purposes.

> hmmm, that does not solve the problem, when i have to login from a
> insecure computer (ie Internet cafe) . I know, you have not connect to
> your network from insecure computers, but sometimes you have not the
> choice.

Yeah, you're right -- that's a very hard one.  Even ssh public key isn't
horribly attractive in that situation.  You're basically betting that
whoever has hacked that cafe system has only installed a keyboard logger
and hasn't bothered to do something that would let them grab your ssh
private key as well.

But yes, you don't want to get Kerberos tickets on an insecure system.

As portable systems (handhelds, laptops, etc.) and ubiquitous wireless
becomes more common, hopefully there will be less need to use computers
that you don't physically control.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:
> Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST):

>> However, if you also have AFS, which I recall that you do, you can't
>> turn it off at that level.  You have to leave DES as a supported
>> enctype since the AFS service key at present still has to be DES
>> (although we're working on that).  In that case, you have to deal
>> with it at creation time for each principal.  In other words, when
>> you do addprinc or ktadd for everything other than the AFS service
>> key, pass the -e "aes256-cts:normal" option to the command to force
>> the enctypes to be restricted to 256-bit AES.

> We use NFSv4.

I think the current version may have that same problem.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:

> Let the option
>   master_key_type = des3-hmac-sha1
> as it is?

Yes.  The master key isn't used on the network and changing it is very
difficult in lenny.

> No change in /etc/krb5.conf required?

Correct.  Clients will negotiate the strongest available encryption key
automatically.

> should i renew all host keys?

Ideally, yes, since that will get them on AES only.  If you have any
existing keys that don't have AES keys, you do need to list fallback
enctypes as supported until you've rekeyed them or you won't be able to
authenticate to them.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Fri Jul 10 2009 00:56:57 GMT+0200 (CEST):
> Peter Jordan  writes:
> 
>> btw is it possible to use any kind of one time password mechanism with
>> mit kdc?
> 
> Not without applying custom patches that are rather a hack.  You can,
> however, do PKINIT, which lets you use smart cards that can do X.509
> authentication (some of which are quite inexpensive these days).  We're
> evaluating the DESfire cards for our purposes.
> 

hmmm, that does not solve the problem, when i have to login from a
insecure computer (ie Internet cafe) . I know, you have not connect to
your network from insecure computers, but sometimes you have not the choice.

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST):
> Peter Jordan  writes:
>> Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
> 
> 
> 
> However, if you also have AFS, which I recall that you do, you can't
> turn it off at that level.  You have to leave DES as a supported enctype
> since the AFS service key at present still has to be DES (although we're
> working on that).  In that case, you have to deal with it at creation
> time for each principal.  In other words, when you do addprinc or ktadd
> for everything other than the AFS service key, pass the -e
> "aes256-cts:normal" option to the command to force the enctypes to be
> restricted to 256-bit AES.
> 


We use NFSv4.

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST):
> Peter Jordan  writes:
>> Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
> 
>>> Ensuring that you use AES enctypes for all keys (disable DES and
>>> ideally also 3DES)
> 
>> How?
> 
> In /etc/krb5kdc/kdc.conf, set the supported_enctypes configuration
> option for your realm to:
> 
> supported_enctypes = aes256-cts:normal
> 
> Note that you'll also need to enable rc4-hmac:normal if you need to do
> cross-realm trust with Active Directory, and you'll need to enable
> des3-hmac-sha1:normal if you have any Java 1.4 clients.
> 
> However, if you also have AFS, which I recall that you do, you can't
> turn it off at that level.  You have to leave DES as a supported enctype
> since the AFS service key at present still has to be DES (although we're
> working on that).  In that case, you have to deal with it at creation
> time for each principal.  In other words, when you do addprinc or ktadd
> for everything other than the AFS service key, pass the -e
> "aes256-cts:normal" option to the command to force the enctypes to be
> restricted to 256-bit AES.
> 


Let the option
master_key_type = des3-hmac-sha1
as it is?

No change in /etc/krb5.conf required?

should i renew all host keys?

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:

> btw is it possible to use any kind of one time password mechanism with
> mit kdc?

Not without applying custom patches that are rather a hack.  You can,
however, do PKINIT, which lets you use smart cards that can do X.509
authentication (some of which are quite inexpensive these days).  We're
evaluating the DESfire cards for our purposes.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:
> Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):

>> Ensuring that you use AES enctypes for all keys (disable DES and
>> ideally also 3DES)

> How?

In /etc/krb5kdc/kdc.conf, set the supported_enctypes configuration
option for your realm to:

supported_enctypes = aes256-cts:normal

Note that you'll also need to enable rc4-hmac:normal if you need to do
cross-realm trust with Active Directory, and you'll need to enable
des3-hmac-sha1:normal if you have any Java 1.4 clients.

However, if you also have AFS, which I recall that you do, you can't
turn it off at that level.  You have to leave DES as a supported enctype
since the AFS service key at present still has to be DES (although we're
working on that).  In that case, you have to deal with it at creation
time for each principal.  In other words, when you do addprinc or ktadd
for everything other than the AFS service key, pass the -e
"aes256-cts:normal" option to the command to force the enctypes to be
restricted to 256-bit AES.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
> Peter Jordan  writes:
> 
>> It would be a stand alone MIT KDC (with krb-rsh) on debian lenny.
>>
>> "safe" in the sense of "you better attack the services which depends on
>> kerberos than kerberos itself"
> 
> That's what we've done at Stanford for many, many years, and I'm
> comfortable doing so.  The Debian MIT Kerberos maintainers (of which I'm
> one) receive advance notice of upcoming security vulnerability
> announcements and always prepare security updates in advance for any KDC
> vulnerabilities.
> 

btw is it possible to use any kind of one time password mechanism with
mit kdc?

thanks,

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
> 
> Ensuring that you use AES enctypes for all keys (disable DES and ideally
> also 3DES) 
> 

How?


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:

> It would be a stand alone MIT KDC (with krb-rsh) on debian lenny.
>
> "safe" in the sense of "you better attack the services which depends on
> kerberos than kerberos itself"

That's what we've done at Stanford for many, many years, and I'm
comfortable doing so.  The Debian MIT Kerberos maintainers (of which I'm
one) receive advance notice of upcoming security vulnerability
announcements and always prepare security updates in advance for any KDC
vulnerabilities.

The one additional vulnerability that you do open is brute-force attacks
on weak keys, which generally means password-based keys since the
randomly-generated service keys are generally too strong to bother with.
Ensuring that you use AES enctypes for all keys (disable DES and ideally
also 3DES) and that your users have to pick strong passwords should
eliminate most of that concern.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

pod  writes:

> For example there seems to be a school of thought amongst certain
> deployers of Active Directory (a component of which is a kerberos KDC)
> that it should not be exposed more widely than strictly necessary.
> There are however plenty of deployments of Heimdal and MIT KDCs that
> are exposed to the world and, incidentally, derive much advantage by
> so doing.

In my experience, common practice in the Active Directory world is to
start by using VPN before doing anything else, which of course also
works (although I find it more annoying and difficult to use than just
using ssh with an externally exposed Kerberos server).

Certainly, anything you expose to the world can be attacked.  If you
allow anyone to hit your Kerberos server, your Kerberos server can be
attacked.  If you allow anyone to hit your ssh servers with public key
authentication enabled, the public key authentication can be attacked.

Both ssh and Kerberos KDCs are treated with special care and concern for
security issues and generally have a very fast turn-around time for
fixes and updates.

I personally am comfortable exposing UNIX-based Kerberos KDCs to the
Internet.  I have no expertise with running Active Directory and cannot
comment there.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

pod, Thu Jul 09 2009 21:38:31 GMT+0200 (CEST):
> Peter Jordan  writes:
> 
>> It is not my decission to isolate kerberos.
>>
>> Is it safe to open kerberos for the world?
> 
> It's not clear that anyone on this list can answer that question since it
> depends on what "safe" and "kerberos" mean in the context of your
> organization.  The meaning of "safe" is defined by the organizational
> security policy and the meaning of "kerberos" will depend on which
> implementation has been used.
> 
> For example there seems to be a school of thought amongst certain
> deployers of Active Directory (a component of which is a kerberos KDC)
> that it should not be exposed more widely than strictly necessary.  There
> are however plenty of deployments of Heimdal and MIT KDCs that are exposed
> to the world and, incidentally, derive much advantage by so doing.
> 
> 

It would be a stand alone MIT KDC (with krb-rsh) on debian lenny.

"safe" in the sense of "you better attack the services which depends on
kerberos than kerberos itself"

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[pod]

Peter Jordan  writes:

> It is not my decission to isolate kerberos.
>
> Is it safe to open kerberos for the world?

It's not clear that anyone on this list can answer that question since it
depends on what "safe" and "kerberos" mean in the context of your
organization.  The meaning of "safe" is defined by the organizational
security policy and the meaning of "kerberos" will depend on which
implementation has been used.

For example there seems to be a school of thought amongst certain
deployers of Active Directory (a component of which is a kerberos KDC)
that it should not be exposed more widely than strictly necessary.  There
are however plenty of deployments of Heimdal and MIT KDCs that are exposed
to the world and, incidentally, derive much advantage by so doing.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Thu Jul 09 2009 20:45:57 GMT+0200 (CEST):
> Peter Jordan  writes:
> 
>> I want to login passwordless to my ssh server from the internet. vpn
>> is not avaiable and kerberos is not acccessable from outside the
>> lan. How?
> 
> Fix the last problem.  Otherwise, yes, you can't use Kerberos.
> 
> Authentication systems really need to be exposed to all sites from which
> one wishes to authenticate or they're not horribly helpful.
> 

It is not my decission to isolate kerberos.

Is it safe to open kerberos for the world?

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:

> I want to login passwordless to my ssh server from the internet. vpn
> is not avaiable and kerberos is not acccessable from outside the
> lan. How?

Fix the last problem.  Otherwise, yes, you can't use Kerberos.

Authentication systems really need to be exposed to all sites from which
one wishes to authenticate or they're not horribly helpful.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Noah Meyerhans, Thu Jul 09 2009 18:04:54 GMT+0200 (CEST):
> On Thu, Jul 09, 2009 at 06:02:37PM +0200, Peter Jordan wrote:
>> And how to login passwordless from outside the kerberos network?
> 
> There's no such thing as "outside the kerberos network".
> 
> noah
> 

I want to login passwordless to my ssh server from the internet. vpn is
not avaiable and kerberos is not acccessable from outside the lan. How?

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Matt Richardson]

The ISC has another diary entry on the exploit, voicing doubts about
it [1].  The original diary entry [2] doesn't have any more updates on
it, which is kind of a shame as that was where I was originally
tracking the story.  Anyway, there it is and I'm sure we'll hear more
about it.

[1] http://isc.sans.org/diary.html?storyid=6760
[2] http://isc.sans.org/diary.html?storyid=6742

-- 
Matt


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Noah Meyerhans]

On Thu, Jul 09, 2009 at 06:02:37PM +0200, Peter Jordan wrote:
> > If you have Kerberos, why would you use ssh keys?  GSS-API is so much
> > nicer if you already have a Kerberos environment.
> 
> And how to login passwordless from outside the kerberos network?

There's no such thing as "outside the kerberos network".

noah



signature.asc
Description: Digital signature

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Russ Allbery, Thu Jul 09 2009 17:04:06 GMT+0200 (CEST):
> Peter Jordan  writes:
>> Noah Meyerhans, Wed Jul 08 2009 23:13:30 GMT+0200 (CEST):
> 
> 
>> Do you use kerberos/nfsv4 and ssh keys? If yes, how you handle the
>> problem, that the authorized_keys file is not accessable without a krb
>> ticket?
> 
> If you have Kerberos, why would you use ssh keys?  GSS-API is so much
> nicer if you already have a Kerberos environment.
> 

And how to login passwordless from outside the kerberos network?

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Russ Allbery]

Peter Jordan  writes:
> Noah Meyerhans, Wed Jul 08 2009 23:13:30 GMT+0200 (CEST):

>> (Plus we've got Kerberos and don't usually mess around with keys or
>> passwords).

> Do you use kerberos/nfsv4 and ssh keys? If yes, how you handle the
> problem, that the authorized_keys file is not accessable without a krb
> ticket?

If you have Kerberos, why would you use ssh keys?  GSS-API is so much
nicer if you already have a Kerberos environment.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Guntram Trebs]

Bernd Eckenfels schrieb:

In article  you 
wrote:
  
Besides I dont think you can force both, its only one stage in ssh protocol.

But your login shell could ask for the password via Terminal. Maybe with pam..

  
I think, you can, when you are hacking the source code of the server, 
but i'm not into the source code ...


If you try to connect with an invalid key, the server can fall back to 
password authentication. This works transparently on the clients i use.

So you possibly can change the code of the server in this way:
- remember if there was a valid authentication by key, but deny it
- if there is a valid password authentication, only accept it, when you 
remembered a valid key auth


I would not suggest this. It is confusing for the user. And in my 
opinion, there are better solutions:

- let the server listen on another port
- use fail2ban
- put a fail2ban minefield around the other port
- drop invalid packets
- use port knocking

Yes, there are pros and cons.

I dont know a good port knocking server. The ones i testet had static 
keys, what you don't want.
Better would be dynamic keys, maybe with first a knocking sequence by 
time and later by password with answers on port knock daemon.


You could distribute working portknocking clients to your customers.
If you have windows customers, you can distribute putty-configurations 
as reg-files.
Possibly this works with winscp to. At least you can take over 
putty-configs to winscp in a rather hidden menu-button on the very first 
startwindow.

http://en.wikipedia.org/wiki/Port_knocking

As an alternative to port knocking, you could use web based knocking, 
which is more difficult to set up.


With knocking in general you lock the syn-packages on your ssh-port and 
unlock it for a certain time, after receiving a valid knock-sequence an 
another port-range.


However you set up. Keep one important thing in mind:
Try to manage your system in a way, that if an atacker cracked the 
access of one customer, he can't affect changes on other customers.

That is not an easy task on ordinary web servers.

You always have customers, that are not sensible to security. And even 
if your customers are smart, but have in spite of a cracked system, the 
malware could record both there passwords and the passphrase of the 
encrypted private key ...


If the malware was smart, it coul even get between you and the terminal 
window, install it's own public key on the server and try to hide this 
action from your cutomers  by clearing the screen and closing the 
connection. So just keep insecure customers from having influence on 
your system or other customers.


Greeting,
Guntram

--
Guntram Trebs
freier Programmierer und Administrator

g...@trebs.net
+49 (30) 42 80 61 55
+49 (178) 686 77 55 




--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Justus, Tue Jul 07 2009 22:36:31 GMT+0200 (CEST):
> Is there Information on what Versions are affected by this exploit?
> I read something of Version 3.2 and 4.3 in one of the blog entrys
> (http://secer.org/hacktools/0day-openssh-remote-exploit.html), maybe
> someone else could clarify this?
> Would you recommend stopping ssh completely and switching to remote control?
> Regards,
> Justus
> 
> 

I recompiled openssh lenny version for etch without problems. Are there
any reasons against installing this version in etch?

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Sebastian Posner, Wed Jul 08 2009 23:18:43 GMT+0200 (CEST):
> Jim Popovitch wrote:
> 
>> Is there a way to force keys AND passwd verification?
> 
> Normally you'd want to DISABLE PasswordAuthentication and 
> ChallengeResponseAuthentication - unless you have a special and 
> well-maintained setup like e.g. One-Time-Pads or such - because both can 
> potentially be brute-forced way faster than SSH-keys.

Why not using PasswordAuthentication and/or
ChallangeResponseAuthetication like opie/otpw/freeauth? I think its
better then passwordless ssh keys and strong passwords and fail2ban
should help against brute-force.

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Peter Jordan]

Noah Meyerhans, Wed Jul 08 2009 23:13:30 GMT+0200 (CEST):
> (Plus we've got Kerberos and don't usually mess around with keys or
> passwords).
> 

Do you use kerberos/nfsv4 and ssh keys? If yes, how you handle the
problem, that the authorized_keys file is not accessable without a krb
ticket?

PJ


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Bernd Eckenfels]

In article  you 
wrote:
> Is there a way to force keys AND passwd verification?

You know that if its a protocol exploit (which is quite likely) that will
not help you much.  tcpwrapper itself or ipfilter acts quite early in the
protocol stack - that might help.

Besides I dont think you can force both, its only one stage in ssh protocol.
But your login shell could ask for the password via Terminal. Maybe with pam..

Greetings
Bernd


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Sebastian Posner]

Michael Stone wrote:

[A way to enforce non-empty passwd on ssh-keys]

> You can't, which is why it is useful to have both passwords and keys 
> simultaneously--you can enforce a policy on a password.

To cite Noah Meyerhans from his recent mail - my users would shoot me if I ever 
tried such a thing.
Sadly, I'm not their bossbut they are more or less my customers, so putting a 
security policy in place requiring the previously stated mechanism would be 
more like starting a war than a small skirmish.

Sebastian
-- 
baboo
-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Michael Stone]

On Wed, Jul 08, 2009 at 11:18:43PM +0200, Sebastian Posner wrote:

Jim Popovitch wrote:

Is there a way to force keys AND passwd verification?


Normally you'd want to DISABLE PasswordAuthentication and 
ChallengeResponseAuthentication

...
Something that would indeed be interesting is a way to enforce that the 
PRIVATE KEY is password-protected - sadly, you can't see this from the 
public key, and I'm not aware of any possibility to query the client 
concerning this specific matter.


You can't, which is why it is useful to have both passwords and keys 
simultaneously--you can enforce a policy on a password.


Mike Stone


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Noah Meyerhans]

On Wed, Jul 08, 2009 at 02:03:57PM -0700, Roger Bumgarner wrote:
> As far as I know, it does keys first then falls back to passwords. I'd
> imagine PAM could help, but I'm not knowledgeable enough in regards to
> that. I know you're only limited by your imagination when it comes to
> PAM authentication. SSH-keys can (and should!) be password-protected
> already.

One of the big problems with ssh keys, though, is that there's no way
for an admin to force a user's key to be password protected.  On
occasion, when there are other restrictions in place, passwordless keys
are a good thing and can be used safely, but when used to access a
user's account, they're always bad.

Also, since ssh public key auth isn't handled by PAM, I don't believe
there's a way to use PAM to require both keys and passwords.  I could be
wrong, though.  My users would shoot me if I ever tried such a thing.
(Plus we've got Kerberos and don't usually mess around with keys or
passwords).

Not that any of this will help if this alleged sshd vulnerability can be
triggered prior to authentication.

noah



signature.asc
Description: Digital signature

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Sebastian Posner]

Jim Popovitch wrote:

> > ALLOW rules and SSH-keys.
> 
> Is there a way to force keys AND passwd verification?

Normally you'd want to DISABLE PasswordAuthentication and 
ChallengeResponseAuthentication - unless you have a special and well-maintained 
setup like e.g. One-Time-Pads or such - because both can potentially be 
brute-forced way faster than SSH-keys..unless you happen to use a key generated 
with one of those "funny" buggy random-sources from the past, in which case a 
well-maintained sshd nowadays will simply reject your key.

Something that would indeed be interesting is a way to enforce that the PRIVATE 
KEY is password-protected - sadly, you can't see this from the public key, and 
I'm not aware of any possibility to query the client concerning this specific 
matter.

Sebastian
-- 
baboo
-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Roger Bumgarner]

As far as I know, it does keys first then falls back to passwords. I'd
imagine PAM could help, but I'm not knowledgeable enough in regards to
that. I know you're only limited by your imagination when it comes to
PAM authentication. SSH-keys can (and should!) be password-protected
already.

-rb

On Wed, Jul 8, 2009 at 9:37 AM, Jim Popovitch wrote:
> On Wed, Jul 8, 2009 at 09:33, Roger Bumgarner 
> wrote:
>> ALLOW rules and SSH-keys.
>
> Is there a way to force keys AND passwd verification?
>
> -Jim P.
>
>
> --
> To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Jameson Rollins]

On Wed, Jul 08, 2009 at 09:37:55AM -0700, Jim Popovitch wrote:
> On Wed, Jul 8, 2009 at 09:33, Roger Bumgarner 
> wrote:
> > ALLOW rules and SSH-keys.
> 
> Is there a way to force keys AND passwd verification?

That's actually a really good question.  I would be interested in
knowing how to do that.

jamie.


signature.asc
Description: Digital signature

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Jim Popovitch]

On Wed, Jul 8, 2009 at 09:33, Roger Bumgarner wrote:
> ALLOW rules and SSH-keys.

Is there a way to force keys AND passwd verification?

-Jim P.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Roger Bumgarner]

ALLOW rules and SSH-keys. Using a non-standard port will stop the
majority of automated attackers, but a dedicated attack will find
you're SSH server: it only takes 20-30mins to portscan 1-65535.

-rb


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Rafael Moraes]

just update it!


2009/7/8 Leandro Minatel 

>
>
> On Wed, Jul 8, 2009 at 11:38 AM, Norbert Preining wrote:
>
>> On Mi, 08 Jul 2009, Leandro Minatel wrote:
>> > Right you are!, but, don't forget that there are more than 65500 ports
>> to
>>
>> ??? Are you talking about trying the exploit on every single port? Then
>> they would really be stupid. Calling nmap makes that much faster.
>>
>> No the code must be fixed if there is a hole, nothing else helps but
>> turing off ssh.
>>
>> Best wishes
>>
>> Norbert
>>
>>
>> ---
>> Dr. Norbert Preining Vienna University of
>> Technology
>> Debian Developer  Debian TeX
>> Group
>> gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5
>> B094
>>
>> ---
>> LUSBY (n.)
>> The fold of flesh pushing forward over the top of a bra which is too
>> small for the lady inside it.
>>--- Douglas Adams, The Meaning of Liff
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>>
>>
> No, of course not. Maybe I expressed myself  "not in a proper way", sorry,
> english is not my natural language. AFAIK, nmap, by default, scan ports from
> 1 to 1024 and those listed in nmap-services. This allows me to "hide"
> ssh-server for the majority of mortals.
>
> BTW, I agree with you, the code must be fixed, no doubt at all.
>
> Regards
> Leandro
>

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Leandro Minatel]

On Wed, Jul 8, 2009 at 11:38 AM, Norbert Preining  wrote:

> On Mi, 08 Jul 2009, Leandro Minatel wrote:
> > Right you are!, but, don't forget that there are more than 65500 ports to
>
> ??? Are you talking about trying the exploit on every single port? Then
> they would really be stupid. Calling nmap makes that much faster.
>
> No the code must be fixed if there is a hole, nothing else helps but
> turing off ssh.
>
> Best wishes
>
> Norbert
>
>
> ---
> Dr. Norbert Preining Vienna University of
> Technology
> Debian Developer  Debian TeX
> Group
> gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5
> B094
>
> ---
> LUSBY (n.)
> The fold of flesh pushing forward over the top of a bra which is too
> small for the lady inside it.
>--- Douglas Adams, The Meaning of Liff
>
>
> --
> To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>
No, of course not. Maybe I expressed myself  "not in a proper way", sorry,
english is not my natural language. AFAIK, nmap, by default, scan ports from
1 to 1024 and those listed in nmap-services. This allows me to "hide"
ssh-server for the majority of mortals.

BTW, I agree with you, the code must be fixed, no doubt at all.

Regards
Leandro

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Norbert Preining]

On Mi, 08 Jul 2009, Leandro Minatel wrote:
> Right you are!, but, don't forget that there are more than 65500 ports to

??? Are you talking about trying the exploit on every single port? Then
they would really be stupid. Calling nmap makes that much faster.

No the code must be fixed if there is a hole, nothing else helps but
turing off ssh.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
LUSBY (n.)
The fold of flesh pushing forward over the top of a bra which is too
small for the lady inside it.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Leandro Minatel]

On Tue, Jul 7, 2009 at 6:20 PM, Jeroen van Drongelen
 wrote:

> It's helpfull indeed but withe a portscan they can easly find the other
> port of openssh.If have shutdown the openssh service untill i know wich
> version is attackable by this exploit or when they have a solution for it.
>
>
> Regards,
> Jeroen
>
> 2009/7/7 Leandro Minatel 
>
>> Hi,
>>
>> a good practice, at least for me, is put openssh to listen in a different
>> port than the default. I know, it's not the perfect solution.
>>
>> Regards.
>>
>
>
Right you are!, but, don't forget that there are more than 65500 ports to
scan for ssh if it's not listening on the default one. I know, it's a matter
of time, but, almost the majority of "mortals" give up if SSH is not in 22.

Regards.

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Clemens Pfaffinger]

Hi,

this is standard for me. I always change the port of the openSSH-server.

My (current) solution is:
Portsentry listens on port 22, while openSSH-server has another port.
Every port scan attempt will result in a ban via iptables and every
connection to port 22 will also result in a ban via iptables.

Regards


Kontaktinformationen
clem...@csrv.at
www.cdev.at


2009/7/7 Clemens Pfaffinger 

> Hi,
>
> this is standard for me. I always change the port of the openSSH-server.
>
> My (current) solution is:
> Portsentry listens on port 22, while openSSH-server has another port.
> Every port scan attempt will result in a ban via iptables and every
> connection to port 22 will also result in a ban via iptables.
>
> Regards
> 
> Kontaktinformationen
> clem...@csrv.at
> www.cdev.at
>
>
> 2009/7/7 Leandro Minatel 
>
>> Hi,
>>
>> a good practice, at least for me, is put openssh to listen in a different
>> port than the default. I know, it's not the perfect solution.
>>
>> Regards.
>>
>
>

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Jeroen van Drongelen]

It's helpfull indeed but withe a portscan they can easly find the other port
of openssh.If have shutdown the openssh service untill i know wich version
is attackable by this exploit or when they have a solution for it.


Regards,
Jeroen

2009/7/7 Leandro Minatel 

> Hi,
>
> a good practice, at least for me, is put openssh to listen in a different
> port than the default. I know, it's not the perfect solution.
>
> Regards.
>

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Jeroen van Drongelen]

As i have read on this page :
http://secer.org/hacktools/0day-openssh-remote-exploit.htmlit
say's that the attack is againt OpenSSH version 4.3.

So the best thing that you can do is update OpenSSH to a newer version.

But again it are still rumors and i don't know if a version higher then 4.3
is also attackable by the exploit


2009/7/7 Ramunas / techsupport.lt 

> Hi all,
>
> This is a serious security threat if it is not some sort of a duck (as we
> call it in our country). I have firewalled some servers already.
>
> Do you think tcpwrapping ssh service is enough, or should i use iptables
> instead?
>
> Thanks in advance,
> Regards
>
> --
> Ramūnas Čereškevičius
>
> Tel.:  +370 600 48 371
> El.p.: ramu...@techsupport.lt
>
> * UNIX/Linux serveriai
> * Kompiuterių tinklai
> * Internetinių svetainių kūrimas
> * Konsultacijos
>
> www.techsupport.lt
>
>
>
> --
> To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Leandro Minatel]

Hi,

a good practice, at least for me, is put openssh to listen in a different
port than the default. I know, it's not the perfect solution.

Regards.

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Justus]

Is there Information on what Versions are affected by this exploit?
I read something of Version 3.2 and 4.3 in one of the blog entrys
(http://secer.org/hacktools/0day-openssh-remote-exploit.html), maybe
someone else could clarify this?
Would you recommend stopping ssh completely and switching to remote control?
Regards,
Justus


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Clemens Pfaffinger]

Hi,

thanks for this information!
I just hope that this is a hoax.
What would you suggest for securing a server running openSSH?
How can I notice such an attack in my log files?


Cheers


Kontaktinformationen
clem...@csrv.at
www.cdev.at


2009/7/7 Henrique de Moraes Holschuh 

> As usual, you may want to either raise shields (i.e. disable/restrict
> access
> to the ssh service), or pay extra attention to what is happening on your
> SSH
> inbound gateways...
>
> http://lwn.net/Articles/340360/
> http://isc.sans.org/diary.html?storyid=6742
> http://secer.org/hacktools/0day-openssh-remote-exploit.html
>
> Yes, it could be a hoax, and I sure hope that's all it is...
>
> --
>  "One disk to rule them all, One disk to find them. One disk to bring
>  them all and in the darkness grind them. In the Land of Redmond
>  where the shadows lie." -- The Silicon Valley Tarot
>  Henrique Holschuh
>
>
> --
> To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>

Re: HEAD's UP: possible 0day SSH exploit in the wild

[Ramunas / techsupport.lt]

Hi all,

This is a serious security threat if it is not some sort of a duck (as 
we call it in our country). I have firewalled some servers already.


Do you think tcpwrapping ssh service is enough, or should i use iptables 
instead?


Thanks in advance,
Regards

--
Ramūnas Čereškevičius

Tel.:  +370 600 48 371
El.p.: ramu...@techsupport.lt

* UNIX/Linux serveriai
* Kompiuterių tinklai
* Internetinių svetainių kūrimas
* Konsultacijos

www.techsupport.lt


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

HEAD's UP: possible 0day SSH exploit in the wild

[Henrique de Moraes Holschuh]

As usual, you may want to either raise shields (i.e. disable/restrict access
to the ssh service), or pay extra attention to what is happening on your SSH
inbound gateways...

http://lwn.net/Articles/340360/
http://isc.sans.org/diary.html?storyid=6742
http://secer.org/hacktools/0day-openssh-remote-exploit.html

Yes, it could be a hoax, and I sure hope that's all it is...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org