Visite também: UnderLinux ·  VivaOLinux ·  LinuxSecurity ·  Dicas-L ·  NoticiasLinux ·  SoftwareLivre.org ·  [mais] ·  Efetividade ·  Linux in Brazil ·  Floripa  

Spam em comentários

Os comentários do BR-Linux foram alvo de spam no início da manhã de hoje. A remoção foi tão simples quanto costuma ser, e já estamos voltando à operação normal. Os comentários de usuários não registrados continuam liberados, mas se você ainda não tem login registrado no BR-Linux, renovo o convite para criar um, já que os usuários contam com alguns recursos adicionais. Procurei ativar o mínimo de bloqueios possível hoje, mas se este tipo de fenômeno continuar se repetindo, vou ter de tomar medidas mais restritivas, bloqueando mais palavras e expressões - espero não ser levado a isto. No caso de spam de hoje, os anúncios foram relativos a jogos de Poker, e removi cerca de 400 deles.

Comentários dos leitores

Os comentários abaixo são responsabilidade de seus autores e não são revisados ou aprovados pelo BR-Linux. Consulte os Termos de uso para informações adicionais. Esta notícia foi arquivada, não será possível incluir novos comentários.
Comentário de brain
teste...: Augusto
Comentário de Grobsch
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


Comentário de brain
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.
Comentário de renatogdelf
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.
Comentário de Grobsch
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
Comentário de Patola
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ário de brain
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.
Comentário de Luc
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.
Comentário de Patola
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
Comentário de
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.
Comentário de Luc
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.
Comentário de Patola
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
Comentário de Leonardo
Oras: o problema não são os bots....
É o site de cassino.

Comentário de Patola
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
Comentário de pel
E se colocásse uma autentica: E se colocásse uma autenticação por imagem, como os webmails costumam fazer para cadastrar, entre outros ?
Comentário de brain
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.
Comentário de Peter Parker Is No Logged
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.
Comentário de semente
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
Comentário de Tango
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.
Comentário de wrochal
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,
Comentário de clueless
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.
Comentário de hamacker
-: 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.
Comentário de brain
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.
Comentário de hamacker
-: 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 ? :)
Comentário de Patola
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
Comentário de brain
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é.
Comentário de hamacker
-: 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" :).
Comentário de hamacker
-: 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" :).
Comentário de Patola
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
Comentário de Patola
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
Comentário de hamacker
-: 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 :-)
Comentário de Patola
Mas isso não resolve o problema: Nas páginas em que se precisa do assunto para localizar o comentário, como a página de administração que mostra todos os comentários pra você apagar ou modificar, você fica sem ter algo em que clicar; e se você modificar para algo diferente de vazio (digamos, "-"), ainda assim não dá pra diferenciar um comentário do outro (o assunto não é a "chave" do comentário, mas na prática funciona como "chave" para o administrador localizá-lo). A não ser que você use o que eu falei, pegue os primeiros 64 bytes do comentário para colocar no campo assunto.

E ao falar que não quer mais economizar os bytes do comentário, então você tira o que me pareceu o objetivo primário de sua sugestão. Ou seja, chegamos num ponto em que você mesmo invalidou seus argumentos.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Comentário de hamacker
-:
"E ao falar que não quer mais economizar os bytes do comentário, então você tira o que me pareceu o objetivo primário de sua sugestão. Ou seja, chegamos num ponto em que você mesmo invalidou seus argumentos."

Sentí uma provocação aqui, tudo bem, volte lá e leia minha mensagem novamente "mas se não quisermos..." acompanhada antes de "economizaremos 2K a cada 30 mensagens" é bem diferente do que voce esta afirmando. Pode provocar eu não revido. Oras, não dá para ter tudo, dá ? Eu ainda ganhei um mestrado de calculo de tupla, fiz voce consultar a estrutura da tabela (ficaram faltando os collates hein?),... eu tinha que dar algo em troca, em troca não estou "fundamentalista" sobre a questão dos bytes.

Mas (sempre há um "mas"), dá para agradar os dois lados, aplicando o patch, eu não digito comentário nenhum e por outro lado voce ainda tem comentário. :-)

Este não é um jogo de quem ganha ou perde, senão seria um ping-pong pouco produtivo, até porque minha mente fica sinistra neste aspecto e o fim é previsivel, o argucioso considera seus passos.

Antes que eu me esqueça :
"A não ser que você use o que eu falei, pegue os primeiros 64 bytes do comentário para colocar no campo assunto."
No drupal, isso já é assim, experimente não colocar nenhum subject.

inte+
Comentário de Patola
Ok: Agora entendi seu ponto.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
BR-Linux.org
Linux® levado a sério desde 1996. Notícias, dicas e tutoriais em bom português sobre Linux e Código Aberto. "A página sobre software livre mais procurada no Brasil", segundo a Revista Isto É.
Expediente
Sobre o BR-Linux
Enviar notícia ou release
Contato, Termos de uso
FAQ, Newsletter, RSS
Banners e selos
Anunciar no BR-Linux
BR-Linux apóia
LinuxSecurity, Tempo Real
Suporte Livre, Drupal
Verdade Absoluta
Pandemonium
Efetividade, Floripa.net
sites da comunidade
Ajuda
Moderação
Flames: não responda!
Publicar seu texto
Computador para Todos
Notícias pré-2004
Tutoriais, HCL pré-2004