Hugo Doria: HnTool 0.1 liberado

Seguindo o principio do "release early, release often", estamos orgulhosos de liberar a primeira versão do HnTool, uma ferramenta cujo objetivo é fazer uma análise simples do servidor e dizer quais as falhas de segurança que existem.

Nesta primeira versão você terá:

• Suporte ao Arch Linux, CentOS, Debian, Fedora, Gentoo e Ubuntu.
• Testes para Apache, PHP, Portas, PostgreSQL, SSH e outros.
• Relatório em HTML ou terminal.
• Estrutura interna modular e fácil de contribuir.

Temos muitas ideias para as próximas versões do HnTool, entre elas:

• Módulos para MySQL, FTP, DNS, Squid, Iptables, Samba, DHCP, cups
• Um report mais detalhado, mostrando como corrigir a falha encontrada
• Opção para atualizar os módulos pela própria ferramenta
• Analisador web, através de upload de arquivos de configuração
• Suporte a traduções

Baixando e instalando

Para instalar o HnTool pelo fonte, baixe-o desde endereço e faça:

$ tar xvf hntool-0.1.tar.gz

$ cd hntool-0.1

# python setup.py install --prefix /usr/ --root /

Se você usa Arch Linux você pode instalar o HnTool através do pacote criado:

$ wget http://hntool.googlecode.com/files/hntool-0.1-1-i686.pkg.tar.xz

# pacman -U http://hntool.googlecode.com/files/hntool-0.1-1-i686.pkg.tar.xz

NOTA: Por enquanto só há pacote para o Arch Linux. Se você usa alguma distribuição baseada em rpm ou deb e sabe criar pacote, por favor, não se acanhe. Crie um e adicione em um bug report.  Se precisar de um guia, pode usar o PKGBUILD que fiz para criar o pacote do Arch Linux.

Usando

Para rodar o HnTool basta executar o seguinte comando:

# hntool

Isso irá gerar um relatório no terminal:

Se preferir, você pode gerar um relatório em HTML com o comando:

# hntool -t html > index.html

Para maiores informações rode:

# hntool -h

Reportando Bugs

O HnTool está em um estado tão inicial e com tanto código sendo adicionado frequentemente que, com certeza, você vai encontrar vários bugs. Por favor, não deixe de relatá-los em http://code.google.com/p/hntool/issues/list.

Contribuindo

Contribuir com o projeto é fácil. Você pode dar sugestões, reportar bugs e pedir novas funcionalidades. Além disso, você pode contribuir criando módulos. Veja como é fácil:

Todos os módulos seguem a seguinte estrutura:

Como falei, resolvi criar o hntool de forma modular. A estrutura de um modulo é, mais ou menos, assim:

import os
 
	class rule:
		def short_name(self):
			return "ssh"
		def long_name(self):
			return "Checks security problems on sshd config file"
		def __init__(self, options):
			pass
		def analyze(self, options):
			check_results = {'ok': [], 'low': [], 'medium': [], 'high': [], 'info': []}
			ssh_conf_file = ['/etc/ssh/sshd_config', '/etc/sshd_config']
 
			for sshd_conf in ssh_conf_file:
				if os.path.isfile(sshd_conf):
					try:
						fp = open(sshd_conf,'r')
					except IOError, (errno, strerror):
						check_results['info'].append('Could not
open %s: %s' % (sshd_conf, strerror))
						continue
 
					lines = [x.strip('\n') for x in fp.readlines()]
 
					# Checking if SSH is using the default port
					if 'Port 22' in lines or '#Port 22' in lines:
						check_results['low'].append('SSH is using the default port')
					else:
						check_results['ok'].append('SSH is not using the default port')
 
					# Closing the sshd_config file
					fp.close()
 
				return check_results
		def type(self):
			return "files"

Explicando melhor:

• short_name(self): Uma string contendo o nome curto do modulo. Ele será usado, por exemplo, na hora de listar todos os módulos existentes (hntool -l).
• long_name(self) : Aqui é a descrição do módulo. Também será mostrada na listagem dos módulos.
• analyze(self): É aqui que fica o código de verdade. O resultado desse método deve ser sempre uma lista com 5 elementos, que correspondem aos níveis de segurança encontrados - ok, info, low, medium e high, respectivamente.
• type(self): Cada módulo será de um tipo. "files" para módulos que lidam com arquivos de texto simples(/etc/passwd, por exemplo) ou de configuração. "services" para módulos que lidam com serviços.

Autores

Muita gente foi importante para este release, contribuindo com sugestões, bugs reports, código e, claro, apoio. Muito obrigado, Alexandro Silva, Aurélio Heckert, Candido Vieira, Elton Pereira, Italo Valcy, Késsia Pinheiro, Rafael Gomes, Rafael Gonçalves Martins, picoloto, Sebastian SWC. :-)

