Conectando OpenVPN com WatchGuard Firebox

Recentemente um cliente optou por trocar sua estrutura de segurança baseada em software livre por um produto “caixa preta” chamado WatchGuard Firebox (ou algo do tipo).

Como interajo apenas com servidores da rede interna, não conheço muito bem a estrutura de borda.

Até então utilizava-se um servidor OpenVPN e minha conexão era feita através de um cliente do OpenVPN.

Como temos um serviço de monitoramento através deste túnel, fiquei preocupado, pois o cliente apontou apenas um software para Windows como conexão. Posteriormente descobrimos que além de Windows, existe cliente para Mac e também para softwares com suporte a arquivos .ovpn!

Apenas fiz alguns ajustes no arquivo de configuração (para passar pela autenticação de usuários automaticamente), conforme sugestão apontada aqui [1] e a conexão via cliente OpenVPN foi estabelecida sem maiores dificuldades!

 

Referências:

[1] Connecting Linux to WatchGuard Firebox SSL (OpenVPN client) – http://jochen.kirstaetter.name/blog/linux/connecting-linux-to-watchguard-firebox-ssl.html

[CC] Como extrair texto de um arquivo de dados (binário) em Windows

Para um usuário acostumado com o mundo *nix, extrair textos (strings) de arquivos binários é trivial. Basta utilizar o comando “strings”. Mas em um Windows Server, como faço isto? É mais simples que eu poderia imaginar! Existe o comando “findstr”. MUITO útil e BASTANTE funcional!!!

Exemplo de uso:

findstr "meu nome" arquivo.dat

 

Referências:

[1] Findstr – Search for strings – http://ss64.com/nt/findstr.html
[2] Findstr – https://technet.microsoft.com/en-us/library/bb490907.aspx
[3] Findstr – http://en.wikipedia.org/wiki/Findstr

[CC] git com proxy

Recentemente um cliente pediu-me auxílio em uma rede onde a navegação direta é restrita, forçando o uso de proxy. Com isto, o atualizador do sistema deixou de funcionar, pois a nova versão do mesmo adotou o git como parte de seu ferramental.

Tive então que pesquisar como forçar o uso do proxy através do git. Descobri [1] que é bastante simples, bastando adicionar as linhas abaixo (com a referência correta de seu endereço de proxy) antes de executar a chamada do git:

git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:3128
git config --global https.proxy https://proxyuser:proxypwd@proxy.server.com:3128

 

Referências:

[1] Getting git to work with a proxy server – http://stackoverflow.com/questions/783811/getting-git-to-work-with-a-proxy-server

[CC] Ajustando encondig para pg_dumpall

Hoje um cliente me relatou que o backup lógico do seu banco PostgreSQL havia parado com a seguinte mensagem:

pg_dump: Error message from server: ERROR:  character 0xe28093 of
encoding "UTF8" has no equivalent in "LATIN1"

Descobri [1] que seria necessário ajustar a configuração de enconding do client do PostgreSQL. Descobri também que o comando “pg_dump” oferece uma opção para definir o conjunto de caracteres correto (“–encoding=UTF8”, no caso em específico).

No entanto, como eu utilizo um backup completo do banco, esta opção não me servia, já que o comando “pg_dumpall” não oferece suporte para este parâmetro. E foi no manual do “pg_dump” que encontrei minha solução: antes de exportar o banco, basta configurar a variável PGCLIENTENCODING! Segue o exemplo:

export PGCLIENTENCODING=UTF8
pg_dumpall ...

Referências:

[1] http://stackoverflow.com/questions/14525505/postgres-issue-encoding-utf8-has-no-equivalent-in-encoding-latin1

Samba 4 e compartilhamento público (“security=share”)

Venho relatando aqui no blog os ajustes de serviços e configurações necessários em função da nova versão 7 do RedHat (e similares). Mais detalhes podem ser encontrados na parte 1 e parte 2.

