Escrito por Helio Loureiro
Categoria:

Não dá mais pra ignorar os dispositivos móveis.   Não é somente na televisão, Internet e no dia à dia que vemos os smartphones e tables.  Na estatística de acesso ao site eles também estão aparecendo, e de forma crescente.

Eu mesmo tenho usado bastante meu celular Nexus S para navegar na web (principalmente quando estou na cama) e nada me irrita mais que acessar um site não preparado para ele, que fica mais de 1 minuto para carregar as páginas.  Mas não adianta nada reclamar dos outros se nem mesmo eu tava prestando a devida atenção a isso.

Então instalei o módulo Mobilebot do Joomla para modificara formatação do site para dispositivos móveis.

Como ainda está em fase de testes, não prometo uma grande melhoria o resolução imediata dos problemas, mas já é um começo.

Escrito por Helio Loureiro
Categoria:


Finalmente cheguei à conclusão do motivo das falhas de SSH.  Eu não tinha me dado conta, mas o problema surgiu depois do upgrade do Ubuntu que estou usando no laptop, para a versão 11.10 (Oneiric).

Como fui conectar em um outro servidor e tive o mesmo erro, vi que não era problema do Solaris, mas sim do cliente ssh.  Então tentei uma conexão em modo de debug:

helio@shibboleet:~$ ssh -C -v slowlaris
OpenSSH_4.2p1 Debian-4.sesarge.2, OpenSSL 0.9.7m 23 Feb 2007
debug1: Reading configuration data /home/helio/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to slowlaris [1.2.3.103] port 22.
debug1: Connection established.
debug1: identity file /home/helio/.ssh/identity type 0
debug1: identity file /home/helio/.ssh/id_rsa type 1
debug1: identity file /home/helio/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: no match: Sun_SSH_1.1.3
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-4.sesarge.2
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information
SPNEGO cannot find mechanisms to negotiate
debug1: Offering GSSAPI proposal: (null)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'slowlaris' is known and matches the RSA host key.
debug1: Found key in /home/helio/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Trying to start again
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/helio/.ssh/id_rsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Offering public key: /home/helio/.ssh/id_dsa
Received disconnect from 1.2.3.103: 2: Too many authentication failures for minsat

Dessa vez olhei com mais atenção a saída do comando.  Notei vários erros com a mensagem "Unspecified GSS failure.  Minor code may provide more information" e uma referência aos tipos de autenticação "gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive".  Então busquei pelos erros de ssh com gssapi na Internet e... BINGO!  Achei uma opção simples para desativar o mesmo, que deve ter mudado com o upgrade do openssl.  Basta passar o parâmetro "-o GSSAPIAuthentication=no".

helio@shibboleet:~$ ssh -C -v -o GSSAPIAuthentication=no slowlaris
OpenSSH_4.2p1 Debian-4.sesarge.2, OpenSSL 0.9.7m 23 Feb 2007
debug1: Reading configuration data /home/helio/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to slowlaris [1.2.3.103] port 22.
debug1: Connection established.
debug1: identity file /home/helio/.ssh/identity type 0
debug1: identity file /home/helio/.ssh/id_rsa type 1
debug1: identity file /home/helio/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: no match: Sun_SSH_1.1.3
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-4.sesarge.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'slowlaris' is known and matches the RSA host key.
debug1: Found key in /home/helio/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/helio/.ssh/id_rsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Offering public key: /home/helio/.ssh/id_dsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password: 
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Remote: Channel 0 set: LANG=en_US.UTF-8
Last login: Tue Dec  6 11:30:56 2011 from 1.2.3.7
Oracle Corporation      SunOS 5.10      Generic Patch   January 2005
You have new mail.
[helio@slowlaris ~]> 


Para evitar digitar essa opção em todas as conexões, simplesmente adicionei o parâmetro em ".ssh/config".  E fim dos problemas.


Fonte: http://www.walkernews.net/2009/04/06/how-to-fix-scp-and-ssh-login-prompt-is-very-slow-in-linux/

Escrito por Helio Loureiro
Categoria:

Hoje fui brindado com essa mensagem ao tentar acessar por ssh uma workstation Sun Ultra 10 que tenho por aqui.  Simplesmente não conseguia conectar por ssh.

helio@shibboleet:~$ ssh ultra10
Received disconnect from 1.2.3.241: 2: Too many authentication failures for helio

