teste...: Augusto

Invasão Alienígena...: Outro dia invadiram o fórum do GoblinX e encheram de tópicos sobre cassinos, tive que limitar também o acesso a usuários registrados...


GoblinX, um livecd nacional baseado no Slackware

Não é propriamente uma invasão...: Mas é chato pacas. Mas espero não precisar recorrer a recursos restritivos, como exigir permanentemente o login, ou obrigar o usuário a passar por captchas a cada comentário.

Chato?: chato é apelido este troço.

Eu acho uma porcaria, pois creio que TODAS as notícias aqui publicadas foram infectadas. Mesmo sendo usuário registrado, quando seleciono "novos textos", aparecem TODAS as notícias do BR-Linux, sendo que eu já havia lido todas, para facilitar a navegação.

Sucesso e boa sorte, brain, no combate a esta praga.
Bullshit.

Sim é chato...: Sim, é muito chato e alguns leitores irão se sentir desprestigiados por não comentarem as notícias, porém é ainda mais chato ficar apagando spams... Passei um bom pedaço da manhã de sábado fazendo isso...

Boa Sorte!!!

GoblinX, um livecd nacional baseado no Slackware

Coincidência: brain, acabei de enviar um comentário pra ti perguntando o que você usava pois o mesmo tipo de ataque de SPAM ocorreu no LinuxFUD.

Bom, eu conversei com o pessoal do #drupal-support (não deu pra procurar em http://drupal.org porque o sítio está em manutenção) e me indicaram dois jeitos diferentes:

Módulo antispam, um jeito bem abrangente de marcar comentários como spam e usar um filtro bayesiano pra esse tipo de comentário ser apagado automaticamente.

Detector de mau comportamento, que identifica e trava os spambots pelas requisições deles.

Eu vou começar a testar algumas dessas soluções. Se você achar outras, gostaria de saber de ti.

Obrigado.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Comentários anônimos: Já tomei as medidas necessárias, na dose mínima possível. Reativei os comentários anônimos, mas vou continuar monitorando ao longo do dia.

We are the robots: Já vi isso acontecer em wiki, que é sempre abertão.

Não é tão difícil. É fácil detectar um post com trocentos links e retê-lo automaticamente. Você pode criar uma lista negra de links. E também pode anotar o IP de quem posta e proibir mais de 3 posts por minuto.

Não pode ser um spammer levar a melhor num antro de nerds.

Medidas: - Os IPs desses spambots são altamente variáveis. Proibir por IP não adianta.

- Detectar posts com links acho pouco efetivo também, pois tem gente (como eu!) que adora enfiar links em seus comentários. =P Talvez investigar os links a partir de uma lista negra, mas além de ser uma solução um pouco "pesada" (muitos acessos ao banco de dados), uma das táticas mais conhecidas de spammers é variar domínios, IPs e URLs.

- Proibir mais de 3 posts por minuto não adianta porque se rastrear por IP, é muito provável que o post dos próximos 3 minutos de spambot venha de outro.

- E por último, outra solução que eu tentei mas não deu certo foi obrigar a visualização de comentário antes do post. Mesmo assim, os spambots enviam o comentário. Parecem ser spambots bem inteligentes.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Robôs: Mais ou menos! Das 3 medidas propostas, acho que só a do meio seria mais ou menos efetiva neste caso específico. De qualquer forma, se você quiser contribuir um módulo do Drupal implementando a sua idéia, acredito que muitos administradores de sites pelo mundo podem ficar gratos.

Pessimista: Não é assim.

Um robô até pode trocar de IP a cada "alguns" minutos (eu nunca vi), mas não várias vezes por segundo. Ao tentar disparar 10 posts (ou mais) em um minuto, como eles fazem, já se denuncia e é bloqueado. O IP não fica bloqueado por mais que 1 minuto. O robô pode voltar com outro IP ou esperar passar 1 minuto, mas nunca vai conseguir postar mais que 2 ou 3 vezes por minuto. Isso SE ele tiver redutor de velocidade. Eu nunca vi um que tivesse.

