Mar 30

Colocando o snoopy no Debian 6

Pessoal,

Em um laboratório para um syslog server em banco mysql com snoopy em servidores CentOS 6 e Debian 6, me deparei com o fato de que o Debian 6 não possui o pacote snoopy.

Por isso tive de baixar o source e instalar manualmente. Abaixo seguem os passos para instalá-lo:

download da ultima versão no site do projeto

http://sourceforge.net/projects/snoopylogger/

tar um tar -zxvf no arquivo

entre no diretório

rode o configure

execute o make, make install e o make enable

execute o comando export LD_PRELOAD=/usr/local/lib/snoopy.so

execute o comando echo “/usr/local/lib/snoopy.so” >> /etc/ld.so.preload

depois um invoke-rc.d rsyslog restart

E os logs do snoopy já estarão sendo escritos no /var/log/auth.log

Mar 26

Usando o rsync daemon

Como usar o rsync daemon.

O Rsync possui a opção de rodar como um daemon onde o usuario que se conecta para executar a cópia dos dados não existe no servidor.

Nas distribuições baseadas em debian o rsync possui um script de inicialização como serviço sem depender do xinetd o que já acontece nas distros baseadas em Red Hat.

Em ambas as distribuições será necessário criar os seguites arquivos:

/etc/rsyncd.conf
/etc/rsyncd.secrets

Obeservação:

O arquivo de secrets deve ter permissão 600

Diferenças de configuração entre Red Hat e Debian:

Como o rsync no modo daemon irá rodar pelo xinetd algumas alterações devem ser observadas

uid que no debian pode ser nobody com xinetd tem que ser root
gid que no debian pode ser nobody com xinetd tem que ser root

Sintaxe do rsyncd.conf

uid = user que opera o daemon
gid = grupo que opera o daemon
list = yes
read onlyrue
use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
hosts allow = IP
slp refresh = 30
secrets file = /etc/rsyncd.secrets
use slp = false

[nome da seção]
path = local onde estão os dados a serem copiados
ignore errors = yes
ignore nonreadable = yes
transfer logging = yes
comment = comentario
auth users = user de copia dos dados

Sintaxe do rsyncd.secrets

user:password

Para habitar o rsync via xinetd edit arquivo /etc/xinetd.d/rsync para o seguinte conteúdo

# default: off
# description: The rsync server is a good addition to an ftp server, as it \
# allows crc checksumming etc.
service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = –daemon
log_on_failure += USERID
}

Script para copia do dados lado do cliente:

#!/bin/bash
RSYNC=$(which rsync)
LOGGER=$(which logger)
SECRETS=”/etc/rsync.secret”
OPTIONS=”-avztpoglH –delete –owner –group –force –password-file=$SECRETS”
USER=”user”
LOG=”/var/log/backup.log”
LOGGERTAG=”Sync images”

SERVERS[1]=”ip do servidor daemon”
SECTIONS[1]=”section name”
DESTINATIONS[1]=”path de destino”