Felizmente o acesso por telnet estava disponível.  Não encontrei nada relacionado à ssh que pudesse estar bloqueando meu acesso.  Mas como estava rodando um programa que testava acesso via ssh para outra máquina, que abria várias threads, imaginei que isso tivesse matado todo os meus max_files_open disponíveis.

Mas mesmo matando todos os processos ssh, continuei com esse problema.

ultra10{root} #: ps -ef | grep -i ssh | awk '{print $2}' | xargs kill -9

Tentei parar o serviço e abrir o ssh em modo de debug: 

ultra10{root} #: svcadm disable ssh
ultra10{root} #: /usr/lib/ssh/sshd -f -dd

Mas também sem nenhuma ajuda claro.  Olhando na Internet achei que era possível arrumar isso alterando o parâmetro " MaxAuthTries".  Editei então o arquivo "/etc/ssh/sshd_config" e deixei as entrada da seguinte forma:

MaxAuthTries    60
MaxAuthTriesLog 30

O ssh voltou a funcionar.  Resta agora descobrir como meu programa com expect e threads causou isso.

Escrito por Helio Loureiro
Categoria:

 Recentemente foi liberado o Joomla 1.5.25 em http://www.joomla.org com várias correções sérias de exploração de falha por XSS.  

A série 1.5.x refere-se à versão estável.  Para as versões de desenvolvimento, atualização para 1.7.3 corrige essa falha.

Se você é usuário de Joomla, não perca tempo e atualize logo seu CMS.

Joomla 1.7.3 completo

Patch do Joomla 1.7.3 a partir do 1.7.2

Joomla 1.5.25 completo

Patch do Joomla 1.5.24 a partir do 1.5.25



Escrito por Helio Loureiro
Categoria:

Faz um pouco mais de uma ano desde a aquisição do netbook Dexnet N280 através da loja online da  Saraiva.  Na época em que escrevi sobre o mesmo por aqui, algumas pessoas me alertaram sobre o problema com as dobradiças da tela.  Após pouco mais de 1 ano utilizando o netbook, e esses problemas começaram a dar as caras.

Não resta muito o que fazer uma vez que o problema parece ser por desgaste do material (não pelo uso contínuo, mas pela baixa qualidade), então estou procurando a nota fiscal para notificar o fabricante e solicitar reparo do equipamento.  Eu só não lembro se a garantia era de mais de 1 ano.  Se não for, só me resta chorar...

Escrito por Helio Loureiro
Categoria:

Tudo tem um início.  Para fazer o restante dos artigos inteligíveis, é preciso explicar um pouco de telefonia, mais precisamente da transmissão da telefonia em forma de dados.  Ou na verdade como a voz vira dados.

Na figura abaixo é mostrado um exemplo, bem simplificado e limitado, de chamadas telefônicas em sistemas que chamamos de "rede fixa".  Antes da chegada dos celulares, era o que conheciamos como telefonia.




O telefones se comunicam com as "centrais telefônicas", ou "centrais de comutação", que pegam o conteúdo de voz do assinante e enviam para o destino.  As centrais telefônicas fazem também o roteamento para o telefone de destino.

Não entrando muito sobre os detalhes do antigo sistema de telefonia, mas comentando da parte que realmente interessa, basta saber que a comunicação entre os telefones e a central telefônica se faz de forma analógica.  Uma vez a voz chegando na mesma, essa é digitalizada e trocada entre as outras centrais totalmente digital.  Ao chegar na central do telefone destino, essa voz digitalizada é convertida em formato analógico novamente.

Os primeiros celulares usavam algo muito parecido, inclusive enviado o conteúdo da chamada (voz) em forma analógica, o que permitia a "escuta" da mesma.  Apesar da tecnlogia CDMA naquela época já permitir chamadas digitais, no Brasil adotou-se o formato analógico provavelmente pelo alto custo dos aparelhos celulares digitais.  Já no GSM, a comunicação é completamente digital.  Qualquer tecnologia a partir do GSM tem-se a chamada telefônica completamente digital.  O responsável pela digitalização é o próprio celular.

Não importando muito para explicar a rede de telefonia pré-paga, mas como curiosidade, existem dois modos de digitalização de voz: a lei-A e a lei-µ  (lei-mi).  Nos EUA é usada a lei-A e aqui no Brasil, a lei-µ.

Ambas as leis designam com quantos bits será digitalizada a voz.  Não em relação à quantidade, mas em relação à inclinação da curva de frequência da voz.  Falando de forma mais simplificada, quando a voz é mais grave, usa-se menos bits, quando é mais aguda, mais bits.  Onde e quando usar esses bits é o que é mapeado pelas tais leis.  Em geral ao se trocar os codecs de voz e misturar as leis, de um lado se ouve a tal "voz de pato", e do outro, a voz do Darth Vader.

