Já é sabido que a maior vulnerabilidade dentro das empresas ou mesmo computadores pessoais são justamente os próprios funcionários ou usuários.

Manter uma boa política de senhas é fundamental para garantir a segurança básica de suas informações e tentar minimizar as chances de alguém ter acesso indevido a elas.

Vou apresentar dicas simples para uma boa política de senhas que vão além das dicas comuns como “mantenha uma senha que contenha mais de 8 caracteres, sendo eles números, letras minúsculas, maiúsculas e caracteres especiais…”.

Em escritórios é importante haver também uma política de troca de senha regular. Mas, como forçar os usuários a seguirem essa política de troca de senha regular? Evitando que o mesmo se logue caso não troque a senha de forma periódica, claro.

Vamos começar pelo básico.

1- Definindo a complexidade das senhas de usuários:

Para definir a complexidade, precisaremos alterar a configuração de definição de senhas de usuários. O processo pode ser diferente, de acordo com a sua distribuição.

Arch Linux:

Edite o arquivo passwd que se encontra em /etc/pam.d/passwd, da seguinte forma:

# vim /etc/pam.d/passwd

Debian, Ubuntu, RedHat, CentOS e outras:

# vim /etc/pam.d/system-auth

Configure sua linha de senha de forma que fique algo parecido com o seguinte:

password       required        pam_cracklib.so difok=3 minlen=10 ucredit=3 ocredit=2 retry=3

Onde:

difok=3 -> Informa a quantidade de caracteres que podem se repetir em relação à última senha. Por exemplo: Se minha antiga senha era “kalib” e eu tento usar “kalamba” como nova senha, receberei uma informação de erro, pois eu repeti 3 letras que já existem na senha anterior “kal”.

minlen=10 -> Informa qual a quantidade mínima de caracteres aceitos para a senha do usuário. No exemplo, o mínimo de caracteres aceitos serão 10, caso contrário será apresentada uma mensagem de erro solicitando que o usuário tente uma nova senha.

ucredit=3 ->Informa a quantidade de letras maiúsculas que deverão compor minha senha. No exemplo, eu precisarei utilizar no mínimo 3 letras em maiúsculo, ou “Uper Characters” em minha nova senha.

ocredit=2 -> Informa a quantidade de “outros caracteres” ou caracteres especiais, como por exemplo *, &, %, $, _, etc.

retry=3 -> Informa quantas vezes o usuário vai poder tentar, em caso de senha indevida, antes de receber a mensagem de erro.

Outros parâmetros que podem ser utilizados são os seguintes:

dcredit=x -> Informa a quantidade de dígitos que deverão ser utilizados como números na senha, onde x é o número mínimo desejado.

lcredit=x -> Informa a quantidade de caracteres minúsculos, ou “Lower Characters”, mínimos em sua senha.

2- Definindo que a nova senha não poderá ser igual às anteriores:

No mesmo arquivo do ponto anterior, iremos inserir o parâmetro remember na linha conforme exemplo:

password sufficient pam_unix.so use_authtok md5 shadow remember=10

remember=10 -> Informa que a nova senha não poderá ser igual às últimas 10 senhas utilizadas por este usuário.

Agora que já sabemos como definir uma política para criação de senhas seguras, vamos conhecer o “chage“, que nos ajudará a definir a política de datas ou validade das senhas.

3- Checando as políticas de validade de senhas de um determinado usuário:

# chage -l usuário

O comando acima verifica os atributos de validade daquela senha, e lhe retornará algo similar ao seguinte:

Last password change : May 11, 2011

Password expires : never

Password inactive : never

Account expires : never

Minimum number of days between password change : 0

Maximum number of days between password change : 99999

Number of days of warning before password expires : 7

 
As informações acima apresentam dados como data de última mudança de senha, data de expiração, tempo de inatividade, quantidade mínima de dias para se trocar a senha antes de a mesma expirar, etc.
 
4- Criando uma “validade” ou período de expiração para a senha de um determinado usuário:

# chage -M 99999 linustorvalds

 
Este comando vai desabilitar o período de validade da senha, informando que a mesma não expira nunca.
 

# chage -M 50 -m 7 -W 7 linustorvalds

 
Este comando aplica a política de senha para o usuário “linustorvalds” onde:
-M 50 -> Define que a senha será válida por um máximo de 50 dias, quando a mesma deverá ser trocada.
-m 7 -> Define o número mínimo de dias em que o usuário poderá trocar sua senha antes do período especificado para expiração. Caso o usuário possa trocar a qualquer momento ou dia, o valor deverá ser 0.
-W 7 -> Número de dias antes de expirar nos quais o usuário vai receber alertas informando que sua senha irá expirar.
 
Caso você deseje especificar um dia exato no qual a senha de determinado usuário vai expirar, você pode utilizar o parâmetro -E seguido da data desejada no formato AAAA-MM-DD.
 
Além disto, você pode desejar que a senha do usuário “linustorvalds” seja trocada no próximo login do mesmo. Neste caso você poderá utilizar o parâmetro -d, conforme exemplo abaixo:

# chage -d 0 linuxtorvalds

 
O -d significa quantidade de dias também.
 

É isso pessoal.

Have fun!

Para aqueles que também não curtem de forma alguma a aparência padrão GTK do Wicd e não conhecem ainda a interface que foi lançada posteriormente em QT, fica a dica: Troquem com urgência!

E o network-manager?

Bom, o network-manager é um excelente(sendo modesto) gerenciador de redes para o Linux, porém infelizmente ele peca muito em sua interface para o KDE. Compare o network-manager em suas interfaces gtk (Gnome) e qt (KDE) e entenderá o que eu digo. A versão para KDE é extremamente confusa e bagunçada em comparação com a interface para o Gnome.

