Neste artigo abordaremos alguns "Security Hacks" para sistemas Linux e *BSD, ou seja, implementações simples que irão ajudar você a melhorar a segurança de seus servidores. Vamos conhecer algumas dicas matadoras e softwares que farão a diferença nesta empreitada.
Bom, não irei me ater em explicar a definição de fingerprinting aqui no artigo, pois o conceito é muito difundido na internet, quem quiser conhecer mais sobre este conceito por favor fique à vontade de parar a leitura e fazer uma breve busca no Google.
Vou dar uma idéia esdrúxula sobre o conceito. Finger print significa impressão digital, todo sistema operacional tem o seu fingerprint, que irá revelar o tipo de sistema operacional em questão.
Existem ferramentas que coletam essas informações que serão muito úteis para o atacante em potencial. Um das mais difundidas ferramentas e de mais fácil uso é o "nmap", escrito pelo sr. Fyodor ( www.insecure.org ).
Vamos verificar um ataque coletando o fingerprint do sistema:
# nmap -O test.rootsec-labs.net
Starting nmap 3.45 ( www.insecure.org/nmap ) at 2004-06-02 at 15:00 MST
Interesting ports on test.rootsec-labs.net
(The 1653 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
13/tcp open daytime
22/tcp open ssh
37/tcp open time
113/tcp open auth
Device type: general purpose
Running: OpenBSD 3.X
OS details: OpenBSD 3.0 or 3.3
Nmap run completed -- 1 IP address (1 host up) scanned in 24.873 seconds
Como podemos observar, o nmap coletou o fingerprint do sistema e nos retornou o sistema operacional que o servidor alvo utilizava, no caso um OpenBSD.
Agora o que poderíamos fazer em nosso OpenBSD para bloquear essa técnica? Vamos adicionar algumas regras ao nosso pf.
Para bloquear vamos adicionar algumas regras como essas a seguir em nosso /etc/pf.conf:
set block-policy return
block in log quick proto tcp flags FUP/WEUAPRSF
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF
block in log quick proto tcp flags SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF
Pacotes que acionem estas regras pode ser facilmente analisados usando o tcpdump, usando os seguintes comandos:
# ifconfig pflog0 up
# tcpdump -n -1 pflog0
Bom, agora depois de adicionadas as regras ao nosso servidor, vamos fazer o teste para verificar se o nmap consegue pegar o fingerprint:
# nmap -O test.rootsec-labs.net
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-02 22:56 MST
Interesting ports on teste.rootsec-labs.net
(The 1653 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
13/tcp open daytime
22/tcp open ssh
37/tcp open time
113/tcp open auth
No exact OS matches for host (If you know what OS is running on it, see
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.48%P=i686-pc-linux-gnu%D=12/2%Time=3FCD7B3F%O=13%C=1)
TSeq(Class=TR%IPID=RD%TS=2HZ)
T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=Y%W=0%ACK=O%Flags=AR%Ops=)
T4(Resp=Y%DF=Y%W=4000%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
Nmap run completed -- 1 IP address (1 host up) scanned in 27.028 seconds
Como podemos ver, o nmap se confundiu e nos liberou um Gnu/Linux entre as fingerprints.
Recomendo uma leitura aprofundada do assunto para utilizar técnicas como esta em outros sistemas.
[5] Comentário enviado por engos em 08/07/2004 - 11:18h
Fiz um artigo praticamente sobre o mesmo assunto, mas diria que seria um pré-requisito para o seu, só estou esperando ser postado... seria legal ter uma crítica sua que com esse artigo ganhou meu respeito.
O interessante é que você colocou bastante coisa importante e explicou algumas, mas outras não.
Tirando as explicações que ficaram faltando, outras estão um pouco fraca, acho que isso foi um erro do artigo, pois deixou algo do tipo: "Aqui estão os comandos, se virem para saber se podem ou não fazer e o que vai/pode acarretar futuramente".
No geral gostei do artigo como um todo, mas achei muito fraca a explicação, pois nem todos vão entender o que você colocou, eu mesmo fiquei com muitas dúvidas no Snort.
Continue com os artigos que esse foi interessante...
[6] Comentário enviado por y2h4ck em 08/07/2004 - 22:07h
Caro Engos, obrigado pela crítica... alguns termos quero deixar claros.. como disse no início do Artigo, eu não considero ele como um "como fazer" mas sim um " como buscar ". Quero mostrar algumas soluções interessantes para o pessoal, como vc disse algumas eu dei mais atenção devido a não serem tão trivais, como por exemplo fuzzy no OpenBSD ... poucos aqui ja utilizaram. Questão do snort... no próprio site do snort temos muita documentação em PDF mostrando como fazer regras para o mesmo e então decidi não gastar o tempo falando sobre algo ja tão documentendo.
[7] Comentário enviado por y2h4ck em 08/07/2004 - 22:21h
ah só pra completar a questão de "Aqui estão os comandos, se virem para saber se podem ou não fazer e o que vai/pode acarretar futuramente", não sei onde o senhor viu isso ... porem apenas disse que PESQUISAS SE FAZEM NECESSÁRIAS... alguem que cre piamente em algo que leh ... realmente não está apto a fazer nada ... devemos ler e pesquisar sobre o assunto que lemos... como disse ... e um "como pesquisar"... portanto, encerro aqui o ensejo :)
[9] Comentário enviado por agk em 08/07/2004 - 22:50h
Ótimo artigo, ajuda a abrir os olhos para alguns pontos importantes para a proteção do sistema, que comumente passam desapercebidos pelos administradores de segurança/redes.
[11] Comentário enviado por mrfreeze em 09/07/2004 - 00:05h
Otimo artigo.
Achei muito boa a ideia de dar um overview de assuntos variados sobre a seguranca de sistemas *BSD e Linux.
Considero esse metodo muito eficiente para liberar a imaginacao dos leitores. Essas pequenas dicas "liberam a mente dos leitores" deixando eles livres para pesquisarem o assunto que lhes forem uteis.
[13] Comentário enviado por removido em 30/10/2004 - 20:33h
A minha compilação - mdk 10.0 dá o seguinte erro:
Cracktest.c:6:19: crack.h: No such file or directory
Cracktest.c: In function `main':
Cracktest.c:14: error: parse error before '{' token
Cracktest.c: At top level:
Cracktest.c:18: error: parse error before "else"
Cracktest.c:21: warning: parameter names (without types) in function declaration
Cracktest.c:21: error: conflicting types for `exit'
/usr/include/stdlib.h:612: error: previous declaration of `exit'
Cracktest.c:21: warning: data definition has no type or storage class
[23] Comentário enviado por fabri em 10/10/2006 - 16:15h
Achei este artigo Módulo Security News , que voces acham......
Tô cum mêdo...
fabri
"Softwares de código aberto têm mais brechas de segurança que proprietário, diz pesquisa
Aplicativos proprietários são em média cinco vezes mais seguros se comparados a projetos open source
Da redação
DATA - 09 Out 2006 FONTE - Módulo Security News
O Departamento de Segurança Nacional dos EUA, em parceria com a Universidade de Standford e a desenvolvedora de software Coverity, analisou os 50 maiores projetos de software de código aberto na atualidade e concluiu que eles apresentam mais brechas de segurança do que softwares de código proprietário.
A análise feita pelas três instituições demonstra que o código proprietário é, em média, cinco vezes mais seguro. O estudo utilizou um detector de erros automático e nenhum software de código aberto dos projetos avaliados apresentou um número menor de vulnerabilidades em comparação a aplicativos proprietários. Como exemplo, a pesquisa citou que um código proprietário desenvolvido por uma empresa aeroespacial apresenta um nível de segurança cinco vezes maior que o mais seguro dos códigos open source."
[24] Comentário enviado por slaypher em 26/01/2007 - 19:39h
Olá,
Um bom artigo mesmo, mas gostaria de saber, é possível aplicar FPFuzzy em máquinas GNU/Linux? Eu procurei na Internet e não encontrei nada que me ajudasse a fazer isso. Alguma dica?