Recentemente adquiri o plano de dados 3G da operadora Claro em meu Nokia 5610, porém a conectividade com a internet estava somente disponível no navegador padrão do aparelho e qualquer outra aplicação (inclusive o OperaMini que já veio pré instalado) não conseguia acesso a rede.

Para liberar o acesso de todos os outros softwares na rede de dados da claro foi necessário adicionar uma configuração de dados personalizada. Seguem os procedimentos para a definição do ponto de acesso personalizado:

1. Acesse Configurações -> Configuração -> Configurações Pessoais
2. Entre no menu Opções e selecione Adicionar nova
3. Entre em Ponto de Acesso
4. Entre em nome da conta, e escolha um novo nome.
5. Entre em Configs. pt. acesso, e em Configs. portadora
6. Nos campos Nome do usuário e Senha informe claro
7. Altere o pt.acesso dados para claro.com.br
8. Ainda no menu de configurações pessoais, entre em Pto. de acesso preferido
9. Selecione a nova configuração

Meus agradecimentos ao Thiago Hickmann que inicialmente disponibilizou informações sobre a conectividade 3G da Claro no 5610…

Depois de um bom tempo sem a seção de música do mês vamos voltar com uma banda bem antiguinha mas de altíssima qualidade, que pra variar é pouquíssimo conhecida no país…

Malice Mizer! Um dos principais marcos no j-rock mundial!
Definitivamente vale a pena conhecer!

Yesterday I was compilling a new release of PHP packages for Red Hat Enterprise 5 (RPM) in the x86_64 architecture and I got a bug during the compilation proccess of the php-mssql module that requires the freetds-devel package to be built.

By default, the configure script doesn’t find the required freetds libraries on the system (even if they are correctly installed) because in the lastest versions of freetds we don’t have the tds.h and libtds.a files.

To bypass this check and continue building your packages normally you can use this simple and dirty workarround:

$ touch /usr/include/tds.h
$ touch /usr/lib/libtds.a

Or you can edit the configure script (make a patch and apply during the build process) to find the correct files and directories.

Official report: http://bugs.php.net/bug.php?id=44991
Tanks to Brian for the help!

Recentemente tive que realizar a instalação do Nagios em um servidor rodando ArchLinux e definitivamente foi uma ótima escolha que me permitiu um sistema de monitoramento muito otimizado, estável e de fácil implementação.

A instalação pode ser realizada facilmente através dos repositórios oficiais e do AUR, porém temos uma padronização diferente dos demais sistemas, principalmente nos usuários que rodam as aplicações. Durante a instalação tive apenas que adaptar as permissões do diretório necessário dos remote commands, seguem as alterações e permissões necessárias:

#chown http:nobody /var/nagios/rw
#chmod gu+rwx /var/nagios/rw
#chmod g+s /var/nagios/rw

Após setar as permissões reinicie o Apache e o Nagios para efetivar as mudanças e os comandos enviados através da interface já poderão ser executados normalmente.

Realmente, sistemas de monitoramento sobre ArchLinux assim como em OpenBSD são uma alternativa muito boa para otimizar ao máximo os recursos de seu servidor com segurança e alta performance.

When we have a system directly connected to the internet and with the SSHd running on port 22, brute-force and dictionary attacks are inevitable. Even with a strong password, our authlogs are filled with useless information and the authentication daemon doesn’t stop processing requests from the attacker.

On Linux based servers we have very good tools to avoid this problem, like DenyHosts and Fail2ban, but on OpenBSD we can directly use the PF (PacketFilter) to manage the SSH new connections on the server avoiding this kind of attacks coming from the internet and improving security on the server.

The pf rule I used to manage the connections is very simple and clean, but you can make changes according to your own environment.

pass in on $ext_if proto tcp from any to ($ext_if) port 22 \
  flags S/SA keep state \
  (max-src-conn-rate 3/30, overload <ssh-blacklist> flush global)
block drop in quick on $ext_if from <ssh-blacklist>

First we classify our attackers using the “max-src-conn-rate” , that in this example classify any hosts trying to connect 3 times in a period of 30 seconds. When the attacker is classified, his IP address is written on the ssh-blacklist table, and finally we drop packages coming from the hosts classified.

Well, we don’t need this hosts banned forever so we can use the expiretable program (present on OpenBSD Ports) to manage the registrations on our table and remove the entries after some time blocked. To do this we can simply run expiretable as a daemon:

/usr/local/sbin/expiretable -d -t 3600 ssh-blacklist

Where 3600 means seconds, on the lastest versions the time can be specified using the sulfixes s, h, m and d like “1h30m”.

If you prefer, just add an entry on your crontab to make the checks automatically:

*/5 * * * * /usr/local/sbin/expiretable -t 3600 ssh-blacklist

Thanks to Johan Fredin for the tip!