| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Estou, considerando os últimos acontecimentos relacionados com o OpenSSH, a considerar implementações alternativas do SSH. As alternativas que conheço: - LSH, o ssh da GNU - Software Livre, mas estou um bocado inseguro quanto a este programa, já que foi descoberto um Remote Root Exploit há três dias.
- FreSSH - Licença BSD, ainda não implementa a versão 2.0 do protocolo, o que é uma grande falha.
- SSH Tectia Server, o SSH da ssh.com - Não é software livre, mas tem uma licença Non-commercial interessante (é open-source e permite ao utilizador criar bugfixes e implementar novas features), tem uma data de features e parece bastante sólido e seguro.
Que opiniões têm sobre estes programas? O que escolher, tendo em conta factores técnicos, políticos e comerciais? O que usar em casa, na universidade e na empresa? Cumps, João Ribeiro
--
sena@smux.net
http://smux.net/
|
| | | | | | Penso que não há qualquer versão do protocolo SSH que se aplique ao teu caso, volta ao telnet.
Esta política do "muda porque tem bugs" acontece devido ao excesso de opções no mercado... O OpenSSH continua a ser uma das melhores implementações do SSH, infelizmente tem bugs, mas isso não tem propriamente uma cura total.
Cada vez que tens um problema com o teu carro compras um novo ?
|
| | | | | Penso que não há qualquer versão do protocolo SSH que se aplique ao teu caso, volta ao telnet. É este o teu conselho? :/ Cada vez que tens um problema com o teu carro compras um novo? Esta é uma comparação completamente pertinente. :/ Ontem à noite, para experimentar, instalei o ssh da ssh.com. Ao fim de uns minutos já tinha uma instalação com as funcionalidades que tinha com o OpenSSH. Deu-me um bocado menos de trabalho do que comprar um carro novo... Cumps, João Ribeiro
--
sena@smux.net
http://smux.net/
|
| | | | e entao ?
qual e' a diferenca entre "eu instalei e vi e gostei ou nao "
a dizer
"porque deu isto ACHO que vou instalar porque e' melhor e nao sei mas UM DIA VOU experiementar etc etc"
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| | | | Ao fim de uns minutos já tinha uma instalação com as funcionalidades que tinha com o OpenSSH.
Quando surgiu o OpenSSH, muita gente começou a migrar e os principais motivos não foram a licença, mas o excesso de bugs da versão comercial... Onde quero chegar é que o problema com determinado software não é a existência de bugs, mas se os mesmos são resolvidos, de preferência com rapidez !
Se aparentemente a versão comercial tem menos bugs, isso é porque já não é tão usada como na "época pré-OpenSSH". Não se esqueçam que o OpenSSH tem uma equipa de programadores que se preocupam com a segurança em primeiro lugar... ou não seja o OpenBSD considerado o S.O. mais seguro...
|
| | | | Eu durante muito tempo usei o ssh da ssh.com em sistemas redhat e slackware. Desde que mudei primeiro para a debian e depois para gentoo que andava a usar o openssh, mas esta onda de buracos está a deixar-me algo preocupado.
Por essas e por outras voltei ao ssh do ssh.com, o problema é que em gentoo ainda não havia ebuild. Por isso deitei mãos a obra e aqui está ela.
Quem usar gentoo e quiser testar que por favor coloque lá os resultados.
Neste momento apenas estou a usar em uma máquina mas correu tudo bem.
Gustavo Felisberto
72ef1d7183eb2ea89420b94c0cf3e1f1
apt-get install anarchism |
| | | | Eu estou como tu.
Duante muito tempo usei o ssh.com, depois voltei para openssh, mas já começo a ter dúvidas...
Mário Gamito
my web shelter |
| | | | Homens de pouca fé. :)
O OpenSSH não tem tido mais bugs do que a maior parte do software, muito pelo contrário.
Simplesmente deu-se o azar de haver 3 correcções no espaço de uma semana, o que sem dúvida faz uma pessoa reparar...
... mas nenhuma delas é exploitable no default install. Esta do PAM, pelo que li, só afecta quem desligue o PrivSep, o que não vejo qualquer razão para fazer.
As 2 primeiras correcções não foram algo tipo "temos um buraco no OpenSSH! Há servidores por todo o mundo a ser hackados! Depressa, lancem um fix!". Foram, sim, os próprios autores a corrigir bugs proactivamente. Querem melhor?
Era bom que em todo o software os bugs fossem descobertos exclusivamente pelos autores do mesmo...
"It is every citizen's final duty to go into the tanks and become one with all the people."
- Chairman Sheng-ji Yang, "Ethics for Tomorrow" |
| | | | Estou sem o tempo necessário para te dar uma "boa resposta", pelo que vou ficar pela "posta de pescada não justificada". :-)
Na minha opinião o OpenSSH é a melhor opção. Já há uns anos que se posicionou como o servidor de ssh mais auditado do mercado.
Mais importante para se perceber a história de bugs do openssh é observar a natureza desses bugs... não só não são "triviais", como não são propriamente "your average, easy to exploit, buffer overflow". Claro que uma vez "criado" o exploit isso é relativamente igual ao litro, na mão do script kiddie, mas "até isso suceder" a história é muito diferente.
Há que perceber ainda o impacto que a separação de previlégios tem (separação essa que, da ultima vez que olhei para as alternativas, não estava implementada). Esse impacto é tão simples como ser totalmente irrelevante (bug eventual com impacto limitado) o buffer overflow em quase todos os segmentos de código (muito poucos correm como root até delegar previlégios)...
Não. O OpenSSH, vital como é, tem pregado umas partidas a todos os sysadmins...mas software é isto mesmo. E cada bug que se descobre é um "a menos", ficamos todos um bocadinho mais seguros do que estavamos. Sempre foi assim, sempre será, pelo menos enquanto novas funcionalidades forem sendo implementadas (e o código a auditar for um alvo em movimento).
Não é perfeito, mas é a melhor opção que conheço para o efeito desejado...
PLS
|
| | | | Pois, acho que estás certo.
E eu já fiz 3 ./configure && make && make install :-)
Mário Gamito
my web shelter |
| | | | | (separação essa que, da ultima vez que olhei para as alternativas, não estava implementada) Penso que o ssh da ssh.com implementa isto... Sep 24 10:12:34 [sshd2] User xxxxx, coming from localhost, authenticated.
Sep 24 10:12:34 [sshd2] Now running on xxxxx's privileges. Cumps, João Ribeiro
--
sena@smux.net
http://smux.net/
|
| | | | http://www.citi.umich.edu/u/provos/ssh/privsep.html
A diferença é entre delegar previlégios no passo final, quando passa o PTY, no caso do ssh.com (pelo menos há uns tempos atrás era assim, não sei como está hoje) e ser feita toda a negociação por um processo sem previlégios (com o parent a fazer o controle).
Todos os daemons deviam que necessitam de previlégios correr assim (i.e. com um processo sem previlégios E chrooted por trás a executar todo o código possível de correr em separado)...
PLS
|
| | | | O facto de ser o mais auditado não implica que seja o mais seguro, auditar código é uma tarefa bastante complexa, que exige conhecimentos muito acima da média, assim como investimentos a nivel de tempo.
Além disso a projecção do própio daemon é crucial, o wuftpd é muito mais auditado que o vsftpd, e no entanto isso não o torna mais seguro (mesmo nada).
Hoje em dia, e em daemons de primeira linha, praticamente nenhum bug é trivial, e além disso acho que ter segurança num sistema, não é so estar protejido contra "script kidies", mas sim também contra os denominados hackers.
Acho que contra factos não existem argumentos, e portanto o servidor de ssh comercial (www.ssh.com), é definitivamente o mais seguro até ao momento, o openssh para mim so tem a vantagem de ser grátis.
|
| | | | Ja saiu mais um buraco para o wu-ftpd ;)
|
| | | | Boas.
Complementando e agarrando numas palavras tuas de à uns thread's atrás, é missão/função do sysadmin estar atento aos novos bugs no software que corre nas máquinas que gere. Se o patch/nova_versão demora algumas horas a chegar, é obrigação do sysadmin pelo menos minimizar os possiveis danos, e ir monitorizando mais atentamente os logs.
Tudo o resto será *apenas* conversa...
@754, Nbk
|
| | | | O que usar em casa, na universidade e na empresa? O mesmo. Precisas do mesmo grau de seguranca em todos eles. estou... a considerar implementações alternativas do SSH. A unica razao para usar o protocolo SSHv1 e' que a negociacao Diffie-Helman(sp?) do SSHv2 deixa a maquina sentada. Ha' aqui um trade-off entre a tua seguranca e o hardware que tens. Posto isto, nao nos esquecamos que estamos a ver estes bugs porque o desenvolvimento e' aberto; uma pesquisa rapida no site do ssh.com nao mostra qualquer advisory.
|
| | | | | O mesmo. Precisas do mesmo grau de seguranca em todos eles. Estava também a considerar a licença e a viabilidade comercial. Por exemplo, a liceça non-commercial do ssh da ssh.com é bastante permissiva, mas não se aplica em casos de empresas. Já numa universidade ou em casa, este problema não se põe. E depois há também o factor preço... :) A unica razao para usar o protocolo SSHv1 [...] Eu nunca considerei usar o SSH 1. Isso para mim é impensável. Eu estava a pensar nas implementações disponíveis, não nas versões do protocolo disponíveis. Cumps, João Ribeiro
--
sena@smux.net
http://smux.net/
|
| | | | (i.e. afecta apenas a versão "portable" do OpenSSH - ou seja a que corre em todos os sistemas operativos com excepção do OpenBSD)
a versao portable e' a que corre nos restantes sistemas, mas nao quer dizer que todos estejam vulneraveis...
pelo menos a slackware nao compila o openssh com suporte para PAM, e logo nao e' vulneravel ao problema (e' impressao minha ou o PAM ainda e' uma fonte consideravel de buracos em varios softwares?)
aqui teem o email da slackware sobre a actualizacao:
[slackware-security] New OpenSSH packages (SSA:2003-266-01)
Upgraded OpenSSH 3.7.1p2 packages are available for Slackware 8.1,
9.0 and -current. This fixes security problems with PAM
authentication. It also includes several code cleanups from Solar
Designer.
Slackware is not vulnerable to the PAM problem, and it is not
believed that any of the other code cleanups fix exploitable
security problems, not nevertheless sites may wish to upgrade.
These are some of the more interesting entries from OpenSSH's
ChangeLog so you can be the judge:
[buffer.c]
protect against double free; #660; zardoz at users.sf.net
- markus@cvs.openbsd.org 2003/09/18 08:49:45
[deattack.c misc.c session.c ssh-agent.c]
more buffer allocation fixes; from Solar Designer; CAN-2003-0682;
ok millert@
- (djm) Bug #676: Fix PAM stack corruption
- (djm) Fix bad free() in PAM code
Higuita |
| | | | | | "not nevertheless"???
"It is every citizen's final duty to go into the tanks and become one with all the people."
- Chairman Sheng-ji Yang, "Ethics for Tomorrow" |
| | | | 8)
nao sao so' os portugueses que falam mal a sua lingua, os americanos pelos vistos tambem se enganam ;)
Higuita |
| |
|
