[FUGSPBR] explorar vulnerabilidade

Celso Viana celso.vianna em gmail.com
Sex Dez 17 16:28:40 BRST 2004


Ronan,

Mais uma vez obrigado pela explanação sobre o assunto..... já posso
argumentar melhor sobre isso. Se vc puder me disponibilizar o material
a que se referiu te agradeceria muito.

Celso


On Fri, 17 Dec 2004 11:01:43 -0200, Ronan Lucio <ronanl em videosoft.com.br> wrote:
> Celso,
> 
> > O seu comentário é pertinente........ agora estou a pensar: mostro
> > alguma coisa? ou não? seria melhor deixar isso por conta de cada um,
> > para que eles exercitem o raciocínio (não deixando de salientar que é
> > anti ético essa prática em ambientes que não seja o seu próprio
> > laboratório)? .... o que eu faço? como é que argumento com eles?
> 
> Primeiramente deixa eu entender uma coisa:
> A sua disciplina é sobre segurança, certo?
> 
> Caso positivo, na pós-graduação eu dei uma palestra sobre este
> tema (Segurança de redes) e ainda devo ter algum material quardado.
> Como foi apenas uma palestra, as coisas estão bastante resumidas,
> e talvez servam apenas os temas abordados, levando em consideração
> que segurança envolve desde invasões aos usuários (virus, backdoors),
> passando pelos servidores, e indo até as formas de identificar/barrar
> ataques "on the fly", entidades competentes e etc.
> Ou seja, o tema é bastante amplo. Dá pra ser bem trabalhado.
> 
> Voltando a questão do mostrar ou não mostrar.
> Na minha opinião (pessoal), invadir uma máquina para mostrar
> aos alunos seria uma atitude anti-ética, até porque uma sala de aula
> é um lugar de certa forma, público, onde quase qualquer um pode
> frequentar.
> 
> Sabemos que na prática, é importante para o profissional de segurança
> identificar se o sistema dele está vulnerável, porém, isto ele faz através
> de listas/sites/blogs/informativos sobre segurança e conhecendo a
> versão do software o qual ele está rodando.
> A partir daí, é aplicar o patch, workaround ou atualização. Ou seja,
> ele não necessariamente precisará invadir a máquina pra corrigir o
> problema.
> Caso o administrador queira realmente certificar-se que o sistema não
> mais está vulnerável e queira tentar invadir o seu próprio servidor,
> penso que isso é uma atitude/inicitativa que deve partir dele.
> 
> Agora... partindo do ponto que uma boa didática deve conter também
> conteúdo prático, e em aulas práticas têm que se mostrar algo, talvez
> você pudesse utilizar exemplos menos comprometedores como
> buscar as informações do DNS (hosts e versão), e a partir daí
> corrigir a configuração do servidor para que não disponibilize mais
> estas informações para hosts não autorizados.
> 
> Ou seja, exemplos práticos talvez seja mais interessante utilizar
> aqueles que dizem respeito à má administração/configuração do
> servidor, e que não levem tanto para um lado "crackeano".
> 
> Veja que fornecer senhas (e-mails/ftps)  para usuários com uma shell
> válida pode ser um erro bem mais grave do que não aplicar um
> certo patch para um certo serviço (sem desmerecer a importancia
> da aplicação de patchs).
> Imagine um administrador que para criar uma conta de e-mail, cria
> um usuário joao com shell sh.
> Depois o joao entra lá altera a senha para 123.
> 
> []s
> Ronan
> 
> _______________________________________________________________
> Para enviar um novo email para a lista: fugspbr em fugspbr.org
> Sair da Lista: http://lists.fugspbr.org/listinfo.cgi
> Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
>
_______________________________________________________________
Para enviar um novo email para a lista: fugspbr em fugspbr.org
Sair da Lista: http://lists.fugspbr.org/listinfo.cgi
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/



Mais detalhes sobre a lista de discussão freebsd