Detectar posts com links não impede links legítimos. Esses robôs são repetitivos. Postam um monte de links mas todos da mesma meia dúzia de domínios, apenas com algum final do tipo ?id=99546DP8. Basta uma expressão regular para bloquear quase todos de forma muito eficaz.

Eu acho muito seguro bloquear por uns 15 minutos o IP de quem tenta enviar mais de 10 posts em 1 minuto. Tá na cara que é robô. Nenhum ser humano escreve algo que preste em 10 posts em 1 minuto. E são mínimas as chances do mesmo IP cair na mão de algum inocente que freqüenta o fórum poucos minutos depois. Se acontecer, foi maus aí!

Outra coisa que parece acontecer sempre é que os spammers desistem quando vêem que medidas foram tomadas. Não precisa impedir totalmente. Basta atrapalhar que eles já vão cantar noutra freguesia.

Spambots: Um robô até pode trocar de IP a cada "alguns" minutos (eu nunca vi), mas não várias vezes por segundo. Ao tentar disparar 10 posts (ou mais) em um minuto, como eles fazem, já se denuncia e é bloqueado.

Um bot de um determinado IP envia posts pro sítio apenas a, digamos, cada meia hora. Mas ao mesmo tempo, 10 IPs diferentes enviam comentários de spam. Sacou? É assim que esses spambots que atacaram o br-linux e o LinuxFUD têm funcionado.

Detectar posts com links não impede links legítimos. Esses robôs são repetitivos. Postam um monte de links mas todos da mesma meia dúzia de domínios, apenas com algum final do tipo ?id=99546DP8. Basta uma expressão regular para bloquear quase todos de forma muito eficaz.

Funcionaria para esses (que afinal usam uns poucos domínios), mas o problema maior que eu levantei não é esse: é que isso como solução genérica contra SPAM pesa para o servidor. Se todo spammer usa, digamos, 10 domínios diferentes e você tem 10 novos spammers por dia, são 100 novos registros no banco de dados pra você comparar por dia (além do esforço de acrescentá-los ao banco de dados. Quem faz isso? Você ou um programa? Como o programa detectaria?). Pra CADA comentário, além do computacionalmente caro processamento de strings a mais.

Outra coisa que parece acontecer sempre é que os spammers desistem quando vêem que medidas foram tomadas. Não precisa impedir totalmente. Basta atrapalhar que eles já vão cantar noutra freguesia.

Isso não corresponde à minha experiência, que vê os spammers como os chatos mais persistentes que existem... E duvido que eles fiquem verificando os sítios atacados pra ver se o post das mensagens deu certo.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Oras: o problema não são os bots....
É o site de cassino.

Atualização: O sítio www.drupal.org voltou e com ele a página dos módulos para o Drupal 4.5.x e por conseguinte o módulo de SPAM para o 4.5.x.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

E se colocásse uma autentica: E se colocásse uma autenticação por imagem, como os webmails costumam fazer para cadastrar, entre outros ?

captcha: Esta técnica, conhecida como captcha ("Completely Automated Public Turing Test to Tell Computers and Humans Apart") é justamente um dos recursos que eu gostaria de evitar (conforme comentário anterior) porque coloca barreiras no caminho de quem quer fazer comentários legítimos também. Mas se não houver outro recurso, acabaremos indo nesta direção.

Augusto: acredito que o uso d: Augusto: acredito que o uso de captchas não é muito chato, já que é uma coisa simples bem rápida pro usuário (geralmente 3 caracteres pra digitar). Acho que seria uma boa.

Re: captcha: Mas ainda sim é melhor que obrigar ao usuário registrar, caso algum dia tiver que caminhar pra isso.

--
Movido a Debian GNU/Linux e anarquismo!
# aptitude install anarchism

Eu acredito no ataque: Discorde quem achar que deve, este é um país livre, mas eu sinceramente acho, de coração que a melhor forma de defesa nestes casos é o ataque.

Muitas pessoas e especialistas de IT reclamaram quando o Lycos lançou aquele screensaver que fazia um DDoS em conhecidos sites de spammers, mas a situação é insustentável! A Internet acabou, fechou, só serve para cassinos online, compra de viagra sem receita e aumento do pênis. Poupem-me!

