Re: Debian security being trashed in Linux Today comments

2002-01-14 Thread Daniel Polombo

Adam Warner wrote:

 On Tue, 2002-01-15 at 01:05, Tim Haynes wrote:

Some of us wouldn't dare say such things without at least reviewing the
given distro's security policy, FAQ and history.

 But I was really impressed that updates for unstable/testing were
 released at the same time. For those of us that use/test the bleeding
 edge on our systems it's a great reassurance to see the security team
 giving consideration to the security of testing/unstable.


Well, maybe you should follow Tim's advice and go check the security team's FAQ :

Q: How is security handled for testing and unstable?

A: The short answer is: it's not. Testing and unstable are rapidly moving
   targets and the security team does not have the resources needed to
   properly support those. If you want to have a secure (and stable)
   server you are strongly encouraged to stay with stable.

Of course, if you're using unstable, fixes tend to appear quickly, but :

- tend to is not acceptable when security is concerned
- it may take a lot more time depending on your local mirror

--
Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Don't panic (ssh)

2002-01-14 Thread Daniel Polombo

Iain Tatch wrote:


 
AFAIK, all SSH1 connections are vulnerable to the CRC32 attack. Thus you need
to use SSH2 protocol. OpenSSH supports SSH2. You need different keys though,
as SSH2 so far does not support RSA keypairs and needs DSA keys.  

 That's the impression I was under, too. In which case the current stable
 release of Debian comes with an sshd which uses protocol 1 and is
 therefore open to allowing remote root compromises.

Just a quick precision here : you have to _disable_ v1 in order to be 
protected from that vulnerability. The point here is not that you have to 
support v2, it's that you have to disallow v1. A recent daemon allowing ssh1 
connections is vulnerable.

--
Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Debian security being trashed in Linux Today comments

2002-01-14 Thread Daniel Polombo

Adam Warner wrote:


On Tue, 2002-01-15 at 01:05, Tim Haynes wrote:



Some of us wouldn't dare say such things without at least reviewing the
given distro's security policy, FAQ and history.



But I was really impressed that updates for unstable/testing were
released at the same time. For those of us that use/test the bleeding
edge on our systems it's a great reassurance to see the security team
giving consideration to the security of testing/unstable.



Well, maybe you should follow Tim's advice and go check the security team's FAQ 
:

   Q: How is security handled for testing and unstable?

   A: The short answer is: it's not. Testing and unstable are rapidly moving
  targets and the security team does not have the resources needed to
  properly support those. If you want to have a secure (and stable)
  server you are strongly encouraged to stay with stable.

Of course, if you're using unstable, fixes tend to appear quickly, but :

- tend to is not acceptable when security is concerned
- it may take a lot more time depending on your local mirror

--
Daniel



Re: Don't panic (ssh)

2002-01-14 Thread Daniel Polombo

Iain Tatch wrote:





AFAIK, all SSH1 connections are vulnerable to the CRC32 attack. Thus you need
to use SSH2 protocol. OpenSSH supports SSH2. You need different keys though,
as SSH2 so far does not support RSA keypairs and needs DSA keys.  


That's the impression I was under, too. In which case the current stable
release of Debian comes with an sshd which uses protocol 1 and is
therefore open to allowing remote root compromises.


Just a quick precision here : you have to _disable_ v1 in order to be 
protected from that vulnerability. The point here is not that you have to 
support v2, it's that you have to disallow v1. A recent daemon allowing ssh1 
connections is vulnerable.


--
Daniel



Re: Just a test sorry

2001-10-31 Thread Daniel Polombo

Hans wrote:



i did not get a massage for a while.



I'm very sorry to hear that. As a matter of fact, neither did I. But are you 
sure this is appropriate content for this list? :)


--
Daniel




Re: Port 6000/X11 Won't Close!

2001-08-10 Thread Daniel Polombo

vexation wrote:
 I use debian 2.2 (woody/unstable) with kernal 2.4.7, i use login.app to login
 to X.  I believe i have the --no-listen command set. However, no madder what i
 do port 6000 still remains open.  I really want to close this port for security
 reasons!  can someone please help me?! - Thank you!

Try running X -nolisten tcp.

HTH,

Daniel


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Port 6000/X11 Won't Close!

2001-08-10 Thread Daniel Polombo

vexation wrote:

I use debian 2.2 (woody/unstable) with kernal 2.4.7, i use login.app to login
to X.  I believe i have the --no-listen command set. However, no madder what i
do port 6000 still remains open.  I really want to close this port for security
reasons!  can someone please help me?! - Thank you!


Try running X -nolisten tcp.

HTH,

Daniel



Re: shared root account

2001-07-06 Thread Daniel Polombo

Just a friendly Jedi Knight wrote:

 On Fri, Jul 06, 2001 at 01:19:24PM +0300, Juha Jykk wrote:
 
  I distrust allowing root logins from anywhere but local console(s)
or non-modem gettys i.e. from anywhere over the not-owned-by-me cable.

  umm do You want to run in circles from one machine to another? ;o))
  if not than You need to remotely logon somehow, right?
  i think that ssh'ing into the machine and than than su'ing to root is no
  different than ssh'ing directly as root into that machine...
  (well when You do a su You leave a trace in logs of that fact, while You are
  directly ssh'ing into there is no info in logs on who actually logged on as
  root; there is some patch to at least partialy fix the latter and it was
  mentioned on debian-devel i think)


Disable every direct root login altogether (suppress root's password) 
and add anyone who needs root access to your /etc/sudoers file (if 
necessary, apt-get install sudo, of course). Need a root shell? sudo 
bash, and you're using only your own password ...



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]