Como o nosso espectro de voz, ou faixa de frequência da voz, varia entre 300 Hz e 4KHz, usa-se uma amostragem de 8 KHz para ser digitalizada.  Essa digitalização é feita por meio de pulsos, os chamados PCM, Pulse Coded Modulation, que "medem" a intensidade da voz e a digitalizam.

Essa voz digitalizada é transmitida entre as centrais telefônicas dentro de um link de 2 Mbps no Brasil (os chamados links E1) e 1.5 Mbps nos EUA (links T1).  Vários links E1 são agregados em links maiores, como links STM-1 (155 Mbps) ou até como STM-4 ( 622 Mbps).  Apesar do mundo IP já adotar redes de maior velocidade, com links de 10 Gbps, as redes de telefonia em geral ficam dentro do 622 Mbps.

Essa comunicação entre centrais com esses links é o que veremos nos próximos artigos.

Escrito por Helio Loureiro
Categoria:

Já faz algum tempo tenho pensado em falar um pouco mais sobre telecomunicações por aqui.  Não que eu entenda muito de telefonia, mas boa parte dos sistemas em que trabalho, em geral redes de pré-pago, são na verdade máquinas Unix rodando ou Linux ou Solaris e com bancos de dados MySQL ou Oracle.  Algo bem mais simples que muita gente imagina.

Quando comecei a trabalhar nessa área, também tinha uma idéia de que centrais e serviços telefônicos rodavam em sistemas complexos e dedicados, com algum tipo de linguagem alienígena e que não seriam inteligíveis pelos outros seres humanos.  Em parte eu estava certo.  Existem as centrais de comutação, ou centrais telefônicas, que realmente são algo nesse nível.  Mas existem sim sistemas mais simples (pra nós, humanos) que rodam o bom e velho Linux.  Claro que isso não significa que eles estão somente lá pra fazer backup usando o comando "tar".  Existem também aplicativos sobre os mesmos que suportem aplicações de telefonia, dentro dos requisitos definidos para tal (como tempo de resposta menor de 10 ms por exemplo).

Então espero de agora em diante colocar aqui um pouco de conhecimento sobre essa parte do sistema de telefonia, esclarecendo tanto a parte Unix quanto a parte de telefonia em si.


Escrito por Helio Loureiro
Categoria:

Terror da Internet, os ataques de DDoS ficaram em evidência ultimamente por causa dos grupos AnonOps e LuzSec, que atacaram vários sites usando essa técnica.  

DDoS nada mais é que um ataque do tipo "estouro de boiada".  Utilizando máquinas contaminadas, usa-se um programa "administrador" que envia o agendamento do ataque, com data e horário, para uma máquina de destino.  No caso esse destino foi num dos servidores que administro.  Por acaso onde está o serviço do http://eri.cx entre outros.

O ataque não foi dirigido diretamente à mim, mas um dos sites hospedados lá (não, não foi pro eri.cx).  Durante um ataque DDoS, isso não importa muito pois tudo que está hospedado no servidor é afetado juntamente.  Ou os serviços tornam-se indisponíveis ou a máquina pode travar, o que não deveria acontecer.   Mas um ataque DDoS não abre brechas pra invasão ou algo do gênero.

Leia mais:O dia em que sofri um ataque de DDoS
Escrito por Helio Loureiro
Categoria:

Site atualizado para última versão estável, 1.5.23.  


Estava pensando em migrar para 1.7, mas acabei descobrindo pelo FAQ que a versão 1.5.x é uma LTS, Long Term Supported, ou suporte de long prazo.

Então vou continuar na geração 1.5.x por enquanto.

Escrito por Helio Loureiro
Categoria:

No sistema de agendamento de tarefas, o cron, existe a possibilidade de controle de acesso pelos arquivos /etc/cron.allow/etc/cron.deny.  Existindo somente o /etc/cron.allow no sistema, o usuário deverá ter seu login incluso nesse arquivo para fazer uso do cron.  Do contrário será brindando com uma mensagem semelhante a essa:

You (helio) are not allowed to use this program (crontab)
See crontab(1) for more information

Nos ambientes de telecomunicações, onde muitos dos sistemas operacionais em uso são Solaris, ex-Sun e agora da Oracle, esses vêm com essa forma de controle do cron habilitada por padrão.