$LOGGER -t $LOGGERTAG “Iniciando a sincronia.”
COUNT=${#SERVERS[@] }
for i in `seq 1 $COUNT`
do
$RSYNC $OPTIONS $USER@${SERVERS[$i]}::${SECTIONS[$i]} ${DESTINATIONS[$i]} >> $LOG
done
$LOGGER -t $LOGGERTAG “Sincronia concluida.”

Feb 25

Pra que reinventar a roda

Este post é um desabafo.

Galera ultimamente tenho visto algumas coisas bizarras que me espantam muito como o ultimo caso.

Vamos a ele:

O cliente nos solicitou que efetuassemos um controle das URLs que poderiam ser acessadas por seu servidor de TS.

Ao analisar o ambiente para traçar uma opção para efetuar o controle é identificada a presença de um firewall Linux operando com o Debian Lenny. Eis ae que veio a solução assustadora como o firewall não possuia o squid instalado para trabalhar como proxy e não sei se por preguiça ou total desconhecimento ou sei lá o que o iluminado ao invés de instalar o squid e configurá-lo não crio regras de iptables com os nomes fqdns das urls que deveriam ser acessadas.

Após esta brilhante idéia o que acenteceu?

O servidor começou a apresentar instabilidade no acesso web. URLs que deveriam ser bloqueadas não estavam sendo. E para colocar a cereja em cima do bolo por uma falha de acesso DNS na hora do script de firewall ser reiniciado todo o ambiente ficou indisponível por quase 5 minutos por causa das tentativas do iptables para resolver os nomes das URLs.

Lógico que o cliente ficou furioso com a queda. Para corrigir o erro e garantir que o ambiente não ficasse fora novamente, tive que fazer a solução que deveria ter sido adotada desde o início instalar um squid e configurá-lo, alem claro de limpar o script de firewall removendo as regras que continham nomes de URLs.

Lições:

1 – O iptables troca o nome pelo enderçõ IP.
2 – Um mesmo servidor pode hospedar URLs liberadas e bloqueadas.
3 – O iptables não atualiza a resolução DNS caso a URL mude de servidor.
4 – Se o firewall não estiver resolvendo nome na hora que o script estiver sendo executado a sua execução ficara presa até que o iptables de time-out na tentativa de resolução de nome.
5 – Por que não utilizar uma solução mais simples e já desenvolvida e estável para tratar as políticas de acesso WEB.

Feb 15

Erros básicos na hora de montar um firewall iptables

Revisando servidores linux que atuam como firewall encontrei as seguintes falhas básicas:

1. Não ativar o IP_FORWARD.

Isto pode ser verificado dando um cat no seguinte arquivo:

cat /proc/sys/net/ipv4/ip_forward

- Se estiver com valor 0 significa que está desativado e com isso não haverá roteamento.
- Para ativa-lo basta executar o seginte comando:

echo 1 > /proc/sys/net/ipv4/ip_forward

- Para tornar a alteração persistente a boot descomente a linha do arquivo /etc/sysctl.conf que contenha a seguinte entrada:

net.ipv4.ip_forward=1

Feito isso o firewall já estará fazendo o encaminhamento de pacotes.

2. Não colocar o script de firewall para ser carregado durante o boot.

3. Não analisar se o tamanho default da ip_conntrack é suficiente para atender a demanda do ambiente.

4. Não aumentar o file descriptor do kernel quando o firewall possui um proxy com grande volume de acesso.

5. Fazer regras de QOS no sentido em que o Linux não o faz tratamento.

Feb 14

Load Balance de emergência

Você administra um servidor linux que faz load balance com IPVSADM e está tendo problemas?

Dicas:

  1. Se o servidor possui firewall ativo lembre-se de que o trafego de retorno do servidor, a resposta da solicitação, é tratado como um pacote de estado inválido para o conntrack do linux assim como para o iptables. Logo você deve liberar o trafego que tem como origem o servidor web e porta de origem 80 e/ou 443.
  2. O trafego está liberado mas ainda não funciona, verifique se o IP VIP não está na mesma sub-rede dos servidores, pois o IPVSADM não costuma trabalhar com o ambiente neste formato o IP VIP tem que pertencer a outra rede isto minimiza os problemas.
  3. Tudo checado e ainda não funciona tente uma medida de teste extrema faça o load balance pelo iptables que faz o balanceamento utilizando o algoritmo Round Robin. Segue uma regra exemplo abaixo:

iptables -t nat -A PREROUTING -d 192.168.0.10 -p tcp –dport 80 -j DNAT –to 10.0.0.2-10.0.0.30:80 –persistent

Bom explicando a estrutura da regra no “-d” você deve colocar o IPVIP, já no –to do DNAT você deve colocar o endereço IP do primeiro servidore web unido por um hífen ao endereço IP do ultimo servidor web membro do pool.

Feb 10

Nat um para um com uma única linha

Galera,

Fazendo um tshoot em um firewall que tinha que fazer uma série de regras de nat um para um e vi no bom e velho man uma alternativa para não ter o trabalho cansativo e penoso digitando mais de duzentas regras.

A dica é o NETMAP que nele voce vai informar a rede que deverá ser a mascara da rede abaixo.

ex.:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 172.16.0.0/24 -j NETMAP –to 10.0.0.0/24

Obs.:

Ele só funciona na tabela NAT.

Feb 09

Adicionando a chave publica do APT

Galera,

Este post está mais para uma cola pois vivo esquecendo os passos.

gpg –keyserver pgp.mit.edu –recv-key 9AA38DCD55BE302B
gpg -a –export 9AA38DCD55BE302B | apt-key add -

apt-get clean all

apt-get update

Att.

Feb 07

Script para tirar os inserts de uma tabela de um sql dump de uma database

script para coleta de uma tabela de um sql de backup de uma database

#!/bin/bash
#
# Este scrit gera um novo arquivo .sql com o conteúdo de criação e insercao dos dados
#a partir de um .sql de backup de uma database inteira
#

# Definindo as variaveis estaticas
EGREP=$(which egrep)
CAT=$(which cat)
AWK=$(which awk)

# Solicitando o nome da tabela
printf “Informe o nome da tabela que deve ter o seu conteudo retirado do sql de backup do banco.\n”
read TABLENAME;

# Solicitando o nome do arquivo de backup do banco com o caminho de acesso ao mesmo
printf “Informe o nome do arquivo de backup do banco de dados com o caminho de acesso completo ao mesmo.\n”
read DBBACKUPFILE;

# Solicitando o path onde o sql da tabela deve ser salvo
printf “Informe o caminho onde deseja que o arquivo com os inserts da tabela sejam salvos.\n”
read PATHFILE;

# Definindo as variaveis dinamicas
DESTINATIONFILE=”$PATHFILE/$TABLENAME.sql”

# Executando a retirada do conteudo
$EGREP -ni “INSERT INTO \`$TABLENAME\` VALUES” $DBBACKUPFILE > $DESTINATIONFILE

# Informando o termino da extracao do conteudo
printf “A extracao da tabela $TABLENAME foi concluida e salva no $DESTINATIONFILE\n”

Feb 07

Firewall iptables persistente ao boot no Debian/Ubuntu

Galera,

Analisando alguns fóruns de distros encontrei a menção à alternativa para quem não está afim de digitar um script tradicional contendo funções STOP – START – RESTART as regras de firewall digitadas nele e ainda ter que atualizar a listagem de scripts carregados na inicialização do sistema. A alternativa e a utilização do networking para fazer este trabalho.

Vamos aos passos:

1 - Crie o arquivo /etc/network/if-up.d/iptables

2 - Coloque nele um conteúdo como o abaixo:

#!/bin/bash
/sbin/iptables-restore < /etc/iptables.rules

3 - Salve o arquivo alterado e atribua a permissão de execução.

4 - Crie o arquivo /etc/network/if-down.d/iptables

5 - Coloque nele um conteúdo como o abaixo:

#!/bin/bash
/sbin/iptables-save > /etc/iptables.rules
/sbin/iptbales-restore < /etc/iptablesstop.rules

6 - Salve o arquivo alterado e atribua a permissão de execução.

7 - No exmplo coloquei um dump com nenhuma regra que foi /etc/iptablesstop.rules
abixo segue o conteudo dele

# Generated by iptables-save v1.4.8 on Tue Feb 7 16:41:50 2012
*raw
: PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Tue Feb 7 16:41:50 2012
# Generated by iptables-save v1.4.8 on Tue Feb 7 16:41:50 2012
*nat
: PREROUTING ACCEPT [0:0]
: POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Completed on Tue Feb 7 16:41:50 2012
# Generated by iptables-save v1.4.8 on Tue Feb 7 16:41:50 2012
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Tue Feb 7 16:41:50 2012

Abraços

Feb 07

Inserindo comentário na prória regra de iptables

Galera,

Hoje ao ver um colega re-escrevendo um script de firewall iptables para colocar comentários de informação no script pois o cliente havia solicitado as regras de firewalls presentes no servidor. Me lembrei da match do iptables ou módulo para que quiser que já inclui isso na própria regra.

Como qualquer um de nós normalmente faz todas as reagras de firewall foram feitas sem comentários nas mesmas, mas para quem não sabe é possível colocar um comentário em uma regra e facilitar o entendimento do porque ela está lá. Para isto basta colocar:

-m comment –comment “A informação que desejar entre as aspas”

ex:

iptables -A INPUT -m state –state ESTABLISHED,RELATED -m comment –comment “Acesso de conexões estabelecidas e relacionadas” -j ACCEPT

depois disso é so correr pro abraço.

Vlw.

Older posts «