Por mim se reinaugurava a Santa Inquisição pra caçar estes arruaceiros virtuais.

--
Este espaço está disponível para publicidade.

Augusto, : Augusto,

Uma dica seria você colocar o campo de chave, aonde tem a imagem que gera numeros ou palavras, e requer que o usuário coloque as atribuições.

Exemplo: O que é usado no PHPNUKE para autenticar.

Falou,

Sem esperança: Você é retardado? O cara fala dos captchas, explica o que são e você ainda vem dar uma de professor? Leia as mensagens antes de postar, seu energúmeno.

-: Aproveita que vai mexer no spam e arranca fora o assunto, eu percebo que pouca gente utiliza esse campo, na maior parte das vezes ele é uma replica do inicio do comentario só que cortado abruptamente. Assim voce economiza alguns bytes por comentário no seu banco de dados.
Outra coisa, se for possivel coloca o "Track" que fica nas propriedades da conta ali no menu lateral juntamente com "minha conta, novos textos, desconectar" isso facilita para alguns como eu que fica acompanhando os tópicos de que já participou.
Bom já que é para mexer no SPAM, aproveita e faça isso tambem, na minha opniao ficaria melhor.

Campo assunto: Já que você mencionou o campo assunto, que tal passar a usá-lo? Ele está à disposição, e os títulos são recursos úteis para identificar temas em uma página com muitos comentários diferentes.

Agora que você mencionou, fiz uma contagem rápida entre os 30 comentários mais recentes. Destes, 22 usaram títulos normalmente, 5 tiveram títulos gerados automaticamente pelo CMS (eventualmente cortando palavras pela metade, inclusive) e 3 intencionalmente optaram por colocar um hífen no lugar do título.

Quanto à idéia de que já que vou mexer no spam, poderia aproveitar para mexer em outras coisas, não é bem assim que a coisa funciona sob a minha visão. Eu preferiria nem ter que mexer no spam, mas já que sou obrigado, deixarei de fazer outras coisas para fazer isto, assim como faço sempre que percebo alguma demanda geral. Quanto a mover um recurso que você usa com freqüência para facilitar a sua rotina de uso, acho excelente! Se você me enviar um patch do Drupal (já testado, por favor) ou um arquivo de tema com esta especificação, eu tento instalá-lo para sua conveniência. Se for uma necessidade comum a muitos usuários, estou à disposição para conversar a respeito por e-mail também, de forma a facilitar ao máximo o desenvolvimento do patch.

-: Bem eu não tenho o drupal por aqui, nunca o usei, mas se precisar de algo que valha a pena, é só falar.
O atalho do lado direito para o track economiza apenas um click e eu até que nao ligo muito, o que me entristece mesmo é o campo assunto. Eu acho ele um disperdício, não vou conseguir ponderar nele com prós e contras pois parece mais questão de gosto para a maioria, mas as paginas ficariam menores, perder-se-ia menos tempo ao enviar comentários(se a pessoa tiver que pensar num assunto antes de postar) e economiza banco de dados (provavelmente o indice de busca no mysql vai no campo comentário e não no assunto).
Me parece (veja é uma sensação) que muitos não dão atenção ao assunto porque o comentário vem + abaixo e logo o comentário é que ganha a destaque.
Se desejar eu busco o drupal, e modifico ele para voce, deve ser algo simples talvez apenas deixar o campo (inputbox) assunto em hidden. Topas ? Mas teria que fazer uma consulta prévia, porque afinal de contas deve haver alguem (ou todos) contrário a minha opnião.

Claro que abrir um bugticket ficaria melhor, pois o time do drupal poderia convenientemente deixar isso como opcional no centro de controles. Enfim, o que manda chefe ? :)

Show me the code =): Fácil falar, mas não acha melhor fazer?

Eu sou contra. O assunto do comentário é importante (e por isso é utilizado) e além de tudo é essencial para, por exemplo, a localização do comentário na interface administrativa e linkagem de comentários moderados abaixo do threshold atual. O que isso quer dizer é que introduziria mais modificações do que apenas no campo do formulário e em uma opção da interface administrativa; introduziria problemas não-triviais no funcionamento do CMS.