Isso aumenta a segurança do sistema, mas também torna alguns trabalhos simples mais difíceis, principalmente quando é necessário ter agendamento de trabalho.  Claro que isso poderia ser resolvido com ajuda de um bom administrador de sistemas, o sysadmin, e conhecimento em Unix, mas isso parece estar se tornando cada vez mais raro nesses dias.

Então criei o mycrond, um daemon escrito em perl, para rodar periodicamente como o crond do sistema.  A sintaxe não é perfeita e tem alguns furos, como não aceitar "*/5" para tarefas a cada 5 intervalos, mas utiliza uma sintaxe que somente Solaris aceita como, por exemplo para tarefas agendadas para cada 5 minutos, utilizar "0,5,10,15,20,25,30,35,40,45,50,55".  O restante é parecido com o uso normal da crontab.

Não é 100% perfeito, pois acabei deixando a análise de sintaxe incompleta para todos os valores de data, mas funciona perfeitamente como daemon, não morrendo ao sair do sistema, e é capaz de analisar e rodar formas mais simples da crontab.


Leia mais:mycrontab
Escrito por Helio Loureiro
Categoria:

Não tem nada mais chato que sistema lento.  Atualmente não dá pra aguentar um sistema que fica cortando a música que se está ouvindo só porque o Firefox consumiu 2 GB de memória, a máquina virtual no VirtualBox tá com mais 2 GB alocados e ainda tá compilando um kernel.

Pois é exatamente o que tem acontecido e muito em Linux.  Não sei de outras distribuições, mas especificamente em Ubuntu.

Como os patches de tempo real foram incluídos na árvore principal do kernel já faz algum tempo, isso deveria estar bem mais amenizado.  Fui em busca de informação sobre como ativar tal função e encontrei o comando "chrt" (change realtime talvez).

Lendo o manual do chrt, é possível ver uma gama de opções sem muitas explicações, nem comparativos de resultados.  Isso não ajuda muito na ampla adoção do mesmo.  Eu acabei fazendo alguns experimentos tanto em Intel 32 bits quanto em 64 e consegui um resultado supreendemente bom e bem fácil.  Apenas adicionei prioridade de tempo real ao processo init.

chrt -r -p 1 1

Esse comando adiciona a política de escalonamento SCHED_RR ao processo ID 1 (init) com prioridade 1. 

A política default do init é SCHED_OTHER, que de acordo com manual - SCHED_SETSCHEDULER(2) - significa:

SCHED_OTHER   política padrão de round-robin baseado em compartilhamento de tempo

SCHED_RR      política round-robin

Olhando mais a fundo o manual do escalonador, é possível ver que somente o SCHED_RR ativa a funcionalidade de tempo real.

Então basta adicionar esse comando no "/etc/rc.local" do Ubuntu/Debian para ter um sistema sem problemas de "travadinhas" quando sobrecarregado.  Eu fiquei mesmo surpreso em como foi fácil melhorar o desempenho do sistema e como isso não é incluído por padrão nos sistemas.


Escrito por Helio Loureiro
Categoria:

Ultimamente, monitorando meu encurtador eri.cx, notei que o mesmo estava recebendo muitos links sem nenhum clique.  Olhando mais de perto pude ver que os mesmos eram relacionados à SPAM/vírus.  Alguns robôs de Internet, ou mesmo máquinas zumbis, que adicionam esses links suspeitos.

Um dos agressores foi claramente o IP 213.5.66.88.   Resolvi o problema adicionando-o em duas regras de firewall bem simples:

iptables -A INPUT -p tcp --dport 80 -s 213.5.66.88 -j LOG
iptables -A INPUT -p tcp --dport 80 -s 213.5.66.88 -j REJECT

Criei uma tabela chamada quarantine e migrei as entradas do banco para lá, manualmente.  E também notifiquei os administradores do site sobre o ocorrido, enviando mail para abuse@site e security@site.

Achei que a solução era perfeita e que tinha resolvido meus problemas.  Essa semana dei uma  olhada novamente na base do encurtador.  De 900 links inseridos, uns 350 eram desse tipo (malditos SPAMMERS!).

Chorei minhas mágoas no Twitter, bem no estilo "reclamar no Twitter muito", e recebi algumas sugestões para evitar esses ataques.  Mesmo meu guru mental para idéias técno-copiadas, Eduardo Maçan, que administra o encurtador miud.in -- do qual chupinhei várias coisas, sugeriu uma verificação do encurtador via web através do refereer antes de encurtar qualquer link.