Bem, é isso. Aguardem novidades na versão 0.2.

Gustavo Noronha (kov): Designing from the bottom up

Have you ever seen, while dealing in a support channel with a novice that just got in touch with the power of UNIX a conversation that goes like this?:

<novice> How can I process the output of a command, so that any number of spaces gets turned into a newline?
<seasoned> What are you trying to do?
<novice> I want to list the contents of a directory, but I want one per line.
<seasoned> ls -1

I have seen this numerous times, even as one of the actors. At times I was the novice, and many times in #debian-br I was the seasoned person trying to get the novice to focus on the problem they were trying to solve, not on the solution they thought was right.

While reading Máirín Duffy’s awesome paper about contributing to Free Software as a designer I couldn’t help but get that image brought to my memory again, and again. Specially when I read this part:

This means the language and even the approach FLOSS projects take to solving problems tend to be focused on implementation and technology rather than starting with a real-life user problem to solve and determining appropriate implementation afterwards.

That does sound like us, and it does sound like many of the solutions we come up with. While I was reading her paper, there was a reference I got very interested in checking. It’s a PDF with no links in it, so I only had the number of the reference. What I would have to do is I would have to scroll to the end of the paper, and find the reference, then somehow come back to the place I was looking at.

My most immediate thought was ‘you know, maybe evince should have tabs’. Why? Because I could open a new tab, go to the place the reference was at, and to ‘go back’ I just needed to close the new tab. Other options require much more effort - remembering the page I was at, or maybe the scroll offset more or less, and scan for the part of the text I was at. But those are not the only options! I could have the application set a marker on where I am, and have an easy command to go back to that marker, for instance, or evince could provide a way of ‘looking ahead’ without throwing away the current state at all. I’m pretty sure if I look around enough I will find tools that solve this problem in a fairly good way.

Now, I think that is exactly how we ended up with tabs in so many places they do not make sense in, and with so many ad-hoc solutions that solve our problems in half-assed ways. Even in browsers, we tend to use tabs as ad-hoc solutions to real problems we have no real solution to handle yet, such as “I want to check this other thing out real quick, but I do not want to lose any state of this page”, or “I want to check this out, but not right now, so let me open it, and then I’ll come back to it”, or maybe even “I want to look at this now, but since it is going to take a while to load, I might as well let it load in the background, and when I finish reading this I can go look at it”. These are the real problems we have, and I think we need better designs that solve them for real, instead of just patching them with the ad-hoc solution that tabs are.

The other extreme of the spectrum is, of course, not doing something, or even anything for lack of the perfect solution. Using ‘this is not a real solution’ as an excuse to not implement something that could serve as a temporary solution to a problem may cause more frustration than having to deal with the ad-hoc solution that is tested, and being applied to other applications for some time. After all, in many cases the ad-hoc solution can be later replaced with a proper one.

I guess this is another instance of the very difficult problem of balancing different realities: proper design is not always available to start something up, specially if the application is backed by individuals and not by a company or a bigger project that could bring in designers to work on it from the start. In this case having something up and running is usually a very important first step in a free software project - usually required to get enough interest to make it worth designing for.

Hugo Doria: A melhor coisa da páscoa

A páscoa é aquela velha história: temos que agradecer a aquele que lutou, morreu e ressuscitou por nós. Goku, claro.

Além disso, temos que comer muito chocolate (oba!), o que não deixa de ser muito bom. Mas, sem dúvida, a melhor coisa da páscoa é isso aqui:

Não tem preço.

Leonardo Ferreira Fontenelle: O GNOME 2.30 já está no Arch Linux

Acabei de realizar minha atualização quase diária no meu netbook (amanhã mexo no desktop), e o Arch Linux simplesmente instalou o GNOME 2.30, menos de 30 horas após o lançamento do código-fonte. Eu estou sem palavras!

Uma coisa de que não gosto em distribuições de Linux é o atraso que elas introduzem entre os lançamentos de código-fonte e a instalação para o usuário final. (Não que eu tenha muita escolha, já que também não gosto muito de Windows.) A principal razão de eu usar o Arch Linux é ter software o mais atualizado possível. Tradicionalmente, tenho que esperar poucas semanas até poder instalar uma versão 2.xx.0 do GNOME, mas dessa vez o Arch Linux realmente excedeu minhas expectativas.

Eu não recomendo o Arch Linux para ninguém. Se você for um usuário típico do Arch Linux, vai descobrir sozinho se a distribuição é para você. Mas hoje não tenho como deixar de dizer em alto e bom tom que estou muito feliz com o Arch Linux.