[FUGSPBR] explorar vulnerabilidade
Ronan Lucio
ronanl em videosoft.com.br
Sex Dez 17 11:01:43 BRST 2004
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/
Mais detalhes sobre a lista de discussão freebsd