Pensei em fazer isso, mas tornaria impossível notificar os administradores dos sites afetados que suas máquinas estão comprometidas, e fora o problema de performance que poderia ocorrer ainda mais que o hosting que contratei tem somente 64 MB de RAM e CPU compartilhada num ambiente Xen.  Então resolvi mudar a abordagem e simplesmente deixar as máquinas zumbis adicionarem as URLs "do mal".  Mas uma vez por dia eu rodo um programa em Python que faz a busca de padrões desses vírus/scammers, move pra base do quarentine (assim ninguém clicará nos mesmos) mantendo as mesmas entradas, e comunica ao mails abuse@domínio e security@domínio sobre o ataque.

Então segue o script que fiz para esse fim.

#! /usr/bin/python
# -*- coding: utf-8 -*-
# $Id:$ 

# COPYRIGHT
#
#    Copyright (c) 2011 by Helio A. L. Loureiro
#
#    Permission to use, copy, modify, distribute, and sell this software
#    for any purpose is hereby granted without fee, provided that the above
#    copyright notice appear in all copies and that both that copyright
#    notice and this permission notice appear in supporting documentation.
#    No representations are made about the suitability of this software for
#    any purpose. It is provided "as is" without express or implied
#    warranty.

### main code
from os import popen
from re import sub, search
import smtplib
from time import ctime,strftime


mysqldb = "eri.cx"
mysqluser = "eri.cx"
mysqlpasswd = "xc.ire"
log_dir = "/var/log"

# Enviando mensagens
def Log(msg):
	log_file = log_dir + "/report-sql-spam-" + \
		strftime("%Y-%m") + ".log"
	msg = msg.rstrip("\n")
	msg = "[ " + ctime() + " ] " + msg + "\n"
	log = open(log_file, "a")
	log.write(msg)
	log.close()

# Formatando o texto do mysql
def GenSQLCommand(sql):
	cmd = "mysql -u %s -p\'%s\' %s << EOF" % (mysqluser, mysqlpasswd, mysqldb)
	cmd = cmd + "\n" + sql + "\n" + "EOF\n"
	
	return cmd
	
def RetrieveMySQL():
	sql = """SELECT 
	yourls_url.keyword,
	yourls_url.url, 
	yourls_url.title,
	yourls_url.timestamp,
	yourls_url.ip,
	yourls_url.clicks
	FROM yourls_url WHERE  
	yourls_url.title like '%dingo.ucsf.edu%' OR
	yourls_url.title like '%cssa.grad.wustl.edu%' OR
	yourls_url.title like '%wiki.usfca.edu%' OR
	yourls_url.title like '%pantherfile.uwm.edu%' OR
	yourls_url.title like '%csci.marietta.edu%' OR
	yourls_url.title like '%webfiles.uci.edu%' OR
	yourls_url.title like '%Ultram %' OR
	yourls_url.title like '%Cialis%' OR
	yourls_url.title like '%Tramadol%' OR
	yourls_url.title like '%xanax%' OR
	yourls_url.title like '%viagra%' ORDER BY yourls_url.keyword;
	"""
	cmd = GenSQLCommand(sql)
	
	sql_result = popen(cmd).readlines()
	sql_result = sql_result[1:]

	return sql_result
	
def InsertQuarantine(db_lines):
	sql = """INSERT INTO yourls_quarantine 
	(keyword, url, title,timestamp,ip,clicks) VALUES """
	for e in db_lines:
		sql = sql + "\n( "
		e = e.rstrip("\n")
		for d in e.split("\t"):
			sql = sql + "\'" + d + "\', "
		sql = sql[:-2] + " ),"
	sql = sql[:-1]
	cmd = GenSQLCommand(sql)
	popen(cmd).read()
	
def DeleteEntries(keywords):
	sql = """DELETE FROM yourls_url USING yourls_url WHERE """ 
	sql = sql + "keyword = \"%s\"" % keywords[0]
	for k in range(1, len(keywords)):
		sql = sql + "OR keyword = \"%s\"" % keywords[k]
		
	cmd = GenSQLCommand(sql)
	popen(cmd).read()
	
def GetDomain(url):
	url = sub("^http://", "", url)
	url = sub("^https://", "", url)
	url = sub("/.*", "", url)
	
	return url

def SendMail(rcpts, msg):
	fromaddr = "helio" + "@" + "domain.com"
	mail = smtplib.SMTP('localhost')
	mail.sendmail(fromaddr, rcpts, msg)
	mail.quit()