Eis que muitas distribuições começaram a sugerir a utilização do Wicd como gerenciador de redes para quem utiliza o KDE.

No Arch, por exemplo, encorajamos fortemente o uso do Wicd com o KDE ao invés do network-manager. Sim, sempre utilizei ele, porém…

E então? Meio bizarro, certo?! Alguém havia pensado em dizer “Mas ele não é tão feio..”?

Bom, que tal apresentar uma alternativa a isto? O wicd-kde!

Como uma imagem vale mais que mil palavras:

Mais amigável certo? Uma interface mais limpa, organizada e bonita. Bem ao estilo “clean”, como alguns preferem dizer.

Mas, deixando um pouco a frescura de lado. Não recomendo a utilização da interface em qt apenas por questões de estética.

A verdade é que o seu ambiente fica mais limpo com esta interface. Limpo? Sim.

Se você utiliza o KDE mas possui aplicações em gtk, por consequência você possuirá uma série de bibliotecas instaladas em seu ambiente para fazer com que esta aplicação em gtk funcione da maneira correta. Porém, se você instala uma aplicação em qt, pouca coisa adicional será necessária, visto que seu sistema já está preparado para rodar este tipo de aplicação.

Digamos que é uma união: Útil ao Agradável!

E a parte que interessa? Instalar, instalar, instalar!

Infelizmente, nem todas as distribuições empacotaram o wicd-kde até então, mas se você é usuário Arch Linux, a sua vida será mais fácil.

O pacote wicd-kde encontra-se pronto no AUR.

O processo é o já manjado:

1- Baixar o arquivo compactado:

$ wget http://aur.archlinux.org/packages/wicd-client-kde-git/wicd-client-kde-git.tar.gz

2- descompactar:

$ tar -xvzf wicd-client-kde-git.tar.gz

3- entrar no diretório e em seguida executar o PKGBUILD para geração do pacote em si:

$ cd wicd-client-kde-git

$ makepkg

4- Instalar o pacote gerado:

# pacman -U wicd-client-kde-git-20110426-1-x86_64.pkg.tar.xz

Feito. ;]

Have Fun!

Abraços!

Se você é ou conhece algum usuário de Arch Linux aqui no Ceará, favor entrar em contato.

Infelizmente não estamos em condições de oferecer recompensas financeiras pelas denúncias ou comparecimentos voluntários. Quem sabe, uma cervejinha ou duas, até que rola.

Brincadeiras a parte, de fato estamos buscando usuários do Arch Linux em nosso estado.

O fato é que o Arch Linux Brasil como um todo vem começando uma campanha de “localização” de usuários em diversos estados como uma forma de estreitar as relações entre estes. A ideia é procurar uma forma de fazer com que os usuários de Arch Linux possam ter uma maior interação entre si, o que facilita na organização de encontros, eventos, install fests, etc.

No momento estamos mapeando e buscando interessados na ideia, portanto fica o convite:

Se você é usuário do Arch Linux e mora no Ceará ou conhece algum usuário do Arch Linux por aqui, passe a informação.

Por favor se identifique através do seguinte link: http://forum.archlinux-br.org/viewforum.php?id=20

Abraços!

Cansado de apenas poder assistir aquele webcast ou vídeo-aula online? E se estiver em um local sem conectividade? Porque dor de cabeça? Sou usuário Linux! Obrigado por ter a ideia de criar o Linux e facilitar nossas vidas Linus. ;]

Recentemente me deparei com esta problemática. Como realizar o download deste tipo de conteúdo?

Ao checar o código fonte da página que exibia o vídeo, vi que eram streamings dos protocolos mms ou rtmp, o que, aparentemente, dificultava o download.

Para quem mais estiver passando por este problema, segue a solução. Aliás, as soluções.

Uma vez que, através do código fonte você consiga identificar a URL completa do arquivo mmc ou rmtp, fica fácil utilizar alguma das metodologias a seguir.

A primeira opção é a aplicação Mimms.

Esta é a forma mais simples e prática com arquivos do tipo mms.

Para usuários do Arch Linux, já existe um pacote pronto no AUR.

A instalação, segue o padrão de arquivos baixados do AUR:

1- Download do Tarball;

2- Descompatar: $ tar -xvzf mimms.tar.gz

3- Acessar o diretório e efetuar a compilação do pacote: $ cd mimms && makepkg

4- Instalar o pacote que lhe foi gerado: # pacman -U mimms-3.2.1-2-any.pkg.tar.xz

Feito. Agora é só executar da seguinte forma:

$ mimms mms://url_de_origem_do_streaming/arquivo_streaming.wmv

Será que isso funciona mesmo? Experimente:

$ mimms mms://wms.andrew.cmu.edu/001/pausch.wmv

Oi, simples assim.

Outra alternativa?

Utilizando o Mencoder:

Não é tão simples quanto o mimms, mas também é rápido e prático.

O comando que deve ser utilizado?

mencoder mms://url_de_origem_do_streaming/arquivo_streaming.wmv -o arquivo_streaming.wmv -oac copy -ovc copy

Um pouco mais complexo, certo? Mas funciona.

E quanto aos arquivos de streaming que utilizam o protocolo rtmp?

Neste caso a opção é utilizarmos o rtmpdump.

Sim, claro.. Se você utiliza o Arch Linux, sua vida continua simplificada:

# pacman -S rtmpdump

Pronto, está instalado. ;]