Agora, argumentar questão de espaço ocupado pelo assunto é fogo, hein? É algo absolutamente desprezível frente a todos os outros campos de um comentário - e nem estou contando em relação ao CMS todo, com todas as suas cerca de 50 tabelas.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Campo assunto: Bom, eu dou especial importância ao campo assunto, e lamento que uma mainoria deixe de preenchê-lo. A maioria o faz, facilitando a vida de quem às vezes procura um tema específico em uma longa discussão. Neste ponto, acredito que não valha a pena modificar código, templates ou temas.

Quanto ao restante, eu não sei. Não percebo a demanda, exceto no teu caso. Se quiseres tentar algo, e não for me dar muito trabalho aplicar o patch, eu tento colocar no ar. Mas se for algo individual, talvez um bookmark ou uma hotkey do navegador sejam mais efetivos, até.

-: multiplique o tamanho do assunto e multiple pela quantidade de comentarios feitos diariamente, pegou tudo ? multiplique por um período como 365 dias, não vamos nem comentar o tamanho da cada página do banco de dados e nem se eles são codificados em formato UTF para não aumentar ainda mais a conta. Da próxima vez, pense em "n".

Quanto ao seu "threshold", voce parece e fala como técnico, mas se for saberia que ninguem identaria registros por um assunto, mas sim pelo ID que cada registro gera. A solicitação é retirar a entrada do dado assunto (o input portanto) e economizar digitação e leitura e não mexer estruturalmente.

"Facil falar...", e voce acha que no meu ultimo comentário eu me oferecí para quê cara pálida ? Da próxima vez, não pense em "n", apenas "pense" :).

-: Essa frase :

Show me the code

poderia entrar para sua lista de FUD, porque os piores programadores são aqueles que já saem programando antes de discutir o assunto. Já passaram muitos assim por nossa equipe, eles acabam disperdiçando códigos (alguns muito bons) porque não entenderam o problema na mesa do usuario, faltou discutir ainda mais o problema.

Como voce mesmo diria, é "fálacia" :).

Drupal: multiplique o tamanho do assunto e multiple pela quantidade de comentarios feitos diariamente, pegou tudo ? multiplique por um período como 365 dias, não vamos nem comentar o tamanho da cada página do banco de dados e nem se eles são codificados em formato UTF para não aumentar ainda mais a conta. Da próxima vez, pense em "n".

Na verdade não precisa nem multiplicar pela quantidade de comentários feitos diariamente. Basta pegar uma média, digamos, de comentários por notícia. Eu não sei qual é a média do br-linux e como não tenho acesso ao banco não posso te dizer isso. Mas vou trabalhar com a hipótese de que temos em média 30 comentários por notícia. Para uma notícia (uma entrada na tabela "node" do drupal), teríamos, de acordo com a descrição da tabela "comments" do drupal:


| cid | int(10) | | PRI | NULL | auto_increment |
| pid | int(10) | | | 0 | |
| nid | int(10) | | MUL | 0 | |
| uid | int(10) | | | 0 | |
| subject | varchar(64) | | | | |
| comment | longtext | | | | |
| hostname | varchar(128) | | | | |
| timestamp | int(11) | | | 0 | |
| score | mediumint(9) | | | 0 | |
| status | tinyint(3) unsigned | | | 0 | |
| format | int(4) | | | 0 | |
| thread | varchar(255) | | | | |
| users | longtext | YES | | NULL | |
| name | varchar(60) | YES | | NULL | |
| mail | varchar(64) | YES | | NULL | |

Que dá, por registro (os cálculos dos tamanhos dos campos podem estar errados, fiz de cabeça e com pressa; assumi 2048 bytes em média para o "comment", que é de tamanho variável, e 10 para o "users"), fazendo um cálculo bem por baixo: 2911 bytes, e o assunto tendo 64. Aproximadamente 2,2%.

