www.linuxsecurity.com.br
1
Fale conosco
C@RTAS
CARTAS
A seção c@rtas é destinada ao
leitor para que opine sobre o conteúdo
da revista LinuxSecurity Magazine, enviando suas sugestões ou comentários. As
cartas podem ser resumidas por questão
de espaço.
mail to: [email protected]
Este
espaço
é seu!
www.linuxsecurity.com.br
2
Sumário
Retrospectiva: os três programas de criptografia mais influentes no dia-a-dia do
administrador da rede.
Marco “Kiko” Carnut.
6
14
Níveis de execução
Rubens Queiroz de Almeida
Enriquecendo os logs de seu sistema Unix e facilitando a auditoria, parte 1
18
Renato Murilo Langona
27
SPAM x qmail
Diego Linke - GAMK
33
Saudosa Malloca, Malloca Querida ...
Izar Tarandach
FingerPrint - Explorando a pilha TCP/IP (versão 1.0)
39
Sandro Mello
45
Introdução à Análise Forense - Parte 1
Leonardo Alcântara Moreira
49
TrustedBSD - Parte I - Introdução
Edson Brandi
52
Snort - Uma ferramenta NIDS
Gabriel Armbrust Araujo
Aumentando a segurança do seu Webserver com LIDS
Rodrigo Pereira Telles
www.linuxsecurity.com.br
3
59
MENSAGEM AO LEITOR
Carta ao Leitor
Em meados de 1999, logo após um excelente treinamento
em segurança computacional ministrado pelo mestre Guina na
Unicamp, criei a lista security-l, composta por alguns dos alunos
do curso para que o fluxo de informações pudesse permanecer
assim como o contato.
A lista, que ainda existe hoje, cresceu e iniciou o projeto
LinuxSecurity Brasil no segundo semestre de 2000, agregando
membros dia após dia passando a ser uma comunidade nacional.
Hoje posso dizer que mais um sonho começa a ser realizado, o da publicação de informações livres através de uma revista.
Inicialmente no formato eletrônico PDF, a LinuxSecurity Magazine nada mais é do que o resultado do esforço da comunidade para
a própria comunidade, da boa vontade de uma grande maioria
disposta a ajudar e compartilhar conhecimentos, o que já é o suficiente para um excelente resultado.
De início a LinuxSecurity Magazine não terá muitas colunas ou seções. Com a evolução da revista e com a boa aceitação
de todos, gradualmente agregaremos novos conteúdos que sejam
pertinentes e úteis à comunidade.
Essa nossa primeira edição pode ser vista como comemorativa dos dois anos de projeto LinuxSecurity e também como a
consolidação de mais uma etapa na evolução do projeto como um
todo, assim como da disseminação do conhecimento e do software
livre em nosso país.
Todos os artigos dessa revista foram escritos por profissionais Brasileiros que aceitaram o convite e o desafio, tanto profissionais de segurança computacional quanto diagramadores,
designers e administradores de sistemas, todos unidos e com um
mesmo ideal.
Agradeço a todos vocês que tornaram possível a realização
desse sonho e espero sinceramente que essa seja não a minha, não
a sua, mas a NOSSA revista, a nossa conquista.
Encerro por aqui essa primeira carta ao leitor, na esperança
de que esse trabalho seja de utilidade, que possa ser continuado
em breve e, quem sabe, tornar-se um dia impresso. Sintam-se todos meus convidados para entrar em contato com sugestões, críticas ou para envio de artigos para próximas edições.
Meus mais sinceros desejos de sucesso a todos.
Renato Murilo Langona
([email protected])
LinuxSecurity Brasil Solutions S/C Ltda.
www.linuxsecurity.com.br
4
www.linuxsecurity.com.br
Diretor Executivo: Renato M. Langona
Diretor de Operações: Renato M. Langona
Diretor de Marketing: Renato M. Langona
Coordenador executivo: Renato M. Langona
Colaboradores
especiais: Gustavo Nozella
Marcello Romeiro
Webmaster: Renato M. Langona
Diagramação e
assessoria gráfica: Marcello Romeiro
Capa : Gustavo Nozella
Marcello Romeiro
Revisão: Renato M. Langona
Gerente Administrativo: Renato M. Langona
LinuxSecurity Magazine é uma
publicação mensal da LinuxSecurity
Brasil Solutions S/C Ltda
Distribuição Exclusiva: OnLine
Fax para contato: +55 14 4621030
SAC ( Serviço de Atendimento ao Cliente)
Problemas de qualidade na entrega e/ou
exemplares. O SAC presta atendimento aos
leitores por e-mail: [email protected]
A LinuxSecurity Maganize não se
responsabiliza por conceitos emitidos nos artigos
assinados de colaboradores, a LinuxSecurity
Magazine não se responsabiliza por eventual
quebra de links fornecidos por colaboradores nem
pelo material exposto neste(s) link(s). Problemas
com quebra de links devem ser reportados para
[email protected]
subject:
“LinkQuebrado” indicando a edição e o artigo”.
A fim de proteger todos os interessados e ainda
assim estipular a divulgação de material referente
ao Linux e à LinuxSecurity Magazine,
convencionou-se que reproduções de texto da
LinuxSecurity Magazine são permitidos, desde
que se inclua a frase “Reproduzido com a
permissão da LinuxSecurity Magazine
(www.linuxsecurity.com.br)”.
www.linuxsecurity.com.br
5
ARTIGO
Sumário
Criptografia: A influência no dia a dia
Retrospectiva: os três programas de criptografia mais influentes no dia-a-dia do administrador da rede
C
tcpdump) em qualquer roteador entre o cliente e
o servidor, junto com um pouco de conhecimento
dos protocolos de rede, tornava trivial capturar
as senhas dos usuários e até do root.
omemoração de aniversário envolve
festa, mas também envolve relembrar o
passado, ceder à nostalgia; e tentar
prever o futuro, enxergar para onde se vai. O
Renato me pediu pra rememorar os programas
de criptografia mais influentes no dia-a-dia
prático do administrador de segurança antenado
no mundo do código livre. Eu diria que foram
três, o SSH, o PGP/GPG e o HTTPS/SSL/X.509,
implementados no Apache via o mod_ssl. Vale
a pena relembrar as histórias, os lances e os por
quês de todos eles – mesmo porque há um
desfecho de impacto para todos nós.
Toda vez que eu falo sobre interceptação, até
hoje um monte de administradores de sistemas
me olha meio incrédulo, achando que é uma
realidade distante ou tecnodelírio de filme
hollywoodiano. Acredite – é feito rotineiramente.
Para muitos, como telecoms e ISPs, o foco não
é espionar os outros, e sim depurar o
funcionamento da rede. Entretanto os espiões
digitais, lícitos e ilícitos, existem. Mas,
retornemos às questões técnicas – falo das
questões culturais mais adiante.
SHELL SEGURO:
ABAIXO O
TELNET E OS
SERVIÇOS-R
Várias soluções foram propostas para tornar
mais difícil para um invasor fazer das credenciais
(login/senha) que conseguisse. As primeiras
foram melhorias no controle de acesso: por
exemplo, usar o tcpwrappers ou um firewall
(àquela época eram raros; mais provável serem
ACLs de roteador Cisco, para os poucos que
sabiam e queriam usá-las) para restringir o
endereço de origem de onde se podia conectar.
A idéia era, “ok, você pega minha senha de
root, mas daí de onde está não usa”. Dificulta,
sim, mas não resolve: o tráfego e as credenciais
continuavam indo abertas do mesmo jeito,
suscetíveis a captura; e nem sempre era viável
restringir o endereço de origem. Além disso, o
atacante poderia nem estar fazendo questão de
logar na sua máquina – meramente ver você
lendo seu correio pelo Pine, Mutt, etc. já podia
ser o bastante para ele.
No começo,
controlar
remotamente
uma
máquina
Unix era usar o utilitário telnet para fazer
emulação de terminal. Ou os “serviços-r”: rlogin,
rsh, rexec. Concebidos nos anos 80, na era em
que a Internet era pequena e crédula, mandavam
todo o seu tráfego “em aberto” – inclusive os
logins e senhas. Isso os tornava presas fáceis
para toda uma sorte de ataques: um sniffer
genérico (capturador de pacotes, tal como o
www.linuxsecurity.com.br
Com um pouco mais de conhecimento e algumas
ferramentas especializadas, tais como o hunt,
6
era possível até seqüestrar uma sessão em
andamento: o usuário legítimo conecta,
satisfazendo quaisquer controles de acesso; e
depois o atacante consegue “tomar conta” da
conexão em si. Se a vítima estava logada no seu
servidor com a conta de root, o atacante
tinha a situação perfeita para causar
um belo estrago. Verdade, é um
ataque sofisticado que requer
diversas pré-condições para ser
feito. Mas quando satisfeitas,
o hunt o torna não apenas
viável, mas muito fácil.
A solução mais aceita veio com o advento do
pacote SSH: o Secure SHell. Era um protocolo
inteiramente novo e um pacote de programas: o
servidor SSH, o cliente SSH e alguns utilitários
de apoio. Ele resolveu os vários subproblemas
técnicos: ele criptografa todo o tráfego, tornando
impossível para o atacante entender o que você
está fazendo e/ou obter logins e senhas;
identifica os servidores usando chaves
criptográficas, o que, se corretamente
usado, permite detectar falsificação de
DNS; oferece um esquema de
autenticação de usuários também
usando chaves criptográficas que torna
as senhas no servidor desnecessárias.
Além de vários outros recursos legais,
como a capacidade de estender o
mesmo tipo de proteção para conexões
X Windows remotas e até para outros
protocolos, tais como o VNC.
E há ainda outros
ataques poderosos:
por exemplo, se um
atacante conseguir
forjar respostas de DNS
para a sua vítima, pode
fazê-la conectar em
uma máquina sob seu
controle, ao invés da
máquina que a vítima
esperava e com isso
pegar as credenciais
desejadas.
Durante vários anos, o SSH
era um tanto desconhecido.
Até porque ele só era
distribuído em código fonte – e
muitos sistemas não tinham gcc, make e
afins para compilá-lo. Há muitos
administradores de rede, especialmente os
“corporativos”, que ou não sabem fazer um
simples ./configure && make install, ou
simplesmente morrem de medo de compilar
um programa eles mesmos; já a turma do código
aberto costuma ser mais desenrolada nisso. (Um
monte de gente de empresas grandes – bem
grandes e famosas, nacionais e internacionais,
setores privado e governo, com um tremendo
orçamento de TI – vive me perguntando sobre o
que é o SSH, como fazer um “projeto piloto” de
SSH na empresa deles, etc; e ainda há alguns
que, quando eu falo em SSH, fazem o sinal-dacruz como se eu fosse o demônio em pessoa.
Memo para os admins corporativos e gerentes
de TI: aprendam com a comunidade opensource; nesse aspecto, eles estão anos-luz à
frente). A licença das primeiras versões do SSH
era muito restritiva, não permitia que o programa
Em suma: telnet,
rlogin, rsh, etc.,
são inseguros
demais. Podem ser aceitáveis para uma rede
local muito controlada, mas disponibilizá-los na
rede global é um risco inaceitavelmente alto –
hoje em dia, é pedir para ser invadido.
A criptografia veio trazer várias contramedidas
técnicas para essas vulnerabilidades. Muitas
delas, como senhas descartáveis (one-time
passwords), SRP, tokens em hardware, etc.,
ajudavam, mas, por uma razão ou por outra,
nunca se tornaram muito populares.
www.linuxsecurity.com.br
7
viesse na instalação padrão dos SOs. Portanto,
sendo opcional, acabava sendo relegado. Os
radicais reagem a isso dizendo:
Torne a segurança o padrão; não dê ao usuário
a chance de degradá-la.
os torna presa fácil para programas como o
sshmitm, que realiza o celebrado ataque “manin-the-middle”. Mas a maioria das pessoas não
faz a menor idéia do que seja esse
ataque, porque desconhecem o
funcionamento
da
criptografia de chave
pública subjacente ao
SSH. Aí toda a segurança
que ele oferece fica fragilizada
meramente pelo mau hábito
do usuário.
Hoje em dia, isso mudou. A turma do
OpenBSD criou uma versão do SSH
chamada OpenSSH, com uma licença muito
mais aberta. Isso tornou possível que ele se
tornasse parte da instalação padrão do
OpenBSD, Linux, Solaris e outros SOs mais
recentes. Há versões para Windows;
inclusive, o OpenSSH já vem pré-instalado
no Cygwin (se você usa Windows além
de Unix e não conhece o Cygwin, não
sabe o que está perdendo). Em
qualquer repositório acha-se pacotes
RPMs, DEBs, etc., bem como binários
até para plataformas menos comuns,
tais como AIX, HP-UX, Solaris, etc.
Compilá-lo a partir dos fontes costuma ser
facílimo. Qualquer que seja o caso, levase menos de cinco minutos para
instalar e por para rodar. Há vários
ótimos clientes para Windows
(SecureCRT, a própria linha de produtos da
SSH.com e da Bitvise, TTSSH, Putty) e há até
clientes em Java (JavaSSH, Mindterm) .
Esse é só um exemplo
dentre muitos possíveis
para ilustrar um ponto
recorrente: segurança não
é plug-in – não é
simplesmente instalar um
programinha e estar
seguro. Segurança é
entender o sistema, suas
possíveis falhas, como as
contramedidas
contornam
as
vulnerabilidades, o que pode dar
errado, qual a parte do usuário em tudo isso –
que hábitos ele tem de ter, como tomar decisões
de segurança informadas e conscientes. Eu
costumo dizer que segurança é como higiene:
não basta instalar o chuveiro; é preciso adquirir
o hábito de tomar banho todo dia.
Por tudo isso, há quem considere o SSH uma
das mais bem sucedidas iniciativas de prover
segurança através de criptografia: amplamente
disponível, seguro, bem implementado, fácil de
instalar, conveniente de usar. Falaremos de
outras iniciativas não tão bem sucedidas, que
pecam em algum desses pontos.
Na comunidade open-source, o SSH já é velho
companheiro de muitos admins. Mesmo assim,
muitos nunca o estudaram por completo.
Exemplo:
Muitos desconhecem que o ssh-agent e o
ssh-add podem prover um serviço de
“single-sign on” que permite ter toda a
segurança do SSH digitando a frase-senha
da chave privada do usuário uma única vez.
Há uma armadilha no fato do SSH ser
conveniente de usar: ele é até conveniente
demais. Isso faz com que muitos administradores
não estudem direito no que ele se baseia, as
proteções que ele oferece, e quais as condições
para que seja efetiva. Por exemplo: a
esmagadora maioria dos usuários do SSH que
eu conheço não se importa em checar o
fingerprint dos servidores onde conecta. Isso
www.linuxsecurity.com.br
As lições que se tiram são: se você ainda usa
telnet, rlogin, etc., faça um favor a si mesmo: livrese deles e troque pelo SSH. E se você pretende
8
trabalhar com segurança, e, em especial,
segurança criptográfica, devore os manuais, a
documentação. Segurança não é só instalar o
pacote. Leia, estude, compare com outros
sistemas, outras instalações. Aprofunde-se.
Professores universitários: incluam essas coisas
nos currículos dos seus cursos; e uma dica: o
melhor, mais didático, prático e abrangente livro
que eu conheço sobre os conceitos de
criptografia aplicados a segurança de redes é o
livro do Stallings. Faça seus alunos lerem uma
página dele ao escovar os dentes todo dia e em
um ano você terá formado admins mais
preparados. Nada melhora mais a segurança do
que gente que sabe o que faz.
Para dar um exemplo de bobagens ditas por
gente muito lida e supostamente em outros
assuntos confiável, basta lembrar que, quando
o sshmitm foi lançado no dsniff-2.3, vários jornais
e sites anunciaram “o fim do SSH”, “novo
programa ‘quebra’ a criptografia do SSH” –
quando, de fato, o ataque man-in-themiddle já era conhecido e previsto desde
o início, e os meios para tratá-lo já
existiam: a verificação do fingerprint
do servidor e o modo
StrictHostKeyChecking.
popular na Internet. Isso atraiu a ira das
entidades de inteligência do governo americano,
que há muito vinham jogando areia do
desenvolvimento de bons produtos de
criptografia porque eles rotineiramente espionam
o tráfego das redes de dados e não querem
deixar de entender o que capturam. Exportar
produtos de criptografia nos EUA sem uma
autorização expressa do governo era crime na
época. Zimmermann foi processado e levou três
anos e muita ajuda da Electronic Frontier
Foundation para tirá-lo da enrascada.
O PGP tem várias similaridades conceituais com
o SSH: eles usam uma técnica híbrida para
prover a segurança e gerenciabilidade de chaves
da criptografia de chave pública (também
conhecida como “assimétrica”) com a
performance da criptografia simétrica
convencional (que é 1000 vezes mais rápida);
vários dos algoritmos são os mesmos (RSA, DH/
ElGamal, DES, CAST, AES, etc); os dois provêem
confidencialidade – o SSH protege o tráfego de
rede, enquanto o PGP protege mensagens de
e-mail e arquivos quaisquer; para que seu uso
realmente garanta a segurança, é preciso
conferir os fingerprints das chaves. Eles diferem,
porém, nos detalhes de implementação, nos
formatos de dados e dos pacotes, etc.
PRIVACIDADE DE
EMAIL: PGP & GPG
Um recurso legal que o PGP tem é o de
assinatura digital (o SSH também faz, é invisível
para o usuário; é usado só internamente, para
prover a autenticação). Você pode criar um bloco
de dados que autentica uma mensagem ou
arquivo qualquer, satisfazendo as seguintes
propriedades: só você pode criar esse
pacotes de dados e ninguém mais
conseguiria forjá-lo; e qualquer pessoa
pode verificar sua autenticidade.
Justamente por isso, esse bloco de
dado é chamado de “assinatura
digital”. Ele age algo parecido com
uma assinatura física – ele
garante que você gerou aquela
mensagem ou arquivo. E mais:
Outra história heróica de como a criptografia vem
se enxerindo na vida prática dos admins e dos
usuários em geral é o caso do PGP. Para quem
não conhece, é um programa que permite cifrar
mensagens de e-mail e arquivos quaisquer. Ele
já tem uma longa história – a primeira versão foi
lançada em 1991, para DOS, como um trabalho
solitário do Phil Zimmerman. Depois de vários
upgrades de versão, virou um produto da Network
Associates, mas, por insistência do Zimmerman,
sempre houve uma versão freeware.
O PGP foi um dos primeiros programas com
criptografia genuinamente forte a se tornar
www.linuxsecurity.com.br
9
se o arquivo for adulterado, sua assinatura não
conferirá – ela é função da mensagem (as
assinaturas reais não provêem isso). Ou seja,
como dizem os professores de criptografia: a
assinatura digital provê também verificação de
integridade.
Outro recurso único do PGP é a segurança de
sabermos com quem estamos falando. As chaves
PGP identificam pessoas, através de seus nomes
e endereços de e-mail: os usuários podem usar
o próprio recurso de assinatura digital para
assinar as chaves de outros usuários como forma
de “apresentá-los” entre si. Ou seja, se eu assino
a sua chave pública PGP, isso é interpretado
como que eu tenha dado meu aval de que essa
chave é mesmo sua; se alguém mandar uma
mensagem para você usando essa chave, eu
atesto que você é você mesmo. No jargão da
área, isso se chama “distribuição indireta de
confiança”.
O SSH não tem esse recurso. As chaves SSH
identificam os servidores apenas por IP/DNS.
Mas elas não provêem a possibilidade de um
servidor atestar a identidade de outro, ou do
admin senior assinar as chaves dos seus
servidores, ou algo que o valha. Por isso, confiase que os usuários sejam maduros o bastante
para religiosamente se dar à ligeira
inconveniência de verificar os fingerprints das
chaves para se certificar de que ninguém está
zoando com seu roteamento ou com seu DNS.
Alguns diriam que essa inconveniência é mais
do que ligeira, dado que até usuários experientes
freqüentemente não verificam os fingerprints.
Mas a verdade é que muita gente que usa
o PGP também está se lixando para esse
negócio de assinar as chaves uns dos
outros. A maioria nem sabe que nada disso
existe. E muitos dos que sabem, não
aplicam. O resultado final é que a
criptografia agrega segurança,
realmente
dificulta
a
interceptação... mas não tanto
www.linuxsecurity.com.br
10
quanto poderia ser. Se o usuário for descuidado,
um araponga determinado ainda consegue
interceptar o tráfego de muita gente; ele tem mais
trabalho, mas ainda consegue. Por outro lado,
para os conscientes da importância dessas
questões, vivemos um momento único:
finalmente temos em mãos as ferramentas para
tornar o trabalho dos arapongas realmente
inviável. Há apenas poucos anos, isso não
apenas não existia, mas também parecia
inconcebível. Hoje é uma realidade: podemos
enviar e-mails com a velha e boa privacidade.
Mesmo assim, ainda há um longo caminho a
trilhar, pois o PGP ainda é “coisa de nerd”: só
quem usa são os interneteiros da velha guarda,
administradores de sistemas mais esclarecidos
e entusiastas de informática. O usuário médio
do Windows que só sabe visitar portal não faz a
menor idéia de nada disso. O desafio
é de divulgação e de didática:
como tornar todos esses
conceitos acessíveis para uma
audiência não-técnica mais
ampla. Um amigo meu disse
certa
vez
com
muita
propriedade: “vou acreditar que
o PGP se tornou popular
quando mamãe passar a usar”.
Parece brincadeira enunciar
assim, mas ele está certo: eu
vivia alardeando que o PGP era
fácil de usar e descobri que... estou
errado. Quase todo usuário novato demonstra
dificuldade em entender os conceitos de chave
privada e chave pública; a primeira coisa que
eles fazem é mandar uma mensagem cifrada
para eles mesmos, ao invés de mandarem as
chaves públicas recém-geradas deles – entre
muitas outras patetadas simples mas
dolorosamente comuns. Leia mais sobre isso no
artigo “Por Que Joãozinho Não Consegue Cifrar:
Uma Avaliação da Usabilidade do PGP 5.0”, que
apesar do título jocoso, é excelente, sério, direto
ao ponto.
conjurar os mortos: usar infame o esquema de
certificação X.509.
Justamente porque o PGP não conquistou o
grande público, a Network Associates nunca
conseguiu fazer dinheiro com ele. Resultado: ela
desistiu e descontinuou a linha de produtos PGP,
deixando uma legião de usuários meio que
órfãos. A comunidade de código-aberto vinha se
preparando para isso e fez um programa
compatível: o GNU Privacy Guard (GPG), cujo
time de desenvolvimento hoje conta com subsídio
do Governo Alemão. O Zimmerman fundou uma
ONG para promover o padrão OpenPGP. Apesar
de tudo, hoje o GPG é item padrão na maioria
das distribuições dos SOs de código aberto. Mas
ainda há muitos, muitos usuários por conquistar.
O X.509 é um formato para armazenar chaves
públicas em coisas chamadas certificados
digitais, que permitem não só obter as chaves
necessárias para que a criptografia funcione,
mas também oferece meios de garantir que as
chaves pertençam a quem dizem pertencer –
uma versão daquela idéia dos usuários
assinarem chaves uns dos outros que discutimos
acima sobre o PGP, só que de forma mais
hierarquizada, rígida e institucional.
Em tese, isso viabiliza a seguinte coisa: o usuário
conecta em um site, recebe as chaves e o
navegador as valida automaticamente,
sinalizando “tudo ok” para o usuário através de
um simpático cadeadinho amarelo. Isso funciona
porque o certificado em a assinatura digital de
uma Autoridade Certificadora, empresas cujo
negócio é dar o “aval digital” que os sites são
quem dizem ser – de novo, que não tem ninguém
corrompendo o DNS ou o roteamento globais da
Internet. (Acredite, todo santo dia tem gente
tentando corrompê-los).
X.509, SSL e HTTPS: A WEB
“SEGURA”
Demos um passeio pela
segurança de conexões
de emulação de terminal,
com o SSH, e das
mensagens de email,
com o PGP. É natural
perguntar: hmmmm... e o
que temos de segruança
criptográfica para a Web e seu
protocolo-mor, o HTTP? Temos o
HTTPS.
Essa é uma história mais sórdida, que
remonta à ressureição de alguns mortos.
Explico: em 1993, a Netscape teve a sacada de
bolar um protocolo para prover segurança
criptográfica para HTTP. Na ocasião, a sensação
era que segurança criptográfica tornaria a Web
um paraíso para se conduzir negócios on-line.
O protocolo em si levou algum tempo para ser
evoluído, mas hoje temos o SSLv3 e seu irmão
mais novo, o TLSv1. Quando aplicado ao HTTP,
dá origem ao HTTPS que vemos nas URLs dos
“sites seguros”. Contudo, na hora de escolherem
um meio de distribuir as chaves e garantir a
identidade dos servidores e clientes, resolveram
www.linuxsecurity.com.br
Seria tudo muito bonito se: a) o formato X.509
não fosse incrivelmente rebuscado, difícil de
implementar e inerentemente problemático – eles
são mais irritantes que os arquivos .TIFF dos
programas gráficos, que às vezes nem o
programa que salvou consegue ler de volta; b)
várias versões do IE/Windows não tivessem
criptografia deliberadamente aleijada; c) a
interface de usuário de gerenciamento de
certificados digitais não fosse genericamente
uma droga na maioria das aplicações, tornando
tudo isso incrivelmente obscuro para a mamãe
do meu amigo que só quer comprar uns
presentes na americanas.com.
Pior, as Autoridades Certificadoras oferecem um
serviço desnecessariamente caro (um certificado
digital para servidor custa uns R$ 2.500,00 por
ano), burocrático e que não garante grandes
11
níveis de segurança. Além do fato de o usuário
não entender nada: o fato do site ter o selinho
“site seguro, clique e verifique” significa apenas
que o site tem boa chance de ser legítimo e que
o tráfego é difícil de ser interceptado – mas não
garante que o site não tenha vulnerabilidades
ridículas que lhe permitam ser invadido (ou que
já esteja invadido) e ter toda a base de cartões
de crédito roubada, ou pedidos emitidos nos
nomes de outras pessoas, etc; nem garante a
idoneidade da empresa. Mas o usuário final vê o
cadeadinho amarelo e acha que está tudo bem.
Mesmo assim, o SSL/TLS/HTTPS é um avanço.
Montar um webserver “seguro” leva mais que os
cinco minutos que se leva para montar um
servidor SSH, mas o mod_ssl do Apache faz um
belo trabalho em tornar a tarefa senão simples,
pelo menos factível. Se você tiver um pouco de
paciência de ler os HOW-TOs e a documentação,
dá pra fazer bem feito em uma tarde. Ainda assim,
o que eu recebo de e-mail de gente me pedindo
ajuda sobre como gerar seu primeiro certificado
só perde para a quantidade de spam que aterrisa
diariamente na minha caixa postal. Aliás, pra
esses: visitem a AC de Certificados Expressos
da FreeICP e sigam as instruções; o certificado
sai na hora, feito caldo de cana. Para turma do
Windows, funciona no IIS, também.
O protocolo SSL também provê uma maneira
poderosa de autenticar não só os servidores, mas
os usuários também, usando chaves públicas –
conceitualmente semelhante ao método
empregado pelo SSH para fazer a mesma coisa,
só que, claro, muito mais complicado, rebuscado,
coalhado de problemas de interoperabilidade.
Resultado: quase ninguém usa. Há pouquíssimos
desenvolvedores que sabem criar aplicações que
usem esses recursos da maneira correta. E é
justamente esse, complicado, caro e rebuscado,
que o Governo Brasileiro tornou lei.
www.linuxsecurity.com.br
A MP 2200-2: AGORA CRIPTO
É LEI NO BRASIL
É
isso mesmo. Essa
história
toda
de
criptografia, chaves
privadas e públicas –
tudo isso que um monte de
gente não sabe usar direito, foi
institucionalizado na Medida
Provisória 2200-2 e se chama
“Infra-Estrutura de Chaves
Públicas – Brasil”, ou ICP-BR.
Teoricamente, é uma boa idéia:
usar a nata dos algoritmos de
criptografia para tornar Internet
Brasileira mais segura.
Nada é difícil para quem não
tem de implementar. Para nós,
administradores de sistemas e de redes,
desenvolvedores de aplicações, etc., sobra ter
de descascar o abacaxi da interoperabilidade
para criar essa Internet Brasileira supostamente
segura. Nem vou cansar o leitor sobre as
dezenas de coisas que podem dar errado se não
implementarmos direito (minto; logo abaixo eu
digo pelo menos uma que é particularmente fácil
de explicar). Para isso, visitem o site do Projeto
FreeICP; é um projeto que tenta criar uma infraestrutura de chaves públicas que de código
aberto que funcione e interopere com a ICP-BR
– o que, ao forçar uma discussão centrada nos
aspectos técnicos de implementação, expõe as
dificuldades em se implementar o proposto pela
ICP-BR.
Um aspecto especialmente trágico é que, como
quase ninguém entende nada disso, algumas
coisas muito estranhas viraram lei. Por exemplo,
a resolução No 11 do Comitê Gestor da ICP-BR
diz que todos os certificados digitais de usuário
devem conter a data de nascimento, CPF, PIS/
PASEP e RG+Órgão Emissor do detentor).
12
Pense bem nisso: você quer mesmo revelar todos
esses seus dados pessoais para qualquer um
na Internet? Especialmente considerado que
tudo que sua operadora de cartão de crédito pede
para lhe “autenticar” em várias operações pelo
atendimento via telefone é sua data de
nascimento e CPF? Se os spammers já pintam
miséria pegando só seu endereço de e-mail, o
que você acha da perspectiva de eles poderem
pegar seus identificadores nos principais
cadastros nacionais em uma só tacada?
O CAMINHO ADIANTE
A criptografia mudou, sim, o nosso jeito de
trabalhar, e tem tornado, a passos lentos mas
firmes, a Internet mais segura. O SSH nos
permite administrar as máquinas remotamente;
o PGP nos provê boa segurança para mandar
correio (dá até pra mandar senhas de root de
servidores via e-mail... o quêêê? Você mandava
mesmo sem criptografia?!) e arquivos; o mod_ssl
tem impulsiona a web segura. E há várias outras
aplicações criptográficas para as mais diversas
especialidades, numerosas demais para
mencionar aqui. Mas o resultado é inegável: a
infra-estrutura para tornar a Internet mais segura
já está aí.
Isso nos impõe um desafio: aprender a usar isso
tudo de forma segura e manter isso tudo seguro.
Em detalhes. Compreender os prós e contras,
entender a teoria por trás das coisas e saber
aplica-la na prática. Não exagerar demais em
uma proteção e deixar todo o resto descoberto.
Explicar isso para os usuários, para os gerentes,
para os políticos e aqueles que decidem –
melhorar nossa didática, refinar as analogias.
Entender as questões políticas, desenrolar os
problemas de interoperabilidade, atentar aos
regulamentos. Ter uma visão geral do quanto a
criptografia já está difundida em diversas
aplicações (dica: a PKI-Page é um bom ponto
de partida).
www.linuxsecurity.com.br
13
E, por causa da MP 2200-2, a demanda por gente
que entenda sobre como montar webservers
seguros com certificação digital vai crescer um
bocado. Eu arriscaria dizer que vai se tornar um
bom filão de mercado – vai ser curioso ver os
quadros de avisos pedindo “contrata-se
profissional com experiência em criptografia,
montagem e operação de servidores seguros
segundo o padrão ICP-BR” ou “administrador de
rede com experiência em administração de
servidores SSH”; ou ainda “procura-se
desenvolvedor de aplicações Web em Java;
experiência com criptografia, JCA e JCE são
altamente desejáveis”. A criptografia, antes
distante, agora vai fazer parte dos nossos
currículos e do nosso dia-a-dia. Tanto a boa, bem
implementada, quanto a ruim. Vai ser um
prazeroso desafio acompanhá-la todo dia nesse
e nos próximos aniversários da LinuxSecurity.
FICHA
do
AUTOR
Nome:
Marco “Kiko” Carnut.
CISSP é Consultor de Segurança de
Informação da Tempest Security
Technologies, unidade de negócios
do Centro de Estudos e Sistemas
Avançados do Recife, ONG
vinculada ao Centro de Informática
da Universidade Federal de
Pernambuco.
e-mail: [email protected]
ARTIGO
Sumário
Níveis
Níveis de
de Execução
Execução
Níveis de execução
S
istemas Linux podem funcionar em
vários níveis distintos de execução.
Cada nível é caracterizado pelo conjunto
de processos permanentes e funções oferecidas.
Sistemas Red Hat Linux e derivados, utilizam seis
níveis de execução, ou runlevels, como são mais
conhecidos. Esta concepção tem suas origens
no sistema Unix desenvolvido na AT&T (System
V Unix).
K10xfs -> ../init.d/xfs
lrwxrwxrwx 1 root root 13 Mar 22 20:58
K15gpm -> ../init.d/gpm
lrwxrwxrwx 1 root root 15 Mar 22 20:53
K15httpd -> ../init.d/httpd
lrwxrwxrwx 1 root root 18 Mar 22 21:05
K30sendmail -> ../init.d/sendmail
lrwxrwxrwx 1 root root 14 Mar 22 21:03
K50inet -> ../init.d/inet
lrwxrwxrwx 1 root root 13 Mar 22 20:53
K60atd -> ../init.d/atd
lrwxrwxrwx 1 root root 15 Mar 22 21:06
K60crond -> ../init.d/crond
lrwxrwxrwx 1 root root 13 Mar 22 21:02
K60lpd -> ../init.d/lpd
lrwxrwxrwx 1 root root 15 Mar 22 20:59
K75netfs -> ../init.d/netfs
lrwxrwxrwx 1 root root 17 Mar 22 21:05
K89portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Mar 22 20:59
K90network -> ../init.d/network
lrwxrwxrwx 1 root root 16 Mar 22 21:06
K99syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 16 Mar 22 20:59
S00single -> ../init.d/single
Os níveis de inicialização são controlados
pelos scripts que se encontram no diretório /etc/
rc.d/init.d. Uma listagem deste diretório revela
os seguintes arquivos:
atd
nfslock
crond
portmap
dhcpd
postgresql
functions
random
gpm
rstatd
halt
rusersd
httpd
rwhod
inet
sendmail
keytable
single
killall
smb
linuxconf
snmpd
lpd
squid
mars-nwe
sshd
named
syslog
netfs
xfs
network
ypbind
Uma rápida inspeção nos revela vários
serviços conhecidos como sendmail, httpd e
named.
Cada nível de execução é controlado
através de links simbólicos existentes nos seis
diretórios (/etc/rc.d/rc1.d até /etc/rc.d/rc6.d).
Examinemos o conteúdo do diretório /etc/rc1.d:
Como se pode ver, todo o
conteúdo do diretório
/etc/rc1.d consiste
de links simbólicos
apontando para scripts
dentro do diretório /etc/
rc.d/init.d. A primeira letra dos
nomes dos links simbólicos pode ser ou “S” ou
“K”, indicando se o processo para o qual aponta
deve ser ativado (Started) ou desativado (Killed).
O número que se segue a esta letra indica a
# ls -l
lrwxrwxrwx 1 root root 19 Mar 22 21:02
K00linuxconf -> ../init.d/linuxconf
lrwxrwxrwx 1 root root 18 Mar 22 20:54
K05keytable -> ../init.d/keytable
lrwxrwxrwx 1 root root 13 Mar 22 20:59
www.linuxsecurity.com.br
14
ordem em que os processos devem ser
encerrados ou ativados. Em nosso exemplo o
primeiro processo a ser desativado é o linuxconf.
O primeiro a ser ativado, após terem sido
encerrados todos os demais processos, é o script
single. Cada um dos scripts residentes no
diretório /etc/rc.d/init.d aceita geralmente três
parâmetros: start, stop, restart. Estes parâmetros
indicam, respectivamente, a ativação,
desativação e desativação seguida de
ativação do processo. Para determinar
o nível de execução em que seu
sistema está funcionando, utilize
o comando /sbin/runlevel. Este
comando irá consultar o arquivo
/var/run/utmp para determinar o
estado atual e o anterior. Caso
o estado anterior não possa
ser determinado é exibida a
letra “N” em seu lugar:
rede (como nfs, nis, named e httpd).
Nível 3
Este é o nível normal de operação,
com todos os processos ativos.
Nível 4
Este nível não é utilizado na maior
parte das distribuições
Nível 5
Semelhante ao nível 3, com todos os
processo ativos, porém com uma
interface gráfica de logon
Nível 6
É executado neste nível um reboot do
sistema.
\
Alteração dos Níveis de Execução
Os níveis de execução podem ser mudados
pelo superusuário com o sistema em
funcionamento. Sempre que é alterado um nível
de execução são comparados, nos dois níveis,
os processos que devem ser ativados e quais
devem ser desativados. O processo init, que é
processo pai de todos os demais (PID 1),
compara a lista dos processos que devem ser
encerrados no diretório indicativo d o
nível de execução atual com a
lista dos processos que devem
ser ativados no nível de execução
de destino. De posse desta
informação o processo init
determinará quais processos devem
ser ativados ou desativados.
Para reiniciar o sistema basta
executar o comando:
#init 6
Veja a lista dos links em /etc/
rc.d/rc6.d:
# /sbin/runlevel
N3
Descrição dos Níveis de Execução
A seguir listamos os estados possíveis de
um sistema Linux e sua descrição:
Nível 0
Neste nível o sistema está parado
Nível 1
Sistemas funcionando no nível 1
estão em modo monousuário, com
um conjunto mínimo de processos
ativos. O sistema de arquivos raiz
(root) está montado em modo de
leitura. Este nível de execução é
normalmente utilizado quando a
inicialização normal falha por
alguma razão.
Nível 2
A maior parte dos serviços estão
ativos, com exceção dos processos de
www.linuxsecurity.com.br
#init6
K00linuxconf
K05keytable
K10xfs
15
Definição ou Remoção de Processos Residentes
K15gpm
K15httpd
K30sendmail
K50inet
K60atd
K60crond
K60lpd
K75netfs
K80random
K89portmap
K90killall
K90network
K99syslog
S00reboot
Para desativar um serviço de um
determinado nível de execução basta
remover o link simbólico do diretório
apropriado. Por exemplo, para desativar o
serviço httpd, do nível de execução 3, basta
remover o link /etc/rc.d/rc3.d/S85httpd do
diretório /etc/rc.d/rc3.d.
Similarmente, para inserir um novo
serviço, basta criar um link no diretório padrão
de execução, apontando para o script
correspondente em /etc/rc.d/init.d:
Como se pode ver, a maioria dos
links inicia-se com a letra “K”, indicando que os
processos serão desativados. Apenas um link
inicia-se por “S”, S00reboot, que aponta para o
script /etc/init.d/halt. Similarmente, para colocar
o sistema em modo monousuário:
# cd /etc/rc.d/rc3.d
# ln -s /etc/rc.d/init.d S99local
Este script realmente existe e é
normalmente utilizado para inserir os serviços
locais. Pela numeração (99), este script sempre
será o último a ser ativado.
init 1
Importante, certifique-se de escolher uma
numeração que posicione a ativação do script
na ordem correta. Se o serviço é dependente do
funcionamento
da
rede
ele
deve
necessariamente ser ativado após estes serviços
estarem ativos.
Nível de Execução Padrão
O nível em que o sistema irá funcionar é
indicado pela entrada do arquivo /etc/inittab.
id:3:initdefault:
Utilitários para Configuração dos Níveis de Execução
Neste sistema o nível padrão de execução
é 3. Para alterar este nível de execução basta
alterar o número “3” para o valor desejado. Nunca
altere este valor para “0” ou “6”, que indicam,
respectivamente, o sistema parado ou em modo
de encerramento.
www.linuxsecurity.com.br
Até agora abordamos a configuração
manual dos scripts de inicialização. Existem
entretanto diversos utilitários para realizar este
este trabalho. chkconfig Utilitário para
configuração dos níveis de execução invocado
a partir da linha de comandos ksysv Utilitário
gráfico que permite a configuração dos níveis
16
de execução e ativação e desativação de
processos individuais linuxconf Ferramenta
genérica de configuração que permite o
gerenciamento dos níveis de execução
A forma mais segura de se lidar com esta
configuração certamente começa com o
entendimento perfeito de seu funcionamento. As
interfaces gráficas podem obscurecer o
significado real do que se está fazendo e
conduzir a uma configuração indesejável. Em
qualquer situação, realizando-se o trabalho
manualmente ou através de utilitários,
recomendamos o backup de todos os arquivos
envolvidos para poder retornar à uma situação
estável em caso de problemas.
Para lidar com a ativação e desativação de
processos residentes, algo que frequentemente
precisamos fazer sempre que alteramos a
configuração de um serviço, precisamos realizar
os seguintes passos:
Referências Adicionais:
No transcorrer deste artigo foram feitas
referências aos comandos ln, init, chkconfig,
inittab e runlevel. A
leitura
da
documentação destes
c o m a n d o s
fornece informações
valiosas sobre
todo
o
processo
descrito e pode
ser acessada a partir
do comando
man (man ln,
man init, etc).
# cd /etc/rc.d/init.d
# httpd restart
Em nosso exemplo nos dirigimos ao
diretório onde ficam todos os scripts de ativação
de processos e invocamos o script httpd com o
parâmetro “restart”.
FICHA
do
AUTOR
Um artifício engenhoso para realizar esta
tarefa nos é fornecido, através de um alias, em
sistemas Conectiva Linux. Este alias, disponível
no ambiente do usuário root, chama-se cds:
alias cds=’cd /etc/rc.d/init.d && ls’
Nome Completo:
Rubens Queiroz de Almeida
Data de Nascimento:06/06/1960
Empresa: Unicamp
Diretor de informática
Mentor de diversos projetos
ligados ao software livre incluindo
a lista
Dicas-L:
http://www.dicas-l.unicamp.br
Como podemos ver, o alias realiza dois
passos: a mudança para o diretório /etc/rc.d/init.d
e a listagem de seu conteúdo. Desta forma
podemos visualizar o nome de todos os scripts
disponíveis, facilitando a invocação do script
apropriado. Simples, mas extremamente útil.
www.linuxsecurity.com.br
17
ARTIGO
Sumário
Enriquecendo os Logs do seu sistema Unix
e Facilitando a Auditoria - Parte 1
Enriquecendo os logs de seu sistema Unix e facilitando a auditoria, parte 1
bastante para verificação real de um dado
servidor, além de não proporcionarem uma
maneira prática e menos monótona de
acompanhamento e leitura, por isso recorremos
a ferramentas livres disponíveis.
Irei apresentar nesse primeiro artigo da forma
mais simples possível algumas ferramentas
específicas para o tratamento e análise/auditoria
de logs em sistemas Unix, tornando-os mais ricos
em informações e mais fáceis de serem
gerenciados.
Introdução
Acredito que já seja do conhecimento da maioria
dos amigos leitores que a auditoria, leitura,
avaliação ou análise freqüente dos logs de um
servidor seja uma das principais funções
delegadas a um administrador de sistemas que
tenha o desejo de manter seu servidor seguro e
estar a par de tudo o que ocorre no mesmo.
Infelizmente essa também é uma das tarefas
mais monótonas e repetitivas, o que acaba
muitas vezes fazendo com que dados
importantes não sejam lidos ou analisados de
forma correta ou com a devida atenção.
Algo que sempre repito e acredito é que uma
das maiores dádivas do mundo do software livre
e Open Source é termos uma miríade de
soluções para um dado problema. É justamente
por isso que o leitor não deve levar em
consideração apenas o que apresentarei nesse
artigo, devendo procurar por si próprio novas
fontes, ferramentas similares e informações mais
aprofundadas para a implementação do sistema
que mais se adequar à sua situação e/ou rede.
Dentre as soluções possíveis, escolhi para esse
primeiro artigo as ferramentas:
Sistemas Unix-like já possuem por padrão um
sistema excelente para registro de logs,
comumente representado pelo syslogd e klogd,
que são os daemons responsáveis por
oferecer
esse
suporte,
registrando mensagens de
diferentes aplicativos e
serviços (inclusive de si
próprios) , além do kernel,
em diferentes locais de
acordo
com
suas
configurações.
–IPPL (http://pltplp.net/ippl/)
–LogSurfer (http://www.cert.dfn.de/eng/
logsurf/)
Apesar de ser
um
sistema
excelente,
geralmente os
logs gerados e
registrados
como padrão
não
são
suficientes ou
completos o
www.linuxsecurity.com.br
Como disse anteriormente, tentarei ser o mais
claro e objetivo possível nesse artigo, porém
convido cada um dos amigos leitores a
realizarem pesquisas e estudos sobre essas
ferramentas para o aprofundamento do
conhecimento e, conseqüentemente, melhor
utilização das mesmas.
18
mesmo e adequá-lo ao seu ambiente.
IPPL
O arquivo de configurações padrão de nossa
instalação é o
/usr/local/etc/ippl.conf (podendo ser alterado no
momento da compilação utilizando o script
configure com a opção —sysconfdir=/diretório),
que é muito bem comentado. Nele temos como
opções principais:
O ippl é um
l o g g e r
altamente
configurável de
protocolos IP
desenvolvido por Hugo Haas e E t i e n n e
Bernard como substituto ou alternativa ao
conhecido iplogger. Ele registra mensagens
ICMP, conexões TCP e datagramas UDP,
possuindo uma sintaxe de configuração amigável
e muito similar a encontrada em servidores web
Apache, além de já possuir um cache DNS
padrão incluído. Podemos entender como Logger
de protocolos IP um serviço ou daemon que
registre em arquivos de log pacotes IP enviados
para um servidor.
–runas
Sintaxe: runas usuário
Através dessa opção podemos utilizar outros
usuários do sistema para executarmos o ippl.
Comumente esse usuário é o nobody ou o ippl
(criado apenas para esse propósito).
–noresolve
No momento em que escrevo esse artigo, a última
versão disponível do IPPL é a 1.4.14 e pode ser
obtida através do endereço:
Sintaxe: noresolve protocolo
Com essa opção ativa em nosso arquivo de
configurações, o ippl não tentará utilizar
resolução DNS durante o registro dos logs para
um dado protocolo escolhido ou para todos
(noresolve all). Essa opção é altamente
recomendada para servidores com alto tráfego.
http://pltplp.net/ippl/archive/ippl-1.4.14.tar.gz
A instalação do IPPL é extremamente simples.
Após realizar o download do código fonte e
descompactá-lo, basta utilizarmos a tríade:
–Log-in
./configure; make; make install
E já teremos o ippl corretamente compilado e
instalado em nosso sistema, já configurado para
ser executado como nobody e com prefixo de
instalação /usr/local por padrão . Caso deseje
utilizar outro usuário como padrão, o script
configure possui a opcao —with-user=USUARIO
ou então você poderá alterá-lo através do
parâmetro runas do arquivo de configurações do
IPPL.
Sintaxe: log-in protocolo destino
Através dessa opção, podemos separar os
arquivos onde serão registrados os pacotes
enviados ao servidor por protocolo. Utilizando
por exemplo log-in icmp /var/log/ippl/
icmp.ippl.log, fará com que os registros de
pacotes icmp sejam direcionados ao arquivo
icmp.ippl.log no diretório /var/log/ippl . Devo frisar
aqui que a ferramenta não cria o diretório ou
arquivo escolhido, ele deverá existir ou ser criado
pelo próprio administrador.
Dependendo do tráfego de seu servidor, uma boa
idéia é simplesmente direcionar todos os seus
logs para o próprio /var/log/messages (log-in all
/var/log/messages), facilitando assim a auditoria
Apesar de já podermos executar o ippl logo após
sua instalação sem a necessidade de alteração
de seus parâmetros, seu arquivo de
configurações possui diversas opções que
podem facilitar ainda mais o funcionamento do
www.linuxsecurity.com.br
19
automática desses logs através do LogSentry ou
pelo LogSurfer (comentado mais abaixo) com um
arquivo de configuração unificado.
Você também tem pode utilizar a opção log em
conjunto da options, disponíves para determinar
de forma explícita como deve ser registrado um
dado pacote ou conexão diferentemente do
padrão configurado. Um exemplo dessa opção
pode ser:
–Run
Sintaxe: run protocolo
A opção run determina quais são os protocolos
cujos pacotes serão registrados. Como padrão
o icmp e tcp estão habilitados.
log options resolve,logclosing,normal tcp
port 22 from 10.0.0.32
Nesse caso, toda conexão vinda de 10.0.0.32
para a porta 22 (ssh) local seria registrada com
as opções resolve (para resolução de nomes),
logclosing (para registro do término da conexão)
e com nível de detalhes normal.
–logformat
Sintaxe: logformat formato protocolo
Essa opção é responsável pelo nível de detalhes
com que os logs serão registrados, variando de
mínimo (short), normal (normal) e detalhado
(detailed). Para qualquer servidor o
recomendado é o detalhado, que inclui
informações a respeito da origem, destino e porta
acessada de uma conexão registrada.
O leitor poderá criar regras mais elaboradas e
complexas de acordo com o funcionamento de
seu servidor e rede obtendo, para isso, maiores
informações através da página manual do
ippl.conf:
man 5 ippl.conf
Além da configuração, o IPPL possui opções para
filtragem de tudo que for registrado. Essas
opções são de fácil entendimento e também
devem ser utilizadas no arquivo ippl.conf.
Uma dessas opções é a ignore, que faz o que o
próprio nome diz, ignora certos pacotes baseado
no protocolo, tipo, host e porta destino, host e
porta origem. Essa opção é importante para evitar
por exemplo que conexões ao serviço web de
um servidor sejam registradas (já que as mesmas
já são registradas de forma muito completa pelo
próprio daemon responsável pela web) ou que
mensagens icmp comuns não aumentem seus
logs de forma descontrolada. Para esse exemplo,
poderíamos utilizar em nosso arquivo de
configurações:
Depois de configurado, podemos já executar
nosso ippl e observar no arquivo de logs
escolhido os pacotes sendo registrados. Não se
esqueça de adicionar o mesmo em seu arquivo
de inicialização:
# Inicializando o logger IPPL
if [ -x /usr/local/sbin/ippl ]; then
/usr/local/sbin/ippl
fi
LogSurfer
Para quem já conhece o
swatch e o LogCheck,
o LogSurfer é uma
ferramenta muito similar
desenvolvida por Wolfgang
Ley e Uwe Ellerman para checagem e auditoria
de logs, porém com a capacidade de manipular
ignore tcp port 80 ou ignore tcp port http
ignore icmp type echo_reply ou ignore
icmp type 0
ignore icmp type echo_req ou ignore icmp
type 8
www.linuxsecurity.com.br
20
registros com diversas linhas, adaptando
dinamicamente suas regras. O programa foi
desenvolvido para monitorar qualquer arquivo de
log baseado em texto de seu sistema em tempo
real, tomando decisões baseadas em regras,
podendo também executar programas externos,o
que facilita muito o trabalho de administradores
de sistemas, principalmente em servidores com
tráfego considerável onde essa análise em tempo
real é praticamente impossível de ser realizada
pelo próprio responsável pelo sistema.
para esse fim, como por exemplo logsurfer :-)
Assim como do IPPL, a instalação do LogSurfer
é bem simples e rápida, bastando aos mais
apressados:
./configure; make; make install
Após a instalação padrão, provavelmente você
poderá encontrar problemas ao acessar as
manpages do pacote dependendo de sua
distribuição. Caso isso aconteça, instale
manualmente as manpages em seu
sistema utilizando por exemplo:
A vantagem do LogSurfer sobre
outras ferramentas de análise
similares é justamente a rapidez
com que você será informado a
respeito
de
qualquer
eventualidade no servidor. Ao
invés de precisar analisar
resumos de logs enviados
ao seu email de tempos em
tempos, você receberá uma
notificação assim que um dado
fato ocorrer e poderá tomar
imediatamente sua decisão ou ainda
acompanhar o caso, evitando muitas vezes um
incidente de segurança maior.
cp man/logsurfer.1 /usr/share/
man/man1/
cp man/logsurfer.conf.4 /usr/
share/man/man4/
Substitua /usr/share pelo
prefixo
correto
caso
necessário.
Depois de corretamente
instalado, precisaremos
agora configurar as regras de
análise do LogSurfer para utilizá-lo corretamente.
O arquivo padrão que deverá conter essas regras
é o logsurfer.conf, porém você poderá especificar
outros arquivos de regras diferentes através do
próprio comando de linha e até executar diversas
instâncias do LogSurfer dependendo de suas
necessidades.
O LogSurfer é uma ferramenta poderosa e muito
versátil, podendo possuir configurações muito
simples, mas também complexas ao extremo.
Repassarei nesse artigo algumas informações
simples e básicas sobre ele, esperando que tais
informações encoragem o estimado leitor a
procurar sempre mais.
Para entendermos melhor a estrutura de
configuração das regras do LogSufer, devemos
primeiramente saber que cada regra no arquivo
deve conter 6 campos obrigatórios e um campo
opcional, todos separados por espaços. O sinal
“-” colocado em um dos campos determinará sua
anulação ou não utilização. Como os campos são
delimitados por espaços, caso um campo
necessite conter espaços, ele deverá estar
delimitado por aspas simples ou duplas, do
contrário cada um será entendido como sendo
um campo da regra.
A última versão do LogSurfer disponível no
momento é a 1.5a e pode ser obtida através do
endereço:
ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer/
logsurfer-1.5a.tar
Como a ferramenta não necessita de privilégios
de superusuário para ser executada, antes de
instalarmos o logsurfer o ideal é criarmos um
usuário comum no sistema, de preferência um
www.linuxsecurity.com.br
21
Se precisarmos utilizar aspas duplas em algum
campo já delimitado por aspas, deveremos
utilizar o caracter escape (“\”).
Os tipos de ação disponíveis são:
–ignore: Nada mais será feito caso a ação seja
ignore, ou seja, o processo será simplesmente
ignorado.
–Exec: executa um programa externo, podendo
receber também parâmetros ou argumentos.
Todos os programas devem ser sempre
especificados utilizando o caminho (PATH)
completo para o mesmo.
–Pipe: Assim como o exec, ele executa um
programa externo, porém repassando a esse
programa as linhas que combinaram com a
regra como stdin. De forma prática é o mesmo
que utilizar o pipe (“|”) em sua linha de
comando para passar argumentos a outros
programas.
–Open: Essa ação abre um
contexto que já exista. O
contexto nada mais é que um
conjunto de linhas que foram
lidas pelo LogSurfer.
–Delete: Essa ação apaga um
contexto existente
–report: Com essa ação os
contextos especificados são
utilizados como stdin do programa
especificado como primeiro argumento.
–rule: Utilizados para criação de novas
regras em tempo real.
Como disse anteriormente, o contexto para o
LogSurfer são conjuntos de mensagens que
foram lidas pela ferramenta. Contextos podem
ser utilizadas com a opção “report” para
apresentar uma coleção de mensagens
associadas a uma ação específica, como por
exemplo todas as mensagens de uma sessão
ftp ou telnet.
Os campos e suas funções em ordem
são:
match_regex not_match_regex stop_regex
not_stop_regex timeout [continue] Ação
Sendo:
–match_regex: Expressão regular que
determina quais linhas ou registros de um log
combinam ou casam com a regra.
–not_match_regex: Expressão regular que
determina quais linhas ou registros deverão
ser excluídos do campo anterior
(match_regex).
–stop_regex: Caso uma linha ou
registro combine com a
expressão regular do
campo stop_regex, a
regra será deletada da
lista ativa.
–not_stop_regex: Caso uma
linha ou registro combine
com a expressão regular
do
campo
not_stop_regex e o
campo stop_regex não
esteja anulado com o sinal “-”, então a regra
não será deletada.
–Timeout: Duração em segundos para timeout.
Para especificar um timeout infinito, devemos
utilizar “0” nesse campo.
–Continue (opcional): Caso a palavra
“CONTINUE” seja incluída na regra, as demais
regras do arquivo de configuração serão
também consideradas ao invés do processo
ser terminado, que é o padrão do LogSurfer.
–Ação: Esse campo especifica o tipo de ação
que deverá ser tomada pelo LogSurfer caso
uma regra seja ativada. Esse campo é seguido
por diversas opções dependendo da ação
escolhida.
www.linuxsecurity.com.br
Cada contexto também possui 6 campos, sendo
eles:
–match_regex: Determina que linhas casarão
com o contexto.
–not_match_regex: utilizado para excluir linhas
determinadas pelo match_regex.
22
–line_limit: Define o número máximo de linhas
que serão armazenadas no contexto. Ideal
para evitar ataques DoS.
–timeout_abs: Valor em segundos que define o
timeout absoluto do contexto antes que a ação
padrão seja executada (comentado abaixo).
–timeout_rel: Valor em segundos que define o
timeout relativo do contexto, que é o intervalo
de tempo de espera para que novas
mensagens sejam adicionadas ao contexto
antes que a ação padrão seja executada.
–default_action: Ação padrão a ser executada
caso o número de linhas máximo ou os
timeouts sejam alcançados. As ações ignore,
exec, pipe e report estão disponíveis para esse
campo.
article.php?sid=3056
h t t p : / / w w w. l i n u x s e c u r i t y. c o m . b r /
article.php?sid=1843
h t t p : / / w w w. l i n u x s e c u r i t y. c o m . b r /
article.php?sid=1848
h t t p : / / w w w. l i n u x s e c u r i t y. c o m . b r /
article.php?sid=2665
http://www-106.ibm.com/developerworks/library/
l-sed1.html
http://www-106.ibm.com/developerworks/library/
l-sed2.html
http://www-106.ibm.com/developerworks/library/
l-sed3.html
Nesse exemplo simples estaremos monitorando
o arquivo padrão de registro de logs de muitas
distribuições Linux, o /var/log/messages.
Apesar de interessante, a teoria
muitas vezes não é muito útil se não
for acompanhada de pelo menos um
exemplo prático de utilização, por
isso vamos apresentar agora um
desses exemplos. Antes de
apresentá-lo porém, gostaria de
recomendar aos estimados
amigos que procurem maiores
informações a respeito de
expressões regulares, cujo
entendimento é muito importante
não só para a utilização dessa
ferramenta, como também para
diversas outras tarefas de
qualquer administrador de
sistemas.
Um bom início de estudo sobre expressões
regulares é o capítulo 19.1 do Advanced BashScripting Guide:
Executamos o LogSurfer da seguinte maneira:
/bin/su - logsurfer -c “/usr/local/sbin/
logsurfer -c /etc/logsurfer.conf \
-f /var/log/messages”
Através dessa linha de comando estaremos
executando o logsurfer com privilégios do usuário
logsurfer, utilizando o arquivo de regras /etc/
logsurfer.conf e monitorando nosso arquivo de
registro de logs /var/log/messages.
Em nosso /etc/logsurfer.conf:
# logsurfer.conf exemplo
‘sshd\[([0-9]+)\]: log: Password
authentication for (.*) failed’ - - - 0 pipe
“/bin/mail root -s \”Falha na
autenticação SSH\””
http://www.tldp.org/LDP/abs/html/x11896.html
‘proftpd\[([0-9]+)\]: server \(([09.]*)\[([0-9.]*)\]\) - no such’ - - - 0 pipe
“/bin/mail root -s \”Usuário proftpd
não existente\””
Além dos documentos para aprofundamento (awk
e sed), que o ajudarão muito a dominar
completamente expressões regulares, além do
próprio awk e sed, indispensáveis à
administração:
‘.*’ - - - 0 ignore
h t t p : / / w w w. l i n u x s e c u r i t y. c o m . b r /
www.linuxsecurity.com.br
23
Nesse simples logsurfer.conf de exemplo temos
uma primeira regra que envia um email ao
superusuário do sistema em todos os momentos
em que houver uma falha na autenticação de um
usuário SSH e a string de erro padrão de
autenticação do sshd for registrada em nosso /
var/log/messages. Como estamos utilizando a
opção de ação pipe, a mensagem registrada sera
enviada como entrada do programa mail,
portanto enviada juntamente com o email ao
superusuário para pronta análise.
Pela segunda regra de nosso arquivo, quando
um usuário qualquer tentar conectar-se ao
servidor ftp proftpd local com um usuário
inexistente no sistema, um email será
também enviado ao superusuário
contendo o registro para análise.
A última linha de nosso arquivo
exemplo de configuração simplesmente diz ao
LogSurfer para ignorar quaisquer outros registros
de nosso arquivo de logs. Como puderam
perceber também, utilizei aspas simples para
delimitar o primeiro campo das 2 primeiras
regras, aspas duplas para delimitar as opções
da ação pipe e o caracter escape para poder
utilizar aspas duplas dentro de um campo
delimitado por aspas duplas como explicado
anteriormente.
Comentei nesse artigo que outras instâncias
do LogSurfer poderiam ser executadas
analisando diferentes arquivos de log de
seu sistema ao mesmo tempo.
Poderíamos por exemplo criar uma
configuração para executar uma
instância específica para os logs do
servidor DNS Bind:
——————————————
## Arquivo exemplo comentado logsurfer-BIND.conf
# Ignoramos algumas mensagens comuns
‘named.*IN MX. points to a CNAME’ - - - 0 ignore
‘named.*starting’ - - - 0 ignore
# Nesse caso ativamos um script qualquer de exemplo que funcione como pager,
# enviando a um celular ou email uma notificação
‘^.{16}(.*) named\[([0-9]+)\]: Ready to answer queries’ - - - 0
exec “/bin/pager.sh \”Servidor DNS iniciado\””
# No caso abaixo uma notificação será enviada ao hostmaster via email quando
# uma zona DNS não estiver sendo encontrada.
‘^.{16}(.*) named\[([0-9]+)\]: db_load could not open: (.*): No such file or directory’ - - - 0
pipe “/bin/mail hostmaster -s \”Arquivo de zona DNS apagada ou não encontrada
\””
# Registramos também requisições negadas pelo nosso servidor e utilizamos o
# script perl externo reportmailer para enviar a notificação ao hostmaster
‘^.{16}(.*) named\[([0-9]+)\]: denied (.*) from \[(.*)\].*for \”(.*)\”.*’ - - - 0
open “$5” - 5000 600 180
report “/bin/reportmailer -r hostmaster -S \” $5\”” “$5”
# Mais uma vez utilizamos o script perl reportmailer para enviar uma notificação
# de um erro gerado por uma recusa a um arquivo de zona DNS
‘^.{16}(.*) named\[([0-9]+)\]: master zone \”(.*)\”.*rejected due to errors \(serial (.*)\)’ - - - 0
www.linuxsecurity.com.br
24
report “/bin/reportmailer -r logsurfer -S \”DNS zone $4 serial $5 broken on $2\”” “$2 named\\[$3\\]”
# Ignoramos outros registros
‘named\[[0-9]+\]’ - - - 0 ignore
O script Perl utilizado acima, assim como o script pager.sh são apenas exemplos ilustrativos
para demonstrar que outros programas externos e com mais opções
e parâmetros podem ser utilizados:
—————reportmailer—————
#!/usr/bin/perl
use Getopt::Std;
getopts(“S:r:”);
my $SUBJECT = $opt_S if defined $opt_S;
my $RECIPIENT = $opt_r if defined $opt_r;
open OUTFILE, “|/usr/sbin/sendmail $RECIPIENT ;
print OUTFILE “Subject: $SUBJECT\n\n”;
while (<>) {
print OUTFILE $_;
}
——————pager.sh———————
#!/bin/bash
SMSEMAIL=”[email protected]” #email para celular
echo $1 | /bin/mail -s ‘LogSurfer Pager’ $SMSEMAIL
Como disse, esses são exemplos extremamente
simples perante o real poder do LogSurfer, mas
já servem como bom ponto de partida. Outros 2
exemplos com maior complexidade podem ser
acessados através do site do próprio projeto em:
ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer/
config-examples
Espero que o artigo tenha sido de alguma forma
útil e que tenha despertado o desejo do leitor
em procurar novas fontes de informação a
respeito. Fico a disposição para eventuais
dúvidas e/ou sugestões e volto na próxima edição
de nossa revista com mais dicas para o
enriquecimento de seus logs e facilidade de
auditoria/análise.
Obrigado a todos pela atenção e pelo tempo
gasto na leitura desse documento.
FICHA
do
AUTOR
Forte abraco...
www.linuxsecurity.com.br
25
Nome:
Renato Murilo Langona
Idade: 22
Profissao: Analista/Consultor de
Seguranca da Informação
Empresa: LinuxSecurity Brasil
Solutions S/C Ltda.
Email:
[email protected]
Site:
http://www.linuxsecurity.com.br
www.linuxsecurity.com.br
26
ARTIGO
Sumário
SPAM
SPAM xx qmail
qmail
SPAM x qmail
falha de segurança no qmail e, por incrível que
pareça, ninguém achou nada ainda. A versão
atual do qmail é a 1.03 de 1998, isso nos dá
uma grande sensação de estabilidade deste
grande MTA.
Introdução
A
palavra SPAM na verdade é uma marca
de presunto enlatado que se popularizou
num programa de TV, onde Vikings pediam
repetidamente presunto enlatado da marca
SPAM.
Cada processo do qmail roda apenas com as
permissões que realmente necessita, evitando
assim que algum processo rode como root
desnecessariamente.
Porém, na internet, SPAM são e-mails que
recebemos e não são solicitamos, normalmente
fazendo propaganda de um produto ou serviço,
falando mal de alguma pessoa, propaganda de
sites pornográficos, corrente, pirâmide...
Para maiores informações sobre a segurança do
qmail visite o site: http://cr.yp.to/qmail/
guarantee.html
Estes e-mails sempre são enviados não apenas
para você mas para várias pessoas (muitas
vezes milhões). Como resultado disso tudo,
temos nossas caixas postais cheias de “lixos”e
além disso para nós, administradores de
sistemas, servidores de e-mails lotados, gerando
tráfego desnecessário.
Estrutura do qmail
O qmail é modular e possui vários programas
que o gerenciam. Na figura abaixo veremos cada
um deles e a suas principais funções.
Neste artigo ,irei abordar como filtrar estas
mensagens e também como prevenir que nosso
servidor de e-mail seja usado para enviar um
SPAM.
Por que qmail ?
Discutir qual MTA (Mail Transfer Agent) é melhor
é como discutir política ou futebol, cada um vai
defender o que mais gosta.
Mas a escolha do qmail foi por ele ser um MTA
totalmente modular e principalmente seguro.
Para se ter uma idéia da segurança do qmail, o
seu autor Dan Bernstein ofereceu em março de
1997 500 dólares para quem descobrisse alguma
www.linuxsecurity.com.br
27
qmail-smtpd - É o daemon que escuta
(auxiliado pelo tcpserver ou inetd) na porta
25 (smtp) para receber as mensagens.
qmail-inject - É o programa responsável
pela entrada de um e-mail no qmail atravéz
de linha de comando.
qmail-queue - É o programa responsável
pelo gerenciamento da queue (fila).
qmail-send - É o programa responsável
pela entrega dos e-mails.
qmail-rspawn - É o programa que gerencia
as entradas remotas (MX externos).
qmail-lspawn - É o programa que gerencia
as entregas locais (caixas dos usuários).
qmail-remote - É o programa que faz a
entrega propriamente dita do e-mail
remoto.
qmail-local - É o programa que faz a
entrega do e-mail localmente (caixa dos
usuários).
Digamos que queremos liberar RELAY para os
IPS 192.168.0.X e 192.168.5.2, neste caso
teríamos que colocar no nosso /etc/tcp.smtp o
seguinte:
192.168.0.:allow,RELAYCLIENT=””
192.168.5.2:allow,RELAYCLIENT=””
Logo após teríamos que gerar o cdb:
# tcprules /etc/tcp.smtp.cdb /etc/tcp.tmp
< /etc/tcp.smtp
E colocarmos no nosso tcpserver o parâmetro -x
/etc/tcp.smtp.cdb
# tcpserver -x /etc/tcp.smtp.cdb -u 81 -g
82 0 smtp /var/qmail/bin/qmail-smtpd &
Parece um pouco confuso no
começo, mas na verdade
se formos analisar é
extremamente simples e
funcional. É importante
nós entendermos
como
o
qmail
funciona,
para
futuramente no artigo
entendermos como
funciona
cada
software.
Feito isso todos os e-mails que vierem de
192.168.0.X ou 192.168.5.2 terão o RELAY
liberados.
OBS: Se você omitir o parâmetro -x no tcpserver
e não instalar nenhum software que abra o
RELAY ,o qmail tem como padrão o RELAY
fechado.
A configuração do qmail é feita em arquivos
normalmente localizados no diretório /var/qmail/
control. Existem alguns arquivos por padrão no
qmail que podem nos ajudar a bloquear SPAM.
RELAY no qmail
São eles:
/var/qmail/control/badmailfrom - Neste arquivo
podemos listar e-mails que queremos que o qmail
rejeite. Se omitido o usuário, ele considera o
domínio inteiro:
O controle de RELAY no qmail é feito pela
variável RELAYCLIENT, normalmente setada no
arquivo /etc/tcp.smtp que depois de transformado
em formado CDB é passada como parâmetro
para o tcpserver através do opção -x.
# cat /var/qmail/control/badmailfrom
[email protected]
Vamos ver um exemplo:
www.linuxsecurity.com.br
28
Feito isso altere a linha do seu tcpserver ou inetd
para o qmail-smtpd receber 3 parâmetros:
[email protected]
@dominio.com
# tcpserver -x /etc/tcp.smtp.cdb -u 81 -g
82 0 smtp /var/qmail/bin/qmail-smtpd
meu_hostname meu_sofware_de_auth
patch_do_binario_true &
/var/qmail/control/concurrencyremote - Este
arquivo normalmente não está no diretório
control, terá que ser criado. Caso não exista o
arquivo, o valor padrão é 20, ou seja , o qmail
limitará em 20 entregas de e-mails remota
simultâneas. Se você quiser mudar este valor
para 80 por exemplo faça:
# tcpserver -x /etc/tcp.smtp.cdb -u 81 -g
82 0 smtp /var/qmail/bin/qmail-smtpd
mail.gamk.com.br /var/vpopmail/bin/
vchkpw /usr/bin/true &
# echo 80 > /var/qmail/control/
concurrencyremote
OBS: Neste exemplo foi usado o qmail
com vpopmail http://www.inter7.com/
vpopmail que é um software muito bom
para um servidor com vários domínios.
OBS2: /usr/bin/true é o patch do arquivo
em *BSD, verifique a localização do seu
(no Linux normalmente fica em /bin/true).
Mas como você pode ver no qmail ,por padrão,
você não tem muitas opções para bloquear
SPAM, para melhorar isso existem vários
softwares, que veremos logo a seguir.
qmail-smtpd-auth
Caso você use realmente o vpopmail, você terá
que ajustar as permissões do binário vchkpw
para:
Este software realiza o trabalho de autenticação
de usuários no SMTP para enviar e-mail.
Para obter este patch entre em: http://
members.elysium.pl/brush/qmail-smtpd-auth/
# chmod 4755 /var/vpopmail/bin/vchkpw
# chown root.wheel /var/vpopmail/bin/
vchkpw
Este pacth possui suporte auth do tipo: LOGIN,
PLAIN, CRAM-MD5.
A versão atual do patch é a 0.31. Para instalar
siga as instruções:
OBS: O grupo do root em sistemas *BSD
é o wheel. Caso esteja usando Linux altere
para root.
# cp README.auth base64.h base64.c ../
qmail-1.03
# patch -d ../qmail-1.03 < auth.patch
Feito isso qualquer usuário de qualquer lugar
da internet vai ter acesso ao envio de e-mails
usando o seu SMTP se fizer a autenticação com
o seu usuário e senha.
Feito isso recompile o seu qmail (desligue o qmail
antes se estiver rodando):
Vpopmail com suporte a liberação de RELAY
após auth no POP3
# cd ../qmail-1.03
# make setup check
www.linuxsecurity.com.br
Esta é outra funcionalidade interessante se
usarmos qmail junto com o vpopmail.
29
Na hora de compilar o vpopmail use as opções
(./configure):
•
Limitar o máxido de recepients por
mensagem
—enable-roaming-users=y —enable-relay-clearminutes=60
•
Controle de RELAY por IP, dominio e Mail
From.
Logo após adicione no cron para rodar de minuto
em minuto o binário: clearopensmtp
Você pode encontrá-lo na página: http://
www.fehcom.de/qmail/qmail_en.html. A versão
atual é a 1.8.0.
E no tcpserver coloque o parâmetro -x /var/
vpopmail/etc/tcp.smtp.cdb
Neste caso os usuários que fizerem auth via
POP3 terão 60 minutos de RELAY aberto, no
SMTP.
Para instalar o
SPAMCONTROL:
Copie o tgz do SPAMCONTROL para dentro do
source do qmail e descompacte-o.
Logo após execute ./spamcontrol.sh. Feito isso
os patchs serão aplicados.
Agora basta recompilar o qmail ou apenas o
qmail-smtpd novamente usando “make setup
check”.
Feito isso o SPAMCONTROL será instalado no
seu qmail e ele irá alterar inclusive os man pages.
Para maiores informações sobre as novas
variáveis que o spamcontrol criou, no qmail digite
“man qmail-control”.
SPAMCONTROL
Como eu falei anteriormente, a maioria das
configurações do qmail é feita no diretório control
com o SPAMCONTROL. Não podia ser diferente.
Para bloquear e-mails nós temos os bad* files:
SPAMCONTROL é um patch
também para o qmail-smtpd
desenvolvido por Erwin Holffmann,
que uniu vários patchs de diversos autores e
fez um grande patch, com várias funcionalidades
anti-spam para qmail. Na minha opinião o melhor
patch para qmail.
/var/qmail/control/badmailfrom - Neste arquivo
não alterou nada. Continua o padrão do qmail
/var/qmail/control/badrcptto - Neste arquivo
colocaremos os recepients que queremos
bloquear (lembre-se que pode colocar domínios
também).
Este patch aplica ao qmail-smtpd varias
funcionalidades, como:
•
Suporte a filtrar from e to com regex
•
Suporte a checagem de DNS no mail from
•
Suporte a tarpit
•
Os bad* lista recebem o KILL da conexão
TCP na hora
www.linuxsecurity.com.br
/var/qmail/control/badmailpatterns - Igual ao
badmailfrom só que neste arquivo você pode
usar Wildcards (*,!,[]).
30
/var/qmail/control/badrcptpatterns - Igual ao
badrcptto só que neste arquivo você pode usar
Wildcards (*,!,[]).
tcpserver). Com isso você poderá definir que
algumas redes não farão checagem de DNS e
outras sim. Se você quiser que apenas em alguns
domínios não seja feita a checagem de DNS,
coloque estes dominios no arquivo /var/qmail/
control/nodnscheck.
Estes arquivos listados acima quando forem
negar uma mensagem negarão na porta com
a mensagem de erro e haverá corte da
conexão TCP imediatamente.
Com o SPAMCONTROL podemos controlar o
RELAY de várias maneiras (por IP, dominio e
por Mail from).
Outra grande funcionalidade do
SPAMCONTROL é o suporte a tarpiting,
isso é, você define quantos “rcpt to” um email pode ter e depois que ultrapassar este
numero, ele começará a ter um delay definido
num arquivo de configuração para pedir o
próximo comando, fazendo com que se uma
pessoa quiser enviar um SPAM para 150 pessoas
quando passar de 10 (exemplo) as próximas (de
11 a 150) ficarão muito lentas para o SMTP
aceitar, fazendo com que a pessoa desista
(normalmente).
Os arquivos de configuração são:
/var/qmail/control/mailfromrelay - Controle de
RELAY baseado no Mail From
/var/qmail/control/relaydomains - Controle de
RELAY baseado no Domínio
/var/qmail/control/relayclients - Controle de
RELAY baseado no IP do Cliente.
OBS: no relaydomains você tem que
colocar o dominio e um : (dois pontos) no
final, por exemplo: “gamk.com.br:” (um
por linha).
/var/qmail/control/tarpitcount - Numero de “rcpt
to” para começar a ficar lento (Default: 0) . 0
significa ilimitado.
Como vocês puderam observar ,o
SPAMCONTROL é um patch completo para o
controle de SPAM no qmail, além dessas
funcionalidades apresentadas no artigo, existem
algumas outras que você poderá encontrar no
arquivo README.spamcontrol presente no
source do SPAMCONTROL.
/var/qmail/control/tarpitdelay - Delay em
segundos para aceitar o próximo “rcpt to”
(Default: 5).
Outra opção interessante que o SPAMCONTROL
implementa e que pode ser usada juntamente
com o tarpiting é limitar o número máximo de
recipients por mensagem, na variável /var/qmail/
control/maxrecipients.
qmail-filter
O qmail-filter é um filtro de e-mails para qmail
desenvolvido pelo grande amigo Rodrigo P.
Telles. Ele foi escrito em AWK e a sua versão
atual é a 1.0.4. Você pode obtê-la na página http:/
/qmail.linuxsecurity.com.br
Eu normalmente uso tarpitcount com 20
tarpitdelay de 5 e maxrecipients com 40.
Neste caso, a partir de 20 pessoas o qmail irá
começar a fazer um delay de 5 segundos para
pedir o próximo e a partir de 40 ele negará o
envio da mensagem.
Este software trabalha entre o qmail-smtpd e o
qmail-queue, bloqueando os e-mails na porta,
nem chegando a entrar na queue (fila).
Por padrão temos vários filtros (por Subject) de
vírus, algumas extenções de arquivos e alguns
arquivos perigosos. Obviamente estes filtros
Checagem de DNS com o SPAMCONTROL é
padrão. Se você quiser desabilitar configure a
variável NODNSCHECK no seu tcprules (-x
www.linuxsecurity.com.br
31
poderão ser alterados facilmente editando o
arquivo qmail-filter.awk. Além disso, junto com
o qmail-filter acompanha o virus-total.awk que
oferece algumas estatísticas dos e-mails
barrados (baseado nos logs do qmail-filter).
A instalação é muito simples basta executar o
comando ./install, o programa fará algumas
perguntas (em português) e pronto!! ele será
instalado.
Como ele barra os e-mails na porta, ele retorna
um erro para o cliente. Este erro pode ser
personalizado. Leia o arquivo INSTALL que
acompanha o source do qmail-filter para saber
como fazer isto.
Além disso, junto com source do qmail-filter
existe um arquivo chamdo FILTERS com
instruções de como criar novos filtros (em
português).
O qmail-filter é uma execelente ferramenta que
filtra através de Subject e arquivos anexados
em e-mails, porém por possuir um código
simples, pode ser facilmente alterado para filtrar
outras coisas.
FICHA
do
AUTOR
SPAM é coisa séria e hoje em dia na intenet é
um modo de propaganda fácil e barata mas que
muitas vezes incomoda várias pessoas. O qmail
possui várias ferramentas para prevenir isto.
Entre na página oficial do qmail http://
www.qmail.org que você encontrará uma gama
de ferramentas úteis e alguma com certeza o
agradará.
Espero ter sido útil neste artigo simples que
pretendeu mostrar algumas maneiras de se
proteger contra SPAM e proteger o seu servidor
de ser usado para envio.
Eu pessoalmente uso a solução qmailfilter+SPAMCONTROL. Verifique qual lhe
agrada e começe a se proteger desse mal.
www.linuxsecurity.com.br
Nome:
Diego Linke - GAMK
System/Network Administrator
Curitiba - Parana - Brazil
e-mail: [email protected]
Web Site: http://www.gamk.com.br
Phone Number: (+5541) 9967-3464
32
ARTIGO
Sumário
Saudosa Malloca, Malloca Querida ...
Izar Tarandach, Junho ’02, (c)LinuxSecurity Brasill
O
conceito de seguranca faz parte e
todos os estágios de desenvolvimento
de software. Em artigos anteriores em
minha coluna no site da LinuxSecurity (http://
www.linuxsecurity.com.br), abordei alguns destes
estágios e as estratégias e ferramentas utilizadas
para diminuir a possibilidade de bugs no produto
final.
O planejamento do sistema deve incluir o
fator segurança, e o código-fonte deve ser
revisado automaticamente por ferramentas
especializadas e a mão por colegas que possam
encontrar problemas de lógica e maior
complexidade do que as opções automáticas
Passado o momento da compilação, nos
restam ainda algumas tarefas, em se tratando
tanto de segurança quanto de boas práticas de
programação, como por exemplo estarmos certos
de que o programa pode sobreviver ao “teste do
gorila”, e de que não existem problemas de
memória, que podem trazer problemas a longoprazo, no caso de servidores que apresentem
vazamento de memória ou, a curto, no caso de
buffer overflows e outros possíveis problemas
ligados a entrada de dados não verificados.
Na maioria das vezes, erros simples são
encontrados rodando o programa, utilizando
entradas pré-definidas que provem a correção
do mesmo, quando a saída esperada é recebida.
No caso de algum problema, debugadores e
comandos de impressão espalhados pelo
programa ajudam e são, normalmente,
suficientes.
Infelizmente, este tipo de debug implica
que a presença e a natureza do bug são
conhecidas, e que o programador tem algum
conhecimento da operação de um debugger (que
pode ser complexo, em alguns casos - por
exemplo, adb).
www.linuxsecurity.com.br
Assim, uma das melhores ferramentas
que podem ajudar o programador neste estágio
do processo é o runtime-debugger, e este é o
assunto que eu gostaria de abordar neste artigo.
Programas tem basicamente quatro tipos
de usos para memória: variáveis globais,
variáveis
locais,
memória
alocada
dinamicamente e memória partilhada.
As variáveis globais e locais podem
apresentar problemas, as primeiras quando
utilizadas sem inicialização prévia (“lixo” na
variável), e as seguintes por estarem presentes
no stack. Nesta categoria o problema se
apresenta na maior parte das vezes como
memória alocada dinamicamente.
Alguns dos erros mais comuns quando se
utiliza memória dinamicamente alocada são
buffer overflows (tenta-se escrever após o fim
do segmento alocado) e underflows (tenta-se
escrever antes do começo do segmento
alocado).
FICHA
do
AUTOR
Nome Completo:
Izar Tarandach
Idade: 34 anos
Profissão: Diretor de Engenharia e
Tecnologia
Empresa: Aduva Ltd.
E-mail: <[email protected]>
http://www.aduva.com/~izar
33
O programa sai com um SIGSEV, uma falta
de segmentação, já que tenta acessar uma pagina de memória que não foi alocada pelo malloc.
O resultado é a parada total do programa, na
maioria dos casos, e em alguns casos específicos, a possibilidade de se inserir código malicioso dentro da execução do binário em questao,
com os resultados conhecidos.
O uso de “debuggers de malloc”, como
efence, libsafe e soluções comerciais como
Insure e Purify nos permitem isolar este tipo de
erro e outros, antes deles se tornarem perigosos
demais.
void foo(char *bar) {
char baz[10];
strcpy(baz,bar);
}
Se a funcao foo for chamada com argumento “abcdefghijklmnopqrs” vai provocar um buffer
overflow, já que a variável baz, que deverá receber uma cópia do argumento, só tem lugar para
10 caracteres (9+NULL de terminação):
Assim, se o programa for rodado
usando libsafe, o resultado sera ligeiramente
diferente:
Starting program: /home/izar/./foo
Breakpoint 1, main () at foo.c:8
8
foo(“aaaaaaaaaaaabcdefghijklm”);
(gdb) s
foo (bar=0x80484a8 ‘a’ <repeats 12
times>,”abcdefghijklm”) at foo.c:4
4
strcpy(baz,bar);
(gdb) n
5
}
(gdb) p baz
$1 = “aaaaaaaaaa”
(gdb) n
izar@milfalcon ~ > setenv LD_PRELOAD /lib/
libsafe.so.2
izar@milfalcon ~ > ./foo
Detected an attempt to write across stack
boundary.
Terminating /home/izar/foo.
uid=501 euid=501 pid=1635
Call stack:
0x400175d5
0x4001770f
0x8048410
0x804842e
0x4004b27b
Overflow caused by strcpy()
Killed
Até aqui, tudo bem. O programa foi executado, a cópia da cadeia foi feita e, por ser o gdb
um debugger bastante “esperto”, a variável baz
é mostrada como tendo apenas 10 vezes a letra
“a”. Porém:
A vantagem inerente ao uso de libsafe é
que não requer uma recompilaçã do codigo para
fazer o debug. Basta informar ao carregador de
bibliotecas dinâmicas que estaremos fazendo
uso do libsafe via o uso de setenv em tcsh ou
“export LD_PRELOAD=/usr/lib/libsafe.so.2” em
bash. A variável de ambiente LD_PRELOAD
informa ao carregador que a biblioteca em
questão deve ser carregada antes de quaisquer
outras, efetivamente possibilitando um “override”
de funções específicas. Isto é exatamente o que
o libsafe faz, sobrecarregando aquelas funções
main () at foo.c:10
10
}
(gdb)
0x4003c3ce in _dl_pagesize () from /lib/
libc.so.6
(gdb)
Single stepping until exit from function
_dl_pagesize,
which has no line number information.
Program received signal SIGSEGV ,
Segmentation fault.
0x4003c448 in _dl_pagesize () from /lib/
libc.so.6
www.linuxsecurity.com.br
34
conhecidas como problemáticas, que recebem
espaços de memória e efetuam operações como
cópia sem checar as fronteiras (strcpy, strcat,
gets, scanf...etc.).
Uma vez que o programa chama a rotina,
a versão provida pelo libsafe é usada. Essa
versão provê uma guarda mais detalhada dos
espaços de memória, e como visto no exemplo,
pode dar uma indicação mais específica do local
do erro.
Outra vantagem do uso de libsafe é a
escrita nos logs de quaisquer violações. Se você
tiver um servidor que esteja sob suspeita de ser
vulnerável a ataques via buffer overflow, é
possivel receber uma mensagem cada vez que
uma tentativa ocorrer:
Outra opção interessante é efence. O
uso é um pouquinho mais complicado, mas as
opções são mais flexíveis. O projeto é fruto do
trabalho do “desconhecido” Bruce Perens.
Esta biblioteca pode ser usada tanto
estaticamente, compilada dentro do programa (/
usr/lib/libefence.a na linha de compilação) quanto
dinamicamente utilizando o mesmo mecanismo
de setenv/export explicado acima.
Uma vez que se incluiu a biblioteca com
um destes métodos, resta rodar o programa em
um debugger - do contrário, teríamos que rodar
o programa, receber um arquivo core e então
sim rodar o debugger. Como arquivos core
podem ser muito grandes, vale a pena começar
o processo desde o debugger.
[root@milfalcon izar]# more /var/log/secureJun 25
12:26:27 milfalcon libsafe.so[1635]: 2.0.13
Jun 25 12:26:27 milfalcon libsafe.so[1635]: Detected
an attempt to write across stack boundary.
Jun 25 12:26:27 milfalcon libsafe.so[1635]:
Terminating /home/izar/foo.
Jun 25 12:26:27 milfalcon libsafe.so[1635]: uid=501
euid=501 pid=1635
Jun 25 12:26:27 milfalcon libsafe.so[1635]: Call stack:
Jun 25 12:26:27 milfalcon libsafe.so[1635]:
0x400175d5
Jun 25 12:26:27 milfalcon libsafe.so[1635]:
0x4001770f
Jun 25 12:26:27 milfalcon libsafe.so[1635]:
0x8048410
Jun 25 12:26:27 milfalcon libsafe.so[1635]:
0x804842e
Jun 25 12:26:27 milfalcon libsafe.so[1635]:
0x4004b27b
Jun 25 12:26:27 milfalcon libsafe.so[1635]: Overflow
caused by strcpy()
izar@milfalcon ~ > gcc -g -o foo foo.c
izar@milfalcon ~ > setenv LD_PRELOAD
libefence.so.0.0
izar@milfalcon ~ > gdb ./foo
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce
Perens <[email protected]>
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show
warranty” for details.
This GDB was configured as “i386-mandrake-linux”...
(gdb)
Na primeira linha da execução do gdb
pode-se ver a mensagem “ElectricFence 2.2.0...”,
indicando que a biblioteca foi incluida com exito.
Se isto nao for suficiente, é possivel
recompilar a libsafe com a opção de enviar email
com a notificação do problema cada vez que este
ocorrer. A documentação da biblioteca tem todos os detalhes necessários. Libsafe pode ser
encontrada em:
http://www.research.avayalabs.com/project/
libsafe/index.html.
www.linuxsecurity.com.br
(gdb) run
Starting program: /home/izar/foo
[New Thread 1024 (LWP 3744)]
35
Antes da execução do programa,
podemos utilizar as variáveis de ambiente
EF_PROTECT_FREE e pedir que o efence gere
uma exceção no caso de acesso a memória
previamente retornada ao sistema.
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce
Perens <[email protected]>
Program received signal SIGSEGV, Segmentation
fault.
[Switching to Thread 1024 (LWP 3744)]
0x400b4869 in strcpy () from /lib/libc.so.6
Modificando mais uma vez nosso foo.c:
Aqui pode-se ver o efence avisando onde
o erro ocorreu.Sem o efence, a mensagem seria:
char * foo(char *bar) {
char *baz = (char *)malloc(10*sizeof(char));
(gdb) run
Starting program: /home/izar/foo
strcpy(baz,bar);
return baz;
}
Program exited with code 0110.
(gdb)
main() {
char *ptr = foo(“abcdefghi”);
free(ptr);
strcat(ptr,”foo”);
O programa nem mesmo apresenta o erro!
Para falar a verdade, tive de dar uma
“ajeitada” no programa para que o efence
soubesse lidar com ele. A linha char baz[10] foi
modificada
para
char
baz=(char
)malloc(sizeof(char)*10)); para que o efence
pudesse interceptar a alocacao de memória!
Caso contrário, o erro não teria sido encontrado.
Isso é facilmente explicado apos examinar
a construção das duas soluções: libsafe faz um
sobrecarregamento das funções problemáticas,
enquanto o efence é focado no uso de malloc.
Na minha opinião, a melhor solução seria um
trabalho conjunto com as duas soluções.
Alguns outros erros comuns são a
tentativa de se acessar memória que foi
previamente
retornada
ao
sistema
(programadores C, memória que allocada com
malloc, é retornada com free; programadores
C++, memoria inicializada com new, é retornada
com delete) e a escrita para um ponteiro que
contenha zero. Enquanto a leitura da locação
zero é legal, porém indefinida, a escrita gera uma
exceção na unidade de processamento de
memória, normalmente parando o program com
um segmentation fault.
No primeiro caso, o desempenho do
efence é mais acentuado.
www.linuxsecurity.com.br
}
Uma vez compilado e rodado o programa
sem efence, nada deve ocorrer. Porém, se
compilarmos com efence, e setarmos a variável
EF_PROTECT_FREE para 1, veremos:
(gdb) run
Starting program: /home/izar/./foo
[New Thread 1024 (LWP 3945)]
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce
Perens <[email protected]>
Program received signal SIGSEGV, Segmentation
fault.
[Switching to Thread 1024 (LWP 3945)]
0x400b3893 in strcat () from /lib/libc.so.6
O problema em strcat foi achado e
assinalado para correção. Da mesma maneira,
pode-se utilizar EF_PROTECT_BELLOW para
assinalar problemas de buffer underrun, quando
a memória for acessada abaixo do espaço
reservado, EF_ALLOW_MALLOC_0, para deixar
36
de assinalar a chamada de malloc com zero como
argumento, e EF_FILL, que preenche a memória
alocada com o valor da variável, com o intuito
de interceptar a leitura de memória não
inicializada.
“ rodar
o programa, tanto sob
debugger como livre
“testar o programa para uso de
variáveis não-inicializadas
“testar o programa para uso de
ponteiros com valor zero
“ testar
o programa para
vazamentos de memória
(memória
alocada
não
retornada ao sistema)
Existe um pequeno problema de conflito
entre o alinhamento de memória usado por
malloc e a maneira como o efence acha erros.
Para um tratamento mais detalhado deste
problema, indico ao leitor a página manual do
efence (‘man efence’).
Em conclusão, o conceito de debugging
do uso de memória como um dos passos finais
antes de considerar o projeto “acabado” deve ser
visto como imprescindível. A metodologia a ser
utilizada é bastante simples. Este é um exemplo
não exaustivo, e ainda há mais testes a serem
incorporados:
Neste artigo não abordamos o
fator de vazamento de memória, já que o mesmo
é mais um problema de performance do que de
segurança, porém a mesma classe de
ferramentas aqui apresentada pode ser usada
para encontrar problemas do tipo. Por exemplo,
a ferramenta memprof pode ser muito útil neste
caso.
“Black-box testing (não-intrusivo)
“fazer
o “teste do gorila” - jogar
lixo como entrada não
estruturada para o programa, e
ver como se comporta
“ mapear todas as possíveis
entradas de dados do programa
(linha de comando, network,
pipes, dados vindos de outros
programas)
“ prover a entrada estruturada,
porém utilizando tamanhos
variáveis e exagerados de
campos, enquanto o programa
roda sob um debugger de uso
de memória
“checar que a saída do programa
não seja “suja”, caso esta seja
utilizada como entrada em
algum outro programa
Em caso de dúvidas, reclamações e
caixas de garrafas de cerveja, meu email está a
disposição. Alguns ponteiros para mais
ferramentas que tratam de uso de memoria:
“gcc com checagem de memoria http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
“FDA - http://packages.debian.org/unstable/
devel/fda.html
“NJAMD - http://fscked.org/proj/njamd.shtml
“White-box testing (intrusivo)
“recompilar
o programa com uma
biblioteca com checagem de
erros de memória
www.linuxsecurity.com.br
37
www.linuxsecurity.com.br
38
ARTIGO
Sumário
FingerPrint
FingerPrint - Explorando a pilha TCP/IP (versão 1.0)
T
raduzindo mais ao pé da letra fingerprint
seria a impressão digital, literalmente o
polegar na tinta, mas no mundo
underground essa expressão tem um valor
especial. Seria a exploração da pilha TCP/
IP para definir o S.O. de um respectivo
host. Sendo notório essa
identificação para o invasor ter
sucesso na utilização de um
respectivo exploit, sendo que o
invasor tem em mente que ao ter
em mãos um exploit funcional
para um serviço de um
respectivo sistema operacional
ele terá uma única oportunidade
que poderá lhe permitir “rootiar”
a máquina, dessa forma uma
investida falha poderá tirar o
serviço do ar e/ou ainda chamar
atenção do administrador.
com SNMP habilitado e configurado de forma
padrão com “comunidade publica” e
utilizando ferramentas como snmpwalk ou até o
languard.
Outra forma clássica de FingerPrint é a
manipulação de datagrama ICMP, um
exemplo dessa técnica é a resposta
de icmp tipo 8 (echo request), cujo
padrão é icmp tipo 0 (echo replay),
em que a partir do valor do campo
TTL da resposta é possível, em muitos
casos, determinar o sistema
operacional da máquina, pois mesmo
seguindo RFCs, muitos fabricantes
acabam criando particularidades na
implementação da pilha TCP/IP de seu
sistema, devido a não definição
específica para certos padrões de
resposta. Dessa forma tem-se um novo
cenário interessante, onde com um
inocente ping, o invasor pode executar um
FingerPrint. Veja na tabela abaixo alguns
exemplos:
Todavia, de forma generalizada,
podemos englobar qualquer técnica
que defina o sistema operacional como um
FingerPrint, dessa forma podemos começar
aentender essa técnica e seu objetivo através de
um exemplo básico que é a
artimanha trivial de leitura de banners, em que
por exemplo através do comando comumente
conhecido como telnet, o invasor faz uma conexão
para uma dada porta de serviço, digitando um
comando específico ou uma seqüência de
caratecteres sem sentido para provocar um erro
e retornar o banner ou informações que possam
ser analisadas.
Sistemas que retornam valor 30 para ICMP tipo 8
- Roteador Cyclades PR2000
- Switches (3 Com)
Sistemas que retornam valor 32 para ICMP tipo 8
- Windows 95 (primeira versão)
Sistemas que retornam valor 60 para ICMP tipo 8
- Impressoras HP (JetDirect / LaserJet )
Uma outra possibilidade de um invasor obter não
só o FingerPrint mas também em muito casos o
footprint sem muito esforço é através de servidores
www.linuxsecurity.com.br
Sistemas que retornam valor 64 para ICMP tipo 8
- Compaq Tru64 V5.0
39
a manipulação tanto de datagramas UDP como
TCP para esse fim, sendo que as possibilidades
são maiores para esse último devido as
particularidades das pilhas TCP/IP de cada
sistema, assim os crackers buscam identificar
essas diferenças entre os sistemas operacionais
organizando-as em tabelas com cada respectivo
perfil (assinatura de comportamento) para
desenvolvimentos de programas de sondagem
(scanners) que sejam capazes de enviar uma
seqüência de pacotes pré-definida a um host e a
partir da resposta, cruzar com as informações da
tabela de assinaturas e aí sim identificar o sistema
operacional ou ainda simplesmente atuar como
um farejador (sniffer) de pacotes. Essa lógica é a
base dos scanners de Fingerprint.
- Linux Kernel 2.0.x
Sistemas que retornam valor 128 para ICMP tipo 8
- Windows 95 (segunda versão)
- Windows 98
- Windows 98 SE
- Windows ME
- Windows NT 4 Workstations SP 3
- Windows NT 4 Workstations SP 6a
- Windows NT Server SP4
- Windows 2000 Profissional
- Windows 2000 Server
- Windows XP
- Novell Netware 3.12 / 5.0 / 5.1 SP1
Sistemas que retornam valor 255 para ICMP tipo 8
- FreeBSD 3.4 / 4.0
- OpenBSD 2.6 / 2.7 / 2.8 / 2.9 / 3.0 / 3.1
- NetBSD
- BSDi
- Solais 2.5.1 / 2.6 / 2.7 / 2.8
- HP-UX
- IRIX
- AIX
- ULTRIX
- OpenVMS v7.1-2
Esses programas de fingerprinting podem ser
divididos de forma didática em três categorias de
acordo com a técnica utilizada.
Passive OS Fingerprint: seriam programas de
sondagem que ao invés de enviar uma seqüência
de pacotes atuam com sniffers capturando
pacotes de redes e, a partir da estrutura dos
datagramas, definem o sistema operacional da
máquina que os está enviando. Bons exemplos
de programas de FingerPrint que usam essa
técnica são: p0f e o Ettercap (escrito por 2
programados da Universidade de Milão,um
verdadeiro canivete suíço na mão de um insider).
Conhecendo essa tabela bastar fazer um
traceroute ou usar o mtr, observar o número de
saltos, somar e chegar no valor da TTL
correspondente.
Aticve OS Fingerprint: São scanners de fingerprint
que analisam as respostas de um respectivo host
para pacotes por ele manipulados e enviados,
sendo capazes de definir o Sistema Operacional
do host alvo, cruzando os dados com sua tabela
de fingerprint. Bons exemplos são o QUESO (sua
base é o arquivo queso.conf) e o nmap (sua base
é o arquivo nmap-os-fingerprints).
Deamon OS Fingerprint: Seriam “Acitves OS
FingerPrints” que são desenvolvidos para explorar
diretamente um serviço, um bom exemplo seria o
“telnetfp” desenvolvido pelo TESOTeam que é
capaz de fazer um fingerprint a partir de um servidor
telnet.
A partir desse exemplo podemos assumir uma
política bem restritiva a respostas ICMP, exemplo
disso é que muitos Firewalls são configurados para
não responderem a nenhuma solicitação ICMP
exceto das definidas pelo administrador.
Partindo do pré-suposto que um alvo pode ser
facilmente atingido a partir do momento em que é
localizado, fica muito mais difícil acertar em algo
que não se vê ou que não se possa alcançar.
Mas tudo o que foi mencionado até agora são
técnicas simples embora sagazes, mas o
FingerPrint vai além disso, pois ainda é possível
www.linuxsecurity.com.br
40
As técnicas são muitas, entretanto, vamos destacar
as mais utilizadas:
fingerprint mais inteligentes são capazes de
utilizarem esse valor de um datagrama , pois alguns
possuem um valor especifico como o AIX, todavia
existem outros com valores similares como por
exemplo a implementação da pilha TCP/IP da
Microsoft que possui o mesmo valor do FreeBSD
e OPenBSD. Como bons exemplos podemos citar
QUESO e o NMAP.
Investigação de FIN (FIN Probe)
-Técnica interessante que consiste no envio de
um flood de pacotes FIN para um host.
Implementações que seguem a RFC 793
detornam RST para portas fechadas e demais
devem ignorar os pacotes, mas existem
implementações da pilha TCP/IP na família
Microsoft Windows, com exceção da primeira série
da versão win/95, que respondem com RST nas
duas situações. Um dado interessante dessa
técnica é ser base das varreduras de serviço
“Nulas (pacotes TCP sem flags ativos), Arvore de
Natal (pacotes TCP com flags FIN/URG/PSH
ativos) e FIN”.
Exemplos de exploração de FingerPrint com
Nmap:
# nmap -o ip.ip.ip.ip
# nmap -O -p 119 -P0 ip.ip.ip.ip
# nmap -sS -O -p21,80 -P0 -v ip.ip.ip.ip
Investigação FALSA (BOGUS flag)
Obs.: Quando ocorrer de não haver a identificação
ainda é possível forçar com o parâmetro
“- - osscan_guess”
- Técnica bem conhecida pois foi implementada
no QUESO. Consiste em enviar um datagrama
TCP com flag de valor (64 ou 128) no cabeçalho
de um pacote TCP de inicio de conexão (bit SYN
ativo), a maioria dos sistemas operacionais
retornam um pacote RST.
# nmap -sS -P0 - - osscan_guess -p 110
ip.ip.ip.ip
Como o Nmap realiza o fingerprint ?
Padrão TCP de ISN (TCP ISN Sampling)
O arquivo nmap-os-fingerprint tem assinaturas de
vários sistemas operacionais. Esse arquivo é
continuamente incrementado com contribuições de
vários profissionais do mundo Livre, pois quando
é executado um Fingerprint e a assinatura do host
não corresponde a nenhuma do registro no arquivo
nmap-os-fingerprint, o nmap faz a saída na tela da
respectiva assinatura, dessa forma um usuário
pode encaminhar essa nova assinatura uma vez
que ele saiba qual o sistema que não fora
identificado pela ferramenta para o email do
principal desenvolvedor do nmap: [email protected]
ou submeter a informação direto no site do nmap
http://www.insecure.org/cgi-bin/nmap-submit.cgi
- Essa técnica, como o próprio nome já diz, tem
como objetivo identificar o sistema operacional a
partir do modo como eles elaboram o Número Inicial
de Seqüência, pois sistemas como Solaris, IRIX,
FreeBSD, usam um padrão de incrementação
randômica, e o sistema Windows usa um outro
modelo que esta vinculado ao horário. Antigos
modelos usados em Unix baseados em 64k eram
famosos por serem fáceis de burlar.
Janela Deslizante inicial do TCP (TCP
Initial Windows)
- Técnica que trabalha com a informação do
tamanho da janela de um pacote. Scanners de
www.linuxsecurity.com.br
41
Assinatura ?
T4(DF=N%W=0%ACK=S%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=S%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=N)
Se fomos considerar o nmap-os-fingerprint como
uma base de dados, podemos considerar cada
assinatura um registro, dessa forma seria correto
falar que cada assinatura é composta por nove
campos descrito a seguir:
- Tseq is the TCP sequenceability test
Contramedidas
- T1 is a SYN packet with a bunch of TCP options
to open port
Eliminar todos os banners ou
simplesmente alterá-los para evitar
facilitar a atividade de curiosos.
Ter políticas restritivas quanto à
resposta ICMP de sua LAN ou
Rede Periférica para Internet, em
alguns caso simplesmente negar
qualquer possibilidade.
Uma dica interessante é
que podemos manipular
no Linux o arquivo
“ip_default_ttl” cujo valor
original é 64. Mudamos para
35, isso já deixa o nmap cego
pois essa informação vai gerar
uma resposta que não
corresponde com a base de
dados de assinatura do nmap.
Sabemos que quando a exploração é
feita por scanners mais arrojados como o Nmap a
contramedida tem que ser engenhosa, à altura,
uma solução é o IP Personality , um projeto muito
interessante de path de kernel (família 2.4)
que permite habilitar diferentes “personalidades”
para a pilha TCP/IP do Linux, há mas se eu estiver
usando windows? Não conheço nenhuma solução
além de você migrar para Linux >;-).
O primeiro objetivo desse projeto é justamente ser
uma contramedida para a forma como o nmap
realiza o FingerPrint O segredo é o uso do próprio
veneno pois a simulação usa justamente a
informação da assinaturas da base do nmap, o
arquivo nmap-os-fingerprint.
- T2 is a NULL packet w/options to open port
–T3
is a SYN|FIN|URG|PSH packet w/options to
open port
- T4 is an ACK to open port w/options
- T5 is a SYN to closed port w/options
- T6 is an ACK to closed port w/options
- T7 is a FIN|PSH|URG to a closed port w/
options
- PU is a UDP packet to a closed port
Através desses campos são estruturadas a
respectivas assinaturas, não somente de Sistemas
operacionais como também de equipamentos
específicos como switches e roteadores.
Veja abaixo um exemplo de assinatura que
corresponde ao sistema operacional AtheOS.
# Contributed by “Steven Lawrance”
<[email protected]>
Fingerprint AtheOS ( www.atheos.cx )
TSeq(Class=RI%gcd=<8%SI=<A78&>6)
T1(DF=N%W=3FF0%ACK=S++%Flags=AS%Ops=M)
T2(Resp=N)
T3(Resp=Y%DF=N%W=3FF0%ACK=S++%Flags=AS%Ops=M)
www.linuxsecurity.com.br
42
Feito essa etapa estaremos definindo o cenário
para o IP Personality ser
suportado, mas ainda dependemos do Iptables e
o recurso da tabela šmangleš.
Instalando o IP Personality Patch
Baixe o path correspondente para a versão de seu
kernel, nesse documento estarei exemplificando
para o Redhat 7.2, cujo Kernel é o 2.4.7. Como
esse modulo irá ser manipulado com uma
“propriedade” especifica do IPtables,
também será necessário ter o mesmo na máquina.
Para o a versão destinada ao Kernel 2.4.7 utilize o
iptables 1.2.2 ou superior.
Uma vez que seu sistema esteja atendendo os pré
requisitos, podemos passar para a instalação do
path de kernel:
3) Aplicando o patch iptables:
$ cd iptables-1.2.2/
$ patch -p1 < o patch ( que acompanha o
pacote do IP Personality)
4) Compilando o iptables:
1) Patch do kernel:
# make
Vá para o diretório do fonte do código fonte de seu
kernel:
5) Carregando o novo modulo gerado
ppara o iptables ipt_PERS.o:
# cd /usr/src/linux
# patch -p1 < path (pacote do Ippersonality)
# insmod ipt_PERS
6) Escrevendo as políticas para tabela
“mangle” como o uso da target PERS:
2) Compile seu Kernel:
Durante a etapa de configuração (make config) será
necessário habilitar em seu kernel o suporte a
Iptables com a nova opção adicionada pelo path
aplicado:
—tweak {src|dst}: define a ação se será para
destino ou origem
—local: referindo-se que o pacote é para máquina
local necessário para
decoy (isca).
IP Personality Support (EXPERIMENTAL)
—conf <file>: define o arquivo de configuração com
a assinatura do
respectivo sistema operacional
Editando o arquivo de configuração do kernel:
CONFIG_IP_NF_PERS=y
Vide exemplo:
Caso você deseje que o IP Personality seja
suportado como modulo pelo kernel.
CONFIG_IP_NF_PERS=m
Imagine o cenário onde duas máquinas A e B,
separadas por uma máquina linux funcionando com
o roteado. Toda resposta com destino a maquina
será emulado o perfil de resposta de um sistema
AmigaOS.
Você pode utilizar ainda o “make menuconfig” indo
em “Network options/IP: Netfilter configuration/IP
Personality Support (experimental)”
# iptables -t mangle -A PREROUTING -
Compile seu kernel e habilite em seu bootload para
suporte do mesmo.
www.linuxsecurity.com.br
s B -d A -j PERS —tweak src —conf
43
Bibliografia
amigaos.conf
# iptables -t mangle -A PREROUTING -s A -d B -j PERS
—tweak dst —conf
amigaos.conf
sites:
http://ippersonality.sourceforge.net
http://www.insecure.org
http://www.sys-security.com
http://www.absoluta.org
Agora todo pacote de origem local com destino a
maquina B terá emulado o perfil de resposta do
sistema operacional Win9x, o que com certeza não
é uma boa idéia pois será motivação para tentativas
de ataques DOS !
Livros:
Hackers Expostos
Segurança Nacional
Desvendando TCP/IP
# iptables -t mangle -A PREROUTING -s B -d router -j
PERS —tweak dst —
local —conf win9x.conf
# iptables -t mangle -A OUTPUT -s router -d B -j PERS
—tweak src —local —
conf win9x.conf
FICHA
do
AUTOR
Para finalizar a configuração é necessário
incrementar o arquivo šip_conntrack_Maxš com um
valor especifico de 20480
# echo 20480 > /proc/sys/net/ipv4/ip_conntrack_max
Nome: Sandro Mello
e-mail: [email protected]
IMPORTANTE:
Para você efetuar seus testes o
interessante seria usar o nmap a partir
de outro host ou a até o osdet que é um
versão modificada justamente
para testar o IP Personality.
Atuante na área de TI desde de 1991 adquirindo
ampla visão das necessidades e peculiaridades
deste setor. Atualmente é Chief Security Office
(CSO) da 4Linux, desenvolvendo projetos de
Redes e Segurança utilizando Software Livre,
sendo responsável também por projetos de Ensino
a Distancia na mesma. Formado em Tecnologia
de Processamento de Dados pelo Mackenzie onde
também fez Pós Graduação em Analise de
Sistemas. Atualmente aluno do curso de Mestrado
em Engenharia de Redes no IPT/USP, “Membro
do ADC (Apple Developer Connection)” e do GUSoftware Livre da Sucesu São Paulo.
Esse documento é apenas um resumo, é
extremamente válida a visita ao site do projeto http:/
/ippersonality.sourceforge.net.
Bem, finalizo aqui esse artigo, só me resta
agradecer ao Renato Murilo essa oportunidade de
compartilhar meus conhecimentos.
Palestrante assíduo em vários eventos
acadêmicos e corporativos, como Comdex - SP,
Semana Paraense de Informática - Sepai (Pa),
Forum Internacional de Software Livre - RS,
Workshop de Informática do Instituto Bennett - RJ
entre tantos outros de igual importância.
QUE A FORÇA ESTEJA
CONOSCO !!!
Colaborador de matérias para revistas e jornais
como: PcMaster, Diário de São Paulo e Digital.Net
e agora LinuxSecurity Magazine.
www.linuxsecurity.com.br
44
ARTIGO
Sumário
Introdução
Introdução àà Análise
Análise Forense
Forense -- Parte
Parte 11
Introdução à Análise Forense - Parte 1
E
ste é o primeiro de uma série de artigos
em que serão introduzidos os conceitos
básicos de análise forense no âmbito dos sistemas computacionais. O objetivo é acompanhar
passo a passo as etapas do processo, permitindo
aos leitores se profundarem posteriormente se lhes
for interessante. No mínimo, pretendemos dotar os
administradores de rede do conhecimento necessário para gerar e preservar as informações que são
o substrato do trabalho do analista forense. No evento de uma invasão, mesmo não sentindo-se preparado para realizar ele mesmo a análise, saberá como
proceder para não dificultar o trabalho futuro do analista, que poderá ser um colega com mais conhecimento ou até mesmo um profissional contratado no
mercado.
nicas necessárias. Este é o contexto da análise forense, que pode ser definida como:
Análise Forense em Sistemas Computacionais é o
processo de coleta, recuperação, análise e
correlacionamento de dados que visa, dentro do
possível, reconstruir o curso das ações e recriar
cenários completos e fidedignos.
Preparando-se para a invasão
As técnicas descritas poderão ser utilizadas em
qualquer sistema, porém alguns cuidados prévios
permitem gerar e garantir a consistência de uma variedade maior de informações para a análise. O trabalho de análise, que é a parte mais trabalhosa do
processo, constitui-se principalmente do
correlacionamento de dados, portanto quanto mais
redundantes forem os dados mais fácil se torna a
Neste primeiro artigo ainda não abordaremos
o processo de análise em si. Pretendemos ilustrar
como algumas medidas simples, e outras nem tanto, podem aumentar e muito a quantidade e a qualidade dos dados a respeito do seu sistema. Ilustraremos ainda qual o procedimento adequado ao se
deparar com um sistema que se suspeita de comprometimento.
FICHA
do
AUTOR
A complexidade crescente dos sistemas
computacionais, integrando um grande número de
novas tecnologias, sistemas legados com novas
implementações, interligação dos ambientes de rede
e softwares com um número cada vez maior de linhas de código, é algo que cria o ambiente propício
para o surgimento de brechas de segurança. Por
mais capacitada e dedicada que seja a equipe de
segurança de uma empresa há sempre o risco do
comprometimento. Neste contexto é fundamental
para a continuidade dos negócios uma política de
recuperação de desastres. Além disso, em um eventual incidente, é desejável a capacidade de levantar
os acontecimentos de forma a permitir que sejam
tomadas as medidas jurídicas, administrativas e técwww.linuxsecurity.com.br
Nome Completo:
Leonardo Alcântara Moreira
Idade: 29 anos
Profissão: Engenheiro de Computação
Empresa: Montreal Informática Analista de Projetos
E-mail: <[email protected]>
45
chegada a uma conclusão e maior é o grau de
confiabilidade desta. Em seguida iremos inumerar
algumas técnicas e ferramentas úteis no processo:
HIDS no estado do sistema e arquivos de log.
A possibilidade de detecção rápida de um
ataque bem sucedido facilita o trabalho de levantamento. Quanto menos tempo o sistema estiver
sob o controle alheio menor será o seu comprometimento e mais claras estarão “as pegadas” do
intruso.
Por fim, os dados reportados pelo IDS podem dar indícios ao analista à respeito do modo
de operação do invasor, servindo para orientar sua
análise e corroborar suas hipóteses.
A utilidade dos dados do IDS dependem, no
entanto, da sua integridade, que pode estar afetada caso estes estejam gravados na própria estação como alguns IDS de host fazem por default.
Caixa de ferramentas do analista
Em um sistema comprometido tudo pode ter sido
alterado. Os arquivos de log, os binários do sistema, e até mesmo o
kernel, através do uso cada vez
mais comum dos LKM. O analista precisa ter à mão versões
confiáveis dos utilitários do sistema e das ferramentas extras
que irá utilizar no processo de coleta. Os binários
devem ter sido previamente compilados, em um
sistema asseguradamente limpo, com ligação estática. As bibliotecas de ligação dinâmica do servidor comprometido também podem ter sido alteradas. A utilização de cd-rom ou disquete dependerá principalmente da disponibilidade dos dispositivos leitores correspondentes. É preferível utilizar um cd-rom com os binários e um disquete para
a gravação da saída dos utilitários. Se os binários
estiverem contidos em um disquete é recomendado que este seja protegido contra a gravação.
O conhecimento prévio e a prática com estas ferramentas é de grande relevância. Algumas
possuem sintaxes obscuras e geram saídas pouco amigáveis aos leigos. Dada a volatilidade das
informações o aprendizado na prática pode atrapalhar o sucesso da empreitada.
Cópias de Segurança ou Backup
Peça fundamental na recuperação de um desastre, um sistema de backup bem organizado também pode ser bastante útil no processo de análise. A comparação dos arquivos antes e depois
ajuda a montar o quebra-cabeça onde algumas
peças foram perdidas, ou seja, setores do disco
foram sobrescritos.
Preservação de Logs
Uma coisa pouco comum exceto nos sistemas de alta segurança é o cuidado de arquivar os
logs fora dos servidores, de preferência fora da
rede. Comprometer um host e alterar seus logs
para apagar rastros é muito mais fácil que comprometer dois hosts que disponibilizam serviços
diferentes e portanto talvez não apresentam provavelmente a mesma vulnerabilidade. Melhor ainda se o segundo servidor nem mesmo em rede
estiver.
A solução pode se apresentar como um servidor de logs centralizado para o qual todos os
servidores redirecionam seus arquivos de log, ou
cópias destes. Pode-se acrescentar requintes para
dificultar o comprometimento deste servidor central. Este pode estar protegido por um outro
firewall, ou de outra forma.
Sistemas de detecção de intrusão.
Sem nos aprofundarmos muito em detalhes
técnicos, há basicamente dois tipos de sistemas
de detecção de intrusão, ou IDS: os baseados em
rede (NIDS) e os baseados em host(HIDS). Ambos fundamentam-se na análise do comportamento do ambiente monitorado, detectando anomalias ou assinaturas características de ataques ou
funcionamento inadequado, diferenciando-se apenas no escopo de seu monitoramento. Os NIDS
utilizam o tráfego em um segmento de rede e os
www.linuxsecurity.com.br
46
backup. RESISTA !!!
Mais que isso... saia da frente do teclado, dê uma volta no corredor, tome um
copo d’água. Certifique-se que está calmo e
sob controle antes de voltar à “cena do crime”, lembre-se que qualquer interação com
o sistema vai alterá-lo e pode sumir com dados importantes. A velocidade é importante, mas cada passo a partir de então deve
ser pensado. Lembre-se que é pouco provável que o invasor esteja realizando alguma
atividade danosa exatamente naquele momento. Boa parte dos invasores quer manter
sua discrição enquanto explora os recursos
do seu sistema ou o utiliza como base de
lançamento para outras invasões, logo estes evitarão modificar seu sistema mais que
o necessário. Os invasores que possuem instinto destrutivo provavelmente já terão conseguido causar muito dano antes que você
os note. Um rm * não demora mais que alguns minutos. Logo o pânico não ajudará em
nada.
Também pode ser utilizada a porta serial ou
paralela do computador para enviar os dados para
o servidor de logs. Não é difícil implementar esta
solução de forma a permitir o envio de dados
utilizando um driver tão simples que não oferece recursos para uma invasão.
Outra opção é a utilização de ferramentas impedindo a modificação do conteúdo dos
logs, permitindo apenas a inclusão de novos
eventos.Temos por exemplo no caso do Linux o
LIDS. Devemos lembrar no entanto que não há
garantias que esta ferramenta ou outras porções
do kernel não contenham bugs que permitam a
alguém driblar seus controles.
Independente da utilização de qualquer
uma destas soluções ou de qualquer outra que
siga as mesmas linhas, o importante é tentar
preservar ao máximo a integridade dos arquivos de log do sistema.
O grande foco deve ser sempre a preservação dos dados. E esta depende de onde
estão armazenados. Existe uma tabela que
ilustra a sua volatilidade :
Integridade de Arquivos
A utilização de um utilitário de verificação
de integridade, por exemplo o Tripwire, permite
identificar arquivos alterados, complementando
as informações levantadas através dos MAC
times
Registradores, memória cache
Memória
Estado da Rede
Processos
Disco Rígido
Disquetes, Zips, Fitas
Cd-rom, dados impressos
A invasão
Um belo dia acontece. Uma ferramenta do IDS
alarda. Um usuário reclama de algum
dado seu alterado. O administrador
encontra um arquivo estranho em
um diretório do sistema. O sistema se comporta de forma
inexplicável... De repente algum
indício leva o administrador a
procurar por outros e em minutos fica claro que o seu sistema foi invadido. E agora ?
O primeiro impulso é muito forte: reinicializar a máquina, reinstalar tudo, voltar
www.linuxsecurity.com.br
Toda operação realizada em um computador ou até mesmo o seu funcionamento normal executando as tarefas de sistema causa a modificação do seu estado. Desta forma o procedimento deve
sempre procurar salvar primeiro os dados mais voláteis.
47
A coleta
O processo de coleta é relativamente
simples e não requer nenhum grande esforco
além da atenção para evitar que se danifiquem dados importantes. Ainda assim é impossível a reconstrução perfeita de todo o
cenário.
O primeiro passo é colocar seu cd-rom
de ferramentas e um disquete em branco e
coletar as informações sobre a memória, estado da rede para arquivos no disquete.
Assim quem sabe com muita sorte você pode
até surpreender uma conexão do atacante
ou algum backdoor.
Não analise nada ainda, não perca tempo e nem o foco. Tenha disponivel um bloco
de notas e documente tudo que achar importante. Terminado este processo você deverá
ter em mãos todas as evidências, ainda em um
estado muito cru, que serão utilizadas.
A partir deste
ponto o processo é
idêntico ao de uma investigação criminal comum. Isole a área adequadamente. Para isso
retire o cabo de rede, notifique outros usuários que
possam utilizar o console da
máquina. Se precisar se ausentar coloque um aviso sobre o teclado.
No próximo artigo continuaremos analisando a utilização de algumas ferramentas que podem compor um kit básico.
A idéia é levantar o estado do sistema antes da reinicialização, pois boa parte
destas informações serão perdidas. É importante utilizar sempre um disquete para
redirecionar a saída ou copiar os dados que
interessam direto da tela para o papel. Não
escreva de forma nenhuma no próprio disco
rígido!!! Os blocos livres podem conter informações de arquivos apagados.
1
Loadable Kernel Modules.
Módulos do kernel que podem ser carregados
sob demanda quando associados a algum
recurso, ou através de utilitários de
administração. Estes módulos permitem gerar um
kernel mais compacto e flexível.
2
Intrusion Detection Systems.
3
Network Intrusion Detection Systems.
4
Host-based Intrusion Detection Systems.
5
Linux Intrusion Detection System.
Patch para o kernel do Linux que permite o
controle de acesso a recursos através de Access
Control Lists. Este módulo vem ainda com um
port scanner embutido. http://www.lids.org
6
Tripwire
É uma ferramenta que verifica a integridade de
arquivos através da comparação de informações
sobre os arquivos, tais como atributos,
assinaturas binárias, tamanho, etc.
http://www.tripwire.org
7
Registros de datas de criação, alteração
e acesso em um sistema de arquivos.
Não exagere, recolha só as informações essenciais. Cada comando que você
utiliza tem o potencial de destruir mais dados. Então evite trabalhar no sistema original.
Agora pode bootar a máquina. Retire
o disco rígido, coloque-o em outra máquina
e faça uma cópia da imagem de cada sistema de arquivos. Copie os dados, byte a byte,
para um arquivo dentro de um sistema de arquivos maior ou faça a cópia física para outro disco rígido de capacidade igual . Agora
você tem imagens nas quais poderá trabalhar, sem o risco de perder seu original. Se
possível crie um hash destas imagens para
que você possa verificar a qualquer momento a sua integridade.
www.linuxsecurity.com.br
48
ARTIGO
Sumário
TrustedBSD - A Missão...
TrustedBSD - Parte I - Introdução
O
projeto TrustedBSD foi criado com o
objetivo de adicionar uma série de
extensões de segurança ao sistema
operacional FreeBSD, tanto no nível do kernel
quanto no nível das aplicações, visando tornálo um sistema compatível com o nível de
segurança B1 segundo os critérios do NCSC
(U.S. National Computer Security Center). Um
sistema pode ser classificado em 4 níveis de
segurança, variando de D a A1, sendo
que o D é definido como sendo o
nível de segurança mínima, a
classificação de um sistema
depende do comportamento do
mesmo perante o teste
(TCSEC) de avaliação aplicado
pelo departamento de defesa norte
americano (DoD). A classificação
atual do FreeBSD é C2.
estabilidade e performance do sistema.
Para que muitas das novas features de
segurança pudessem ser implementadas, foi
necessária a criação de uma API específica, que
possibilita a associação de metadados adicionais
a um arquivo ou diretório. Esses metadados
receberam o nome de EA (Extended Attributes),
e é através deles que o conceito de ACLs foi
implementado.
Dentre
as
extensões
do
TrustedBSD
que
serão
disponibilizadas na versão 5.0 do
FreeBSD, merecem destaque as
seguintes:
Trust Management
Apesar de obtermos um sistema
relativamente seguro numa instalação
padrão
do
FreeBSD,
existem uma
serie
de
ajustes de
configuração
que podem ser
executados
para
s
e
melhorar
o nível de
segurança do servidor, tais como
desabilitar serviços desnecessários,
setar flags especiais nas partições, etc. Esta
extensão visa realizar todos esses ajustes de
forma automática, minimizando a possibilidade
É importante lembrar que o
TrustedBSD é um projeto que
ainda está em andamento,
sendo que a maioria das
extensões só estarão
disponíveis a partir da
versão
5.0
do
FreeBSD.
A adição das novas funcionalidades
propostas pelo TrustedBSD implica
uma grande alteração na
implementação do subsistema de
segurança do FreeBSD, motivo
pelo qual elas estão sendo
incorporadas gradualmente ao
branch -Current a medida em que se tornam
estáveis, sendo estes cuidados necessários para
evitar que as alterações afetem a funcionalidade,
www.linuxsecurity.com.br
49
de que o administrador cometa erros durante o
processo.
Continuarei com informações
mais específicas no
próximo número
da LinuxSecurity
Magazine.
Fine-grained System Capabilities
Normalmente num sistema UNIX, todos os
direitos e privilégios são atribuídos ao usuário
“root”, esta extensão visa retirar do mesmo parte
desses super poderes e colocá-los sob o controle
direto do sistema operacional.
Access Control Lists
Listas de controle de acesso (ACLs), permitem
aos usuários definir permissões de acesso mais
detalhadas para os seus arquivos e diretorios,
não ficando restritas aos conceitos tradicionais
de usuário/grupo.
FICHA
do
AUTOR
Security Event Auditing
Normalmente um sistema UNIX só loga registros
de autenticação e de situações de erro,
comportamento que pode dificultar em muito um
processo de auditoria de segurança. Esta
extensão visa proporcionar o registro de eventos
independente de estarem ou não associados a
eventos anormais.
Nome Completo:
Edson Brandi,
Idade: 25 anos,
Profissão: Bacharel em Quimica
pela UNICAMP.
Trabalha profissionalmente com
FreeBSD desde 1995 tendo atuado
como consultor junto a varias
empresas nos ultimos anos. É um
membro ativo da comunidade
FreeBSD, sendo o responsavel pelo
site “FreeBSD Primeiros Passos”
(www.primeirospassos.org),
fundador do “Grupo Brasileiro de
UsuarioFreeBSD”
( www.fugspbr.org), responsavel
pelo projeto “FreeBSD LiveCD”
(livecd.sourceforge.net).
Atualmente trabalha como
Gerente de Tecnologia no iBest
(www.ibest.com.br).
Mandatory Access Control
Esta extensão permite ao administrador definir
de forma centralizada e única regras de
preservação de privacidade e integridade para
todos os objetos do sistema, sobrepondo-se as
demais ACLs.
São inúmeros os benefícios proporcionados pela
adoção das extensões acima, você se interessou
pelo assunto e deseja maiores informações sobre
o estágio atual de desenvolvimento do
TrustedBSD, visite o site do projeto em http://
www.trustedbsd.org
www.linuxsecurity.com.br
50
www.linuxsecurity.com.br
51
ARTIGO
Sumário
Snort
vulnerabilidade de uma aplicação; ataques DOS
(Deny of Service) , na tentativa de enviar
centenas de pacotes de modo que a vítima se
afogue.
Uma ferramenta de NIDS monitora todos os
pacotes enviados a uma interface de rede e,
baseando-se em uma série de regras préestipuladas, gera alarmes quando algum desses
pacotes conter especificaçõs que o aponte como
possível ataque. Para aqueles que gostariam de
ler mais sobre NIDS, segue um ótimo FAQ sobre
o assunto: http://www.ticm.com/kb/faq/idsfaq.html
Introdução
A
tualmente uma das maiores preocupações
do administrador de uma máquina
conectada à Internet, seja residencial ou
a porta de entrada de uma empresa, é manter a
segurança de sua rede interna. A primeira
resposta (e na maioria das vezes a única) é
configurar um firewall com um conjunto de regras
que impeçam o acesso indevido de terceiros.
Mas será que podemos prover
algum outro mecanismo que
n o s
alerte sobre tentativas de
invasão e scans?
É justamente essa
resposta que esse
artigo tem como
objetivo, informar e
esclarecer sobre NIDS
- Network Intrusion
Detection System - que pode
ser traduzido como “Sistema de
Detecção de Invasão de Redes”.
Para isso, usaremos como
ferramenta o Snort. (www.snort.org)
Snort - Uma ferramenta NIDS
Iremos utilizar nesse artigo o Snort, uma
ferramenta NIDS open-source bastante
popular por sua flexibilidade nas
configurações de regras e constante
atualização frente às novas ferramentas
de invasão (como o fagroute).
Snort monitora o tráfego de pacotes em
redes IP , realizando análises em tempo real
sobre diversos protocolos (nível rede e
aplicação) e sobre conteúdo (hexa e ASCII).
Outro ponto positivo desse software é o grande
número de possibilidades de tratamento dos
alertas gerados, que podem ser gravados em log
via syslog, armazenados em uma base de dados
(MySQL, PostgreSQL,...) , em arquivo XML ou
mesmo gerando Traps SNMP que podem ser
enviados para um segundo software de Gerência
de Redes para auditoria.
Atualmente ele é suportado para diversas
plataformas Unix e inclusive Windows. Os testes
para esse artigo foram feitos utilizando Red Hat
7.3 , kernel 2.4.18-4 , mas seus resultados podem
O que é NIDS ?
Como citado acima, NIDS é um sistema de
configurações e regras que tem como objetivo
gerar alertas quando detectar pacotes que
possam fazer parte de um possível ataque. Na
verdade, as ferramentas hoje disponíveis
detectam diversos tipos de situações: scans, afim
de verificar quais portas de seu sistema estão
abertas ; ataques de compromentimento, na
tentativa de obter geralmente uma shell com
privilégios de root explorando alguma
www.linuxsecurity.com.br
52
Mas aonde instalar?
Certo. Sabemos como funciona e que tipo de
informação/alertas o snort irá gerar. Mas em que
tipo de sistema e/ou localização de uma rede
deve-se instalar um NIDS?
O snort tem como objetivo analisar o tráfego de
uma rede, alertando possíveis tentativas de
comprometimento. Justamente por isso, ele deve
ser instalado em um ponto de rede que receba
todos os pacotes que trafegam entre a rede
interna e externa, como em uma DMZ. (ou mesmo
na máquina fazendo NAT que repassa os pacotes
em uma rede ADSL doméstica, por exemplo :)
ser obtidos em praticamente qualquer máquina
com seu Unix preferido.
Como ele funciona?
Vamos supor que estamos tentando verificar
tentativas de ataques que exploram o um bug no
protocolo SSH1 (SSH CRC32 attack detection code
bug - 02/08/2001 - veja em http://www.kb.cert.org/
vuls/id/945216 ) que permite ao atacante ganhar
privilégios em certo sistema que esteja rodando o
daemon antigo de sshd. Para esse tipo de ataque
específico, criamos uma regra (veremos regras de
snort a seguir) como a seguinte:
alert tcp $EXTERNAL_NET any ->
$HOME_NET 22 (msg:”EXPLOIT ssh
CRC32 overflow”;
flags:A+; content:”|00 01 57 00 00
00 18|”; offset:0; depth:7;
content:”|FF FF FF FF 00 00|”;
offset:8; depth:14; reference:bugtraq,2347;
reference:cve,CVE-2001-0144;
classtype:shellcode-detect; sid:1327;
rev:2;)
Instalando Snort
Primeiro vamos satisfazer as dependências do
snort e instalar o pacote libpcap, um conjunto de
bibliotecas que provê o mecanismo de filtro de
pacotes. Para isso, faça o download em
www.tcpdump.org, e siga a receita de bolo: (Note
que seu sistema já pode ter esse pacote instalado
- mas é sempre bom se manter atualizado :)
Como root: (su -)
Que diabos é isso?
tar zxfv libpcap.X.tar.gz
cd libpcap.X
./configure
make
make install
Não se preocupe em entender os parâmetros
acima por enquanto. O interessante é notar “
content:”|00 01 57 00 00 00 18| “;” . Em termos
gerais, isso pode ser chamado de assinatura
de um ataque, que aqui se encontra em formato
hexadecimal. Quando um pacote chega no
sistema rodando Snort, uma análise é feita nos
dados e opções do protocolo em questão
(TCP,UDP,ICMP, etc) e se ele conter esse
trecho , o pacote pode ser o início de um
ataque. Note que não necessariamente ele
será, já que nossa regra definida acima
depende de outros parâmetros (como offset e
flags) para gerar corretamente um alerta.
www.linuxsecurity.com.br
Feito isso, podemos finalmente instalar o pacote
que pode ser baixado do site oficial
(www.snort.org). A compilação e instalação deve
seguir os mesmos passos descritos acima.
tar zxfv snort.x.tar.gz
cd snort.x
./configure
make
make install
53
Configurando Snort
Agora com tudo instalado,
precisamos configurar o ambiente.
Opcionalmente, tenho preferência
em instalar os arquivos de configuração em um
diretório específico, mas se houver necessidade
o leitor pode mudar o diretório em questão,
mantendo coerência com o resto do texto.
Crie o diretório:
mkdir /etc/snort
Nele vamos armazenar os arquivos de
configuração utilizados pelo snort. Como o snort
analiza os pacotes de certa interface de rede,
vale a pena separar os arquivos de configuração
em diretórios diferentes, relativos a cada
interface, apenas por organização. Logo,
suponha que seu sistema tenha 2 interfaces de
rede: eth0 para a rede externa (Internet) e eth1
para a rede interna. É possível que se queira
tratar a análise das interfaces diferentemente, já
que se trata de subredes diferentes. Crie o
diretório da interface:
mkdir /etc/snort/eth0
e um diretório geral para os arquivos de regras:
mkdir /etc/snort/rules
Volte agora para o diretório source do snort,
aonde compilamos o pacote, para copiar alguns
arquivos de configuração:
cd snort.x
cp snort.conf /etc/snort/eth0/
cp classification.config /etc/snort/eth0/
cp *.rules /etc/snort/rules/
O diretório dos arquivos de regras (no nosso
caso, /etc/snort/rules/) contém diversos arquivos
que podem ou não serem utilizados pelo snort
durante a execução. Cada arquivo contém
www.linuxsecurity.com.br
54
assinaturas de scans/ataques específicos, logo
é de extrema importância a atualização desses
arquivos, visto que novas técnicas de scan e
ataques aparecem regularmente. Para isso,
mantenha no seu bookmark o site http://
www.snort.org/dl/signature , aonde novas
atualizações das assinaturas são postadas. Mas
antes de aprofundar em regras e assinaturas,
vamos completar nossa instalação.
Quanto menos processos rodando como o
usuário root, melhor. Por isso vamos criar um
usuário snort (grupo snort):
groupadd snort
useradd snort -g snort
passwd -l snort
O último comando garante que o usuário snort
esteja disponível somente para o root - e nenhum
outro usuário. Agora mudamos as permissões
dos arquivos de configuração para que somente
o usuário snort tenha acesso.
chmod -R 700 /etc/snort/
chown -R snort.snort /etc/snort/
Arquivo de configuração
- snort.conf
Quando o snort é executado no modo
de detecção de intrusos, um dos
parâmetros é o arquivo de
configuração
que
contém
informações específicas, como
interface a ser monitorada, quais
regras serão usadas, existência de servidores,
etc. O artigo deve cobrir as principais, deixando
o leitor se aprofundar no assunto. Vamos editar
o arquivo snort.conf , um exemplo de
configuração padrão do pacote, muito bem
documentada:
vi /etc/snort/eth0/snort.conf
Procure a linha em que a variável HOME_NET é
declarada. Deve ser algo do tipo:
A linha significa que o snort irá usar o syslog
para gerenciar o output, sendo LOCAL5 a facility
e CRIT (crítico) o nível de severidade. Iremos,
em breve, editar o arquivo syslog.conf para
adicionar uma linha correspondende, indicando
o arquivo de log a ser utilizado pelo syslog.
Por último, devemos incluir quais regras o snort
usará em seu monitoramento. As linhas de
“include” fazem justamente isso. Por exemplo, a
linha:
var HOME_NET $eth0_ADDRESS
Com isso estou indicando que o snort deve
monitorar o endereço IP da interface eth0. É
possível especificar o endereço IP diretamente
(ou mais de 1!). Uma alternativa seria: var
HOME_NET [10.1.1.0/24,192.168.1.0/24] Outras
variáveis, como HTTP_SERVERS, podem ser
declaradas e tem como valor padrão a própria
variável HOME_NET. Se for seu caso, substitua
pelo endereço IP correspondente. Agora
setamos a variável que define o diretório que
contém as regras:
include $RULE_PATH/exploit.rules
irá incluir as regras definidas no arquivo /etc/
snort/rules/exploit.rules , responsável pelas
assinaturas de certos exploits (programas que
tentam explorar certa vulnerabilidade de certo
programa, na tentativa de obter uma shell do
sistema). Inclua todos os arquivos ou somente
aqueles que desejar. Lembre-se que a inclusão
de regras também é outro fator para a
performance do snort. Muitos arquivos de regras
resultam em maior demanda de processamento.
Editando syslog.conf
Como dito anteriormente, configuramos o snort
para gerar logs através do daemon syslog com
a linha: output alert_syslog: LOG_LOCAL5
LOG_CRIT. Agora temos que modificar o arquivo
de configuração do syslog para que as mudanças
tenham efeito.
Edite o arquivo /etc/syslog.conf e adicione a
seguinte linha:
var RULE_PATH /etc/snort/rules
O arquivo também contém a declaração de
preprocessors, que são pequenos módulos/
plugins que extendem o poder do snort, a um
certo custo de processamento. Essa
funcionalidade está presente desde a versão 1.5
do snort, abrindo espaço para que os
programadores de plantão desenvolva plugins
adicionais e acoplem ao snort. Embora a
utilização deles possa aumentar as chances de
detecção de um ataque, vale a pena lembrar que
a adição de plugins adicionais resulta na
necessidade de um processamento extra. Como
exemplo:
preprocessor frag2
# Arquivo log snort
local5.crit
/var/log/snort/snort.log
Isso garante inclusão do plugin frag2,
responsável por detectar scans e ataques com
fragmentação do pacote IP, utilizado como
alternativa de ataque para driblar certos
mecanismos de detecção.
Como dito no início deste texto, é possível
redirecionar os alarmes do snort para diversas
saídas e aqui usaremos um arquivo texto,
gerenciado pelo syslog para armazenar nossos
alarmes:
output alert_syslog: LOG_LOCAL5
LOG_CRIT
www.linuxsecurity.com.br
Nota: há possibilidade que seu arquivo já tenha
uma linha tratando a facility local5 (ou *.crit). Se
esse for o caso, talvez seja melhor assumir outra
facility para tratar os alarmes do snort. Fica por
sua conta!
Agora criamos o diretório e o arquivo de log:
mkdir /var/log/snort/
55
touch /var/log/snort/snort.log
chmod -R 770 /var/log/snort/
chown -R snort.snort /var/log/snort/
chmod 700 /etc/init.d/snort.sh
n -s /etc/init.d/snort.sh /etc/rc3.d/S14Snort
ln -s /etc/init.d/snort.sh /etc/rc1.d/
K91Snort
Agora , com tudo pronto, precisamos reiniciar o
syslog. Há diversos modos de fazer isso. Sua
distribuição deve conter um script de inicialização
em /etc/init.d/syslog , nesse caso:
Pronto! O snort está devidamente configurado
para iniciar durante o boot, gravando os alarmes
em /var/log/snort/snort.log . Se você quiser parar
por aqui, já cobrimos o necessário para o
funcionamento do snort - agora basta manter a
base de assinaturas atualizada, visitando o site
www.snort.org de tempos em tempos.
Convido aos interessados a continuar a leitura
do próximo ítem - Introdução à regras de Snort aonde tentaremos entender como as regras de
Snort funcionam, assim
podemos escrever nossas
próprias regras, aperfeiçoando
ainda mais nossa solução.
/etc/init.d/syslog restart
caso contrário:
kill -1 ‘cat /var/run/syslogd.pid‘
Testando a instalação
Tudo que precisamos já está
configurado e estamos prontos
pra um teste. Inicie o snort:
Introdução à regras de
Snort
snort -D -c /etc/snort/eth0/snort.conf -u
snort -g snort -b -l
/var/log/snort/snort.log
Uma solução NIDS só é realmente eficiente se
sua base de dados está sempre atualizada, já
que novos ataques aparecem todo o dia. Para
tornar a explicação mais didática (e provar que
realmente funciona :) iremos criar uma regra de
snort para a recente vulnerabilidade encontrada
no daemon servidor de httpd Apache. De acordo
com a cert.org ( http://www.cert.org/advisories/
CA-2002-17.html ) e a Apache Software
Foundation http://httpd.apache.org/info/
security_bulletin_20020617.txt existe uma falha
na configuração padrão das versões 1.2.2 e
superior, 1.3 até 1.3.24, e versões 2.0 até 2.0.36
durante o tratamento de dados codificados em
pedaços (chunks). Recentemente o grupo de
segurança Gobbles publicou um exploit do
problema para a plataforma OpenBSD e afirma
ser possível explorar o mesmo problema nas
plataformas Linux (GNU) 2.4 (x86), Sun Solaris
6-8 (sparc/x86) e FreeBSD 4.3-4.5 (x86).
Considerando que seu sistema já esteja
conectado à Internet, logo seu log começará a
se encher de alertas, como o seguinte:
Jun 01 17:12:34 eca snort: [1:615:2]
SCAN Proxy attempt
[Classification: Attempted Information
Leak] [Priority: 2]: {TCP}
200.254.85.134:61546 ->
200.134.1.18:1080
Iniciando Snort durante o boot
Vamos criar um script de inicialização do snort,
assim quando o sistema inicia, o snort começa a
executar. Pegue o arquivo aqui Depois:
mv snort.sh /etc/init.d/
www.linuxsecurity.com.br
56
Visto que se trata de um problema grave, valhe
a pena criarmos uma regra no snort para notificar
as possíveis tentativas (e se você ainda não
atualizou seu Apache, pause essa leitura e corra
até o site do seu distribuidor ;-). Antes de mais
nada, vamos entender a sintaxe básica.
diversas outras opções para a configuração de
regras que não serão escopo deste artigo, já que
o objetivo é iniciar o leitor no básico sobre a
sintaxe das regras. Se quiser se aprofundar no
assunto, sugiro uma visita ao site: http://
www.snort.org/docs/writing_rules/
O básico
Escrevendo a regra para Apache
Quando o snort inicia, ele lê do arquivo de
configuração quais regras serão tratadas, de
acordo com a sintaxe:
exemplo: include $RULE_PATH/scan.rules
aonde $RULE_PATH é uma variável definida no
mesmo arquivo
Portanto, o arquivo scan.rules contém diversas
regras que classificam
tipos de scan.
Um exemplo simples
Esse exemplo retirado da própria documentação
do snort vai nos ajudar
entender a sintaxe básica:
Voltando ao nosso problema inicial, abaixo se
encontra a regra oficial disponibilizada no site
oficial do snort para o recente problema no
Apache:
alert tcp any any -> $MY_NET any (flags:
S; msg: “SYN packet”;)
(para snort-1.8.6)
alert tcp $EXTERNAL_NET any ->
$HTTP_SERVERS $HTTP_PORTS
(msg:”WEB-MISC Transfer-Encoding\:
chunked”;
flow:to_server,established;
content:”Transfer-Encoding\:”; nocase;
content:”chunked”; nocase;
classtype:web-application-attack;
reference:bugtraq,4474;
reference:cve,CAN-2002-0079;
reference:bugtraq,5033;
reference:cve,CAN-2002-0392; sid:1807;
rev:1;)
Primeiro notamos a definição da variável
MY_NET, que compreende os endereços IP da
minha rede - 192.168.1.0/24 e 10.1.1.0/24 . Logo
em seguida, a diretiva “alert” significa que o snort
irá gerar um alerta (e loga-lo) se:
o pacote for do tipo tcp;
o pacote vier de qualquer endereço e qualquer
porta (any any) destinado à variável $MY_NET
(meu endereço) para qualquer porta (any);
além disso, o pacote deve conter a flag SYN do
protocolo TCP, caracterizando como possível
inicio de uma conexão TCP (msg: “SYN packet”);
A sintaxe lembra bastante a configuração de
regras de um firewall, como o iptables. O tipo do
protocolo deve ser informado (tcp, udp, icmp,
etc), a origem (endereço IP e porta), o destino
(idem), entre outras opções disponíveis. Existem
Iremos analizar todas as opções da regra,
demonstrando suas utilidades.
Note que a conexão em questão se trata do
protocolo TCP, vindo da rede externa (normalmente
a Internet) de qualquer porta origem (any) para a
variável $HTTP_SERVERS , que obviamente
compreende todos os servidores w3 da minha rede,
para o conjunto de portas, também definido por
uma variável $HTTP_PORTS. A mensagem que
deve ser postada no alarme é “WEB-MISC
Transfer-Encoding: chunked”
Para uma melhor análise das opções
content:”Transfer-Encoding\:” e content:”chunked”
, vamos nos basear no recente exploit lançado pela
Gobbles ( http://www.dcc.unicamp.br/pub/~983728/
pub/artigos/snort/snort.sh) para verificar a
assinatura que devemos receber em
var MY_NET [192.168.1.0/24,10.1.1.0/
24]
www.linuxsecurity.com.br
57
uma rede. Além de uma prevenção, os alarmes ajudam
a definir possíveis atacantes, aumentando a
flexibilidade aliado a outras soluções de segurança,
como regras adicionais de firewall. No entanto, a luta
entre os sistemas de detecção de scans e as
ferramentas de scan (como o nmap) é eterna. Enquanto
os scans tentam driblar os sistemas de detecção,
obtendo informações sobre um sistema sem gerar
alertas ou suspeitas, ferramentas como o Snort tentam
cobrir todas as técnicas de scan para tentar denunciar
tais varreduras. É necessário, portanto, a atualização
constante, tanto do software, como das assinaturas
de novos ataques.
caso desse ataque seja usado (mesmo que o exploit
seja para OpenBSD, e não para Linux).
Acionando o exploit em uma tentativa (frustrada!)
de corromper a execução do Apache rodando
localmente, temos:
gcc -o apache-scalp apache-scalp.c
../apache-scalp 0 127.0.0.1
Vamos dar uma olhada no conteúdo dos pacotes
enviados pelo exploit com o tcpdump (ou outro sniffer
qualquer):
[root@eca root]# tcpdump -i lo -X -s0
tcpdump: listening on lo
Links
Site oficial Snort
http://www.snort.org/
Documentação oficial http://www.snort.org/docs/
writing_rules
Update de assinaturas http://www.snort.org/dl/signatures/
NIDS FAQ
http://www.ticm.com/kb/faq/idsfaq.html
Artigo snort
http://www.dcc.unicamp.br/~983728/pub/artigos/snort/
snort.html
Snort script
http://www.dcc.unicamp.br/~983728/pub/artigos/snort/
22:42:42.486917 eca.33112 > eca.http: P
16384:29897(13513) ack 1 win 32767
<nop,nop,timestamp 659847 659847> (DF)
....
0x34c0
0000 0000 0000 0000 000d 0a54 7261
6e73...........Trans
0x34d0
6368
6665 722d 456e 636f 6469 6e67 3a20
fer-Encoding:.ch
0x34e0
4242
756e 6b65 640d 0a0d 0a35 0d0a 4242
unked....5..BBBB
FICHA
do
AUTOR
0x34f0
420d 0a66 6666 6666 6636 650d 0a
B..ffffff6e..
....
Além dos pacotes do inicio de conexão TCP,
encontramos um pacote com o conteúdo acima Transfer-Encoding e chunked . Ainda verificamos que
se trata de um pacote com flag Ack, vindo do cliente (
eca.33112 - minha máquina/ porta 33112) para o
servidor ( > eca.http - porta 80 ), explicando a diretiva
de fluxo de pacotes: flow:to_server,established; As
demais opções da regra - reference, classtype, sid e
rev - são utilizadas para informação específica da regra,
aonde encontrar referência do problema que ela irá
alertar.
Conclusão
Demonstramos que uma ferramenta NIDS como o
Snort pode ser um grande aliado , apontando, através
de alarmes, os diversos scans/ataques direcionados à
www.linuxsecurity.com.br
58
Nome:
Gabriel Armbrust Araujo
idade: 23
Profissão: analista em gerência e
segurança em redes, terminando
curso de ciência da computação UNICAMP empresa:
www.icaro.com.br
emails:
:
[email protected]
[email protected]
site:
http://www.dcc.unicamp.br/~983728/
ARTIGO
Sumário
Aumentando a segurança do seu
Webserver com LIDS
Aumentando a segurança do seu Webserver com LIDS
A
cada dia que passa ficamos cada vez
mais a mercê dos inconsequentesvirtuais.
Isso se dá ao fato de a internet ter se
tornado o maior meio de comunicação global de
todos os tempos.
Com certeza isso não é uma novidade para você
que está lendo este artigo e pensando no que
este colunista tem de novo para mostrar no que
se refere a “segurança virtual” !
Ultimamente a palavra “segurança” tem causado
um alvoroço muito grande na comunidade
internacional e tudo que se refere à segurança
da informação chama a atenção de todos, como
se fossem os primeiros lançamentos do pirulito
“Diplik” (pode dar risada, eu sei que você
conhece também).
E o que segurança da informação tem a ver com
pirulitos de 20 anos atráz que nem existem mais
(na realidade eu encontrei um desses a uns 2
meses atráz, e confesso, fui obrigado a comprar
pelo menos 10) ?
malditos “script kiddies”.
Podemos ter apenas uma certeza nisso tudo, a
de que você ainda vai ouvir falar muito sobre
Dipli.., opa, quer dizer, segurança da informação
e que a única forma de estar totalmente seguro
nos meios virtuais, infelizmente é desplugando
o seu cabo.
Sejam bem vindos, espero que tenham se
distraído um pouco com a minha pequena
história, que para bons entendedores, pode ser
engraçada.
Neste artigo, terei o imenso prazer de lhes
mostrar, como reforçar a segurança de um
Webserver rodando serviços básicos com LIDS.
Para quem não conhece, o LIDS (Linux Instrusion
Detection System) é um patch para o kernel linux,
que tráz, excelentes recursos para melhorar a
implementação de uma política de segurança
realmente eficaz. Na realidade, o nome LIDS não
faz jus as suas funções, pois herdou este nome
pelo fato de possuir um avançado sistema de
detecção de portscans embutido no kernel.
Pauma pauma, não priemos cânico, eu
explico.
O exemplo do pirulito (sei que não foi uma
boa escolha, mas tudo bem) é como se
fosse a segurança que tanto buscamos,
ou seja, queremos o pirulito mas não
sabemos aonde encontrá-lo, e
queremos a segurança mas não
sabemos ao certo como alcançala, ou mesmo como lidar com
ela, é por isso que o assunto “
chama tanto a atenção, porque
todos estão em uma corrida
frenética para conseguir manter
a sua rede menos vulnerável aos
inconsequentes virtuais ou,
na maioria dos casos, dos
www.linuxsecurity.com.br
O LIDS é muito mais que um sistema de detecção
de intrusos, ele é também um sistema completo
de MAC (Controle de Acesso Mandatório), em
que por exemplo, pode-se configurar ACL’s
(Listas de/para Controle de Acesso) que negam
o acesso de programas à determinados
diretórios/recursos do computador, e isso é válido
também para o super usuário “root”.
Recentemente, tive o prazer de representar a
LinuxSecurity Brasil Solutions no III Forum
internacional de Software Livre, ministrando uma
palestra sobre LIDS, sendo assim, não tomarei
59
automake, make, cpp)
* ncurses-devel (apenas se quiser utilizar
menuconfig)
muito este espaço para falar sobre as
funcionalidades do LIDS, confira maiores
detalhes sobre esta fantástica ferramenta nos
Slides que se encontram online no:
http://www.linuxsecurity.com.br/info/eventos/lidsfisl2002
OBS: A instalação do LIDS não é
recomendada para usuários iniciantes no
mundo Linux, pois envolve conhecimentos
avançados, principalmente no que diz
respeito à recompilação do kernel.
Serviços
Faça o download do LIDS em: http://www.lids.org/
download
O nosso Webserver em questão, terá a seguinte
configuração:
* OpenSSH -> padrão, rodando na porta 22
* Apache/PHP4 -> versão 1.3.26 com suporte a
PHP4
* ProFTPD -> rodando com suporte a chroot
(DefaultRoot ~)
* daemontools -> para controle do qmail
* qmail -> somente como MTA (Mail Transfer
Agent)
* syslog-ng -> maior segurança em relação ao
conhecido syslogd
* kernel 2.4.18 -> último release stable do kernel
Linux série 2.4
* lids-1.1.1r2-2.4.18 -> último release stable para
o kernel 2.4
Assumirei que você baixou o arquivo no diretório
“/usr/local/src” e que o src do seu kernel está
em “/usr/src/linux”:
[root@lids ~]# cd /usr/local/src && tar
xzvf lids-1.1.1r2-2.4.18.tar.gz
[root@lids src]# cd /usr/src/linux
[root@lids linux]# patch -p1 < /usr/local/
src/lids-1.1.1r2-2.4.18/lids-1.1.1r22.4.18.patch
Neste artigo não trataremos da instalação destes
serviços, consulte a documentação de cada um
deles para maiores informações.
[root@lids linux]# make menuconfig
[*] Linux Intrusion Detection System
support (EXPERIMENTAL)
— LIDS features
(256) Maximum protected objects to
manage
(256) Maximum ACL subjects to manage
(256) Maximum ACL objects to manage
[ ] Hang up console when raising a
security alert
[*]
Security alert when execing
unprotected programs before sealing LIDS
[ ] Do not execute unprotected programs
before sealing LIDS
[*] Attempt not to flood logs
(60)
Authorised time between two
identic logs (seconds)
Instalação do LIDS
A instalação do LIDS requer aplicação do
patch no kernel e recompilação do mesmo,
como qualquer outro patch para o kernel, para
isso você vai precisar ter instalado:
* Compilador C/C++ (gcc)
* Fontes do kernel 2.4.18
* Bibliotecas C/C++ para desenvolvimento (glibcdevel)
* Ferramentas GNU para compilação (autoconf,
www.linuxsecurity.com.br
60
Esta linha é muito importante, pois é ela quem
faz o “sealing” do kernel, ou seja, é ela que inicia
efetivamente todas as ACL’s e CAPABILITIES.
[*] Allow switching LIDS protections
[*] Restrict mode switching to specified
terminals
[*] Allow mode switching from a Linux
Console
[ ] Allow mode switching from a serial
Console
[*] Allow mode switching from a PTY
(3)
Number of attempts to submit
password
(3) Time to wait after a fail (seconds)
[ ] Allow any program to switch LIDS
protections
[*] Allow reloading config. file
[*] Port Scanner Detector in kernel
[*] Send security alerts through network
[*] Hide klids kernel thread
(3) Number of connection tries before
giving up
(30) Sleep time after a failed connection
(16) Message queue size
[*] Use generic mailer pseudo-script
[*] LIDS Debug
OBS: Para maiores informações sobre a
instalação do LIDS, consulte o meu artigo
online no:
http://www.linuxsecurity.com.br/
sections.php?op=viewarticle&artid=25
Compilando as ferramentas
lidsadm e lidsconf
[root@lids ~]# cd /usr/local/src/lids1.1.1r2-2.4.18
[root@lids lids-1.1.1r2-2.4.18]# ./
configure && make && make install
lidsadm
lidsadm é a ferramenta que se encarrega de
manipular as CAPABILITIES e o stado do
sistema. Você vai utilizá-la basicamente para:
Recomendo fortemente que você visite a sessão
HELP de cada uma das opções para obter uma
breve descrição do que você está habilitando em
seu kernel.
Perceba que para este kernel estamos limitando
o número máximo de ACL’s de objects e subjects
para 256, é mais do que suficiente.
- Selar o kernel (sealing the kernel -> lidsadm -I)
- Criar free session (veja sobre free session)
- Ativar/Desativar o LIDS (lidsadm -S — +|LIDS_GLOBAL)
- Fazer reload das ACL’s (lidsadm -S —
+RELOAD_CONF)
- Mostrar status (lidsadm -V)
Compile o seu novo kernel:
[root@lids linux]# make clean dep
bzImage
Veja maiores informações na man page do
lidsadm.
Após a compilação, configure o seu novo kernel
no seu gerenciador de boot, mas “NÃO” faça o
reboot da sua máquina ainda.
lidsconf
lidsconf é a ferramenta que manipula as ACL’s
do LIDS.
Veja maiores informações na man page do
lidsconf.
Coloque a seguinte linha no final do seu
arquivo “/etc/rc.d/rc.local”:
[ -f /proc/sys/lids/locks ] && /sbin/lidsadm -I
www.linuxsecurity.com.br
61
-23:CAP_SYS_NICE
-24:CAP_SYS_RESOURCE
-25:CAP_SYS_TIME
-26:CAP_SYS_TTY_CONFIG
-27:CAP_MKNOD
-28:CAP_LEASE
-29:CAP_HIDDEN
-30:CAP_KILL_PROTECTED
-31:CAP_PROTECTED
Arquivos de configuração
Arquivo “lids.net” de exemplo:
O LIDS utiliza os seguintes arquivos de
configuração que residem no diretório “/etc/lids”:
MAIL_SWITCH=1
MAIL_RELAY=192.168.1.2:25
MAIL_SOURCE=lidsbox.telles.org
[email protected]
[email protected]
MAIL_SUBJECT=LIDS ALert
* lids.cap -> arquivo aonde são configuradas as
CAPABILITIES
* lids.conf -> arquivo aonde são armazenadas
as ACL’s em formato não legível
* lids.net -> arquivo aonde devem ser
configurados os dados para notificação de
violações por e-mail
* lids.pw -> este arquivo armazena a senha do
LIDS criptografada em RipeMD-160
Conhecendo um pouco sobre
objects e subjects
Arquivo “lids.cap” utilizado neste artigo:
O LIDS trabalha com objects (objetos) e subjects
(referencia de um objeto para outro objeto),
sendo assim, ele transforma diretórios e arquivos
em objetos, que são mais fáceis de serem
manipulados, vejamos um exemplo:
-0:CAP_CHOWN
-1:CAP_DAC_OVERRIDE
-2:CAP_DAC_READ_SEARCH
-3:CAP_FOWNER
-4:CAP_FSETID
-5:CAP_KILL
-6:CAP_SETGID
-7:CAP_SETUID
-8:CAP_SETPCAP
-9:CAP_LINUX_IMMUTABLE
-10:CAP_NET_BIND_SERVICE
-11:CAP_NET_BROADCAST
-12:CAP_NET_ADMIN
-13:CAP_NET_RAW
-14:CAP_IPC_LOCK
-15:CAP_IPC_OWNER
-16:CAP_SYS_MODULE
-17:CAP_SYS_RAWIO
-18:CAP_SYS_CHROOT
-19:CAP_SYS_PTRACE
-20:CAP_SYS_PACCT
-21:CAP_SYS_ADMIN
+22:CAP_SYS_BOOT
www.linuxsecurity.com.br
lidsconf -A -o /etc -j READONLY
A regra acima instrui o LIDS para criar um objeto
cujo nome é “/etc” e que poderá somente ser
lido.
lidsconf -A -s /bin/login -o /etc/shadow -j
READONLY
Da mesma forma, a regra acima instrui o LIDS
para criar uma ACL, onde o objeto “/bin/login”
poderá ter privilégios somente de leitura no
objeto “/etc/shadow”, isso chama-se “subject”.
OBS: Só é possível criar subjects a partir
de objetos previamente criados.
62
CAP_CHOWN -> Capacidade de trocar dono e
grupo do arquivo/diretório
Conhecendo um pouco sobre
CAPABILITIES
CAP_DAC_OVERRIDE -> Acesso DAC (veja
mais abaixo sobre DAC)
CAP_DAC_READ_SEARCH -> Leitura DAC
(veja mais abaixo sobre DAC)
CAP_FOWNER -> Sobrescreve todas as
restrições aplicadas à arquivos, isso se o
owner ID for igual ao user ID, exceto se
CAP_FSETID estiver habilitado
CAP_FSETID -> Restrições se o effective user
ID não for igual ao owner ID
CAP_KILL -> Limitação que faz com que o
effective user ID que emita um sinal deva
combinar com ou user ID do processo que recebe
o sinal. Trocando em miúdos, restringe o poder
que o usuário root tem de matar processo que
não seja dono
Todo e qualquer
recurso que possa ser
utilizado em um
sistema operacional é
chamado
de
CAPABILITY, ou
seja, é uma
capacidade que
é solicitada ao
kernel para executar
uma
determinada
operação. Quando você executa um comando
como “chown root /tmp/arquivo.txt”, você está
solicitando ao kernel a utilização da CAPABILITY
CAP_CHOWN, e o kernel prontamente atenderá
a sua solicitação baseando-se apenas em
permissões de file system.
O LIDS permite que você manipule estas
CAPABILITIES, assim sendo, com o LIDS é
possível instruir o kernel de que nenhum
programa poderá utilizar a CAPABILITY
CAP_CHOWN.
CAP_SETUID -> Execução de processos com
UID forjado (Ex: Apache, Squid, etc)
CAP_SETGID -> Execução de processos com
GID forjado (Ex: Named, ProFTPD, etc)
CAP_SETPCAP -> Transfere capacidade de um
ambiente para qualquer PID (veja sobre
LD_LIBRARY_PATH)
CAP_LINUX_IMMUTABLE -> Modificações nos
atributos de arquivos (chattr)
CAP_NET_BIND_SERVICE -> Binding para
portas TCP/UDP abaixo de 1024
CAP_NET_BROADCAST ->
Multicast
CAP_NET_ADMIN -> Tarefas administrativas de
rede: levantar eth’s, trocar IP’s, rotas, regras de
firewall, configurar modo PROMÍSCUO, etc .
Vejamos as CAPABILITIES que podemos
manipular com o LIDS e uma breve descrição
sobre elas:
www.linuxsecurity.com.br
Broadcast/
63
CAP_NET_RAW -> Utilização de sockets RAW
(Ex: ping, ipvs).
CAP_PROTECTED -> Protege processos de
sinais (KILL, HUP, ALARM, etc).
CAP_IPC_LOCK -> Locking de segmentos de
memória compartilhada.
CAP_KILL_PROTECTED -> Permite matar
processos protegidos .
CAP_IPC_OWNER -> Checagem de ownership
de IPC.
CAP_SYS_MODULE -> Inserir e remover
módulos de kernel.
CAP_SYS_RAWIO -> Acesso a /dev/ports, /dev/
{mem,kmem} e raw devices.
Free Session
CAP_SYS_CHROOT -> Utilização de chroot (Ex:
bind-chroot, ProFTPD, etc).
Free Session (sessão livre) é um recurso
extremamente importante no LIDS, ele serve para
desabilitar o LIDS somente no seu console/tty,
isso é necessário quando o admin precisa fazer
manutenção na máquina, assim sendo, não é
preciso desabilitar o LIDS em todo o sistema para
fazer este serviço.
Entenda-se por manutenção, atualização do
webserver, reiniciar alguns processos protegidos,
alterar um IP, realizar backup e etc.
Antigamente, seria comum desabilitar o LIDS
globalmente para fazer este serviço:
CAP_SYS_PTRACE -> Proccess trace (strace,
ptrace, etc).
CAP_SYS_PACCT -> Configuração de
process accounting.
CAP_SYS_ADMIN -> Tarefas administrativos
do sistema: configurar quotas, hostname,
domainname, mount, umount, serialports, etc.
CAP_SYS_BOOT -> Utilização de reboot.
lidsadm -S — -LIDS_GLOBAL
CAP_SYS_NICE -> Nice level de processos.
Mas a muito tempo atráz, foi incluído este recurso
chamado “free session”, para poder resolver este
problema:
CAP_SYS_RESOURCE -> Resource limites
(Ex: ulimits, quota limits, console limits, etc).
CAP_SYS_TIME -> Manipulação da hora do
sistema e real-time clock.
lidsadm -S — -LIDS
Assim o LIDS é desabilitado somente no console/
tty em que você estiver logado.
CAP_SYS_TTY_CONFIG -> Configuração de
devices TTY’s (Ex: mingetty, getty, screen).
OBS: Somente é permitido 1 free session
na máquina, se você tentar fazer mais de
1, a primeira free session será
automaticamente desabilitada, e o LIDS
estará habilitado novamente neste console/
tty.
CAP_MKNOD -> Ações ioctl e chamadas de
manipulação de dispositivos do sistema.
CAP_LEASE -> Altera leases de arquivos.
CAP_HIDDEN -> Torna processos invisíveis.
www.linuxsecurity.com.br
64
DAC - Discretionary Access
Control (Controle de Acesso Ilimitado)
CAP_SETPCAP e
LD_LIBRARY_PATH
A pouco tempo atráz foi descoberto um BUG de
segurança que envolvia a obtenção de privilégios
a partir da variável de ambiente
LD_LIBRARY_PATH.
Após este ocorrido, o LIDS por padrão nega este
tipo de acesso a esta variável de ambiente, sendo
assim se você precisa que um determinado
programa tenha acesso a estas informações,
deve-se criar ACL’s do tipo:
O LIDS definitivamente
veio resolver uma série de
problemas de segurança
que alguns sysadmins
possuem a muito tempo
no Linux, um deles diz
respeito ao controle de
acesso ilimitado a
diretórios (DAC).
O super usuário “root” pode
ler/escrever em qualquer
diretório onde ele não tenha
permissão. O LIDS põe um fim nisso, com a
manipulação das CAPABILITIES
CAP_DAC_OVERRIDE e
CAP_DAC_READ_SEARCH, Ex:
lidsconf -A -o /path/do/programa -j READONLY
lidsconf -A -s /path/do/programa -o
CAP_SETPCAP -j GRANT
OBS: Recomendo não manter esta variável
de ambiente setada, a menos que você
realmente precise dela e saiba o que está
fazendo.
[root@lids ~]# ls -ld /home/rodrigo
drwx——— 52 rodrigo rodrigo 4096
Jun 28 21:31 /home/rodrigo
Herança (inheritance -> -i)
Percebam que o usuário “root” não possui
permissão para ler este diretório, mas em uma
situação normal, ele poderá acessar o diretório
sem maiores problemas:
O LIDS possui um avançado sistema de
heranças em suas ACL’s, imaginemos a
seguinte situação:
[root@lids ~]# cd /home/rodrigo
[root@lids rodrigo]# pwd ; id -u
/home/rodrigo
0
#!/bin/bash
log=/var/log/backup-day
tar -czvf arq.tar.gz ~/ > $log
Com LIDS e removendo as CAPABILITIES
CAP_DAC_OVERRIDE e
CAP_DAC_READ_SEARCH:
Se executarmos:
lidsconf -A /etc/scripts/backup.sh -o /var/log/
backup-day -j WRITE
[root@lids ~]# cd /home/rodrigo
Operation not permitted
[root@lids ~]# ls -l /home/rodrigo
Operation not permitted
O script não vai funcionar, pois os seus filhos
não iriam conseguir escrever no arquivo “/var/
log/backup-day”. Usando:
lidsconf -A /etc/scripts/backup.sh -o /var/log/
backup-day -i 1 -j WRITE
www.linuxsecurity.com.br
65
Agora o script “/etc/scripts/backup.sh” pode
passar as suas permissões como herança para
os seus filhos (tar).
separar as informações de LOG que o LIDS gera
em 4 arquivos que estarão dentro do diretório “/
var/log/lids”:
Se pegarmos um outro script executando o nosso
anterior:
* changes -> informações de modificação de
stado do LIDS (enable, disable, etc)
* portscan -> informações referentes a
detecção de portscans
* scanports -> portas que estão sendo
scaneadas
* violates -> informações sobre as violações
do sistema
#!/bin/bash
log=/var/log/backup-day
. /etc/scripts/logrotate.sh
tar -czvf arq.tar.gz ~/ > $log
Estas regras devem ser adicionadas ao arquivo
“syslog-ng.conf”, caso você tenha optado em
instalá-lo no lugar do syslogd são:
Agora não vai funcionar mais, temos um
problema ???
lidsconf -A /etc/scripts/backup.sh -o /var/log/
backup-day -i 2 -j WRITE
#————————————————
source mysrc { file(“/proc/kmsg”); };
Agora os filhos do script “/etc/scripts/backup.sh”
podem passar as suas permissões como herança
para o script “/etc/scripts/logrotate.sh”.
destination lids { file(“/var/log/lids/violates”); };
destination lids_pscan { file(“/var/log/lids/portscan”); };
destination lids_scanports { file(“/var/log/lids/scanports”);
};
destination lids_changes { file(“/var/log/lids/changes”); };
Caso você precise de um nível de herança
infinito, pode-se utilizar “-1”, mas cuidado com
este nível de herança, pois ele é GULOSO.
Ele é o “*” das expressões regulares.
filter f_lids { match(“unprotected”) or match(“try to”) \
filter f_scan { match(“Port scan detected:”); };
or match(“violated”) or match(“Attempt”) or match(“:
access”); };
filter f_sports { match(“LIDS.lids_check_scan.l”) and
match([0-9]+) \
and not match(“return”); };
filter f_lidschg { match(“LIDS locally switched”) or
match(“LIDS: lidsadm”) \
or match(“LIDS switched”) or match(“Mail Switch”) \
or match(“LIDS: Statistics:”) or
match(“LIDS: init”); };
# Esta regra serve para limpar as mensagens sobre LIDS do
log do kernel
filter f_kern { facility(kern) and not match(“LIDS”); };
# Esta regra serve para limpar as mensagens sobre LIDS do
log de debug
filter p_debug { level(debug) and not match(“LIDS”); };
log { source(mysrc); filter(f_lids); destination(lids); };
log { source(mysrc); filter(f_scan); destination(lids_pscan);
};
log
{
source(mysrc);
filter(f_sports);
destination(lids_scanports); };
log
{
source(mysrc);
filter(f_lidschg);
destination(lids_changes); };
#——————————————————
LIDS e syslog-ng
LIDS e syslog-ng formam
um par perfeito para
geração e monitoramento
de LOGs, pois não adianta
um sistema que gera
muitas informações de
LOG se o admin nem
mesmo sabe como utilizar
estas informações em seu
próprio benefício, assim
sendo, estas informações
acabam se tornando
inconvenientes.
Com syslog-ng, nós vamos
www.linuxsecurity.com.br
66
nas directivas de “Directory” do seu apache, pois
seria uma catástrofe fazer o apache seguir links
simbólicos no sistema.
Muito cuidado, esta opção vem como default na
instalação padrão do apache.
Se você não terá nada de especial neste
diretório, simplesmente utilize
“Options None”.
OBS: Recomendo a leitura da
documentação do syslog-ng para maiores
exclarecimentos sobre estas regras.
Crie o diretório “/var/log/lids” antes de reiniciar o
syslog-ng:
[root@lids ~]# mkdir -p /var/log/lids
Alguns ajustes no “proftpd.conf”
É extremamente recomendável que você
“prenda” os seus usuários de ftp dentro do seu
próprio home, isso evita muitas catástrofes, para
isso, utilize a seguinte
configuração no seu arquivo “proftpd.conf”:
Configuração
Alguns ajustes no PHP4 (php.ini)
Uma ótima opção é utilizar o mod_php4 em safe
mode, desabilitar o php por padrão e também
barrar algumas funções perigosas:
DefaultRoot ~
Para evitar que utilizem o usuário de ftp para
fazer conexões ssh no seu
servidor ou outra similar, crie sempre usuários
com shell “/bin/false”, e não esqueça de colocar
esta configuração no “proftpd.conf”:
engine = off
safe_mode = On
disable_functions = phpinfo, php_uname,
get_current_user
RequireValidShell Off
Como última dica para o proftpd, utilize a directiva
“ServerIdent” para esconder a versão do proftpd
(obscuridade como complemento de segurança,
sim; como solução, nunca)
Veja a documentação online do php para maiores
informações sobre funções em http://
www.php.net .
Como o php está desabilitado por padrão, será
necessário habilitá-lo por diretório onde será
utilizado, Ex:
ServerIdent on “Telles FTP Server”
Veja a diferença:
- Antes
[root@lids ~]$ ftp localhost
Connected to localhost.localdomain.
220 ProFTPD 1.2.2rc1 Server ready.
<Directory /home/httpd/html/scripts_php>
Order allow,deny
Allow from all
php_flag engine On
</Directory>
- Depois
[root@lids ~]$ ftp localhost
Connected to localhost.localdomain.
220 Telles FTP Server
Name (localhost:rodrigo):
Alguns ajustes no “httpd.conf”
Recomendo fortemente que você não utilize a
opção “FollowSymLinks”
www.linuxsecurity.com.br
67
Se você acha que já está acabando, está
enganado, agora que começa a ficar
interessante.
Não esqueça de configurar a senha do LIDS:
-j GRANT
Qual tal uma regra de LIDS para permitir que o
daemon proftpd possa escrever no diretório “/
etc” das 11:00 as 11:15 (pouco usual é claro):
[root@lids ~]# lidsconf -P
MAKE PASSWD
enter new password:
reenter new password:
lidsconf -A -s /usr/sbin/proftpd -o /etc -t
1100-1115 -i -1 -j WRITE
Somente com estas 3 regras, eu tenho certeza
que a sua mente já imaginou o que é possível
fazer com o LIDS, fantátisco não ?
OBS: Sempre utilize senhas fortes, com
números, letras e símbolos.
Nesta etapa, já teremos todos os serviços/
daemons funcionando, sendo assim,
apenas nos focaremos na configuração das
ACL’s do LIDS.
E por isso eu disse que dependendo do
refinamento que você deseja fazer no seu
sistema, você terá muitas ACL’s para digitar na
mão e você pode ter certeza,
uma hora isso vai começar a ficar inconveniente.
Pensando nisso, eu resolví escrever um script
em shell, que lê um arquivo (/etc/lids/lids.objs)
em um formato um pouco mais simples, e monta
as regras para você, vejamos como ficariam as
regras acima:
OBS: Não prossiga com as configurações
caso alguma etapa anterior não tenha sido
executada com sucesso.
Em um sistema como o nosso, pode-se ter
facilmente mais de 100 ACL’s de LIDS, isso vai
depender muito do refinamento que cada um
desejará fazer quando estiver dominando a
ferramenta.
No nosso sistema teremos 121 ACL’s, estão
incluídas ACL’s para o boot correto do sistema e
também para o desligamento sem maiores
danos.
OBJ:/etc:0:READONLY
S U B : / u s r / s b i n / p r o f t p d : 1:GRANT:CAP_NET_BIND_SERVICE:20-21
SUB:/usr/sbin/proftpd:-1:WRITE:/etc:T(11001115)
Eu não sei você, mas eu achei este formato muito
mais simples e rápido de manter, vamos utilizá-lo
daquí pra frente. É sempre assim, o sysadmin
sempre quer automatizar algo, dizem as más
línguas, que não existe bicho mais preguiçoso que
o sysadmin, é claro, eu concordo com eles.
O script que lê este formato de arquivo e monta as
regras do LIDS, chama-se lidsconf.sh e foi
incorporado à distribuição do LIDS como contrib à
partir da versão 0.11.1, infelizmente este script lê
somente o formato para a versão do LIDS do kernel
2.2. Mas não se preocupe, nem tudo está perdido,
eu atualizei o script para a nova versão (kernel
2.4), ainda não está incorporado como contrib para
o LIDS 1.1.1r2, mas já pode ser obtido através do
endereço http://www.linuxsecurity.com.br/tools/IDS/
lidsconf-2.0.tar.gz .
Entendendo um pouco sobre
CAPABILITIES
Vamos ver como seria uma regra para tornar o
diretório “/etc” como somente leitura:
lidsconf -A -o /etc -j READONLY
Vejamos agora, como seria uma regra de LIDS
para permitir que o daemon proftpd pudesse
levantar na porta 20 e 21:
lidsconf -A -s /usr/sbin/proftpd -o
CAP_NET_BIND_SERVICE 20-21 -i -1
www.linuxsecurity.com.br
68
ACL’s
Todas estas ACL’s foram feitas/testadas em distribuições Linux baseadas em RedHat, pode ser
necessário fazer algumas adaptações caso a distribuição seja diferente.
Nosso arquivo “/etc/lids/lids.objs” com as ACL’s necessárias para o perfeito funcionamento de
todos os serviços e que o lidsconf realizará leitura:
OBS: Os PATH’s utilizados neste arquivo, estão de acordo com a instalação padrão dos serviços
em uma distribuição baseada em RedHat, altere conforme a sua necessidade.
——————————————————————————————————————
# Proteção de diretórios:
OBJ:/sbin:0:READONLY
OBJ:/bin:0:READONLY
OBJ:/boot:0:READONLY
OBJ:/etc:0:READONLY
OBJ:/lib:0:READONLY
OBJ:/usr:0:READONLY
OBJ:/root:0:READONLY
OBJ:/home:0:READONLY
OBJ:/var/log:0:APPEND
OBJ:/etc/shadow:0:DENY
OBJ:/etc/ssh/sshd_config:0:DENY
OBJ:/etc/ssh/ssh_host_key:0:DENY
OBJ:/etc/ssh/ssh_host_dsa_key:0:DENY
OBJ:/root/lidsconf.sh:0:DENY
OBJ:/service:0:READONLY
OBJ:/etc/lids:0:DENY
OBJ:/etc/httpd:0:DENY
OBJ:/home/httpd/html:0:DENY
OBJ:/var/log/httpd:0:DENY
# Boot do sistema:
SUB:/etc/rc.d/rc.sysinit:1:WRITE:/etc
SUB:/etc/rc.d/rc.sysinit:1:WRITE:/boot
SUB:/etc/rc.d/rc.sysinit:1:WRITE:/var/log
SUB:/etc/rc.d/rc.sysinit:1:GRANT:CAP_KILL
SUB:/etc/rc.d/rc.sysinit:1:GRANT:CAP_SYS_ADMIN
SUB:/etc/rc.d/rc.sysinit:1:GRANT:CAP_SYS_RAWIO
SUB:/etc/rc.d/rc.sysinit:1:GRANT:CAP_NET_ADMIN
SUB:/etc/rc.d/rc.sysinit:1:GRANT:CAP_SYS_MODULE
SUB:/etc/rc.d/rc.sysinit:1:GRANT:CAP_CHOWN
SUB:/etc/rc.d/rc.sysinit:-1:GRANT:CAP_DAC_OVERRIDE
SUB:/etc/rc.d/rc.sysinit:-1:GRANT:CAP_DAC_READ_SEARCH
www.linuxsecurity.com.br
69
# Funcionamento do sistema:
SUB:/sbin/hwclock:0:WRITE:/etc/adjtime
SUB:/sbin/hwclock:0:GRANT:CAP_SYS_TIME
SUB:/sbin/update:0:GRANT:CAP_SYS_ADMIN
SUB:/sbin/init:0:WRITE:/etc
SUB:/sbin/init:0:WRITE:/var/log/lastlog
SUB:/sbin/init:0:WRITE:/var/log/wtmp
SUB:/bin/bash:0:GRANT:CAP_SYS_RESOURCE
SUB:/bin/bash:0:WRITE:/root/.bash_history
SUB:/bin/login:0:READONLY:/etc/shadow
SUB:/bin/login:0:WRITE:/var/log/wtmp
SUB:/bin/login:0:WRITE:/var/log/lastlog
SUB:/bin/login:0:GRANT:CAP_SETUID
SUB:/bin/login:0:GRANT:CAP_SETGID
SUB:/bin/login:0:GRANT:CAP_CHOWN
SUB:/bin/login:0:GRANT:CAP_SYS_TTY_CONFIG
SUB:/bin/su:0:READONLY:/etc/shadow
SUB:/bin/su:0:GRANT:CAP_SETUID
SUB:/bin/su:0:GRANT:CAP_SETGID
SUB:/sbin/mingetty:0:GRANT:CAP_SYS_TTY_CONFIG
# Shutdown
SUB:/etc/rc.d/init.d/halt:-1:GRANT:CAP_KILL_PROTECTED
SUB:/etc/rc.d/init.d/halt:-1:GRANT:CAP_KILL
SUB:/etc/rc.d/init.d/halt:-1:GRANT:CAP_SYS_ADMIN
SUB:/etc/rc.d/init.d/halt:-1:GRANT:CAP_SYS_RAWIO
SUB:/etc/rc.d/init.d/halt:-1:GRANT:CAP_NET_ADMIN
SUB:/etc/rc.d/init.d/halt:-1:GRANT:CAP_SETUID
SUB:/etc/rc.d/init.d/halt:0:WRITE:/var/log/wtmp
SUB:/etc/rc.d/init.d/halt:0:WRITE:/var/log/lastlog
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_KILL_PROTECTED
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_KILL
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_SYS_ADMIN
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_SYS_RAWIO
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_NET_ADMIN
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_DAC_OVERRIDE
SUB:/etc/rc.d/init.d/killall:-1:GRANT:CAP_DAC_READ_SEARCH
# OpenSSH
SUB:/usr/sbin/sshd:0:READONLY:/etc/shadow
SUB:/usr/sbin/sshd:0:READONLY:/etc/ssh/sshd_config
SUB:/usr/sbin/sshd:0:READONLY:/etc/ssh/ssh_host_key
SUB:/usr/sbin/sshd:0:READONLY:/etc/ssh/ssh_host_dsa_key
SUB:/usr/sbin/sshd:0:WRITE:/var/log/wtmp
SUB:/usr/sbin/sshd:0:WRITE:/var/log/lastlog
www.linuxsecurity.com.br
70
SUB:/usr/sbin/sshd:0:GRANT:CAP_SETUID
SUB:/usr/sbin/sshd:0:GRANT:CAP_SETGID
SUB:/usr/sbin/sshd:0:GRANT:CAP_FOWNER
SUB:/usr/sbin/sshd:0:GRANT:CAP_CHOWN
SUB:/usr/sbin/sshd:0:GRANT:CAP_DAC_OVERRIDE
SUB:/usr/sbin/sshd:0:GRANT:CAP_SYS_TTY_CONFIG
SUB:/usr/sbin/sshd:0:GRANT:CAP_NET_BIND_SERVICE:22-22
SUB:/usr/sbin/sshd:0:GRANT:CAP_PROTECTED
SUB:/usr/bin/ssh:0:GRANT:CAP_NET_BIND_SERVICE:0-1024
# syslog-ng:
SUB:/sbin/syslog-ng:0:GRANT:CAP_CHOWN
SUB:/sbin/syslog-ng:0:WRITE:/var/log
# daemontools
SUB:/usr/local/bin/multilog:0:WRITE:/var/log/qmail
SUB:/usr/local/bin/svc:0:WRITE:/var/qmail/supervise
SUB:/usr/local/bin/supervise:0:WRITE:/var/qmail/supervise
SUB:/usr/local/bin/supervise:0:GRANT:CAP_KILL
SUB:/usr/local/bin/setuidgid:0:GRANT:CAP_SETUID
SUB:/usr/local/bin/setuidgid:0:GRANT:CAP_SETGID
# qmail
SUB:/var/qmail/bin/qmail-inject:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-rspawn:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-lspawn:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-queue:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-clean:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-send:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-remote:0:WRITE:/var/qmail/queue
SUB:/var/qmail/bin/qmail-send:-1:GRANT:CAP_DAC_OVERRIDE
SUB:/var/qmail/bin/qmail-send:-1:GRANT:CAP_DAC_READ_SEARCH
SUB:/var/qmail/bin/qmail-queue:0:GRANT:CAP_DAC_OVERRIDE
SUB:/var/qmail/bin/qmail-queue:0:GRANT:CAP_DAC_READ_SEARCH
SUB:/var/qmail/bin/qmail-start:0:GRANT:CAP_SETUID
SUB:/var/qmail/bin/qmail-start:0:GRANT:CAP_SETGID
SUB:/var/qmail/bin/qmail-lspawn:0:GRANT:CAP_SETUID
SUB:/var/qmail/bin/qmail-lspawn:0:GRANT:CAP_SETGID
SUB:/var/qmail/bin/qmail-lspawn:0:GRANT:CAP_DAC_OVERRIDE
SUB:/var/qmail/bin/qmail-lspawn:0:GRANT:CAP_DAC_READ_SEARCH
SUB:/var/qmail/bin/qmail-rspawn:-1:GRANT:CAP_NET_BIND_SERVICE:1-1023
SUB:/var/qmail/bin/qmail-local:1:WRITE:/home
# Apache
SUB:/usr/sbin/httpd:0:GRANT:CAP_NET_BIND_SERVICE:80-80
www.linuxsecurity.com.br
71
SUB:/usr/sbin/httpd:0:GRANT:CAP_SETUID
SUB:/usr/sbin/httpd:0:GRANT:CAP_SETGID
SUB:/usr/sbin/httpd:0:READONLY:/etc/httpd
SUB:/usr/sbin/httpd:0:READONLY:/home/httpd
SUB:/usr/sbin/httpd:0:WRITE:/var/log/httpd
# ProFTPD
SUB:/usr/sbin/proftpd:-1:GRANT:CAP_SETUID
SUB:/usr/sbin/proftpd:-1:GRANT:CAP_SETGID
SUB:/usr/sbin/proftpd:-1:GRANT:CAP_SYS_CHROOT
SUB:/usr/sbin/proftpd:-1:GRANT:CAP_NET_BIND_SERVICE:20-21
SUB:/usr/sbin/proftpd:-1:READONLY:/etc/shadow
SUB:/usr/sbin/proftpd:-1:WRITE:/home/httpd/html
# Mail - Você vai precisar destas regras caso utilize o comando “mail” para
# enviar e-mails a partir do console
SUB:/bin/mail:0:GRANT:CAP_SETGID
SUB:/bin/mail:0:WRITE:/root
SUB:/bin/mail:0:WRITE:/home
—————————————————————————————————————————
Se você ainda não baixou o script lidsconf.sh, então faça isso agora, e rode-o no seu sistema,
se você não digitou nada errado, ele apresentará:
[root@lids ~]# ./lidsconf.sh
=========================================================
Read objects : 121
Errors: 0
Inserted objects successfully: 121
=========================================================
Se existirem erros, veja o arquivo de log (/var/log/lids.log) do script para maiores informações
sobre o erro.
Depois desta longa jornada de configurações, finalmente você pode rebootar o seu Linux com o
novo kernel e experimentar o fruto do seu trabalho, esta é a melhor parte !
Muito cuidado com a falsa sensação de segurança que o LIDS pode passar, pois ele é simplesmente
o espelho da sua confiança no sistema, as ACL’s aquí descritas oferecem um alto grau de
confiabilidade, mas não corrigem problemas como:
1 - utilização de senhas 1234, RG, data de nascimento, etc
2 - criar usuário de ftp com shell válido
3 - passar senhas de ftp e ssh por ICQ, e-mail e qualquer outro meio não
www.linuxsecurity.com.br
72
criptografado
4 - permitir que usuários estranhos façam
upload de código php sem auditoria
5 - o servidor fica em cima da mesa da
secretária
6 - não tem senha na BIOS e dá boot por
CDROM e disquete
7 - etc, etc, etc
Referências:
http:/www.lids.org
http://www.linuxsecurity.com.br/info/eventos/
lids-fisl2002
http://www.linuxsecurity.com.br/
sections.php?op=viewarticle&artid=25
http://lists.sourceforge.net/lists/listinfo/lids-user
http://www.apache.org
http://www.php.net
http://www.proftpd.net
http://www.qmail.org
http://cr.yp.to/daemontools.html
http://cr.yp.to/ucspi-tcp.html
http://www.balabit.hu/en/downloads/syslog-ng
www.linuxsecurity.com.br
FICHA
do
AUTOR
Nome:
Rodrigo Pereira Telles
Idade:23 anos
e-mail: [email protected]
Administrador de Sistemas UNIX
Consultor de Segurança
Desenvolvedor de ferramentas GPL:
-Webtools ->
http://webtools.linuxsecurity.com.br
- Securitylog2html/netfilter2html ->
http://webtools.linuxsecurity.com.br
- qmail-filter/queue-admin ->
http://qmail.linuxsecurity.com.br
O Mantenedor/Desenvolvedor de conteúdo
do site http://www.dicaslinux.com.br
O Colunista, desenvolvedor e representante
da LinuxSecurity Brasil Solutions
http://www.linuxsecurity.com.br
O Palestrante da III ExpoSALT (Exposição
de Sistemas Alternativos) no Rio de Janeiro
sobre Webtools e incentivo ao
desenvolvimento de sistemas alternativos.
O Palestrante do III Forum Internacional de
Software Livre em Porto Alegre sobre LIDS
73
www.linuxsecurity.com.br
74
www.linuxsecurity.com.br
75