Archive

Archive for December, 2009

Código de erros e status – Squid

December 30, 2009 1 comment

Mais um achado. O significado dos códigos de status e erros encontrados nos logs do squid. Mais uma vez segue a fonte. 🙂

http://jczucco.blogspot.com/2006/04/squid-result-codes.html

TCP_HIT
Uma cópia válida do objeto pedido estava no cache.

TCP_MISS
O objeto requisitado não estava no cache.

TCP_REFRESH_HIT
O objeto solicitado foi armazenado em cache, mas esta obsoleto. A consulta IMS para o objeto resultou em uma mensagem “304 não modificado”.

TCP_REF_FAIL_HIT
O objeto solicitado foi armazenado em cache, mas esta obsoleto. A consulta IMS falhou eo objeto obsoleto foi entregue.

TCP_REFRESH_MISS
O objeto solicitado foi armazenado em cache, mas está obsoleto. A consulta IMS devolveu o novo conteúdo.

TCP_CLIENT_REFRESH_MISS
O cliente emitiu um “no-cache” Pragma, ou algum comando de controle de cache análogo junto com a solicitação. Assim, o cache tem que reler o objeto.

TCP_IMS_HIT
O cliente emitiu uma solicitação IMS para um objeto que estava no cache e atual.

TCP_SWAPFAIL_MISS
O objeto acreditava estar no cache, mas não pôde ser acessado.

TCP_NEGATIVE_HIT
Pedido de um objeto em cache negativamente, por exemplo, “404 não encontrado”, para o qual o cache acredita que o objeto esta inacessível. Mas Também se referem a opção “negative_ttl” no seu arquivo squid.conf.

TCP_MEM_HIT
Uma cópia válida do objeto pedido estava no cache e na memória, evitando acessos ao disco.

TCP_DENIED
O acesso foi negado para esta solicitação.

TCP_OFFLINE_HIT
O objeto solicitado foi recuperada da cache durante o modo offline. O modo offline não valida qualquer objeto, veja o que é modo offline(comando offline_mode) no arquivo squid.conf.

UDP_HIT
Uma cópia válida do objeto solicitado estava no cache.

UDP_MISS
O objeto solicitado não está no cache.

UDP_DENIED
O acesso foi negado para esta solicitação.

UDP_INVALID
Uma solicitação inválida foi recebida.

UDP_MISS_NOFETCH
Durante o inicio “-Y”, ou durante as falhas freqüentes, um cache em modo hit only irá retornar cada UDP_HIT ou este código. Vizinhos devem, deste modo, somente buscar hits(exitos).

NONE
Seen with errors and cachemgr requests.

Os seguintes códigos nao estao mais disponivel no Squid versão 2:

ERR_*
Erros contém o código de status http.

TCP_CLIENT_REFRESH
Veja: TCP_CLIENT_REFRESH_MISS.

TCP_SWAPFAIL
Veja: TCP_SWAPFAIL_MISS.

TCP_IMS_MISS
Excluido, TCP_IMS_HIT usado.

UDP_HIT_OBJ
objects Hits(com exito) não estão mais disponiveis.

UDP_RELOADING
Veja: UDP_MISS_NOFETCH.

Atenciosamente 😀

Códigos de erros – Protocolo HTTP

December 30, 2009 Leave a comment

Encontrei essa listagem com os códigos de erros e status mais comuns do protocolo HTTP e resolvi postar aqui. Segue a fonte abaixo.

http://jczucco.blogspot.com/2006/04/http-status-codes.html

000 Used mostly with UDP traffic.

100 Continue
101 Switching Protocols
*102 Processing

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
*207 Multi Status

300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See Other
304 Not Modified
305 Use Proxy
[307 Temporary Redirect]

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request URI Too Large
415 Unsupported Media Type
[416 Request Range Not Satisfiable]
[417 Expectation Failed]
*424 Locked
*424 Failed Dependency
*433 Unprocessable Entity

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
*507 Insufficient Storage

600 Squid header parsing error

Atenciosamente 🙂

Categories: Protocolos

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

Meu primeiro post – Pizza via shell

December 18, 2009 2 comments

Meu primeiro post e um desafio do meu amigo Paulo, ele vive querendo mostrar que Operations Manager da Microsoft e superior ao Nagios pode até ser mas dúvido ele pedir pizza via script de monitoramento. No link abaixo mostra um script para pedir pizza online. Paulão Chupa essa manga 😛

http://www.beigerecords.com/cory/Things_I_Made/PizzaParty

😀

Categories: curiosidades