Um dos serviços que precisei configurar e que também sofreu alteração, foi o compartilhamento de arquivos via protocolo SMB, feito com o nosso amigo Samba. Embora a nova configuração que precisei fazer tenha sido em função da versão 7, esta mudança ocorreu com a versão 4 do Samba, estando assim disponível em outras distribuições atuais.

Precisei fazer um compartilhamento de arquivos público, sem restrições de acessos nem autenticação de usuários. Em versões anteriores do Samba, isto era feito através da seguinte configuração (no smb.conf):

security = share

Usei a mesma diretiva, ajustei as demais configurações que eu precisava e fui rodar um testparm (para verificar se estava tudo correto). Para minha surpresa o teste acusou:

WARNING: The security=share option is deprecated

Fui então pesquisar o que poderia estar errado, pois meu compartilhamento não estava funcional. Em [1] encontrei a nova versão de  configuração para esta versão do Samba.

Mesmo na versão 3.6 do Samba que está em meu computador pessoal, este aviso já aparece. Não consegui identificar a partir de qual versão ocorreu esta mudança.

Em suma, as configurações ficam assim:

[global]
# (...)
security = user
map to guest = Bad User
guest ok = yes

Referências:

[1] Set up Samba without using Deprecated “share” Security Setting – https://vicidi.wordpress.com/2012/01/23/set-up-samba-without-using-deprecated-share-security-setting/

[Resolvido!] HAVP – Could not fork daemon

Esta semana eu estava implementando uma necessidade nova, solicitada por um cliente e precisei reproduzir o ambiente dele em uma máquina virtual para testes. Assim, instalei um Slackware mínimo, Clamav, HAVP e um Squid para criar um servidor proxy com análise de vírus do conteúdo.

Não entrarei em detalhes sobre esta configuração pois existem diversos tutoriais a respeito. O próprio HAVP oferece uma documentação detalhada sobre o assunto.

No entanto, ao tentar iniciar o serviço do HAVP, eu me deparava com o seguinte erro:

Starting HAVP Version: 0.92
Could not fork daemon
Exiting..

Infelizmente eu não encontrava detalhes suficientes para decifrar o mistério. Todos os fóruns e soluções que encontrei apontavam para o caminho de conflito de portas, o que não era o meu caso.

Em geral, eu não uso o Clamav como daemon, mas resolvi iniciá-lo neste formato para traçar um caminho diferente. Eis então que a “luz se fez”!!! Através do log do Clamav encontrei uma esperança na seguinte mensagem:

ERROR: daemonize() failed: Cannot allocate memory

Como eu tinha montado uma máquina virtual modesta, afinal era apenas para um teste local, aloquei apenas 512 MB de RAM. Infelizmente, como vim a descobrir, não era o suficiente para minhas necessidades.

Desliguei a máquina, reservei 1 GB de RAM, inicializei novamente o servidor virtual e voilà, o HAVP inicializou sem problemas!

Espero que este pequeno relato auxilie mais alguém, pois acabei dispendendo várias horas até encontrar esta solução!

RedHat 7 (e similares) e novos conceitos/comandos – parte 2

Como relatei na parte 1, houve algumas modificações nesta versão 7 do RedHat (e seus similares). Uma das modificações foi o sistema de inicialização. O, até então predominante, sysVinit foi substituído pelo systemd.

Uma documentação completa sobre o systemd por ser encontrada aqui [1]. Recomendo também a leitura desta documentação [2] elaborada pela comunidade do Arch Linux.

RedHat 7 (e similares) e novos conceitos/comandos – parte 1

Esta semana coloquei em produção um servidor Oracle Linux 7, uma das distribuições que se baseia na parte livre do RedHat para criar sua distribuição. Tenho usado tanto o RedHat como o CentOS a bastante tempo. E faz algum tempo, passei a utilizar o Oracle Linux para deixar ambientes homologados, ao gosto do cliente. RedHat e CentOS sempre mantiveram estrutura e comandos idênticos (a diferenciação fica em poucos programas e, essencialmente, na marca, logo, enfim, atributos “visuais”). Com o Oracle Linux, não é diferente.