def Main():
	spam_list = RetrieveMySQL()
	
	ATTACKED = {}
	KEYWORDS = []
	for spam in spam_list:
		Log(sub("\t", ",", spam))
		keyword, url, title, timestamp, ip, clicks = spam.split("\t")
		domain = GetDomain(url)
		KEYWORDS.append(keyword)
		try:
			ATTACKED[domain].append(spam)
		except KeyError:
			ATTACKED[domain] = [spam]
			
	for poor_soul in ATTACKED:
		rcpts = ["abuse@" + poor_soul, 
		"root@" + poor_soul,
		"security@" + poor_soul]
		msg = """From: Helio Loureiro <""" + "helio" + "@" + "domain.com" + """>
To: abuse@%s, root@%s, security@%s
Subject: Service abused from your domain

Hi,
		
I'm the sysadmin from domain eri.cx, a little poor shortener.
Recently I noticed some attacks (SPAM url shorteneds) coming from
your site.

Here follows the logs:

#timestamp|ip|title|url
""" % (poor_soul, poor_soul, poor_soul)
		for spam in ATTACKED[poor_soul]:
			keyword, url, title, timestamp, ip, clicks = spam.split("\t")
			msg = msg + "%s|%s|%s|%s\n" % (timestamp, ip, title, url)
		#print poor_soul, "=>", ATTACKED[poor_soul]
		
		msg = msg + """
It seems your server was compromised.  So please take actions accordingly.

This is an automatic mail report.  My apologizes if it sent unwanted 
information.

Best Regards,
Helio Loureiro
http://eri.cx
"""
		#print msg
		SendMail(rcpts, msg)
		InsertQuarantine(spam_list)
		DeleteEntries(KEYWORDS)

if __name__ == '__main__':
	Log("== Starting... == ")
	Main()
	Log("## Finishing... ## ")
	



Escrito por Helio Loureiro
Categoria:

De tanto @eduardomacan e @ale_borba reclamarem dos meus posts repetitivos no twitter, aqui segue então mais uma dica com Python pra dar um refresco na repetitividade.

Tenho algumas máquina velhas na empresa, umas Sun Ultra 10, que uso pra compilar e testar código.  Uma com Solaris 10 e outra com o 9 (ambas fazendo jus ao nome Slowlaris).  Elas tinham IP fixo e ficavam num ambiente de laboratório, mas recentemente resolveram tentar *cobrar* o espaço físico e a energia elétrica, além da "administração do sistema".   Resolvi então pegar ambas e as colocar próximas de mim, no ambiente de escritório.

O maior problema disso é que o ambiente disponibiliza IP somente por DHCP.  Então como resolver a questão de saber qual o IP da máquina para fazer conexão via SSH, uma vez que o mesmo pode mudar a cada novo boot (e realmente muda por aqui)?

Como sempre, Python veio para salvar o dia.  Uso o programa abaixo para enviar por mail qual o IP do servidor.  É feito para Solaris, por isso algumas definições são específicas, como o uso da interface "hme0" e a localização do comando "ifconfig".  Mas tudo pode ser adaptado facilmente para outra plataforma.


#! /usr/bin/python

import smtplib
from os import popen
from string import split
from re import search, sub
from socket import gethostname
from time import ctime

interface = "hme0"
ifconfig = "/usr/sbin/ifconfig"
mailserver = "mail.internal.domain.com"

def SendMail(rcpts, ip):
	fromaddr = "Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo."
	subject = "== Location update: %s (%s) == " % (ip, gethostname())
	msg = "From: %s\nTo: " % fromaddr
	for n in rcpts:
		msg = msg + n + ","
	msg = msg[:-1] + "\nSubject: %s" % subject
	msg = msg + """

Location update from host %s: %s

%s
-- Powered by Python --
""" % (gethostname(), ip, ctime())
	mail = smtplib.SMTP(mailserver)
	#mail.set_debuglevel(1)
	print "Sending:", msg
	mail.sendmail(fromaddr, rcpts, msg)
	mail.quit()
	
def GetIP():
	for line in popen(ifconfig + " " + interface).readlines():
		#print line
		if search("inet", line):
			line = line[:-1]
			line = sub(".*inet ", "", line)
			line = sub(" .*", "", line)
			
			return line
			
		
	
def Main():
	ip = GetIP()
	rcpts = [ "Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.",
		"Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.",
		"Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo."
		]
	SendMail(rcpts, ip)

if __name__ == '__main__':
	Main()


Em seguida apenas adicionei o mesmo dentro do "/etc/init.d" e fiz o link em "/etc/rc3.d".