Archive

Archive for the ‘Troubleshooting e problemas resolvidos’ Category

Firefox me bloqueando???

November 14, 2012 Leave a comment

Ola pessoal, esses dias estava configurando o varnish acelerador web e coloquei ele para funcionar na porta 79, uma antes da 80 :P. Ao terminar de configurar fui testar o acesso e olha o que o firefox me disse.

Sim senhores o firefox tem uma proteção por porta, mas fique tranquilo e fácil resolver isso, vamos lá:

Acesse o “painel de configuração” do firefox.

  • Abrir uma nova aba e digitar about:config
  • Uma mensagem será exibida, clique em “Serei cuidadoso, eu prometo!”
  • Clique com o botão direito em qualquer área dentro das configurações exibidas.
  • No menu de contexto aberto selecione Nova preferência > String.
  • Digite: network.security.ports.banned.override e clique em OK
  • Ele solicitara o valor, digite o número da porta que esta tentando acessar e depois tente o acesso.

t+

pisando no freio do kernel

November 7, 2012 1 comment

Ola pessoal, nessa semana recebi a tarefa, de instalar um servidor bacula em um servidor HP ML330. Instalei o ubuntu normalmente, mas na hora de inicializar surgia o seguinte erro.

Starting up…
Loading, please wait…
Gave up waiting for root device. Common problems:
-Boot args (cat /proc/cmdline)
-Check root delay = (did the system wait long enough?)
-Check root=(did the system wait for the right device?)
-Missing modules (cat /proc/modules; ls /dev)

ALERT! /dev/disk/by-uuid/aa10r6jd-2r58-75dy-j7op-3gh56kl98nb does not exist. Dropping to a shell!

BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

(initramfs)

Após isso não inicializava o kernel e ficava no prompt, quando entrei no prompt do busybox(para quem não sabe busybox, é o conjunto de utilitários do linux customizados em que o objetivo é ser pequeno, para ser executados em dispositivos embarcados como celular, flash, etc), e listei o diretório /dev/, ele exibia os device da controladora. O hardware era uma controladora SCSI Compaq. Após analisar desconfiei que poderia o kernel estar sendo muito mais rápido que a controladora, então pesquisando encontrei o parametro “rootdelay” que retarda a inicialização. Então na inicialização do grub apertei a tecla “e”, e editei o grub em tempo de execução, e adicionei a seguinte linha no kernel

linux /boot/vmlinuz-3.2.0-23-generic root=UUID=4cb78f3e-a217-4b05-883c-443fc67ca52f ro rootdelay=140 vga=normal

Apos iniciar o kernel e aparecer o prompt de login, faça o login normalmente e edit o arquivo /etc/default/grub e adicione os parametros.

GRUB_CMDLINE_LINUX_DEFAULT=”rootdelay=60 vga=normal “

Depois execute:

sudo update-grub

Com isso o kernel retarda a inicialização e a controladora SCSI fica pronta e entrega os devices para o kernel.

🙂

Ataque de botnet

December 19, 2009 3 comments

Vou postar um problema que tive em um servidor de e-mail que administro. Além do problema vou relatar a solução que apliquei para resolver o problema, com isso achei interessante publicar. Tenho o seguinte ambiente, servidor mta postfix, firewall Microsoft ISA Server.

Os e-mail vem a partir da internet atravessam o firewall e são entregues ao mta. O mta não tem endereço válido, portanto temos um nat estático. Monitorando o uso do mta durante períodos do dia e noite, o volume de tráfego era muito intensivo e a fila de e-mail chegava a ter 30mil e-mails. Um valor muito alto para o volume normal de e-mail.

A partir daí começou minha jornada para resolver problema, aumentei o nível de checagens na chegada dos e-mails. Apliquei as seguintes restrições:

# O numero maximo de tentativas de conexoes de qualquer clientes sao permitidas.
smtpd_client_connection_rate_limit = 15
# Como várias conexoes simultaneas de qualquer cliente e permitida
smtpd_client_connection_count_limit = 15
# O numero maximo de pedidos para entrega de mensagens de qualquer cliente é permitido
smtpd_client_message_rate_limit = 15
# O numero maximo de enderecos de destino que qualquer cliente pode enviar.
smtpd_client_recipient_rate_limit = 15