Ou seja, por comentário, você teria 2,2%. Quanto aos dados do assunto, suponhamos ter 100 comentários por dia no br-linux; como é varchar, pode variar de 0 a 64, vamos usar a média de 32 bytes. Teremos 32*100 == 3200 bytes por dia economizados. Isso em 2911 * 100 == 291100 bytes.

Se um comentário tiver em média 1024 bytes, a porcentagem muda para 3,4%. A média de bytes dos comentários com assunto por dia, 188700 bytes. Ainda me parece muito pouco para economizar. E a inserção deles é feita em conjunto com os outros campos, ocupando um tempo de processamento ainda menor do que considerando em separado.

Quanto ao seu "threshold", voce parece e fala como técnico, mas se for saberia que ninguem identaria registros por um assunto, mas sim pelo ID que cada registro gera. A solicitação é retirar a entrada do dado assunto (o input portanto) e economizar digitação e leitura e não mexer estruturalmente.

Eu não disse da identificação do comentário no banco de dados (certamente que existe o campo de ID do comentário, como aparece no campo "comments" do drupal que colei aí), e sim de partes do CMS em que o assunto tem que aparecer, senão o link fica vazio; você pode querer mudar cada parte para, por exemplo, referenciar os primeiros 64 bytes do corpo do comentário ao invés do assunto, mas aí, como eu disse, vai ser uma mudança não-trivial, porque você vai ter isto espalhado em várias partes do drupal, inclusive em módulos de terceiro que porventura venha a utilizar.

"Facil falar...", e voce acha que no meu ultimo comentário eu me oferecí para quê cara pálida ? Da próxima vez, não pense em "n", apenas "pense" :).

Uai, mas você só falou mesmo! Não mostrou o código. Falar que pode fazer, mesmo que explique as linhas que vai seguir, não é igual a mostrar o patch que poderia ser diretamente aplicado.

Show me the code! Cadê? Quero um patch, não falatório!

Atualização: utilizei o banco de comentários do LinuxFUD pra calcular a média de ocupação de um comentário inteiro; deu 999 bytes. Para o assunto do comentário, 20 bytes em média, dando 2%. Perto o suficiente da minha estimativa, embora possa ser bem diferente do br-linux.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

FUD: Tudo agora é FUD? =)

Mas eu discuti o assunto, inclusive entrei nos méritos - detalhes do que deve ser feito - bem mais do que você. E eu disse para me mostrar o código porque você diz que é "simples" ser feito; se perceber, o que eu contestei é exatamente que não é tão simples, coloquei os pontos que acho relevantes e problemáticos e, baseado nisso, te provoquei: já que é tão simples, faça o patch e coloque aqui!

Não vamos desgastar o termo! FUD ou falácia é quando falamos algo e não sustentamos com argumento (na verdade FUD é algo muito mais específico, mas ultimamente tem sido usado como sinônimo de falácia). É fácil taxar tudo que discordamos de FUD, e eu até concordaria que seria falacioso eu chegar e simplesmente dizer "não, não é". Mas não foi isso que eu fiz.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

-: 30 pessoas comentando, economizaremos 1920bytes, quase 2K.
mas se não quisermos economizar bytes no assunto, voce ainda pode suprimi-lo para que assuma sempre as iniciais de cada comentario, basta deixar a variavel de formulario subject sempre = "", eis o código (ó vós, os de pouca fé) :
trocar as linhas :

(--
(input maxlength="64" class="form-text"
name="edit[subject]" id="edit-subject" size="50"
value="" type="text" /)(/div)

vamos substituir pelas linhas abaixo, o subject sera
assumido com as iniciais do comentario
--)
(div class="form-item")
(input maxlength="64" class="form-text"
name="edit[subject]" hidden id="edit-subject" size="50"
value="" type="text" /)(/div)

tá dá...
pronto, suprimiu o subject e ainda assim ele existe, eu ainda mexeria na página das listas dos comentários que é longa para caber ainda mais comentários, mas enfim o drupal não é meu, né ? :-)

eu acho o subject sem importancia, voce pensa diferente, viva as diferenças, se eu usasse drupal, meu drupal iria ser melhor do que todo mundo :-)