A execução do mesmo também é bastante simples, precisando apenas especificar a origem e o destino do streaming em questão. Segue sintaxe:

rtmpdump -r “rtmpe://url_de_origem_do_streaming/arquivo_streaming.wmv” -o arquivo.streaming.flv –resume

Have fun! ;]

Abraços!

Banner do Flisol quixadá

Saudações galera!

Algumas pessoas já me perguntaram nos últimos 3 dias porque eu não estava no Flisol Fortaleza este ano. “Cara, nem lhe vi lá pelo Flisol correndo pra cima e pra baixo esse ano.”

Bom, como eu havia informado anteriormente, mas nem todos devem ter notado (certo Rodrigo, hehehe), este ano estive no Flisol de Quixadá. A oportunidade de palestrar por lá surgiu e resolvi mudar o ambiente do meu Flisol este ano.

Logo na sexta-feira, dia em que cheguei em Quixadá, tive duas boas primeiras impressões:

1- O clima estava melhor do que o de Fortaleza. Sim, já não aguentava mais o nosso calor infernal. Por mais que eu já estivesse esperando um calor ainda maior, fiquei surpreso ao perceber que o tempo estava mais fresco. Talvez por conta da umidade…

2- Poucos minutos depois de minha chegada esbarro com o Ronaldo, também membro da Tux-CE, que optou por também palestrar no Flisol de Quixadá. Nos esbarramos no Hotel mesmo, já que acabamos ficando no mesmo.

Já que citei o Hotel, gostaria de fazer dois agradecimentos. Primeiro ao Samy e demais membros da organização que possam ter feito os contatos com hotéis e agilizado nossa reserva por lá. Obrigado Samy e demais envolvidos. Segundo, a todos do Hotel Monólitos que nos receberam super bem e prestaram um excelente serviço. Sim, NOS receberam bem. Porque plural? Pelo fato de minha namorada, Mari, ter ido também para Quixadá. Acho que também devo agradecer a ela pelo apoio que me deu e boa vontade (saco e paciência) de assistir minha palestra bem como outras durante todo o dia do evento. ;]

Logo na sexta aproveitamos para descansar depois de uma semana corrida de trabalho em Fortaleza. Eu, Mari e Ronaldo fomos para um restaurante que ficava próximo ao Hotel, onde tomamos umas cervejinhas e comemos uma excelente carne. No domingo fui descobrir que neste mesmo restaurante fazem a melhor bisteca que já comi na minha vida. Portanto, se alguém tiver a chance de visitar Quixadá, não deixe de comer uma bisteca caprichada no Ponto da Bisteca. O Araújo, que estava no time de organização do evento, acabou nos encontrando por lá rapidamente nesta noite.

No sábado, optei por ir bem cedo ao evento. Sim, gosto de ver as coisas por trás dos bastidores. Não gosto de apenas chegar, palestrar e ir embora. Minha primeira surpresa do dia? Uma equipe de aproximadamente 30 pessoas na equipe de organização do Flisol! o.O Bom, sei que no dia já parabenizei a todos eles, várias vezes por sinal, mas deixo novamente os parabéns. Estive envolvido direta ou indiretamente em todas as edições do Flisol Fortaleza desde o ano de 2006 e nunca vi uma equipe de organização com tanta gente disposta a ajudar. Vocês estão de parabéns.

Membros da organização - Mesa de credenciamento

Depois de “participar” como ouvinte da primeira reunião do dia com a equipe de organização do evento, os preparativos de última hora começaram e aproveitei para conhecer o local do evento, dar uma volta, etc. O evento aconteceu na Faculdade Católica Rainha do Sertão, que por sinal é linda e bem arborizada.

O evento contou com duas apresentações de abertura: Um show de humor e um grupo de dança. Infelizmente não lembro o nome do Humorista ou do grupo de dança para deixar os devidos créditos. Mas, ambos estão de parabéns também.

Ainda durante a apresentação de humor tive minha segunda surpresa do dia. Um dos integrantes do time de organização me chamou para um canto mais afastado do ginásio e me fez um convite para uma breve filmagem que eles estavam preparando. Como não estava esperando por isso, acabei tendo de improvisar algo. Mas deu tudo certo, espero. o.O

Em seguida tive minha terceira surpresa do dia. O evento contou com uma rápida mesa de cerimônia para abertura oficial do evento, para a qual fui convidado de surpresa, Samy vocẽ me paga onde foi dada uma breve explicação sobre o intuito e importância do evento bem como do Software Livre como um todo para a comunidade em geral.

Mesa de cerimônia na abertura do evento

Mesa de cerimônia na abertura do evento

Mesa de cerimônia - "Milagre, Marcelo não citou ou mostrou nada do Arch?" Sim, a camisa.

Após esta breve apresentação foram iniciadas as palestras. E como fui o primeiro palestrante do dia, tive a minha quarta surpresa no evento. Sim, muitas surpresas logo no período da manhã. hehe

Início de minha palestra sobre cultura hacker

A surpresa? A enorme quantidade de pessoas que estavam ali sentadas assistindo minha palestra. Por achar que não teria a menor condição de palestrar sem microfone acabei optando por utilizar o microfone e subir no palco que, até então, só havia sido utilizado para a apresentação de dança. De lá eu poderia ter uma visão melhor do público, bem como eles de mim. Apenas lá de cima pude ver a real quantidade de pessoas. Não tenho números, mas eram muitas. Talvez o Samy possa dar alguma média aqui nos comentários do blog!? Por outro lado, acho que as fotos falam por si só.

Platéia durante minha palestra

