TEXTOS DIDÁTICOS
Você também pode colocar seu texto didático aqui, apenas mande um e-mail para clubhackerbrasil@bol.com.br e acrescente ao seu texto o seu nome.
_______________________________________________________________________
Autor: Carmem Zardo
Os Cavalos de Tróia Digitais
Você conhece aquela história sobre o presente de grego (literalmente), um belo cavalo de madeira, que escondia centenas de soldados prontos para acabar com a paz dos troianos, certo?
Na era da informática não mudou muito, a não ser pelo fato de que os cavalos de madeira são feitos agora de bytes. Os chamados "programas Cavalo-de-Tróia" são, aparentemente, programas comuns, muitas vezes conhecidos, algumas vezes novos, mas que sempre fazem algo mais do que anunciam.
Seja capturar senhas, causar estragos ou tirar proveito do usuário de alguma forma não documentada. Tá complicado? Imagina o seguinte: toda vez que você se conecta ao seu provedor, ele executa um programa chamado "login", que lhe pergunta seu nome e sua senha. Imagina se alguém faz um programa muito parecido com o "login" mas que, ao invés de lhe conectar no provedor, ele faz uma cópia da sua senha em um arquivo escondido, onde apenas o autor do programa alterado sabe o local. Em alguns dias ele resgata este arquivo e terá nas mãos a senha de quase todos os usuários do seu provedor.
Algumas pessoas têm confundido Cavalos de Tróia com Backdoors. Os conceitos são parecidos, mas existem diferenças fundamentais. Por exemplo: o Back Orifice e o NetBus são Cavalos de Tróia, pois não possuem nenhuma finalidade prática para a vítima. Já o ICKiller, que derruba usuários do ICQ possui uma backdoor, pois há uma porta dos fundos que permite certas invasões
.___________________________________________________________________________________________
Autor: Rodrigo Vaquez
Invadindo seu site para melhorar a segurança
Neste documento irei mostra um incomum método para segurança de sistemas. Em vez de meramente falar sobre os problemas, nos vamos olhar através dos olhos de um intruso em potencial (com os olhos de um intruso), e mostra "por que" ele é um intruso. Irei mostrar que até mesmo aparentemente inofensivos serviços de rede podem ser valiosas ferramentas para pesquisar os pontos fracos de um sistema, até mesmo quando os serviços operam corretamente eles são usados para ataques.
Em um esforço para irradiar alguma luz de como as mais avançadas invasões ocorrem, este documento descreve vários mecanismos que os crackers estão usando atualmente para obter acesso a sistemas e, em complemento, algumas técnicas que qualquer intruso suspeito pode usar, ou que nós usamos em nossa próprias máquinas ou em maquinas de amigos ou com autorização do administrador.
Nossa motivação para escrever este documento e que os administradores de sistemas freqüentemente não sabem ou não sentem a presença do perigo também não conhecem os ataques triviais. Também para informar que o nível de proteção depende do que deve ser protegido, muitos sites parece ter carência de documentos para avaliar qual nível de segurança é adequado para computadores e redes. Para mostrar o que os intrusos podem fazer para ganhar acesso a um computador remoto, nos vamos tentar montar uma ajuda para os administradores de sistemas para ficarem "informados" de quanto seus sites são seguros -- ou não. Nós vamos limitar a discussão a técnicas que podem permitir um intruso remoto acessar (talvez não interativo) shell em máquinas UNIX. Este é o objetivo -- nós consideramos também a dependência do site e , em muitos casos, coisas triviais não merecem muita discussão.
Nós não queremos meramente fazer uma lista de bugs ou regras de segurança. O objetivo deste documento é uma leitura para olharmos nossos sistemas com outros olhos -- e proporcionar "segurança" e uma oportunidade para "entender" como os sistemas podem ser comprometidos.
Nós gostaríamos de dizer novamente que o objetivo deste documento é testar a segurança de seu próprio site, e não para invadir sistemas de outras pessoas. As técnicas de invasão que vamos mostrar aqui com freqüência deixa traços em seus arquivos de log -- isto talvez seja construtivo para examinar após tentar algumas das técnicas de ataque, para ver o que um ataque real talvez deixe você ver. Certamente outros sites e administradores de sistemas vão ver suas atividade se você decidir usar estas técnicas nas maquinas deles para testar a segurança sem a autorização deles, talvez eles não falem nada, mas se perceberem que é um ataque é provável que ações legais sejam movidas contra você.
Este documento tem quatro partes principais. A primeira parte é a introdução e descrição. A segunda parte é uma tentativa de mostra ao leitor como detectar um intruso e mostra os riscos de segurança caso você não conheça seu sistema. Esta parte mostra as técnicas para obter informações, cobre as estratégias básicas de invasão e fala sobre as configurações dos serviços básicos da rede (ftp, mail, tftp, etc.) Ela também discute rapidamente tópicos mais avançados, como NIS e NFS, vários erros comuns e problemas de configuração dos sistemas operacionais ou sistemas específicos. Estratégias defensivas contra vários ataques são tratadas aqui.
A terceira parte fala sobre transações com confiança : O quanto a segurança de um sistema depende da integridade dos outros sistemas.
A quarta parte cobre os pontos básicos para um administrador proteger seu sistema. Muitos dos métodos tratados aqui são conhecidos de todos, mas na pratica freqüentemente eles são ignorados -- vamos tentar mostrar os risco decorrente de ignorar as praticas básicas de segurança.
Estudo de casos, links para tópicos de segurança e informações sobre softwarer são tratadas no final deste documento.
Enquanto explorávamos os métodos e estratégias discutidas neste documento nos escrevemos o SATAN ( Security Analysis Tool for Auditing Networks.) Ele foi escrito em perl, shell, expect e C, ele examina uma máquina remota ou marca uma máquina e colhe todas as informações possíveis sobre os problemas da máquina NIS, finger, NFS, ftp e tftp, rexd e outros serviços. Ele mostra um relatórios com os vários pontos com potencial falhas de segurança -- usualmente as configurações incorretas ou serviços de rede configurados de forma errada, mostra os erros em sistemas ou utilitários de rede ou pobre ou ignorantes decisões de segurança. O SATAN não usa todos os métodos que vamos discutir aqui neste documento, mas vamos incluir todos e disponibilizar via ftp quando estiver completo; Apêndice A cobre os pontos que estão com defeitos.
Note que não é possível cobrir todos os métodos de invasão de sistemas em um simples documento. Particularmente, não vamos falar sobre dois métodos de invasão de sistemas : Engenharia social e quebra de senha. O ultimo método é bom, no entanto, todas as estratégias discutidas aqui formam uma engrenagem para conseguir o arquivo de senhas. Em complemento, enquanto sistemas com janelas (X, OpenWindows, etc.) podem prover fértil terreno para exploração, nós simplesmente não conhecemos muitas técnicas usadas para invadir sistemas remotos via janelas. Muitos cracker de sistemas usam terminais non-bitmapped. Finalmente vermes, vírus, trojan horses e outras coisas muito interessantes não são comuns (em sistemas UNIX) e provavelmente usam técnicas similar as descritas neste documento com estratégias de ataques.
_______________________________________________________________________________
Autor: Daniel Oliveira
Firewall
1 - Introdução
Este texto não aborda todas as características de um sistema de firewall, somente lista de forma resumida alguns dos recursos que seriam recomendado em um sistema de firewall "eficiente".As características listadas abaixo estão presentes no firewall-1 ver. 3.0 (check-point) e fazemos uma breve comparação entre este firewall e as soluções baseada em routers e proxies.
Não pretendo com este texto diminuir a importância das soluções baseadas em router e proxies, mas mostrar de forma rápida e superficial que existem novas tecnologias que agregam maior valor a política de segurança bem como uma maior facilidade na administração e analise de logs entre outras.
2 - Características de um sistema de firewall "seguro"
Resumidamente podemos dizer que um firewall deve ser capaz de ter acesso, analisar e utilizar os seguintes pontos:3 - Comparação com outras alternativas
- Informações da conexão - informações de todas as sete camadas.
- Estado derivado da conexão - o estado que derivou das comunicações prévias. Por exemplo, a saída do comando PORT de uma sessão de FTP poderia ser salvo de forma que uma conexão FTP de dados poderia verificar sua validade.
- Estado derivado da aplicação - o estado derivado de outras aplicações. Por exemplo, a um usuário previamente autenticado só seria permitido acesso a serviços autorizados via firewall.
- Manipulação de informação - a facilidade de manipulação das informações baseadas em todos os fatores acima.
Nesta seção vamos realizar uma análise rápida de soluções baseadas em routers e proxies e veremos até que ponto as tecnologias de firewall disponíveis provêem estas quatro características de firewall.
4 - Routers (roteadores)
Os roteadores operam no nível 3 do modelo de referência OSI, isto acarreta em uma inabilidade para prover segurança até mesmo para os serviços e protocolos mais básicos. Roteadores não são seguros, uma vez que não provêem as características essenciais a um firewall:
Além dos fatores acima expostos, os roteadores são difíceis de configurar, monitor e administra e não provê logs adequados e mecanismos de alerta.
- Informações da conexão - os roteadores só têm acesso a uma parate limitada dos cabeçalhos dos pacotes.
- Estado derivado da conexão e Estado derivado da aplicação - roteadores não conseguem manter o estado derivado de uma conexão ou de uma aplicação.
- Manipulação de informações - roteadores têm uma capacidade muito limitada para manipular informação.
5 - Proxies
O proxy é uma tentativa de implementar firewalls ao nível de aplicação. Os proxies conseguem coletar parcialmete as informações derivadas da conexão e das aplicações. Proxies também são capazes de processar e manipular informação.Porém, há desvantagens ao analisarmos o uso de proxies com os "verdadeiros" firewall :
Os proxies são vulneráveis aos SO e aos erros de aplicações, informação de negligência são mantidas nas camandas mais baixas e em muitas implementações de proxy estas informações não são transparentes.
- Limite de conexão - cada serviço precisa de seu próprio servidor proxy, assim o número de serviços disponíveis depende do número de proxies.
- Limite tecnológico - os gateways não podem prover proxies para UDP, RPC e outros serviços de protocolo comuns.
- Performance - o nível das implementações afeta o desempenho das aplicações.
6 - Conclusão
Historicamente, aplicações a nível de routers supriram as necessidades para o uso comum da Internet.. Porém, como a Internet evoluiu e tornou-se um ambiente dinâmico que constantemente oferece novos protocolos, serviços e aplicações, os routers e proxies não são suficientes e não conseguem garantir a segurança as diversas aplicações da Internet ou cumprir as novas necessidades empresariais, alto bandwidth alto e a exigências de segurança de redes.______________________________________________________________________________
Autor: Luiz CarlosCGI - SSI Server Side Include
O que são Server Side Include ?
SSIs são "marcações" colocadas no documento HTML que podem executar ou manipular variáveis de ambiente e arquivos de estatísticas. Uma "marcação" tipica de SSI se parece com :<!-- comando SSI --> Veja :
<HTML>
<BODY>
<H1> Ultima modificação feita em : </H1> <!--#echo var="LAST MODIFIED"-->
</BODY>
</HTML>O comando SSI acima inclui a última data de modificação em relação ao primeiro arquivo aberto para análise. Isso acontece por que o primeiro arquivo aberto pelo servidor define o ambiente onde todos os outros arquivos devem operar.
Veja uma lista dos comandos SSI com uma breve descriçào :
Os documentos HTML que contém SSI geralmente terminam com a extenção .shtml; A utilização mais comum para SSIs ocorre na inclusão de assinaturas ou logotipos de empresas em todos os arquivos criados. O arquivo include fica armazenado no servidor, sendo incluído sempre que um arquivo HTML que contenha um comando include for solicitado; no próximo tópico vamos detalhar melhor o funciomamento dos SSIs.
config Define o formato de horário, tamanho ou mensagens de erro. echo Insere os valores das variáveis SSI em páginas HTML. exec Executa um comando de sistema ou um programa CGI, inserido a saida gerada pelo programa na página da web. flastmod Insere na página a data de última modificação do arquivo. fsize Insere na página o tamanho do arquivo. include Insere o conteudo de arquivos HTML em páginas da web.
Como o SSI funciona ?
Quando um servidor retorna um arquivo contendo comandos SSI, é necessário ler cada linha do arquivo à procura da sintaxe especial de comandos SSI, ou seja, é realiza uma análise do arquivo (parsing). Os comandos SSI podem estar localizados em qualquer parte dos arquivos HTML. Isso significa que o servidor precisa realizar um esforço extra para localizar os eventuais comandos contidos no arquivo da HTML. Isso também significa que os arquivos SSI são retornados mais lentamente ao cliente da web que os arquivos comuns da HTML. Quanto maior for o número de arquivos SSI que o seu servidor precise processar, mais carga de trabalho será colocada sobre o servidor e, como conseqüência, o servidor passará a operar com menor velocidade, mas isso não quer dizer que você não deva utilizar SSI, basta estar ciente do custo e dos benefícios associados ao uso de arquivos SSI.
É perigoso habilitar SSI ?
Se seu servidor permite rodar programas CGI e forem seguidas as mesmas restrições definidas para os programas CGI quando utilados os SSI, não haverá riscos adicionais; caso você não tenha certeza quanto as restrições dos CGIs recomendo desabilitar o comando exec do SSI. O comando exec executa comandos com o UID do servidor web.Vejamos dois exemplos de uso malicioso do SSI :
Imagine um típico livro de visitas (guestbook) onde as pessoas podem colocar seu comentários, o que acontece se nosso amigo cracker colocar algo do tipo :
<!--#exec cmd="/bin/rm -rf /" -->
Você vai ter uma grande dor de cabeça na proxima vez que algum navegador acessar a página.
Ou algo do tipo :
<!--#exec cmd="find / -name nome_arq -print" -->
Ele vai procura por um arquivo chamado nome_arq. Imagine se nosso amigo colocar isso algumas centenas de vezes no seu livro de visitas, seu servidor com certeza vai parar.
Para ver como desabilitar o SSI em servidores NCSA e Apache, olhe o arquivo access.conf e tenha certeza de que a diretiva "Includes" não esteja na lista de opções. Aqui está um exemplo do diretório root, mas você deve verificar todos os diretórios definidos :
#/home/www/docs inicio do root
<Directory /home/www/docs># Aqui pode existir "None", "All" ou qualquer combinação de
# "Indexes", "Includes", "FollowSymLinks",
# "ExecCGI"ou "MultiViews".Options Indexes FollowSymLinks
</Directory>Cheque também no arquivo srm.conf, as seguintes linhas :
Addtype text/server-parsed-html .shtml # todos os arquivos terminados com .shtml pode executas comandos SSI
Addtype text/server-parsed-html .html # todos os arquivos terminados com .html podem executar comandos SSISe você quer rodar os comandos mais simples do SSI no seu servidor coloque "IncludesNOEXEC" na lista de opções para desabilitar o comando exec e só permita a execução de comandos SSI nas páginas com extenção .shtml. Isso vai eliminar a maioria dos problemas; mas você ainda está sujeito a brincadeiras. Por exemplo, considere uma centena destas linhas no seu livro de visitas :
<!--#echo var="LAST MODIFIED" -->
Agora é com você.
_______________________________________________________________________________ NÃO ESQUEÇA DE MANDAR VOCÊ TAMBÉM O SEU TEXTO, VOCÊ IRÁ CONTRIBUIR BASTANTE COM O CLUB HACKER.