O blog ainda está em plena atividade, porém ultimamente tirei um tempo dedicado para finalizar os projetos iniciados algum tempo atrás e isso tem me tomado a maior parte do tempo livre…

Em breve volto com novos posts! Mas por enquanto deixo aqui o endereço do novo servidor jabber aberto que deixei no ar esta semana!

O registro pode ser feito diretamente pelo client…

Address: talk.luizxx.com Port: 5222

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…

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

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!

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.

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!

Primeiramente é necessário conhecer a diferença básica entre downtime planejado e downtime não-planejado.

Normalmente o downtime planejado acontece ao realizar-mos atualizações críticas de sistema (ie. Kernel) e alguns tipos de manutenção relacionada ao funcionamento base do sistema operacional. Este tipo de downtime deve ser sempre notificado com antecedência aos clientes que dependem do serviço e deve ser feito no menor tempo possível, apesar de não ser uma prática muito correta algumas empresas costumam não contabilizar o downtime planejado em seus relatórios de disponibilidade.

Já o downtime não-planejado normalmente acontece devido a problemas físicos no ambiente computacional, tendo entre suas principais ocorrências problemas elétricos, falhas de hardware, excesso de temperatura no ambiente, problemas de rede / telecomunicações, problemas de segurança, falhas em aplicações e no próprio sistema operacional.

Agora podemos ir ao nosso cálculo de disponibilidade (%), que nada mais é do que a disponibilidade total do serviço dentro do período de um ano, e a partir do valor obtido pode-se ter o nível real de disponibilidade para obtenção de estatísticas e SLA (marketing normalmente adora esses números!).

Os valores mais comuns de disponibilidade relacionados com downtime são:

• 98%    - 7.30 dias por ano / 14.4 horas por mês
• 99%    - 3.65 dias por ano / 7.2 horas por mês
• 99,5% - 1.83 dias por ano / 3.60 horas por mês
• 99,8% - 17.52 horas por ano / 86.23 minutos por mês
• 99.9% - 8.76 horas por ano / 43.2 minutos por mês
• 99.95% - 4.38 horas por ano / 21.56 minutos por mês
• 99.99% - 52.6 minutos por ano / 4.32 minutos por mês
• 99.999% - 5.26 minutos por ano ou 25.9 segundos por mês
• 99.9999% - 31.5 segundos por ano ou 2.59 segundos por mês

Lembrando sempre que uptime é totalmente diferente de disponibilidade!

Suhosin é um módulo avançado de proteção para servidores de aplicação rodando PHP, é foi desenvolvido para proteger tanto os servidores como os próprios desenvolvedores de vulnerabilidades nas aplicações construídas e no próprio core do PHP.

O módulo é compatível com instalações do PHP em qualquer sistema compatível, não apresentando problemas com outros módulos presentes na instalação, incluindo Zend Optimizer e APC.

Um dos recursos mais interessantes deste módulo é a encriptação transparente de cookies e dados de sessão, evitando inumeros ataques de “session hijacking” O módulo também realiza inumeros tipos de filtragem de dados em tempo real, evitando ataques DOS e scripts maliciosos sendo executados no servidor.

Para aqueles que precisam desenvolver aplicações em PHP com mais segurança em um ambiente controlado e auditado, o módulo é muito útil!

Ah sim, para aqueles que possuem planos de hospedagem Linux na Locaweb e desejam realizar a ativação do módulo, é necessário apenas adicionar a seguinte linha em seu arquivo php-cgi.ini:

extension=suhosin.so

Notei que muitas pessoas em diversos fóruns tem postado esta mesma dúvida e também existem diversas respostas dadas, porém poucas delas são simples e funcionais como poderiam ser.

Segue uma forma prática para liberar a entrada direta, sem redirecionamento para a porta do proxy:

# iptables -t nat -I PREROUTING -d 200.201.160.0/20 -j ACCEPT

Dessa forma inserimos uma regra prioritária sobre as outras (-I), liberando o range da CEF para ser acessado diretamente sem o redirecionamento.

Lembre-se de colocar a regra após todas as outras, ou então antes delas!

O Rails Summit Latin America surge para completar a agenda dos grandes eventos mundiais de Ruby on Rails. Inspirado na RailsConf americana, que reúne cerca de dois mil desenvolvedores e tomadores de decisão, o Rails Summit Latin America trará, ao Brasil, os principais palestrantes e especialistas mundiais do assunto, incluindo a participação especial do criador do Ruby on Rails, David Hansson.

description by Locaweb

Como todos sabem não sou desenvolvedor Rails (apesar de gostar muito de Ruby), mas para todos aqueles que precisam desenvolver sites de uma maneira rápida, facil e bem caprichada (totalmente fancy né Akita! rs) é uma ferramenta incrível. Recomendo a conferência para todos os que querem se aprofundar nesta tecnologia inovadora e totalmente promissora.

A Rails Summit Latin America deste ano será patrocinada pela Locaweb e vai contar com a presença de todos os principais desenvolvedores e mantenedores da tecnologia no mundo todo.