Platéia durante minha palestra - Ronaldo e Mari no canto direito

Platéia durante minha palestra

Abordei dois temas:

1- Cultura Hacker – Tenha ética e ganharás respeito

2- Software Livre – Nunca vi nem comi, eu só ouço falar

Casa cheia, certo?

Eu realmente não esperava tanta gente. Bom saber que em Quixadá temos tantas pessoas interessadas em conhecer algo novo. As possibilidades são enormes e as chances de saírem dali futuros militantes do software livre são óbvias.

Após a minha palestra o evento teve uma pausa para o almoço. Eu e a Mari aproveitamos para passear mais um pouco e ver como andava o movimento do lado de fora do ginásio onde se encontrava o Sertão em Rede. Do que se trata este Sertão em Rede? É um projeto que visa a inclusão socio-digital. Imagine um tele-centro para capacitação, oficinas, etc. Agora imagine um ônibus para levar o equipamente do tele-centro as mais diversas cidades.  Legal, certo? E se ambos fossem um só? O tele-centro e o ônibus? Sim, é isso mesmo. O ônibus que leva o tele-centro é o próprio tele-centro. Equipado com máquinas com Linux, ar-condicionado, lousa, cadeiras, mesas e toda a estrutura necessária para se realizar um curso ou capacitação qualquer. Sim, ele também possuí conectividade com a Internet, do contrário não poderia se chamar Sertão em Rede, certo?! Particularmente, achei brilhante. Parabéns aos responsáveis pelo projeto bem como ao Flisol por ter levado o Sertão em Rede para ser apresentado no evento.

Ônibus Sertão em Rede

Ambiente interno do Ônibus Sertão em Rede

Ambiente interno do Ônibus Sertão em Rede

Ainda nesta pausa para o almoço pude reparar nos ônibus que estavam estacionados no local. Sim, vieram muitas pessoas de outras cidades próximas para o evento como podem ver na foto abaixo. ;]

Ônibus que vieram de outras cidades próximas

Claro, não posso deixar de citar o almoço. Acredito que a Mari e os demais tenham gostado tanto quanto eu. Excelentes peixes, frito e cozido com molho de camarão, carne de sol, etc. Obrigado Samy Soares e Italo Bethoven por terem nos convidado para apreciar a excelente culinária do restaurante Abelardo.

No período da tarde aconteceram demais palestras e atividades previstas do evento como sala de games, sala de vídeos, install-fest, etc. Aproveitei para assistir algumas palestras, infelizmente não tinha como assistir todas, e visitar as demais atividades do evento.

Sala de Games

Sala de palestras - Palestra sobre HTML5 com George Gomes, SEDUC

Palestra O que o Software Livre Pode Fazer Por Você – Marcelo “Bill”, F13

Conheci novas pessoas e pude rever alguns velhos amigos e companheiros como o Marcelo “Bill” da F13 Informática e o Pedro Henrique, também membro da Tux-CE. Ambos palestraram no período da tarde.

Claro, no final da tarde todos estavam esgotados e optamos por nos recolher em nossos respectivos hotéis/casas para um banho e rápido descanso antes de nos encontrarmos novamente para o jantar.

Bom, cá entre nós. É fácil para o Samy combinar de tomarmos banho e descansarmos por cerca de 2 horas até ele voltar e nos encontrarmos para o jantar. Ele mora lá. Mas, nós estavamos como visita. Descansar? Ficar deitado? Isso nós podemos fazer em casa, certo?

Depois que eu e Mari terminamos o banho e descemos para o térreo do Hotel, já estavam por lá prontos também o Ronaldo, Pedro, Bill, sua namorada Poliana e outro camarada cujo nome, infelizmente, não lembro. Então já começamos uma pequena roda ali mesmo na fachada do hotel onde tomamos umas cervejinhas e tivemos um papo descontraído enquanto aguardávamos o Samy, que chegou com uma pontualidade que impressionaria qualquer britânico.

De lá pegamos a estrada e fomos jantar no restaurante Pé de Serra. Não fica exatamente em Quixadá. Digamos que fica entre Quixadá e Quixeramobim. O restaurante é lindo e a comida é divina. Foi excelente pois, já com a mente menos acelerada, pudemos bater um papo legal. Tirando algumas indecências insanas saídas da mente do Bill, tudo o mais foi tranquilo.

Após a janta resolvemos ir para um pub chamado Bom Motivo, onde estava acontecendo um tributo ao eterno Raul Seixas. O local era bem aconchegante e animado. Talvez por isso a casa estivesse com tanta gente. Com isto fechamos a confraternização de pós-flisol.

No Domingo apenas descansamos no Hotel e rodamos um pouco pelas ruas da cidade. No período da tarde conheci a tal bisteca do Ponto da Bisteca. Sem comentários. Será que eles fazem entrega em domicílio se eu disser que meu endereço fica em Fortaleza? o.O

Novamente, obrigado a todos pela recepção e hospitalidade e parabéns pelo excelente evento.

Espero que boa parte do público tenha absorvido as ideias e sementes que ali foram plantadas pelo pessoal da organização e palestrantes como um todo. Que ideias sejam trocadas e fortalecidas.

Mais fotos do evento? Clique aqui!

Abraços!

Estranho o título?

Bom, de fato foi o que aconteceu. O KDE 4.6.2 foi lançado e para demonstrar que a briga entre usuários KDE x GNOME simplesmente não faz sentido, esta release foi batizada de “Congrats“, parabéns em português, em homenagem ao lançamento do GNOME 3 que teve mesma data.