Tentei uma series de combinações de restrições via os “smtpd_X_restrictions” do postfix, mas sem sucesso, li e reli vários históricos de listas de discussões, li a documentação do postfix mas nada adiantou, até que resolvi monitorar a conexão com um sniffer(wireshark), e finalmente resolvi o problema. Segue abaixo os procedimentos e passos que segui para resolver o problema.

Diário de bordo.

Percebi um ataque vindo do ip 69.3.86.74, o spammers spoofava o from com o email “login@rbc.com” e enviava e-mails para vários destinos, dava para perceber que a lista de e-mails era gigante. Então comecei a monitorar pelo ip do spammer via sniffer e via logs do postfix.

# tshark -V host 69.3.86.74 > wireshark.log
# tail -f /var/log/mail.log | ack-grep –passthru “login@rbc.com”

Após monitorar analisando os logs notei o seguinte trechos do arquivo wireshark.log truncando alguns itens.

Logo depois do three-hanshake vemos a seguinte conexão:

Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 200.193.244.45 (69.3.86.74)
Version: 4

O MTA é 192.168.0.2 respondendo ao spammer(69.3.86.74)

Agora o payload smtp

Response: 220 mail.dominio.com.br ESMTP Postfix\r\n
Response code: 220
Response parameter: mail.dominio.com.br ESMTP Postfix

Agora o EHLO

Simple Mail Transfer Protocol
Command: EHLO [xxx.xxx.xxx.xxx]\r\n
Command: EHLO
Request parameter: [xxx.xxx.xxx.xxx]

Agora vemos o pedido de autenticação

Simple Mail Transfer Protocol
Response: 250-mail.dominio.com.br\r\n
Response code: 250
Response parameter: mail.dominio.com.br
Response: 250-PIPELINING\r\n
Response code: 250
Response parameter: PIPELINING
Response: 250-SIZE 51200000\r\n
Response code: 250
Response parameter: SIZE 51200000
Response: 250-VRFY\r\n
Response code: 250
Response parameter: VRFY
Response: 250-ETRN\r\n
Response code: 250
Response parameter: ETRN
Response: 250-STARTTLS\r\n
Response code: 250
Response parameter: STARTTLS
Response: 250-AUTH PLAIN LOGIN\r\n
Response code: 250
Response parameter: AUTH PLAIN LOGIN
Response: 250-AUTH=PLAIN LOGIN\r\n
Response code: 250
Response parameter: AUTH=PLAIN LOGIN
Response: 250-ENHANCEDSTATUSCODES\r\n
Response code: 250
Response parameter: ENHANCEDSTATUSCODES
Response: 250 8BITMIME\r\n
Response code: 250
Response parameter: 8BITMIME

Vemos o envio de usuário e senha por parte do spammer.

Simple Mail Transfer Protocol
Command: AUTH PLAIN AHJpY2FyZG8AUEBzc3cwcmQ=\r\n
Command: AUTH
Request parameter: PLAIN AHJpY2FyZG8AUEBzc3cwcmQ=

E olhe a resposta do postfix (MTA), para o spammer.

Simple Mail Transfer Protocol
Response: 235 2.7.0 Authentication successful\r\n
Response code: 235
Response parameter: 2.7.0 Authentication successful

Verificando os logs do postfix(mail.log) verifiquei o usuário em questão.

Dec 18 14:46:20 mail postfix/smtpd[742]: 030CC681FD: client=unknown[69.3.86.74], sasl_method=PLAIN, sasl_username=maria

Após isso e com o postfix utilizando SASL fiz o seguinte teste com o utilitário testsaslauthd.

root@mail:~# testsaslauthd -u maria -p 123456
0: NO “authentication failed
root@mail:~# testsaslauthd -u maria -p 123
0: OK “Success.”
root@mail:~#

Duas tentativas que fiz descobri a senha frágil da “maria”, entrei em contato com o cliente e pedi que alterasse sua senha e os volume de 3 mil e-mails pararam.

Postei esse troubleshooting como prova de que senhas dificeis sao utéis, e uma politica de senha na empresa é essencial, é e sempre será de suma importância no ambiente corporativo. Portanto sysadmins, vamos cobrar politica de senhas para por fim aos spammers 😀

Até a próxima