Por isto, qualquer mudança que o RedHat 7 tenha incorporado, está refletida nas demais distribuições que acompanham a mesma release. Assim, minhas pesquisas, referências e citações, podem apontar para qualquer uma destas distribuições.

Um detalhe que sempre estranhei no instalador da RedHat foi o fato do arquivo /etc/hosts nunca ficar corretamente configurado quando definimos nome de máquina e IP fixo. Nesta minha instalação, o nome da máquina sequer foi ajustado a contento. E fiquei com o nome de localhost definido.

Como faria em qualquer versão anterior, eu apenas corrigiria o arquivo /etc/hosts (que o instalador nunca deixou corretamente ajustado) e o arquivo /etc/sysconfig/network (que nesta versão não foi configurado durante a instalação). Mas para minha surpresa, estas correções não foram suficiente para ajustar o nome do servidor.

Pesquisando, descobri [1] que o processo de ajuste de nomes nesta versão foi modificado. Precisei utilizar um utilitário para ajustar o nome (e acertar os arquivos que já havia acertado previamente):

# nmtui-hostname

Depois disso, é necessário reiniciar o serviço responsável pelo nome do servidor:

# systemctl restart systemd-hostnamed

e, para verificar se as alterações surtiram efeito, basta executar o seguinte comando:

# hostnamectl status

Mas para as alterações surtirem efeito na console, será necessário reiniciar o servidor.

Bom, enfrentei mais algumas novidades nesta versão, mas deixarei isto para outros textos que publicarei em breve. Espero que este breve artigo possa contribuir para algum leitor.

Referências

[1] Change HostName in CentOS 7 / RHEL 7 – IT’zGeek – http://www.itzgeek.com/how-tos/linux/centos-how-tos/change-hostname-in-centos-7-rhel-7.html#axzz3QgXE66S3

[CC] Desabilitar o envio de e-mails na crontab

Recentemente deparei-me com um servidor no qual não era feita uma manutenção preventiva a algum tempo (nem todo cliente opta pelo serviço!). Aproveitando uma necessidade criada, acabei fazendo uma verificação da situação do servidor.

E encontrei vários e-mails destinados ao “root”, ocupando espaço desnecessário (o volume era considerável!). Verifiquei que a maioria dos e-mails eram oriundos de processos executados na crontab.

Como ninguém estava acompanhando estas mensagens (e nem iria), achei mais conveniente desabilitá-las. Procurei então por uma maneira de eliminar o envio de forma geral e não para cada agendamento criado (outra possibilidade).

Na referência abaixo também é citada esta possibilidade individual. Mas fiquei com a opção de fazer isto através da variável MAILTO. Basta adicioná-la (caso não exista na cron) com o valor “zerado”:

MAILTO=""

Referência:

Disable The Mail Alert By Crontab Command – http://www.cyberciti.biz/faq/disable-the-mail-alert-by-crontab-command/

Versão 4 do awk e novas palavras reservadas

Nos primeiros dias de novembro foi lançada uma nova versão do Slackware e alguns dias depois me surgiu a necessidade de instalar um novo servidor firewall. Se fosse outra distro, eu esperaria a estabilização da versão para então instalar. Mas tratando-se do Slackware, tive confiança que poderia colocar em produção uma versão “saída do forno”.

Tenho um roteiro de instalação e algumas rotinas que utilizo de forma padronizada em todos os servidores administrados por mim. Dentre estas rotinas, uma que coleta dados de carga de CPU e memória para o MRTG. Venho utilizando estas rotinas a bastante tempo, baseadas neste artigo do Augusto Campos.

Pois bem, a rotina que coleta dados da CPU funcionava bem até que o Slackware passou a utilizar a versão 4 do awk. A partir desta versão, a palavra “load” (utilizada no script) passou a ser uma palavra reservada para o comando awk. Com isto, a geração de dados sobre CPU e memória deixou de ser gerada!

Como gastei um tempo até que descobrisse o motivo (o “load” como palavra reservada), achei melhor compartilhar com os meus leitores e deixar registrado aqui para referências futuras.