Realmente é deplorável quando as listas, fórums e canais estão infectados com insultos contra ambiente gráfico X ou distribuição Y. É claro que sempre vão existir diferenças e brincadeiras sobre qual é o melhor, quem tem vantagem, etc. Afinal, somos humanos e temos gostos diferentes, certo?! Assim como existem piadas e brincadeiras entre torcedores de times opostos, no mundo da computação isso sempre vai existir também. O problema é quando se torna algo de mal gosto ou agressivo.

Enfim…

Para demonstrar que o projeto KDE realmente não liga para estas briguinhas infantis, e que não encara o projeto GNOME como um oponente que deve ser batido, a nova release do KDE 4.6.2 recebeu o nome de “Congrats” para homenagear o tão esperado lançamento do GNOME 3. Segue um pequeno trecho traduzido da notícia oficial no site do KDE:

“Com o codinome “Congrats” (parabéns) dedicamos este lançamento para os nossos amigos no lado GNOME, que lançam uma nova versão principal hoje.”

The KDE Plasma Netbook Workspace

Muitas melhorias chegaram com esta release, no geral correções de bugs ou melhorias de performance. Para detalhes do changelog, acesse este link.

Claro, se você é usuário Arch Linux, já pode ter o seu KDE 4.6.2, que encontra-se disponível nos repositórios do pacman. Basta atualizar seu sistema, caso já tenha o KDE instalado em outra versão: pacman -Syu

Que isto sirva de exemplo para nós, usuários. ;]

Abraços!

Você sabe o que é rootkit?

Nunca vi, nem comi, eu só ouço falar!

É um vírus? É um trojan? É um spyware? Não, é um rootkit mesmo.

A verdade é que ainda não existe um consenso em relação ao que o rootkit é de fato. Muitos dizem que é um tipo de vírus, alguns dizem que é um trojan, como você chamaria? Eu prefiro chamar de malware, que, ao pé da letra, seria um termo utilizado para algum aplicativo contendo código malicioso. o.O Acho que seria um meio termo aceitável para que possamos utilizar como base.

Mas esse bicho morde? É de comer?

Bom, em tese um Rootkit é um tipo de malware, como expliquei acima, cuja principal intenção é se camuflar, impedindo que seu código seja encontrado por qualquer antivírus.

Teoricamente, é exatamente isto que ele tenta fazer. Passar despercebido. De fato a grande maioria dos antivírus não são capazes de rastrear Rootkits justamente por conta do seu comportamento. É aí que surgiram ferramentas especializadas neste tipo de busca. Alguns antivírus, os mais caros, já agregam excelentes ferramentas para buscar rootkits. Mas, como eles conseguem se camuflar tão bem?

Estas aplicações, rootkits, têm a capacidade de interceptar as solicitações feitas ao sistema operacional, podendo alterar o seu resultado.

Imagine que você está utilizando sua máquina e seu sistema operacional solicita a leitura ou abertura de um determinado arquivo, podendo ser a seu mando ou mesmo do antivírus, por exemplo, o rootkit intercepta os dados que são requisitados e faz uma filtragem dessa informação, deixando passar apenas o que ele deseja, ou seja, código não infectado. E o que acontece? O antivírus ou qualquer outra ferramenta ficam impossibilitadas de encontrar o arquivo malicioso ou o código, dependendo do caso.

Não é incomum encontrar o Rootkit como não apenas uma aplicação, mas um conjunto de aplicações ou, como também chamamos, toolkit.

Resumidamente poderíamos dizer que é um programa com código malicioso que busca se esconder de softwares de segurança e do usuário utilizando diversas técnicas avançadas de programação para tal.

Geralmente escondem suas chaves nos registros do sistema operacional e escondem seus processos no gerenciador de tarefas, o que torna uma missão quase impossível para um usuário identificar por conta própria. Outra prática comum de quem escreve rootkits é fazer com que eles se escondam em drivers de hardware, que são arquivos de sistema fundamentais para que o sistema operacional funcione corretamente com seus dispositivos.

O nome RootKit é por conta da função para a qual o mesmo é desenvolvido. Primeiramente ele é um kit de funcionalidades e códigos maliciosos cujo objetivo é se infiltrar nos sistemas de forma silenciosa e despercebida, geralmente liberando um  *backdoor para que o invasor possa posteriormente acessar o sistema infectado com privilégios de super usuário ou usuário administrador (root).

Para quem nunca ouviu falar em backdoors, a explicação pode ter parecido um tanto quanto confusa, portanto aqui vai a nota de rodapé: Backdoor é, assim como na tradução ao pé da letra, uma porta dos fundos. Uma falha de segurança intencional que possibilita a invasão do seu sistema de forma que o invasor possa ter este acesso e controle com um mínimo de trabalho.

Sem mais papo furado, vamos conhecer algumas ferramentas que buscam rootkits em seu Linux.

RKHUNTER

A primeira ferramenta que vou apresentar se chama rkhunter, que é a minha favorita.

Se, assim como eu, você for usuário do Arch Linux, poderá encontrar o rkhunter no AUR através deste link.

A instalação é simples e segue o padrão de qualquer instalação a partir do AUR, conforme passos abaixo:

1- Descompacte o arquivo:

[kalib@tuxcaverna downloads]$ tar -xvzf rkhunter.tar.gz

2- Acesse o diretório criado:

[kalib@tuxcaverna downloads]$ cd rkhunter/

3- Execute o PKGBUILD para criação do pacote em si:

[kalib@tuxcaverna rkhunter]$ makepkg

4- Com o pacote criado, basta instalar:

[kalib@tuxcaverna rkhunter]$ sudo pacman -U rkhunter-1.3.8-1-any.pkg.tar.xz

Feito.

Seu rkhunter está pronto para ser utilizado, mas como toda e qualquer aplicação de varredura, como antivírus, por exemplo, é sempre recomendado atualizar sua base de dados antes de iniciar a busca, portanto digite o seguinte para atualizar a base com as propriedades dos arquivos existentes:

# rkhunter –propupd

Em seguida é a hora de atualizar a base de dados do rkhunter em si:

# rkhunter –update

Agora, vamos vasculhar o sistema:

# rkhunter -c

Você terá uma listagem das checagens parecida com esta:

Perceba que é tudo apresentado de forma simples e objetiva.

No final da checagem ele gera um arquivo onde ele armazena todas as informações que ele registrou bem como lhe aponta uma descrição dos resultados da busca.

TIGER

Esta será a nossa segunda ferramenta.

O Tiger é uma ferramenta de segurança que não pensa tanto na aparência, portanto não espere uma tela tão amigável e colorida quanto a do rkhunter. ;]

A instalação da mesma no Arch Linux também se dá através do pacote do AUR que pode ser encontra neste link.

A instalação segue o mesmo procedimento que utilizamos no rkhunter, conforme abaixo:

[kalib@tuxcaverna downloads]$ tar -xvzf tiger.tar.gz

[kalib@tuxcaverna downloads]$ cd tiger/

[kalib@tuxcaverna tiger]$ makepkg

[kalib@tuxcaverna tiger]$ sudo pacman -U tiger-3.2.3-2-x86_64.pkg.tar.xz

Finalizado. Para executar, basta rodar:

# tiger

Ele iniciará a busca e lhe trará uma interface como esta:

Assim como o rkhunter, no ato de finalização ele irá gerar um arquivo com o relatório da checagem. Ele lhe informará o caminho do arquivo, mas provavelmente será em /var/log/tiger/.

CHKROOTKIT

Agora vamos para a terceira e última ferramenta deste post.

Para usuário Arch, desta vez a instalação é ainda mais simples do que as duas anteriores, visto que o pacote já se encontra nos repositórios do pacman.

[kalib@tuxcaverna ~]$ sudo pacman -S chkrootkit

Instalado!

Assim como o Tiger, o chkroot também possui uma interface simples sem cores ou enfeites, conforme pode ser visto abaixo:

Apesar de não ser colorida e enfeitada, é uma interface bem simples e de fácil entendimento, concordam?

Claro, não existem apenas estas ferramentas para busca de rootkits e códigos maliciosos, mas levaria muito tempo para escrever sobre todos ou ao menos a maioria.

No mais, acho que já é um bom começo para um entendimento básico sobre o que é esse tal Rootkit e o que esse bicho faz.

Com estas ferramentas as chances de algum rootkit passar despercebido em seu ambiente Linux já são bem limitadas.

Abraços!

Brute-Force? O Dirb lhe ajuda a identificar vulnerabilidade em seu site!

Agora que já conhecemos um pouco sobre as técnicas de brute-force e a ferramenta Dirb, que tal conhecer outra mais apresentável?

Me refiro ao DirBuster. Uma aplicação multithread desenvolvida pelo OWASP (The Open Web Application Security Project) que tem como objetivo realizar brute-force em diretórios e nomes de arquivos na web. Assim como o Dirb, o DirBuster trabalha em cima de dicionários ou listas. Ao todo ele trás 9 listas que podem ser utilizadas para nossas varreduras e testes. Como todas as suas listas foram criadas na unha, após exaustívas pesquisas e buscas na web por nomes mais utilizados para arquivos e diretórios em servidores web, o DirBuster mostra-se extremamente efetivo para este tipo de atividade conseguindo encontrar até mesmo os arquivos mais ocultos e escondidos.

Mas se você não ficar satisfeito, nós garantimos a devolução do seu dinheiro, com apenas utilizar o modelo de dicionários, o DirBuster ainda lhe possibilita o ataque de brute-force mais purista. Tentativa e erro com combinações possíveis de caracteres. Claro, se você tem muito poder de processamento e tempo sobrando, boa sorte. ;]

Legal Kalib, quer dizer que agora posso sair invadindo sites?

o.O Como diria o Chaves: Ai que burrrrroooo.. dá zero pra ele…

Não amigo. O meu intuito não é incentivar ou apresentar qualquer mecanismo ou técnica para este tipo de atividade. O DirBuster não foi feito para este propósito e nem conseguirá efetuar isto. Ele não fará nenhum tipo de exploit em arquivos ou diretórios que ele encontre. O DirBuster serve exatamente para identificar possíveis alvos para estes tipos de ataque, o que nos permite agir de forma corretiva ou preventiva em nossos servidores web. ;]

Chega de lenga lenga.. vamos ao que interessa!

Como instalar?

Bom, se você utiliza Arch Linux, pode pegar o pacote no AUR através do seguinte link(Lembrem-se de votar nele):

http://aur.archlinux.org/packages.php?ID=20809

Feito isto, basta seguir o procedimento padrão para pacotes do AUR.

1- Descompactar: [kalib@tuxcaverna downloads]$ tar -xvzf dirbuster.tar.gz

2- Entrar no diretório dirbuster e gerar o pacote: [kalib@tuxcaverna dirbuster]$ makepkg

3- Instalar o pacote: [kalib@tuxcaverna dirbuster]$ sudo pacman -U dirbuster-0.12-1-x86_64.pkg.tar.xz

Feito. ;]

Outras distribuições? Não tenho certeza se o pessoal de outras distribuições empacotou o DirBuster, portanto provavelmente você vai precisar baixar o arquivo compactado do site oficial do projeto. Busquei tanto no Debian quanto no (K)Ubuntu 10.10 e em nenhum destes encontrei o DirBuster nos repositórios através do aptitude.

Portanto se você não utiliza o Arch, segue link para download da ferramenta:

http://www.owasp.org/index.php/DirBuster#tab=Download

Mas qual a cara do bicho?

Como explicado antes, ele funciona parecido com o Dirb, porém em uma interface GUI (gráfica).

Como podem ver, é uma interface simples e de fácil manuseio.

Vamos aos pontos:

1- No campo Target, você deverá inserir a URL que será alvo do seu brute-force de diretórios e arquivos web.

2- Logo abaixo, vocẽ escolhe se deseja utilizar apenas GET ou HEAD & GET.

3- Agora é a vez de escolher quantas threads deseja utilizar. Quanto maior o número de threads, mais requisições simultâneas você estará utilizando. ;]

4- Abaixo você deverá escolher o tipo de brute-force.

* Baseado em dicionários, neste caso você deverá escolher um dos dicionários que a ferramenta já lhe disponibiliza através do seguinte caminho: /opt/DirBuster/

* Baseado em brute-force puro. Neste caso você deverá escolher qual conjunto de caracteres deseja que sejam utilizados, quantidade mínima e máxima de caracteres por tentativa.

5- Em seguida é a hora de escolher os filtros: Deseja fazer brute-force apenas em diretórios? Arquivos também? Modo recursivo? Extensões em branco? Diretório inicial para o scan? Que tipo de extensão?…

E como é o retorno que ele me dá?

Bom, vou escolher meu alvo e vou utilizar 20 threads em simultâneo. Não vou deixar a ferramenta rodando por muito tempo pois estou apenas fazendo uma demonstração.

Como podem ver, filtrei para que o brute-force comece no diretório raiz (/) e optei pela maior lista que o DirBuster possui como dicionário. Deixei rodando por cerca de 30 segundos e já tive o seguinte resultado.

A parte borrada no início da imagem não é um defeito. Vocês não pensaram que eu iria deixar exposto o alvo no qual fiz o teste, certo? No caso, optei pelo site de uma de nossas instituições de ensino. Bom, a imagem acima é um exemplo do retorno que consigo com a ferramenta. É a visão em Lista. Além dela você pode optar pela visão em árvore, que, como o nome informa, lhe trará a árvore de diretórios, sub-diretórios e arquivos que foram encontrados. Abaixo um exemplo da visão em árvore:

O resultado, mesmo deixando a ferramenta rodando por apenas 30 segundos, foi o esperado. Um espantoso caso de descuido com a segurança do site.

Alguns leves exemplos que me chamaram a atenção na lista que consegui:

Um diretório de administração exposto desta forma indicando que existe uma sessão do site com acesso permitido apenas para administradores. O que isso me leva a crer? Que quem conseguir acesso a esta sessão consegue manipular o sistema do site? O que nos leva a uma posterior análise da página index contida nele que possibilita uma tentativa de brute-force de login e senha? psssiiiuuuu… o.O

Um diretório para uploads de Arquivos? Que tal testar ele? Apenas usuários administradores possuem permissão de upload? Ou alunos conseguem fazer upload de fotos, trabalhos, por exemplo? De qualquer forma, isso me indica que existe a possibilidade de eu subir arquivos para o servidor deles. Que tal um script em php que me permitiria ter um console shell no servidor deles para inclusão, exclusão, edição, etc.. ? pssiiiiuuuu… o.O

Pode não ser nada.. mas também pode ser muita coisa.. O que um diretório chamado “gerencia” faz ali tão exposto e com um nome tão… tão… discreto? o.O psssiiiuuuuu

Acho que já conseguiram entender um pouco do que o DirBuster faz.

Abraços!

Happy Hacking…

PS: Wrong developers! Never play security by obscurity!

- DEV do Arch, qual é sua missão?

- Empacotar antes de qualquer distribuição!

- DEV do Arch o que é que você faz?

- Eu empacoto coisas que assustam o Satanás!

É isso aí pessoal, ontem o projeto KDE liberou o KDE 4.6 com muitas melhorias e o pessoal do Arch já saiu na frente, claro. Sim, se você usa Arch, não precisa esperar, pode atualizar seu KDE com o seu rotineiro # pacman -Syu.

Dentre as grandes mudanças, gostaria de destacar o suporte nativo ao UPower, UDev e UDisks que podem ser utilizados ao invés do depreciado HAL. Para isso, o pacote hal deixa de ser uma dependência do kdebase-workspace e pode ser removido do seu sistema.

Outra novidade é que com a última atualização do Phonon, os DEVs declararam que o backend Xine não será mais mantido e precisará do PulseAudio para funcionar; você realmente deveria pensar em trocar para o GStreamer ou VLC backend.

Várias melhorias foram implementadas também em contexto geral no Plasma Workspaces que ganhou, dentre outras coisas, um novo sistema de Activities, lhe permitindo uma associação mais fácil de aplicações com atividades específicas e particulares como trabalho ou atividades de casa. Várias mudanças no Kwin, o gerenciador de janelas do Plasma, também foram implementadas para melhorar a performance do mesmo e ao mesmo tempo tornar mais leve para o sistema como um todo.

E se eu tiver um netbook?

O KDE 4.6 também trouxe uma série de novos recursos que facilitam e tornam o sistema ainda mais leve para este tipo de usuário. O Plasma Netbook, otimizado para computadores mais portáteis, se tornou ainda mais leve e fácil de se utilizar através de uma tela touchscreen.

Várias modificações no dolphin, correções de bugs e aparência também foram implementadas, mas… se eu for realmente listar todas as modificações, posso acabar perdendo meu emprego, portanto vou apenas lhes deixar o link do site oficial onde podem ser encontradas todas as mudanças desta release: http://kde.org/announcements/4.6/

Abraços!

Como diria a Feiticeira (não lembro o nome real dela), não é feitiçaria, é tecnologia!

Como já expliquei no outro post, tive problemas com meu notebook e por isso passei muito tempo afastado do blog. Bom, recentemente comprei outro e cá estou novamente em casa.

Mas, como nem tudo é um mar de rosas… toda mudança trás impactos positivos e negativos.

A máquina escolhida foi um Dell Vostro 3300. Com certeza uma excelente máquina e que eu não deixaria de recomendar para ninguém.

Para quem comprou algum Dell recentemente, ou pensou em comprar, não deve ser uma novidade que estas máquinas, em sua grande maioria, estão trazendo chipsets wireless da Broadcom, ao invés dos Intel.

Quando pensei em comprar, refleti bastante sobre isto, visto que os drivers para broadcom no linux já tiveram um passado um tanto quanto nebuloso em se tratando de Wireless.

Resolvi encarar e não me arrependo. A performance está excelente. O driver realmente funcionou como deveria funcionar porém tive um pequeno problema.

Utilizo KDE como gerenciador de janelas em meu ArchLinux e Wicd como gerenciador de redes. Estava tudo funcionando bem mas ao reiniciar a máquina um certo dia percebo que o Wicd não havia encontrado nenhuma rede wireless. o.O

Reinicio novamente e ele volta a encontrar. Feitiçaria? Fiquei curioso e resolvi reiniciar novamente e… funcionou. Pensei: “Foi apenas um susto..ela devia querer descansar..”

Mas no dia seguinte ao ligar em casa percebi que, novamente, a interface wireless não foi encontrada pelo Wicd. Lembrei do fato anterior e reiniciei novamente. A interface continuava sem funcionar no Wicd.

Lhes poupando dos testes que resolvi fazer para isolar o problema, descobri que as vezes a minha interface wireless estava subindo como eth0, as vezes subindo como eth1. Isso, obviamente, deixava o Wicd confuso, pois na configuração dele é necessário especificar qual será a interface wireless e qual será a wired (cabeada). Portanto, quando o notebook subia com a wireless na eth1, o Wicd funcionava numa boa, mas quando subia na eth0 o Wicd continuava tentando escanear redes wireless com a eth1, portanto não funcionava.

Após algumas pesquisas descobri que este é um acontecimento comum em relação ao driver da broadcom. Este chaveamento ou swap de interfaces de rede acontece realmente de forma aleatória.

Como resolver? Amarrando a interface ao nome, literalmente.

A placa começou a funcionar da forma esperada após vincular via regra o MAC da interface ao nome que eu desejava para ela. Desta forma, na hora de subir, ambas passam a subir de acordo com a regra que eu especifiquei, o que resolveu o problema pois a interface wireless passou a sempre subir com o mesmo nome, evitando que o Wicd tentasse escanear com uma interface que não existe.

Sem mais papo furado.. mãos à obra!

Antes de mais nada é necessário criar, caso você já não possua, o arquivo /etc/udev/rules.d/10-network.rules acrescentando o seguinte conteúdo:

SUBSYSTEM==”net”, ATTR{address}==”aa:bb:cc:dd:ee:ff”, NAME=”eth0″
SUBSYSTEM==”net”, ATTR{address}==”aa:bb:cc:dd:ee:ff”, NAME=”eth1″

o.O wtf?

Bom, com isto você estará deixando claro para o sistema qual o nome que deverá ser atribuído para cada interface.

Você deverá apenas substituir o “aa:bb:cc:dd:ee:ff” e “ff:ee:dd:cc:bb:aa” pelos respectivos endereços MAC das interfaces.

O valor dos campos NAME podem ser alterados de acordo com sua vontade, por exemplo: eth0 para a cabeada e wlan0 para a wireless.

Caso não saiba como conseguir o endereço MAC de suas interfaces, utilize o seguinte comando:

# ifconfig | grep HW

Isso lhe dará um retorno parecido com o seguinte:

eth0  Link encap:Ethernet  HWaddr A4:BA:DB:D7:41:C0
eth1  Link encap:Ethernet  HWaddr 1C:65:9D:6E:65:1B

Os endereços MAC são os valores que destaquei acima.

ATENÇÃO: Apesar de o MAC constantemente ser escrito com letras em maiúsculo como apresentado acima, no caso do arquivo 10-network.rules você deverá utilizar letras em minúsculo. Exato, o arquivo é case sensitive, portanto só funcionará desta forma.

Caso você receba uma saída parecida com a minha e queira se certificar de qual dos dois endereços MAC é o que realmente representa a interface wireless pode testar com os seguintes comando:

# iwlist eth0 scanning

e…

# iwlist eth1 scanning

Você perceberá que terá resultados diferentes. O que retornar um scan completo de redes wireless disponíveis, obviamente, é a interface Wireless. ;]

Após ter escolhido o nome que deseja para cada uma de suas interfaces pode salvar o arquivo de regra.

ATENÇÃO²: Certifique-se de atualizar o seu arquivo /etc/rc.conf para evitar que os nomes das interfaces estejam diferentes das que você criou no arquivo de regras.

É isto.. agora sua interface funcinoará da forma esperada.

Abraços!